I had read and heard lots of praise about Rails and was planning to add another skill to my list. I thought to myself that if I’m doing him a favour he can put with the slow speed of a developer  learning a new language and framework.

Whilst working through the documentation and tutorials I couldn’t help comparing Rails to Django, since it is the framework I’m most comfortable with and it takes a little time to unwire your assumptions and expectations of how a web framework ought to work. So, basically this is a one-sided mini-review of Rails.

The Ruby language

I’ve read that Ruby lacks the amount of non-web libraries that Python has. But that doesn’t bother me since I almost exclusively do web stuff. I’m simply not clever enough to have a use for for SciPy and NumPy.

What I don’t like about Rails

ActiveRecord

The abovementioned project obviously didn’t need a really complicated data model: a handful of entities with some simple many-to-ones. Particularly because ActiveRecored markets itself as a simpler solution to heavyweight enterprise ORMs like Hibernate, I found setting up this schema surprisingly difficult. Compared to Django, Rails introduces a few new concepts, which took me little bit to get my head around it.

• separation of schema and model: in Django the model is the schema and I couldn’t really understand why those two things should be separate
• migrations: I can see how this could come in handy but in my case this was yet another extra thing I had to keep tabs of
• if you have a many-to-many relationship you will have to define a join table yourself; in my view this is exactly the type of thing that an ORM at the abstraction level of ActiveRecord should take care of

Particularly due to that last point I kept thinking that ActiveRecord is just SQL rewritten in Ruby.

Templating

Using pure Ruby in .erb templates surely is powerful but to me smells of Java Scriptlet, doesn’t it? I subscribe to the view that the template language is for designers and should only allow safe constructs. Not really a biggie, but rather a little quirk.

No built-in admin

This is something I love about Django and find kind of a deal-breaker with Rails. Django gives you great looking admin interfaces for editing your data out of the box. It takes you 95% of where you want your admin area to be and I myself never had the need to customize the template. I hear that with the introduction of the newforms library it is now not so hard anymore to write your own admin views. All in all, I’m pretty surprised that Rails hasn’t event got anything remotely similar. (Maybe I have given up looking too soon? Let me know in the comments.)

What I like about Rails

Directory structure

Rails is pretty good at giving you a feeling of where your files ought to be in the directory structure, by neatly giving you a controller per model. Also, I quite like the distinction between the top level folders config, app, db, test etc. This is, in my opinion, something of a weak point in Django, where I never quite understood where stuff is supposed to live. Yes, you say that you should be separating your code into individual Django apps but I think that is the wrong abstraction level and like the concepts of plugins somehow better. That might be the Java developer in me speaking – a gem is much more like a JAR.

Dependency management

It’s great that you can specify the needed gems for your application and even tell the runtime that you need a specific version of Rails. I haven’t tried it but it seems that the needed gems are automatically installed if they aren’t already. Managing your dependencies is kinda non-existent in Django.

Grass isn’t always greener

Well, I don’t really know what I expected but Rails does not magically solve all problems and does not trivialise web development. On the other hand I wasn’t unhappy with Django – I just wanted to expand my horizon.

Rails certainly boosts your productivity but I found a few things, mostly around ActiveRecord, a bit strange and counterintuitive. I can’t say that I have fallen in love with Rails but it is a solid framework worth its popularity. Bear in mind that this is me speaking after using Rails for about 2 weeks – I’m sure I have only scratched the surface of the things that Rails can do for me; I hear that the testing and deployment tools are fantastic. Maybe I’ll do a follow up post on how my view changed after I used them.

Soon, however, I discovered that it had a few bugs: It was borking non-ASCII characters. And there didn’t seem to be a way to exclude certain folders so it was often listing tags twice in the resulting documentation. Another gripe I had (which is also the case with the regular JavaDoc tool) was the extremely ugly mid-90s default stylesheet. The tool seemed to have been abandoned (last change in 2005), but I managed to checkout a working copy from their CVS. Stupidly, dev.java.net requires an account to simply checkout code, but luckily I found account details on bugmenot.

The tool

Weirdly the code didn’t compile straight away as two classes were missing, but I just rewrote them. I also added a nicer stylesheet, which I pinched from JBoss.

The character encoding issues simply went away by recompiling the project with Java 1.5 compatibility settings. I also put the code under Mercurial version control (screw CVS) and uploaded it to my bitbucket.

Getting it

Just go to taglibdoc-ng’s page on bitbucket and read the technical details. Or you simply head over to the downloads page and grab the latest JAR. I have plans to put it up on Maven Central, but to be honest have never done that so will have to find out how easy that is.

Buzz in itself is also not very Googley so I was scratching my head what it was all about. Then I read column in the New York Times:

Facebook and Twitter will face renewed pressure to publish and consume standardized data feeds as well now. If Buzz is big enough, it could break the dam holding back a flood of standardized data. Where there is standized (sic) data, there is scalable network effects, consumer choice, competition and thus innovation.

Maybe Google isn’t really interested in providing another me-too product. Maybe they want to pry open Facebook and their social data feeds so they can organise and rank them, making them useful for their users. Think of a Google Reader for Twitter/Facebook/Friendfeed. Then do what Google does best and slap a few ads in it and bingo! As always Google isn’t really a content provider but rather a way to channel all the available content out there and make it into a neat, bite-size parcel. That’s what made them what they are today.

When I started learning how dependency injection works it was extremely hard for me to understand. Once I got what it does I still didn’t quite get what the benefits of this technique were. I just thought it was some overly complex design pattern that is just making life difficult for the sake of it. After all, what is so bad about using new anyway?

Well, in this blog post I want to share what I have learned about dependency injection since leaving university and a becoming full-time programmer last September. I hope I can help a newbie to understand a little more about this design approach. Don’t be frustrated, however, if you don’t get it straight away: It took me the best part of my first month to really dive into dependency injection even though I had read lots of articles and blog posts about the topic.

Dependency injection vs. Inversion of control

Some authors strangely claim that DI is the same thing as IoC. I however think that DI is a type of IoC, namely to tell the to be injected object what its dependencies are. Inversion of control, to me, means something more general: That there is a predefined workflow (the control part) that the developer hooks her own components into. This principle applies to virtually all libraries and frameworks. For example, your favourite web development framework allows you to write a request handler for a URL, but most likely you can’t change the nature of the request itself. You will always receive a HttpRequest as the input of your request handling code. Dependency injection however is a specialisation of this principle.

Modules and dependencies

When you start to build big systems you naturally tend to modularise. Lets take online shopping as an example. You have one module of your code handling the user input for an order and validating form fields; lets call this module the OrderHandler. Then you have another module, which opens a connection to your payment provider and checks that the credit card data the user just gave are actually kosher and the payment can go ahead. We call this module the CreditCardPaymentService.

So, when the OrderHandler has validated all the form fields it passes the data over to the CreditCardPaymentService. But before it can do that it needs to have or create an instance of the CreditCardPaymentService. In (pseudo-) code this would probably look something like this:

class OrderHandler:
   this.payment_service = new CreditCardPaymentService()
   handle_request(request):
     # do something to validate the user input...
     payment_data = request.get_parameters()
     response = this.payment_service.handle_payment(payment_data)
     if response.successful():
         return new HttpResponse("Payment accepted")
     else:
         return new HttpResponse("Payment declined")

So far, so good. But what happens when you have quite a few parts of your code taking orders and querying the PaymentService? They all call new CreditCardPaymentService.
Now, your boss has decided your going to switch from your old credit card provider to Paypal. You write a new PaymentProvider that sends a request to their server and authorises the payment. When you actually want to switch over, you will have to replace all instances of CreditCardPaymentProvider with PaypalPaymentProvider. Once you do these kinds of thing a lot, you’ll end up thinking that there’s got to be a better way to do this.

DI to the rescue

What if all the different modules of your shopping website, instead of creating new instances of PaymentProviders, would instead be given (or injected) those modules?

Maybe we could rewrite the above code like this:

class OrderHandler:
 
 this.payment_service=None
 
 set_payment_service(payment_service):
    this.payment_service=payment_service
 
 handle_request(request):
    # do something to validate the user input...
    payment_data = request.get_parameters()
    response = this.payment_service.handle_payment(payment_data)
    if response.successful():
        return new HttpResponse("Payment accepted")
    else:
        return new HttpResponse("Payment declined")

Obviously now it is easy to exchange on payment provider with another one. The downside of this that you have to pre-configure the OrderHandler with some type of PaymentProvider. Most DI frameworks do this using Factories and assign each configured, ready-to-use object a string. A factory is supplied with some configuration file that defines those objects and their dependencies.
Those config files could look like this:

/* objects.conf */
#cc_order_handler{
  class: OrderHandler
  payment_service: CreditCardPaymentService
}
 
#paypal_order_handler{
  class: OrderHandler
  payment_service: PaypalPaymentService
}

We now have a central piece of code that handles each module’s dependencies. It basically instantiates the OrderHandler, sets the right payment service and then gives this object to whoever wants to use it. If we wanted to fetch on of the order handlers we would do it like this.

factory = new ObjectFactory("objects.conf")
paypal_payment_handler = factory.getObject("paypal_order_handler")

What you have done now is to externalise the configuration process of  the Handler from inside it to the factory with calls the set_payment_provider method before it returns it to whoever is requesting the object.

As an added benefit we can now easily unit-test the OrderHandler by creating and injecting a fake PaymentService that always returns a positive response.

Implementations

This principle is currently used in a lot of enterprise Java applications. The most popular framework that uses this pattern is Spring. Spring uses XML files for configuration and much of what I described above stems directly from Spring, which actually many more things and DI is just one, albeit central, aspect of the framework.

Another piece of code I also want to have a look at is Google’s Guice which superficially looks less all-singing, all-dancing, but still very interesting.

It’s the same for all Google accounts:

https://www.google.com/accounts/o8/id

Your username is not part of the OpenID.

Long answer

Well, it seems little strange that Google, your friendly neighbourhood search giant, is so coy about its OpenID support. I had to search around for quite a while to find my OpenID URL, which is the thing you paste into the OpenID box at the service you want to sign up to.

Logging in with your OpenID URL

Why is Google doing this, you may ask? They are usually very good about these things and usually support an open standard (like they have done with XMPP, which they use for Google Chat.) My suspicion is that they want to plug their own OAuth instead, which is a similar protocol, but they effectively solve different problems.

Anyway, the URL that lets you sign into OpenID enabled services is
https://www.google.com/accounts/o8/id
This URL is the same for all Google accounts; it redirects you to Google’s servers for you to confirm the logging in process. That’s it.

A good example

Stackoverflow.com is doing OpenID signing in right. I doesn’t ask you to fiddle with an OpenID URL but rather gives you nice and easy logos to click on – it fills in the URL for you. Well done!

Stackoverflow.com login page

At the moment this is limited to only English and German, but as soon as the last few kinks of theinternationalisation have been ironed out, I will try to add more languages.

In the meanwhile, if you find something that has been translated incorrectly or something that hasn’t been translated at all, make sure to let me know either in the comments to this post or by writing an email to lenniboy@gmail.com.

Terve!

Pekka L has provided a Finnish translation: http://lenni.info/edd/fi.

Thanks Pekka.

• compiled
• JavaDoc’d
• unit tested

These things don’t need to be declared and are automatically done by Maven. Maven’s great advantage over Ant is it’s ability to handle the dependencies of your project, ie. the old “Hunt the JAR” game is a thing of the past as Maven will simply download whatever libraries or frameworks you will need. Most of the time your build will run smoothly and Maven will spit out a nice JAR or WAR without problems.

The curious error message

However, if there are build errors they tend to be on the cryptic side. “The artifact has no valid ranges” is one of those. Basically it means that you do have a valid range, however you have defined two (or more) different version ranges of an artifact in a fixed way. Most likely you haven’t defined those dependencies in the same project but through a transitive dependency.

Let’s have an example. Your project my-app, depends on an artifact super-framework at version 1.0, and only 1.0, nothing else. my-app also depends on another of your apps called my-app2. my-app2 has a dependency on super-framework but only for versions 0.5 to 0.9. This means that you have incompatible version ranges and you need to resolve this. You will have to edit my-app or my-app2 and change their version ranges for super-framework.

This took me a little while to figure out myself since the error kinda suggests to look in the wrong place. The range is perfectly valid, it’s just that there is too many of them.

Debugging this message

That is a little tricky. You can try running Maven with the -X flag, which will show a running log of how the version is chosen. Also, sometimes the Maven plugin for Eclipse can give you some clues, but sometimes it is way off.

One word of advice though, it seems to matter in which order you include your dependencies in the the POM file. So, if you include a dependency on

super-framework [0.5,1.5)

it will fetch the latest available version, say 1.1.

If you then have a transitive dependency further down that includes

super-framework [0.5, 1.0)

Maven will generate this misleading error, since it will not select anything other than the 1.1 it already has, even though it could just select 0.9 without producing a version conflict. If you swap the order, weirdly, it works.

Last Saturday the disc finally arrived! It didn’t take long to upgrade the system from Leopard and the process was smooth and polished – almost zero user input required as we are used form Apple.

Now to the actual OS: Well, startup and shutdown is noticeably faster but to be honest I couldn’t see a massive speed up in the main system. To be fair, it was pretty speedy on Leopard already and I never had the feeling that it was sluggish; therefore it probably went  from pretty fast to very fast and maybe that difference isn’t so big.

Lets get to the improvements. These aren’t earth-shaking but many of them fall under the category “Oh, that’s nice”.

• Working CD/DVD burning support: This was a major gripe of mine on Leopard. Disc writing would often fail and Disk Utility was awful for burning – Leopard’s “burn folders” never worked either. If that wasn’t such a basic thing I would say “Well Done” to Apple but this should have been way better a long time ago.

Snow Leopard disc burning

• Expose is more useful. Instead of the old seemingly random positioning of the windows they now arrange themselves on a grid and the dock and the menu bar turn black which I like better. Also, if you click on an active dock icon and then hold you can see all the windows that the program has open at this point in time.
• Dock stacks are scrollable. Again this really isn’t a killer feature.
• Address Book can sync with GMail. I’m liking that.
• Quick Time looks nicer. I’m not quite sure what has happened under the hood there but I like the new interface. Just get yourself Perian and it is almost as good as VLC.
• Mail supports Exchange server. Even though I didn’t test this, as I use neither, this could come in handy. It also means that Exchange server is better supported out-of-the box on OS X than on Windows – go figure.

Apparently, there is all sorts of stuff happening with Grand Central and OpenCL but I rarely have an application that is heavy on either CPU or GPU so this doesn’t really matter to me but is nice to know. Almost all of my programs still worked fine under Snow Leopard; the only one where I had to use a beta version is Cyberduck.

There is one little gripe: I used to have a developer preview version of Safari 4 which allowed websites to be saved as a web application which then had it own dock icon (and presumably its own process). I assumed this feature was held back until Snow Leopard came out but I can’t seem to find it. Hmm.

Baseline

I like it particularly for the fact that it isn’t jam-packed with features that no-one needs but is a good solid exercise in improving the core of the system. I got this update for £10 and I think even £30 would be no-brainer for all Leopard users. I don’t think I would pay the full retail price (£129.00 for the box set with iLife) for it though.

LaTeX on the other hand, doesn’t seem to like those drop shadows as they contain transparency (also know as alpha channel) which after the conversion to PDF appears as ugly black borders. Fortunately there is an easy fix for this problem, which I found in a mailing list message.

You will need to have ImageMagick installed for this to work. ImageMagick’s convert command line tool allows you to convert the transparent part into proper colours rather than a grey layer with added transparency information (which is what throws the tex-to- PDF converter). Before you add those images to the tex file, convert them like this:

convert -background white -layers merge input.png output.png

From now on you will have to supply an email address if you want to submit measurements for a hub or rim, but please be assured that this data will be for my eyes only. I won’t spam you or won’t give your email address to anyone.