Ionrock Dot Org

Note: I am making an effort to blog about my work and what I do during the day in hopes that I can learn more from my experiences. So I apologize for assumed knowledge in posts.

Only after you finish something do you think about what sources you could have potentially looked at for solutions to a problem. A great example is a recent table issue I addressed at work. The issue was essentially settings for whether a row or column has a span were getting dropped. Looking back I realize it might have been a good idea to look into how browsers implement this. Of course that would have been a project unto itself.

This is often the case. Today, for example, I wanted to write a blog entry but I didn't want to actually visit my blog admin page. I can't stand using the forms because there is no spelling checking. Yes, I know about firefox extensions and how there are spelling checking tools. The problem is these sorts of tools always get in the way after a while. My blogging solution then was to write a quick script for sending an XML-RPC request to my blog using the MetaWeblog API. This was a seemingly simple task. A few hours later of peripheral browsing while working on my table issue, I find nothing more than a large script for sending the message. This was much more complex than I had hoped and my desire to write a blogging tool quick diminished.

In some ways you could call me a quitter for not spending the time to get done something I wanted to do. In some ways you would be right, but in reality the issue is I have no patience with complexity. The other day I played around with Rails for a moment and realized the biggest contrast compared to something like TurboGears or Pylons. Rails makes assumptions because it is faster. This is arguable of course, but if you assume that it is not, then it is a fact! This is what TurboGears and friends do not do well at all. There is no assumption made about the file names, directories or anything else and this is what hurts it.

The downside is that by making assumptions, it is required that every piece must tested. This was the issue in my table problem. I had to verify every single character I typed, which was very error prone. Fortunately, Rails (and the Python based derivatives) all have good debugging facilities, which was far from anything I had with the table issue. Had I been able to assume a piece of the code was correct, I could have been in a fourth of the time.

Framework rambling aside, I am very proud I fixed the table bug. It was a huge bug that should have been handled a long time ago. Sometimes things slip through the cracks and even though it is a little embarassing when it happens, it feels good fix it in the end.