random musings on life, music, and technology

I recently heard a software engineering director candidate with many years of web development experience describe Ruby on Rails as “just another web framework”.

That’s what I thought too, until I spent some time working with it over the past 8 months.

The fact is, Rails is much more than that. It is a radical paradigm shift away from both the bloated, configuration-based methods of J2EE and the chaotic hackfest that is PHP.

Here are my top 3 reasons why I think Rails sets itself apart:

- The ActiveRecord ORM. This is the first ORM I’ve worked with since NeXT’s Enterprise Object Framework that really lives up to the promise of ORM’s, and does so with minimal configuration and fuss.

- Terseness. The syntax of Ruby on Rails applications is remarkably terse. It can be a bit daunting at first, but after a while you begin to realize what a huge cognitive win this is. Getting rid of all that unnecessary syntactical noise makes it much easier to focus on solving problems.

- Gems. The eco-system of 3rd party components for rails in unlike anything I’ve ever seen in any development community. There are some truly remarkable gems, such as this one for authenticaion, or this one for creating seed data for your project. The time savings these gems provide cannot be overstated. And it’s fascinating to watch how the Rails community seems to converge on certain gems, which become almost part of the “standard”.

Rails is making web development fun again. I’m so glad I jumped in the pool – the water’s fine!

Which of these PHP statements do you think is faster:

array_key_exists($key, $array);

vs.

isset($array[$key]);

??

If you said “isset”, you’d be right! It is approximately 60% faster, as others have noted.

This is counter-intuitive, and seems like a very easy optimization could be made to bring the performance of array_key_exists() up to par with isset().

Here’s a handy Ruby script I wrote a few months ago to extract email addresses from a blob of text.

In this case, all of the email addresses are surrounded by angle-brackets, so that makes the script much easier.

It’s kind of trivial, but a nice little example of the elegance of Ruby:

#!/usr/bin/ruby -w

IO.foreach("data.txt") {|line|
    line.scan(/<.*?@.*?>/).each{|addr|puts(addr.delete('<>') + "\n")}
}

My blog was starting to have major problems recently – most notably, Akismet stopped working, and the spammers were getting through again. I tried to upgrade WordPress, but my database was out of date.

So I finally bit the bullet and did a clean install of the version of WordPress supported by my hosting service, and began the painful process of converting my data to the new version.

I’m in the process of restoring things (my user table for example). So if you want to leave a comment before that happens, you might have to sign up again. Very sorry for the inconvenience!

I’ve been working with ExtJS now for about 7 months. It’s an amazing library for building Rich Internet Applications in Javascript, arguably the best available. However, as I’ve blogged about previously, the API is so huge and rich that it can be hard to find what you’re looking for.

For example, here’s a problem I ran into today:

- I note that a long field label is wrapping and would like to fix this.
- checking the code, I see this is an Ext.form.Textfield inside an Ext.form.FormPanel
- using Firebug I see it has a width of 100px. I verify that setting it to 200px fixes the wrapping issue.
- I check the Ext.form.Textfield docs.* No obvious way to set the width of the fieldLabel.
- try setting autoWidth: true on the Textfield. no change.
- try setting grow: true on the Textfield. no change. although not specified in the docs, these properties seem to apply to the field only, not its label.
- try google: “Ext.form.Textfield change fieldLabel width”
- found forum post that refers to the “labelWidth” property of Ext.form.FormPanel. Voila!

*Here is where I made my mistake. I assumed Ext.form.Textfield would contain the property to control its labelWidth, but it was actually the FormPanel that controls this for all of its elements. This is a common pattern with ExtJS – if the property you’re looking for isn’t on the object you expect, check its “container” object.

Of course I still don’t know how to override the labelWidth for a specific TextField, but I’m sure it’s in there somewhere…

Since the mid-90′s, I’ve worked fairly extensively with nearly all of the major Relational Database vendors: Oracle, Sybase, SQL Server, DB2, and MySQL. (Even dabbled a bit with Postgres.) I’ve been able to do this without too much trouble because, until fairly recently, the SQL implementations provided by the various vendors were not that different.

Over the past few years though, I’ve noticed more and more deviations from standard SQL coming into play, mostly from MySQL. I’ll admit I do not follow developments in the ANSI spec process, so some of these may be SQL-92 standards, but I suspect most are not. For example, take “INSERT IGNORE”. As others have noted, this is useful for developers, but it’s non-standard, and therefore not easily portable. Another example is “GROUP CONCAT”, which has created major headaches for some developers .

Oracle of course has its share of non-standard operators as well, such as “MINUS” and “INTERSECT”.

One could certainly argue that vendors are merely being “innovative” here, but one has to be careful when choosing to use these non-standard features. MySQL does not clearly point out in their documentation when they are deviating from SQL-92. Unless you are very certain that you will never need to run your code on a new database, these functions are probably best avoided if possible.

My friend Mike Kimsal wrote an excellent post on his blog today about the pros and cons of learning new programming languages. It inspired me to leave the following reply, which I decided to post here.

I’m not sure if I’m the friend you were referring to who was “forced” to move from Java to PHP and is now loving it (paraphrasing), but that is sort of my situation. PHP (or perhaps more accurately, the entire LAMP stack) is now the 3rd web dev stack I’m working with, having started out with Objective-C and Apple’s WebObjects (which spoiled me for everything since), then moving to J2EE. All of these environments have their pro’s and con’s. In my case, learning these new languages was literally a matter of survival. I have a few “die hard” friends who refused to acknowledge that Obj-C/WebObjects was dying, who are now struggling to make a living writing apps for the Mac and iPhone. I’m also starting to see the writing on the wall for J2EE. Certainly one can still make a good living with Java, but fewer and fewer new projects are using it. Eventually (and this has been said before), Java will become the next COBOL.

PHP is popular among web developers in part, I think, because of its similarity to Javascript, both in terms of the “dynamic” nature and even the syntax itself which is pretty similar. Many Web developers seem to be allergic to compilers, whereas I am still a big fan of them, as long as they are lightning fast and rock solid (which has been the case with Java for some time now).

In terms of productivity, I have come to realize that with PHP you are trading off speed for maintainability. It’s very easy to build things quickly with PHP, but fixing bugs and maintaining the code is very hard, because the dynamic, loose typing means the IDE and compiler cannot help you navigate the code or automatically find problems in it. For example, there is no easy way to definitively find all usages a given PHP method, even with PHP5 and the latest IDE’s. The fact that you can define new variables on the fly means you can easily create bugs like the following:

$user->getEmployee($id);

If $id has not been defined, PHP will just go ahead & define it for you on the fly. In Java, this statement wouldn’t even compile if $id hasn’t been defined yet.

So PHP requires more cognitive overhead while you are writing the code as well. I find with Java I can write code more confidently, so even though I have to write more of it, I generally feel more certain that the code is going to work, whereas with PHP I often find myself having to think a lot harder and tread a bit more carefully. Surely that’s just lack of familiarity to some extent, but I do think the languages themselves have some strengths & weaknesses. Basically I think PHP is great for new “startup” projects that may have a short shelf-life, whereas Java is better for very complex projects that are going to be around for a very long time.

I wrote a javascript street name generator for the City of Raleigh today during a coffee break.

I hope the City finds it useful.

(The Towns of Cary and Apex can use it as well, of course.)