A couple of years ago, I got the ‘specification-by-example’ bug. I was playing with this new project called Cucumber, and was really enjoying the idea of specifying examples in an English-like syntax that testers and BAs could supposedly read. (I say supposedly, because it never really took on at my previous place-of-employment. Which was a shame). Nonetheless, I enjoyed it, and advocated it when and where I could. Heck, if nothing else, it was an excuse to write support code in Ruby as a break from the Java stuff.
There are three basic approaches to writing software that I know of. The first is always strive for technical excellence. This is great if you can do it – I’ve never worked in a place where technical excellence was always priority #1 with no compromise. If that’s you, then you probably don’t need to read this.
The second way is throw code around and hope it works – this is far too common. You look at the problem in front of you, and you grab a solution that’s good enough for now, doesn’t blow the budget (time and money) too badly, and leave the mess to be cleaned up (or worked around) later. Industry wide, this is the norm – a consequence of always focusing on the short term.
The third is a pragmatic compromise – try to make it as good as possible, while recognising that parts of the system will be, well, shit. That’s what I want to talk about here.
Very handy way of creating an OSGI bundle out of an otherwise normal Maven project.
Having converted the customer-facing pages of Wotif.com from a Freemarker/WebWork/EJB stack to a Grails/Spring3 stack earlier this year, I’m now officially a huge Grails fan. In setting up a new dev box, I wanted to install it – but who wants to install a download, huh? I wanted to build it from source (you can tell I’m a former Gentoo user!). Here’s what I did.
I love Selenium. It’s a great tool, that does a damn fine job. But one thing I’ve been wanting to do for a while is to get it to use a different DNS server to the box it’s running on.
Here’s how you do it:
java -Dsun.net.spi.nameservice.provider.1=dns,sun -Dsun.net.spi.nameservice.nameservers= -jar selenium-server.jar
(Caveat: may not work on non-Sun JVMs. Does work on OSX, though…)
Some months ago, I wrote about how the Maven Eclipse Plugin 2.7 release didn’t fix a bug introduced in 2.6
Well, neither does the newly released 2.8 version.
Guys, I know you didn’t hear me earlier, but for pity’s sake – DO NOT RELEASE SOFTWARE while you still have critical bugs open. If you don’t want to fix the bugs, edit the issue so it’s no longer bloody marked as critical.
I’m going to be spending some time over the next couple of weeks learning about OSGi – there is an application at work that we want to try and make more modular. In particular, we’d like to be able to share the back tier with more front end clients. The more conventional modularisation techniques, such as EJBs, have been tried and didn’t work fairly well. Simply creating more deployments is prohibitive, due to hardward And before someone asks “why not just stick a web service on it and share that way” – some of the front end clients will be those web services. To cut a long story short, one of the options we want to check out is OSGi.
The only problem is that there isn’t much in the way written up on the web about writing OSGi components – at least not without invoking magic tools (e.g. Maven plugins) that don’t work on any version of any tool developed six months later. Which is odd, because OSGi, as a spec, doesn’t look that hard to write too. So, I thought I’d write up a series describing the initial investigative spikes, starting as close to the metal as possible and working up.
In two words: pretty neat.