What’s Up With CeaMuS Development

January 31, 2006

In spite of the appearances on the CeaMuS site, there actually has been a respectable amount of activity in software development. The version has been bumped from 2.0c to 2.0e, and some of the results from beta testing are finding their way into the code. Some other things are being done to make it easier to expand CeaMuS when new features are necessary. So what are the changes?

The biggest change that you’ll see as an end user is that configuration got a lot easier. In 2.0c all of the configuration was handled through the ceamus.conf file. While the format of this file isn’t difficult, it simply can’t be edited online via a web browser and there are too many opportunities for things to go wrong. This was abundantly clear during beta testing. The structure of the file was also something of a nuisance to manage in the code.

Version 2.0e stores only the most crucial information in the ceamus.conf file. All the other configuration–the menus and galleries–are now stored in the database. A lot of things are also “handled” for you. One of my least favorite tasks in setting up a site was always setting up the directory structure for galleries. Now when the images are generated for a gallery the directory structure is automatically put into place. The same feature will be available for menus by the time 2.0e is actually released to the public.

The biggest changes, and the things holding up release, are architectural. Much of this can be blamed on my cousin, who bought me two excellent programming books for Christmas this year. Eric Gamma’s Design Patterns helped me to solidify solutions to some problems that had been bothering me for a while. Scott Meyer’s Effective C++ and Effective STL helped me to straighten out some problems that I’d been having, and that had been limiting development of new features in CeaMuS.

The other big change is that I finally decided to automate the building of database objects. CeaMuS always used the Active Record design pattern. Before the classes were always written by hand, but once they were done it was very easy to write interfaces that used the database. Over the fall a lot of ideas that had been swirling in my head about how to automate this took final shape, and I have a fully automated system for generating active record objects. I’ll post more about that later. For right now, all of the data objects and interfaces are being retrofitted to use these automatic objects.

The current state of the code is that it’s all ripped up. It’s definitely not following the Agile Manifesto of always being in a shippable state. But the upside is that as of Sunday last all of the individual components were compiling well together. A high level of paranoia will set in now as I put together a reasonably comprehensive test suite to make sure that it all actually works well together.

With just a little bit of luck I’ll be able to release 2.0e soon, something that will almost certainly make my beta testers a good deal happier.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: