May 23rd, 2010 - 1:59 pm
This weekend I finally found the time and motivation to do something that I probably should have done a couple of years ago, I started moving my sites away from Media Temple’s Grid Server. If you’re reading this post then i guess the migration to my shiny new Linode VPS has been successful. I was very tempted to write an in-depth discussion of why I have left Media Temple and why i chose Linode. I decided not to for a few reasons:
- This could just be my opinion – feel free to do your own research though
- Media Temple are likely to be too busy schmoozing at industry parties to care
- Its sunny outside and i can smell BBQ
- I’ve already exhausted too many hours trying to make my Grid Server usable, i don’t intend to waste any more of my time even thinking about them
- I’m a geek with a shiny new toy that doesn’t suck, i intend to play with it now
May 2nd, 2010 - 7:18 pm
I’ve just been through setting up Zend Framework on my Grid Server from Media Temple for the first time. There’s a few gotchas in there so i thought i’d share my experiences so hopefully that will save headaches for others in the future.
First things first, you will need to grab an up-to-date version of Zend Framework for your account. I plan to use Zend for a number of sites so i’ll create a folder in my home directory and call it Zend. Since i might want to switch between different versions of Zend i’m going to check out the folder into its tagged directory so from within the Zend folder i’ll run this command:
svn export http://framework.zend.com/svn/framework/standard/tags/release-1.10.4/
You can then reference Zend for each site by creating a symbolic link, e.g. from within /domains/domain.com/library run
ln -s ~/Zend/release-1.10.4/library/Zend
Now then, at this stage this is all fairly obvious and will match your Zend setup on most server configurations. What makes Grid Server a special case is the fact that it still runs in PHP 4 by default. If you were to run
php --version
from within the shell you will likely see PHP running 4.4.8 for CLI. This is lame for a number of reasons, specifically though for Zend Framework. Zend uses PHP5 specific syntax so when you first setup Zend_Tool you will run into your first major issue. If you have followed the instructions of the Zend site you will likely have created an alias so that “zf” points to your zf.sh file*, something like this:
alias zf='~/Zend/release-1.10.4/bin/zf.sh'
However, if you run that command you will get
Parse error: syntax error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or '}'
which is basically the “you’re using PHP4″ error. Annoying, but actually simple to fix. Open up zf.sh in vi and you’ll see a block of code that looks like this:
if test "@php_bin@" != '@'php_bin'@'; then
PHP_BIN="@php_bin@"
elif command -v php 1>/dev/null 2>/dev/null; then
PHP_BIN=`command -v php`
else
PHP_BIN=php
fi
Basically this block of code uses a number of methods to locate where PHP is installed. We don’t need it to do this hard work though, we know where it is and we need to define which version we want it to use. So, simply at the end of this block or in place of the entire block we can add this line:
PHP_BIN=/usr/bin/php5
Simple as that, Zend_Tool will now use the PHP5 executable for all the command line goodness. From here on in, its up to you. Happy coding.
* There’s no point adding all these handy little aliases if you’re going to lose them each time your shell session ends. I would usually add my aliases to the .bashrc file but since this file isnt used on Grid Server then you instead need to place them in your .bash_profile file located in your home directory. For example:
alias ll='ls -la'
alias zf='~/Zend/release-1.10.4/bin/zf.sh'
March 3rd, 2010 - 1:26 am
Its a sad fact that for many developers your day to day work will involve dealing with legacy code and, invariably, this code sucks. It can be global variables, lack of documentation, code without test coverage or all of the above and more. We’ve probably all been angered by it, cursing the developers we inherited the code from. How then can you make sure that your coding legacy is a stable one and not a ticking timebomb?.
If we are to contemplate creating a stable legacy then its worth considering for a moment what it means to inherit a problematic codebase. There are a number of very professional approaches to handling an inherited codebase. Rowan Merewood presented his ideas on the subject recently at PHPBenelux (slides here). He has some solid ideas about dealing with the legacy of inherited code or poorly documented code. He also introduces the fact that all code we write is future legacy code in waiting. That being said, you need to start making sure your legacy will be a good one.
I was once told to comment my code like my coding peers were psychopaths with OCD-like interest in good code and bad anger management skills. This is a good starting point. Following a coding standard is probably one of the next things you should choose to adopt. Developers are often very adaptable people,adept in multiple languages, but we have a massive dislike for inconsistency. I recently spent almost an hour updating a 3rd party library to follow a strict camelcasing pattern in variable names, the lack of consistency made me feel uneasy. Because the code followed no formalised pattern it had become fractured, incosistent and harder to follow. A good example of a recognised standard is the Zend Framework Coding Standard for PHP. According to the documentation the standard helps to “…ensure that the code is high quality, has fewer bugs, and can be easily maintained”. It will also keep the developers than inherit your code happier. Legacy++.
The benefits of a coding standard do not stop there. Another powerful tool in the toolset for a PHP developer is PHP_CodeSniffer, a tool designed to detect violations of a defined set of coding standards. In the way it is possible to “validate” HTML against a specific Doctype Declaration it is also possible to validate the syntax of your PHP against a defined rulebase. The ability to enforce coding style may seem restrictive at first but the longer you follow this kind of regime the more it will become second nature. It will also become a massive tool within your bug detection routines.
Documentation of code, as i touched on before, is likely one of the greatest assets in making your code a positive legacy. It’s can also be directly linked to the adoption of a coding style. In the case of phpDocumentor a formalised set of parameters within your code comments are used to allow for the automatic generation of documentation for your project. We all know that good documentation makes developers happy so this is a great start. Most good IDE’s will use this documentation for “hints” as you code, this is invaluable also.
Hopefully, by following these few simple steps you can begin to see the ease by which you can make your coding legacy a better place. These tips are aimed very much at the more beginner programmer because i’m sure that no experienced programmer would ever not follow these principles (cough*). Of course this is only the start as I have not touched on either Unit Testing or Continuous Integration. However, I think we can all learn something by recognising ourselves as the creators of coding legacies. Oh, and be scared of people that inherit your code, if its bad and they’re mental, then you better sleep with one eye open.
* well, I try to most of the time 
further reading:
