Thursday, June 26, 2008

Elsewhere on the Web

Test Driven Development


There was a nice article at Sitepoint about Test Driven Development. The author, Chris Corbyn, walks through the TDD process using PHP examples, and describes some of the benefits he has discovered in the TDD process.

Firefox 3 Memory Benchmarks and Comparison


With both Firefox 3 and Opera 9.5 being freshly released, here's a nice memory performance comparison of those browsers, as well as the IE Beta version 1 and Flock. The memory tests are computed by a custom built .NET application, and provide a good look at how these browsers compare in memory management on the Windows operating system.

Sketching in Code: the Magic of Prototyping


The folks over at A List Apart offer us yet another excellent write-up. David Verba, Technology Advisor for Adaptive Path, takes a look at using prototypes in the web application development process, and what prototyping can offer that wireframes cannot.

Same DOM Errors, Different Browser Interpretations


Hallvord R. M. Steen of Opera offers a very interesting look at how the different browsers interpret the DOM, and what tools each of them provide for debugging. Some attention is also given to Opera's new debugging tool, Dragonfly.

Tuesday, June 17, 2008

A Better Way To Globalize

Lately I've been working quite a bit with some PHP code that made heavy use of global variables. It made the code quite rigid to work with...when changes were made in one function it had a ripple effect on many other key functions and more than once, made me curse global scope.

But sometimes it's necessary to share information between different functions, so what's a programmer to do? Global variables certainly make that possible, but they also create some problems. Heavy reliance on global variables makes it difficult to reuse code. Rarely can we uproot functions with a large dependency on global variables and insert them into different contexts or scripts without problem.

Debugging code also becomes difficult. When a variable is global in scope, it could be being instantiated virtually anywhere making it tough to track down. What's even worse is coming back to that code after a year, or as it was in my case, trying for the first time to decipher code that relies on global variables.

Luckily there's a much better way: the registry pattern. The registry pattern simply creates a class that servers as a central repository, or registry, of objects that we can now utilize throughout our code. It accomplishes this by utilizing static methods and properties, which means you'll want PHP5 to accomplish it....you can use it in PHP4 but it requires some workarounds. This pattern is particularly useful when used to store a data connection.

Breaking It Down


The best way to explain this is to walk through the code.

  1. class Registry{

  2. private static $instance;

  3. static function instance(){

  4. if ( ! isset( self::$instance ) ){

  5. self::$instance = new self();

  6. }

  7. return self::$instance;

  8. }

  9. }


The code above first simply creates our registry class, aptly called Registry (line 1). We then create a static function (line 3) and variable (line 2). This is how we will keep track of whether or not an instance of this class exists. If it doesn't, then we create a new instance of the class.

Now we just need to create set and get functions for anything we want to use globally. In this case, we'll create set and get functions for a very simple object that we'll call a TestObject and a variable to contain that object.

  1. class Registry{

  2. //.....

  3. private $testObject;

  4. function getTestObject(){

  5. return $this->testObject;

  6. }

  7. function setTestObject( TestObject $test){

  8. $this->testObject = $test;

  9. }

  10. }


Our two new methods do exactly what they sound like...the get and set methods simply retrieve or save our testObject to the $testObject variable. That's all there is to it...now we can use our registry class to make a TestObject instance that we can use globally (for this post, just accept that TestObject allows us to set and display a message...all the code is available for those who want a closer look). Since we are using a static property and method to ensure that all instances of that class have access to the same values, it doesn't matter where we initially instantiate the class.

  1. function setting(){

  2. $myTest = new TestObject();

  3. $myTest->setMessage ( "Registry Patterns Rock!" );

  4. $reg = Registry::instance();

  5. $reg->setTestObject( $myTest );

  6. }

  7. function retrieve(){

  8. $reg = Registry::instance();

  9. $myObject = $reg->getTestObject();

  10. echo ( $myObject->getMessage() );

  11. }

  12. setting();

  13. retrieve(); //outputs Registry Patterns Rock!


Now despite the fact that we create the two instances of the registry class within two separate functions, you can see that they both have access to the same values thanks to the Registry pattern, without all the mess that can be caused by global variables. To add more values to our registry class, we simply add more private variables and some set and get functions.

But Wait...There's More!


Another handy way of utilizing the registry pattern, is to use our Registry instance to create and then cache an object, skipping the need for a set or get function. For example, if I have a data connection that I know I want to be standard throughout the project I can create a function like this inside of my Registry class:

  1. class Registry{

  2. //.....

  3. function dataConn(){

  4. if ( ! isset ( $this->dataConn ) ) {

  5. $this->dataConn = new dataConn();

  6. $this->dataConn->setHost( 'localhost' );

  7. }

  8. return $this->dataConn;

  9. }

  10. }


Now, instead of worrying about the set and get functions, I can just call the dataConn() function. If the data connection has already been created, then it returns the connection. If not, it first creates my connection, and then returns it. So I can safely call the function without concerning myself with whether or not I've already created the connection...it takes care of that for me.

The registry pattern is so incredibly useful and a definite improvement over using the dreaded global variable in your code. I highly encourage you to play around with the sample code and see the different ways that the registry pattern can manage your code.

Wednesday, June 4, 2008

Javascript: The Good Parts

Who Wrote It?


When I first heard Douglas Crockford was writing Javascript: The Good Parts (let's just call it JTGP from here on out) I was anxiously awaiting the release. Crockford has been responsible for many highly regarded articles and presentations, as well as for his incredible work with JSON, JSLint and much more. While Brendan Eich may be the father of Javascript, Crockford is probably the Godfather. Even Eich himself called Crockford "the Yoda of Lambda JavaScript programming."

What's Covered?


JTGP does as promised...it brings to attention the best parts of the Javascript language. Topics like Objects, Inheritance, Arrays, Functions and Regular expressions are discussed throughout the book. While focusing on the "good parts" of Javascript, Crockford also points out the not-so good parts and explains why these other parts don't fall into the good category by pointing out caveats and pitfalls.

I've seen it mentioned before that people complained about the book being a bit short. It weighs in at a very light 145 pages, 45 of which are appendixes. The information is quite dense however, and I thought the appendixes were extremely valuable. The appendixes include looks at what Crockford considers to be the "awful parts" and the "bad parts" of Javascript. They also include looks at JSLint and JSON as well as providing some helpful syntax diagrams.

Should I Read It?


As mentioned before, the book is short, but very dense. As a result, there is a lot of information covered, but not always a lot of explanation involved. The book seems to take a bit of a different approach than the typical Javascript book...it's more focused on why than it is on how.

That is not at all a bad thing though. Assuming you have a nice handle on the language and it's syntax, there is a lot to get out of reading this book. In fact, there is so much information crammed in here that it will probably take several readings to truly grasp all the information being delivered. Don't make the mistake of assuming that because it is short it is an easy-read...this book covers advanced information and does so at a very rapid pace.

The Final Verdict


JTGP is a great book for anyone who wants a deeper understanding of the why behind the how. I would recommend it to anyone, though I would warn that you'll want to have a decent understanding of the syntax before reading it...since the book focuses so much on why, there's not a lot of explanation on how things work, and to get all that this book has to offer, you'll want to know that. Overall, a very good book that is good enough to demand several readings.

Great...Where Do I Get a Copy?