» Moritz online

It’s been a while since my last post but last weeks conference really deserves one. So, three colleagues and me went to London to attend the QCon London and to make it short: It was pretty good! Most talks I attended were really good and well, as usual, you can’t avoid to have a couple not so good ones anyway ^^ So, the main reason I’m posting here is Damian Conway’s talk Instantly better presentations. It was the best talk of all I went to, even though it had nothing to do with software development, agile or whatever. Nevertheless, I think everybody giving lectures, speeches, talks and alike should read his expose which is available on his website
Apart from this one, my no. 2 and 3 were both really good and amazing talks, but I can’t decide which one was better:

• Put a UI Developer in a Bank; See what happens by Horia Dragomir
• Hire Education – making interviews rock by Dan North and Trisha Gee

By the way, there are a ton of slides and more information available on the QCon Website!

Got a new toy and it’s simply amazing

Nexus 4

Coming from a HTC Desire HD with an old Android 2.3, which I was too lazy to root and update it manually, it’s simply amazing to use Android 4.2.1 on a device with enough power to send a dozen astronauts to the moon. The display is awesome, it’s lightning fast and the battery lasts longer than the Desire ever had

So, we’ve been using Grails at gibbon’s five for a while now and stumbled into different problems with our unit tests. One of the weirdest ones were occasionally failing tests on our Jenkins that never failed locally. So we digged into this a little and came up with a simple explanation, that I’d like to share with you.

Let’s assume we have a controller and want to test it. First thing you’d probably do is go to the Grails Guide, Chapter 10: Unit Testing Controllers and start with something like this:

import grails.test.mixin.TestFor

@TestFor(SimpleController)
class SimpleControllerTests {
    void testSomething() {
    }
}

Now, if you have multiple tests which need some variable set inside the (controller.)request and you have a little knowledge of JUnit, you’d probably come up with something like this:

import grails.test.mixin.TestFor
import org.junit.Before

@TestFor(SimpleController)
class SimpleControllerTests {
    @Before
    void initialize() {
        request.variable = "foobar"
    }
    void testSomething() {
        // some code here needs the request.variable
    }
    void testSomethingElse() {
        // some code here needs the request.variable
    }
}

This is bad.

Continue reading “Grails Unit Testing and a little fun with @Before” »

In my current project we’re using Reject.if* (ifNull, ifNotNull, ifTrue…) methods for several validations, error management etc. As we’re also using FindBugs, we stumbled upon a problem with code like the following, in which FindBugs comes up with a NP_NULL_ON_SOME_PATH warning, in this case a false positive:

void foo(String bar) {
    Reject.ifNull(bar);
    bar.getBytes();
}

After searching for a solution and asking some people, we finally found a solution that works pretty well in this case: Passing a system property called findbugs.assertionmethods [1] through Maven to FindBugs. The code for it in the pom looks somewhat like this:

...
<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>findbugs-maven-plugin</artifactId>
    <version>2.5</version>
    <configuration>
        <effort>Default</effort>
        <threshold>Medium</threshold>
        <xmlOutput>true</xmlOutput>
        <findbugsXmlOutputWithMessages>true</findbugsXmlOutputWithMessages>
        <omitVisitors>FindReturnRef</omitVisitors>
        <jvmArgs>-Dfindbugs.assertionmethods=de.mopri.utils.Reject.ifNull</jvmArgs>
    </configuration>
</plugin>
...

By using the jvmArgs element the system property is properly passed down to FindBugs and telling it that the method Reject.ifNull is used as an assertion. Now FindBugs acknowledges that bar.getBytes() won’t throw a NullPointerException

Reminds me about some discussions I had about controlling your program flow with exceptions

Using exceptions to control program flow is a bad idea. Creating exceptions requires taking a snapshot of the call stack, and that’s costly. – John Flinchbaugh Oct 16 ’08 at 12:17

Not if you override the method that generates the call stack in the exception you throw to do nothing. That’s the advantage of a custom exception. – shemnon Oct 17 ’08 at 14:03

The whole thread can be found here on stackoverflow.

Logging in grails is somehow confusing me a little. I don’t know why but even though I’m familiar with log4j and never had trouble working with it, grails logging sometimes manages to make me feel like a total newbie. After looking for a nice and simple solution for a timebased rolling and archiving, I thought someone else might be interested in it as well and I don’t have to look for it again So here is the daily rolling log configuration, which is also archiving (and zipping) the old log:
Continue reading “Grails with time-based rolling logs” »

Nachdem ich letztens noch von den versteckten Kosten berichtet habe, hat heute auch heise.de etwas dazu geschrieben. Auch zu dem hier letztens erwähnten Sicherheitsloch bei der Authentifizierung gibt es Neuigkeiten, denn es sieht so aus, als hätten die Macher dort ein wenig nachgebessert. Leider sind sie allerdings sehr verschwiegen, so dass es keine Bestätigung dafür gibt.

Der Betreiber der beliebten SMS-Alternative WhatsApp hat heimlich Änderungen an seinem Dienst vorgenommen, um eine seit längerer Zeit bekannte Schwachstelle zu stopfen.