The SOLID principles are:

• S - Single Responsibility Principle
• O - Open/Closed Principle
• L - Liskov Substitution Principle
• I - Interface Segregation Principle
• D - Dependency Inversion Principle

I’ve found a strong correlation between the SOLID principles and a practice called Object Calisthenics, an idea from Jeff Bay detailed in the book, The ThoughtWorks Anthology. Some of the rules in Object Calisthenics compliment the SOLID principles very well, I will refer to the rules when this is the case. In short, without going in too much detail, here are the 9 rules of Object Calisthenics:

1. Use only one level of indentation per method
2. Don’t use the else keyword
3. Wrap all primitives and strings
4. Use only one dot per line
5. Don’t abbreviate
6. Keep all entities small
7. Don’t use any classes with more than two instance variables
8. Use first-class collections
9. Don’t use any getters/setters/properties

The SOLID principles focus on Dependency Management. I’m sure as developers, we’ve all been victims of projects with poor dependency management - changing code in one part of the system breaks code in another part; Re-using code is difficult or impossible; Classes and methods are huge and often it’s hard to tell what they’re supposed to be doing. The SOLID principles are ways to reduce the likelihood of this of happening. Unlike design patterns which guide you to a solution, the SOLID principles can be used as a guide to prevent problems.

In this article, I will cover the first of the SOLID principles, the Single Responsibility Principle - “A class should have one, and only one, reason to change”. This is basically the same as “cohesion”, or writing classes with “high cohesion”. So, why is this important? If a class has more than one responsibility, there is more than one reason for it to change. This leads to very volatile classes which of course could affect any other classes that depend on it. See also Object Calisthenics, rules 6 and 7.

It is often easy to spot classes that fail this principle as they often contain words like “Manager”, or “Handler”. When implementing SRP, classes become more specific and focussed and the class names reflect the single responsibility of the class, e.g. EmployeePayrolCalculator.

So how do you go about refactoring your code to implement this principle? Begin by implementing the principle in your methods - refactor your methods to 5-7 lines, one block of indentation and a single responsibility per method (see rule 1 and 2 of Object Calisthenics). Once you have refactored your methods, ask yourself how many reasons does your class have to change? If the database schema changes, does it affect your class? And if the business rules change? How about a user interface change? If you establish more than one reason for change, refactor the class into two or more classes until you are happy that all your classes only have one responsibility.

In the next article - The Open Closed Principle.

ZendCon kicked off on 17 October in Santa Clara, California. The surprise of the conference was the announcement of the launch of Zend Developer Cloud during Zend’s CEO Andi Gutmans’ opening keynote speech.

Zend Developer Cloud is a free, cloud based environment for developing and deploying PHP applications. It has tools to quickly set up PHP application stacks, including Zend Framework, Joomla, Drupal and WordPress. It includes a code tracing tool and debugging features. Once the application is ready, it can be deployed to any cloud provider supporting the “Zend Application Fabric”, including Amazon and Rackspace. Zend Developer Cloud also supports the ability to take snapshots of instances at any given time that can be shared with other developers. This could be useful for developer collaboration. It is currently available as a “technology preview release”, you can request an early access key here.

The keynote also featured a live demonstration and one of the tools featured during the demonstration was the new Zend Studio 9 beta. It features tight integration with the Zend Developer Cloud, allowing developers to deploy to the cloud instances from within the IDE. Other noteworthy features include Git and Github support build into the IDE which should make a lot of developers very happy. Emphasis was also placed on how the new IDE can be configured to only include modules that developers need, cutting down a lot of the bulk that is a common complaint with Eclipse IDEs.

During the week before the conference, the beta 1 release of Zend Framework was announced. ZendCon 2011 had several talks detailing the internal workings of the new framework. One of the major changes includes extensive use of dependency injection throughout to make it truly extensible. Most of the framework was rewritten to ensure consistency throughout and to harness the full capabilities of PHP 5.3. The architecture was also simplified greatly by introducing event driven programming to the framework. To find out more about ZF2, have a look at the community wiki. Take note that the API will change while still in Beta.

Aah, the old programming language debate, much akin to comparing religions or political parties – bound to end up in a fist fight. Some will argue that as long as you choose the right tool for the job, it doesn’t matter, but I’ve found it’s always the little things that break the camel’s (or in this case, the programmer’s) back.

I wrote a little Python pet project (mind the pun) this week after years of web development using only PHP. As a matter of fact, my first job was a Python position. Eventually, as I started doing GUI development in Delphi, Python was relegated to odd jobs and hacks. When I started doing PHP development, Python became redundant and eventually my skills became rusty as old nails. Until now.

Even after just one week using Python, I remember why I’ll always prefer it – it empowers me as a programmer. In the Python community, they refer to it as the “batteries included” philosophy – with the mere inclusion of a library, anything becomes possible. Combine that with clean and readable syntax, fluent interfaces, powerful list comprehensions, list slicing, an interactive console, and too many other features to mention, it’s clear to see why.

I’ll illustrate using a Python example (Yes, it’s a bad example):

date = details[1].split("<td>")[1].split("</td>")[0].strip()

This line takes the second element of a list (the Python equivalent of an array) and parses a date string out of an HTML table cell. Whether or not it is advisable to do this is a topic for another day, but it illustrates quite handily how the combination of “everything is an object”, great list operators and string functions makes a hack like this effortless. Here is the equivalent PHP code:

$parts = explode('<td>', $details[1]);
$otherParts = explode('</td>', $parts[1]);
$date = trim($otherParts[0]);

If you’re a PHP developer and haven’t worked with Python before, do yourself a big favour and head over to the Python tutorial or check out any of the multitude of hacks, projects and frameworks written in Python and see how it’s the little things that make programming enjoyable.

Head over to the Cape Town government site and fill in the online form. After a few days they will send you the amount, a reference number and their banking details.

After making the payment, I received my license in the post within a week!

Awesome. Now how about credit card payment facilities, please?

I grabbed my camera and took some rather close-up shots of it hiding behind a cooler box.

Thinking it was a rather harmless mole-snake, I moved the cooler box in an attempt to scare the animal back where it came from, but to my surprise, this rather non-docile snake reared up its hooded head, ready to strike. I have never moved so fast!

Considering my options, I phoned 10111 for some “advice”. The lady on the other end, amidst muted laughter, assured me that the she’ll send the police. Not even 2 minutes later, the police arrived. After a quick search, it turns out the snake had gone into hiding.

Unable to assist any further, the police called in a snake expert to assist.  After tearing up my garage and kitchen, he found it hiding in my kitchen cupboard.

One deadly Cape Cobra, ready to strike.

The snake was stuffed into a bag for transport - hopefully to a place far, far away from me!

This is probably the most common argument against template engines. People often say “but PHP IS a template engine”. Proponents of template engines will then counter argue that the syntax is simpler, but in some cases this is just not true…

We use Smarty in one of our products and in retrospect, we would most likely not have chosen to use it if we had to do it all again. However, based on our requirements and design decisions at the time, it was probably the right choice for then. When we started out, we opted for a MVC architecture where controllers pull data from models and push the data as arrays to the view. The advantage of this approach is that it keeps the templates simple because you’re only ever printing the contents of variables and occasionally looping over a dataset.

As our product evolved and became more complicated, this process became tedious and inefficient. Objects had to be converted to arrays and passed to the view. Sometimes this included a hierarchy of child objects. Then we started implementing lazy loading and iterators, the benefit of which quickly evaporated when we converted all of our objects to arrays.

We decided to instead pass either the model objects to the view or to use view helpers. The view then calls methods on the model or loops over the iterator, preserving the original objects and any lazy loading. All was well again, but of course the views started getting more and more complicated. To refer back to the argument, our templates have now become as complicated as embedded PHP code in HTML would have been. Add of course the additional overhead of the template engine and the cost of learning yet another language and suddenly a template engine doesn’t make an awful lot of sense anymore.

The problem is that requirements, design decisions and technologies all shift and evolve over time. It is not possible to predict where your product will be in 2 years, 5 years or even a few months from now. As software engineers, we try to accommodate change as much as possible by building safeguards into our code. However, at the end of the day, we cannot predict the future so we have to make peace with the fact that continuous re-factoring is as much a fact of life as change itself.

Drizzle is a relatively new project with the aim of producing a lightweight relational database system based on MySQL. From the Drizzle website:

“Drizzle is a community-driven project based on the popular MySQL DBMS that is focused on MySQL’s original goals of ease-of-use, reliability and performance. The Drizzle team is removing non-essential code, refactoring the remaining code, switching to a microkernel architecture (with well-defined APIs) and generally making Drizzle into a lean, mean query-running machine.”
One of the biggest drivers for the lean kernel and quick bootstrapping of Drizzle is to make it an ideal database to use on cloud architectures. It is important to note that due to this, windows compatibility was removed from Drizzle.

It is quickly apparent that creating a stripped down version of MySQL wasn’t their only goal as the system includes a comprehensive plugin architecture. This allows many options for integration.

Pluggable authentication allows you to use plugins to authenticate using something like LDAP or HTTP. A pluggable query filter allows you to block or filter queries before they get executed. With the pluggable query cache (still in development), you could even plug in something like memcache. Even SQL functions are pluggable, allowing you to write custom functions.

Drizzle can be installed using apt-get, RPM’s or can be easily compiled from source. Installation is made even simpler because there is no bootstrap step and no system tables that need to be created.

Starting up Drizzle is simple, with the only required parameter being the data directory: drizzled –datadir=/my/data/path

Plugins can be installed using apt-get and need to be enabled when starting up the daemon, for example: –plugin-add=md5,pbxt

Drizzle is still in alpha and major new changes are introduced on a daily basis, so its not quite ready for your production environment, but it’s certainly worth keeping an eye on this project.

For more information, visit the project wiki.

Taking the organizational reigns this time around, Eli White takes over from Cal Evans who recently moved from Zend to iBuildings. Organization was mostly smooth, with a few minor hiccups – day 1 had a serious lack of power supply, leaving most attendees with dying laptops before lunch. Compounding the problem, no notepads or pens were provided on registration. Attendees who had registered early and received free netbooks reported that the netbooks came with European plugs instead of US ones. However, most of these issues were sorted out by day 2.

The speakers at this year’s ZendCon included some familiar stalwarts – Sebastian Bergmann was back and presented on topics including testing, quality assurance and continuous integration. Accompanying him, was Stefan Priebsch and Arne Blankerts, who together with Sebastian Bergmann makes up the newly formed PHP consulting company, thePHP.cc. Cal Evans was present in the capacity as a speaker and delivered a good presentation on design patterns. Of course, Elizabeth Marie Smith was back and presented on PHP for the desktop using php GTk as well as a talk on SPL

Of all the speakers, two that stood out was Ilia Alshanetsky and Stefan Priebsch. I attended two of Ilia sessions, the first about premature optimization and the second on popular caching tools, APC and Memcache. His rapid delivery style and excellent knowledge crammed an almost overwhelming amount of content into a single one hour slot. Stefan Priebsch joined in on a code review tutorial session with Sebastian Bergmann and Arne Blankerts, but it was only when he presented on OOP best practices when he came into his own. Stefan is an engaging speaker and his OOP knowledge demands a lot of respect.

As usual, Twitter and the ZendCon IRC channel was abuzz with attendees tweeting during the conference and was a great way to keep a finger on the conference’s pulse.

The conference, however, wasn’t without negatives – drinks (soft drinks and coffee) were only served after every 2 talks and physically removed after the break, even though these weren’t refrigerated to begin with. In some instances, I had to leave the conference venue to purchase my own drinks.

This year there was no party or any afterhours activities arranged by the conference or sponsors other than the usual reception – this year sponsored by Adobe.

Regarding the format of the conference, I do feel that there are too many talks and the talks are too short – it is simply not possible (unless your name is Ilia Alshanetsky) to fit any meaningful amount of information into a one hour slot , especially the more advanced topics (which are of course the more interesting ones).

ZendCon 09 ended with a framework shootout – a representative of each of the more popular PHP frameworks were invited to appear in a panel discussion and the audience grilled them with questions. Of course, to liven things up, each panel member was provided with a toy gun. Although not particularly useful, it was highly entertaining and a great way to end the conference with.

For a list of conference speakers, talks, ratings and slides of this year’s ZendCon, check out the ZendCon Joind.in page.

I recently had 2 of my remotes fail within the space  of a month and was off to E.T. Systems to acquire a new one (at a whopping R125 mind you!)

Here’s the simple procedure to sync your new remote to your E.T. Systems garage door:

The E.T. Systems remotes work by implementing some sort of patented rolling code transmitted by the remote and identified by the receiver. Without digging into details, this rolling code necessitates syncing your remote to your garage door.

To start, pop open the plastic cover of your garage door. Next, search for 3 pins labeled “BT LT” (bottom right of the circuit board in this picture):

The idea is to short the pin on the “BT” side with the middle pin - press the button on the remote that you wish to use to open the garage door and at the same time use something metal to “short” the pin labeled “BT” and the middle pin. You should hear a beeping sound which indicates that the operation was successful.

It all started on a windy autumn day when the fascia board on my roof blew off, nearly falling on my poor neighbour’s Uno (which surely would have flattened it :)) On my neighbour’s advice, I decided to claim from my building insurance. So, Tuesday morning 10 AM, I decide to brave the Absa call center and submit my claim…

20 minutes of annoying hold music later and I’m put through to an operator - I submit the claim and they tell me its been forwarded to the Cape Town division, great. Knowing how these things go, I make a note of the Cape Town office’s number and end the call.

By Wednesday afternoon I still hadn’t heard back from those lazy Capetonians, so I decide to do some leg work with my fingers and call them up - “no sir, we’ll submit your claim to a contractor immediately”. “So why haven’t you?” - I wanted to ask.  So I wait in vain with a couple of days of rainy weather threatening to destroy my house even further.

Friday afternoon I get a call from the contractor who assured me in a very Afrikaans accent that Absa takes their insurance very seriousness and he wants to come have a look, right now! After insisting that I’m at work and won’t be able to open up for him, he’s so adamant that I just let him be - hope he has good eyes!

The weekend comes and goes and before I know it, it’s Wednesday again. Give them a call - “No, the person who is dealing with your claim is on leave, I’ll follow up and call you back”. Great.

Friday afternoon arives, and yet again I phone. Now, by this time I’ve had enough of their shoddy service and I was planning on switching to Santam the moment the claim is settled. So to my suprise (or maybe not) they refuse to fix the roof - they claim the workmanship on the fascia board is bad because the builder used nails instead of screws. Hmmm. OK, very irate now. I phone up my good buddy Dann at Santam - apparently they need a specific clause in their policy that specifies that nails used on the facia board is considered bad workmanship, otherwise they have to pay up…

So several phone calls later I’m able to get my hands on the policy wording… I quote from section B: Specific Exceptions: “3. defects in design or construction” - Sounds pretty broad and subjective to me.

So I phone some builders, a structural engineer, the Master Builder’s association and the overwhelming opinion is that nails are more frequently used than screws and doesn’t constitute bad workmanship.

Finally, after several emails, phone calls, and weeks later, the claim is reassessed and a contractor is assigned to fix the roof, success! Of course, not wanting to end up in the same situation again I ask him what they use to attach the Fascia boards… NAILS!! They use F#$%#%@ nails!

In conclusion, it doesn’t pay to be an optimist - insurance companies will and do find any excuse not to pay out a claim leaving it up to the consumer to prove their case. I guess most people just give up and with the amount of trouble I went through with this claim, maybe that would have been the saner option!

I’ll be cancelling my insurance with Absa the moment the roof is fixed and start looking for another bank to finance my home loan.