If you choose to use their iframe approach, you're putting the burden of maintaining the Facebook look & feel entirely on your own shoulders. If Facebook decides to change their design (which they do pretty frequently), your application will be forced to play catch up. All this puts the developers at the mercy of the platform. At least with Microsoft, you could choose when to upgrade when you had the time and money to burn a hole in your wallet. Facebook unfortunately doesn't provide best practices for enterprise development. This is no surprise when one discovers that their testing model involves inflicting new changes to subsets of their user base rather than going through the trouble of creating a testable development environment.

In the longterm, I think this will hinder v2 versions of Facebook applications. If Facebook wants to see more powerful enterprise integration, they'll have to provide more than what's required to create a "grow your own bonzai" application.

In the words of Ralph Johnson:

Designing software is hard. That is what makes it so fun! People who are good at designing software enjoy solving hard problems, at bringing order to chaos, at overcoming difficulties. Things that used to be hard are now easy, but we have moved on to working on problems that would have been impossible 20 years ago. OO programming helps but does not eliminate the difficulty of design.

I always assumed that Christopher Alexander's A Pattern Language was some source of inspiration for these gentlemen and I was surprised to find out that it wasn't in fact the case.

When we started working on the Flyt Foundation together, I asked Mike what he felt made him such a successful teacher. He told me that what made him successful was his ability to tell stories. As someone who produces online education resources, I thought of how fragmented my own work is and how it suffers from this very issue.

All this is to say that the Flyt Foundation just recently launched a preliminary site on a humble budget with the lofty goal of providing young people with the ability to tell stories that will change our world into a better one.

If you're interested in learning more, don't be shy and check out the Flyt Foundation website, or send Mike Savatovsky an email.

You can setup your own code templates in the PHP options in NetBeans:

Here's the code template I use for generating unit test cases:

/**
 * Test class for ${classname}
 * @author: jlebensold
 */
 
class ${classname}
    extends ControllerTestCase
{
    protected $$${obj};
 
    public function setUp()
    {
	parent::setUp();
	$this->${obj} = new ${class_to_test}();
    }
 
    public function tearDown()
    {
	$this->${obj} = null;
    }
}

I even managed to get the unit testing environment to work with my Zend Framework installation with a little bash scripting. I realized that the PHPUnit test runner built into netbeans requires certain command line arguments, but because its designed to do single class tests instead of using the phpunit.xml file, I had to override it.

Here's my batchtest.sh file:

#!/usr/bin/env bash
cd ~/Sites/myproject/tests
phpunit --configuration phpunit.xml $1 $2
#phpunit $1 $2 $3

with this file, I can set either to have phpunit behave like it normally would in NetBeans (line 4), or have it read my phpunit.xml file instead.

The result is a nice little test runner that's built into my development environment:

I'm still trying to integrate code coverage, but since I get HTML reports, I think I can handle switching to my web browser for that.

The author, Peter Svennson, is probably one of the most qualified people in the world to be writing a book about Dojo, considering he's a contributor. The book takes plenty of time covering some of the more common Dijits and how best to apply them in an application. Like any framework, knowledge of certain core components helps when extending that knowledge across the rest of the library.

As someone who's worked extensively with JQuery and Prototype, I appreciated the authors recognition of other frameworks, while being able to diplomatically keep the discussion focused on Dojo without diminishing the work done on the other site of the Javascript framework fence.

Before being totally entrenched in the various Dojo libraries, Svennson takes a couple pages to explain closures and Javascript's prototype based object model. I found his explanation enlightening and a good starting point for a conversation on Dojo. Svennson also sold me on Dojo's class building framework.

What kept me flipping through the pages was Svennson's passion for the technology. The writing style is informal and conveys his personal interest in Dojo's architecture. However sometimes I felt this same passionate writing starts to read more like a sales pitch and less like a serious technical reference.

If you're the type of person that likes to work through a practical application of the technology, Learning Dojo is probably not the best book for the job. Instead of figuring out how to build a form with client-side validation that showcases all the Dojo bells and whistles (which I don't think one app could truly do), you're invited to create custom events, learn how to build class structures with pseudo-inheritance, look at localization and ways of theming your application. Since a lot of these features are design-releated, they tend to feel disjoint.

Only in the last chapter are we introduced to "real-world Dojo". While the examples are great, they feel almost tacked on. Regardless, the multi-charting project and the CRUD application cover a lot of components that were already discussed previously. It's also nice to see that Svennson mentions how to unit test using DOH. Learning Dojo is by no means a book for beginners: as the book progresses, there are large chunks of markup that are loosely explained in passing.

If you're already married to Dojo, planning a site in Dojo or inheriting something written in Dojo, this book could be a great reference for getting familiar with the technology quickly. If this sounds like you, grab a copy from Amazon.

UPDATE: enjoy reading Chapter 6 for free online!

I've always been interested in the idea that abstractions can help us discover new relationships that weren't

inherently visible in the implementation that we're trying to tackle. With that thinking in mind, I put together a little engine to help me visualize design patterns that I've drawn. You can navigate the interface with your arrow keys or the "ASDQWE" keys. Unfortunately, fullscreen flash doesn't support keyboard interactions. Without further blabbering, the project is called DPIcon and it's available to play with at dpicon.com.