Blogging Pubbitch

Disclaimer: I've had the pleasure of working with Pramod on a project. He's a thoroughly lovely chap. Now that's out of the way....

The concept behind Refactoring Databases is that developers shouldn't be the only ones having success with refactorings. It's time for the DBAs to be provided with the patterns needed to successfully manage the transition from harder to use, less well organised data to clearer, well structured information.

In doing this, one of the things that the book brings home is that the time-scales for changes in a databases' schema can be dramatically longer than those in application code; I liked the fact that this was made clear to the reader. Given the time-scales involved it seems fortunate that the refactorings covered provide recipes to keep code that depends on the older, unrefactored, schema up and running.

The book also provides a strategy for providing confidence in your refactorings by introducing the concept of staged environments --- a series of environments which are increasingly controlled leading from the developer's workstation all the way to the production environment. This sort of concept should hardly be alien to developers, and is something that I've seen happen informally on many projects with databases, but promoting this concept to the fore when working with databases can only be a Good Thing.

This leads me to my next point: like many things, once the ideas and concepts presented in this book are laid out in front of you, they seem pretty obvious. Whether this is good or not is for the reader to decide, but I thought that it was one of the stand-out features of the book --- spotting the obvious is one of the hardest things to do in computing.

In summary, I enjoyed the book and would recommend it to anyone who has to work on anything other than a greenfield database. Is it perfect? Of course not, but it's a clearly put-together big step in the right direction.

Just had to jump through an enormous number of hoops to download a new copy of RealPlayer One for OS X because my previously working beta had decided to time out and never work again. I'm not entirely sure that it's not time limited, the site was a dog to navigate, they asked for personal information to download the player, and they had opt-out rather than opt-in checkbox invitations for more spam than I know how to deal with.

MS, for all their failings, don't make it this hard to get hold of their player. If I didn't know better, I'd say that Real were desperate to put themselves out of business by alienating any users that are foolish enough to go near them. I can only describe them as being actively user hostile and randomly useless.

*click* Another part of the XP way of thinking sinks in. I've been trying to develop "test first" for a while and found it to be slow going. I think that there were two reasons for this. Firstly, I was exploring a number of different ideas in code, and until those had been thrashed out nothing was going to go fast.

But I don't think that's the real reason for my slow project velocity. You see, as a developer, I love the intricacies of working on the back-end of the site. I'm fascinated by all the little moving parts, whirring in front of my eyes. Anyone who's ever written an appreciable amount of code must know this feeling, surely? But that's not the best way to get the speed up. The thing that's just clicked is that being able to show the end-user of your code something sooner rather than later isn't just to keep them happy. It's to keep you focussed on what you're doing.

I've just taken the time to start developing "front end first" by writing the JSP the way that I'd like it to be. This gives me the interface to my Webwork actions in the same way that TDD offers me a chance to write the interfaces to the other components. Once I know what the actions need to do, I can figure out what other pieces of the puzzle need some flesh to get things to work as expected.

Suddenly, I'm going a lot faster.

And apolgies for the snappy title.

Here's my wild and crazy idea, which'll only make sense to people who have used Hibernate. Why not extend MapGenerator to also read the source for the classes it examines (if available) and hunt out the XDoclet tags meant for the HibernateDoclet task?

This allows for at least two things:

• The graceful handling of abstract parent classes (I happen to like the way that MapGenerator deals with them)
• Give complete control over how the generated mapping does table and column names (which is why it's not advisable to use MapGenerator without faffing with the generated files)

The Hibernate XDoclet task has some known limitations (especially when handling composite keys) that I don't think that MapGenerator suffers from (though I could be wrong!)

In fact, it should be possible to write something like MapGenerator that relies on QDox to do all the analysis without having to compile the code at all or rely on reflection. Argh! If only there were time to do that!

What a great level of customer service is it that I can log a bug with Apple about the UI of OS X and have a response sitting in my inbox the next day? Okay, it asked for more information, but within 20 minutes of sending that information a real human had read it and "forwarded it on to the appropriate engineering team" (as well as getting an automated response too) All I ever get from MS are slow (if any) responses and endless spammed questionnaires asking if their service was okay. Ditto Oracle and Weblogic, but they approach me through lackies and salesmen. The Apple response is more like one of the better Open Source mailing lists (Hibernate's, for example)

Frankly, I'm impressed with the way that Apple are starting to focus on providing a better service to their customers. Not only are the Apple guys on the mailing lists I'm on unfailingly polite, but they're also helpful (which I suppose they should be, but not entering flame wars or rising to some of the baiting is a Good Thing)

They've also got some bright souls working for them, who are dedicated to what they do (Dave Hyatt springs to mind straight away) and they make some of the most desirable computer kit on the planet.

So a public "pat on the back" for Apple, then. Now, all they need to do is get JDK 1.4.1 out to an eagerly waiting public (I've got the developer preview, but it's just not the same as an official version)

Given my browsing habits, and the haphazard way that I collect bookmarks, I'd like some more smarts from my browser. Ideally, I'd like my bookmarks "scored" (like my mail is in mutt) If I boomark a page more than once, then it should have a higher score than one that I've only bookmarked once.

If I visit a site that one of my bookmarks is on (not necessarily the bookmark itself) then that bookmark should have a higher score than a bookmark on a site that I seldom visit. Obviously, it should be possible to determine how long that score will last, possibly allowing it to "decay"

If I constantly keep typing the same URL into the URL bar, I want that bookmarked too. For example, I've not bookmarked "www.google.co.uk because I always type it. Finally, if I spend a lot of time reading pages on one site, it would be really useful if the browser could automatically create one bookmark that site for me, possibly using information that should already be exposed for accessibility purposes.

What am I whining for? There's nothing stopping me from trying to fit this to Mozilla except for an utter lack of free time....

I've been using emacs ever since university (not that long, but long enough) and thought that there must be a neat way to persuade it to help with java development in the same way it copes with C/C++ dev work. For those of you not in the know, emacs and the GNU tool chain combine fairly seamlessly; it's possible to call gcc from within emacs, and then jump to any file and line that reports a compilation problem by just moving the cursor to the right place and hitting return. Very nice.

After a little hunting on google, here's how I now do it:

  M-x compile

When asked for the path to the make command, try

  ant -find build.xml -emacs

I'm using jikes as my compiler, so have to add "build.compiler.emacs" to my ant properties. And that's it. Nice and easy.

Joe speaks sense. Again.

The Pragmatic Programmer suggests learning a new programming language (at least) once per year.

...

So, which one should it be? How will they change the way I think? What will you be learning this year?

It's been on my list of Things I Want To Do for a while, so I'll choose Ruby as this year's language. I saw my parents yesterday and they gave me a belated Christmas present: the Pragmatic Programmers' Programming Ruby, so it looks fated, AFAIAC.

I wouldn't mind the time to improve my (almost negligable) Prolog knowledge too, but there's only so much time in the day.

Oh, and Joe, you might be interested in JRuby

Just spent a part of the day reading the docs and playing, and have come to the conclusion that mod_proxy and mod_rewrite are simpler to set up than jk, jk2 or mod_webapp and just as effective, if not more so, because you're not tied to using Tomcat (well, Jetty has a JK adapter too, but *shhh*)

For those of you out there looking to see how it's done, take a look at the Proxy Support HOWTO over at the Jakarta site. Use this technique when you need to pass through whole sub-directories to your app server (take a look at your servlet-mappings in the web.xml file --- it should be obvious)

Where you have a servlet mapping that matches a postfix (such as "*.jsp") you'll need to write a mod_rewrite rule that redirects that URL to the proxy. For example, I am currently using:

RewriteRule ^/(.*\.jsp.*)   http://localhost:8080/$1  [P,L]

to pass any requests for JSPs to the localhost, and this seems to do the trick.

BTW, I assume that I have to match after the postfix in case the JSESSIONID is appended to it. If I'm deluded or just plain wrong, can someone please comment?

Just dug out an email that was sent to me all the way back in October by Marko Asplund, in which he details some fixes to make the build process a bit less traumatic. The most useful tip is how to avoid having to muck around with your java installation's header files to get a successful build on Linux. Great stuff.

Once I've tested it, I'll update the docs again.