Tuesday, January 22, 2008

TDD interlaced with functional testing

Today, I heard an interesting suggestion from a colleague during a pair-programming session. After we finished writing the first test for a particular web action and making the test pass, he suggested that we do a functional end-to-end test before writing the next test. The reasoning behind that was to make sure that our idea for the functionality is solid before we commit to writing more tests. So, not only was the first test used to test-drive code for better reliability, but also to explore different designs for the functionality. In a way, that first test served as something in between a spike and driving actual functionality.

What do you think of that? Has anybody done testing this way before?

Monday, January 21, 2008

Element content in Glimmerized XML

Now that we have basic namespace support in the Glimmerized XML syntax, let's tackle the next question:

How do we place content in elements?

Here is an example written with basic XML:

<ajax:text>This is an Ajaxified text box</ajax:text>

Here is the same example done with Glimmerized XML:

ajax.text{"This is an Ajaxified text box"}

Intuitive transition, isn't it?

Now, what about mixed content?

Look at this XML snippet:

<p>
  I want to buy these instruments:
  <ul>
    <li>Accordion</li>
    <li>Organ</li>
    <li>Keyboard</li>
  </ul>
  Please make sure they are all Yamaha!
</p>

Here is the same snippet Glimmerized:

p {
  text "I want to buy these instruments:"
  ul {
    li {"Accordion"}
    li {"Organ"}
    li {"Keyboard"}
  }
  "Please make sure they are all Yamaha!"
}

Sweetly simple huh? The "text" prefix is needed to declare content that comes before other elements. Notice how it was left out at the last text snippet. This is because the last line in a Ruby block always represents the return value, so the Glimmer engine took advantage of that fact. This is the same reason why with simple element content, there is no need to utilize the "text" prefix.

The story doesn't end here though. Stay tuned for two upcoming surprises that will make it easier to author mixed content in elements.

Glimmerized XML Namespaces Continued

While it's true that Glimmerized XML syntax can now handle namespaces, support is not complete yet as pointed out in a comment by Ed Merks, the co-architect of the Eclipse Modeling Framework.

How do you include attributes that have qualified names?

Here is how it is done in XML:

<label bundle:key="contact.firstName" >
  <text ajax:id="firstName" />
</label>

Glimmerized syntax now supports that as follows:

label(bundle.key => "contact.firstName") {
  text(ajax.id => "firstName")
}

How do you declare XML namespaces?

Using the same mechanism.

Here is an example of an XML declaration of a namespace:

<billing:price xmlns:billing="http://billing.system.biz/schema" units="CAN">47.38</billing:price>

Here is the same example written with Glimmerized syntax:

billing.price xmlns.billing=>"http://billing.system.biz/schema", units=>"CAN" {"47.38"}

Notice how attribute names do not have to be Ruby symbols anymore (e.g. units => "CAN" instead of :units => "CAN".) Ed's suggestion to drop the colon coincided with the need to support prefixes, so the syntax has been enhanced to allow qualified names, which were not possible with symbols.

Stay tuned for more on how to include simple text or mixed text in an element body.

Sunday, January 20, 2008

Glimmerized XML Namespaces

In a previous post, I mentioned a new Glimmer DSL for authoring XML documents.

XML support has been expanded further now to cover namespaces.

Take a look at this XML example:

<body>
  <bundle:label key="contact.firstName" >
    <ajax:text id="firstName" />
  </bundle:label>
  <bundle:label key="contact.lastName" >
    <ajax:text id="lastName" />
  </bundle:label>
</body>

It utilizes elements from two different namespaces: bundle and ajax.

Here is how to author that with the Glimmerized syntax:

body {
  bundle.label(:key => "contact.firstName") {
    ajax.text(:id => "firstName")
  }
  bundle.label(:key => "contact.lastName") {
    ajax.text(:id => "lastName")
  }
}

Intuitive and simple, isn't it?

Now, look at the following XML document:

<body>
  <domain:label key="contact.firstName" >
    <domain:text id="firstName" />
  </domain:label>
  <domain:label key="contact.lastName" >
    <domain:text id="lastName" />
  </domain:label>
</body>

Since namespaced elements come from the same namespace, things can be simplified with the Glimmerized syntax by utilizing the namespace wrapper:

body {
  namespace("domain") {
    label(:key => "contact.firstName") {
      text(:id => "firstName")
    }
    label(:key => "contact.lastName") {
      text(:id => "lastName")
    }
  }
}

So, namespaces are now officially supported by the Glimmerized XML syntax. There is more to it though, so check out the next post about it.

Friday, January 18, 2008

Glimmer Is Stylin'

Take a look at this Glimmer (introduced here) code snippet:
table(SWT::BORDER) {
  layout_data GridData.new(SWT::FILL, SWT::FILL, true, true)
  table_column {
    text "First Name"
    width 80
  }
}
It may look clean enough to a casual SWT developer such as myself, but upon presenting Glimmer at a Chicago Area Ruby meeting, someone pointed out how it violates one of Glimmer's philosophies by repeating the word SWT before every style constant. Of course Glimmer Listens, and just when you thought Glimmer's syntax couldn't get any cleaner, you get this:
table(:border) {
  layout_data GridData.new(fill, fill, true, true)
  table_column {
    text "First Name"
    width 80
  }
}
Notice the difference? Styles don't need a bulky "SWT::" prefix anymore. Just because Glimmer's fans loyal to its philosophies saw that improvement coming, that doesn't mean there won't be any surprises in the future. ;)

Wednesday, January 16, 2008

XML is DEAD!!! Welcome Glimmerized XML!

Yes!!! You heard it! XML is finally DEAD to all XML haters... why? Because, XML has been officially Glimmerized!

Ok, this originally happened with the Builder framework, but it was very easy to implement something similar with Glimmer's flexible engine.

Take this XHTML document for example:

<html>
  <body>
    <form id="contact" class="information">
      <input id="name" name="contact.name" />
    </form>
  </body>
</html>

Here is the same document Glimmerized:

html {
  body {
    form(:id => "contact", :class => "information") {
      input(:id => "name", :name => "contact.name")
    }
  }
}

Isn't it much cleaner? Isn't it much much easier to read? It's about time we got something like that, thanks to the power of Ruby and the flexibility of the Glimmer engine.

Since XHTML is a special form of XML, Glimmerized syntax goes further to give special treatment to ids and classes due to their popular use:

html {
  body {
    form_contact_information {
      input_name(:name => "contact.name")
    }
  }
}

The word following the first underscore after an element name represents the ID. The word following the second underscore after an element name represents the class. If there is no ID, then simply place two underscores before the class name (e.g. form__information)

How do you print the resulting XML? Simply assign the html element to a variable and call to_xml on it:

document = html { }
document.to_xml #prints <html></html>

What else? If most of the XHTML on your project is maintained by programmers, they'd definitely appreciate the Glimmerized syntax, wouldn't they? If so, you can easily run a Ruby script that Glimmerizes all your XHTML documents so that you can delete them and rely on the pretty Ruby syntax instead! What happens if you later change your mind however, and push the task of maintaining the XHTMLs to web designers? Simple! Run another Ruby script that converts Glimmerized XHTML documents back into the basic XML syntax!

Now that's a funeral that does not fill my heart with any regret!!! Rust in pieces XML!

Friday, January 11, 2008

Attitude Towards New Technologies

When you hear about a new language, framework, library, or technology, what is the first thought that goes through your mind?

Some developers immediately think about ways to deface the new technology, find faults with it, or come up with reasons for not using it. These are the developers that make good risk managers as they are thinking more about the potential pain and they would like to minimize it.

Other developers immediately think about ways to use the new technology and find great applications for it that can improve their productivity or project quality. These are the developers that make good creative thinkers as they are focusing more on the potential pleasure and they would like to maximize it.

Nonetheless, most developers oscillate between the two mentalities depending on the current mood and circumstances, and both kinds of mentalities are useful to have in a software development team.

What attitude do you usually have on first encounters with new technologies? Do you focus more on potential pain or pleasure?

Sunday, January 06, 2008

JFace TableViewer vs Swing JTable

While the SWT Table widget in Eclipse supports display of tabular data through the host operating system native table widget, its API is low-level and does not come with built-in support for data management through the MVC architectural pattern. This is where JFace TableViewer comes into place. It allows developers to populate tables through the implementation of model classes, the chief of which are IContentProvider and ITableLabelProvider.

How does it compare to the Java Swing JTable though?

To populate a table, JTable requires developers to implement a class called TableModel, which abstracts the data presentation of a table. The actual method that populates the table is getValueAt(int rowIndex, int columnIndex), which returns objects to be rendered for every cell in the table.

TableViewer on the other hand notices a pattern in table population related to the fact that table data is usually broken into rows, and then per each row, it is broken into columns. It takes advantage of that by having developers specify how data is broken into rows through an IContentProvider implementation, and then specify how a row is broken into columns through an ITableLabelProvider implementation.

Since table data often comes in a list or collection of some sort, the benefit of the latter approach is that one can reuse the same IContentProvider implementation across many tables, only needing to implement different ITableLabelProviders for each use-case.

This can still be done in Swing by relying on an abstract TableModel that always expects data in a collection, but the IContentProvider makes the separation of concerns cleaner in TableViewer.

Swing JTable provides other advantages due to being a rendered widget instead of a native platform widget. It supports having a TableCellRenderer, enabling you to render data in any way you like (e.g. as buttons, checkboxes, canvas painting, etc...) whereas TableViewer always displays data only as text, image, or a combination of both.

Is the API of either TableViewer or JTable a factor in determining which to use to build your future business applications?

I would say no. The differences are mostly aesthetic as you can accomplish basic business needs easily with either widget.

What really sets the decision apart is that TableViewer relies on a native table widget, offering a more familiar look and feel and potentially better performance whereas JTable is a Java Swing platform-independent widget, giving you more control and flexibility over the look and feel of the table.

Update: While this may have been accurate for previous versions of SWT, the situation changed with SWT 3.3 as it now supports cell rendering just like Swing. Please check Tom's comment for more details.

Saturday, January 05, 2008

Type-Inference with Generics

Generics in Java 5 and beyond offer many cool features, one of which is type-inference.

Consider this, for an example:

public Object load(Class objectClass, Serializable id);

This is an Object-Relational mapping method that loads an object from a repository based on the object id. Unfortunately, it requires you to cast the object after the method call, cluttering your code unnecessarily, as shown in this example:

Person person = (Person)mapper.load(Person.class, 35);

While Java Generics are often applied at the Class level, they can also be applied at the method level. In fact, in this case, they would offer a neat application of type-inference. Here is how the load method is rewritten to take advantage of that:

public <TYPE> Object load(Class<TYPE> objectClass, Serializable id);

Now, one way of calling this method is as follows:

Person person = mapper.<Person>load(Person.class, 35);

Of course, this does not get rid fo the clutter, yet only moves it by turning the cast into a generic <TYPE> specification.

However, there is another way to call the method that takes advantage of type-inference. Java can figure out the TYPE from the objectClass you pass to the method, so all you need to do is this:

Person person = mapper.load(Person.class, 35);

This achieves clean loading of the object without any necessity to repeat yourself and specify the Person class again in a cast or generic <TYPE> specification.

Thursday, January 03, 2008

Good bye 2006-2007 look

A while ago, I read a fun book called Keep Your Brain Alive. The gist of it is that in order to maintain an optimal mental state and keep the brain on its toes, people must switch their routines often and regularly try out new things. I think that to an extent, this supports the eXtreme Programming philosophy of Embrace Change.

In any case, changing your blog layout can actually be one of these routine changes, so good bye 2006-2007 look!



For the next few days, I will be experimenting with different looks, so don't be surprised if the layout keeps changing.

Wednesday, January 02, 2008

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! :)