Posts Tagged ‘Programming’

Haynes Catalog live

Friday, July 3rd, 2009

I’m glad to announce that the Haynes Catalog went live yesterday. The Haynes Catalog is an online project which “presents an interactive and continuously updated database containing music for and with oboe up to 1800“. A friend of mine, Peter Wuttke, continually collects information and uses the online catalog to make this available to the public.

The application is using Ruby on Rails with a Mysql database in the background. Apart of the public part of the application, there is an admin interface which allows Peter to update the data. Since I worked on this project only sporadically in my spare time, two challenges proved to be more complicated than expected:

  1. Versioning of changes:
    We tried to make changes of the data transparent to the user. It should be visible to the user, when information has been changed, for example when a composition has been published, or other data is corrected. Hence there is some change history.
    However, not all changes should be mentioned – simple corrections of typos etc. should be ignored.
    Finally, the versions must span several tables as there are a lot one-to-many or many-to-many relations.
  2. Synchronisation:
    Most of the research is done offline, for example in libraries or when travelling. Therefore there exist two installations, both being “productive”: the official homepage plus an offline installation which is used during the research.

Both problems can be solved, but there is no “out-of-the box” solution. There will be some detail about how to solve these two issues in a Rails application in following posts.

Redesign of Beauty of Code

Wednesday, June 24th, 2009

In the last weeks I completely changed the design of this site. It became much lighter and I removed some plugins which I didn’t want to use anymore. In particular, I removed the simile timeline on the left.

In the previous design, I used the WP Simile Timeline plugin to show the timeline of the blog entries. This was a vertical timeline located in the left sidebar. The problem was that vertical timelines are pretty complicated to design and the simile timeline doesn’t really support a vertical layout. Therefore I chose to change to a horizontal blog timeline as part of the redesign. At the same time I realized that the timeline doesn’t fit to the overall design.

Hence I wrote my own timeline implementation using jQuery and embedded it in the new layout. Each small vertical tick in the header corresponds to a blog entry. If you hover over it, the link to the blog entry is shown.

Currently there are only few features:

  1. RSS feed: the timeline implementation reads the RSS feed of the site an creates the div elements for the timeline.
  2. Custom creation of events:  create a div and call a simple javascript method to add an event.
  3. Design completely using CSS: it is very difficult to change the theme of the simile timeline. The timeline above can be adjusted using very simple CSS.

But of course, it still can (and needs) to be enhanced.

Using checkstyle with bitten

Tuesday, November 18th, 2008

Bitten is a trac plugin for continuous integration which I use for the antdiff project and it does a good job in getting the daily builds organized. One nice feature is the summary for unit tests and code coverage tools (I use corbertura). But what I was missing was a similar summary for my checkstyle reports.

But thanks to XSLT, there is a simple solution: Bitten is able to include test and coverage reports from xml files. And since checkstyle generates a xml file for the results, it was straight-forward to translate the checkstyle xml file to a xml file for bitten. The only problem is that bitten only knows the two mentioned types of reports, so I decided to use the test report. 

And this is the (extremely simple) stylesheet:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

  <xsl:template match="file">
    <xsl:choose>
      <xsl:when test="count(error) = 0">
        <test status="success" fixture="{@name}" name="No checkstyle errors" file="{@name}" />
      </xsl:when>
      <xsl:otherwise>
        <xsl:for-each select="error">
          <test status="error" fixture="{../@name}" name="{@message}" file="{../@name}" />
        </xsl:for-each>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>

  <xsl:template match="checkstyle">
    <report category="test">
      <xsl:apply-templates/>
    </report>
  </xsl:template>   

</xsl:stylesheet>

Translating the checkstyle xml report using this stylesheet allows you to treat checkstyle results in the same way as unit test failures.

But there is one slight problem: the file names in the checkstyle xml are absolute file names. Hence also the file names in the bitten build summary are absolute. In my setup this means having something like “/tmp/bittenFpQXrh/build_Trunk_22″ in front of the name, which doesn’t look good and it also breaks the link to the source code. The simple solution was to remove the path name from the checkstyle report using the following ant task:

<replace file=“${dir.reports}/checkstyle_report.xml” token=“${basedir}” value=“”/>

Maybe it would be nice not to link the checkstyle results to the source code, but rather to the html reports which give more information about the details of the problem.

Please see on of the antdiff build status pages as an example (click on “Test results” in the checkstyle section).