Code Naked

So I am working on a new assignment at work yesterday, should be a pretty simple task I think. I am consuming a SOAP service to get some simple data. Little did I know that it was such a pain to work with .Net when you are using the PHP SOAP extension. I started out with the following WSDL (just a portion that I wanted to work with is listed).
<wsdl:binding name="WSHttpBinding_IFeedService" type="i0:IFeedService"> <wsp:PolicyReference URI="#WSHttpBinding_IFeedService_policy"/> <soap12:binding transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="List"> <soap12:operation soapAction="http://schemas.example.com/IFeedService/List" style="document"/> <wsdl:input name="ListRequestMessage"> <soap12:header message="i0:ListRequestMessage_Headers" part="MetaRequest" use="literal"/> <soap12:body use="literal"/> </wsdl:input> <wsdl:output name="ListResponseMessage"> <soap12:header message="i0:ListResponseMessage_Headers" part="MetaResponse" use="literal"/> <soap12:body use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="ListByCode"> <soap12:operation soapAction="http://schemas.example.com/IFeedService/ListByCode" style="document"/> <wsdl:input name="ListByCodeRequestMessage"> <soap12:header message="i0:ListByCodeRequestMessage_Headers" part="MetaRequest" use="literal"/> <soap12:body use="literal"/> </wsdl:input> <wsdl:output name="ListByCodeResponseMessage"> <soap12:header message="i0:ListByCodeResponseMessage_Headers" part="MetaResponse" use="literal"/> <soap12:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:binding name="BasicHttpBinding_IFeedService" type="i0:IFeedService"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="List"> <soap:operation soapAction="http://schemas.example.com/IFeedService/List" style="document"/> <wsdl:input name="ListRequestMessage"> <soap:header message="i0:ListRequestMessage_Headers" part="MetaRequest" use="literal"/> <soap:body use="literal"/> </wsdl:input> <wsdl:output name="ListResponseMessage"> <soap:header message="i0:ListResponseMessage_Headers" part="MetaResponse" use="literal"/> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="ListByCode"> <soap:operation soapAction="http://schemas.example.com/IFeedService/ListByCode" style="document"/> <wsdl:input name="ListByCodeRequestMessage"> <soap:header message="i0:ListByCodeRequestMessage_Headers" part="MetaRequest" use="literal"/> <soap:body use="literal"/> </wsdl:input> <wsdl:output name="ListByCodeResponseMessage"> <soap:header message="i0:ListByCodeResponseMessage_Headers" part="MetaResponse" use="literal"/> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> So I write up a quick test script to grab that WSDL and try to run a method on it. It looked something like this:
$wsdlUrl = 'http://eavdevscar01/core/ScarlettFeedServices.svc?wsdl'; $clientOptions = array( 'trace'=>true ); $client = new MySoapClient($wsdlUrl, $clientOptions); echo "Functions:\n"; foreach ($client->__getFunctions() as $function) { echo $function,"\n"; } echo "Types:\n"; foreach ($client->__getTypes() as $type) { echo $type,"\n"; } try { $params = array( 'NetworkCode' => 'Test' ); $results = $client->List($params); print_r($results); } catch (SoapFault $e) { print "Call failed\n"; print $client->__getLastRequestHeaders() . "\n"; print $client->__getLastRequest() . "\n"; print $client->__getLastResponseHeaders() . "\n"; print $client->__getLastResponse(); } Easy-peasy, I have working with PHP driven SOAP services a bunch of times before so I could pretty much write that off the top of my head. So I run the code and I get a SoapFault saying that the Content-type is text/xml when it was expecting application/soap+xml. So I Google around and find that I have to specify the soap version 1.2 in order to get the correct Content-type. So I make the following change to $clientOptions:
$clientOptions = array( 'trace'=>true, 'soap_version'=>SOAP_1_2 ); Nice, that error is fixed. But Now I have another SoapFault: "The SOAP action specified on the message, '', does not match the HTTP SOAP Action. Google again. This time it looks like the PHP soap client is not able to deal with WSHTTP binding and must use the basicHTTP binding. I am not authenticating for this SOAP service, so I am not sure why it even matters. Luckily, the WSDL tells me that I have basicHTTP bindings available. When I try to use the basic data source though, I get another SoapFault "Action /basic is not defined". So then I email the provider of the feed to make sure their basic binding is configured correctly and working. They make some changes and end up dropping the WSHTTP binding completely from the WSDL. Sweet, that error is fixed.

Except that I am getting another SoapFault, fortunately for me I have run across it aready in my little adventure. It is now complaining that the Content-type application/soap+xml is incorrect as it was expecting text/xml. Seriously! So I go and remove the soap_version element from the $clientOptions array. Awesome, that was an easy one to fix!

But now I have another SoapFault: "Object reference not set to an instance of an object.". Google again. This is where things get really annoying. First of all, the SoapFault error message is ridiculously cryptic. I find all kinds of forum posts and comments in the PHP manual about how you are supposed to pass parameters into the action method on your client. Here are some of the different versions that I tried:
$params = array( 'Test' ); $results = $client->List($params); No good.
$params = array( 'NetworkCode' => 'Test' ); $results = $client->ListByCode($params); No good.
$params = array( 'NetworkCode' => 'Test' ); $results = $client->__soapCall('ListByCode', array($params)); No good.
class ListByCodeRequest { public $NetworkCode = 'Test'; } $params = new ListByCodeRequest(); $results = $client->__soapCall('ListByCode', array($params)); No good. Then I tried adding 'classmap' => array('ListByCode', 'ListByCodeRequest') to the $clientOptions array. That didn't work either. Please bear in mind that these changes may appear to be the flapping around of a dying fish, but I assure you that they each involved several minutes of Google research. I will admit though that by this point I was feeling fairly desperate. I decided to go get a copy of soapUI to see if maybe the feed itself wasn't working. I import the WSDL click on LIST and hit run. Bam! Results are returned immediately. I calmly stand up and leave my office before I bring violence upon my computer.

15 minutes pass

Okay, so I return to me desk and decide to look ONLY at the requests I was making and try to get them to match the ones created by soapUI. Here's what soapUI was doing:
<soapenv:Header/> <soapenv:Body> <ns1:ListByCodeRequestMessage> <ns1:Request> <ns1:NetworkCode>Test</ns1:NetworkCode> </ns1:Request> </ns1:ListByCodeRequestMessage> </soapenv:Body> And here is what I was producing:
<SOAP-ENV:Body> <ns1:ListByCodeRequestMessage/> </SOAP-ENV:Body> So obviously my parameters where not being passed in. I tried making the following change:
$params = array('NetworkCode', 'Test'); $results = $client->ListByCode($params); Which results in this request:
<SOAP-ENV:Body> <ns1:ListByCodeRequestMessage/> <param1>Test</param1> </SOAP-ENV:Body> Snap! I am getting a different SoapFault saying that param1 is basically an unknown parameter. I proceed to try several versions of nested arrays and finally give up after this one:
$params = array('ListByCodeRequestMessage'=>array('Request'=>array('NetworkCode', 'Test'))); $results = $client->ListByCode($params); You see I am back to the whole "Object reference not set to an instance of an object." SoapFault. It is then that lightening comes down and strikes my brain. This is the final (and working) version of the script:
$wsdlUrl = 'http://example.com/FeedServices.svc?wsdl'; $options = array( 'trace'=>true ); $client = new SoapClient($wsdlUrl, $options); class ListByCodeRequestMessage { public $Request; } class Request { public $NetworkCode; } try { $request = new Request(); $request->NetworkCode = 'Test'; $message = new ListByCodeRequestMessage(); $message->Request = $request; $results = $client->ListByCode($message); print_r($results); } catch (SoapFault $e) { echo "Call failed\n"; echo $client->__getLastRequestHeaders() . "\n"; echo $client->__getLastRequest() , "\n\n"; echo $client->__getLastResponseHeaders() . "\n"; echo $client->__getLastResponse(),"\n\n"; } So, hopefully this little saga will help others that are in danger of having a very long day as I had escape their fate. On a side note, whenever I am doing this kind of research on Google I always wish that there was an option to specify how old the results should be. I have the option Search: [ ] the web [ ] page from Canada, but I'd really like to see [ ] from this month [ ] from this year [ ] any time as options as well. A blog post mentioning PHP and SOAP from 2003 is probably not going to be helpful. Although sometimes I can see the date it was written before I click, not seeing the entry at all would be great.

I hear a lot of talk about the use of PHP in the Enterprise, recently there was even a white paper circulated extolling the virtues of PHP and attempting to make the case that PHP should be the language of choice for Enterprise development. Although the paper does bring up some interesting points such as the large number of extensions and the fact that there are a number of bridges for PHP to load native code written in Java and other languages, taking away from these strengths was that there is way too much emphasis placed on how many websites run PHP. Although it is hard to argue with the fact that PHP is greatly suited to web development, that in no way translates into suitability for Enterprise development. No offense to the language, but I find it perfectly understandable that PHP is not often considered a language suitable for Enterprise development.

PHP developers have a love-hate relationship with Java. Many PHP'ers are quick to point out that "PHP is not Java" and yet when one considers some of the most recent waves in PHP interest, they are frequently things that have been around in the Java world for years and are just now being introduced into PHP. A couple of recent examples are the sudden surge in PHPUnit and phpUnderControl. The latter isn't even a fully native PHP solution but en extension of the venerable Cruise Control continuous integration suite. That being said, I use both of those extensively and they form a crucial part of my software development process. Unfortunately, I feel that the adoption of these technologies has started to plateau as the initial wave of blog posts and general buzz have died down. Many PHPers feel that it's just too much effort for what it's worth. This is the key to the whole debate in my opinion. PHP developers put everything behind speed when it comes to development, in fact I often see bad code decisions being made for the benefits of a few CPU cycles. Perhaps it's because the speed of PHP is the primary strength that developers point to when comparing it to other languages that they focus on that feature. Honestly, PHP should be the fastest language on the web, after all it's all it's done for the last decade.

Here's what you should take away from this post:
1) Using PHP does not make you cooler. It should mean that you have chosen the right tool for the job. There is a reason why Zend Studio (from Zend, The PHP Company) is written in Java and not PHP-GTK. Why be just a PHP developer when you can be a programmer with many tools at your disposal.
2) If you want to improve the way PHP is considered in terms of The Enterprise, make your code look like it was written for the Enterprise. Stop considering your software to be something that you will write and throw away. Write it like it's something you will have to maintain for a decade and some day you just might get to.

So this is the last rule in the Deep Simplicity series. This time we will be talking about rule #9: Don't use Getter/Setters/Properties At first, I was confused about the rule because the main advantage of OOP is that you have the data and the methods that work on that data in the same place. I have often complained about the ridiculous idea that you should just blanket generate getters and setters for every single property. This leads to copy and paste errors and in my opinion a class that is totally bloated with useless methods. This idea is more in keeping with the spirit of rule 9.

The basic idea is that if you just give blanket access to your properties then you are allowing the client code to ignore encapsulation and in doing so you are allowing operations on your object's dirty bits to take place outside of your class. As usual, allowing this to take place is not a good idea. Take a look at this code:
class Product { private $price; private $taxable; public function getPrice() { return $this->price; } public function getTaxable() { return $this->taxable; } } class Order { private $taxRate; private $products; public function getTotal() { $total = 0; foreach ($this->products as $product) { if ($product->getTaxable()) { $priceWithTax = $product->price * $this->taxRate; } else { $priceWithTax = $product->price; } $total += $priceWithTax; } return $total; } }
The Order::getTotal knows way too much about the product object. What happens if there are other factors in determining the price after taxes? Are you going to put all of that logic into the getTotal method as well? What happens if you want to calculate the price after taxes without having an order? Code duplication results in multiple places for possible bugs if the spec changes, you have to "remember" where those calculations are done in order to update them all. Encapsulation solves this problem by making one and only one logical place for functionality to reside. It's hard to remember all of the places that code should change if you have never seen it before. Here is the same functionality with no access to the Product's private parts:
class Product { private $price; private $taxable; public function priceAfterTaxes($taxRate) { if ($this->taxable) { return $this->price * $taxRate; } return $this->price; } } class Order { private $taxRate; private $products; public function getTotal() { $total = 0; foreach ($this->products as $product) { $total += $product->priceAfterTaxes($this->taxRate); } return $total; } }
Wow, not a single accessor in sight. Once again the code we end up with looks much cleaner than the original. The semantic intent is clear and more importantly, this new method is much more likely to be reused.

In the end these rules are meant to be a means to an end. You can always come up with edge cases and exceptions to the rules where you find that the code you end up with is maybe not as good as it could have been. The point is not that you follow these rules to the letter or die trying; the point is that by thinking about these rules as you write code you will end up with something that is far better than you would have otherwise done. I hope that the examples I have given have shed some light on how simple and understandable your code can become with a little more effort on your part. If you are interested in more of the great ideas from Thoughtworks, make sure you grab The Thoughtworks Anthology.

Okay, back to the rules! Rule #8 is: Use First-Class Collections. Unlike the previous rule, I really like this one. Basically the rule states that any class that contains a collection should have no other instance variables. This is similar to other Deep Simplicity rules in that it makes it clear what the responsibility of the class is.

On top of this, a simple array has very little semantic intent other than the name that a developer gives the variable that contains it. As we have discussed before lazy programmers can take your well-meaning code and pervert it into meaningless spaghetti by simply chopping a few characters off of a variable name. By making the collection a full-blown object in it's own right it also becomes clear where you should put helper code like filtering or applying a function to all members of the collection. Let's take a look at some code:
class Card { protected $value; protected $suit; } $all = array(); $all[] = new Card('Ace','Spades'); $all[] = new Card('Ace','Diamonds'); // continue for all cards in a standard deck $deck = $all; $p1 = array(); for ($i=0; $i<8; $i++) { $random = rand(0, count($deck) - 1); $p1[] = $deck[$random]; unset($deck[$random]) } $p2 = array(); for ($i=0; $i<8; $i++) { $random = rand(0, count($deck) - 1); $p2[] = $deck[$random]; unset($deck[$random]) } // Do one exchange $ask = random(0, count($p1)-1); $has = false; foreach ($p2 as $i => $c) { if ($p1[$ask]->value == $c->value) { $p1[] = $c; unset($p2[$i]); $has = true; } } if (! $has) { echo 'Go fish!'; }
So, this is some seriously lazy programming. Although there are a few comments, they are very sparing. The short variable names give you no real clue about what the four arrays represent - at least not without having to expend some brain power figuring out what all of this means. I know you may be saying to yourself that this is a poor example, but I assure you, I have seen code like this in production all the time. I think it's a legacy of the PHP developer lifecycle, starting with one-off single page scripts and eventually evolving into more. Let's see the code again with some more comments and better variable naming:
class Card { protected $value; protected $suit; } $allCards = array(); $allCards[] = new Card('Ace','Spades'); $allCards[] = new Card('Ace','Diamonds'); // continue for all cards in a standard deck // Copy all cards because we want to deal some out $gameDeck = $allCards; $playerOneHand = array(); for ($i=0; $i<8; $i++) { // find a random card from the game deck $randomCard = rand(0, count($gameDeck) - 1); // Add card to player two $playerOneHand[] = $gameDeck[$randomCard]; // Remove card from game deck unset($gameDeck[$randomCard]) } $playerTwoHand = array(); for ($i=0; $i<8; $i++) { // find a random card from the game deck $randomCard = rand(0, count($gameDeck) - 1); // Add card to player two $playerTwoHand[] = $gameDeck[$randomCard]; // Remove card from game deck unset($gameDeck[$randomCard]) } // Do one exchange $askForCard = random(0, count($playerOneHand) - 1); $hasCard = false; foreach ($playerTwoHand as $cardIndex => $card) { if ($playerOneHand[$askForCard]->value == $card->value) { // Move the card to the asking player's hand $playerOneHand[] = $card; unset($playerTwoHand[$cardIndex]); $hasCard = true; } } if (! $hasCard) { echo 'Go fish!'; }
So this example is much more clear in terms of intent. Although you can now determine what each of the arrays is representing, you have to do a lot of parsing in order to determine what is going on. On top of the difficulty in understanding what is going on, there are lots of bug-prone areas where you deal with the fact that arrays are 0 indexed. such as this line:
$askForCard = random(0, count($playerOneHand) - 1);
Now, some of you are saying that getting a random card from an array of cards should be extracted into a method. I agree with you completely! The questions is, where? Should we put all of this in a Game class which has a Game::getRandomCard(array $cards) method? When you are playing "Go Fish" is there some game device that a player passes their hand into to get a random card? I don't think so. If however, you take the advice of this rule and make all of these arrays into first class objects, it becomes quite clear where that method belongs:
class Card { protected $value; protected $suit; } class Game { public function getCardDeck() { $deck = new Deck(); $deck->append(new Card('Ace', 'Spades')); $deck->append(new Card('Ace', 'Diamonds')); // continue for all cards in a standard deck return shuffle($deck); } } class Deck extends ArrayObject { protected function deal($count) {} } class PlayerHand extends ArrayObject { protected function getCardToAskFor() {} protected function has(Card $card) {} protected function give($hand, $value) {} } $game = new Game(); $gameDeck = $game->getDeck(); $playerOneHand = new PlayerHand($gameDeck->deal(8)); $playerTwoHand = new PlayerHand($gameDeck->deal(8)); // Do one exchange $askFor = $playerOneHand->getCardToAskFor(); if ($playerTwoHand->has($askFor)) { $playerTwoHand->give($playerOneHand, $askFor); } else { echo 'Go fish!'; }
I don't know about you, but this last example seems very clear in terms of what's going on. Even if a lazy developer where to come along and started changing the variable names to three or less characters in length, things still make sense with minimal effort because the logic is hidden away in the Collection itself rather than getting in the way of getting work done.

One more rule to go: #9 Don't user any Getters/Setters/Properties

In this entry I am going to talk about rule #7: Don't Use Any Classes with More Than Two Instance Variables. This for me is one of the hardest rules to try to follow. The author of Deep Simplicity states that he is about to release a one hundred thousand line application that strictly follows these rules, so I guess I just suck.

The reason that we can break any object down to have one or two instance variables is because when you have more than two of them, you can usually group two into one object. Adhering to this rule makes for logical code that has a very defined responsibility. This after all is the whole point to these rules; making it so that everything is so simple it requires little to no thought to work on the project. Let's look at some code:
class User { protected $firstName; protected $lastName; protected $address; protected $phoneNumber; public function __toString() { return $this->firstName . ' ' . $this->lastName; } }
So we have all seen the classic User object, you might be wondering how we can get this object to have one or two instance variables. You can do it by either working your way down by splitting an object into related halves or working your way up by taking any to instance variables and making an object out of them. So let's try it:
class User { protected $name; protected $contactInformation; public function __construct() { $this->name = new Name() $this->contactInformation = new ContactInformation(); } public function __toString() { return $this->name->asFullName(); } } class Name { protected $first; protected $last; public function asFullName() { return $this->first . ' ' . $this->last; } } class ContactInformation { protected $address; protected $phoneNumber; } So there we have it. The User object was broken down into finer grained objects that can then house the logic specific to those properties. It's pretty sweet when it works out that way, but in the interest of full disclosure I'll admit that I have no idea how to break up the original User class I was going to use for this example:
class User { protected $firstName; protected $lastName; protected $address; protected $city; protected $state; protected $zip; protected $phoneNumber; }To me, that is more like the User objects I see all of the time. I can still break it up into Name and ContactInformation. ContactInformation can be broken down into Address and PhoneNumbers, but I can't think of a way to break up this object:
class Address { protected $address; protected $city; protected $state; protected $zip; }To me, every property in there belongs to an address. Further, I can't think of a way to group any two of these properties into a new object or a way to split this object in half. Can you see a way to split them? Feel free to comment about it.

Next time is rule #8: Use First Class Collections.

The next rule in Deep Simplicity is Keep All Entities Small. This is one of the rules that I think should be more of a guideline. Jeff Bay thinks that a class should be no more than fifty lines. I think adding the corollary that it's fifty lines without comments makes this rule a little more palatable.

That being said, Jeff does have some good reasons for limiting the class size. The first reason is that classes that are more than fifty lines long tend to do more than one thing - which is bad because it makes them harder to understand and harder to reuse. Another good point is that a class that is small is going to fit onto your screen without scrolling, being able to see as much of it as possible means that it is easier to grasp all of the responsibilities of the class.

That's it for this one, next time we'll talk about rule #7: Don't Use Any Classes with More Than Two Instance Variables

The next rule we will be looking at in Deep Simplicity is Do not abbreviate. As developers, it is often said - tongue in cheek - that being lazy is a virtue. I think that the laziness of developers is a key source of preventable errors. Copying and and pasting code being the number one offense when it comes to inadvertently adding errors from being lazy. It's even worse for those developers that are reluctant to use an IDE and hack away on vi or emacs. Another way developers are lazy is by shortening the names of classes, methods and variables with abbreviations which lead to confusion and tend to hide larger issues.

I recently came across code that looked like this:
if ($foo->getBwid()) { $widget = Widget::getByBarWidgetId($foo->getBwid()); return $widget; }
Can any one tell me what a Bwid is? Oh sure you can guess by looking at the context in which it is being used, but are you really sure? look at the amount of energy you'd have to expend just to write this code in the first place. Even if you wrote both the Foo class and the Widget class, I'd bet that you would have to look up the method you wanted to use. If not immediately, a year after you wrote them you'd be screwed. How much more digging would a new developer to the code base have to do?

By looking at the reasons for the abbreviation you can find ways to improve the code. Are you typing the same word repeatedly? You probably should look for duplicated code. Are you doing it because the method names you are using are getting too long? You probably should look for a missing class. Try to keep names to one or two words, this doesn't count for PHP classes that have to bear the weight of namespacing. Zend_Cache_Backend_Memcache is okay, Zend_Cache_Backend_StoreDataOnYourHardDrive is not so great. you should also try to avoid duplicating context. If you have a class named Order, naming a method shipOrder is pointless and sounds weird when you say it out loud: $order->shipOrder(). Naming the method ship(), sounds much better: $order->ship(). Keep things simple and clear and you should be fine. If in doubt, try saying it out loud.

Next is part #6: Keep all entities small.

The next rule in Deep Simplicity is based on the Law of Demeter ("talk only to your friends") but is phrased more colloquially as Use only one -> per line. In PHP it should actually be "Don't use more than two -> per line" since we have to use $this-> in order to access local properties. The main reason we want to try to follow this rule is because if we don't, we are breaking a basic principal of OOP - encapsulation.
By reaching into the child of a child object, we are essentially saying that the child object is a middle-man that does not provide us with the functionality we need. It can also be an indication that there is a missing object in our Domain. By treating code that looks like this $a->b->c() as a warning flag, you can be on the look out for objects and classes that may be missing. Let's take a look at some code and then we can see if we can make it better.
class User { protected $account; public function getBalance() { $balance = 0; $numTransactions = count($this->account->transactions); for ($i=0; $i < count($this->account->transactions); $i++) { if ($this->account->transactions[$i]->isDeposit()) { $balance += $this->account->transactions[$i]->amount(); } else { $balance -= $this->account->transactions[$i]->amount(); } } return $balance; } }
As you can see, we are reaching far into the account's dirty bits to put together the balance for the User. To me, the code felt bad as soon as I wrote it. To be completely honest, it's actually the for loop that is bugging me. Other than this example, it has probably been over a year since I used the for keyword. Lemme just fix it up a bit before we continue.
class User { protected $account; public function getBalance() { $balance = 0; foreach ($this->account->transactions as $transaction) { if ($transaction->isDeposit()) { $balance += $transaction->amount(); } else { $balance -= $transaction->amount(); } } return $balance; } }
Although this code is much improved over the previous version, we are still reaching into transactions to get their amount. This is bad. To be completely honest, the User object should have no knowledge of the concept of a transaction at all. When you go to the bank machine you choose to withdraw $100 from your checking account. My bank machines don't offer the "Add withdrawal transaction to your checking account's list of transactions" option, does yours?. After you get your cash monies, you are presented with a receipt, on which is printed your checking account balance, not a sum of your transactions. So, let's write it like that:
class User { protected $account; public function getBalance() { return $this->account->getBalance(); } }
I know right? Have you noticed how many times in this series when we are done we end up with methods that are less than five lines long? Although the User class API is essentially the same, we have improved the Account class API by adding the getBalance method to it. This method has a strong cohesive name and responsibility. This means that other developers are far more likely to use it and the line
$this->account->transactions[$i]->amount() should be rarely seen in the Domain if at all.

Next part is #5: Do not abbreviate.

Don't get me wrong, I think the Zend_Registry component is great. There are a couple of problems that I see when using the Zend_Registry as a container for junk like database connection objects and session namespaces and pretty much every other resource that you need to be globally accessible. The first, is that there is no information about what kinds of resources are available to you when you are using the registry. In other words, there is no way to know what Zend_Registry::get('db'); is actually going to give you. Is it a Database connection resource or is it a Data Buffer? Actually, it almost makes more sense for "db" to be an acronym for data buffer ... At any rate, there is no way to enforce what you are getting. This means that your editor can't code hint for you and your API docs don't really show an object that has the responsibility of wrangling application resources. I guess that is a good summary for the first issue with Zend_Registry - it's too generic to be really useful.

The second problem with the Zend_Registry is that it is essentially a global array. At any given time an innocent developer can unwittingly blow away your database connection with his data buffer and there is nothing to stop him. We all know (or should know) that global variables are bad. They inject uncertainty into our applications and can be the cause of some of the most irritating to debug problems. So, to sum up the second issue with Zend_Registry - it suffers from the same issues that all global variables suffer.

So, how do we fix it. Simple really, we create an object that is responsible for maintaining these application services. In fact, I use two different objects to manage two different types of application resource. I use Naked_App_Environment to manage configuration and environment information and I use Naked_App_Workspace to manage my application resources such as Naked_Db connections and Zend_Logger instances. Let's take a look at these two components and see how your life as a developer can be made better... Continue reading "Better Alternatives to using Zend_Registry"

So I installed Google Chrome yesterday. After spending an hour or so gloating to the developers that work on a Mac because they couldn't install it I sat down to really play with it. I heard a lot of people saying things like "Safari has draggable tabs" or whatever as if it was a bad thing that Google implemented them. Ummm, weren't you paying attention? Google intentionally copied good features from other browsers; not only that, but they want other browsers to copy things from their browser so they made it open source.

You know, in the industry we hear all the time about the war between Microsoft and Google. I will admit that I always thought that there was a stand-off between the two as well. After downloading the beta of Chrome I can honestly say that there is no competition, at least not from Microsoft... I can't remember the last time I installed any software beta or otherwise that I was happy to use. (Oh not you calc, you still do a great job) There is honestly nothing wrong with Chrome that I could see. I starts up and renders wicked fast, stays out of the way of what I am trying to do and has some handy features that I already enjoy using immensely.

That being said, I haven't gone so far as to make Chrome my default browser yet. Firefox has one major feature that I just can't let go of: extensions. Even though Chrome has some handy items for debugging and stuff, it can't touch Firebug and Web developer extensions for Firefox. Let's face it, the user base for Firefox started out with the geeks and then moved into mainstream as we all recommended it to our mothers so we would stop getting called about their computer acting slow after they went to the recipesthatp0wnyou.com website. Until Chrome becomes a development tool as essential as Firefox is, I don't think it will replace Firefox for me as my default browser.

PS: The guy that though of the application shortcuts feature needs a raise. GMail feels like a desktop application now.