I have already been a Groovy user for a while, so didn’t really need to do go through its koans. Still happy to find out someone had made the effort of writing some koans for Groovy. There’s a few more, if you google them. Now, I’m busy working my way through the Scala Koans, which, truth be told, needs some work on its runner. That doesn’t get in the way of fun though, you can still find out in which order to solve the koans by reading the right source file.

Update: also, these Javascript Koans look interesting.

Kudos to the Ruby community for introducing this concept to programming universe.

Anticipating future requirements

Ah yes, the beauty of coming up with a software design that is ‘ready for the future’. “Implementing that one feature the client was talking about is going to be so easy thanks to my design!”. Guess what, you can’t predict what your client will want a month from now, let alone a year from now. The thing about the future is that it tends to pretends itself differently than you expected almost every time. And then you find yourself doing more refactoring than necessary because you need to remove parts of a system that are now dead weight. Plus, you made the initial implementation harder and more time-consuming then necessary. So just build what you know is needed now, and do that well. That will be difficult enough in most cases.

Being a push-over

How many times do I hear developers complaining about how management doesn’t give them any time to do the right thing. Well then make management listen to you. “But I don’t like to be involved with politics,” I hear you say. Well, wake up and smell the roses because politics is sure involving itself with you. Stand up for the quality of your codebase.

Elitism

Please, no more scoffing at front-end development. Java (excuse me, ‘Enterprise Java’) developers that feel superior to front-end guys, evolution is going to take care of you. The time were you could say “oh but I’m a back-end guy” and not bother to read up on HTML, CSS and Javascript are behind us. Rest assured, the younger generation of developers knows this and is more than happy to replace you at the coolest projects. You can have fun in back-end legacy land until you retire.

Believing the hype

A new year, a new buzzword. XML, SOA, RIA, cloud, there’s no end to them. Really, there is no need to run after these things all the time. In fact, if you have a memory that functions you will remember some buzzwords that by now are dead and buried. And how many of them are just about the pendulum of computing swinging (think fat server, thin client vs thin server vs fat client). Know your classics.

Mystification

Yes, we’re geeks and we write software. It’s so easy to feel intellectually superior to those clueless marketing and management guys, isn’t it? And we’ll throw in some tech-lingo for good measure if they’re being annoying. Most of the times, non-technical people are quite good at getting their message across. Us developers however, struggle with explaining what we do to others. Now who’s being dumb here?

Language fundamentalism

Ruby vs Java vs Python vs C# vs PHP vs Scala etc etc. So often the tone of conversations about languages and tools gets so heated. Come on guys it’s only programming. Can we please just stick to acknowledging the core strength of each language? That should help us making a calm and rational decision about what to use for a project, instead of flame baiting the other camp with yet another crappy benchmark.

Getting lost in a bubble of silence

How cool is it work on some issue,  just program the day away, uninterrupted by thoughts of the context or weight of the problem at hand. Us developers just love to spend a lot of time this way. Some of us do get a nagging feeling “hmm maybe I shouldn’t be spending so much time on this detail,” then to ignore it and just continue hacking.

Yes you counted right, there’s seven bad habits here. I got on a roll.

I got a Google Appengine account, had a look around for the right technology stack and got going. Here’s the result (in Dutch).

A bit about the technologies involved:

• I needed an easy way of hosting. Appengine provided that. Getting up and going was extremely easy with IntelliJ.
• I’m a Java guy, so I went for the Java version of Appengine. Lately though, I have been enjoying Groovy. Good thing that that will run just fine on Appengine.
• I looked at running Grails on Appengine first but decided that Gaelyk would be a better fit. Using Grails would be a bit like working against the grain of Appengine, which is a different beast.
• To display the chart, I used Google’s Visualization API. Sadly, it uses Flash under the hood. I might change the chart type soon.

Gaelyk was fun to work with, doing a simple thing like this really suits it well.

• Respectable Java developers have moved away from J2EE at least five years ago, and arguably longer ago than that.
• If your codebase is, in fact, really based on J2EE you’re not going to find anybody decent that wants to maintain it. Kill your codebase now and rewrite it, or suffer the cost of the huge technical debt involved. The longer you wait, the higher the cost.
• Recruiters: if you didn’t mean J2EE, but JEE5 or JEE6, or even ‘Java for companies’, then use those terms. ‘J2EE’ puts good developers off because it was such horrible pain to work with.

I think that one of the reasons that I was able to get the idea at all (let alone pursue it), was due to the fact that I was taking a voluntary break from contracts. I was lucky enough to have saved some cash so I wanted to spend time on some technologies that you don’t run into a lot in the enterprise Java world.

When I’m in the middle of a contract I am completely caught up in it and therefore don’t have time for other stuff, at least when it comes to my profession.

The idea I had wasn’t revolutionary, but something like it did not exist yet out there on the web and the audience for it ranged in the order of 15 million. What I wanted to do is create a social platform for people to communicate about a specific sport, let’s say mountain biking, to socialize it and to give the people that practice that sport insight into how they’re doing so that they might improve. Given the fact that the this specific sport is often more of a passion than just a casual hobby, I thought the site would have a chance of success. I still believe that.

I was lucky enough to be able to team up someone who is knowledgeable on both social media and the sport and soon enough we had come up with a pretty good list of features and I could start developing. Together we came up with requirements, I developed, he tested. We did about 45 incremental releases that way, got through all the boiler-plate functionality a social networking site needs and the UI was coming along nicely.

A couple of months passed, and I would spend at least 10 hours a day working on the site and things were looking good, not in the least thanks to Grails, which I recently blogged about too.

And then the big set-back came. A different website, well-established and catering to the same community, had also seen the light and had integrated a very beta-ish version of the same concept into their website, which already had a big audience. I was gutted.

It prompted me to step back and think about what I was doing. Here I was, on a huge, almost solo-effort to build something that in terms of complexity and labor required was best compared to FourSquare. Sure, the thought had crossed my mind: is this really feasible? But my enthusiasm and the feedback from others made me continue. And there was more: having worked with many other web-software professionals, I had access to people that were willing to help me out on areas that I couldn’t handle myself, such as graphic design.

The obvious question is: why didn’t I seek investment upfront? I felt that investment would be easier to get once the concept of the site could be demonstrated. It is usually kind of hard to convince people of your concept when it only exists on paper. Just as we got to the point in time where I could look for investment, the other website mentioned earlier launched their take on the concept. And with this kind of concept, being the first mover is critical.

I did contact the biggest competitor of that website. At first they seemed to be very interested but after a conference call they asked for was cancelled they didn’t show a great deal of interest. I think that this deal went south in part due to the fact that they were based half-way around the world, and for our initially scheduled presentation I did not fly over. Big mistake.

So now it’s late March and I’m abandoning the project. I loved working on it but when I add up all of the things mentioned above, I think it’s wiser to give up.

What we did complete:

• A well-defined commercial strategy
• All boiler-plate functionality for a social networking site implemented (follow, unfollow, sign up, find friends etc etc)
• Security precautions (think OWASP)
• A nice asynchronous way of dealing with the heavy lifting that makes the social network tick.
• A nice Ajaxified UI (thank you jQuery UI)
• All the central concepts of the sport covered by functionality, so that users would see real benefit compared to just using Facebook or Twitter
• Good test-coverage that inspired confidence in the quality of the implementation.

What we didn’t complete:

• The companion iPhone and Android apps. I was considering just doing a HTML 5 mobile version but that was going to run into problems (access to the camera API being the most notable). I was going to focus on developing these after putting the website online.
• Integrate a CMS to be able to easily update some pages with secondary content.

Next time:

• I hope to be a bit more lucky in terms of timing
• I’ll try harder to get more developers involved full-time. I like to think of myself as a pretty productive developer but the amount of work required here was obviously exceeding what one man could finish in a reasonable amount of time.
• When I demonstrate the product to a potential partner/investor I’ll insist on doing so face-to-face, no matter how far away they are.

All in all, I really enjoyed working on it and I  learned a lot. This was just my first attempt at a start-up, so I guess the second time around is likely to be more successful.

For me, being a Java developer, getting started with Grails was really easy. Here’s why:

• Grails builds upon usual suspects: Spring and Hibernate, each of which I have years of experience with
• The conventions used in its convention-over-configuration mechanism made complete sense to me
• Documentation is pretty good
• It has a lively and supportive user mailinglist
• You gotta love Groovy.
• GSP (the grails counterpart of JSP) just does everything right
• Spock is a great unit testing framework

I was developing in Grails with IntelliJ IDEA version 10, which has excellent support for Grails. Setting up a project is trivial.

A couple of things to be aware of / that I’ve learned:

• Grails pre-determines the Spring version that is in your project, and understandably so. With Grails 1.3.x it gets Spring artifacts from SpringSource’s EBR. This means that you have to be careful when including other artifacts that may refer to the regular maven-central style artifact names. Apparently this will change come Grails 1.4. You can deal with this problem by running ‘grails dependency-report’ and excluding artifacts in BuildConfig.groovy
• Grails controllers are request-scoped, unlike your familiar Spring MVC controllers
• There are a lot of plugins available for Grails, but they vary wildly in terms of quality. Do read the source.
• Grails comes with the Prototype Javascript library, but it is really easy to switch to jQuery. Apparently,  jQuery will be the default as of Grails 1.4
• If your application sends mail, the greenmail plugin is pretty nice. No more waiting for emails to arrive at development time.
• When adding plugins, be aware of which controllers / services / meta-methods it adds. Sometimes you don’t want them to be exposed.
• Pure unit tests run a bit slower than I would like, but on my 2009 Macbook Pro I can run a Spock unit test with about 10 test-cases within IntelliJ in about 5 seconds. That’s acceptable.
• The Spring Security plugin is great, but pick your means of securing resources carefully, as they are mutually exclusive.
• The Hudson/Jenkins Grails plugin is nice and does the job. It would be nice though if it didn’t mark a build that has one failing test as ‘failed’ but as ‘unstable’. But I believe this is caused by the grails command exiting with an error value when a test fails.
• Only in rare cases do you have to restart your local app while developing, so turn-around time is very small.
• Doing basic AJAX is really simple with Grails. Its GSP taglibs and JSON support help out a lot. Combined with the jQuery plugin life is easy.
• Modularize your app by turning parts of it into plugins. It really is quite easy.
• A great find was the fixtures-plugin and its accompanying build-test-data plugin. Writing integration tests for complex queries was never easier.

All in all, Grails allowed me to get productive very quickly. I did not spend time on setting up web.xml, configuring spring, configuring data sources etc etc. Instead, I could focus on the task at hand.

Given the fact that the Grails always offers you a way out if you need to do very specific stuff in Java, I think Grails is probably going to be my default weapon-of-choice in the time to come. People that think it isn’t enterprisy enough because it’s powered by a scripting language are misguided. Sure I had my annoyances with it, and maybe I’ll blog about those later on

The JSPX format is an xmlized (that is not a word, I know) version of JSP. Check out this question at stackoverflow if you would like to find out about JSPX.

Back to the issue at hand: Appengine precompiles all JSP’s at deploy time. The current version (1.3.4) of Appengine does not let the Jasper compiler kick in if no .jsp files are found in the webapp. However, if you add a dummy.jsp file to the webapp (say in WEB-INF), the Jasper compiler will actually be started and it will pick up .jspx files.

At Google I/O 2009, Ray Ryan held a talk titled ‘Best Practices For Architecting Your GWT App‘. In the talk, he layed down a design blueprint for real-world applications. One of the most important aspects he talked about was Model-View-Presenter (MVP). I have seen how developers have struggled organizing the code in their GWT project. Much of that struggle can be attributed to the fact that many of us Java developers don’t really have any component-based UI experience. Not many of us have worked with Swing, instead we’ve been spitting out JSP’s and writing Controllers. GWT requires a different approach and up until Ray’s talk, not much guidance existed around the subject.

After Ray’s talk, quite a few developers jumped at the opportunity to implement a framework that formalized MVP, the client-side EventBus and Dependency Injection using GIN. A couple of community projects appeared on Google Code:

• GWT-MVP
• GWT-Dispatch. A Command Pattern implementation

Those projects highlighted that a real need existed within the community to have some frameworks that help developers organize their code, much like Spring-MVC does on the serverside. With the announcement of GWT 2.1 M1 it seems that the core GWT team at Google have acknowledged that need. It packs an MVP framework, so from GWT 2.1 onwards the GWT-MVP will be obsolete (but their pioneering was very important!). If you’re interested in MVP, also read the article on the official GWT documentation site.

The final development I’d like to mention is the integration between SpringSource’s great tool Spring Roo and GWT. I have been using Roo for quite a while and the new GWT support it adds is very exciting. Have a look at these screencasts (especially the second one, further down the page) and see how quickly you can get started with a GWT application. The code generated by Roo builds upon the MVP pattern. I for one will be monitoring the progress on GWT 2.1 and Spring Roo 1.1 closely!

An example:

1. A team is put under some pressure, or at least feels like it is.
2. Code is written that is below standards and the team knows it.
3. As the team continues to add features, the burden of the suboptimal code written earlier becomes heavier.
4. The business people wonder why everything is buggy and development is at a low pace.
5. The team is frustrated and feels like it’s a victim of those clueless business people. “We weren’t given any time do better”, the team says.

Now it would make me popular with the programming crowd if I would argue that the business people should have known better and should have allowed them more time to write code of higher quality. And sure, they should be aware of these things. But often they’re not. or they forget about it.

What I want to say is something else. I think that developers should take responsibility for their code. That means that they should not allow business people to just downplay the importance of refactoring, or to postpone it. The team will just have to make them understand just how important it is. Tools like Sonar can help developers conveying that message to business people. And sure, that means playing your part in company politics, especially when you’re the team’s lead developer. But whether you like it or not, company politics are a fact of life. As a developer, you can either be a sitting duck or get into the game and defend the quality of your code base. You might even have to nag a bit, but in the end when you’ve done your refactoring, you will have done everybody involved a great service. That will be on more step in your company becoming the great software shop you’d love to work in.

It seems that by offering JPA and JDO, Google has attempted not to alienate developers too much. But the fact of the matter remains that the Appengine Datastore (some people call it ‘a huge HashMap’) is very different from an RDBMS and we as developers best accept that fact and get on with it.

A number of projects have been started that offer an alternative to using the datastore in your API: simpleds and Objectify being amongst the most notable. SimpleDS seems to be developed by a somebody who come from a JPA/Spring background and it has nice features such as such as declarative transaction management through Spring. With Objectify, there is no out-of-the-box way to do that. Then again, it’s probably not that hard to develop a transaction manager for Objectify.

On the other hand, the documentation for Objectify seems to be more complete and it has a much more active user group. It’s tough making choices on the bleeding edge I have made some progress with Objectify and it was quite easy to get started. The interface of the Objectify interface looks a bit complicated and you find your self newing Key<YourEntity> objects all over the place. But, it works like a charm and is easy to write integration tests for.

Therefore, I will be evaluating both. Could both project join forces? That would probably benefit the community at large. Both projects are very much in early stages, even though Objectify has reached version 2.1 by now

Update: I found an interview with the 3 lead developers of Twig, Objectify and SimpleDS. Read it here.