Site Redevelopment

I’ve been doing this web thing since 1994 – you’d think I’d have gotten the hang of it by now. I’ve made a career out of it, having long since left the lucrative position of late-night radio DJ without looking back. They say that the cobbler’s son never has any shoes. Likewise, I have never, in my entire web career, had a decent web site of my own. I’m now working to redevelop my own web site using everything I’ve learned in the last 13 years about general design and development principles. These are some more-or-less random notes as I go along.

There are a few things I’ve learned. One is that no matter how much I work on the backend, coding and re-coding until I am satisfied that my code is the cleanest, most efficient, most reusable machine I can possibly build, no one else will care unless the site looks good and/or I have something to say. Oh well.

I’ve got a pretty decent-looking site right now: http://www.genghishack.com. But it’s boring. Yes, there’s a picture of me holding baby Hannah, but I might as well have an “under construction” gif (shudder) on the front page. I like the background colors, but what I’m really concerned with is how the backend framework is organized. This site is built on a set of files that I wrote intending to use as a template to stamp out other people’s sites – and have, several times. The code keeps evolving. It’s not terribly complex, but it’s an expression of clean design principles and proper separation of the various forms of functionality and presentation.

(One thing I’ve also learned is that I have ADD. Which means that I hardly ever finish anything in my personal life that I start. I’m working on that also. As you can see, I’m easily distracted by random thoughts. And bunnies.)

Back to the site. Right now, I’m working on the configuration file, where I set the constants and string variables that will be used throughout the entire site. This is my key to reusability and portability: make sure that there is only one place where you have to change your files’ path names. One. Everywhere in the code that you refer to a path or a URL to a file that is part of your site, begin the reference with the constant that refers to that location. Never, ever hard-code a path or URL. Don’t even use relative paths. Make the paths absolute and make them all begin with something like $PATH_FILES or some such. That way, you can move your directories around if you happen to find a different directory structure works better for you, or rename or replace your directories with ease.

I’m finding this holds true for path names, urls, and database table names. Data tables can and will change their names every time the code is re-used. They need to be abstracted, just like the user, pass, location, name and port of the database.

Which brings me to naming conventions. Another principle I incorporate into my code is that of clearly worded, understandable variable names. I find it best to put the function of the variable first and the name second, such as $TABLE_USER, $URL_IMAGES, $PATH_INCLUDES and so forth. I’m going to wind up with several of each type, and I like to be able to scan the code and see exactly what type I’m dealing with where. The capital letters for these types of variables are because I’m naming them as both constants and variables – for each one, I declare a constant (to be referred to as PATH_INCLUDES, for example) and then declare an equivalent string variable ($PATH_INCLUDES = PATH_INCLUDES). There are instances in which it’s appropriate and convenient to use one over the other. I like to have both available.

When I’m writing layouts, I use here-doc notation a lot. I tend to prefer this type of notation to templates, though that may change in the future. The point is that when I’m writing HTML, I use a lot of inline variables. The variable versions of the constants are very useful at times like these, because I don’t want to break out of my here-doc string to include a constant. I haven’t found a way to include those inside of a here-doc string, not even using {}. The constants are useful in other parts of the code. So, part of the function of the configuration file is to set them both.

I’m also learning to sanitize my user inputs. I never used to know anything about security vulnerabilities such as SQL injection attacks (which can cause you to lose large amounts of data, among other things), but am becoming wiser. Rather than the old database abstraction layers I used to use, which in themselves were a step, much earlier in my career, away from hard-coded MySQL or Oracle commands, I’ve switched entirely to using PEAR’s DB class and parameterizing all of my queries. It makes sense. Here is a cartoon that perfectly illustrates the dangers of SQL injection.