Development

Validation: black or white list

When you’re validating data – either client- or serverside – there are basically two strategies you can choose between. You can either blacklist data or white list data. Blacklisting seems to be the most popular way to validate data, but white listing is so much better. Here’s a brief description of the two strategies and why the white listing is better. The black listing strategy is validating you input against a list of characters which are illegal in the input. You can either reject input containing the blacklisted characters or just remove them from the input.

Do Repeat Yourself

It seems most developers has listen too much to the principle of “don’t repeat yourself”, and so otherwise bright developers in some cases strive too much to avoid repeating themselves and makes a mess of their systems but avoids repetitions completely. If your developer and reads about the DRY, do also remember the important step one: Think. I’m basically all for DRY. Endless repetitions of the same lines of codes is a pretty bad idea and should be avoided.

Don’t use Ajax blindly

GMail and other web applications have adopted a new technique coined Ajax (by Adaptive Path). It brings web applications a step away from the stateless web and closer to real applications. It’s harder to built applications with the applications, but it’s hot – and the most recent release of Rails (for Ruby) promises to make it much easier to do Ajax applications. Before you do too many Ajax applications, do think for a second. Tadalist is a great example which could have been so much better with less Ajax code. The application rocks in a browser – if you’re at a full computer where the browser knows about and fulfil the requirements posed by the Ajax technique.

Developers, Designers and Templates

David HH has an interesting piece on “The false promise of template languages”. While neither Perl nor PHP may offer the same clean syntax in the code as Ruby can do, it does indeed raise a few interesting questions about how actually benefit from the templates and who does in the space between designers and developers. I do love some degree of separation between heavy duty code and the interface layer, and usually work with HTML::Template or Smarty – they work and the penalty for using a separation layer seems to be the smallest possible (at least in a balanced performance/ functionality view).

Client side Progress bar

Providing feedback in user interfaces is quite important. If you have a task, which may take a while, one of the ways to signal to the users, that the system is working, is by displaying a progress bar. If you don’t know how to make one, we do have one available for you.

Secure PHP Programming

A new group has appeared on the net – the PHP Security Consortium (PHPSC). It is an international group of PHP experts dedicated to promoting secure programming practices within the PHP community. Nice. While many PHP developers make sites people are supposed to use and enjoy, few as actual education and experience in how to make secure applications and websites.

Through projects and articles, they’ll try to educate PHP developers.

it’s more than syntax

Most developers and programmers know more than one programming language, but often do most of their development in just one language. Listening in on IRC channels on people using something other than their favourite language is often quite interesting. It’s often a common misconception, that their favoured programming language - be that perl, php or java - is the ultimate tool no matter what the challenge is. When they are forced to use something else, a large part of the development process seem dedicated to (a) bitching about how much easier this and that would be in their favoured language and (b) forcing the language they use into looking like their favoured language.