Right then, back to Apache for a bit until I can find time to discover what on earth is wrong with my fastcgi install! Hopefully everything works now!
Java makes me passionate
I really like Java, it’s a fundamentally great language. Verbose at times, but great.
However, web application development in Java is painful. Additionally, the compilation and deployment of Java webapps completely suck. I mean, they’re terrible.
I dread to think how many frameworks exist in Java to ease web app development – each one claiming it’s the best and will solve all your woes, yet none come anywhere close to the ease of development in Rails, Django, or any of the PHP frameworks.
I remember being introduced to JSF at ApacheCon Europe 2006. I came back declaring that we would never use JSF for our internally-developed applications. When there was masses of hype, and everyone was claiming JSF was amazing, I got a few questions in the office.
Two years on and there’s finally some acceptance that JSF 1.0 was horrible for developing web applications, with some defensively claiming that JSF 2.0 will solve all the problems. Right, because that always works.
See the recent discussion:
Anyway this means I try and keep a close eye on things like JRuby and Grails but we’ve been pretty reluctant to use them at work because we tend to have large monolithic applications which require maintenance by different people over time which means code homogenisation is good.
To this end, our last couple of projects have been in Struts2+Spring+JPA+Hibernate. This is a nice combination, with a number of well-understood components working well together, especially since we’ve used the Zero Configuration plugin which allows us to drop tens of lines of XML in favour of a few lines of annotations. The Zero Configuration stuff is as buggy as hell and there’s no concrete date for Struts 2.1.2 where it should be fixed, but that’s by-the-by. For me, the fact that we haven’t had to be editing XML almost makes it worth it 😉 Also, Struts2 is highly testable which fits in nicely with our existing testing process.
But when you have a framework you’re (mostly) happy with for development, it highlights the other pain points you may have. For us, this was definitely the deploy/test cycle. We were already using TDD in the compile cycle so there’s a level of confidence about the backend code – tests always run after a successful compile, but when you’re amending the web interface either for small cosmetic changes or for larger changes of data representation there’s a long recompile, redploy, retest cycle that drives me insane. Obviously there are ways around it if you’re using something like Eclipse and have a web application in the structure it needs but we tend to have a number of files which are built at compile-time by Ant. Also, I don’t like being tied to an IDE for tooling purposes – I’m very happy with my current editor thank you very much. The only real missed opportunity was AppFuse – we remembered about it too late; any other Struts2 projects will probably start with it though.
All of this is why I was pleased to see Play! . It’s a just-in-time compilation framework where the controllers and model are pure Java and the view is Groovy; excellent!
This means that we can reduce the time taken to learn (we only need to learn one component – the view – plus config) whilst leaving all the business logic in a state maintainable by anyone in the team. It serves up locally through Apache Mina whilst also being deployable to a more conventional container like Tomcat or JBoss. Changes to both business logic and template are instant, and you can still test it to your heart’s content !
Unfortunately the latest stable version (1.0-stable3 at writing) doesn’t contain critical features like, um, if..else in the template language. Everything seems to be in the nightly, but having been burned with the Zero Configuration Struts plugin (which had the notice “This is experimental. Feedback is appreciated!”) I wouldn’t like to commit any real effort to writing an application in it. As soon as they have that core stuff nailed down though – I’m there.
Mai blog! It is back!
So, I finally finished the move from one host to another. It should not have taken as long as it did but after a frustrating night with the nginx config I spent a few days unwinding and catching up with the BBC’s new light entertainment series for Saturday nights, Merlin by watching it on iPlayer. My god I love iPlayer. It’s amazing. Even though I already have a PVR which the wife and I use heavily, iPlayer has still changed how we think about and watch TV. Awesome.
In the process of moving server I also moved from my blog being served from Apache+mod_php to Nginx+fastcgi (in particular I followed these instructions: Perfect Setup: Ubuntu Hardy+Nginx+MySQL5+PHP5+Wordress). I learnt a few things, although I’m sure most lessons will become apparent over the coming weeks. 😉
Firstly, nginx is amazing. In-place binary upgrades; simpler (to me) config files; faster; smaller; less memory overheard. If memory is no object to you, then you’re probably safe staying with Apache2, otherwise I’d recommend the switch.
fastcgi is less good, taking more memory than I’d like, although it’s hard to do an apples-to-apples comparison because of course Apache2 masks the PHP usage. This may also be throwing off the nginx vs. Apache2 comparisons between my servers but only by a small amount I hope.
Another reason I’ve taken to nginx is that the documentation seems to have made a leap that Apache2’s never seems to have managed. That is to say, it is a user-friendly wiki with sections for both user-contributed recipes as well as a complete config reference. Apache’s documentation has always been a source of pain to me, and it’s almost always guaranteed that the answer you’re looking for is on someone’s blog or in a mailing list somewhere rather than closer to the main docs and having some vague authority of being halfway accurate.
Of course, this may just be because Apache2 is now a venerable beast (or at least the docs that also apply to Apache are), but it makes a big difference.
Anyway, I look forward to a world of excitement with my new nginx setup. I have yet to set up proper logging (like filtering 404s and logrotate for specific site logs) and I have a mass of images and videos still to bring over from my old site, plus wordpress maintenance like theme-munging and plugin installation, and at some point it might be nice to actually have a home page…