This is the first entry in a semi-regular series sharing things that we’ve been looking at and reading recently …

Sarah (one of our project managers)

• Broadband becomes a legal right in Finland

• Guggenheim collaborates with YouTube and invites video submissions

Sue (one of our designers, recently returned from a break in the sunny northern hemisphere)

• Eye-candy and inspiration on www.citid.net

• Great experimental fonts (also: free!)

• Lighten up your winter blues: heaps of colour and shapes on Coolhunter

Alastair (one of our developers)

• Firefox 4 introduces more HTML 5 and CSS functionality. One step further towards the death of Flash? Still in beta so one for the developers.

• Excellent! Wayne and Garth spotted in the UK. Party on!

Rachel (our office manager)

• Artist creates masterpiece on an iPad

• World Cup 2010 statistics: all the key data for each team, from the Guardian

(Rachel notes that she’s not as much of a sports fiend as the above link might suggest, and also recommends data/infographic blog Cool Infographics)

Jake (who looks after our usability testing tool IntuitionHQ)

• David Gillis on Fusing Content Strategy with Design, in UX Magazine

• The Real Life Social Network, slides from a presentation by Paul Adams, Senior User Experience Researcher at Google

• Gnarcade – Video Game Invasion: for video game fans, and geeks in general

Courtney (that’s me – project manager)

• Aaron Straup Cope’s magical slippy map showing the world as revealed by geo-tagged photos on Flickr

• Significant Objects, an investigation of art and the market through short stories and eBay

• Swallows and Amazons, the current exhibition at Robert Heald Gallery, which is close to our office – on show until 31 July.

During a brief slow period on a Friday afternoon I started pondering how much work I actually do, and if it was even useful knowing. Obviously all our code is stored in a version control system (git), so in a way all of the data for finding out the quantity of work is readily available. A little investigation and I found that it’s quite easy to pull a list of commits from git showing total lines added and deleted per file:

git log --oneline --numstat

I’ve committed a lot of code that I didn’t write, such as plugins, the Rails framework etc. So a quick and dirty ruby script later I could get a list of all unique files in all repositories that I’ve committed to. It was pretty easy to go through the list and create an exclusion list. I then broke out Ruport to aggregate everything by extension. That gave me the following table:

I’ve cleaned this up a little and collapsed some alternative extensions down.

Commits per week

Just over 110,000 lines added and 50,000 deleted, of which about 100,000 are to Ruby files. Now I’m not claiming to have written all those lines myself, any part of any line changed counts towards the total. All this does is illustrate the general balance of work that I do. There have been two lines added for every line deleted. This year has seen a lot of refactoring work, so it’ll be interesting to run the same exercise next year and see if the results are similar (of course git holds historical data, but we only started using it about 18 months ago, and previously had everything stored in subversion).

It’s interesting to see that the proportion of additons to deletions is much higher in view (rhtml/haml) files than in ruby code. This could point to the way things look being changed much more than the way things work.

Now if only there was a way to measure the quality of work. (Actually there are tools; metric_fu is a good starting point and we use it a lot at Boost. However, that’s going a little too far for this post).

Another interesting bit of data I extracted from git is the number of commits I’ve done per week over the last 52 weeks.

I’ve posted my script as a github gist. You  can run it by modifying the @repositories array with a list of git repositories, @author with your email address and @excludes with a list of regular expressions for excluding files. Run the script as ruby gitcount.rb. If it is run with the argument “files” then it will list individual files, making it easier to build the exclude list.

DrupalSouth, an annual gathering of Drupal people from around New Zealand, happened over the long weekend here in Wellington.

The venue was Mac’s Brewery; a great location on the Wellington waterfront, a good venue for a conference of this size and of course geeks love good beer, it’s a fact.

Alastair (a fellow Boost developer) and I presented a talk on beginning Drupal module development at one of two Sunday morning red-eye sessions. Our presentation focused on getting people started with Drupal module development. The intention was to give simple examples of how you can tap into Drupal hooks and other elements of the API, such as the Form API.

Pitching a technical talk to beginners is always difficult depending on the background of the audience, hopefully it’s simple enough to understand while giving enough information for those who are raring to go.

The presentation slides and our sample code are available to download.

• Presentation slides
• Sample code

Any feedback will be appreciated, please feel free to comment.

We’ve been using Kanban for a few weeks now on some projects, taking over from Scrum where appropriate. We’ve used the Kanban process for projects in ongoing maintenance and for those that seem more like a list of tasks to be performed (Drupal CMS integration).

Pros

• Forces workflow.
• Easier to see each task’s status – it has a place in the workflow instead of being not started / working / complete as with scrum.

Cons

• Less satisfaction – you don’t see the burndown or how much work you’ve personally completed.
• Kanban is more about a flow of tasks, and one premise is that the number of tasks in each stage of the workflow is restricted. This can be difficult when there are tasks that must be dealt with by different team members – for example design tasks verses programming tasks. A design task may take up a slot in the workflow for a long period of time.
• Kanban can’t express dependent tasks. This sometimes causes tasks to move back and forth along the workflow to free spots for the tasks they depend upon. Scrum has a less confusing way of showing what’s happening.
• Harder to see overall project status. This is a problem when working with Kanban for the whole project, but not for projects in maintenance mode.

Some of these cons are things that we need to work around by improving our own processes. Ideally all the tasks can be dealt with by all team members (but this is impracticable for expressing our design tasks). We also need to work towards each task being a self contained unit of work with no dependencies.

I think with Kanban we’re still finding our feet. The tools aren’t yet as mature and easy to use as the scrum tools we use. Our task descriptions and workflows are still evolving. It seems to me that the Kanban structure requires more ongoing maintenance from the project manager than scrum where the structure is set at the beginning of each sprint. As we’re still only experimenting with Kanban we haven’t found a good balance and tasks tend to pile in the completed stack for too long before being verified.

My overall feeling is that scrum is a more satisfying process to develop under – you get better and more immediate feedback. Kanban is helpful in preventing work being done when the scrum process isn’t in place – a situation that is very tempting when bugs start appearing.

We’ve released our first public Drupal module – linkedtheme. This modules gives you the ability to link themes together so that they share their block configuration, great for subthemes.

You might use this Drupal module for a site where one section has a significantly different look to another, but the header or menu section has the same look and you want to display the same blocks.

Linked themes

This Drupal module would also be useful if you had user selectable themes. As the user changed the theme they used they would see the same blocks on the site.

Here at Boost we are always endeavouring to improve our processes and ultimately our outputs. The ‘cycle of continuous improvement’, if you will. This means we actively looking for new ideas to test and where appropriate integrate into our day.

Recently we have been researching the agile process Kanban and how it might integrate with our Scrum processes. Kanban is a less prescriptive agile methodology than Scrum. It concentrates on moving items through the pipeline from formulation to completion. It shares many ideas with Scrum and often Kanban teams adopt Scrum artifacts such as daily standups.

What is Kanban

Kanban is an agile methodology that shares much in common with Scrum, but it also has a number of key differences. For example, where scrum uses sprints to limit work in progress, Kanban limits work in progress by workflow state.

For a given project, a number of states are decided on, for instance backlog, develop, test and deploy. Each of these states can have a limit to the number of items that can be in that state at any given time. In this example, the develop state may have a limit of three while the test state may have a limit of two. Nothing can be moved from one state to the next if that limit has been reached. Some states may not have a limit – the backlog, for instance.

Work flows from backlog -> develop -> test -> deploy. We can measure how long it takes a task to move through the pipeline from beginning development to being deployed. This is called lead (or cycle) time and is Kanban’s key metric.

One day in Kanban land. How a Kanban project might proceed. Thanks to Henrik Kniberg

One day in Kanban land. Thanks to Henrik Kniberg

One day in Kanban land. Thanks to Henrik Kniberg

One day in Kanban land. Thanks to Henrik Kniberg

Where could Kanban be of benefit over Scrum

For Boost there are a couple of situations where I can see an immediate improvement with Kanban.

One situation is when a web application or product is in a maintenance phase. During this time we need to address defects and issues as they arise, as well as implementing new, usually smaller, features. We find that a fixed length sprint can limit our responsiveness to defects as we are reluctant to alter a sprint that is in progress. Kanban would enable us to prioritise issues while still addressing the planned smaller features.

The other situation where we see Kanban working well is when developing content managed websites. In this case it is often difficult to break the work into two week sprints. It often feels as though the work is more of a constant stream of very small features that come together to make the site. Often at the end of the sprint we often don’t have a product increment to demo or deploy, especially in the early stages. Kanban would enable us to deploy and demo when ready rather than on a rigid schedule. Deployments would become more frequent as the project progressed.

I won’t go into too much more detail here. There is an excellent forty page PDF entitled Kanban vs Scrum written by Henrik Kniberg (http://www.crisp.se/henrik.kniberg) that goes into some detail about what Kanban is and how it can work with Scrum.

Would love to hear about your experiences of Kanban!

A cluster on IntuitionHQ

Our new product, IntuitionHQ, shows clusters of clicks on an image. To generate these clusters we made use of a gem called Hierclust. The great thing about this gem is it’s simplicity – just input the points and a minimum cluster separation, and out come the clusters.

The problem with Hierclust was the performance. With fewer than 100 points to cluster Hierclust was running too slow to do it dynamically. This was no problem, we moved the clustering program into a cronjob and stored the data in a marshalled file.

However, in testing we found that Hierclust was still too slow. Once we had over 200 points being clustered it started taking minutes to process – an unsustainable amount of time for the data we expected. The graph below shows the timings, which I believe is O(n³). We had to disable cluster processing while looking at the problem due to issues it was causing on the server.

Graph of points v time taken

ai4r

The first course of action was to look for an alternative way to do the clustering. Looking at several solutions, the most promising looked to be the gem ai4r. This provided a number of different clustering algorithms, and was faster / more scalable. Unfortunately the clustering algorithms needed to know the number of clusters – information that we didn’t want to estimate.

Documentation

It’s important to always read the documentation of gems you’re using. After going back to Hierclust and looking through the code I found a value I could tweak to improve the performance at the cost of accuracy. This bought us some time by reducing the processing time of our current data from minutes to 10-20 seconds. It wasn’t going to scale, but we could re-enable the cronjob.

ruby-prof

We then decided that if we could improve the performance of the Hierclust gem itself we didn’t need to worry that it was taking so much longer for each point, as there would be a natural limit to the number of points viable for a project. Using Benchmark and ruby-prof I started to go through the gem with a fine tooth comb. I had test data with 250 points, taking 11 seconds to run. You can take a look at my test file here: http://gist.github.com/219094.

Profiling the code showed that it was spending a lot of time flattening arrays. Looking at every place where flatten was called I found that where each cluster contained an array of points, each of which could be a cluster, flatten was called. By simply changing the code to store the flattened array in an instance variable (invalidating when required) the time to run the test data went from 11 seconds to 3 seconds, a nearly 4 times improvement.

 %self     total     self     wait    child    calls  name
 15.31      9.02     9.02     0.00     0.00  4404288  Hierclust::Point#points
 12.41     35.59     7.31     0.00    28.27   920825  Array#map-1
 12.31     30.76     7.26     0.00    23.50  1060120  Array#map
 12.16      7.17     7.17     0.00     0.00  1980941  Array#flatten
  6.94     26.08     4.09     0.00    21.99   530058  Hierclust::Cluster#x
  6.77     38.33     3.99     0.00    34.34  1060116  Hierclust::Cluster#points
  6.74     25.28     3.97     0.00    21.30   530058  Hierclust::Cluster#y
  6.31     56.69     3.72     0.00    52.97   265029  Hierclust::Point#distance_to

Table lookup

A 4 times improvement was good, but we needed something closer to a 10 times improvement. I couldn’t find anywhere else in the code to improve the performance. However, we did note that quite a lot of time was spent calculating the distance between points (a Pythagoras calculation). Lookup tables are faster, we thought, so why not pre-generate possible values and load them from disk. This was quickly discounted when some quick maths showed us it would require gigabytes of space; probably not faster then.

RubyInline

The next step was to look at throwing some C code into the gem to improve the performance. I tried recoding various methods using RubyInline, a brilliant gem that makes it easy to add small snippets of C code to ruby. For example, the following ruby code:

def distance_to(other)
  Math.sqrt((other.x - self.x) ** 2 + (other.y - self.y) ** 2)
end

Can be rewritten in the same file in C:

inline do |builder|
  builder.include '
'
  builder.c "
    double pyth(double x1, double y1, double x2, double y2) {
      double rr = pow((long)x2 - (long)x1, 2) + pow((long)y2 - (long)y1, 2);
      return sqrt(rr);
  }"
end

Unfortunately the speed benefits were very small, 3 seconds to 2.5 seconds, or 4.5 times faster than the original 11 seconds. You can see my efforts at patching Hierclust here: http://github.com/jemmyw/hierclust.

C Extension

I reasoned from the data I got from ruby-prof that the main bottleneck in the gem, apart from the distance calculation, was in doing array operations. Using RubyInline wasn’t going to solve that. So, using my rusty knowledge of C and this PDF I set about rewriting the Hierclust algorithm in C. As we didn’t require hierarchical clustering I dropped that part of the algorithm and just stored the cluster information with coordinates and cluster size. I used the previous test data of 250 points during development to ensure that the output from the C extension was exactly the same as the output from Hierclust, and once complete I ported Hierclust’s spec files to the new gem.

The results were well worth the effort. The same set of 250 points that took 11 seconds with Hierclust and 3 seconds after my modifications, took ~0.009 seconds using the new C based gem, 1000 times faster. The test file required only changing three lines (class names and requires).

The fastcluster gem can be downloaded:

gem install fastcluster

Or you can get the source code from http://github.com/jemmyw/fastcluster.

Test files for Hierclust and fastcluster: http://gist.github.com/219094

I recently came across FakeFS, which sounds like a great idea for helping to test file functions. However, I did pick up on the following off the website:

[...] it means replacing our mkdir call with a call to mkdir_p won’t break our tests. Because, really, it shouldn’t.

Now I understand that in the context of the example given, mkdir and mkdir_p should do the same thing. But mkdir and mkdir_p do perform different operations, and the tests should break if mkdir_p is changed to mkdir. If you change mkdir_p to mkdir and your passing tests don’t fail then your tests aren’t correct.

I recently found squirrel, and I wanted to use it for a project we’re working on to simplify some complex finder statements. Squirrel allows turning something like this:

Task.find(:all,
  :conditions => [
    'active = ? and (updated_at > cache_version or cache_version IS NULL)', true
  ]
)

into:

Task.find(:all) do
  active == true
  any do
    updated_at > cache_version
    cache_version.nil?
  end
end

The problem is testing

Then I ran into a serious problem – how to test this piece of code using rspec? Here was my first attempt:

it 'should find all active tasks where updated_at is greater than cache_version or cache_version is null' do
  Task.should_receive(:find).with(:all).and_return(@tasks)
  Task.update_cache
end

This doesn’t test the search conditions at all. So I moved on to yield:

Task.should_receive(:find).with(:all).and_yield
 received unexpected message "active"

Then I started adding in the expectations:

Task.should_receive(:active)
Task.should_receive(:find).with(:all).and_yield

But how do I know that active is being compared to true? Now I’d have to use a mock to do that:

mock_active = mock(:active)
mock_active.should_receive(:==).with(true)
Task.should_receive(:active).and_return(mock_active)
Task.should_receive(:find).with(:all).and_yield

As you can see, this is getting quite painful. So it was time to abstract this out into something more meaningful. I created a class called FindWithSquirrel:

class FindWithSquirrel
  include Spec::Matchers
 
  def initialize(klass, expected)
    @klass = klass
    @expected = expected
  end
 
  def verify
  end
end

And I added a way to gain access to the class:

class Class
  def should_receive_squirrel_find_with(expected)
    FindWithSquirrel.new(self, expected)
  end
end

Now the new class needs to extend ActiveRecord to override find and record what happens:

class FindWithSquirrel
  def initialize(klass, expected)
    ...
    extend
  end  
 
  def extend
    @klass.class_eval %Q{
      def self.find_with_finds
        @find_with_finds ||= []
      end
 
      def self.find_with_find_with(*args, &blk)
        find_with_finds << find_without_find_with(:query, &blk).to_find_conditions
        find_without_find_with(*args, &blk)
      end
 
      class << self
        alias_method :find_without_find_with, :find
        alias_method :find, :find_with_find_with
      end
    }
  end
end

So now I’ve got a variable on the model class holding an array of generated conditions. I can fill in the verify method:

class FindWithSquirrel
  def finds
    @klass.find_with_finds
  end
 
  def verify
    finds.should include(@expected)
  end
end

That’s all fine, but now I need to make rspec actually call my verify method. I can do that by reusing the way rspec mocks work. I can do that by adding my class instances to the same array that rspec adds it’s mock expectations:

class FindWithSquirrel
  def initialize(klass, expected)
    ...
    $rspec_mocks.add(self) unless $rspec_mocks.nil?
  end
end

Now the rspec mock framework is expecting to call the methods ‘rspec_verify’ and ‘rspec_reset’, so:

class FindWithSquirrel
  alias_method :rspec_verify :verify
  def rspec_reset
  end
end

Now I can run this spec, and it works great. But it seems to break all the subsequent specs that also use the find function. I have to flesh out that reset function a little. Remember my earlier extend function – I need to remove my ActiveRecord extensions:

class FindWithSquirrel
  def unextend
    @klass.class_eval %Q{
      class << self
        alias_method :find, :find_without_find_with
      end
    }
  end
 
  alias_method :rspec_reset, :unextend
end

So what does my spec look like?

it 'should find all active tasks where updated_at is greater than cache_version or cache_version is null' do
  Task.should_receive_squirrel_find_with(
    ["(tasks.active = ? AND (tasks.updated_at > tasks.cache_version OR tasks.cache_version IS NULL))", true]
  )
 
  Task.update_cache
end

So the class is testing that squirrel is outputting the correct conditions. You could argue that squirrel’s own tests fulfill this testing need, but this class gives a good jumping point to testing that squirrel is receiving the correct parameters. The full file can be found here. Just include it from your spec_helper.

When writing a Rails application, how do you decide on the best indexes to add to your database? It might seem obvious, especially if you work on a project from scratch. The problem is a little harder when you come to optimize an existing codebase.

New Relic

Recently I’ve been using two methods to work out where to put indexes. Firstly I’d strongly recommend using New Relic RPM in development mode. When running your application you can visit /newrelic to get all kinds of useful information. Here you can see the most recent rails calls:

And you can drill down to see the database calls:

And then you can drill down further to see a statement analysis. This will give you information like so:

So this will tell you that there are no keys used, and no possible keys to use. If you now create a migration as follows:

class CreateIndexes < ActiveRecord::Migration
  def self.up
    add_index :projects, :account_id
  end
end

Now run the query again after migrating:

But we could do better. Notice that in the extra field it says “Using filesort”. This means that MySQL is doing a normal sort using the row data. If projects are usually selected by account_id and ordered by position then we have a good case for sorting by index. We can’t just add an index on the position column as this won’t be used (try it and you’ll see exactly the same results). Instead we have to add an index that covers both account_id and position:

add_index :projects, [:account_id, :position]

Now looking in RPM again you’ll see things change to:

Overriding execute

I talked about using two tools to work out where to put indexes. New Relic is great and gives lots of useful information, but I wanted to see what queries were running without indexes as the application was used, in order decide if they required optimizing. I placed the following (ugly) snippet of code into the development or staging environment file:

config.after_initialize do
  unless ActiveRecord::Base.connection.respond_to?(:old_execute)
    ActiveRecord::Base.connection.class.class_eval do
      alias_method :old_execute, :execute
 
      def log_explain(str)
        if str =~ /^SELECT.*WHERE/i
          results = old_execute('EXPLAIN %s' % str)
 
          while row = results.fetch_row
            if row[5].blank?
              File.open(RAILS_ROOT + '/log/sql.log', 'a') do |f|
                f.puts str
                f.puts row.inspect
              end
            end
          end
        end
      end
 
      def execute(*args)
        log_explain(args.first)
        old_execute(*args)
      end
    end
  end
end

This performs a similar task to RPM in that it runs MySQL’s EXPLAIN statement on each SELECT statement that runs. However, I’ve set it up to filter out any statements that are already using keys (if row[5].blank?). Now by tailing the file log/sql.log I’ll be able to see any unindexed queries that are running on the database. I can use this information to quickly run through the whole application to find any problem areas.

What not to index

Most of the database calls from a rails application are going to be quite generic, the same thing over and over, and indexing is good in this situation. Some database calls are going to be a little different – think search, statistical count, etc. You’ll need to think careful if these require indexes or not, considering how often they’re run, and how fast they need to be. Caching can be a good replacement in these areas. Also take into account that indexes slow down database writes, and indexes on string columns are going to be much more intensive that indexes on integer columns.

Load testing

Of course you might not find all problem areas, or you might not be optimizing the correct queries. These methods should give you a good idea, but they’re no replacement for doing good load testing on your application. We’ll be posting more about load testing a rails application in the future.

Cross-browser compatibility issues are the bane of web developers world-wide and in this ever shifting landscape it is important to have processes that integrate cross-browser testing in a robust and systematic way. Over the last 9 years we have evolved a robust workflow for web development and cross-browser testing is an integral part of this.

An overview of the process

We start by constructing the HTML/CSS in a text editor (Textmate, RubyMine IDE or Aptana IDE) and viewing it in Firefox. We develop standards compliant HTML/CSS, so Firefox is a great starting point as it supports the CSS standards well and enables us to use a number of key tools including Pixel Perfect, YSlow and the Web Developer toolbar.

Once we are happy that the design is accurately implemented in Firefox we use Litmus to create screenshots across a selection of Browser/Operating System combinations. Litmus has a number of great features that really make this process easy. Firstly, you can retest the page with a simple button click and Litmus keeps track of the revisions, secondly Litmus uses the W3C validators to check that the HTML and CSS validate and links trough to the error pages and thirdly Litmus lets us indicate visually whether a particular combination is rendering correctly so we can keep track of what is complete and what remains.

Running the initial test in Litmus will usually through up a number of issues, especially in IE6 (suprise!). At this stage we move on to the target Browser/Operating system to correct the issues. More often than not this is a process of finding work-arounds for the poor standards support in IE6 and IE7 while still ensuring the the HTML/CSS validates and is semantically correct.

We iterate through the testing in Litmus and fixing problems on the target platform until we are happy that the design is working correctly across all platforms. We then use the publish option in Litmus to create  publicly accessible version of the test to send through to our client. This enables our clients to be certain the design is rendering correctly across platforms. You can see an example test here: http://boost.litmusapp.com/pub/5125956

From here the HTML/CSS gets passed to a developer who integrates the HTML with the web application or content management system. This is where the utility of Litmus really shines. During this phase we use Litmus in the same way as we use Unit tests in our programming, to confirm that nothing is broken as we add features and develop the site. This is the key to consistent and successful projects, constant and consistent testing during the life-cycle of development.

Using Litmus

The first step is entering the URL to test and choosing the Browser/Operating Systems. Once you have made your choice you can set this to be the default for further tests.

Litmus: starting the test

The second step is viewing the results. The overview screen gives an estimate of how long all tests will take to complete and the page updates as the tests complete. On the left side it shows the results of the HTML and CSS validation.

Litmus: Test overview screen

The third step is to check each of the individual results. At this stage we usually mark the ones that are passing and the ones that are failing to keep track of progress.

Below is a page that is not rendering correctly, and we mark this as incompatible.

Litmus: Example of a failing page

Below is a page that is rendering correctly, and we mark this as compatible.

Litmus: Example of a passing page

The final step is to publish the test and send the URL to the client, you can view the test here: http://boost.litmusapp.com/pub/5125956

Here at Boost we lovingly handcraft our HTML and CSS when implementing our designs. We use text editors rather than programs like Dreamweaver or Frontpage. We find it’s faster, and it enables us to produce clean, correct code that’s easy to integrate.

Our process starts with the production of the designs in either Photoshop or Fireworks. Once these are approved by our client, we convert them to HTML/CSS templates before integrating them with the web application or content management system.

At the HTML/CSS stage we use two tools to ensure the design is being accurately implemented: Pixel Perfect and Litmus. Today I’ll focus on Pixel Perfect - I’ll talk about Litmus another time.

What is Pixel Perfect?

Pixel Perfect is a Firefox/Firebug extension that allows web developers and designers to easily overlay a web composition on top of the developed HTML. Pixel Perfect is built on top of Firebug (another Firefox extension), so you will need to have Firebug installed and active to use Pixel Perfect.

The video below is a quick look at how Pixel Perfect is used.

Why Pixel Perfect?

We strive to ensure that the integrity of the design is kept as it is implemented.

Because of the way different that browser and operating systems render HTML text, it is practically impossible to get sites rendering identically across all browsers and operating systems that we support. Using tools like Pixel Perfect helps us to make the differences all but imperceptible.

With considerable effort going into our design at Boost, it is important that this is reflected in the final product. While a small gap here and a slightly different text size there seem like small issues in the rough and tumble of building a site, they all add up. What was once a tight, balanced and considered solution to a design problem can turn out as ramshackle, unpolished and unprofessional.

Before we found Pixel Perfect we tried a number of different tools including Afloat, which makes the OS X Preview application partially transparent, but this approach was less flexible and didn’t work as well.

What are the benefits of using Pixel Perfect?

Using Pixel Perfect in our HTML/CSS production workflow provides a number of tangible benefits, including:

• reduced time and cost during the quality assurance process
• increased speed of development of the HTML/CSS
• creating closer working relationships between designers and developers
• a better looking website of which we can all be proud.

Run, don’t walk, to get Pixel Perfect today

Grab your copy, for free, from: http://www.pixelperfectplugin.com/

And don’t forget to give a donation if you want to see this great plugin grow and flourish.

We’ve released a radar (spider, polar) chart component for Flex as an open source (MIT) project on github. This is abstracted from our Sonarhq product. For the most part we’ve been using the Flex Charting components from Adobe, but this doesn’t include radar charts. We looked at several commercial packages, but these turned out to be either too expensive, or not flexible enough. There is a free component a vailable at Kap Lap, but it didn’t support the styles we needed to match the design we had.

In the end it was easier to produce our own (about a day and a half of work). The project depends on some common libraries we’ve developed at Boost over the last couple of years, which we haven’t decided on open sourcing yet, but we have included the binary under the same license so that the charting component can work. Here’s a demo and how to get going:

Download the code or the swc [230KB] file from github and create a new project. In the project properties add the swc library or open the chart project and include it. Create an application with the following code:

  <![CDATA[
 
    private function init():void {
      radarChart.addAxis('bread');
      radarChart.addAxis('cheese');
      radarChart.addAxis('wine');
      radarChart.addAxis('fish');
      radarChart.addAxis('meat');
 
      radarChart.addSeries('Male', {bread: 3, cheese: 4, wine: 5, fish: 1, meat: 4});
      radarChart.addSeries('Female', {bread: 4, cheese: 2, wine: 4, fish: 5, meat: 3});
    }
 
  ]]>

This will show a simple chart similar to the one here. The charts can be styled quite a bit. Take a look through the code to see the styles that can be applied. Note that I haven’t yet allowed for styling the bits of text.

Originally my intention was to extend the flex charting objects in order to implement the chart. Unfortunately I found the structure a bit complex, and documentation for extending non-existent. I’m sure it would have been possible, but I didn’t get very far and just wanted to just get it done.

Update 24th Aug 2009: New release that fixes issues with drawing the highlight and removing series radar_chart-1.1.swc.

Update 28th Oct 2009: New release that fixes removing labels when removing axis: radar_chart-1.2.swc.

Update 16th Jul 2010: Release that works correctly with Flex 4. This is for Flex 4 (Flash Builder 4) only, and will not work with Flex 3. radar_chart-1.3-flex4.swc.

On the 25th of February ’09 I did a brief JRuby presentation on JRuby and how we’re using it at Boost. We’re really excited about some of the capabilities of JRuby.

We’re running a client deployment on Tomcat fronted by IIS, and it was really easy to get everything set up. We wanted to try another deployment on Glassfishv3 with no webserver in front. Unfortunately (and glassfishv3 is still in development) there were two barriers that prevented us doing so :

• Exessive memory consumption: 2 rails apps + the admin interface = more than a 1G slice could handle.
• SSL: I was so close to getting this working, but several hours of working on this is too much, it should be easier.

In conclusion, JRuby isn’t quite ready for our in house projects where we control the deployment, but it is great for Windows deployments. We’ll keep an eye on it. JRuby 1.2 was released just a few days ago with performance increases.

Download the presentation.