Audio file (mp3) of the session.

Audio file (mp3) of the session.

My second issue was converting MOD files recorded by the camera before uploading them to Vimeo. Initially, HandBrake looked like an excellent solution as it compresses mods to mkv, my preferable format. On top of that it was free, which doesn’t happen a lot in the Mac world. However, I found out my camera starts recording new mod file every 60 minutes. To verify that and see if any recording is lost in the middle I recorded my digital clock for about 3 hours and found out no time above one second is lost. To merge the files I switched to Video Converter Ultimate for Mac which is more capable than HandBrake although it is not free. This application also allows conversion of mkv files resulting from the merge to mp3 audio so that people would be able to download the smaller audio files to their players. As a long-time iPod listener, I believe having a downloadable mp3 file is definitely a must for any technical session being recorded.

Another application I found for conversion of video files (to audio and video formats, including mp4 and mp3) was Miro Video Converter, also a free one but with a limited functionality. For instance, it doesn’t allow to control the compression quality.

At the end of the day, video converter from Wondershare is the one I use the most although I have all 3 of them installed.

One thing I wouldn’t suggest, though, is clicking the “Remember it as my default option” checkbox in the converter welcome screen as I found no way to switch the conversion mode later and had to reinstall the application to undo the default “Video” mode.

Well, now I have created my own “Technical Sessions” Vimeo channel (reposted here in “Video” category) where all sessions I ever visit will be uploaded to. The link to corresponding mp3 files is available in every video “Description”. Right now most sessions are in Hebrew but this will change next year.

This time the subject was Groovy and Ronen Narkis (@narkisr) presented Groovy as a language, its powerful GDK, AST and MOP capabilities together with GPars examples. Ronen presentation is available in his GitHub repository.

I was invited to speak about Gradle and since my session was targeted to the audience where not everyone was familiar with either Groovy or Gradle I decided not to cover it feature-by-feature or go into any technical details (and we were short on time, as always). Instead, I picked 10 facts about Gradle which, coming from the Maven background, made me say “Hmm, that’s cool!” in the past. Hope you’ll share my experience so here it is.

My other presentations are now available in GitHub as well.

In the simplest form the plugin can be used as:

..
apply from: 'https://raw.github.com/evgeny-goldin/gradle-plugins/master/src/main/groovy/CodeNarc.gradle'
..

which adds new "codenarc" Gradle task. But it is better not to rely on default values of CodeNarc version and RuleSet files which will change every time a newer CodeNarc version is released. Specifying some of parameters makes Gradle builds less vulnerable to CodeNarc updates:

..
codenarcVersion      = '0.15'
codenarcRuleSetFiles = [ 'codenarc.groovy' ]
apply from: 'https://raw.github.com/evgeny-goldin/gradle-plugins/master/src/main/groovy/CodeNarc.gradle'
..

As always, examples and documentation are available in the Wiki. Your comments, feedback and bug reports are most welcome!

This is the third Gradle plugin released as of today. Two others are:

• “About” plugin adds textual “about” file to build artifacts created, linking each binary artifact to the build environment and sources it was created with. The file added contains details about build date and time, last commit made in the project, Java / Gradle versions used for build and some other optional elements like project dependencies, local paths, system and environment variables. If the project was built by Jenkins, TeamCity or Hudson build server then corresponding job details are also added to the file generated.
  
  This is a simple and powerful way to keep all your artifacts aware of their build context, timestamp, and environment.
• “Duplicates” plugin locates duplicate libraries in Gradle configurations. Duplicate libraries have different coordinates (group or name) but contain an identically named classes, i.e., classes with identical fully qualified names. One source of possible duplicates are changes done to library coordinates in Maven repositories. When libraries evolve, migrate, grow up and split up they may start naming their artifacts differently. And then having an old and new version of the same library in Gradle configuration causes a duplicate problem.
  
  Another possible source of duplicate classes in the same configuration are repacking portions of one library in another which may happen from time to time. Whatever reason for duplicate is, this plugin quickly locates all of them and either fails the build or displays a warning.

New Gradle plugins will surely be added later so stay tuned!

Some more good news! “Jenkins: The Definitive Guide” published by O’Reilly Media now contains my contribution dedicated to "maven-jenkins-plugin" in chapter 10, “Generating Your Maven Build Jobs Automatically”. I would like to thank John Ferguson Smart for letting me provide this contribution!

Java:   log.error( "Class [" + c + "] not found" )
Java:   log.error( String.format( "Class [%s] not found", c ))
Groovy: log.error( "Class [$c] not found" )

The reasons were mostly to spot any trailing whitespaces in variables logged which was very helpful in error messages. As simple as it sounds, lots of messages thrown or logged today still don’t enclose variables in any special characters which can make them quite obscure.

What would you say about this error message ?

..
java.lang.IllegalArgumentException: No enum const class Something.
	at java.lang.Enum.valueOf(Enum.java:196)
..

I was surprised why failing Enum.valueOf() didn’t include the wrong value in the error message. But it did! Here’s the failing code:

..
enum Something{ A, B }
assert Something.A != Something.valueOf( '' )
..

So it was an empty String. Normally, wrong Enum.valueOf() input is printed:

..
enum Something{ A, B }
assert Something.A != Something.valueOf( 'C' )

java.lang.IllegalArgumentException: No enum const class Something.C
	at java.lang.Enum.valueOf(Enum.java:196)
..

But with empty argument "No enum const class Something." simply looked like a period at the end of the sentence! I wish it was "No enum const class [Something.]" instead.

// "java/lang/Enum.java"
public static <T extends Enum<T>> T valueOf(Class<T> enumType,
                                            String name) {
    T result = enumType.enumConstantDirectory().get(name);
    if (result != null)
        return result;
    if (name == null)
        throw new NullPointerException("Name is null");
    throw new IllegalArgumentException(
        "No enum const " + enumType +"." + name);
}

Groovy 1.8.0 released in April brought a lot of new features to the language, one of them is native JSON support through JsonSlurper for reading JSON and JsonBuilder for writing JSON.

I recently used JsonBuilder in one of my projects and initially experienced some difficulties in understanding how it operates. My assumption was that JsonBuilder works similarly to MarkupBuilder but as I have quickly found out, it really doesn’t.

Let’s take a simple example. Assume we have a class Message that we would like to serialize to XML markup and JSON.

@groovy.transform.Canonical
class Message {
    long   id
    String sender
    String text
}

assert 'Message(23, me, some text)' ==
       new Message( 23, 'me', 'some text' ).toString()

Here I used Groovy 1.8.0 @Canonical annotation providing automatic toString(), equals() and hashCode() and a tuple (ordered) constructor.

Let’s serialize a number of messages to XML.

def messages = [ new Message( 23, 'me', 'some text'       ),
                 new Message( 24, 'me', 'some other text' ),
                 new Message( 25, 'me', 'same text'       )]

def writer = new StringWriter()
def xml    = new groovy.xml.MarkupBuilder( writer )

xml.messages() {
    messages.each { Message m -> message( id     : m.id,
                                          sender : m.sender,
                                          text   : m.text )}
}

assert writer.toString() == """
<messages>
  <message id='23' sender='me' text='some text' />
  <message id='24' sender='me' text='some other text' />
  <message id='25' sender='me' text='same text' />
</messages>""".trim()

Well, that was pretty straightforward. Let’s try to do the same with JSON.

def json = new groovy.json.JsonBuilder()

json.messages() {
    messages.each { Message m -> message( id     : m.id,
                                          sender : m.sender,
                                          text   : m.text )}
}

assert json.toString() ==
       '{"messages":{"message":{"id":25,"sender":"me","text":"same text"}}}'

Wow, where did all other messages go? Why only one last message in the list was serialized?
How about this:

json = new groovy.json.JsonBuilder()

json.messages() {
    message {
        id     23
        sender 'me'
        text   'some text'
    }
    message {
        id     24
        sender 'me'
        text   'some other text'
    }
}

assert json.toString() ==
       '{"messages":{"message":{"id":24,"sender":"me","text":"some other text"}}}'

Same story. Initially I was puzzled, but then JsonBuilder source code showed that every invocation overrides the previous content:

JsonBuilder(content = null) {
    this.content = content
}

def call(Map m) {
    this.content = m
    return content
}

def call(List l) {
    this.content = l
    return content
}

def call(Object... args) {
    this.content = args.toList()
    return this.content
}

def call(Closure c) {
    this.content = JsonDelegate.cloneDelegateAndGetContent(c)
    return content
}

As you see, one should invoke JsonBuilder exactly once, passing it a Map, List, varargs or Closure. This makes JsonBuilder very different from MarkupBuilder which can be updated as many times as needed. It could be caused by the JSON itself, whose format is stricter than free-form XML markup: something that started as a JSON map with a single Message, can not be made into array of Messages out of sudden.

The argument passed to JsonBuilder (Map, List, varargs or Closure) can also be specified in constructor so there’s no need to invoke a builder at all. You can simply initialize it with the corresponding data structure and call toString() right away. Let’s try this!

def listOfMaps = messages.collect{
                 Message m -> [ id     : m.id,
                                sender : m.sender,
                                text   : m.text ]}

assert new groovy.json.JsonBuilder( listOfMaps ).toString() ==
       '''[{"id":23,"sender":"me","text":"some text"},
           {"id":24,"sender":"me","text":"some other text"},
           {"id":25,"sender":"me","text":"same text"}]'''.
       readLines()*.trim().join()

Now it works :) After converting the list of messages to the list of Maps and sending them to the JsonBuilder in one go, the String generated contains all messages from the list. All code above is available in Groovy web console so you are welcome to try it out.

Btw, for viewing JSON online I recommend an excellent “JSON Visualization” application made by Chris Nielsen. “Online JSON Viewer” is another popular option, but I much prefer the first one. And for offline use “JSON Viewer” makes a good Fiddler plugin.

P.S.
If you need to read this JSON on the client side by sending, say, Ajax GET request, this can be easily done with jQuery.get():

<script type="text/javascript">
var j = jQuery;

j( function() {
    j.get( 'url',
           { timestamp: new Date().getTime() },
           function ( messages ){
               j.each( messages, function( index, m ) {
                   alert( "[" + m.id + "][" + m.sender + "][" + m.text + "]" );
               });
           },
           'json'
        );
});
</script>

Here I use a neat trick of a j shortcut to avoid typing jQuery too many times when using $ is not an option.

But this beautiful Git presentation (download) by Luca Milanesio of GitEnterprise and HudsonMobi provided a better solution! Take a look:

[~/projects]$ git clone git://git.kernel.org/pub/scm/git/git.git
[~/projects]$ cd git
[~/projects/git]$ git checkout v1.7.5.4
[~/projects/git]$ make prefix=/usr/local all
[~/projects/git]$ sudo make prefix=/usr/local install
[~/projects/git]$ git --version
git version 1.7.5.4
[~/projects/git]$ source contrib/completion/git-completion.bash
[~/projects/git]$ export PS1='\W$(__git_ps1 " (%s)") \$ '
git ((v1.7.5.4)) $

Now my command prompt always displays current Git branch. Let’s try TeamCity build agent checkout folder:

git ((v1.7.5.4)) $ cd ~/java/agent/work/56ff0db610964031/
56ff0db610964031 (master) $

It works! Many thanks, Luca.

#[12:48:47][~/projects/git] ((v1.7.5.4)) $ cat ~/.bash_profile | grep PS1
PS1='#[\t][\w]$(__git_ps1 " (%s)") \$ '
#[12:49:45][~/projects/git] ((v1.7.5.4)) $ cd
#[12:52:40][~] $