Monthly Archives: May 2004

Internet Explorer source editor…..

After doing some more web development today I got sick of having the IE View Source go to notepad. I have fixed this on PC’s before, but not on my current laptop.

Finding out how to change my view source editor took longer that 30 seconds, so here is a link to make this easier to find :).
View Source Editor in Internet Explorer

In case that moves….

HKEYLOCALMACHINE\ Software\ Microsoft\ Internet Explorer\View Source Editor\Editor Name\default=pathtovim\gvim.exe

A quick review of the IntelliJ GUI Editor

I have just started doing some volunteer work for a Christian Organisation, putting together a simple computer based contact form, that they will be able to use in small displays in conferences and the like.

The initial idea that was expressed was that they would want an “Access Database” to do it. This translates this to having a form to capture the data, and a way of retrieving it later.

Being most productive in Java and IntelliJ, I figured that I would give the GUI editor a quick go (If you’ve got a hammer everything must be a nail ;)).

I haven’t used it since having a bit of a play a few months ago in the EAP, and found that it has improved immensely. It’s not quite perfect, but works very well. It does a good job of focusing on the view keeping the controller and model separate.

You edit the view with the standard Canvas metaphor. There is a property editor for editing the standard bean properties of components, and a navigator allowing browsing of the layout. The definition of the view is stored in an XML file, which is then used to generate either a Java class or bytecode depending on your preference.

The hooking up of the screen to a underlying Java class is really quite nice. You assign the form to a class (type in the name and if the class doesn’t exist you get the option to create it), and then follow the same approach for the properties. The online documentation makes it easy to learn how to do the normal things like grouping a collection of radio buttons.

When wanting to introduce a JScrollPane, I found some of the drag and dropping didn’t quite work as I expected, after a bit of hacking and things not working as I thought they would, I took a quick look at the underlying XML file. It was easy to read and understand, allowing direct editing with a text editor, 5 Seconds later and my Panel was inside a JScrollPane.

The Editor isn’t quite perfect yet, but it is well on the way. Support for editing an attribute on a group of components at the same time would be nice, as well as improved drag and drop in the form navigation panel.

Overall I found that the form editor made developing a GUI a pleasure. It was much more fun that Forms development with a package produced by a leading database company 5 years ago. I look forward to using the 4.1 version of the IntelliJ UI builder.

Continuous Integration isn’t rocket science…

After hearing Aslak talk about how great Damage Control is, and how it builds on some of the lessons learnt from Cruise Control, I thought I would take a look for myself, and get a feel for what the features are, and seeing what it offers over Cruise.

CruiseControl is not exactly the cleanest piece of code that is out there. The are large pieces of it that are only ever run through the unit tests, proving that good tests coverage doesn’t enforce good code. The configuration and setup of it is also harder than it needs to be. At the end of the day the responsiblities for a Continuous Integration tool are simple:

1) Check the version control system for updates (I think it is important to do this without changing the version control system, even if it means polling it every couple of minutes).
   builds should still happen after every commit (with the configurable lag time).
2) Call out to a build program (simple support for ant is nice) capturing the result of the build, as well as messages.
3) if the result of 2 is a success, send messages to the appropriate targets (e-mail support is crucial, anything else is nice).
4) on a failure send messages to the appropriate targets.

In order to support the above process there would need to be a simple config file perhaps using YAML. Ideally the configuration should be decoupled enough from the rest of the application, that this could be put into XML or properties as desired.

Obvious targets for 3, and 4 are e-mail messages (putting the results in the message would be useful), and a project website. The possibilities for others would be: IRC/Messanger/SMTP/SMS/Telephone Messages/etc etc etc…..

The configuration format should be simple enough that a front end for configuration should not be required. A page for restarting the build might be nice, but under normal running coniditions this wouldn’t be required.

Most of what is described here is met by Damage Control. The thing that I don’t like about Damage Control is that it seems to almost be overengineered. It is noblely doing alot of things in elegant ways, but in doing so, I think it is getting away from what is most useful for the typical internal development team. The need is for something that anyone could download, edit a simple config file, and have it just work. Any more magic should be hidden from the casual user, but possible to implement by the more advanced one.

If anyone has a free one of these, or wants to build one let me know :).