Monday, December 16, 2013

Guest post about Brackets and building Brackets Extensions

It’s already a couple of weeks ago, that I provided two guest posts about Brackets for Safari Books Online.
Please have a look at introduction to Brackets and Building a Brackets Extension and let me know what you think.
I’d like to hear your feedback. Thanks.

Friday, November 8, 2013

git re-merge done easy

I messed up some files during a larger merge a couple of days ago. When I tracked down the files that had issues (in my case the unit tests didn't succeed anymore), I wondered if there is an easy way to revert to the version of the file before the merge and redo the merge or at least bring back the file with the conflict markers.

I was looking for an elegant solution. Something must exist that helps engineers to easily resolve situations like this.
After 45 seconds of research (sometimes it's that quick if you know the right words to search for), this result on StackOverflow came up.
git checkout -m <filename>

Very nice solution. I was able to go back to the state, where the file contained all the conflict markers and I was able to resolve the issue pretty quickly.

Yes, sometimes git is really easy.

Sunday, March 3, 2013

Using cobertura with gradle

I wanted to get code coverage for my current groovy project. Since I use gradle and all of my source is written in groovy, I searched for a gradle plugin that provides cobertura functionality for groovy files. I found two (perhaps there are a more available)

Using both plugins wasn’t a big deal. There is a slight difference how to set them up in your build.gradle file though. Both plugins provide very similar configuration options to tweak cobertura’s behavior. Let’s take a look.

Using Eric Wendelin’s Cobertura plugin

Adding the plugin to the build.gradle

I’m using gradle 1.4 for this exercise and I added the following to my build.gradle:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath "net.saliman:gradle-cobertura-plugin:1.1.0"
    }
}

apply plugin: 'cobertura

This will provide you with four new tasks:

  • coberturaInstrumentMain
  • coberturaInstrumentTest
  • testCoberturaReport
  • coberturaConfigureTest

So, which task to call to determine the code coverage? Simply run the test tasks and your source will be instrumented prior to executing your tests.

But what you really want, is to run the check tasks because this will not only run your tests on your previously instrumented source, but it will also create the coverage report. And that’s basically what we want.

The plugin provides some configuration options to tweak cobertura’s behavior

option description
format ’html’ (default) or ’xml’
reportsDir Path to report directory for coverage report. Defaults to ${project.reportsDir.path}/cobertura
includes List glob paths to be reported on. Defaults to [‘**/*.java', ‘**/*.groovy', ‘**/*.scala’]
excludes List glob paths to exclude from reporting. Defaults to [‘**/*Test.java', '**/*Test.groovy', '**/*Test.scala’]
ignores List regexes of classes to exclude from instrumentation. Defaults to [‘org.apache.tools.*', 'net.sourceforge.cobertura.*’]

To specify the output format of cobertura’s coverage report you have to do this:

cobertura {
    format = ‘xml’
}

Using Steve Saliman’s Cobertura plugin

This plugin is based on the work of gradle_cobertura. The original version had some issue with the latest gradle version, so I decided to pick one of the 20 forks. The one with the most recent changes was Steve Saliman’s Cobertura plugin. You can find the setup instructions in the README. Currently the compatibility chart shows that gradle 1.1 is the highest supported version right now. I’m using it with gradle 1.2, 1.3 and 1.4 and they work too. So, let’s move ahead and give it a try.

Adding the plugin to the build.gradle

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath "net.saliman:gradle-cobertura-plugin:1.1.1"
    }
}
apply plugin: 'cobertura'

This will add 2 new tasks:

  • cobertura
  • instrument

To get your coverage report you need to run the cobertura task and the report will be created.

There are a couple of options available to this plugin to change the cobertura behavior:

option description
coverageDirs Directories under the base directory containing classes to be instrumented. Defaults to ${project.sourceSets.main.classesDir.path}
coverageDatafile Path to data file to use for Cobertura. Defaults to ${project.buildDir.path}/cobertura/cobertura.ser
coverageReportDir Path to report directory for coverage report. Defaults to ${project.reportsDir.path}/cobertura
coverageFormats Formats of cobertura report. Default is a single report in ‘html’ format
coverageSourceDirs Directories of source files to use. Defaults to ${project.sourceSets.main.java.srcDirs]
coverageIncludes List of include patterns
coverageExcludes List of exclude patterns
coverageIgnores List of ignore patterns

Fix broken links in coverage report

In order to have a working link to the groovy source files in the coverage report, it’s necessary to add the following to your build.gradle. This will add the groovy source directory to the list of coverageSourceDirs

cobertura {
    coverageSourceDirs << project.sourceSets.main.groovy.srcDirs
}

Report location

For both plugins, the generated report can be found in build/reports/cobertura.

Summary

I have to admit, that both plugins are too similar in functionality to declare a clear favorite. In general, both plugins have subtle differences in regards of their configuration. I like that Eric Wendelin’s Cobertura plugin supports groovy (and scala) files right out of the box without further configuration. But this is only a very small advantage. I’ll stick with Steve Saliman’s Cobertura plugin for a while, since there is still active development. Not a strong reason, but as I mentioned earlier, there are only subtle differences between both plugins.

The choice is up to you.

Monday, February 11, 2013

List all available instruments templates

Using Apple's instruments on the command line to inspect an iOS application on the device, usually involves a specific template to capture data from the application running on the device.

For my current project I usually used the Automation.tracetemplate to launch my iOS app. But after I've upgraded Xcode from 4.3 to 4.5, the filesystem location of the instruments templates have been slightly changed. The framework that I wrote for the performance tracking system failed in finding the template. I started to investigate a better solution to be able to deal with different Xcode versions that could be found on the dev machines.

For that reason I created a little helper class to identify the version of Xcode to locate the correct path of the Automation.tracetemplate. That works pretty fine, but I don't know if this will work for future Xcode versions too. This solution required xcodebuild -version to determine the Xcode version and xcode-select -print-path to determine the location of the Xcode folder. I needed this information to assemble the path to the templates.
There must be a better, shorter way of getting this information.

A better solution

Running instruments on the command line produces a rather concise than helpful overview of the available options. I couldn't find any manpage for instruments on my machine. Rather by accident than intentional, I came across the instruments manpage on Apple's Developer Connection website.

The manpage contained far more information about the available options including some description for the unknowing user. I discovered the option -s that produces a list of all available instrument templates.  Even if the manpage was targeting the Xcode tools 3.2.5 version (I couldn't find a more recent version), the option is still recognized by the latest instruments (as time of writing I used Xcode 4.6).

Running instruments -s and parsing the output will give me path to the Automation.template. without any guessing or probing. I hope this option will remain available in instruments in future versions.

Tuesday, January 29, 2013

Das tote Pferd

Es gibt diese Weißheit der Dakota Indianer: „Wenn Du entdeckst, dass Du ein totes Pferd reitest, steig ab!”

Und heute ist es wieder passiert. Ich hab die Zeichen wieder nicht gesehen. Vielleicht waren dort auch keine, aber das Pferd auf dem ich geritten bin ist definitv tot. Leider bin ich nicht aus freien Stücken abgestiegen, sondern abgestiegen worden.
Mit anderen Worten: mein Arbeitgeber hat heute mal wieder eine neue strategische Ausrichtung bekannt gegeben und leider war mein Team, und damit eine Menge anderer Kollegen, nicht mehr direkt Teil dieser neuen Strategie. Zum Glück wurde aber keiner meiner Kollegen entlassen. Das hat die Firma aus den vergangenen Umstrukturierungen gelernt. Erst fire, dann hire ist teuer.

Hab ich noch einen Job? Ja, hab ich. Also kein Grund zum meckern. Was für ein Job? Keine Ahnung.

Warum rege ich mich darüber auf? Du bist in den USA. Da ist das doch gang und gebe. Ja, das ist zwar richtig und es verwundert mich auch nicht wirklich. Es ist nur die Häufigkeit der Veränderungen in den letzten 2 Jahren gewesen. Und jedes mal das ungute Gefühl, dass ich irgendwann durch die Mühlen falle und keinen Job mehr habe, wir das Land verlassen müssen, weil das Visum an meinen Arbeitgeber gebunden ist.
Naja, jetzt heisst es erstmal abwarten und sehen was das kommt. Jeder Neuanfang ist auch eine Chance etwas Neues zu lernen.
Also, es ist mal wieder Zeit etwas Neues zu lernen.