Separating the Application from the Environment

A useful pattern for developing testable rich client GUI applications is the Humble Dialog Box by Michael Feathers. I have used variations of it for TDD style development of all kinds of Windows programs. It boils down to have a rather dumb view (the humble dialog box) that delegates the handling of its events to a controller object. The controller does all the magic. It talks to the models and does whatever is necessary to react to the users gestures. When it is done it tells the view how to change its state. The view is mostly passive in this process. It receives events (user gestures), delegates them to the controller and receives updated data. It usually does not contain any logic besides what is needed to retrieve any event related data to hand it over to the controller. The controller talks to the view only through an interface. It does not know the concrete implementation of it.

With this approach it it possible to switch to a different GUI library or support multiple libraries in parallel without changing the controller. Use of this pattern enabled me to drive the design of the controllers and models by tests. It also let me migrate parts of an application from the older .Net Windows-Forms (SWF) to the more modern WPF library without even touching the controllers. All I needed to do was creating new WPF views, which called the same services of the controllers as their old SWF counterparts did. The controller would not know the difference as it did not know the difference between the tests that drove its design and the "real" views. Of course this also lets you use different GUI libraries "in parallel". The controllers and models are implemented once and can be used with different GUI libraries on different platforms.

For Web development I usually follow the Ports and Adapters pattern by Alistair Cockburn. Instead of having horizontal Layers stacked upon each other, having the user interface on top and the database on the bottom it puts the business layer(s) in the center and services like the UI and the DB on the outside. For each service need of the application there is a port and adapters that plug concrete services into those ports. E.g. there might be a persistence port and an MySQL adapter or an UI port and a Ruby on Rails adapter. A persistence adapter might be a database specific Repository and a UI adapter would be a controller in an MVC framework. There are multiple architectural patterns that are very similar. The Clean Architecture by Robert Martin explains them in more detail.

Lately I was thinking about how I would implement Ports and Adapters with regards to rich client GUI applications and how it relates to the Humble Dialog Box and then it dawned on me. The "Controller" in the Humble Dialog Box is actually the application specific business logic, the Interactor, the Control Object. The views "code behind" is the UI ports adapter for the used GUI library. The term "Controller" was confusing me in this context, because with the usual MVC web frameworks I use the controller only as an adapter to the business logic. It does not contain any business logic itself.

It basically always comes back to separating the application from the environment. The details of the different approaches might differ, but the big picture is always the same.

A Generic WPF-Control

There are several ways to reference generic types from XAML for bindings. Unfortunately there is no way to define a generic type using XAML.

I needed to port a fancy dialog for selecting from a list of items from Winforms to WPF. The original dialog had a generic type parameter for the type of the items. Something along the lines of public class SelectionDialog<TItem> : Form. This is not possible if you want to design the layout of a control with XAML, because the XAML type definition does not allow to define type parameters.

All I did to circumvent this limitation was to create a non generic dialog class which I designed with the Visual Studio XAML designer. Then I created a second class with a type parameter for the items. This class is derived from the XAML designed class and voilà I got a XAML dialog with a type parameter.

Custom Field Handlers for Views 2 (Drupal)

This is a step-by-step example how to create custom field handlers for Views 2 for Drupal. I needed this information myself and all I could find was not going very deep, at least not as deep as I needed it. I learned all the necessary details by reading other handlers that came with the views module (in views/modules) and by extensive use of print_r().

This is the goal: Extending the scheduler module to be able to view a countdown until a node is published or unpublished. Countdown meaning "How many time units until the node is published or unpublished". This would be the perfect job for the views module. Scheduler already exposes its publish_on and unpublish_on fields for use with views.

Defining the supported views version in file scheduler.module:

<?php
function scheduler_views_api() {
 
$info['api'] = 2;
  return
$info;
}
?>

Defining the table and fields in file scheduler.views.inc:

<?php
function scheduler_views_data() {
 
$tables['scheduler']['table']['group'] = t('Scheduler');

 
// how is the scheduler table linked to the nodes
 
$tables['scheduler']['table']['join']['node'] = array(
   
'left_field' => 'nid',
   
'field' => 'nid',
  );

 
// description of the fields (table columns)
 
$tables['scheduler']['publish_on'] = array(
   
'title' => t('Publish on'),
   
'help' => t('Date/time on which the article will be automatically published'),
   
'field' => array(
     
'handler' => 'views_handler_field_date',
     
'click sortable' => TRUE,
    ),
   
'filter' => array(
     
'handler' => 'views_handler_filter_date',
     
'label' => t('Publish on'),
    ),
   
'sort' => array(
     
'handler' => 'views_handler_sort_date',
    ),
  );

 
$tables['scheduler']['unpublish_on'] = array(
   
'title' => t('Unpublish on'),
   
'help' => t('Date/time on which the article will be automatically unpublished'),
   
'field' => array(
     
'handler' => 'views_handler_field_date',
     
'click sortable' => TRUE,
    ),
   
'filter' => array(
     
'handler' => 'views_handler_filter_date',
     
'label' => t('Unpublish on'),
    ),
   
'sort' => array(
     
'handler' => 'views_handler_sort_date',
    ),
  );

  return
$tables;
}
?>

I am not going to explain this code in detail because it is really simple and everything is documented really nice in the views help. Since we just exposed existing DB fields we only needed to define how the scheduler table is to be joined with the node table. For displaying the values we could rely on a predefined handler for date values (views_handler_field_date). That is the code that we need to build upon.

What we need now is a custom handler because there is no predefined handler for our purpose. At first we need to define the field. Let's start with a simple second count down:

<?php
  $tables
['scheduler']['publish_countdown'] = array(
   
'title' => t('Publish countdown'),
   
'help' => t('Time until the article will be automatically published'),
   
'field' => array(
     
'handler' => 'scheduler_handler_field_scheduler_countdown',
     
'click sortable' => FALSE,
     
'timestamp_field' => 'publish_on',
    ),
  );
?>

Note the handler definition (scheduler_handler_field_scheduler_countdown). Now we need to actually implement the handler. Handlers need to live in their own files. So we create a file scheduler_handler_field_scheduler_countdown.inc:

<?php
class scheduler_handler_field_scheduler_countdown extends views_handler_field {
  function
query() {
   
$this->ensure_my_table();
   
$this->node_table = $this->query->ensure_table('node', $this->relationship);
   
$this->field_alias = $this->query->add_field(NULL,
     
'IF(publish_on AND publish_on > UNIX_TIMESTAMP(),
        publish_on - UNIX_TIMESTAMP(), NULL)'
,
     
$this->table_alias . '_' . $this->field);
  }
}
?>

This handler class derives from views_handler_field, the base class for field handlers. All we need to do is override the query() method, because the countdown value can be calculated via the query. The add field method of the query adds a new field to the query (dooh!). We need a field in the query result that is calculated like this: publish_on - UNIX_TIMESTAMP(). The rest of the condition statement is to limit the calculation to time stamps that represent future times. This is the actual query that will be performed to determine the fields for a view containing the countdown:

SELECT node.nid AS nid,
       node.title AS node_title,
       IF(publish_on AND publish_on > UNIX_TIMESTAMP(),
           publish_on - UNIX_TIMESTAMP(),
           NULL) AS scheduler_publish_countdown
    FROM node node
    LEFT JOIN scheduler scheduler ON node.nid = scheduler.nid
    WHERE node.status = 0

We are not done yet. All handlers must be declared in the _views_handlers() hook which can be implemented in the module.views.inc file. So we extend scheduler.views.inc with this function:

<?php
function scheduler_views_handlers() {
  return array(
   
'handlers' => array(
     
'scheduler_handler_field_scheduler_countdown' => array(
       
'parent' => 'views_handler_field',
      )
    )
  );
}
?>

That's all for a simple countdown field. It can be added to views and shows the number of seconds until a node will be published. Our handler only supports a countdown for the publish_on field because that's hard coded into our query. We can provide all the additional parameters we need in the 'field' array:

<?php
  $tables
['scheduler']['publish_countdown'] = array(
   
'title' => t('Publish countdown'),
   
'help' => t('Time until the article will be automatically published'),
   
'field' => array(
     
'handler' => 'scheduler_handler_field_scheduler_countdown',
     
'click sortable' => FALSE,
     
'timestamp_field' => 'publish_on',
    ),
  );
?>

Now we can change the handler like this:

<?php
    $time_field
= $this->definition['timestamp_field'];
   
$this->field_alias = $this->query->add_field(NULL,
     
'IF('.$timestamp_field.' AND '.$time_field.' > UNIX_TIMESTAMP(),
        '
.$time_field.' - UNIX_TIMESTAMP(), NULL)',
     
$this->table_alias . '_' . $this->field);
?>

Since the name of the actual field is now variable we can add a field for a unpublish countdown:

<?php
  $tables
['scheduler']['unpublish_countdown'] = array(
   
'title' => t('Unpublish second countdown'),
   
'help' => t('Time until the article will be automatically unpublished'),
   
'field' => array(
     
'handler' => 'scheduler_handler_field_scheduler_countdown',
     
'click sortable' => FALSE,
     
'timestamp_field' => 'unpublish_on',
    ),
  );
?>

If scheduler will support scheduled promotion/demotion of nodes or any other action, we can add countdown fields really easy.

But we still only have second countdowns which are actually not really that useful. We would like to have all kinds of countdowns, like in minutes, hours, days and weeks. But we are not going to create handlers for all those values and a fixed definition of fields for those values is also not so nice. How about making the field definition and the handler more generic regarding the actual display format of the countdowns. That's where field options come in handy.

Until now the custom field handler is pretty simple because it only manipulates the database query to provide derived fields. Now we want to alter the rendering of the fields. The user should be able to select how the countdown should be displayed, e.g. its units of scale. It should also be possible to select how the unit should be displayed. At first we need to define the options form in the options_form() function of the handler. We want the user to able to select seconds, minutes, hours, days or weeks as unit of scale and we also want a smart mode which figures out which unit would be best for the current value of the countdown. For the display of the units the user should be able to select long units (e.g. "4 days" or "6 weeks"), short units (e.g. "4d" or "6w") or no units at all.

<?php
 
function options_form(&$form, &$form_state) {
   
parent::options_form($form, $form_state);
   
$form['countdown_display'] = array(
     
'#title' => t('Display countdown as'),
     
'#type' => 'radios',
     
'#options' => array(
       
'smart' => t('Smart mode'),
       
'seconds' => t('Seconds'),
       
'minutes' => t('Minutes'),
       
'hours' => t('Hours'),
       
'days' => t('Days'),
       
'weeks' => t('Weeks'),
      ),
     
'#default_value' => $this->options['countdown_display'],
    );
   
$form['units_display'] = array(
     
'#title' => t('Display time units'),
     
'#type' => 'radios',
     
'#options' => array(
       
'long' => t('Long (e.g. 3 days)'),
       
'short' => t('Short (e.g. 3d)'),
       
'none' => t('No units at all'),
    ),
     
'#default_value' => $this->options['units_display'],
    );
  }
?>

This code defines two option fields as radio buttons. We need to tell views that there will be two options with default values:

<?php
 
function option_definition() {
   
$options = parent::option_definition();
   
$options['countdown_display'] = array('default' => 'smart');
   
$options['units_display'] = array('default' => 'long');
    return
$options;
  }
?>

Now the user will be presented this two options, but they will still have no effect. We need to define how the field values will be rendered. A field handler can define a render() function for this task. If there is no such function a value will be displayed as the database query returns it.

Let's define the scale values and the unit names first:

<?php
 
const SECOND_SCALE = 1;
  const
MINUTE_SCALE = 60;
  const
HOUR_SCALE = 3600;
  const
DAY_SCALE = 86400;
  const
WEEK_SCALE = 604800;

  private
$render_params = array(
   
'seconds' => array(
     
'scale' => self::SECOND_SCALE,
     
'singular' => 'second',
     
'plural' => 'seconds',
     
'abbreviated' => 's',
    ),
   
'minutes' => array(
     
'scale' => self::MINUTE_SCALE,
     
'singular' => 'minute',
     
'plural' => 'minutes',
     
'abbreviated' => 'min',
    ),
   
'hours' => array(
     
'scale' => self::HOUR_SCALE,
     
'singular' => 'hour',
     
'plural' => 'hours',
     
'abbreviated' => 'h',
    ),
   
'days' => array(
     
'scale' => self::DAY_SCALE,
     
'singular' => 'day',
     
'plural' => 'days',
     
'abbreviated' => 'd',
    ),
   
'weeks' => array(
     
'scale' => self::WEEK_SCALE,
     
'singular' => 'week',
     
'plural' => 'weeks',
     
'abbreviated' => 'w',
    ),
  );
?>

Because we defined the above array of unit properties we do not need a switch-statement for the render function:

<?php
 
function render($values) {
   
$countdown_display = $this->options['countdown_display'];
   
$value = $values->{$this->field_alias};

   
# what about the "smart" scale?
   
$params = $this->render_params[$countdown_display];

   
$scaled_value = round($value / $params['scale']);
    switch (
$this->options['units_display']) {
      case
'long':
       
$rendered_value = format_plural($scaled_value, '1 '.$params['singular'],
                           
'@count '.$params['plural']);
        break;
      case
'short':
       
$rendered_value = $scaled_value.$params['abbreviated'];
        break;
      case
'none':
       
$rendered_value = $scaled_value;
        break;
    }
    return
$rendered_value;
  }
?>

This code does not handle the "smart" scale option yet. We need to examine the actual value and check if it is larger than the scale value of each unit. We want to use the largest unit possible. E.g. if the value is 30 we want seconds as the unit, if the value is 61 we want minutes as the unit (and so on). Just replace the comment in the code above with the code below:

<?php
   
if ($countdown_display == 'smart') {
      if (
$value > self::WEEK_SCALE) {
       
$countdown_display = 'weeks';
      }
      elseif(
$value > self::DAY_SCALE) {
       
$countdown_display = 'days';
      }
      elseif(
$value > self::HOUR_SCALE) {
       
$countdown_display = 'hours';
      }
      elseif(
$value > self::MINUTE_SCALE) {
       
$countdown_display = 'minutes';
      }
      else {
       
$countdown_display = 'seconds';
      }
    }
?>

That's it. We are done. The user can now include a countdown until a node is published or unpublished in her views. Actually it should be quite easy to use our handler in other modules for other kinds of countdowns.

The final code can be found here: scheduler.views.inc and scheduler_handler_field_scheduler_countdown.inc

Does TDD lead to inefficient algorithms?

Bob Martin showed in a recent blog post "Echoes from the stone age" how TDDing a sorting algorithm would lead to good ol' bubble sort. That stirred up a heated discussion if TDD is really worth it, if it leads to "inefficient" algorithms.

Nobody ever claimed that TDD is supposed to find algorithms that are optimized. TDD at function level defines the behaviour of functions. The behaviour of a sorting algorithm is that an initially unsorted list is sorted after the algorithm has been applied. Well, that's exactly what bubble sort does.

What are you optimizing for anyway? Speed? Memory consumption? Those are behaviour too (temporal and spatial), but they were not specified in Bobs requirements (a.k.a. tests). If you need a sorting algorithm that sorts a certain number of elements with a certain initial order in a certain time, you can specify that in a test (some testing frameworks support performance test, e.g. AUT). Bubble sort might fail that test. So what? That's the reason why we write tests first. We want to see it fail so we can fix it.

Because we have all the nice tests in place that test the external, non-temporal behaviour we can go and read about sorting algorithms and eventually throw out all that bubble sort code in favour of quick sort. Our tests will find out if we made a mistake. We will know if we break something and our latest test tells us if the chosen algorithm is fast enough for our requirements.

The test might even tell us that bubble sort is good enough. Why waste time on a super efficient algorithm if you need to sort a small number of items that are usually in order, but sometimes a new element is added to the list our of order. Bubble sort does that in one pass. You wont need quick sort, if the average number of items is 10.

Oh, by the way: You don't want to be caught committing premature optimization anyway, do you?

Large font for code editors

People always talk about how to gain screen real estate for their IDEs/code editors in order to have more code visible. Why do we need to have lots of code on the screen? What’s the benefit? Do I need to see more than the function I am currently working on? Not really.

About a month ago I set the font in all my editors to Consolas 12. This leaves me with just 45 lines in plain editors and about 30 in IDEs with a panel at the bottom. But that’s stupid isn’t it? With a 30” screen and a 9pt font you can get about three gazillion lines of code displayed. I will tell you a secret. If you keep your functions small and tidy you wont need more than 30 lines. Try it yourself. It helps keeping focused at the job at hand.

Implicit Type Parameter for Implementing Type

A while ago I had an interesting twitter discussion with Chris Ammerman (@cammerman) about type parameters of generic interfaces (C#). Chris tweeted "I often encounter a situation where I want a generic interface, but the type param should ALWAYS be the type of the implementing class". One example of this is ICloneable. Would it ever be acceptable for ICloneable.Clone() to return an object of a type other than the implementing type of the interface? With ICloneable you will always want to cast the result of Clone() because most of the time you want The Real Thing® instead of System.Object. For that reason many people create their own generic interface:

public interface ICloneable<T>
{
T Clone();
}

public class Foo : ICloneable<Foo>
{
Foo Clone() { /* implement me */ }
}

This is still ugly. I want this instead:

public interface ICloneable
{
implementer Clone();
}

public class Foo : ICloneable
{
Foo Clone() { /* implement me */ }
}

implementer would be a keyword like base or this but it would not refer to an object but to a type. It would behave as an implicit type parameter to the interface. This would not only be convenient syntactic sugar. It would also make the use of the parameter explicit. You couldn't do class Foo : ICloneable<Bar> anymore.

List of Tweets:

Powered by Drupal, an open source content management systemCreative Commons LicenseSyndicate content