Jackson’s Blog

There is an old saying “A stitch in time saves nine.” What it means is that if there is an issue, if you address it early, it’ll take overall less effort than addressing it down the road. This is saying applies not only to stitch, but to programming as well. Employers should be wary of creating an environment where employees are concerned about asking questions. A hostile work environment might cause the worker to avoid any questions that can clarify the task at hand. That can ultimately lead the entire project off course.

That being said, while it’s great to fully trust your employees to do the task you’ve assigned, communication is extremely essential in an organization. If you didn’t communicate your desires clearly, or if your employee didn’t fully understand what you’re saying, that can also lead the project off course. Which is why you should check in with your employee every now and then to see if he has any questions or to get an idea of where the project is at and where it’s going.

If you have the choice to either spend 5 minutes to fix it now or spend 3-4 months fixing it later. Spend the 5 minutes now.

There is an important lesson to be learned from the jQuery versus PrototypeJS battle. While there isn’t really anything wrong with Prototype, jQuery is simply better. Yes, there are some pros and cons to either one, but to me, jQuery was simply better designed. It’s as if, one day, some guy decided to come up with a JavaScript framework to make working with JavaScript a lot faster and easier. That person went out, figured out what the day-to-day of JS developers were, and decided to come up a framework based on that.  While I can easily write an article on PrototypeJS versus jQuery, today’s article is on the importance of feature gathering.

Feature gathering is the process of consulting your clients about their needs and desires before creating your application. I’ve come across a few programs where they’ve developed what they thought the client would like, instead of directly consulting the clients about their exact requirements. There are pros and cons of each method. The con, your client might be annoyed with your lack of initiative. The pro, work flow can be streamlined, the code can be designed around how features might be added, main ability, scalability, and etc. I like doing things, and I like doing things right from the get-go. Of course, if I was a developer who wanted a ton of project time, then I’d develop the most inefficient most unmaintainable system there is to get all the money I can, but I don’t. So I rather create a solid, efficient, and easy to maintain product, and that can only be accomplished if I did a good job at the feature gathering stage.

The first step to fixing a problem is figuring out that there is one. Top is great command to examine what’s going on your system. It can tell you how resource intensive a process is, how long it’s been running, who executed it, and etc. Through Top, you can see if a process like httpd or Apache is taking up a lot of resources, if it is then a script executed via Apache is taking up a lot of resources. The problem with Top is that it doesn’t show you what script were executed via the web and how resource intensive that script is, and it’s not supposed to. Just like Windows’ task manager, it doesn’t make any sense for it to keep track of what files are opened in Excel, that’s Excel’s job.

Good thing for us, Apache is able to keep track of it through an Apache Module known as “mod_status”. Today’s post won’t cover how to install mod_status, what its graph looks like, or how to read it, but it’ll talk about how to use it in conjunction with Top to troubleshoot problematic scripts. This information is readily available on the web, but here’s a link to more info regarding the Apache module: http://httpd.apache.org/docs/2.0/mod/mod_status.html

Top allows us to identify which process is sucking up a lot of resources. Mod status keeps track of web calls and their corresponding PIDs. By look up a problem process in top and then finding that process in mod status, then we can start analyzing and fixing the problem. From that point on, we can start the “blaming” process

While there are many unwritten rules, here are few which I find most significant. To me, these are qualities of any professional web application.

I expect nothing less from any modern day professional web application and applications I develop. The applications I develop might not always fulfill these requirements, but it’s definitely something I strive for each time a line of code pours from these hands of mine.