The Mac Mini is 1,000 Days old now

The Mac Mini Turns 1,000 Days Old Today

Last Wednesday we discussed in our team that we would need another Mac Mini for hosting a zoom room and another Jenkins build node for our iOS projects.

When I looked at the MacRumors Buyer’s Guide it showed that the Mac Mini was not updated for exactly 1000 days – what a coincidence ;)

But it is really sad that there has been no update for the Mac Mini in such a long time. Though Apple recently told the press “The Mac Mini remains a product in our lineup” they are not really supporting that statement by actions.

I would gladly buy a new Mac Mini with up to date hardware but the currently available configurations are not worth their money.

Looking at the state of the Mac Mini and their latest statements made me think: what if Apple takes the modularity of the new Mac Pro so far, that it could combine the Mac Mini and the Mac Pro into one product? A desktop Mac without a display than can be configured from 1.000 EUR to 10.000 EUR ? That would sound pretty intriguing and a lot like the famous xMac that the community wished for a long time.

If there is no update to the Mac Mini later this year, I would be sad, but it could be another hint that this is their plan.

TypesScript 1.8 Beta

wurde heute hier vorgestellt:

Für mich genialstes neues Feature: der TypeScript Compiler compiliert jetzt auch JavaScript. Dadurch kann man alle seine JS Files gleich mit in den Build Prozess geben und dann nach und nach in TS konvertieren.

Außerdem spart man sich die Definition Files (.d.ts) wenn der Compiler die JS Files gleich mit analysieren kann.

Ich glaub ich muss die Beta gleich mal in unserem größten JavaScript/TypeScript-Mix-Projekt testen.

Grails 2.2.x and the problem with inner classes

We have been using Grails 2.2.x in some of our projects since it came out last year. Last week when I tried to upgrade another project because it was time to develop some new features I ran into a strange problem after upgrading from 2.1.3 to 2.2.1:

org.codehaus.groovy.grails.web.pages.exceptions.GroovyPagesException: Error processing GroovyPageView: Error executing tag : Error executing tag : java.lang.VerifyError: (class: com/troii/project/tags/SomeTag$Info, method: getSession signature: ()Ljavax/servlet/http/HttpSession;) Incompatible object argument for function call
	at com.googlecode.psiprobe.Tomcat70AgentValve.invoke(
	at java.util.concurrent.ThreadPoolExecutor.runWorker(
	at java.util.concurrent.ThreadPoolExecutor$
Caused by: org.codehaus.groovy.grails.web.taglib.exceptions.GrailsTagException: Error executing tag : Error executing tag : java.lang.VerifyError: (class: com/troii/project/tags/SomeTag$Info, method: getSession signature: ()Ljavax/servlet/http/HttpSession;) Incompatible object argument for function call

I had never seen a java.lang.VerifyError exception before and the second strange thing was that the exception only occured when deploying the war in a tomcat not when starting the app with grails run-app.

Searching the web brought up some JIRA issues:

GRAILS-9627 inner class or enum in domain class breaks unit/integration testing
GRAILS-9784 Using an anonymous inner class in Controller causes VerifyError
GRAILS-10068 inner class in controller class breaks unit testing

and a blog post from someone who experienced the same issue.

Seems like with the update from Groovy 2.0.6 to 2.1.0 caused a compilation problem for inner classes. I had no chance to test with Grails 2.2.2 which was release three days ago but it seems the only workaround currently is to move the inner classe to external ones.

UPDATE: Seems Grails 2.2.2 improved a lot, at least for our project it works.

Java Bean Getters/Setters

Many Java developers think they know everything about Java Beans and the correct getter/setter styles, but there are some hidden traps ;-)

Let’s do a little quiz!

How should the correct and getter/setter for a property with the following field look like?

private String name;

This is an easy one:

public String getName() {
  return name;

public void setName(String name) { = name;

Notice that the first letter of the field was made uppercase.

Here is a different one:

private String URL;

The correct getter/setter methods would look like:

public String getURL() {
  return URL;

public void setURL(String URL) {
  this.URL = URL;

In this example the field was already uppercase so nothing was changed in the getter/setter.

So what’s about a field like this:

private String iMessageId;

This one is a little bit tricky – could you guess the correct getter/setter?

public String getiMessageId() {
  return iMessageId;

public void setiMessageId(String iMessageId) {
  this.iMessageId = iMessageId;

It is important that the case was not changed – like for the URL field. This happens when the second letter of the field name is already uppercase. The reason for this is the method java.beans.Introspector.decapitalize:

 * Utility method to take a string and convert it to normal Java variable
 * name capitalization.  This normally means converting the first
 * character from upper case to lower case, but in the (unusual) special
 * case when there is more than one character and both the first and
 * second characters are upper case, we leave it alone.

* Thus "FooBah" becomes "fooBah" and "X" becomes "x", but "URL" stays * as "URL". * * @param name The string to be decapitalized. * @return The decapitalized version of the string. */ public static String decapitalize(String name) { if (name == null || name.length() == 0) { return name; } if (name.length() > 1 && Character.isUpperCase(name.charAt(1)) && Character.isUpperCase(name.charAt(0))){ return name; } char chars[] = name.toCharArray(); chars[0] = Character.toLowerCase(chars[0]); return new String(chars); }

I guess this one was new to some of you, wasn’t it?

The last example applies to boolean properties. We know that the getter/setter for

private boolean active;

may look like

public boolean isActive() {
  return active;

public void setActive(boolean active) { = active;


public boolean getActive() {
  return active;

public void setActive(boolean active) { = active;

But not everybody knows that the getter/setter for a property of the type Boolean:

private Boolean closed;

must look like

public Boolean getClosed() {
  return closed;

public void setClosed(Boolean closed) {
  this.closed = closed;

the getter isClosed() would not be recognized.

Not to long ago even Eclipse code generators made mistakes with those edge cases – I checked today and both IntelliJ and Eclipse generated everything correct. If you want to look into the specification you can do this here.

Signing Android APK files under JDK7

We are using maven to build our Android applications in Jenkins for testing and for publishing them to the Play Store. Recently I started to have problems with the Play Store saying that the APK files were not signed or not aligned so I upgraded the Android Maven plugin and adapted the pom.xml files. Finally I was able to submit the signed and aligned APK files again to the Play Store – everything fine again, at least I thought so.

An hour later I got the first mail from a user telling me that he hat troubles installing the update of the app from the Play Store. The error message said something about the certificate so I tried it myself and got the message


when trying to install the app on my device. I was confused because the app was signed, it contained the certificate information in the META-INF directory and the MANIFEST file and the Play Store validated it as signed.

Some research brought up this article about Android’s Problem with JDK7 and I remembered that I recently installed JDK7 on my MacBook. It turns out that there is a difference in JDK7 regarding signature algorithms and ant has a problem with it too. So to get APK files that are signed correct I had to configure the signature and digest algorithm the maven-jarsigner-plugin uses as described here:


Conclusion: Always test APK files after signing!

Spannende Wochen für RIM

Es sind spannende Wochen, die da auf RIM zukommen. In den nächsten Tagen wird RIM ihr neues Betriebssystem BlackBerry 10 und ihre neuen BlackBerry Geräte vorstellen. Die Neuvorstellung repräsentiert für RIM und die Marke BlackBerry quasi einen Neustart in vielerlei Hinsicht.


Das neue Betriebssystem basiert auf QNX, wie bereits das System das auf dem Playbook gelaufen ist. RIM hat das Playbook OS allerdings sehr viel weiter entwickelt, und in BlackBerry 10 wieder die gesamten Funktionen eingebaut, für die BlackBerry bekannt wurde (Synchronisierung von Mail, Kalendar, Kontakten, Todo’s usw.) plus ein paar zusätzlicher Funktionen (z.B. Balance für Work/Private Trennung). Komplett neues Betriebssystem heisst, dass sich alles ziemlich “fluffig” anfühlt – ähnlich wie bei iOS und Windows Phone ist das UI fast verzögerungsfrei, ruckelt nicht und alles ist schön animiert. Komplett neu heisst aber auch, dass sämtliche Anwendungen, die es bisher für BlackBerry gab, neu für BlackBerry 10 geschrieben werden müssen bzw. portiert werden müssen.

Von den kommenden Geräten sind ja schon ein paar Information im Netz unterwegs (hier und hier kann man sich schon mal ein Bild machen). Es wird Touchscreen Geräte und Geräte mit Tastatur geben. Ich hatte die Gelegenheit unser Alpha Dev Gerät mit Touchscreen ein wenig zu Testen und das fühlt sich sehr gut an. Interessant ist auch die Touchscreen-Tastatur, mit der Funktion Wörter mittels Swipe Geste schnell zu vervollständigen. Das funktioniert ganz gut und beschleunigt das Schreiben merklich. Das Bedienkonzept mit Features wie dem neuen Hub und verschiedenen Swipe Gesten verändern das Feeling des BlackBerry sehr – man darf gespannt sein wie das bei Geräten mit QWERTZ Tastatur wird.

Dem Trend von BYOD kommt RIM mit dem letzte Woche erschienenen BlackBerry Enterprise Server 10 nach – er unterstützt nicht nur die Verwaltung mehrere BlackBerry Geräte je Mitarbeiter sondern kann auch Geräte andere Smartphone Platformen verwalten. Im Bereich des Enterprise Servers war RIM ja immer schon stark und früh weit vorne, jetzt will RIM mit diesen Funktionen den Markt des Device Managements wieder stärker besetzen.

Im Bereich der Anwendungsentwicklung für BlackBerry 10 hat sich im Vergleich zur alten Plattform auch einiges geändert. Wurden früher BlackBerry Anwendungen hauptsächlich in Java entwickelt so gibt es jetzt 4 (!!) verschieden Möglichkeiten Anwendungen für BlackBerry 10 zu entwickeln: C/C++ Native, HTML5 WebWorks, Adobe Air Action Script, Java Android  – die alten Java Bibliotheken gehören aber nicht dazu. Aus Sicht eines Software Entwicklers, der jahrelang BlackBerry Anwendungen unter Java entwickelt hat, schmerzt das natürlich sehr. Auf der anderen Seite kann ich verstehen warum man diesen Weg gewählt hat: um auf einem mobilen Geräte optimal performende Anwendungen zu bekommen führt eigentlich an C/C++ kein Weg vorbei (siehe iOS).

Kein Wunder dass RIM zu schrägen Mitteln greift um seinen Entwicklern mitzuteilen dass sie sie immer noch “lieben”:

Wenigstens sind die neuen Entwicklungstools für alle Betriebssysteme verfügbar (OS X, Windows, Linux) und die Dokumentation auf den BlackBerry Webseiten hat sich auch deutlich verbessert. Ein weiterer Pluspunkt ist, dass RIM stark auf Open Source setzt und dabei github einsetzt um Frameworks, API’s und Samples zur Verfügung zu stellen.

Für unser Produkt timr habe ich mal die Android Version für BlackBerry 10 portiert – das hat mittels des Web Tools sehr gut funktioniert. Wir werden dass jetzt mal testen, und dann entscheiden, ob wir diese Version für BlackBerry 10 in die App World einreichen – auf den ersten Blick sieht das schon ganz gut aus.

Die zusätzlichen Tarifkosten, die bisher anfielen wenn man einen BlackBerry verwenden wollte, sind bereits gefallen – ein weiterer wichtiger Schritt, um BlackBerry Geräte am Markt wieder interessant zu machen.

RIM war mit BlackBerry wirklich ganz früh ziemlich weit vorne – jetzt sind sie ziemlich spät dran und es wird sich in den nächsten Monaten zeigen ob sie sich wieder am Markt etablieren könnnen.

What to ignore

With the latest improvements we made at troii to our development workflow, we discussed what should be committed to a source code repository and what files should be ignored. We already had the rule in place, that nothing should be put into the repository, that is generated from other sources (typically .class files, .war, .jar, …) – this rule is very common and agreed by almost every developer.

How to handle another set of files usually leads to a lot of discussion: IDE settings, e.g. Eclipse .settings, .project, .classpath or IDEA IntelliJ .iml and .idea directory). Up until a year ago we mainly used Eclipse and I used to store the IDE configuration files in the repository. With switching to IntelliJ and working more with git branches, I startet to think about this again, because I had the feeling that those settings files changed more frequently.

I read some articles and posts online and I came to the conclusion that it is better to exclude those settings files too. After looking at the dedicated github repository for git ignore templates at it became even clearer. The template for IntelliJ looks like:


The reasons I had, for putting those IDE settings into the repository, were, that I want a new developer in the team to be able to check out the code and start developing as fast as possible. A new project member should not have to configure his IDE in a very specific way to get the project running or even compiling. With using maven, gradle and Grails in nearly every project this has gotten a lot easier because most IDE’s have import features, that can interprete those build systems and configure the project.

After deciding to stick with those rules, I looked for an easy way to use those git ignore templates and found gitignore-boilerplates – or short gibo. This is a nice little shell script that allows you put the right templates for your project together into the .gitignore file, for example the line

gibo Eclipse IntelliJ Windows OSX Maven Java > .gitignore

creates a gitignore file for a Java project that uses Maven and is developed with IntelliJ or Eclipse under Windows or OS X. You could put the Eclipse, IntellIJ, Windows and OSX ignore rules into your global gitignore file on your machine but I like to put them into the project to make sure that all the other developers of the project use those rules too.

I made a fork of each of those projects because there are configuration files I want to add to the repository:

  • code style settings – so that every developer on the team formats the code in the same way
  • encoding settings – important when working on different operating systems

You can find those forks under and