Category Archives: Java

Java, Ruby, Web Applications, Work

Working with Rails

I have recently struggled to try and get a prototype web application done with Ruby on Rails. It has been a really great experience and like all such experiences consists of both good and bad moments. Things that are particularly striking coming from a Java Web environment:

  • Integrated console
  • No recompile/build/deploy cycle
  • No mix and match components
  • No real programming language skill required.

It is also remarkable how quickly people revert to the level of thought, planning and execution that you might use for a shell script. Even I have found myself getting caught up in “playing” with the app interactively rather than being focussed on creating behaviour and functionality in a structured way.

Elaborating on these points; in Java web development the first issue is usually building up your component stack. Some people just choose Spring  but those people are idjits! If you are working purely in a web tier without any need for any backend interaction then it is probably a good bet but generally you want to put some thought into how you are going to assemble your various stacks. You tend to have to choose your MVC web framework, your persistence framework and your service framework (if appropriate). You often have to give some thought to your caching and messaging frameworks if they are relevant.

With Rails you just use the appropriate Active Module or Rails built-in features. If there is something that is going to ease some pain for you then it is going be operating as a plugin. That’s it, no framework holy war. It also means that there are a lot of applications that are just not going to be suitable for a Rails application as all those Java components have various strengths for different environments. I certainly wouldn’t want to tackle a legacy database with ActiveRecord for example. Not that it couldn’t be done but I wouldn’t want to do it.

The zero-turnaround is impressive after the build-deploy-check cycle. It was a wow factor last year when I saw the Phobos framework being demonstrated by Sun and its not lost any of its shine. By separating its deployment environments so ruthlessly Rails is able to deliver a really positive developer experience.

The interactive console takes a bit of getting used to in terms of faking browser requests but once you get used to doing so it is another tool that you wonder how you’ve managed without for so long. It’s much more intuitive to use than setting up a remote Java debugging instance (although admittedly you do similar tasks in both). It allows you to scratch those itchy “why?” questions.

And finally that lack of programming skill? A bit controversial perhaps? Well I feel that in recent weeks what I have been learning is how to manipulate Rails. The fact that it is implemented on Ruby may allow a lot of features to be implemented in the way they that they are but you are very rarely called upon to show Ruby madskillz. Instead the majority of the time you are simply plugging little customisations into the Rails framework. It is called Rails for a reason after all, when you are on them you are amazingly productive but if you can’t package your problem into a Rails solution then you are out of luck, you’re going to have to develop your own solution and that is going to be hard work. I have been trying to develop my Ruby skills (that is a whole other story) but the truth is you can bang out something that is acceptable with very little Ruby knowledge. You can go a lot of the way purely by mastering Ruby’s hash syntax.

So have I been converted? Well for all its problems I do have a hankering to get back to my great big Java applications with their holy wars and heavyweight processing. After all being on the Rails is fine for getting things done quickly but it can feel claustrophobic. I am also really glad that after getting distracted by the whole JSF controversy the challenge Rails presents to the status quo of web development means that a lot of the Java frameworks are starting to respond to the real problems faced in web development and ensuring that the easy stuff should be easy.

Standard
Java, Software

Java IDEs support Subversion

At last! A genuine point of differentiation between NetBeans and Eclipse. NetBeans has long had SVN support but to be honest it is a little ugly and requires you to download the Collab.Net SVN client. Subversive has been a far superior SVN plugin with a choice of connectors and a decent implementation of a diff editor and team synchronisation page.

Therefore I am absolutely delighted that the Eclipse project has adopted the Subversive code base and is incubating it for release as the official in-built SVN plugin for Eclipse. It’s an excellent decision and puts Eclipse ahead as far as SVN support is concerned. I look forward to the official incorporation of the new plugin.

Part of the reason why Subversive is great is that it really makes it easy to use a variety of SVN provider implementations. My favourite is SVNKit which has always been reliable, fast and fully featured. It surprises me that NetBeans which is otherwise very much all about the Java has chosen to use a native SVN implementation. I would really like them to create an SVNKit based plugin.

Standard
Java, Software, Swing

Getting things done with Thinking Rock

I have used all manner of organisation tools but at the moment the one that is really working for me (and indeed which is telling me I need to write this post) is Thinking Rock. A Java application based on the NetBeans RCP that implements the GTD process.

The basic elements of the application are okay, focussing on quick capture of thoughts and providing enough tools to correctly categorise them. However it is in reviewing and working on your actions that the application really shines. A single screen allows you to review and organise both projects and tasks. The filters for managing tasks are excellent and really make it possible to work with hundreds of thoughts and ideas at the same time. Better yet as a Java Swing programme you get exactly the same functionality and features on OSX and Windows allowing me to use it on all the various computers I own or use at work. A fully-fledged version 2.0 is promised soon but the development version I have been using has been completely stable and fully featured for my use.

I thoroughly recommend it to anyone else with a cross-platform need.

Standard
Java

Observe the Madness!

I decided to give OpenJPA another go now it’s all incubated and promises that running agents are the way of the past. Before I can really try any of that though I have a huge problem with my persistence.xml file not being parsed. I had this problem last time I tried OpenJPA and it took me ages to solve then as well.

I ended up looking at my own blog for any clues as to how I fixed it; I was infinitely recursing up my own arse. Anyway to help improve my Googling for a solution in future… If you are using OpenJPA and you get the following error:

cvc-elt.1: Cannot find the declaration of element 'persistence'.

Then replace the first persistence tag in the following way:


Not <persistence> but
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">

This simply defines what the Schema should be for the persistence unit. To understand why you’re doing this see this post. Note that the post is titled Dumb User Question but it’s really not, if you look at the example persistence file given in the documentation you would forgive anyone for making this mistake.

Standard
Groovy, Java, Scripting, Swing

Groovy Gridbag Example

Before Christmas I decided to give the Groovy Swing Builder a go since I am in the market for a language that makes creating small utilities in Java easier. Groovy is now Groovy 1.5, fully aligned with the Java 1.5 release. The new release sees lots of improvements all over the place. The Groovy Console has had a substantial revision and is now a really good way of experimenting with more complicated scripts (previously I only really used it to run snippets of code). The text colouring and decoration really works and the previous problems with massive stack traces obscuring actual issues seem to have been fixed. Really there are just two things that are needed to make it perfect, the first is line numbers so you can relate error messages back to the script you are working on and auto-completion. I wouldn’t mind having tabbed editors in the console as well but I can live without it.

What hasn’t changed is that documentation is generally woeful and examples and tutorials are hard to find. Most of the Swing examples I could find really used small numbers of components and simple Layout Managers. I have tried to create a more complex example using Grid Bag and based around some existing Swing code I found.

It took me a lot longer than I thought it would to create this code. Part of this is just not knowing how to tackle things, Groovy allows you to set attributes within the constructor with the interesting syntax property: value. However it is hard to know when you should use this or when the interaction should occur within the braces. After getting a working example going there is only one major mystery to me here. If I do not put the table inside the scroll pane then I lose the header columns on the table in the second tab. I really cannot see why that should be and if anyone more versed in the language can help me I would be grateful.

Standard
Java, Software

Setting up a Derby Database

Okay so I currently I am setting up a number of databases on my own V-Server and I thought it would be helpful to make a few notes about the current Java databases and how easy they are to run in Server mode. The two biggest databases are Derby and HSQLDB, this post is about Derby. Both databases are really geared towards the embedded space and generally focus their documentation and tasks around this. In their default setups they are both pretty insecure for running on a public network, neither for example defaults to using passwords to authenticate logins.

All the databases are getting setup in the same basic way. Each database is going to be run in the userspace of a dedicated UNIX user and that user is meant to be accessed via SSH and SSH Keys. All the datafiles will reside within the user’s space. I’m not going to go into that as it is fairly straightforward and is probably better covered by the various UNIX admin guides you can find around the internet.

So Derby first then, well I have played around with Derby before so I hoped this would be the easiest. One thing that you need to know about Derby is that its documentation is good but it is organised into several different documents… by a madman. There is no apparent logic, rhyme or reason to the way information is included in one document or another. When setting up the server I had to jump between the Developer’s Guide, the Tuning Guide, the Server Guide and more unusually the Tool Guide. If you have the same experience then don’t worry, you’re probably doing it right.

Having downloaded the Derby package unpack it to the root directory. I find it helps with upgrades to create a symbolic link ~/derby to the actual installation directory. You can also create a profile environment variable DERBY_HOME that points to $HOME/derby.

With that all setup you can simply run ~/derby/startNetworkServer and you should be in the basic network server business. This is where it gets a bit more complicated. Derby will look for its configuration in the directory where you start it not in DERBY_HOME. So you need to create a derby.properties file in $HOME to configure the behaviour of the server.

To require authorisation you need to properties created in the properties file. Remember that the format of this file is a standard Java properties file. The two properties are:

  • derby.connection.requireAuthentication=true
  • derby.authentication.provider=BUILTIN

You should now restart the server. Now when you want to interact with the database you should need to provide a username and password. You have to check this though to make sure it works.

Run the ij tool from the command line: try to create a new database with something like the following

connect 'jdbc:derby:test;create=true';

You should get a message saying something like ‘Invalid authentication’. If the database is actually created then the database is probably not picking up your properties file, which in turn is likely to be an installation issue.

All being well we can now add a user to the properties file. User information is also a property so to make the file manageable you probably want to use comments to divide up the file into relevant sections and try and keep all the user setup in the same place. The format of the user entry is derby.user.USERNAME=PASSWORD. So for example

derby.user.test=changeme

Okay now restart the server and login via ij again. This time use a connection URL like the one below.

connect 'jdbc:derby:test;create=true;user=test;password=changeme';

This should now create a new database under HOME and give you access to it normally. Drop out of ij and confirm that the test directory has been created.

That is pretty much that now, from here on in you can connect to your server database instance as you would any other database server.

Written like this the setup must seem very basic and quick to perform, which is good. However when I was finding my way with it, it took over an hour and most of that time was taken up with looking for things in the documentation. Nothing is logically organised with Derby, for example the configuration properties are all described in the Tuning Guide. Except the network control properties which are described in the Admin’s Guide.

Unlike code DRY is not a good idea unless you are going to very rigorously modularise the documentation. Even then why not repeat something if it means that all the information relevant to task is one place?

Derby has a great feature list but I wonder how many users are ignorant of what it can do because of the poor documentation?

Standard
Java

JBoss 4.2.2 Binding

As the original post is getting some hits I thought I would just post the short version for people who are stuck and need to get going again.

If your JBoss 4.2 installation is only listening on some ports and not others then you need to add a host parameter to the script that runs JBoss. The script that runs JBoss should look something like this.

run.sh --host=0.0.0.0

The JBoss Wiki does make oblique mention to this as do the Release Notes (look for the Configuration Notes for 4.2.0 in the linked document).

Standard
Java, Software

Test Blight

Another Bliki entry related post; I’m not sure I would refer to what is described in the article as Test Cancer, I would say it is Test Blight. As soon as one test is switched off it weakens all the other tests and soon the whole “test tree” is dying off as it begins to constrain and describe the system less and less.

Test Cancer is probably a better term for the situation where your test base keeps growing and growing but in a meaningless way that actually obscures what is important in terms of the system description. For example JUnit tests that have no assertions but just execute code. Or hundreds of test files that are testing the accessors of your value objects.

Standard
Groovy, Java, Python, Ruby, Scripting

Groovy or JRuby?

Martin Fowler blogged about the question a couple of days ago and ever since I have pondering that maybe it is not really the right question to ask.

I currently toodle between Jython, JRuby and Groovy for various reasons and I am an expert in none. The interesting thing I have found is that it is hard to pick one and just focus on that. To some extent they overlap heavily: they are all cross-platfrom, they are all dynamic, they all integrate with Java API stack I’ve committed to memory.

The first thing to say is that I am interested in scripting languages for prototyping and admin style scripting. I have never used Rails and the Grails data-model means that you need a specific kind of project to work on. If you want to use a particular product and that is only on one platform then that kind of makes your decision for you.

Each language has its own strengths, from my point of view I would categorise them in the following way. Jython has Python’s readability and solid language design, JRuby has Sun’s support, excellent community contributed library code and is very dynamic, Groovy is mini-Java, so it’s easy to learn and most importantly it has a functioning interactive console.

The last point might seem a bit weird, what about jirb and jython‘s interactive mode? Well Martin makes a very important point in his post about the purpose of these ports. Both JRuby and Jython aim to stay faithful to their source languages and be able to run code from their parent C implementations while expanding the API by accessing the Java libraries. Groovy on the other hand stays close to Java syntax and is the only one of the three that allows you to cut and paste code from a regular Java application and then play around with it in an interactive session. That is a very powerful and compelling feature.

Almost all the Groovy I do either comes from wanting to leverage or understand a piece of Java code.

All my Jython work on the other hand is about wanting to automate administration or manual tasks in a clear and concise fashion. Python’s dynamic data structures help, but so does zxJDBC the Jython specific database library that mixes DBI with JDBC to create a highly portable but simple database connectivity solution with no boilerplate!

JRuby on the other hand is something that only really comes up because Alpha Geeks love it. The syntax is gnarled and there is a significant learning curve before someone from a Java background can get “The Ruby Way” of things. The new integration of JRuby into NetBeans though makes developing in the language a comparative snap and I would suspect that JRuby will be a valid choice of application development language alongside Java now. The choice will be driven by the problems you are trying to solve not because one language is inherently “better” than the other.

Standard