A Stitch in Time

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.

View Point on Frameworks

The way humans get computers to do what they want is through “programming” and we program in a “programming language”. In a way, it’s how humans communicate with a computer. When I program, it’s more like talking to a computer than anything else. Talking is what keeps me clothed, fed, and sheltered.

In English, you say whatever you want in any way you want. You can even redefine what words mean. In a programming language you have a similar freedom.

A framework, on the other-hand is a self-imposed method of doing things. In order to do anything within the framework, you must follow these constraints; otherwise, it can’t be done.

Why would anyone voluntarily limit their own freedoms? The answer is collaboration and consistency.

The downside of a framework is the need to remember what these constraints are. The upside of a framework is that through such constraints, you know exactly where a file should be located, how things should be called, where things should be placed and etc. A person who jumps onto the project who is familiar with the same constraints would also instantly know where everything is place, how to place everything, and etc.

When using frameworks, developers should be careful that we don’t over customize the framework. Over customization will cause new developers who know the framework to be unable to find all the things they would need to.

I love frameworks for mid-scale to large scale applications, but I find them unnecessary for simple scripts.

Handling File Storage

When you’re writing a massive application, if given a choice to use a file manager to manage files or to allow the application to manage the files on its own, it’s much preferable that allow the application to handle the file placement logic. This way, the application’s database can be put in charge of maintaining the file locations ensuring that there are no conflicts and that there is a centralized location to find everything. When an application is maintaining the files, there isn’t even a need for a descriptive name to a file, since all relevance will be maintained by the database. Since you’re only interacting with the files through the application, the application can ensure that the file exists, the file won’t be overwritten, and upon deletion, there are no dependencies on this file.

In the case of major applications, where it’s possible for many components to have access to the same files, I recommend that all these interactions be performed through a centralized file management core. This way, if we were to change the file management logic, it can be easily performed at a single location.

Data Inside a Database

Data inside a database should always be post-processed and ready-to-use-as-is. If you can rely on the data provided by the database to be usable as is, then you’ll save yourself a lot of string processing work. Think about it this way, if you have a string, let say “orange” and it’s stored in the database, and you had another string called “apple”, along with other fruit based strings stored in the database. When you do a search for these fruits, you can specify a where condition and then the fruit the name. Even with for usage, you can use the fruit name as is. Whereas if these strings had all these weird characters in it, “orange\’s” and “@pples”, then the where statement will no longer be as effective. Not only that, during run-time, you’ll have to have code to handle these weird characters appropriately. So if you’re ever inserting data into the database save yourself some problems in the future by ensuring that the strings are properly processed.

Feature Gathering

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.

Zend MVC plus Smarty

I’ve been playing with both Smarty and MVC. I can’t help but feel that having both Smarty and MVC is a bit redundant. Smarty was developed so that people with little to no programming experience can be involved in the designing process through the use of templates. MVC is known as Model, View, and Controller. The whole point of the system is to separate the components behind a major web application such that people with different backgrounds can come together and build an application. The model contains the business logic; it is the layer that accesses the database and prepares the data. The controller is the component that handles the parameters and figure out what kind of data it needs and where which views to render in order to achieve the result desired. The view is the component that contains the design for the application. It’s designed in such a way that even a person with no programming experience can code and develop.

It seems in that regard, Smarty and MVC are achieving the same thing. I know caching is a big benefit provided by Smarty, but you’ll find that most MVC frameworks have caching solutions as well.

The model I was coding employed the Table Data Gateway pattern, the resulting object was then feed into the Zend Paginator object, which is then supposed to be fed into a view. The object takes care of every aspect of pagination. Smarty also has a means of paginating, but it then in order for it to perform pagination, requires SQL statements thereby bypassing the model layer. Even if you attempt to pass the Zend Paginator object directly into Smarty, the iterator for the Zend Paginator is completely useless due to Smarty’s insistence on using arrays instead of objects. Although it’s possible that more recent versions of Smarty might’ve corrected this error, but this is one programmer who would have rather worked with Zend MVC instead of Smarty plus Zend MVC.

Get Your Hot Swapping On

There are many ways in which code is rolled out.  I’ve noticed in the new environment I’m in, code roll outs are performed more in a “hot swap” fashion than an install / overwrite fashion. In an overwrite manner, code has been throughly tested in a dev and staging environment before being rolled out to live. Whereas in a hotswap environment, staging is on live, except in a different directory. When it’s time to implement the changes, the directories are merely moved around. I thought this concept is interesting because sometimes, even the staging environment, might not be a perfect replica of the live environment, and this “hot swap” can be an additional test on the code before it becomes live.

Finding Problematic Code with Top and Mod Status

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 😉

Unwritten Rules of Professional Web Applications

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

  • There should be no single point of failure
  • The site should never be sluggish
  • The site should never show any errors
  • If the site is not available there needs to be a maintenance message
  • It needs to employ recent and update to date technologies
  • It should be easily maintainable
  • It should be easily expanded
  • Cross-browser compatibility
  • It should be well documented
  • It should be have an underlying coding convention
  • It should be user-friendly
  • Website layout and design needs to be consistent

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

    Back on Top

    If you searched for my full name in Google for the past 3 weeks or so, you might have noticed that my site completely disappeared from the famous search engine. The reason it disappeared was probably due to my domain expiring and parked, but after 3 weeks of checking and waiting, it appears my site is once again, back on top. There’s a certain about of pride we web-programmers have in regards to our stuff being on top. I shall enjoy it while it lasts.