Tips for developing WebApplications

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 often far easier to refactor code and functionality than it is changing the database tables and fields, and it can be a tremendous help while maintaining an application if you clearly understands the data its working with.

2. Get the basics working first and fast

It often takes a while to get a complete web application finished. Help motivating yourself by getting the core working first and then add features and frosting once it’s working. By having a working skeleton, I usually find it much easier guess how much work needs to finish the various features than I do guessing the work needed to complete a section (ie. admin interface) on the application.

3. Think performance and security from the beginning

Remember to think of performance and security from the very beginning. Sometimes performance – or security – may cause you to layout the data model in a certain way or structure the application a certain way. While you may be able to add performance and security during refactoring, it’s often much harder than it is keeping both in mind from the very beginning.

4. Don’t fix the future; focus on the current needs

I don’t care about the next version. I really don’t want an infrastructure in place, which can help me build the future versions of the application. I want the features and infrastructure in place for the current version I’m working on – and frankly the features in the next version has a tendency to change before I’m ready to develop them.
Too often future-proofing an application clutters the code and too often the clutter doesn’t ever come to any good use – it’s just noise once we get to the real future features of the application.

5. Naming matters

Do think of what names you use on functions, classes, variables and database tables through out the application – and choose something meaningful. A variable named $x doesn’t hint what it’s used for. Help yourself (and other looking at the code) by hinting the uses of various things by choosing meaningful names.

Your mileage may vary

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).

1) Use a MVC framework – it’s an industry accepted standard.
MVC as an idea may be accepted, but there are many ways of implementing the MVC – even with the various PHP frameworks. If you know the MVC pattern it may be an idea to look at the frameworks supporting it, but don’t get carried away.

  • If all your old code is non-MVC code and you don’t have any plans to MVC-refactor it, it may cause you maintenance overhead to try a completely different style  on a single project/web application.
  • If you aren’t used to using a (MVC) framework you need to invest time in learning it.

Do keep an eye on the overhead caused by the framework. If you web application has a heavy load and the framework causes 5-10% overhead, it may a bad idea.

2) Ajax Frameworks
Great idea.. but to utilize the power of an ajax framework, you need to learn how to use it. Also Ajax isn’t the holy grail of the internet. Sometimes it’s cleaver to use it, other times it isn’t. By using plain old HTML and reloading the page from time to time, it may be easier to debug the application.

Do also notice, that writing great/professional quality Javascript often requires just as great skills as writing professional PHP.

3) IDEs
An IDE – Integrated Development Environment – can be a great idea if you know your way around it, and use it regularly. An IDE is – like any other tool – something you need to invest time and resources into, if you want something back – and especially if we’re talking a beast like Eclipse-based tools.

4) Database creation/management software
Let me skip comments on database creating management tools. I’ve never really used them and don’t know if they’re a pain or a benefit. I have often seen though, that too easy access to the database, leads to sloppy database design (or at least something, that isn’t thought through).

So far it’s been my experience, that people who knows the command-line clients to databases, often has invested much more time in thinking their data models through and often spend a little more time considering the table layout, the field definitions, indexes and other important aspects, than those who use a nice graphical interface.

5) Object Relational Mapping
Object-Oriented programming isn’t a holy grail, and most people doing OO programming (in my experience) doesn’t genuinely do object-oriented programming – instead they use the OO-facilities in the language to slap functions together in a class.

There’s nothing wrong with procedural programming as such, and trying to force object-orientation into your code – and even abstracting it away through Object-relational mapping, has often lead to slow performance and odd database designs. If you know what you’re doing great, but there’s no free lunch, and trying to utilze ORM without having a pretty solid grip on what’s happening and why, rarely does anything good to your productivity.

I’m quite sure for some developers, using some sort of object-relational mapping might be a gain in programmer productivity, but do keep in mind, that if you’re developing a site with massive traffic, the programmer gains may easily be crushed in added server resource requirements – spending a few minutes extra optimizing and tuning applications, may in some cases save hours and hours of cpu cycles once the solution is deployed.

Getting back to the article, I’m sure the advise is well-meant and thought through by the author, but do always – as with all advise – think it through and see how may apply to your adoptation. In may daily development some of it is quite terrible (as I often work on a site with thousands if not millions of pageviews every week).

I’m wondering what my 5 tips would be for developing PHP applications fast would be. Check back in a few days, and there may be an answer – which may or may not – apply to you.

How do you know good code?

One of the great challenges of PHP is that it’s so easy to learn, that just about anyone can learn it with not too much of an effort. While this is great for the number of PHP developers, it also seems to have the effect, that there is a huge number of bad examples of code out there. How do you then know good code?
In my book there are a few signs, which you could judge from – and they may even apply broader than just php-code.

First sign: It does the job

The code should be designed for the challenge at hand. Too often developers seem to apply the same style and energy to solve a challenge – no matter how much they differ in complexity and importance. If it’s a simple little function being developed, it shouldn’t require a huge framework.

If it deals with financial or personal data, it should probably utilize transactions and apply logging. Did the developer think of the challenge they set out to solve? – if so it’s a good sign.

Second sign: Well-structed

How does the sourcecode look? Are there mile long lines of code or are they sanely formatted? Is the code broken into functions, classes or another structure – or is it just page after page of sourcecode? – I don’t need to see all code as classes nor as neat function-libraries, but I do like if the developer has made an effort to break an application into some manageable pieces somehow.

Third sign: Reasonable naming scheme and comments

How does the function names, classnames and variable names look? is it random garbage or does it make sense? – I really hate variables named from $a to $z – and I do hate functions named “doSomething” – without specifying it further. I would expect great code to utilize the same naming conventions (CamelCaseing, underscores and so on) across all functions and/or variables.

If strange – as in unnatural/unexpected – things happen in the source code, I would expect a (short) comment explaining what’s going on.

Fourth sign: Security and Contingency

Did the developer think about security? is the code wide open for xss attacks? is input validated? Is “the unexpected” handled gracefully or does the code explode if exposed to simple URL-manipulation? Do you know what a SQL-injection is? If you need data from another source, what happens if it isn’t available? – does the code blow up or does it burn gracefully?

How do you recognize good code?

IP address conversion with Perl

With Perl you can do many interesting transformations of IP-numbers. Below is two small examples allowing conversions from “IP quad” (
format to a single decimal and back. The decimal format may be more convenient and efficient to store in a database.

  sub ip2dec ($) {
    return unpack N => pack CCCC => split /\./ => shift;

  sub dec2ip ($) {
    return join '.' => map { ($_[0] >> 8*(3-$_)) % 256 } 0 .. 3;

In CPAN you can find many modules aimed at using and manipulating IP-addressees.

Some include Net::IP and IP::Country.

Cracking the Cryptext with PHP

In the book the DaVinci code there’s a fun little device called a “Cryptex”. It a container for a secret message, and to open it, you need to align some dials to the correct position. In an quiz somewhere you were invited to crack such a cryptext consisting of 6 dials with 6 letters on each to find the correct combination, which would spell a word. To find the solution quickly, all you need is PHP.