by Derek Clarkson ^{(d4rkf1br3 [at] gmail dot com)}

Dnodi Arrives

Well I’ve been busy. Whilst working on Simon’s UI tooling I decided that one of a the features I wanted to add was the ability use a basic XPath style expression to navigate a user interface. For example

/window//myView//myButton

or something similar. I remembered I had some code sitting in dXml which performed basic xpath expressions against a XML Soap message returned from a web service. So I extracted out the code an have been converting it to be a generic library which can execute xpath like expressions against anything that implements a marker interface.

This new library is called dNodi

Here’s an example of using it:

#import <dNodi/DNNode.h>
#import <dNodi/DNExecutor.h>
#import <NSObject+dNodi.h>

...

// The root node of your datastructure.
NSObject<DNNode> *rootNode = ...;

DNExecutor *executor = [[DNExecutor alloc] initWithRootNode:rootNode];

NSError *error = nil;
NSArray *results = [executor executeQuery:@"/rootNode/subnode" errorVar:&error];
if (results == nil) {
   // There's an error!
}
NSObject<DNNode> *firstFoundSubNode = [results nodeAtIndex:0];

This makes things really simple. The nodes must implement the DNNode protocol which contains only 4 methods for returns the sub nodes, name, attributes, etc. so generally speaking it’s not too onerous to implement.

I hope you find it useful.

Simon

You may notice a new tab up the top – Simon is a new framework Ive been writing over the past few weeks. It’s still in it’s infancy, but it’s far enough along to have proven that it can work.

Simon is a BDD framework for iOS simulators and devices. Basically this means that customers can write very simple stories using a DSL, and the developes can then map code to these stories which when run, proves that the app satisfies the story.

I’ve written Simon with several things in mind,

• Customer stories are kept seperate from he code the implements them. This means that they can easily be added and edited at any time without effecting the code base.
• Simon runs on the simulator or device. This saves trying to setup communication channels between the mac and Simon. So there is no need to enable accessibility features and Simon also has more direct access to the app for testing it.
• No hefty setup. Unlike other BDD frameworks I tried, Simon does not require you to modify the setup of your mac or the simulator.
• Easy to use. Activating Simon and mapping story steps to a Objective C methods takes on a single line of code.

So stay tuned, more to come.

Objective C Reflection Finding Classes

Working on a project at home I found I needed a way to locate classes which would be written later. ie. I don’t know what those classes are called. In Java I would do this via Java Reflection which lets me find out information about classes, methods, fields, etc when the program runs rather than when it is written. In Objective C we also have these facilities but they are not quite as easy to use as Java’s version.

Something Kool This Way Comes

I’ve been a bit quiet lately because I’ve been working on something new. I’ve been looking at Behavioural Driven Development tooling for iOS. Apart from the fact that it’s a new tool to add to the arsinel, it’s also a potental way to express application tests in a more english like manner.

So with this in mind I went hunting for tools for iOS. I did find some, but frankly, I was not impressed. The first I came across seemed to combine the Domain Specific Language of the BDD stories. This goes against the idea that BDD stories can be written and understood by non-developers. I wanted to write the stories in one file, and have the framework look up the executable code elsewhere.

the other frameworks I found where better, but had one failing. They required the developers machine to have accessiblity turned on in system preferences and the simulators. Then the developer is required to code accessibility data into the app which means additional work. Im not sure why at this time, but I’m presumig they do this to save on the amount of code they have to write. But overall this felt very ugly.

So I’ve been playing with ideas for a BDD kit of my own. Currently it’s coming together quite well. I’ve got it scanning and understading files that contain BDD stories, mapping them to segments of code and dymanically finding the classes to run. Best of all, this will all run in the simulator or device, something some of the other kits don’t do.

Stay tuned, more to come.

Cgfloat And Coregraphics

Today I was working with ParseKit which is an interesting API for parsing text and making sense of it. I had included it in some test code and got it working. But when I started to include it into my main project I got this error:

In file included from /Users/derek/projects/Simon/classes/SIStoryReader.m:13:
/Users/derek/projects/Simon/../Releases/ParseKit/v1.0.0/ParseKit.framework/Headers/PKToken.h:50: error: expected specifier-qualifier-list before 'CGFloat'
/Users/derek/projects/Simon/../Releases/ParseKit/v1.0.0/ParseKit.framework/Headers/PKToken.h:82: error: expected ')' before 'CGFloat'
/Users/derek/projects/Simon/../Releases/ParseKit/v1.0.0/ParseKit.framework/Headers/PKToken.h:91: error: expected ')' before 'CGFloat'
/Users/derek/projects/Simon/../Releases/ParseKit/v1.0.0/ParseKit.framework/Headers/PKToken.h:177: error: expected specifier-qualifier-list before 'CGFloat'

Very strange. It didn’t make much sense. CGfloat is a core type. Or is it? As it turned out, it’s not. To get it you have to include CoreGraphics. Which means that any program that wants it, regardless of whether it needs CoreGraphics or not, has to include it. So now any time I’m using a type from ParseKit which has CGFloats in it, I have to first include the CoreGraphics header like this:

#import <CoreGraphics/CGBase.h>
...

Top 5 Movies

Just for something different, I was thinking the other day about my favourite movies. Not necessarily classics (geek or otherwise), but the top 5 movies that I regard as my must recommends. These are the movies that when I think about them, send a tingle up my spine. Because the have amazing cinematography, or tell and an amazing story or in some other way – just blow your mind. So without further ado and in no particular order (and subject to change :) ….

• Avatar
• District 9
• Baraka
• V for Vendetta

Sample Liquid Code In Blog Posts

One thing that drove me nuts for a while was how to include liquid code is source examples done in liquid. Confused, yep it can be. To be able to display liquid tags as text and not process them I had to find a way to escape them. Digging around the net and I evetually found an example where it was done and yet again, it’s good old stackoverflow to the rescue.

The essence of the answer is that by placing either single or double quotes before the tags, the liquid engine doesn’t see them as tag, but as just part of the text. For example:

{{ "{{ post.content "}} }}  =>  {{ post.content }}
{{ '{{ post.content '}} }}  =>  {{ post.content }}

And for example code containing tags:

{{ "{% if true "}} %}  =>  {% if true %}
{{ '{% if true '}} %}  =>  {% if true %}

Now if the second example throws you a bit, don’t worry. It took me a while to understand how this really works because it’s not obvious. Hee’s a table which shows each piece of the puzzle and how it’s interpreted.

It’s a bit tricky to get your head around but does make sense. P.S. and if you want to see some nested nested liquid code, just take a look at the raw liquid code for this blog post :-)

Modding Github Blog Posts

Well, looks like I got it wrong. Not the method mind you, but that fact that GitHub supports plugins. Apparently for security reasons they don’t. So whilst this is an interesting exercise, it’s no good for GitHub. Drats! I’ll leave the rest of this post intact because someone might find a use for it :-)

For a while I’ve been trying to figure something out. Some of the posts on this blog are tool long to fit comfortably on the home page. Looking at the standard liquid filters and tags in the jekyll documentation is that I could not see any easy way to truncate a posting.

So the first thing I tried was:

{% for post in site.posts limit:10  %}
    ...
    {{ post.content | truncatewords: 200 }}
    ...
{% endfor %}

Now that truncates the words at 200, but there are several problems with it:

1. This happens after the post has been converted to HTML, and it will truncate at exactly 200 which may be in the middle of a HTML tag or block. This results in unbalanced HTML code and messed up pages.
2. I have no way to indicate that a truncate did take place and therefore no way to know if I should include a … read more link.

I also thought to try and include the filter inside an {% if ... %} statement which could then include the link if necessary like this:

{% for post in site.posts limit:10  %}
    ...
    7 %}
       ...
    {% endif  %}
    ... 
{% endfor %}

But that didn’t work because liquid cannot handle filters inside tags at the present time. So I started searching on the net, posting on stackoverflow, etc.

After some time I came across what was sitting under my nose all the time. Jekyll plugins. Essentially these let you extend the liquid templating engine used by GitHub pages with Ruby classes and scripts. you can add new tags, filters and file processing code.

Part 1 of the answer

Looking through the list I found the summarize filter by Mathieu Arnold. This basically did what I needed, but I wanted a litte more. So with some work (and learning the basics of Ruby), I came up with this version:

module Jekyll
  module Filters
    def summarize(str, moreLink, moreText, splitstr = /\s*<span id="end-intro"/)
      text = str.split(splitstr)
      text.length == 1 ? str : text[0] + "<a href=\"" + moreLink + "\">" + moreText + "</a></p>"
    end
  end
end

Note: my code may not be the best Ruby code. It’s my first after all.

Anyway, to use this now all I had to do was this:

{% for post in site.posts limit:10  %}
    ...
    {{ post.content | summarize: post.url, " ... read more"  }}
    ... 
{% endfor %}

The second parameter being the url I wanted to use for the read more link and the third parameter being the text of the link. Easy.

Part 2 of the answer

Ok, so now I had the truncation and link issues solved. I had to tell the code where to truncate. You will notice the regular expression in the above Ruby code. That basically tells the code to look for the text <span id="end-intro" in the HTML. The filter then takes all the text before it as the introduction to the post. So by adding a span like this:

This is the intro.<span id="end-intro" /> 

This is the next paragraph.

I can tell the filter exactly where to truncate at for the introduction text which is placed on the blog home page.

Added Disqus Comments

Something new on the site. I’ve added Disqus as a comment system for these blog entries. It’s quite simple to setup. A few bits of javascript added to the jekyll templates and it’s done.

I like these things about it:

• It works on static sites such as these GitHub pages
• It’s full featured with moderation and registration.
• Ok – it looks good !
• It’s free for small sites like this.

So if you want to comment on something, feel free. You will need to register on Disqus first which is not hard if you have an OpenId or Gravatar. Or slightly harder if you don’t, but Disqus is being used on a lot of sites and is very good so it’s worth it.

Codehaus Blues

Over the past few years I’ve been on a number of projects which have use various tools from Codehaus. Codehaus is a group of developers which specialise in development tools built for agile developers. server tools, maven plugins, testing tools and the likes. Lately I’ve been testing another one of their tools in anger on an established enterprise and it’s crystalised some of my impressions of Codehaus and their products in general.

A lot of the tools that have come out of Codehaus have been based on a simple developer need and are written to fulfill that need very well. They usually have good or even slick websites extolling how they solve the problem and how easy they are to use.

However they tend to struggle to work in real world development which is rarely as simple as the Codehaus examples. For example, often they follow the convention over configuration paradigm, but are difficult to reconfigure if you are not using the same conventions as Codehaus used. They make assumptions about the situation they will be used in, have non-obvious properties or simply no easy way to change them at all.

Documentation of anything except the authors original environments tends to be very weak. For example, maven support is often we documented, whilst ant is usually minimal. Another example was recently I was looking at a product that did not have any installation documentation because they authors assumed that everyones setup would be as simple as theirs. The Documentation can also be a mixed bag where some parts talk about doing things via annotations and other don’t. Leaving the developer try try and figure out how the two fit together. Further, javadoc tends to be very minimal. Often properties or methods which have hidden side effects are not documented at all.

Codehaus also regularly fail the rule of least surprise resulting in developers spending hours or days trying to figure out why the behavior of a tool is different to what they would expect. For example, I was recently trying to work out how to configure a tool in a situation where the documentation was too vague and didn’t really cover the setup I was working with. I was looking at a abstract parent class of the tool’s main class. It had several properties that seemed to fit the configuration requirements I had. Yet when I set these properties, nothing happened. I looked into the source code to try and figure out what was going on only to see some try – catch blocks which swallowed exceptions silently. Always a bad idea. After a couple more hours I contacted the author who came back (surprisingly quickly) and said that those properties were ignored by the tool anyway. I don’t know about Codehaus design standards but I don’t design classes to silently ignore properties. They either throw errors or do not have that property in the first place.

After one set of but reports, it was suggested to me by the Codehaus developers that I should supply a patch for the particular tool. Which if I had nothing better to do I’d be happy to. Once I had downloaded the source, figured it out enough to fix the problem (not always easy with some of their code) and tested it out. But I don’t have that much time.

Now this is not a complete rubbish of Codehaus and their products. Almost always they have come up with a simple tool to solve a simple problem. The problem is that the simple tool is often being used in a non-simple real world situation. I also get the impression that the developers behind Codehaus regularly tend to release something that is more beta than production code. So now when ever I see Codehause tools being introduced to a project I always mentally cringe. And I’m not the only one.

Older posts

• 01 May 2011 Crema Live
• 14 Apr 2011 Crema Submitted And Android
• 04 Apr 2011 Crema coming *Real* soon
• 11 Mar 2011 Crema coming soon
• 12 Apr 2010 Building universal binaries
• 09 Apr 2010 Reason 1 why code won't compile
• 09 Apr 2010 I'm not really sure about this ....