Code Naked

I was reading an article today on outspokenmedia.com that was written back in April of 2009 and I was pretty impressed with it. I too feel that not only are people using the recession as an excuse for not trying, but also that employers are using it as an excuse to get rid of employees without having anyone put up a fight. "I'm sorry Bob, in this economy we have all had to make cutbacks, as a result we are going to give you 10 minutes to get your stuff together and say goodbye to the job you have had for 5 years." To which Bob replies "I can totally understand, at least you are going to give me my Christmas Bonus before I leave right?" hahaha. Poor little developer, you'd be cute if we weren't embarrassed to look you in the eye.

Lisa Barone goes through a few points that employees and especially contractors should be doing in order to not only stay afloat, but to excel during these crazy times. I feel that I am performing the majority of items that Lisa suggests we do: Learn something new, Work harder than everyone else, Do the leg work, Take risks, and Shut up. I am always learning and I love it so this is not a problem for me. Even now that I am not on a full-time gig I still sit in front of my computer for a minimum of 8 hours a day. Not 8 hours a day watching YouTube, but spent coding. I have written a framework from the ground up using PHP5.3 features such as namespaces, closures/lambdas, __callStatic, and late static binding. I use these features to build next level framework components such as Dependency Injection, Annotations and a Unit of Work maintained ORM layer. A little over 7,000 lines of code in a couple of weeks. I have also tried out what the development work cycle is like with Zend Studio 7.1 and Zend Server CE. I also used those tools to build a brand new Zend Framework application using a modular layout and integrating Doctrine as the ORM layer. Finally I have started to work with GWT and have discovered that it can actually be really fun to work with. There are a few other items that I have been researching and playing with, but long story short, I have used my free time to the max increasing my skill set.

The one thing that I am still sucking at is surrounding myself with fighters. It's hard to surround yourself with anyone when you work from home. I feel that I need to start being more involved in the PHP community and so I have been trying to find a PHP user group in Toronto that I could attend and perhaps speak at. So far, no luck. If any of you know of a group in the GTA please feel free to tell me about it in the comments!

Normally I don't do any sort of Introduction to Object Oriented Programming posts because to be honest, it's been a long time since I read chapter one and thinking in objects comes naturally to me. Today I happened across the Interfaces section of the PHP manual; the examples and comments on that page were so brutal I thought maybe I should do a public service and write something about how to create a clear object model using a couple of rules of thumb.

In my opinion, one of the most misunderstood OOP mechanisms in the PHP world is the Interface. Unfortunately, the manual seems to support my opinion. In the first example we have the class Template implementing the interface iTemplate. What is an iTemplate? The rest of the examples are even worse: class a implements b. No wonder developers struggle with interfaces when the people that literally wrote the book for them don't seem to get it. Even worse are the comments though, class Rain extends Weather and implements Water? What? Maybe if they mean water as in the sense of watering your lawn. Even so, there has got to be a better name for it than that. The way that interfaces are done in the Zend Framework offers a real-world example of bad interface design. Take a look at the following sentence and let's see if you can make sense of what the involved components are:

Zend_Validate_Date is a Zend_Validate_Abstract and can Zend_Validate_Interface

Now to be completely fair, these class names do get ugly as a result of having to bear the weight of pseudo-namespacing, but if your interface is actually called "Interface" you know you have a problem. Let's look at it again but this time we will be using PHP 5.3+ (which you should be using because it's awesome) and Zend Framework 2.0 - which may have namespace support:

Date is an Abstract and can Interface

This does not describe what type of an object the Date is. Is it a calendar date? Is it a fruit that can be dried and old people drink to help them go #2 more regularly? Or maybe it is a meeting involving two or more people in order to determine if their physical proximity elicits a chemical response. Who knows? And don't even get me started on "can Interface"! Maybe that's what happens if there is chemistry between the people on the Date? Now if you are an experienced OOP developer, you will know that Abstract is the home of some common functionality that all child classes share and that the Interface defines the contract that any objects implementing it must fulfill. But it doesn't tell you anything about what type of functionality is common to the children of the abstract or what types of behavior must be implemented by objects implementing the interface.

Designing objects can be fairly easy for the most part if you take the stance that your objects are nouns and your interfaces are adjectives. Until you get better at it, try to add the suffix "able" to indicate that objects implementing it are capable of doing something. Try this version of the Zend Framework validation action:

Date is a Validator and is Validatable

You won't always be able to use the "able" rule of thumb, but going through the process of trying to think of one will help you arrive at a better object model. Take a look at a few more examples:

A Circle is a Shape and is Drawable
A TeddyBear is a Toy and is Huggable
A CardDeck is an ArrayObject and is both Countable and Sortable

So hopefully these examples help give you an idea how easy it is to create good code. As always when it comes to designing objects, your best tool is simply reading the objects out loud. The better your design, the less like Yoda you will sound. Of course I couldn't leave this post without throwing down some code, and since I was most appalled by the Weather examples in the manual comments I thought I would do my own weather example. The real key here is to note that not only do weather conditions such as the amount of clouds and the UV index rating affect what the actual temperature feels like, so can what you wear. In other words, weather can use objects of completely different types to do work because it knows that those objects are capable of doing a particular thing. Read More

But then I tried to use it. I had a project that I needed to respond to SOAP requests and considering the issues I had last time I played with SOAP, I thought I'd try it a different way this time. The Zend framework is always described as being a collection of components that you can wire together in order to get work done. Most of the time, you use it to build a full MVC stack application, but I only needed one component (I thought) in order to get my work done.

Turns out you need a whole bunch of junk in order to be able to use the Zend_Soap component without a full copy of the Zend Framework:

Zend_Exception - I always thought this was a dumb thing in the first place. I use the SPL exceptions for my stuff.
Zend_Loader - What? Why? I required my class and most of the ZF uses requires as well so I am not sure why it wanted the loader
Zend_Registry - I thought maybe to cache the wsdl? But that's cached in /tmp by the underlying PHP soap action
Zend_Uri - Makes sense, the service is a web service after all
Zend_Validate - Have to make sure the Uri is valid I guess
Zend_Soap - duh

In the end, I needed 106 source files in 20 folders to get things done. This is especially crazy when you think that you can get a boiler plate client working by doing this:$client = new SoapClient('some.wsdl'); $response = $client->getSomething('foo');So you may be asking yourself if the Zend_Soap really needs all of those files. I thought so as well, but to be honest, I am trying to use the component to get a quick start on the service, not to spend an annoyingly long time going through each component only pulling out the exact source files I needed and placing them in their proper place in my library folder. You may also be asking yourself why I would bother in the first place. I'll tell you why, dear reader, it's because I wanted automatic WSDL generation! And it's because of this small desire that my troubles began. Read More

So I have been using git for a while now, and I really like it. I really appreciate being able to check in code without having to have a server available and for some reason it just feels a lot more solid than Subversion. Case in point, today I was merging a big branch back into trunk and it was throwing a ton of conflicts on tabbed versus spaced lines... Easy enough to fix but still annoying in the first place. I don't seem to get those kinds of issues with git. *shrug*

So I am just doing a quick post to say that I have put my toy framework up on GitHub so that I can keep track of it, share it with some other people and because I want to be like all of the other cool kids and have some open source junk on GitHub. I feel cooler already!

The framework itself has some interesting features, but as I said, it's mostly just there to experiment on. Check out what's working now:

* MVC stack - Duh, isn't every framework now?
* Highly modular - Everything for a module lives in the module. Configuration, Routes, etc can all be dropped in place as one folder.
* Uses namespaces - The initial reason I started writing this framework was to get namespace experience. Love them.
* Annotations - Allows you to specify stuff in a method/property doc block. @Inject for example.
* Dependency Injection - Uses type hinting and annotations to inject using constructor and/or setter injection. Can use lambdas/closures as object factories. It's sick, trust me.
* ORM - Has a very Django-like object manager. Want to get all BMWs with a model of 750i newer than 2007? It's easy: $cars = Bmw::objects()->filter('model_eq=750i')->filter('year_gt=2007'); Working on implementing single table inheritance right now where all classes for a hierarchy map onto on database table. Uses lots of late static binding.
* Unit of Work - Basically handles persisting Domain Models transparently using the ORM. If you load an object, change it and then delete it. Only the delete is persisted and the changes are ignored. You can read more about it on Martin Fowler's site. It's pretty awesome too.
* Templating - Another port from django. Basically allows for non-php template syntax. I like it, you might not.

Here's what is on the road map to completion:

* Forms - You guessed it. Django port again. Basically each property in a model is a field with validation and all of that junk built in. The forms handle wrangling them to and from the browser.
* Signals - Very similar to how plugins work in the Zend Framework. Instead of being rigidly contained however, you can emit any old signal to the signal bus and it can be ignored or handled by various listeners
* Automatic auditing - The unit of work knows what changes have happened, by adding an @auditable annotation to a class the Unit of Work will track the changes to the object in an auditing table.
* Automatic Sphynx updating - Again the unit of work knows when an object has been updated so if it has the @searchable annotation it will automatically update the sphynx indexes.
* Creation tools. The point is that this framework pretty much wires up everything for you so you just get down to business. Need something similar to Zend_Tool to help peeps out.
* Who knows. After all of that junk is in place... Well, I'll probably have started all over again ... *sigh* A great way to learn a lot about the new PHP 5.3+ features though!