Archive for October, 2010

Thoughts on Zend Framework

Thursday, October 21st, 2010

Well I’ve jumped into the Zend Framework development… finally!

At first glance it looks like a mess, create the environment, separate models, views and controllers, configure the app, the bootstrap…. When I started working here (my current job, which I can’t give the name due to the terms of my job contract) I was hired because of my knowledge of PHP. Business owners stated that they needed a high profile PHP programmer. They said they were moving towards PHP development under Zend Framwork. Cool! a new learning experience.

I must say that when I got here I wasn’t familiar with ZF so it was a whole new experience. Days went by, and anfter a couple of months I have realized what is Zend Framework and why everybody thinks it’s too complicated. There is a big confusion even from Zend.

The confusion begins from the ZF tutorial. They start explaining you about MVC… here’s the whole confusion.

Zend Framework is a set of libraries that can help you with RAD, it has nothing to do woth MVC paradigm.

MVC is a coding paradigm, such as the three layers paradigm. You can code your whole application in whatever paradigm you wish and still use Zend Framework, but Zend treats both the paradigm and the set of libraries as the same. I’m not arguing that something is wrong, what I’m saying is that Zend Framework is one thing and MVC coding paradigm is a whole different one.

Do not be confused! MVC & ZF are a great, neat way of doing things but, as every technology, you should evaluate if both are needed for every project. If you are coding a simple web service then you might not need to use MVC but still use the framework to RAD.

Do a little research, clarify your needs and make the perfect choice for the case you’re dealing. Sometimes MVC can create a lot of garbage folders and files that wont be used at the end of the day.

Remember: KISS (Keep It Simple, Stupid)

Code maintenance

Wednesday, October 20th, 2010

Keeping track of code through time is a very delicate task.

It gets to be a really important issue when customers are making usability tests to a program. You make some changes, the customer reviews them, approves and you send them to production, a couple of days later the customer changes his mind and ask you to go back to how the program looked 3 months ago.

That scenario gets to be very common in web development and can be a serious problem if you don’t give your customer what he wants. How could you go back to a 3 months old version of a page? Did you backed up your files? Is your presentation layer different from the logic one? What has changed since then? How can I merge those changes?

Changes are part of software life, so they must be documented properly. Changes documentation should answer the following:

Who made the change? If something goes wrong you may identify who made what and the settle responsabilities.

What changes were made? You should keep track of what files were affected, what code lines were modified and what was changed in the logic.

When were those changes made? You’ll keep track of time invested on that change.

Why? Was it because of a user request?, a bug fix?, an enhancement?

If you work for a company answering these questions will prove to be a great way to justify your work. It will even make it easier for your colleagues to keep up with your coding style and logic.

Most developers use inline comments to document changes for example:

/**

* author: Me

* date: October 25th 2009

* version: 1.0.1

* summary: User asked for the color to be changed from red to blue so the code changed from $color = “red”; to current

*/

$color = “blue”;

That’s a nice way to keep track of changes but you’ll get to the point that one change requires a lot of file content modifications, folder creations, code logic changes, etc. which on large projects can be a real hell to keep track of. This just happened recently on my job.

We solved a lot of things by using a version control software. We tested it and finally decided to go for SVN or subversion. It’s pretty easy.

Even though projects creation and repositories administration were a mess at the begining because we wanted to limit access to developer groups only to their assigned projects. We kept SVN and installed USVN on  top of it…. needles to say we are very very happy with the results.

We get to admin our repositories in a very simple way. Since USVN is developed in PHP Zend Framework and you get to modify the code we have made some customizations to it so it works as we want it to work.

One great thing we managed to do with SVN is have a strict control over our stage environment. Developers do a SVN commit which immediately updates a stage environment so changes are visible to QA.  Once QA approves a version we create a tag meaning its a new release which then goes to production.

That’s the main reason I’m posting this, I was the one responsible for implementing those automations and they do work.

How did I do this? Well it’s actually pretty simple. Once a SVN project is created you go into that project’s folder and go to the hooks subfolder. This is where the magic happens.

Though there are several types of hooks I only messed with the post-commit hook.

I granted execution permissions to post-commit file (remove the “.tmpl” part).

Modified the hook so its aware of some important paths and then coded a few lines so, for example, we got SVN to send an email reporting what changed, who did the changes and when was the code commited to project owner so he could keep track of his project.

SVN works for us right now and hooks are a charm. I’m pleased right now and so are my boss and my colleagues :D:D:D:D

I keep repeating to myself: Linux rocks, free software rocks and most of all I rock! hahahahahaha