Are You Still Parsing HTML Element Ids?

To render a list, often times we use repeated HTML elements with a similar template. For example, the search results in ebay.com is a list of divs, each containing different data in the same template. In a server side, this rendering code is somewhat similar to this:

If you noticed, a product with it's database id = 123 will be rendered inside a div with id="product_123", and similarly div id="product_456" will contain the product with id = 456.

With such ids, we can write JavaScript code that can extract the database id of a selected product to do interesting things, for example:


This is a useful and a common technique. However, in this era of HTML5, we can make use of its custom attributes feature to write a clean JavaScript event handler without the help of parsing. Here's an example:


I will never parse my HTML element Id again. What about you?

Object Versioning is an Open Design Problem

This unsolvable maze is a local food from Bangladesh, known as Jilapi
Photo credits to udvranto pothik

Object Versioning is often required by a business rule, for example, to maintain an audit trail or to be able to revert to a previous version, etc. This is the 3rd time in my career where this Object Versioning requirement made me think like -

There's gotta be an easier solution! 

But, I am yet to find one. So, I am thinking it's one of those open design problems, may be.

To clarify the requirement with an example, let's consider the following scenario:

A lawyer is preparing a document for one of her clients using a software. On January 17th, she needs to take a look at the version of the same document from May last year so that she can backtrace some changes that took place during these months.

Lets assume the lawyer is using a software that stores the documents in a relational database with the following schema.

A Document has many Evidences, each provided by an EvidenceProvider

Document (id, client_id, case_id, name)
Evidence (id, document_id, evidence_provider_id, details)
EvidenceProvider(id, name)

Now, given the versioning requirement how would you design your data model?

Here's a couple of points that your design should address at a minimum:

• Going back to a version means a complete snapshot of the old version of the document. So, the version of May 1st should only bring the evidences that were there on that very day.
• As a new version is created, it should inherit all previous evidences.

As I have mentioned earlier, I am yet to find a good data model that can take care of these concerns without over-complicating everything. Let me know if you got a beautiful solution to this problem.

However, in my latest project, the requirement is even harder. It's somewhat like this:

The lawyer may have some documents in the "work in progress version". This means, if she needs to print a document for the court, she only wants to print the last "good version", skipping the "work in progress version".

Also, when there is such a "work in progress version", she needs to attach any new Evidence to both the last "good version" as well as to the "work in progress version".

Well, now you see the design of a data model for Object Versioning becomes really messy and unintuitive.

So, here's my question to you - how would you design a solution for this?

Care Driven Development: Javascript

There is * Driven Development, where they listed "all possible thing" driven development and dedicated a whole website to it! Well, I am adding one more to the list, "Care Driven Development", with an emphasis to Javascript coding.

Javascript coding, do you care enough?

CSS is the most hairy spagetti piece of almost any web project. And its not leading by a far distance to it's first cousin; Javascript. But, the good thing is, it just takes a little care to clean the bush out of Javascript and make it pretty.

Do you care enough not to use the following ever again?

• $('#deep_under_the_ocean').parent().parent().hide()?
• $.ajax(url: 'bank_accounts/transfer_money', amount: 500...)
• $('#eiffel_tower').height($('#paris').height() +  $('#eiffel_tower base').height() + $('#eiffel_tower tower').height() + ...)
• populateNewYork('east', 'north', 50, 100, 23, ...)
• $('.shark').click(function(){$('.small_fish').attacked(function(){...})})
• parseInt($('.selected').id().split('-').last())

I am compiling a list of such careless JS coding examples and this is just a start. If you have a few to add to this list, please keep sending!

Enterprise Software Projects: oh, yeah!

I just rolled off my first ever enterprise software project couple of weeks ago. After staying six months on the project and while the memory is still fresh, I thought I would write a retrospect on the project and on my role.

The program is rather big, I guess it had ~300 people for the last couple or so years. I joined late for the program. So, by the time I went there, a massive amount of work has already been done, meaning a huge learning curve for me. On retrospect, I think I did well :)

My team was small, 4-5 people including 3 devs. But we were responsible for really high value enterprise integration work, especially, linking the two most important applications in the program. This was a great place to learn some of the core business domain specific knowledge and I loved it!

However, enterprise integration stuff is full of XML messaging and translation. While XSLT works when it works, in our situation we had too much logic and stateful data involved in the translation. So, we had to write a hell lot of custom code for all the XML messaging... and it sucks! Why?

Service APIs change all the time! 

I was mostly writing Java at work in this project for the first time in my professional career. This was a big change as well as a good exposure, considering my recent work mostly being in C# and Ruby.  In retrospect, I would say, I would rather not use Java, its a great platform but offers your an aging language.

Being in the enterprise world means dealing with enterprise service buses, queues, oracle database, weblogic, load balancers, risk and compliance and you name it... sometimes the complexity of these things seemed to be unnecessarily troublesome, but then again, at times they made sense as well.

People factors matter way greater than any other factor in such a big project. In retrospect, I think a hierarchical system often leads to longer meetings, useless communication and less ownership for most people.

I will continue this post to a second episode where I will talk about development practices, challenges with multi-project communication, politics and power relations etc. Stay tuned! 

Aligning an HTML DIV Inside Another One

Across different projects, I have found people taking CSS shortcuts for translating the Photoshopped design templates into HTML. Back in the days, layout used to be all Table based and it was kind of straight forward to fit everything into grid cells. However, with CSS styling the extra flexibility to put elements in any arbitrary layout came extra responsibility - to make sure things still align nicely while being fluid to accommodate different screen resolutions and form factors.

Aligning the child div in red inside a parent div in green using CSS

Here's a quick and dead simple example to create CSS alignment for a div inside another one!

Pro Tip: Use position:relative for the parent div and position:absolute for the child div.

This will make sure the parent is positioned relatively to other elements in the page. However, the absolutely positioned child can be positioned anywhere inside the parent without making the whole layout fixed.

Using instanceof is mostly a Code Smell

When using static programming languages such as Java, often time I have seen people writing methods that accept Object as a parameter. These methods typically don't really work on any Object, but works with multiple types of classes that don't have any common base class. Here's an example of such a method:

As you can see in this example, the process method actually expects one of CleanFloor or LaunchRocket instances. However, since the two don't have a common subclass, it falls back to an Object type. And that results in the smelly code as you see in the example.

An ideal solution would be to change the design of the classes so that you can either use a common base class or a generic method. But if you can't just do that

Get rid of the instanceof anyway!

However, this doesn't need to be smelly. Turning to basics of OO programming concepts, you will recall that there's this thing called method overloading that is specifically there to solve this very problem.

It seems so obvious in this example that you might question, why someone would use the former code? Well, I have seen quite a few of them and if you search for instanceof in your Java project, I won't be surprised if you see a few code fragments that match the former example.

Nightly Build is a Warning (or Horror)

Photo credits: insidethemagic

I think, Nightly build is an anti-pattern for Continuous Integration. If you are integrating continuously, then you shouldn't need a nightly build, that would be too discrete :(

If you already have a per-commit continuous integration setup, you shouldn't need the so called nightly build unless there's something bad about the code.

Often times, builds taking >10 minutes are put in the bucket of nightly builds.
Some people put batch processing related tests under such nightly builds. A colleague told me they used nightly build to clean up resources (disk space, recreate the database etc.) on a nightly build - to ensure the apps worked fine on a fresh state.

Under most circumstances, a nighly build means something long running. That in itself can be an indication of poor performance.

But what I have seen is, when such nightly builds are broken - they are rarely looked after or cared for. Because, first thing in the morning, who the hell wants to look at that broken nightly build? Even if someone takes a look, since its long running, it might well eat up all morning to actually try/fix/commit changes and see it go green again! Since it takes longer to make the build green, people keep delaying it for later... meaning

it becomes generally acceptable to let the nightly build stay in RED. 

And once people get used the redness of the nightly build, they start ignoring it, inevitably.

So, here's what I would do:

Avoid nightly builds altogether.
Avoid nightly builds altogether.
Avoid nightly builds altogether.
Otherwise, make one person from the team responsible for the build (rotate people).