Mark Cipolla

Over at SitePoint, I’ve just published my latest post: A Guide to WordPress’ Custom Write Panels.

That’s where Custom Write Panels come in: they let you create slick-looking panels that allow users to enter all the additional information you want for a post.

These ‘can help you leverage the power of WordPress 3.0′s custom post types to even greater effect. (And I) show you how to wield them, so your clients will see you as a true WordPress wizard.

To have a read, check it out.

I just published the second of a series of posts over at SitePoint about wrangling every ounce of performance form your CSS.

In any web page, the order that your browser downloads your content is simple: it retrieves the HTML, which tells it the other files to request from your server, while your CSS provides all the styling to make it display as needed.

Improving front-end performance is shown to have an impact on overall conversion, including click-through rates, average time on site, sales, and even Google rankings.

Have a read. I think I’ve covered some interesting points.

Over at SitePoint, I just published the first of a series of posts about optimising your website for speed.

A web page will make many requests. The first is for the HTML of the page you’re viewing. From that, your browser will request more resources to display the page. A single request has two phases: your browser asks for a file–be it an image, a CSS file, or a JavaScript file–and waits to hear back; then it downloads what the browser sends. Therefore, there are two optimizations that can be made: by decreasing the number of requests, you reduce the amount of time the browser spends waiting to hear back from the server; and by limiting the file sizes of the objects being requested, your browser downloads less information to display a page.

An overview of the posts to come, so have a read, but I delve into the nature of requests (and how browsers handle them), and optimising CSS/JS/Images.

I’ve started blogging over at SitePoint, and did a bit of a write up on a couple of the features of Adobe Illustrator CS5.

With the latest incarnation of the Adobe Suite, Illustrator CS5 brings a slew of new features and improvements to one of my favorite apps.

Thankfully, Adobe has considered what worked and, more importantly, what did not: the main feature additions center on actual drawing.

Have a read

Early designs; I started to work out the heirachy of information presented...

After a few versions of working and reworking the UI for the Hudson Global Dashboard, I quickly realised that it needed a rethink of how the UI elements were displayed.

The primary problem was priority: not every element of a build is as important to the others, and not every build as whole to the other builds.

After discussing it with my peers (the people who, ultimately, would be using it), I discovered that they were interested in achieving different goals than I originally anticipated.

• The title was the most important thing. Full stop. Also, it should be able to be read across the room (whilst being displayed on a 19″ monitor.
• The health of a build. Is it passing? And if not, how long for?
• Everything else is secondary.

I tried using the alignment to display health. Aligning right meant everything was all right...

I had the original breakdown of elements like this: a build could be green, blue or red (passing, testing, or failing respectively). This was the background colour. The stats of a build (it’s health over the last five builds, it’s IP address, it’s description) were displayed very small across the bottom of a build for those interested, but it wasn’t important to the passer by. Every build was the same size, and the builds as a whole expanded to fill the screen.

This worked, I guess, as it’s users could, at a glance whilst walking around the office, know which builds were failing.

Surely there had to be, however, a better way to mix elements of the build with it’s appearance. So I started looking.

Infographics are awesome things; they let a casual viewer glance at immense amounts of information, and immediately take in some information without having to read lots of text.

So what is really important when it comes to builds? I figured out, in descending order:

1. Which build?
2. Is that build passing?
3. How healthy has that build been?
4. Everything else: the IP address, it’s description, etc…

Which build?

This one is easy to tackle. The title. It has to be big, so it can be read across the room from a small monitor, so much larger font size than everything else. Also, colour schemes have to be contrast-y enough so it doesn’t blend.

Is that build passing?

Also easy to tackle. Colour. I decided a simple red – green – blue scheme, with it getting progressively less luminance as the importance of details decrease; A failing build is red, with the brightest red for the title, and less bright for the details as they go down in relevance.

How healthy has that build been?

I found a nice grid structure shows health nicely.

I had a bit of fun with a build’s health. I do show the build’s health in text (although it is of less importance to if the build is passing right now…), but instead had a think of what the health of a build actually means to the end user (a developer, or a business unit guy, etc…).

If a build isn’t healthy; as in, it hasn’t been consistently passing for a number of progressive builds, then there a problems that need addressing.

Be it lax attitudes of the developer’s part (committing untested code… naughty naughty), or problems with environment consistency (tests pass locally, but fail on the CI machine, or vice-versa), or fragile tests (those that need to be run in a certain order, or fail one-in-every-x-number-of-times), this is the stuff that directly impacts and hampers development velocity.

Hence, size. The larger a build (and hence, less healthy), the more devs and business units are going to be concerned with it. If it is getting larger, then that build needs an investment of time and energy to get it back on track. Hudson’s JSON API lovingly provides a description of a build’s health, in percentage (it is really out of five; 0 means a build has failed all of the last five runs, 1 means one of the last five, etc…)

So we ended up with some really large, red builds indicating neglect (as we have Hudson set to run a build every now and again; I think it runs them daily if no pushes occur). You can also have a moderately large green build (as it has finally passed a run!), but with luck (and work to keep it so) the build will decrease in size and stay green.

Ideally, you want small, green builds. If they are all small, the problems you have keeping them so is small. If you have big, red builds, then you have large problems.

But where it works is when you have multiple teams (or pairs, depending on your structure) showing multiple build sets. In this case, you’ll probably get a mix of healthy (small, green) builds interspersed with builds in need of some love (big and red). This I think would be especially useful for project managers; they can see what builds are in trouble, and send in those who are better at testing to help out and upskill. I’ve found in the teams that you’ll have one or two testing gurus, who can make tests sing and fix those pesky environment problem.

Caveats

Naturally, there are caveats. Some builds are just old and haven’t been removed. These naturally will decay over time and as their dependencies are altered, removed or decay themselves these builds will go red and get larger. I’ll be building in a selection option so you can opt out of displaying these builds when the time comes to cull them, without necessarily having to remove them from your Hudson builds.

Also, sometimes builds will go through rough patches… A flurry of commits to try and sort out a build may temporarily make it look a problem, but then get sorted within a few days. Keeping the business units calm during these periods would, hence, be necessary.

Environment problems are just a pain. They crop up from time to time, and can plague builds for ages until they are sorted, if at all.

How was it built?

I’d already rebuilt it on Padrino, so using that I reworked the templates to give it a semantic HTML5 layout.

I’ve been playing with David DeSandro‘s JQuery Masonry, which lets you build stronger grid layouts by absolutely positioning around floated objects. Have a look; this guy is a genius…

Colour scheme is a combination of four or five Adobe Kuler sets; ever a great combination of colour palettes for a designer.

Where to?

So it’s mostly done. Of course, it’s a prototype, and I’ve written no tests around the app that handles testing (I know! Horror!).

Depending on commitments, I’d like to rewrite it, and clean it up where I had a bit of code smell.

Also, I started to write in a TramTracker block that fits in the layout, so you can see when the next trams outside the office are coming. Of course, some of the guys I work with suggested not showing this block until every build is green…

…

I thought of that, but then we’d never get to go home.

In the previous post Thoughts on Cucumber testing: Features, I went into how features work, how they should be written, and for whom their intended audiences are.

Step definitions are the bridge between human readable tests and actual tests that cucumber can understand.

Essentially, step definitions can be broken into two parts:

• The regex part, where the human readable test can be match appropriately to a step.
• The actual tests, where actions are taken or assertions are made.

I’m just going to jump right in, and explain line by line. Here is an example of the step definition for a given step, which is testing the navigation to a group of pages.

1
2
3
4
Given /^the buyer is on the "([^\"]*)" state search page$/ do |state|

  state = state.length > 3 ? State::AUSTRALIAN_STATE_NAMES.index(state) : state

  visit 'http://www.example.com/' + state.downcase

end

It seems that there is quite a lot going on, but it’s really not too bad.

1
Given /^the buyer is on the "([^\"]*)" state search page$/ do |state|

This is the regex part of the step. It is matching on any step that contains the string ‘the buyer is on the “some state” state search page’.

The ([^\"]*) in the middle will match any terms between ‘the buyer is on the ‘ and ‘ state search page’. Now, when used with ‘do |state|’, it will take whatever the term inside the regexed string and make it available as a variable. So, if in the feature file the step read:

Given the buyer is on the VIC state search page

It would match the step definition, and the variable ‘state’ would equal “VIC”.

1
2
Given /^the buyer is on the "([^\"]*)" state search page$/ do |state|

  state = state.length > 3 ? State::AUSTRALIAN_STATE_NAMES.index(state) : state

Now, knowing what state equals, we do some work with the string. If it’s more than three characters (in this example), we match it against a list of state names to find out what we meant. This is so we can enter both VIC and Victoria as strings.

1
2
3
Given /^the buyer is on the "([^\"]*)" state search page$/ do |state|

  state = state.length > 3 ? State::AUSTRALIAN_STATE_NAMES.index(state) : state

  visit 'http://www.example.com/' + state.downcase

This is what given steps will usually do. Given steps (depending on the project) usually do one of two things: having users at pages, and setting up DBs or previous things that are assumed to have happened before the test begins (such as creating users, setting permissions, etc). This step goes to the page using the visit method.

1
2
3
4
Given /^the buyer is on the "([^\"]*)" state search page$/ do |state|

  state = state.length > 3 ? State::AUSTRALIAN_STATE_NAMES.index(state) : state

  visit 'http://www.example.com/' + state.downcase

end

And finally, the ‘end’ ending the step definition.

As you can see, this is where the human readable part of a feature meets actual code doing some tests.

‘Then’ steps are where you can see some assertions happening. All assertions happen in the steps; there shouldn’t be any assertions anywhere else (mainly, keep them out of the page model).

1
2
3
4
5
Then /^the "([^\"]*)" link will have a new icon$/ do |link|

  on_page_with :sub_navigation do |page|

    page.sub_navigation_item.url.should eql link

  end

end

The on_page_with method calls the page model, which we will go into later. For now, we set up methods against the page. The next line is what we are interested in:

1
    page.sub_navigation_item.url.should eql link

The page has a method called sub_navigation_item, which in the page model has a css selector to find the list (inside a li inside an ul) in question, and checks it has a url from the link passed in via the feature.

Tests will grow in complexity, and this is okay, but always strive to make your tests as simple as possible, and as readable as possible. When an assertion can be written as:

page.sub_navigation_item.url.should eql link

and read as “the page subnavigation item has a url that equals this link”

It took me a while to get testing. To be honest, there are still bits I just don’t quite understand.

Since we build on Rails, automated testing is handled using cucumber. The tests are split into two main parts: features, which are the human readable tests, and the step definitions, which are the actual tests, converting the human readable parts into ruby so we can actually make assertions against what we are testing. The page model also gets mixed in, but I’ll get to that.

I’ll only go into features for now; I’ll get to the step definitions and page model work later.

It is, however, very easy to start making mistakes when writing tests that makes life later much harder, especially when it comes to refactoring time (either for manipulating features, or speeding up a build).

Features

• The features are meant to be as easily read as possible.
• Though it can be great to re-use existing features (especially around when setting conditions to go to a page), you really shouldn’t trade readability for ease of testing. Try and find a happy compromise, or rewrite the existing tests to make them more generic (where appropriate). Be careful, though, to not prematurely over-generalise tests, as they make it a really hard slog later.
• The features should be able to be read, and understood, by non-techs. Business / Product owners and business analysts, as well as QA, should really know what’s going on when they’ve read them.
• Basically, they should be based on the feature cards created by business stakeholders / experts.

They are broken into three (and a third) parts.

Given steps

• Given steps are used only when there are things that have to have happened prior to the test. There are no actual assertions in these (so nothing actually gets tested), and page models shouldn’t be involved yet.

1
Given articles have been written by an editor

When steps

• When steps also have no assertions. They are for when a user (or equivalent) performs an action against the page. Clicking links, opening menus, or performing searches are all When step material.
• Also, When steps start to have actions against the page model (explained below).

1
When the user clicks on the "delete post" button

Then steps

• Then steps are the assertions. Something has happened (be it a page load, or a link clicked, etc), and hence, there is a test against it. It is oft best to only test one thing per step, but there are exceptions, and my personal preference is to test one element at a time, so when I test a link, for example, I’ll usually test the href, the title, and any rel attributes as well as the anchor text.
• Then steps also have actions against the page model (explained below).

1
Then the user will see the post has been deleted from the list

And steps

• And steps aren’t steps in their own right, but they perform the same type of step as the previous one. It lets you chain up a series of user interactions, or assertions.

1
2
And the user will see the post flash to alert the user it has been deleted

And the user will see the post displaying the "Deleted" text

Put it all together, and you get a nice test.

1
2
3
4
5
Given articles have been written by an editor

When the user clicks on the "delete post" button

Then the user will see the post has been deleted from the list

And the user will see the post flash to alert the user it has been deleted

And the user will see the post displaying the "Deleted" text

In conclusion

I hope that makes some sense. The cleaner you write your tests, the easier life comes later. In conclusion, one simple rule to live by:

Write your test as simply as possible, so it’s meaning is clear and someone else (who isn’t developing the project) can understand what’s going on.

I’ll get through the other parts of writing tests (the step definitions and the page model) soon.

As they say themselves on the Padrino site:

Many people love the simplicity and expressiveness of Sinatra but quickly come to miss a great deal of functionality provided by other web frameworks such as Rails when building non-trivial applications.

Our goal with Padrino is to stay true to the core principles of Sinatra while at the same time creating a standard library of tools, helpers and functions that will make Sinatra suitable for increasingly complex applications.

Relatively quickly, after writing the first versions of the Hudson Global Dashboard using Sinatra, it started to get a little too big for it’s boots.

Sinatra quickly let me get something out there; I could handle the routes, and perform simple tasks to display the appropriate JSON feeds in a meaningful way. But there were features I wanted; features that, should I add them, would mean probably pushing Sinatra beyond what it was meant for.

Enter Padrino. Luke Cunningham (a rubyist and UI guy of equal measure) put me onto it, and helped me through getting the hang of how things are put together with it.

It’s the next step when your app grows too large for Sinatra. My main requirement was wanting an admin panel, so users could add Hudson servers willy-nilly, and not have to hard-code them.

Padrino is the step up from Sinatra, and a step below the complexity of a full Ruby on Rails stack. And I’m a bit of a fan. It’s really easy to bolt new sections onto, yet still letting you hit the ground running. Give it a try.

So, Ruby on Rails is pretty sweet.

But there are definitely times when the full stack of Ruby on Rails is just too much; you want ruby, but not necessarily a full MVC.

This is true, in my case, when I wanted to write a small app for showing Hudson build statuses. It really only has one screen, showing the status of as many builds as I have. That’s it.

Enter Sinatra. A really lightweight DSL that lets you get the job done, with a minimum of fuss. The example below is seriously as simple as it gets; after the gems are required by the app,  and it has been run, when a user enters on ‘/’ (the root level of the app, so http://localhost:4567/), they get a hello world.

#myapp.rb
require ‘rubygems’
require ‘sinatra’
get ‘/’ do
‘Hello world!’
end

It also has support for routing, public folders for your css / js, and templates / views. I’m not trying to sell it, as it’s not useful for every scenario (far from it), but I like it. It will let you get coding in a snap, and for those little helper apps, it’s a dream. Installation and running the app is literally:

sudo gem install sinatra
ruby myapp.rb

Have a play. Its quite fun to just be able to jump on in.

As part of spiking the abilities of a HTML/CSS/JS/Ruby on Rails driven mobile app, I’ve been spending a fair bit of time exploring the different mobile frameworks available to help speed up development.

The big three, as the title indicates, as IUI (the first mobile, primarily iPhone, dev package), JQTouch (based of a cut down / optimisied version of JQuery), and PastryKit (Apple’s completely undocumented package used for some of their help systems).

Each has a distinctly different flavour, and I had my concerns going in to using a framework at all. I’m a big fan of writing my own code, from scratch. That way, I know my code, and I like my personal coding style; I really dislike some coding styles, and find them just plain difficult and unproductive to work to.

JQTouch

JQTouch is by far the best presented of the pack. It has it’s animation code running on the JQuery library, and it rather lean, coming in at 3.5kb for the JS and a total of 3.4kb for the CSS (including both the primary styles, as well as running one of the supplied themes).

First time around, I was a little put off by its implementation; their example has JS code in the head, and their HTML structure is a little haphazard. But after a bit of a play (upon a second looking), it seems to make a fair bit of sense.

Of course, it does add a few lines to your head:

1
2
3
4
5
<script type="text/javascript" src="http://www.google.com/jsapi"></script>

<script type="text/javascript"> google.load("jquery", "1.3.2"); </script>

<script src="jqtouch/jqtouch.min.js" type="application/x-javascript" charset="utf-8"></script>

<style type="text/css" media="screen">@import "jqtouch/jqtouch.min.css";</style>

<style type="text/css" media="screen">@import "themes/jqt/theme.min.css";</style>

Only a few. And to be honest, its only realistically four (you’re probably already including JQuery). After you’ve included the files, there’s a small bit of JavaScript to begin the process, and you’re done.

Now to the interesting part. The structure is different to how you’ve probably coded before, but not necessarily bad. A little light, or incorrect perhaps, in places, but easy enough to pick up and run with. Essentially, JQTouch provides the ‘native’ looking animations from page to page. But, and here’s the clincher; it requires you to have any page that you have an animation to be in the same source code. Let me explain: a user comes onto your mobile site, and sees the home page (this is a div#home). They click a link to go to section one (a link with a href of #section1) and it does a fancy page flip (the anchor has a class of flip) and the next page is section one (oddly enough, div#section1).

It relies on anchors and naming to figure out what links to what. Not necessarily a bad thing, but perhaps a pitfall if you are relying on server-side response to occur (a form gets submitted, page refreshes won’t use the flip animation). In a nutshell, your code will look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<div id="home" class="current">

  <div class="toolbar">

    <h1>jQTouch</h1>

  </div>



  <ul class="rounded">

    <li class="arrow"><a href="#section1">Section One</a></li>

    <li class="arrow"><a href="#section2">Section Two</a></li>

  </ul>



</div>



<div id="section1">

  <div class="toolbar">

    <h1>Section One</h1>

  </div>



  <ul class="rounded">

    <li class="arrow"><a href="#">Link</a></li>

  </ul>



</div>

It’s quite easy to work with. The visual styling is quite sharp, and you can change the theme (from the two ones provided) in a snap, as well as create your own.

The only downside is that you have to use exactly their HTML structure. Deviance from this means you page breaks, animations don’t work, and your app looks rubbish.

IUI

IUI is the oldest of the frameworks. I’ve never been a fan; their structure of code just grates me the wrong way.

It works in much the same way, has a lighter HTML structure, but in that lies the problem; it forces you to reduce your layout to a list. I like simple code; it’s just that not all the content should be displayed on a list. It just isn’t semantic. I want forms. I want content area.

1
2
3
4
5
6
7
8
9
10
11
12
13
<ul id="home" title="iUI Demos" selected="true">

  <li><a href="#about">About</a></li>

  <li><a href="#samples">Samples</a></li>

  <li><a href="#3rd-party">3rd Party Samples</a></li>

  <li><a href="#tests">Tests</a></li>

  <li><a href="#sandbox">Sandbox</a></li>

</ul>



<ul id="samples" title="Samples">

  <li><a target="_blank" href="samples/music/music.html">Music</a></li>

  <li><a target="_blank" href="samples/prefs.html">Prefs</a></li>

  <li><a target="_blank" href="samples/digg/index.html">Digg</a></li>

</ul>

It’s just not as slick as JQTouch. It feels clunky on the phone. It’s heavier than JQTouch (coming in at 18.9kb for the JS, and 11.8kb for the CSS). I’m sure people are using it, and using it well, but I cannot shake the feeling it’d be a bad match for me; I’d prefer a little complexity, so I have the freedom to work in the content I want.

PastryKit

PastryKit is Apple’s undocumented not-yet-released framework for making iPhone web layouts work like native. It’s very pretty, but this prettyness comes at a cost: there’s no docs, no help, and using it probably will get your app banned (Apple’s obscure denial rules, of course). To check it out, open http://help.apple.com/iphone/3/mobile/ on your iPhone. Any other browser gets detected, and blocked.

Have a read of Daring Fireball’s post. I had a play, but without a lot of time, nor the inclination to reverse engineer the HTML structure (it blocked me, even when I changed my user agent string), I’ll just wait until Apple reveal it to the public.