Rockstar Engineering

What My Teacher Didn’t Teach Me: Views

Posted in Software Design, Software Development by Jose Asuncion on April 11, 2012

My teacher in the university taught me how to translate relationships among data models into a relational schema. For example for the following ER Diagram,

I was taught that to list down magazine’s authors, I would have to create a separate table with the foreign key ids from the author and magazine table. Before I found myself making use of triggers to populate the magazine-author table whenever an article was published. Triggers were a nightmare. At one point, I couldn’t figure out why my database tests were inserting initial data two times into a relationship table. The culprit as I found out was that I forgot there was already a trigger that was populating a relationship table after inserts on other tables. Hence, there was no need to populate the relationship table. I thought that was nasty and that I would never use triggers again if only for the mere fact that you could forget they exist.

Of course you could always join. But I was too lazy for that. Some ownerships go a long way up or down whichever way you look at it.

As I have found out however, I think Views posit a better solution to show relationships in some cases. Here are just some things that I like about them:

1. They are easier to query. They abstract the more complicated query of joining author to article to magazine just to show a list of magazine author’s.

2. They make more sense. Compare the following two queries that lists a particular magazine’s authors:

FROM author
JOIN submissions ON = submissions.author_id 
JOIN publications ON submission.article_id = publications.article_id 
WHERE publications.magazine_id = 1

to this one:

SELECT name FROM magazine_authors WHERE magazine_id = 1;

I am really not so sure what the cons are right now. Performance perhaps? Maybe they will reveal themselves later on.

A Note To Self On Performance : You Ain’t Gonna Need It…Just Yet

Posted in Uncategorized by Jose Asuncion on March 12, 2012

Last week I was tasked to write a publishing api for our company’s web and mobile platforms. The thing about this task was that it already had so many rules to begin with. Furthermore, the data structure of the article itself was an sql nightmare! I had to join to a lot of tables, create new ones to show relationships. Sorting was tricky. I had to sort on three levels, by type, and then by favorites and then by featured.If that wasn’t enough, I had to format the data returned by the database. Sql doesn’t return a has many (one to many) relationship in one data structure but in several rows.

The thing about my approach was that I had tried to fit a lot of rules in one sql query for “performance”. I already was calling three web services and I thought calling just as many queries would grind the api to a crawl. But doing as it turns out was a pretty horrible idea.

One thing I ran into a lot was problems with our persistence framework, Doctrine. I couldn’t join three tables without selecting at least the id of each of them. When I did, Doctrine complained that I had to at least also select a column from each of the tables other than the id. There are so much more that I can’t remember them all but the point was, these hurdles I ran into seemed to not end.

The lesson I learned from this one was not so much to hate ORMs (because of the limited functionality they give you as compared to using sql) but rather not to optimize prematurely. By doing the latter, I make baseless assumptions and acted on them when I didn’t need to just yet. Of course it’s not illogical to think that one query is faster than two queries but, looking back, I asked myself if it was really more important than delivering the functionality required. This lesson, as I have recently read, is concisely summed up in an agile principle: YAGNI: You Ain’t Gonna Need It.

For the Nth Time, the Factory Method: A Simpler Introduction

Posted in Software Design, Software Development by Jose Asuncion on March 1, 2012

I don’t know what it is, but it took me a long time to finally wrap my head around the Factory Method.

I always found the tutorials at Google not very helpful. My number one source of information wikipedia featured a very simple example that didn’t seem to drive home the point. Here it is for reference:

class Complex {
     public static Complex fromCartesian(double real, double imaginary) {
         return new Complex(real, imaginary);

     public static Complex fromPolar(double modulus, double angle) {
         return new Complex(modulus * cos(angle), modulus * sin(angle));

     private Complex(double a, double b) {

The first thing that came to my mind when I saw it was that, what’s stopping me from just instantiating the above like so:

Complex number = new Complex(real, imaginary);

I know for one thing that it was a creational pattern but I never found an opportunity to use or apply it. That day has finally come though.


Tagged with: ,

Just My First Javascript Unit Test In Pictures

Posted in Software Development by Jose Asuncion on February 23, 2012

I used Mozilla Rhino + RhinoUnit for this experiment.

This is how you write a javascript unit test using RhinoUnit

Ant is used to run the tests. I wonder how I can run it without using Ant.

The javascript test in action

Tagged with:

Can Arrays Be Used as Domain Objects?

Posted in Software Design, Software Development by Jose Asuncion on February 23, 2012

Ever since I started programming in PHP and Python, both dynamic languages, from Java I have had a debate with myself  on whether or not to use arrays as business domain objects. I noticed the codebase I was working in passed arrays a lot in $params variables.  In this post, I share, literally , the debates I had with myself regarding this issue in an easily digestible debate themed blog post!

Can Arrays be Used as Domain Objects?

I use arrays because, at the moment, I am currently using PHP in my work. But this can easily be translated to dictionaries in Python or  wait what Maps in Java? From the pov of someone who used to program enterprise Java, it already sounds like bad design. Is it?

Tagged with: , ,