Glimmer Repolished

While many people in Chicago celebrated the new year with a binge of chain-smoking since it's banned in public places starting 2008, I spent the first day of 2008 with a different kind of binge... yes, you guessed it: a programming binge! :P

I initially started Glimmer as a giant spike with the help of Nick Malnick. Later, I covered it with unit-tests with the help of Dave Hoover. Now, I finally re-wrote Glimmer test-first to make it extensible.

What are the benefits I realized from test-driven development:

• 100% unit-test coverage: every line of code was driven by a failing test, so I have a level of confidence about the reliability of the code
• Test-driven design: having tests covering my code as a safety net enabled me to make bold refactorings to produce code that is very modular, maintainable, and extensible
• Incremental sustainable pace: since I only write enough code to satisfy functionality required by one failing test at a time, I never get stuck debugging a mountain of issues as when writing code for a lot of functionality at a time. This gives me a sustainable pace of test/implement/refactor.

Additionally, test-driven design of the code opened my eyes to several ideas, one of which is applying the Chain of Responsibility Design Pattern. After all, Glimmer's DSL processes different commands that perform different tasks, such as instantiating a widget, setting a property, and data-binding, so why not create a chain of command handlers ordered in a certain way, and hand them the job of processing the DSL syntax? Makes a lot of sense, doesn't it? Especially, given the fact that with this design, any programmer can contribute new command handlers to the chain, thus extending Glimmer in any way needed.

In the future, I will talk more about how to extend Glimmer given its new architecture. For now though, happy new year everyone! :)