Community Pick: Many members of our community have endorsed this article.
Editor's Choice: This article has been selected by our editors as an exceptional contribution.

6 Steps to Better Web Programming

I've never met a perfect developer, but I've met several who have taken significant steps towards becoming one! Use the following tips to develop better, faster applications:

Step #1: Write for Lots of Visitors
A common mistake for most developers is to focus so much on making something work that they don't think about how it will work when 100 people hit it all at once. Sometimes 100 simultaneous visitors seems SO far away that developers just figure they'll fix that problem when it comes up. That's the wrong attitude to have - there often is no simple, magic patch to fix the problem. If that's the case and if you're the developer, then you might as well start looking for another job, because you may have just torpedo-ed the whole project.

There's no need to be extreme, either. You don't need to start off with a replica of Google's server farm. As a developer, you just need to plan for a few things. Plan on the application being copied onto another server to split the load, or pieces of the application being served remotely, or even multiple copies of the application running for different customers with separate databases.

A good example from my own experience is thumbnailing. It's extremely easy to write a quick script in PHP that will take a JPEG and resize it by 50% and write out the resulting file. If 100 people are doing it at the same time, you can reasonably expect that the server is going to be really busy. What I did in one of my projects was to write the thumbnailing code so that it was a standalone application. Then, once more and more people used the product, we were able to easily move the thumbnailer application over to another server without rewriting lots of code or worrying about tearing out vital chunks from the main application.

A hundred visitors every second is common for some projects, and some servers see tens of thousands of hits per second. If you get into the good habit of writing code that could be used by 100 people at once without crashing the server, then you'll instantly be far better than most web programmers out there.

Step #2: Become a DBA
Okay, maybe not a FULL database administrator, but knowing the ins and outs of your database is extremely important to getting the best performance out of your applications.

Any good PHP/MySQL developer should:
- Be able to know how to use DESCRIBE and EXPLAIN to analyze tables and their indexes, as well as the queries that are being run.
- Be familiar with the basics of how indexes and keys work.
- Know when to use the different datatypes (example: don't use a TINYINT for an auto-incrementing primary key on a large table).
- Should always try to avoid using the "SELECT * FROM..." query (specify the column names you want instead of the * symbol).

There is a LOT more that can be learned (persistent connections, unsigned vs. signed integers, subqueries vs. joins, dealing with temp tables, etc), and every bit learned will enable you to make the most of every interaction your script has with the database.

Don't fret - learning the basics does not take as long as you might think.

Step #3: Don't Reinvent the Wheel
I frequently see questions on Experts Exchange about how to write certain applications - shopping carts, chat programs, etc... Sometimes there is a valid need to write something from scratch, and sometimes it turns into valuable experience. Usually, if you're a developer, you just want to write it because it sounds like fun. If you are writing something for live, production use, then you should strongly consider finding an existing version of what you're trying to build. Lots of ideas sound simple at the start, but when you start adding in all the security measures, UIs, error handling, unexpected feature requests, etc, that 2-hour project can easily turn into a 200-hour mess.

Step #4: Be Willing to Buy
Sometimes, the "existing version" may be something you have to buy. At that point, you have to weigh your potential time against the cost of the product. Sometimes, your time IS money and $50 up-front could be saving you $5000 in the long run. I've seen some commercial apps sold for under $100 that came with their full source code and a license allowing you to do whatever you want with the code (except sell it as your own).

Step #5: Never Trust Anyone
Cliché, I know, but it's the best advice you can ever take when developing web applications. Sure, most of your intended users probably are not malicious hackers, but security measures are not there to protect you and the server from all of the nice people. It only takes one successful hacker to bring on the world's biggest headache. If your application is small, then the security breach might just result in your web site being defaced. If you're storing sensitive data, like credit cards, then one break-in could result in identity theft for thousands of people, and a PR nightmare.

Learn to write your applications so that you expect the majority of your users are going to try to be searching for security holes. Cross-site scripting (XSS) and SQL injection are some of the most common attacks nowadays, and they can be mostly prevented by filtering your data (e.g. strip out < and > characters out of fields that should contain someone's name), and escaping the data going into your queries. I also frequently see applications that allow files to be uploaded without any restrictions on the file extensions. This means I can write my own PHP script, upload it, and run it on your server! Easy to overlook, and extremely dangerous.

There are some tools like ParosProxy (good, free) and Burp Professional Suite (better, but not free) that will scan your site for vulnerabilities and give you reports. Never release a web application without running a vulnerability scan on it first.

Step #6: Learn How to Debug Better
It still surprises me how many people do not have good debugging skills. They rely solely on error messages, and when those aren't helpful or don't even show up, they are lost. To debug better, you should start by thinking about your program as if it were a car going from point A to point Z. I'll use PHP scripts as an example again.

If the car starts at point A but never reaches point Z and you don't know where it stopped, then you need to go looking for it. The easiest start is to go halfway into the program, to point M, and then put up a line of code that will notify you somehow if the car passes by. Here is where things like print(), file_put_contents(), and mail() become your best friends (if you HAVE to debug a live application, then use file_put_contents() or mail() to avoid debugging information being shown to real visitors). I will frequently put in something like:
and copy it and put it in several key locations throughout the code, and then run the application once. When it stops, I open up the mydebugging.log file and I can see how the car progressed through the script - which points/lines it touched, and approximately where it stopped. Add in a few more debugging lines in that approximate area and continue the cycle until you've identified the exact point where the program stops.

Often times, that's enough to tell you WHY the program stopped at that point and how it got there. Sometimes that's not enough, which is when I pull out print_r(), which dumps the contents of any variable (array, string, whatever). Since variables often are responsible for WHY a program goes one way and not the other, it's important to see their contents before and after the decision in question. Again, using file_put_contents() in different parts of the application can let you see how a variable was created, changed, etc...

As long as you use those two basic techniques correctly, debugging should become an easy task. Still time-consuming, but easy.

There are tools for almost every programming language, including PHP, which will give you more debugging capabilities (breakpoints, watches, etc). If you can get these tools and use them, then you'll have an even easier time. However, the techniques described above should be applicable to debugging almost any type of language, so learn them well.

Copyright ¬© 2009 - Jonathan Hilgeman. All Rights Reserved. 

Comments (1)

Marco GasiFreelancer
Top Expert 2010

Very interesting. I wish now ask for a clarifying, if it's possible, of course. You say:

"Plan on the application being copied onto another server to split the load, or pieces of the application being served remotely, or even multiple copies of the application running for different customers with separate databases."

Leave the third option, which seems to require more coding; the second one, I think, means I have to put different pieces of my site/application in different servers and load from there. But the first one option I really don't understand what it menas. Can you explain me better? I'lll be grateful for this :-)


Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.