Development

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.

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.

How many cookies do you neeed and how many does the browsers support? - It seem to come up all to often, so after a bit of digging in search engines, here are (for my own convenience) the findings of what the limits are on cookies in the currently used browsers.

The cookie standard (RFC2965) specifies a browser should be able to handle at least 20 cookies per domain, but one thing is a standard - who does the real world look?

It seems many developers get stuck in the same systems maintaining the same code for years and years. While it may be a common phenomenon there are a few things you can do as a developer to avoid being trapped in your own code forever.

First make things readable.

While your brain may be wired to a system of only using single character variable and function names or naming global variables after your cats, no one else will get the system. Try to make all names as logical as you possible can. Making it easy to read the code