Quite awhile ago I posted a little piece of javascript, which could be used to a (very) simple webpage slide show. Someone requested a version a little more advanced for use in a kiosk mode, and sure why not - updating the script with the option to set different times on the webpages displayed was a minor change, and it’s been done now.

If you’d like an updated version of a basic webpage slideshow with an option to specify the time each page is displayed, go ahead get it from the lab.

Most developers (and certainly professional shops) working with software- or webdevelopment has understood the ideas behind sourcecode version management - no matter if they choose to use cvs, subversion, git or any of the other fine systems available. How developers use these systems, can provide an easy insight into who is the dummy, the average and the great developer.

When to commit

One of the first distinguishing signs is what they commit - is the version management system used as a backup tool or as a version tracking tool. Some seem to think, you should end the day by committing all your sourcecode (no matter which state it’s in). This is really bad sign. Others commit whenever a new file is finished and thought ready to use - which is slightly better. Others again commit once - just before a new release - and has the commit contain each and every change since last release.

It’s often the case that security is an inconvenience and gets in the way of usability and ease of use. There are exceptions though and for a number of weeks I’ve been playing with the Yubikey (thanks to Schack) from Yubico.

It’s a small device, which plugs into a USB port, and to the computer acts as a keyboard. It has some advanced security build-in with the ability to generate one-time verifiable passwords, but is incredible easy to use – plug it into the USB port and press the single button when you need to sign in to services supporting the Yubikey.

So it been awhile since I sort of promised some tips on developing web applications fast. This post contains my five generic tips, which may apply to you (but then again - your mileage may vary). I’ve tried to abstract the advice and not stick to PHP development here, though it’s by far the world I know best.

1. Spend time on the data model

Too often a data model is driven by code, not careful thinking, and this often causes problems has the web application develops and expand over time. When developing a site, which needs data stored in a database (as most web applications tend to do), do try to spend some time on the data model - which tables do you need, what fields should the tables have, are the naming logical and consistent, what constraints and limitations does the data model offer.

It’s always fun to read articles with tips and tricks by other developers and see how they figure “best practices” are handled. Most developers do seem to thing they observations and practices are easily adopted by anyone, and should be accepted without any argumentation or reasoning behind the advice.

One of the nice examples of this, was a story called “5 tips and tools to develop php applications fast”, and while it may apply to the web applications developed by the author, it’s one of those where I question who is supposed to be the audience. All 5 tips are often found in many textbooks and other stories on the net, and in my experience they are all wrong (more or less naturally).

I’ve been spending quite some time the past days digging around in old code (3+ years old with no or very little changes). It’s quite fun noticing what efforts pay off and which doesn’t when you go back to make chance to old stuff. I’m sure my observations aren’t generally applicable. We’re web developers and are keeping web platform (several pretty big websites on a common codebase) alive year after year.

I recently had a little fun playing with the dynamic cache available in the Zend Platform. The Zend Platform is a commercial product, which provides a number of cool professional features to a PHP setup - one of these is the option to do dynamic caching.

With dynamic caching you can cache the output of a function for a determined period and instead of doing database queries or web service calls for a feature, you can cache the results, save resources and get faster pages.

In programming languages common tasks should be easy, and surprisingly often I find my self loading data from some source file into a database. With PHP loading a CSV file into the database - or posting the data to an API - is quite easy.

The only trick is to know the functions file_get_contents, split (and possibly list).

The routine goes something like this:

$fileName = 'rawData.csv';

$content = file_get_contents($fileName);
$rows = split("\n", $content );

foreach ($rows as $row) {
	list($item1, $item2, item3) = split(';', $row);

	// Do something interesting...
}

If you have a php array, but need to nuke an item from it, the unset function is just the tool to do that. When iterating through the array after removing the item, you should be slightly careful.

The unset function does remove the item, but it doesn’t “reindex” the array, so you should traverse the array by index-numbers after removing the item. The issue is probably best illustrated by this example:

Yesterday PHP 4.4.9 was released, and today PHP 4 is officially dead. There wil be no more updates.

Don’t worry too much tough. PHP 5 is far superior and there’s absolutely no go reason not to have moved on to PHP 5 long ago.

PHP 4 - It was a nice ride and I’m sure you deserve the rest.