I recently had my 1TB hard drive (of which was +750GB full) die on me last weekend, after only 12 months of use. I decided to therefore go through all my old hard drives, that I had copied everything from originally, to see what data might have been left on them. I needed to know when I bought them though, and looking at the label on the drives showned something called a ‘Date Code’ for which there was a 5 digit number?

Anyway, the number is calculated on the financial year, then week number of that year, and the day. It’s all explained on this page, along with a handy date code to real date calculator: Seagate date code.

I might be a bit behind the times here (oh, a good 9 months!), but I’ve finally had a chance to sit down and install Drupal Acquia - and to cut a long story short, I’m very impressed, indeed!

Acquia is the commercially supported version of Drupal. The standard package (which can be downloaded from the acquia site) comes with all those important 3rd party modules: CCK, Views, Wysiwyg, Filefield, Calendar, Date, Google_Analytics, Imagecache, Pathauto, Print, Admin_menu and a whole lot more. Individually downloading, extracting and moving/uploading all these modules can take a fair bit of time normally.

One of the (pretty minor) downsides to using Acquia though, is that the commercial subscription options come bundled (and enabled) with the package, and the default garland themes has a little Acquia branding. Surprisingly though, its pretty easy to disable (aka vanilla-ise it), and I’ve jotted down the whole 2! steps taken below:

1. Simply disable the modules (Site Building->Modules): Acquia Site Information, Acquia Search (if you’ve switched it on) and then Acquia Agent (you might need to disable each one individually). This will remove the subscription messages and the flag shown in your admin menu (top right hand menu).
2. Go to Site Building->Themes->Garland->Configure and tick the ‘User the default logo’. This will switch back on the Drupal alien logo, rather then the acquia logo.

That’s it, pretty simple, huh!

Now a quick note if your a developer:

The 3rd party modules which you’d normally install into ’sites/all/modules’ are instead installed in ‘modules/acquia’. No, don’t put any custom or other 3rd party modules in ‘modules/acquia’ - continue to put them in ’sites/all/modules’ to ensure you don’t contaiminate the acquia installation. The reason you might want to know where the 3rd party modules are that come with acquia, is that you might need to go through the code (perhaps for searching for a theme function, or function parameters).

Not much more to say at this point about Acquia, other then that it rocks!

The other day at work, we were discussing our initial trials of an open source ecommerce web application, and the following post came up: Why do open source web apps suck?

While I can say first hand (attempting to maintain Zencart, Joomla and phpNuke sites in the past) that there are a lot of open source web apps that do suck, I don’t agree that they all do (and the same probably goes for proprietary software too! - some suck and some rock).

“1. You can’t guarantee the code. Unless your developers has spent A LOT of time working with the application, they aren’t going to know the code. For them to become familiar, they are going to have to spend a lot of time getting to know it. This doesn’t save time, it wastes it.”

Can proprietary web apps be guaranteed too? If anything proprietary web apps can be guaranteed less, because in a company where only staff members of that company know the ins and outs of that application, if those staff leave (which, they naturally will), the new comers are going to be spending more time learning and testing, then actually producing work. At least with an open source web app, they could have been exposed to the app before hand, and can hit the ground running when they start?

“2. Making core changes to a system is just asking for trouble - I hope the time you saved by using the system is re-allocated to testing the FULL application - you have no idea what you will break.”

Take the CMS Drupal for example - it’s designed in such a way that no one needs to make any changes to core code because everything can be overridden.

You put your contributed themes and modules into their own folders, and your customised themes and modules into another set of folders. Core updates can be applied without affecting these because Drupal simply knows not to touch these folders.

“3. Skinning pre-built applications sucks. Trying to modify some else’s CSS is worse than someone else PHP. Just like modifying core code libraries and hoping for the best, it is really hard to know what you will break. That is of course assuming the application isn’t a spaghetti of tables, and includes that have little structure (Xoops, osCommerce, Joomla - I’m looking at you).”

In Drupal, all pages, nodes, fields, blocks, and so on, can have their own overridden template files. Whether you choose to call your div something specific and then do your own styling is entirely up to you.

“4. Open source developers are very narrow minded - their contributions are to suit their specific need, which means every developer will try to include their feature, and unless the leads are ruthless, you end up with a application that has everything that opens and shuts, but that doesn’t really open or shut very well.”

Just about any type of developer is going to have their own agenda. For the Drupal core though (like a proprietary app I’m sure), there is Dries, the original and lead developer and then there is a small set of developers that stick to their own areas. See the Drupal MAINTAINERS.txt for details. For developers that are narrow minded, this is still allowed of course, its just a case of them developing their work as a pluggable module.

“5. As soon as you modify software, forget about updating it. If there is a security fix, or a new feature, you will basically have to spend a similar amount of time re-patching the new version with your changes. If you wrote your own application, you can add a feature much more easily.”

With open source web apps, you’re naturally going to require applying security fixes and updates, so its in the developers best interest to support such a thing. Take the Drupal CMS again - it can actually be setup to talk to the Drupal software Repository, and notify you when updates are detected.

“6. ‘Modules’ are a misnomer, I am yet to see a decent module system for anything but the most basic feature - they all involving modifying code to work, which is you ask me, isn’t a module.”

With Drupal, you simply: 1. Download, 2. Upload, 3. Activate in your Module Listing via the admin menu. 4. Configure in the configuration settings of that module via the admin menu. If and when you want to customise the styling of the module output, you create functions or template files in your custom theme folder, not the module (so it also can be updated, see #5)!

Take a look at the 3rd party Drupal Modules: CCK, Views and WebForm - these really add a lot of functionality to Drupal.

“7. The documentation will never be up to date. On of the selling points of open source software is that you have thousands of developers at your disposal to fix and add features quickly - unfortunately, the documentation never keeps up. You better get used to reading source code.”

Most documentation for web apps is outdated anyway. Personally, I always found wiki’s, discussion forums and mailing lists as the best place for advice - at least they are more likely to exist with open source applications and don’t cost an arm and a leg to access?

“8. Open source apps are hacked not engineered. Design by committee never works, design by ad-hoc anarchy REALLY never works - if the project doesn’t have a clear leader who has a vision and is ruthless in implementing it, you are going to end up with a mess.”

After the first sentence, this is pretty much true - but again, it applies to all types of software/web apps. Drupal started off as a hack, but after many rebuilds and iterations, I’d be surprised if even one line of code is still in there from version 1.0.

“9. Support. You don’t get any. Budget time for your developer to scour the ‘net for an obsure german forum where someone has found a solution to the similar problem you have had that may or may-not actually work.”

Check out Acquia - commercial user and developer support for Drupal.

I think the main point here is, just because a web app is open source, doesn’t mean it sucks.

I’m also going to make a note here, that despite me being a Drupal fanboy, I do acknowledge that its not a perfect web app (for one, there are some serious usability issues with the administration interface that have been around since the early days - suppose to be fixed in the upcoming Drupal 7 release though), but hec, can any piece of CMS software be? Hopefully other open source web applications will follow a Drupal like development and maintenance model..

Just a few tracks I’ve heard on ASOT, and other online radio shows over the past few weeks that I really liked, and wanted to share:

1. ASOT#393 (19.30min): “Oliver Smith – Restless (Signalrunners remix)” (yt) - fun classic sounding trance
2. ASOT#390 (39.00min): “Kyau & Albert – Hooked On Infinity” (yt) - soothing euphoric trance
3. Bassdrive.net: “Tyler Straub - Drawn Faces” (yt) - great drum n bass track
4. Somafm: “Mimoid - Strawberry” (lastfm) - weird/spooky chillout
5. Somafm: “Orb - Back Side Of The Moon” (lastfm) - another weird ambient type track

Until next time, Adiós!