"The web" has been replaced

I'm working on my own Rails application during evenings at the moment just wanted to point out something I already had noticed a few months ago: most of the old technologies that made up "the web" a while ago have now been isolated through a new layer of "languages" (I hesitate to call html and css languages).

JavaScript can now be written using coffeescript. CSS can be written using sass/scss/less. HTML can be written using haml. Now there might have already been replacement technologies for all these areas a long time (don't know too much about alternative browser languages), but now it's really feeling like these technologies are good enough to be used in real projects.

My Rails application is going to attempt to use all of them. While I think haml is nice and clean and it's great to not have to type all those annoying angular braces, I'm even more excited about coffeescript and scss. As most people who take the time to learn JavaScript notice, it actually has some really good parts but it's bogged down by some pretty last-millennium syntax and some really awkward design and implementation mistakes. On the other hand, I think coffeescript has the nicest syntax of all languages at the moment.

I haven't really used the CSS replacements that much yet. Layout and design aren't my strongest areas. However in nearly every web application I've worked on so far, the CSS has been very messy. I'm hoping that scss might help alleviate this problem.

Why PHP sucks #1

Welcome to my series of posts of why PHP is the worst language I've ever had to work with. Today's topic is error handling. Or perhaps PHP's lack of it. One of PHP's philosophies seems to be that the programmer should not be troubled by any nasty errors. It's better to attempt to do something even if that is wrong. Failing fast with a clean error message and a stack trace is not one of PHP's virtues.

PHP seems to (I'm just guessing here) have only had errors (with different codes for warnings, notices etc.) before. Now it also has exceptions. This is pretty annoying because you end up having to write your error logging code. This involves setting up your own custom error handler which rethrows the errors as exceptions. Then you can add your own custom exception handler which can obtain a stacktrace from the exception and print it out inside <pre> tags so that you can make some sense of it.

Then you figure out that PHP treats "fatal errors" differently. It bypasses your error_handler and just shuts down your application instead. Then you figure out that you can register a shutdown function and try to output a stacktrace manually from there. Unfortunately by the time this function is called PHP has already torn down most of the stuff you were using and the only thing in your stacktrace is gonna be your own shutdown function.

So you end up installing the xdebug extension and by enabling it you can finally get some output when your program. Except it's a big mess of lines where you end up just having to go through all the mentioned lines to see if you can figure out what's causing your problems. Then after a while you notice that you can echo a single opening <pre> tag at the beginning of your script while debugging your errors and suddenly all the output from xdebug is quite readable. But the fact that you have to go through all of this crap shows why PHP sucks.

Programming books I read in 2010

I read quite a few programming-related books in 2010. Here are the ones I can remember:

Tehokas Java EE-sovellustuotanto

Perhaps the most important book I read all year. Helped me in getting my current job. Taught me the basics of Maven, Hibernate, Wicket, Spring and so on. All of which were needed in the first project I was working in.

Javascript: the Good Parts

Very nice book. I read this for the Javascript study group we've started at my workplace. Recommended to read more than once if you really want to learn Javascript.

Effective Java

Very good Java book.

Refactoring to Patterns

I just skimmed through the descriptions of the patterns and skipped most of the longwinded refactoring instructions. If I remember correctly the smaller refactorings of Martin Fowler's were more immediately useful.

Patterns of Enterprise Application Architecture

While the content of this book was different from what I expected based on the "enterprise application" of the title, it was still a very good book. It taught me more about how Hibernate works. And I've referred to this book a few times when refactoring a project at work.

The Pragmatic Programmer

I had already read this one before. I just read through it again because it was such a long time since I last read it and because it's such a short and easy read.

Facts and Fallacies of Software Engineering

Sort of interesting. The abstraction level was quite high. I was aware of many of the ideas in the book already.

Pro Git

Online book about git. In 2010 I greatly improved my understanding of Git. This book was one of the best sources for learning about it.

CSS Mastery: Advanced Web Standards Solutions

HTML and CSS is one of the biggest pain points of making web applications. One of the things I remember the best from this book was how often the chapters had to have some extra workaround crap instructions for IE and what a pain in the ass it is to make rounded corners.

Rails Recipes

This one was written for Rails 1, so it was a bit out of date. At the moment, I can't really think of any useful recipes I learned from this.

Git version control best practices

Keep commits small, they cost nearly nothing to make in git

• Allows you to easily revert a faulty commit without reverting working code at the same time


• You can easily get an idea of what happened to the project by simply reading the commit message titles in a history browser


• No more of those "committed some stuff" commits

Code new features in separate branches, they cost nearly nothing to make in git

• Allows you to easily return to the latest working state in the master branch when your client wants you to fix a bug discovered on your project's deployment day


• You can just leave your branch to "collect dust on the shelf", if it turns out that the feature was too time-costly to implement, and continue working on it at any point later

• Even the "minimal" tasks usually require more commits than you originally thought

Use no-fastforward when merging

• Because the merged branch groups commits its easier to see which commits belong to the same feature when observing the source history


• All the commits that make up the feature can be reverted in one step if the branch was found to be faulty

Use add -p to split up modifications into separate commits

• Related to keeping commits small

Corollary to "Code new features in separate branches"

• Don't develop directly in the master branch

Use a remote branch if you want to collaborate with other developers on a feature

• If a feature is too big for you to tackle alone, you should push it to your "main repository". The other developers can then pull it and contribute to it and when the large feature is done it can be merged into the master branch

Getting used to Java's Date and Calendar classes

Today I managed to complete the createBooking method of my BookingController. At least it runs without any errors. But the page that shows the week's bookings does not reflect the added booking. I spent quite a lot of time debugging my Calendar-related code. For a while I forgot that its MONTH field's index is zero-based, which caused me a lot of confusion. I was again tempted to start using Joda Time but I would like to refrain from adding too many dependencies. I would also have needed to add joda-time-hibernate and find/create property editors for setting up the Joda Time objects. Sure, this might have been something that would have taken like 15 minutes and worked perfectly, but it could also have led to unwanted trouble.

Anyway, when I was trying to see how far my BookingController was to working, I was doing some really painful manual testing. First I restarted Jetty, then I refreshed my main page, then I had to create a new user, then I went back to the main page, then I clicked the booking time I wanted, then I clicked submit on the form and then finally I would see an exception or error. Not very agile at all. The easiest way to start looking at what's wrong would be to run a separate hsqldb process which I could connect a DB client to and see if my requests have made any changes to the DB. But a better way would be to create a test case that calls my controller instead and then verifies that the expected changes have happened to the database. It would be even better to extract some stuff from my controller so I can test the url routing and form parsing separate from the database-related activities.

Sorting out how to use Spring Security again

It had been a while since I read about Spring Security. Now that I was trying to create a new booking I had to retrieve the currently logged in user to be able to add the new booking to that user's bookings. So I thought I'd just slap a <global-method-security secured-annotation="enabled" /> in my application-security.xml and then add a @Secured("ROLE_USER") on my method that was mapped to ("/") and Spring should pop up a login form for me when accessing that URL. But unfortunately it didn't work that easily. The page showed up just like before, with no login form in sight. So I went back to reading the Spring Security manual and looking for some posts on Spring's forums and after a while I noticed that other people had solved similar problems by putting the global-method-security element in the same xml file as the one where they set up their Controller beans. Since I use the component-scan element to automatically instantiate my @Controller-annotated classes in my servletname-servlet.xml file, I thought I'd just move the global-method-security element to that file. At first I got a long spew of exceptions and call traces, but that was just related to some incorrectly configured xml namespaces. When I sorted that out Spring Security finally worked.

The exercise also straightened out one misconception I had about spring. I thought the DispatcherServlet's servletname-servlet.xml file created a new application context that was separate from the WebApplicationContext which Spring's context loader sets up. But then I found this in the Spring manual "In the web MVC framework, each DispatcherServlet has its own WebApplicationContext, which inherits all the beans already defined in the root WebApplicationContext." However I still don't understand why the DispatcherServlet context didn't inherit the global-method-security element from my WebApplicationContext which contained my security beans.

Registering custom property editors with Spring MVC

Recently I've been able to concentrate much more on more normal coding tasks rather than just figuring out how to configure my application. I got to the point where I wanted to receive data entered and use that to automatically fill in property values for a business object. Fortunately Spring does have support for this. You just add a parameter of the type of your desired object and Spring will setup the properties based on their names from the encoded form values.

Spring has built-in support for conversion from Strings to a large variety of types. But if your business objects has a property of an unsupported type you need to register your own custom property editor that converts a String to that unsupported type. It took me a few tries to get it right but I seem to have gotten my custom editor set up properly now.

The mistakes I made were the following:

First I was trying to set up a CustomEditorConfigurer bean in my application context and use its customEditors property to map my class to an editor. Then I noticed that the customEditors property was deprecated in Spring 3. So I changed my setup to use a PropertyEditorRegistrar instead to register my custom property editor. This still didn't work. Then I figured out that if you just add these as beans in the application context they are probably only available for converting Strings inside that application context. If you want your property editors to be available for binding web requests to objects you need to use Spring's Controller's initBinder method to register your editor with a binder. And if you are using annotation-based controller you additionally need to use the @InitBinder annotation on that method.