Thursday, April 12, 2007

Accepted to Google Summer of Code 2007!

I just got the email congratulating me on my future participation in Google Summer of Code 2007. My application for the Swarm Development Group was accepted!

I just created a GSoC 2007 .Mac page to which I'll post my accepted and declined applications over the next few days.

Saturday, April 07, 2007

OCUnit test reports

Unit testing not only is quite usefull to make my code better but I also really like the visual feedback in the form of the junit generated html reports. The reports automatically generated by the Ant build script provide a nice overview what test cases work or don't work. More important, it shows me what I might have broken by adding a feature. The console results are just fine during development, the HTML reports are better suitable for publishing on the web for example.

These html reports are generated based on xml output from junit. This is all easy in an Ant based java project where tests are run using junit.

The problem is I mainly develop in Objective-C in which case I test using the OCUnit framework. The OCUnit framework nicely integrates with Xcode and displays failures the way Xcode displays compile errors. This is nice during development but pretty useless when builds are run automated on a remote machine.

So to publish test results from an automated xcode build I wrote a ruby script that transforms the console output from OCUnit to a junit compatible XML format. See the following Ant target how this works:

<target name="test" depends="build"
description="Builds the project, runs the unit tests, generates a report">

<exec executable="xcodebuild" dir="zip-framework" failonerror="false" outputproperty="xcodebuild.out">
<arg line="-target Test -configuration release build" />
</exec>

<mkdir dir="reports" />
<mkdir dir="reports/raw" />
<exec executable="OCUnitReport" errorproperty="report-error.out" inputstring="${xcodebuild.out}" searchpath="true" resolveexecutable="true">
<arg line="-d reports/raw" />
</exec>
<echo message="${report-error.out}" />

<mkdir dir="reports/html" />
<junitreport todir="reports">
<fileset dir="reports/raw">
<include name="TEST-*.xml" />
</fileset>
<report format="noframes" todir="reports/html" />
</junitreport>
</target>


The first exec task executes the OCUnit target called Test and saves the result in the xcodebuild.out property. The second exec task transforms this output to xml using the OCUnitReport script. Finally a junitreport task is used to transform this xml to a html report in the reports/html directory.

Why use Ant to build a Xcode project? For one, the only way for the automated build tool CruiseControl to build a Xcode project is to wrap the the command line tool xcodebuild in an exec task. Ant also contains a lot of useful build-in tasks like ftp which can be used for example to upload the build reports to an external server.

Download (ruby script, 5kb)

Wednesday, March 28, 2007

Let the waiting begin!

From the Google Code weblog:

It's shaping up to be another exciting Google Summer of Code this year! As of the deadline, we've received 6,179 student applications from over 3,000 students. The list of accepted student proposals will be published on April 11, 2007 on the Google Summer of Code page.

6,179 student applications from over 3000 students, nice. That's an average of about 2 applications per student. Just wondering how many students actually reached their application limit of 20. Since only 1 in 5 students or 1 in 10 applications (around 600) will be accepted, this should be a long wait for most students :)

Update:
It seems google is accepting around 800 students, instead of the number stated in their faq.

Monday, March 26, 2007

Google Summer of Code

A few more minutes and the Google Summer of Code 2007 (GSoC 2007) student application deadline will pass! I submitted three applications in total for the following organizations:


For the Swarm Development Group I applied to integrate the Swarm library with the Cocoa framework. This is one of the ideas proposed by the Swarm developers.

For the other two organizations I came up with my own project of which I think the project communities will benefit from.

More information on my reasons for choosing the proposed projects and the full project applications as submitted to google will be posted online soon. Accepted student applications will be published by google on the GSoC 2007 homepage on April 11.

Update:
The student application deadline has been extended to 16:00 UTC march 27.

Update 2:
Because of the extended deadline I decided to submit another application, this time for the Eclipse foundation. This brings the total amount of my applications to 4, which I think is a reasonable amount (even though 20 are allowed by google).

C Puzzles

A list of small C programming puzzles. Allthough most of them are easy and some are quite lame, it's a good opportunity to test your C knowledge.

Friday, December 29, 2006

IndieHIG contribution: Source list implementation

My contribution to the IndieHIG: A source list implementation.



The demo is simply displays my NSTableView subclass called JKSourceTableView in a single window. JKSourceTableView makes it easy to use different NSCells in a single column, using different row heights. This enables you for example to create the effect of separator lines.

When I've got a bit more time i'll update the code to use a gradient row background. I'll also create an article explaining how you can use JKSourceTableView in your own code.

Download | Mirror (xcode project zip, 84kb)

Automator command line utility bug?

OS X comes with a commant line utility, /usr/bin/automator to execute Automator workflows from the command line. This is what man automator has to say:

NAME
automator -- runs an Automator workflow

SYNOPSIS
automator document

DESCRIPTION
automator runs the specified workflow document. To create or edit a
workflow, use the Automator application. There are no options.

Not very usefull. All we know now is how to specify which workflow we want to be run, no information on how to add input to the workflow, like a list of url's or a list of files.

I created a simple test workflow that display's two confirmation boxes. When the first one is dismissed with a negative response, the second one shouldn't appear. This works fine in Automator, when run I am presented with a dialog, when I click OK I get to see the second dialog. But when I run the workflow using /usr/bin/automator I never see the second dialog.

Some research using strings /usr/bin/automator reveals the presence of applicationShouldTerminateAfterLastWindowClosed: So perhaps this selector causes /usr/bin/automator to terminate after a dialog is closed, even before the Automator action is completed succesfully.