When I sat down to write this blog, I only intended for it to be rather short. But then it grew, and grew… and grew. I’ve actually started and stopped writing this blog several times. And as an aside, I took this opportunity to comment on my education at RIT, and how it has prepared me for my current job.

Since I’ve been graduated and at Partners and Napier, I’ve realized several things about the field that I’m in. The most prominent is that a web developer wears many hats: software developer, systems analyst, technology expert, and ensurer of usability, to name a few.

how well did RIT prepare me?

Overall, my Information Technology education at RIT has taught me well in all of these areas. But, I do feel that the “web developer” concentration lacks in a few fundamental ways. The first, is that it is merely a “concentration.” I don’t think that quite does it justice, as concentrations within the IT major only account for 2-3 specific courses. To me, the web development concentration (and most of the others) should be separate lines of education within GCCIS; much how ANSI is. There is just too much extra material to cover in a few courses to become a student specialized in these areas. But, I realize this is much easier said, than done.

My second comment about the web development concentration, is that it does not teach the fundamental code management practices that will be necessary for maintaining large and complex websites. Nor does it place emphasis on what the title of this blog is: the fact that web development is very much akin to software development.

and on with the show

Make no mistake: When you’re talking about web development, you’re talking about software development, and then some. There are several major points I am going to make in this blog:

1. We know more than HTML, and HTML is not programming.
2. A web developer should be as competent a programmer as a computer science major or software engineer.
3. We should have extensive knowledge of web technologies, and the impacts of application development on the web.
4. Web developers must be highly versed in systems analysis and design.

Wow. So I just made a crapload of assertions. Let’s look at them each.

1. We write more than HTML

Let’s dispel that notion right now. In fact, a web developer is far more than a kid who can simply write HTML. A web developer, in the proper sense, can oversee the creation of a site from initial art concepts, to technical implementation, to QA testing and client acceptance, to final production launch. We can make GUI decisions, design the database, and architect the code. Knowing the markup language HTML is only a fraction of a web developer’s skills, and most will know more than one programming language.

2. A web developer should be as competent a programmer as a computer science major or software engineer

Why? Since I just dispelled the notion that we’re only capable of HTML, let’s also dispel the notion that a web developer is either a lousy programmer, or simply can’t program at all.

true web developers must be able to program in an object-oriented paradigm

Web applications require just as much thought, planning, and architecture as any other aspect of software development. Because of this, writing quality and robust code is essential. What good is your code if other developers can’t understand it, or extend it? Not only that, but writing applications that interact with a database is a regular process for a web developer. The PHP engine, for example, is extremely robust and very fast at run-time. Yet, this is not an excuse for sloppy or inefficient code.

version control is a must

Web developers must properly use version control, and this is another aspect of software development. Take the following scenario:

You have just launched a site. Let’s call it Sally’s Cookware. You’ve done all your QA and bug testing, the client approved it, and so you launched to the live server. Scheduled in a month, is the launch of a 2nd version of this site, including many more features.

Two weeks later, you’re happily well into development of the 2nd iteration of Sally’s Cookware. Suddenly, your project manager blasts into your office; Sally’s Cookware has a serious bug. There’s an error in the tax calculation under certain circumstances, and thousands of customers are being under-charged on taxes. This needs to be fixed NOW.

But, oh wait, you’re not using version control. In fact, you haven’t got a clue what it means. In this situation, you’re screwed (rather hard). Your current code is two weeks into development; it’s still buggy, untested, and unfinished. How are you supposed to stop what you’re doing, revert to the original code as it was at launch, fix the bug, and then continue development on the 2nd iteration? Well you could, if you had version control.

At RIT, this is something that’s taught in Software Engineering, but not in web development. Why? While you’d think that IT’s Web Site Design and Implementation course would teach these important aspects, it does not. RIT’s Information Technology department, and the web development concentration, lack these vital teachings.

The solution to my above scenario is to use a version control system like Subversion for web development. When using a tool like this, we can save and put aside our current two weeks worth of work, revert to the original launch state, fix the bug, deploy it to the live site, and then continue working on the 2nd installment of the site. Being able to do this, however, requires the same code management practices that software developers learn.

Delving further into the specifics of using version control with web development is beyond the scope I intended for this blog. But here’s an awesome article about it, conveniently titled: Using SVN for Web Development. If you’re still interested, there’s a great book titled Pragmatic Version Control using Subversion. It isn’t a typical dry or boring read (the Pragmatic line of books are good like that), and I actually read through the whole thing in about 4 hours.

3. Extensive knowledge of web technologies, and the impacts of application development on the web

As web developers, we are often uniquely responsible for not only server-side programming, but also for client-side programming. This means ensuring that our interfaces and layouts work for everyone. Regardless of browser, operating system, screen resolution, or the weather outside. We have to test it in many configurations, and ensure that it works just as well for Joan and her Mac as it does for Bob and his PC. This is not unlike the fact that software developers must ensure that their applications run on computers with an infinite number of system and hardware configurations (unless you’re Apple). What happens if the user doesn’t have Flash installed, or JavaScript enabled? Is our application prepared to gracefully handle those situations?

always something new

On top of being aware of all the current caveats of client-side front-end development, there is always something new out there. Some new technological acronym like AJAX or CRACKER-JAX is always on the horizon. And it’s our job to stay abreast of these new fads. Sometimes fads become trends, and trends end up becoming a new de-facto standard. We must decide which to follow, and which to not. Wrong decisions can cost money.

4. Web developers must be highly versed in systems analysis and design

Starting with requirements gathering, to concept, to architecture, to database design, to coding, to usability testing, we need to be capable of it all.

Why can a developer make GUI decisions, and why would we participate in the design process of a website? Because the artists may design something that is too technically difficult to implement in the time or budget allotted. Often by making simple adjustments, time and money can be saved during the programming phase of the site. It’s not my job to drive the creative direction for the site, no more than it is for the artists to program the site. Yet, a developer’s input is critical during the design stages. We must ensure the design is technically feasible, and we do this by working in synergy with the art team.

The notion that a web developer is involved from start to finish helps keep projects on time, and on budget.

in conclusion…

Web development is a unique beast. It requires expertise from a lot of different areas, and it is always changing. It’s for those two reasons that I enjoy it so much.

Make no mistake: When you’re talking about web development, you’re talking about software development, and then some. My boss and director of the Interactive group I’m a part of at P+N agrees that “web development is software development.”

I’ve been working on a pretty big blog. That’s a part of it. Every day I’m at P+N, I realize that a true (and successful) web developer must also be a software developer.

Why? Well, I’m currently working on a Google-like search capability for a client’s site, except it has to search a database of client-uploaded documents. It has to:

• Be a weighted search. Meaning “microsoft software” returns different results than “software microsoft”, because the order of the terms determines their weight.
• Ignore noise words such as “and, but, the, a, in, or, for” etc.
• Sort the results on some kind of scoring; more relevant results must be at the top. Meaning, a scale of relevancy has to be dynamically determined based on the returned result set of the search. 10 results needs a different relevancy approach than 1,000 results.
• Understand expressions, like Google does. Meaning “this phrase” denotes an exact phrase, the + sign indicates a required term, and the - sign indicates a term that should not be in the results, anywhere.

Add to this, the search must include document metadata; which involves the joining of 10 tables or so. Yes… it’s rather insane… And I wouldn’t be prepared for it without my advanced DB classes from RIT.

But… more on all this soon. Just once I have the time to finish the actual blog…

What a ridiculous title. But it’s a clever play on words, because I’m damn clever.

Writing code is one thing. But writing bad code, that’s an entirely different cake. And not the good cake, either. Writing bad PHP is like having that third piece of cake; it’s so easy to do, yet so easy to avoid, and oh so painful later on. In fact, you’ll probably regret it. I know I always do (on both accounts).

The following is a great way to debug your scripts:

mysql_connect('stop', 'eating', 'cake')
or die ( "Error: " . mysql_error() );

But there are several flaws in this. That’s why it’s for debugging. Not production level code.

• It violates one of the cardinal rules of usability: Graceful errors. Do you think your users want to see some garbled error puked at them? Of course not. They should be reassured that an administrator, like for instance, you, has been informed of the error, and the situation shall be resolved promptly. The situation, is under control. The results of a mysql_error() don’t benefit anyone other than you. And that’s a whole lot of no one.
• It reveals information about your server that is potentially a security risk. Often times these errors throw back table names, database names, database usernames, and your full server path. Why would you want people knowing this? If you did, you’d just publish this information publicly, on your MySpace page. But you don’t. So why should you let your errors get out of control? You need to leash them, like children.

taming your MySQL errors

There are several ways to go about this. For one, instead of calling mysql_error(), you can call a custom function. That function then makes a decision about either outputting the entire mysql_error() text, or a short user-friendly error. The function would know which to do, as an example, based on a constant you define in a global config file. This is similar to how phpBB handles their errors; in the admin panel you can elect to output either user-friendly errors, or the god-awful PHP errors in their entirety. Enable full errors while you’re still working on the script, and disable them once you’re at production level.

but that’s not enough

Most of the time, PHP likes to throw errors at you anyways. If you have a connection error, the code below will still display an ugly unfriendly line:

mysql_connect('stop', 'eating', 'cake') or die ( "Error: " . foo() );

The reason for this is because if un-dealt with, mysql_connect() itself will generate a PHP warning and send it to the browser. These warnings can however be suppressed with the @ symbol. For example:

@mysql_connect('stop', 'eating', 'cake') or die ( "Error: " . foo() ); 

With the above line, you now completely control what the user sees upon a connection error (since our databases never go down, right?). The @ symbol will ensure that no errors or warnings ever make it to the browser, and thus your users always think the situation is under control. Even though it probably isn’t.

and now you know

So please, for the love of God, control your errors. Make them nice, and pretty. If not for your users, then for the security factors.