Archive for July, 2009

Zend MVC plus Smarty

Tuesday, July 21st, 2009

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

Wednesday, July 15th, 2009

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

Wednesday, July 1st, 2009

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:

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 😉