Saturday, December 24, 2005

iPod Fever

I got an iPod Shuffle for listening to podcasts a couple of weeks ago, and despite some initial problems, I am very pleased with it. There are still a few rough edges with iTunes. It may be fine for someone who wants to collect and listen to music, but it does not work quite so well for podcasts.

A big rap against the iPod is that it does not have a radio. I got an iPod because I wanted to listen to podcasts while I worked out, and as radio reception is broken at the gym, I was not looking for a radio anyway. With a little experience I have come to realize that a radio in an iPod would be completely superfluous.

The point of the iPod and a podcast is that I can listen to the talk show I want to listen to, when I want to, rather than being tied to the tyranny of the radio schedule. Initially I thought that I would miss the serendipity of having to listen to the available talk radio, however there is plenty of serendipity when you subscribe to the right podcasts.

Thursday, December 15, 2005

Software Development and Content Management

Recently, after I wrote about Content Management for consumers, I realized that the software that I use every day in my job as a Software Developer is also a Content Management system. In bald terms, a Content Management system consists of a content repository and workflow that define and controls how the content is managed.

A software system comes from a collection of source code that is maintained in a Software Configuration Management system (SCM). It allows you to see each change to the code and who made it. A sophisticated SCM allow for code development along different branches at the same time. A SCM is in effect a content repository.

Some people on reading this will say that a Content management system means that all content is kept in a database. I will explain on another occasion why it a bad idea to lock content away in a database and propose a better solution for a content repository.

In the system I use we have a bug tracking system that is called an issues system because issues is good newspeak for bugs, and also because the system is used for tracking not only bugs, but also features and enhancement suggestions. Moreover the system is set up so that you cannot do a code checkin without tying the code change to an issue. This allows the system to check that the code change is made to an appropriate version of the code.

The point of all this is that the bug tracking system defines and controls the code development workflow and is tightly tied to the content repository. Thus the whole thing is a Content Management system.

Tuesday, December 13, 2005

Ruby on Rails

Slashdot must be getting desperate. Yesterday they had a lengthy discussion on the Future of Emacs, and today they had yet another discussion as to whether Java is so 90s. Meanwhile, tonight at the SDForum Emerging Tech SIG, we heard Tom Hill (founder of the SDForum Java SIG) talk about Ruby on Rails, the hottest new software technology on the block.

Ruby is another of those object oriented scripting language that is apparently typeless but seems to always do what is expected without overspecification. Rails is a web application framework written in Ruby that is also designed to do just the right thing. Together they make a terrific base for web based applications. All you need is Ruby on Rails, a database, a web server and a little development time and you are in business.

Tom touched on many interesting topics during his presentation. The one that struck me is the treatment of persistence in Ruby compared to say Hibernate. Hibernate is a Java framework that I mentioned in my last post for persisting Java objects in a database. With Hibernate you specify the object in Java and also specify the database schema and Hibernate does the mapping and transference between these two representations.

In Ruby, the ActiveRecord component gets the object specification from the database schema and creates an object based on the database record structure. There is only one specification of the object structure, so there is no problem with synchronization of specifications. Moreover, the Ruby object automatically adjusts to changes in the database schema without necessarily needing changes to the program.

In practice, a database needs its schema otherwise it would not know how to access and deliver its data. In this light, having the application language bend to use the database schema for its object structure seems sensible, and Ruby makes it seamless.

Tuesday, December 06, 2005

POJO

As a young newly minted software person, one of the first things I remember hearing was an engaging a talk on the issue of separating business logic from implementation. That was mumblety-mumble years ago. How times do not change. Tonight at the SDForum Java SIG we heard a talk on exactly the same subject.

This time the talk was wrapped around the subject of POJO, which stands for "Plain Old Java Objects". Chris Richardson, author of a new book "POJOs In Action" spent most of the talk telling us what POJO are not. In particular POJOs are not Enterprise Java Beans (EJB).

Underlying all the negativity was a positive message. Write your business logic as a set of plain old Java objects. Then implement the application through lightweight frameworks. Use Hibernate or JDO to make the objects persistent and Spring to provide transactions.

The important concept is that you do not change the business logic code. These frameworks are declarative specifications in XML that describe the implementation of the business logic without you having to change it. I know from my experience with JDO that it is not quite as easy as all that, however it seems like we are still headed in the right direction if not making a lot of progress.