Wildfalcon Relaunched

My website – with its new design, is now online.

I’ve been meaning to do something about the design of my website for ages. Finally I have. I was being held back by the way I run several different things I had on the site: My blog, my research history, my photos and a few other small things. Each of which was effectively written as its own independent little mini website, with a visual design that spanned all of them. Changing the design would have meant updating all the different sites with the same design. To put it another way, I had taken out a large technical debt on the site by having all the things written and managed separately.

While this has been going on, WordPress, which is the blogging software I use, has slowly been getting better, and better – more able to handle all the different things I want to do. So this week I bit the bullet, and transferred the most important parts of the web site – the bio and research publications into WordPress. I then spent a bit of time finding and modifying a theme for WordPress that I liked, and the result is now live, though I need to find a higher resolution copy of the banner image. Finally I have paid off the technical debt on my website. I can now modify the design and add features much much easier.

I still haven’t transferred the photos, though my analytics tell me that not many people are looking at those at the moment. I’m far from convinced I can find a way to integrate a photo gallery nicely with WordPress, but to be honest, I haven’t yet seen any photo based site or web service that meets all my requirements, so I’m probably asking too much there.

As for what next, well I am enjoying writing down random ideas, but I feel that I am covering a few too many ideas, and not concentrating enough on what really interests me, which is how the various, apparently unconnected ideas can be interrelated. So I’m going to try and concentrate a bit more on that. Though who knows, I may well need to put up a few more ideas before I can start to show the similarities between them.

By |June 29th, 2007|General|0 Comments

Stuff your Java model into your Rails project

The upcoming, and now recent, release of JRuby 1.0, along with some conversations with various friends has left me thinking a lot recently about how to integrate a Java project with a Ruby (on Rails) project. If you have an existing domain model written in Java then the reasons you might want to do this become obvious. Rails is designed using the MVC architecture, and if you can get it talking to your java domain model, then the M is already written for, you just have to write the views and controllers. Views especially can be painful in Java.

The standard answer for integartion between languages is currently web services: Write a simple XML wrapper round the Java domain objects allowing methods to be called on them, then use that API from within your Rails models. It doesn’t really matter if you use SOAP, REST or your own “standard” (although REST lends itself nicely to having a toXML() and a setXML() method on your java classes and using ActiveResource to GET and SET instances).

However, XML has never been a major contender for speed, and the chances are that your API isn’t designed to minimize the number of calls you make. So you have to pay that overhead more often than you need to. Of course you could add a remote facade, but now things are maybe starting to get more complex than you need…

JRuby provides a much more integrated way of solving the problem. It works like this: JRuby lets you import Java classes into your Rails code. Your controllers do not need to know (or care) that they are not Rails models. They can just find a new User instance, set the password on it, and move on to the next one.

Of course, I’m not suggesting that it’s that simple. Rails expects the models to be ActiveRecord instances. You are likely to suffer from code expecting to find an ActiveRecord method, like User.find and it not being there. I imagine the solution to this would be a library that loads all of your Java classes, and then changes them (as Ruby can do that) to add methods normaly provided by ActiveRecord. You can add the validation methods, then you can add the persistence methods like save, and find. How you do this is going to be dependent on how your Java persistence is done (ok, I’m assuming your Java code has a persistence model – I probably should have mentioned that earlier). If you have used the DAO pattern, the find method could instance a DAO object, load an instance though it, and return that. If you don’t use DAOs, then you map the methods to whatever you do use.

Finally you need to wrap all your code up into a library that runs when rails starts, automatically loads all your java classes, and decorates them. Hey presto, your old legacy Java domain model has a new lease of life as a trendy Rails application. If anyone has the time to write this library, let me know – I would love to have a play with it.

Unlike the rest of the Rails system, this integration won’t be solved by convention over configuration. Potentially it could be, but I think there are just too many different designs; different persistence models and different ways of locating your domain model out there…

By |June 10th, 2007|General|2 Comments