Tuesday, 27 November 2007

I haven't blogged for a short while, so I thougt I better just make a quick note about a few of the things I've been up to.

OSGi ant tools

osgijc is an ant task that replaces javac for use when compiling osgi bundles created with Eclipse. This avoids having to use the PDE and makes integration with a continous integration environmet much simpler.

I should point out that there is already a tool that can do a lot more than this called bnd, but I found it complicated to use and it seemed to clash with the way I like to work in Eclipse. I also felt that it was uncessary to repeat all the information stored in the MANIFEST.MF and build.properties file in a seperate file just to be rebuilt elsewhere, but this is because of the way that you work with OSGi projects in Eclipse. bnd is no doubt highly appropriate if you don't use Eclipse to create your plugins and don't have a MANIFEST.MF throughout your development cycle.

Anyway, a minor change, but as of today osgijc now reads the source folders and destination folder from the build.properties file in the project. In the past these needed to be set in the ant task.

Also note that there is also osgijc's sister tool, osgibb, which will bundle Eclipse OSGi projects in to bundle jars.

By the way, neither tool has been tested with plugins that contribute to the Eclipse UI, but I can't see a reason why that wouldn't work either.

In summary though, I would say use osgijc and osgibb if you're wanting to use ant and your projects are Eclipse plugin projects, otherwise, use bnd.

Rapid Rich Internet Application Development

The main thing I've been up to recently, outside of regular working ours, is getting up to speed with Flex and LiveCycle Data Services.

I have to say, Flex combined with LiveCycle Data Services using db4o is absolutely the fastest way I've ever created an internet application with full data support in the back end. Flex itself makes UI development a doddle. LiveCycle Data Services make accessing data in the back end as simple as called methods on a POJO (real POJOs), then combine this with db4o so that you don't have worry about RDBMS issues and you're really flying in no time.

Flex + LCDS + db4o = truly rapid development

I finish my current employment on Thursday, with Friday left for me to sort out some stuff before I start my new role on Monday. In my new employment I will be using Flex extensively. I am hoping I will also be able to make use of db4o, but since I won't be working in a green-field environment and am most likely to be working with existing RDBMS I think this is unlikely.

I'm far from an expert with Flex at the moment, but I have done enough work to be up to speed with most of the UI side of things. I've been writing a little game to try and use as many of the different aspects as possible. If I get it finished maybe I'll put it online, but I suspect I'll probably just leave it once I start working on something real.

Things I am still unsure about are how to secure access to the backend through LiveCycle Data Services. It is possible for Flex to easily call through to WebServices as well, which I have secure examples of. Anyway, I'm sure I'll pick this up quickly enough on the job and with the training I'll be receiving. Always good to have a head-start though!

Tuesday, 13 November 2007

hibernate hell

I'm afraid I don't like "Hibernate". Hibernate, when used incorrectly, can add a massive overhead to your project in terms of runtime efficiency and maintainability.

Imagine the scenario where the architects of an application decide to create the database schema first. This isn't necessarily a bad thing until you add Hibernate in to the equation. EJB3, cool! So let's generate our objects from our database schema... bad mistake.

Hibernate is in an O/R mapping tool. That means it allows developers to map objects to a relational database schema. By generating objects based on a database schema what you are actually doing is creating Relational Database Objects. What I mean is, rather than creating a valid object model which works well, you are simply creating a bad object model that reflects your database schema. This might sound great and handy BUT... what you end up with won't be an object model that is very useable. Hibernate will add annotations to your objects and will assume all kinds of fetching strategies (it SHOULD assume eager fetching as per the JPA spec, but I'm not sure what it does) and may also add associations between classes that are uncessary or undesireable. For instance, when you add new use cases are the fetching strategies still appropriate? Possibly not! So, if you take this approach you need to go through the generated model with a fine tooth comb and check that it supports your all your currently known use cases and try best you can to make sure it can support your unknown future use cases (a very difficult task!).

Personally, I don't like the "database up" design approach. It implies a waterfall approach from the outset as usually once the database schema has been settled on it is very hard to change it. A better approach is to only think in terms of your object model and do not worry about your database schema until you really need to. At this point I can see Hibernate being more useful in that it will be able to generate your schema for you. However, I wouldn't recommend this either as it will most likely design you a schema that is very rigid to your current object model. Not only will you be stuck with your schema, but your object model won't be very flexible either.

I prefer to work with my object model and leave the RDBMS until the last possible moment. Since I do a lot of modular work, my database schema design ends up being very modular as well. This doesn't suit everyone so a suggestion would be to take the object model in small chunks and design the schema at agreed stages during the project lifecycle. You will naturally group objects together in packages where cohesion between classes is high or the classes fall in to a natural domain. Why should your database schema be any different? A lot of the time though, this is hard if not impossible because of referential integrity - and rightly so! But if you want the same flexibility with your RDBMS schema as you do with your objects grouped in to packages (low coupling) you end up with a lot of join tables. I don't have a problem with this, but tools like Hibernate cannot work that out for you.

Another option, if you really must use a RDMBS is to work with an ODBMS until later on in to your project when your object model has settled down and the risk of change in designing a database schema has been reduced. If you were to use something like DB4O for instance, it will encourage you to respect your object model. With the correct, sensible level, of abstraction it is not hard to create a layer to replace DB4O with your data access code for your RDBMS schema.
(Further more, consider using stored procedures in order to further remove the dependancy on your database schema.)

So you may be thinking that it isn't fair for me to dislike Hibernate, but the reason I do is mainly because it allows developers/architects to take certain shortcuts which add complexity and a certain amount of rigidity to a project. In turn this makes it difficult to be agile, encouraging a waterfall approach and makes it really hard to change your project's code at a later date, even if you just want to add something new.

It doesn't have to be that way, but given the availabilty of the tools, I suspect most developers (under project pressures) will take the easy way out just to satisfy their manager's continual (and understandable) desire for reducing timescales, but it is a false economy.

If you're about to embark on something like this, either generating objects based on a database schema or generating the schema based on objects consider NOT using the tools. Continue to use Hibernate, yes, but don't take the shortcuts as in the end they'll only add overhead rather than saving time and money.

Your turn... have you had a good experience with Hibernate generation tools? Did you have to spend a long time tweaking the objects/schema that was generated? Did you use Hibernate but manually annotate the objects/create mapping files? What approach worked best for you? What nightmares have you had?

Sunday, 11 November 2007

extending a line

This post is more of a math post really. I have to admit, my maths is not that great! I even bought the book "Mathmatics and Physics for Programmers" to help me out. When I used to work with Derek I had it easy with the maths really. The team had several good math brains with Matthew "Bayesian" Bayes probably topping the list of reputable mathematicians in the group. I was given the math on a plate and just had to code it up, most of the time. When I moved on from there found very little need for math, from GIS programming to server side Java my math usage went from daily to less than monthly at a guess.

So I was coding something on a little side project of mine and realised I had a need to "extend a line". Usually I would email my old colleague and friend David Waters, but decided to try and work this one out for myself. I had a flick through my math book I mentioned above and didn't find a direct solution to my problem. However, I did have a good read through the section on Vectors.

Given I had two points and a distance I needed to extend one of those points by, I realised that I needed the following components:
  • a vector (subtract point 1 from point 2)
  • the magnitude of the vector (i.e. the distance between two points, either my starting points or the origin and the vector)
Once I had the magnitude, I worked out what the difference was between the starting line length and the existing line length and worked out what percentage this was of the original line length. This gave me a value which I used to multiply the vector with. Once I had done that I simply added point 1 back on to my newly scaled up vector in order to give me my new end point.

The code looks like this:

* @param p1
* the start of the line
* @param p2
* the end of the line to extend
* @param distance
* how far to extend the line by
* @return the line object
private Line2D createAndExtendLine(Point2D p1, Point2D p2, int distance) {

double length = p1.distance(p2);

Point2D vec = new Point2D.Double(p2.getX() - p1.getX(), p2.getY()
- p1.getY());

double multiplier = (length + distance) / length;

Point2D p3 = new Point2D.Double((vec.getX() * multiplier) + p1.getX(),
(vec.getY() * multiplier) + p1.getY());

return new Line2D.Double(p1, p3);
It appears to work in my test cases, so I'm happy with it, but of course I'd love to hear from the math wizards if it could be better or simpler!

Tuesday, 6 November 2007

USB Mobile Internet

There seems to be a few mobile internet deals popping up these days.

Vodafone's "best" deal appears to be £49 for the modem (+vat) then £25 per month (+vat) with a fair usage cap of 3gb on an 18 month contract at up to 7.2mbs (faster than i can get at home). shame because i like vodafone, but that's just too expensive.

Tmobile has a similar deal, but with free modem, though you can get 10gb data allowance for around £39, and their prices include vat, unlike vodafone. However, I've never liked Tmobile, though can't put a finger on why.

The best deal so far appears to be "3", who's prices include vat and appear to be more transparent. 7gb per month including modem for £25 inc vat. I need a demo, to see if it's as easy as the Vodafone modem (literally plug it in to your laptop and off you go) and I need some assurance that if it turns out to be rubbish I can cancel my contract. I don't live in London, so coverage isn't likely to be as good.

I really want this as I use my laptop a lot when I'm on the move. Certainly I spend an hour or more a day on the train so having internet would be really helpful. However, I'm starting a new job in december and think they will be giving me a new mobile phone. So I'll either be transfering my new number (and they pay the bill) or just dumping my existing contract all together. Either way it'll free up some money for one of these gadgets, which means I can work and play on the move!

For now, I'll leave it and see what happens. Prices may even come down in a month and the deals may change now that 2 big vendors are online with it. Come on Orange, where are you?

Sunday, 4 November 2007

installing flex builder 3

My next "big thing" is Flex. I'll be starting a new job in December and will be working with this great bit of Adobe technology. I decided to get a head start and get it installed. Took me a while, but eventually I worked it out thanks to the above link.

So, to cut a long story short;
  • get the latest version of Eclipse 3 (I'm using
  • get the latest version of Flex 3 Builder beta Plugin (I'm using Flex 3 Builder public beta 2)
  • install Eclipse as usual
  • run the Flex installer
  • use the shortcut under Programs -> Adobe to start Eclipse
If you can run the New Flex Project wizard, everything should be ready to rock. I was using Eclipse 3.0 and it just wasn't happening, but once I got the latest software it was fine.

Well, that's as far as I've got so far, I'm sure there'll be plenty more flexing going here in the future.