Long story short, it’s a tool emphasizing anonymity and protecting people’s freedom, privacy and confidentiality (quite useful when you are a dissident in a not so open country).

I did install Tor so that my machine ran as a Tor relay and exit node. A Tor relay relays the data flow from one Tor node to another. An exit node is the bridge between the Tor network and the real internet: in my previous example that’s the last guy that appears to look at the website you are surfing.

Why did I do that?
Good question. I was curious first and doing my part to keep the world good is something I try to do from time to time.

What happened?
That’s the sad part. I let the node run all night and when I tried to use my connection in the morning I had a couple of bad surprises:

• Google thought I was a bot trying to run automated queries and abusing the system. Consequently, every search I was doing was guarded by a captcha (annoying).
• freenode (IRC) must have thought I was a bad guy cause I could not log onto #hibernate-dev #jboss-dev and co

I suspect some people were abusing the system and hid themselves behind Tor and I was their gateway to the internet. That left a bad taste in my mouth, I’ve disabled my Tor relay.

End of experience.

public String getName() { return this.name; }
public void setName(String name) { this.name = name; }
private String name;

I have been doing it manually for a while but it turns out IntelliJ has a super nice feature for that: Live Templating which allows you to use parameterized and contextual templates to generate code.

Go to your Settings->Live Templating and create a new one.

Add this template:

public $TYPE$ get$UpperName$() { return $lowername$; }
public void set$UpperName$($TYPE$ $lowername$) { this.$lowername$ = $lowername$; }
private $TYPE$ $lowername$;

Then edit the variables:

• TYPE: the expression should be classNameComplete() to refer to the class name context
• lowername: the expression should be decapitalize(UpperName). Also tick skip if defined to not have to validate the computed value (this saves you one key stroke).

I’ve named my Live Template “get”. When I type “get” and TAB, I am asked to type the property type (which is suggested). The second variable asked is the capitalized property name. Then the Live Template infers the rest (decapitalize my property name to fill up lowername).

Pretty nice feature!

Geek et boss: pas une frontière, un gouffre… et pourtant

Ce qui ma frappé, c’est que les geeks et les boss vivent dans des mondes complètements différents, des réalités alternatives presque. C’était particulièrement visible pendant les sessions questions / réponses des keynotes où le micro passe du développeur Java au DSI Renault. Vous aller me dire, on le sait déjà que les DSI ne comprennent rien à la technique. OK mais il y a plus.

M’étant (re)pris une claque avec cette (re)révélation, j’y a réfléchi et j’ai passé du temps à comparer les points de vue pendant ces deux jours. Bien que vivant dans des mondes parallèles, le geek a besoin du boss et le boss a besoin du geek. Aussi bizarre que cela paraisse, c’est presque une symbiose. Comme un animal et son parasite qui le protège de je ne sais quelle autre bactérie (je ne dirais pas qui est le parasite de l’autre). Il y a de l’espoir cependant: au fur et a mesure de ces deux jours, on a vu décrire des techniques et des points de vues qui essayaient de faire parler/interagir les différents niveaux en proposant un langage et terrain commun, en ajoutant des boucles de retour rapides etc (hiérarchies râteau, méthodes itératives, reconsidération de la responsabilité…).

Il y a encore beaucoup de choses a inventer, de progrès à faire. C’est un énorme chantier, particulièrement pour les sociétés françaises. Celles qui prendront le pli gagneront en compétitivité, les autre iront pleurer auprès du gouvernement contre les grands méchants de l’étranger qui leur volent leur clients.

Les keynotes: pour penser plus loin

Une bonne keynote doit présenter quelque chose qui va au delà du thème de la conference, qui fait réfléchir, change les perspectives et fait mal à la tête. L’USI a mis la barre très haut avec 8 keynotes! Toutes n’étaient pas à mon goût mais 6 sur les 8 étaient du gros calibre, voir du gros gros calibre.

Celle qui m’a mis le cul par terre c’est la keynote de Juan Enriquez. Ce monsieur est une pointure en science de la vie et un business man averti. Il a trempé de près ou de loin dans beaucoup des dernières avancées clés en biologie et notamment la récente annonce de la première cellule entièrement synthétique (pour traduire: l’homme a crée la vie a partir de 0).

Juan nous a donne la vision d’un monde:

• où les usines de chimie étaient obsolètes: une vache génétiquement modifiée génère la molécule anti-cancéreuse qui va bien dans son lait en beaucoup moins de place et de pollution
• où les matières synthétiques ne sont pas dérivées du pétrole mais générées par des cellules
• où les donnees génétiques sont du code, les cellules des microprocesseurs et les généticiens des développeurs: geek power!

La vie est la prochaine plate-forme, le vrai post-silicone. Oublier le cloud computing, le cloud computing est l’étape intermédiaire pour nous apprendre à faire du développement massivement distribué. Là où l’informatique silicone manipule des 0 et des 1, le bio développeur manipule des A,C,G,T.

Quelques chiffres clés:

• 100,000 milliards de cellules (10^14) dans le corps humain
• 6 milliards de bits dans le génome humain contenu dans chaque cellule (715 Mo)
• donc le corps humain contient 68.187.713.623 To ou 63,5 Zetta octets (pour info au dessus il y a yotta et puis plus rien )

Une fois que le “hardware” sera peaufiné, il nous suffira d’écrire l’assembleur Vie, et la GVM Genetic Virtual Machine. L’expression code smell prendra tout son sens. Cela ouvre des perspectives totalement bluffantes! Cette perspective et cette vision de Juan Enriquez était tellement soufflante que je me suis dit “je veux bosser pour lui”.

Une petite déception d’ailleurs puisqu’à part moi, les autres questions dans l’assemblée étaient négatives ou pessimistes: Quid de l’utilisation en tant qu’arme? Quid des risques de ceci et cela? Quid des règlementations à mettre en place? etc. On reconnait bien la mentalité française

L’USI est un mini TED dédié a l’IT. Le format geek / boss et les sessions de 20 minutes fonctionnent bien. Un grand merci aux USI boys and girls qui ont tout organisé et avec un peu de chance, à l’année prochaine

This is not a post on why merging is superior in Git compared to SVN (this is something you need to experience), it’s a post on how Git is making my life easier.

This post is split is a few sections:

• some intro
• how to import a SVN repo into Git (feel free to skip this tutorial of you are interested in what I liked in Git compared to SVN)
• use case: multitasking in isolation
• use case: backporting bug fixes
• use case: writing better commits and commit histories
• resources

General

If I had to summarize, Git gives me more freedom than SVN. I am not constrained by the tool in any way:

• it can follow whatever workflow I want
• it is fast
• as a net result my commits are clearer

I’t hard for me to say that but since the move I do enjoy committing stuffs (I know, that’s pretty scary).

The bootstrap

Here is a small tutorial section for people willing to import a project from SVN to Git and keep a bridge between the two. Due to a bug in git-svn for https imports, I am using Git 1.6.5.1 and not the 1.7.1 version.

mkdir project; cd project;
git svn init --trunk=my/svn/repo/project/trunk/ \
             --tags=my/svn/repo/project/tags \
             --branches=my/svn/repo/project/branches \
             my/svn/repo/project

You can optionally create a file containing a conversion between SVN logins and the committers names and email addresses

jdoe = John Doe <jdoe@foo.com>
agaulois = Asterix <asterix@gaule.fr>

In the logs, every time git-svn finds agaulois, it converts it to Asterix <asterix@gaule.fr>. If you want to do that, you need to create this file. Don’t be afraid to miss a couple of logins, if you do, git-svn will stop and ask you to add it. In your Git repository directory, run

git config svn.authorsfile ~/dir/myauthors.txt

The next step is to fetch all the information. This is long, very long. The good news is that you can stop it and restart later.

git svn fetch

Once that is done, you are good to go. To update your Git repo with the new commits from SVN do

git svn rebase

To commit your set of local commits to SVN, do

git svn dcommit

Many people, especially in the open source community, consider DVCS as a bad thing because it encourages committers to keep their work locally and not share with others. In reality, it does not. People who share frequently will continue to do so, people who don’t still don’t and should be fired. Same as usual. In practice for me, I dcommit every 4 to 6 hours.

I do recommend to import one SVN project per Git repository. You will typically get several Git repos per SVN repo. The rule is import the biggest unit that you tag / branch in isolation in SVN. For example, for Hibernate, I’ve several Git repos:

• Hibernate Core (which contains all the modules)
• Hibernate Validator
• Hibernate Search
• JPA API
• Bean Validation API
• Bean Validation TCK

All of these have generally independent release cycles and version numbers. Apparently it is possible to aggregate Git repositories via the notion of superproject but I have not tried.

One golden rule: you cannot share a Git repository and pull changes back with someone else AND use it to commit in a SVN repository. That will be a mess because git-svn rewrites the commit unique identifiers. Forget sharing repos when you use git-svn unless you are abandoning SVN and are doing a one time import.

Multitasking in Isolation

The absolute coolest feature is the ability to work in total isolation on a given topic for very cheap. I am not necessarily talking about the ability to work offline on an island (though that’s nice). I am talking about the ability to work on several subjects in parallel without complex settings.

Let’s take an example. I was working on a new feature for Hibernate Search’s query DSL. I branched master to dsl and started to work, including committing small chunks of work (more on this later). While working on it, I found a bug in the existing query engine. No problem, I literally stopped working on the new feature, put stuff aside (git stash). created a new branch off master named bug123 and fixed the bug. When I was done with the bug fix, I applied it on master and the dsl branch and resumed my work there. There is the workflow:

git checkout -b dsl #create the dsl branch and move to it
#work work commit work commit work
git stash #put not yet committed stuff aside
git checkout master

git checkout -b bug123 #create bug fix branch
#work work #fix bug 123
git commit
git rebase master #apply commits of master on bug123 (not necessary in this case as I did nothing in master)

git checkout master
git merge bug123 #merge bug123 and master
git branch -d bug123 #delete the useless branch

git checkout dsl
git rebase master # apply commits of bug123
git stash pop #reapply uncommitted changes
#work

It looks like a lot of operations but, it’s very fluid and very fast!

What’s the benefit? I’ve fixed a bug in isolation of my new feature even if the same files where impacted. I’ve committed the bug fix isolated: I can easily reapply it to maintenance branches (see below). Had I used SVN, I would have fixed the bug and committed “new feature + bug fix 123″. I would not have backported the fix to our maintenance branch nor would have my co-workers because of the complexity to separate the new feature from the bug fix. In Git the process is so smooth that I even use it to bug fix typos in comments in isolation from my main work.

I should point out that switching branch is super fast and done in the same directory. You IDE quickly refreshes and you are ready to work in the same IDE window. For me that’s a big plus over having to checkout a maintenance branch in a separate directory, set up my IDE and open a second IDE window to work in a different context of the same project: I work on five different projects on average, I can’t afford a proliferation of IDE windows. With Git, the context switching comes with much less friction and saves me a lot of time.

Backporting bug fixes

In SVN land, to backport a bug, I either:

• generate the patch off of the SVN commit, and apply it on a checkout of the maintenance branch
• manually read the commit diff and select which change I want to apply (generally because somebody has committed the fix alongside a new feature or because it has committed the feature in 7 isolated commits)

In the first scenario (the easiest), it involves

• generating the patch
• saving it as a file
• optionally checking out the maintenance branch (ie get a coffee)
• opening my new IDE window
• apply the patch
• commit the change with a log message

In Git, you:

• checkout the maintenance branch (2s)
• run the cherry-pick command (git cherry-pich sha1) over the commit or commits you want to copy from the main branch (logs are copied automatically though you can change them if needed)

So easy you actually do it

Writing better commits and commit histories

A feature I do like is the ability to uncommit things and rewrite / rearrange them. This is something you only do on the commits you have not yet shared (in my case not yet pushed to SVN). That looks like a stupid and useless feature but it turns out I use it all the time:

• I can commit an unstable work, explore a couple of approaches and come back if needed
• I can fix a typo or bad log message
• I can simplify the commit history by merging two or more commits (I typically merge commits I used as unstable checkpoints)
• These operations typically require 5 seconds or less

The net effect of being able to do that is:

• I write better log messages
• I commit more often / in smaller pieces, making my changes more readable
• If the pieces happen to be too small I merge them before synching with SVN

You can also do some more micro surgery. If you are changing code and realize that these are really two or three sets of changes and should be committed separately (changes from the the same file potentially). You can literally select which file / which line to commit. The tool GitX let’s you do that very easily.

Git can do that because it does not track files, it tracks changes. You can stage some changes for commit (two new files and changes in three files), continue working on the same set of files and commit the state as defined when you initially staged it. Your subsequent changes can then be committed later. This is a subtle difference of approach (content management vs file management) but now that I have used it, I like it better. As a consequence, if you change a file, these changes won’t be committed automatically next time you commit. You need to include them (that’s what the -a option is for when you run git commit).

Resources

I absolutely recommend you to read Pro Git:

• that’s a top quality book
• use case oriented
• and it’s also available for free online http://progit.org (though go buy it too, it’s well deserved)

Aside from that, I do use

git help command

very often, their documentation is pretty good. Otherwise, Google is your friend, there are many resources out there.

I don’t need / miss additional tools to work with Git. The command line is good enough and often less confusing (IntelliJ’s integration confused me, so I don’t use it unless I need to compare files). I do like to use GitX a graphical tool for two purposes:

• it displays branches and commits graphically
• it lets you easily stage specific lines of a file for later commit (the micro surgery tool)

That’s it folks,

I hope you enjoyed the read and that I’ve encouraged you to give it a try. git-svn made the try a no brainer really. I’ve lost probably 16 hours to learn, try and understand Git. I’m confident I will get them back within the next three to four months (my ROI is covered ). You can also try it on any directory, I am now using Git to keep a revision history of all my presentations. Remember, no need to set up a server or anything complex. Run git init and you are good to go.
Disclaimer: this is not a thorough comparison, just the feedback of a one month old user.

He replied to me

Believe me, I would like to drop a meeting, not sure which one.

To which I replied

That’s easy, anyone of them

and gave my thoughts on meetings.

If there is a need for bi-weekly meetings to integrate XXX and XXX, we’ve got a problem that meetings can’t solve.

I have a radical take on meetings, especially regularly scheduled meetings:

• assuming n persons in the meeting you waste most of the time n-2 people’s time (and if n>10, it’s likely n-1 people’s time)
• people tend to not prepare meetings. They instead think about the issue at stake while in the meeting and thus wasting n-1 people’s time. Force people to write ideas in a (somewhat short) email, and that will force them to think about the issue more deeply and synthesize.
• a need for a regular scheduled meeting is a sign of lack of trust, lack of natural communication and/or lack of proper task isolation: in any case, better treat the problem at the source than patching with a meeting.

The key to open source success is multiple but one big component is extreme resource/time stress. This constraint leads to:

• very focused teams
• limited need for sync-up style communication (hence the usual small core team)
• proper separation of tasks to limit waste

I am not against communication, I am against communication wasting time (the asymptotic version being pure noise). I favor 1-1 communication personally as the most efficient brain-picking strategy.

Here is how to do it:

• Download Proximity: this application does detect bluetooth devices and lets you launch scripts upon detection or absence of detection (download page here).
• Copy Proximity.app in /Applications
• Start the Proximity.app and open its preference panel (the application adds itself to the menu bar next to your clock)
• Reduce the device monitoring to 30s or so (less time for your colleagues to mess around)
• Add the device (the device needs to be linked with your computer bluetooth, you can do that in System Preference)
• Add an AppleScript that will be run when your cellphone goes out of range (see below)
• Optionally add an AppleScript that will be run when your cellphone goes back in range

The AppleScript to lock your computer is pretty simple. Create a file name out-of-range.scpt and add:

-- out-of-range.scpt

tell application "ScreenSaverEngine" to activate

You can do many more things in these AppleScripts like:

• change your Adium and Skype status
• unlock your screen when you come back in range

This other blog entry has a fairly compete setting example. I personally purposely do not unlock the screen when I come back in range. It’s safer to ask for the password explicitly incase someone… borrows your cellphone.

Unlike some more complex apps, Proximity is pretty simple and does not let you decide at which range a bluetooth device is considered out-of-range. The good thing is that it is pretty soft on your cellphone battery.

I know Java EE 5 and 6 quite well, I’ve been working on it, promoting it, yada yada yada. But when it comes to details on how to configure JBoss AS beyond the standard and the EE programmatic model, my knowledge leaves a lot to be desired.

Good for:

If you want to know how to:

• change the HTTP port
• create two independent clusters on a single network
• customize the thead pools of your HTTP requests, EJB 3 components etc
• tweak the transaction manager
• secure your JBoss AS installation
• etc

This book is a gold mine. Using the index or the table of content, you will reach the information in a minute.

If you want to know how the JBoss Tools can help you:

• create an application
• deploy / undeploy apps
• add new components, pages
• etc

This book will give you nice how-tos that will hold your hands from tooling installation to configuration and wizard usage.

Francesco also explains the basics of the EE programmatic model. This is quite handy as it helps you to kink a configuration trick to an application behavior: all configurations are described with how they impact your application behavior and what it means if you change them.

Not good for:

If you are looking for a book that explain the Java EE programmatic model and development practice in detail, this is not the book for you. You’re better off looking at Seam in Action or any other EE targeted book.

I will keep the book next to me when I develop and deploy on JBoss AS. Finding the right config or tuning will be much faster than a reckless Google search Reading this book, you feel that Francesco uses every bits of JBoss AS, loves it and wants to share his knowledge. Keep going

Disclosure: Swati from Packt Publishing sent me the book for free. I stand by what I said in this blog though.

public class Month {

    private String name;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

And we all complain because that consumes a lot of screen space (9 lines). Provided that the trio attribute / getter / setter really represents a unique property, why not generate it that way?

public class Month {

    public String getName() { return this.name; }
    public void setName(String name) { this.name = name; }
    private String name;

}

That’s much more compact (3 lines, ie a third of what we had) and put all related constructs as a single block. You can also mutualize the JavaDoc for free
What do you think?

Oh and please don’t tell me about Scala, Groovy or Fantom, we all know Java should have had first-class properties. But that’s life.

I have been wanting to share my knowledge and experience for a little while now. I’ll split that in three parts:

• recording
• mixing
• publishing

First things first then, for today the recording.

The material

Microphone

I use the Snowball from Blue Microphones and am very very happy with it. The sound is great, I can also carry it with me to do interviews as it has an option for 360° recording. It plugs into my USB port, is self powered and looks gorgeous on my desk

But in all reality, any USB microphone will do. For a long time I have been using the Plantronics 470 USB. The nice thing about this model is that it’s foldable and fits nicely in a traveler’s bag. Note that my version has a small bug: sometimes, after an hour or so of recording, the sound gets mangled. What I need to do is to unplug and replug the USB dongle. Hopefully, this annoying bug is no more in recent versions.

Skype

If you can, all meet in the same room to record your podcast. First, it’s nice to see people but more importantly, it will make the mixing work much much easier (see next post).

If you cannot, no problem, Skype is indeed surprisingly good to produce podcast. Just make sure everyone is on a decent connection and preferably on ethernet rather than WiFi. Oh and do not start the video, that will save some bandwidth and audio quality.

Recording

Recording strategy

There are two schools here.

• Record the sound on one computer: basically the sound coming out of Skype
• Record each podcast speaker locally (while speaking on skype) and mix the tracks together down the road.

The former is good in that it reduces the amount of mixing you have to do down the road. But it has a few drawbacks:

• the sound quality won’t be as good as the second approach as you are dependent on Skype’s instant quality. While it’s easy to recover missing words from a conversation while *into* it, it’s quite tedious when you are listening to a podcast.
• people tend to speak at the same time on skype. Since you don’t have instant visual feedback, it’s quite common to speak at the same time create a lovely cacophony.

You can record the Skype flux with tools like Audio Hijack Pro (on Mac, $32). There are free alternatives but simplicity is key for me and avoid mistakes (like not recording).

The second approach (ie. recording each local voice while speaking on skype) is pretty easy to set up but requires everyone to record locally. The easiest solution is to download Audacity (free and open source) and ask everyone to click on the record button.

Right before starting the podcast, make sure to have a common signal to sync the various tracks. I usually count down (3, 2, 1) and everybody say zero at the same time. And voilà, I’ve got my mark. Also ask everybody to stay silent for a couple of seconds: that will come handy during the mixing phase.

I personally ask everyone to record locally. I also record my Skype flux as a backup. It’s quite painful to have to re-record a podcast, so better avoid it.

PS: if someone can record the sound coming from Skype AND the local sound from my mic in the same file via Audio Hijack Pro, let me know. I know it’s possible but for some reason it does not work for me (not a huge problem as it’s not my workflow).

Recording format

Make sure to record in a non destructive format like WAV or AIFF. The reason is that you will apply a bunch of mixing tricks down the road and getting the real bits are going to help. The size is going to be roughly 700 MB per hour and per person.

What you can do to cut down the hard drive and bandwidth bill is to use the FLAC format that is a non-descructive compressed audio format. I personally use Max a free audio converter tool for Mac OS to convert my WAV or AIIF into FLAC. One hour of recording then goes down to 200 MB (around 4 times the MP3 equivalent). Audacity also can record in FLAC nateively in the latest beta version.

Backup

If you use the local recording approach, do yourself a favor, create a Dropbox account. It’s free for up to 2 GB, it’s a breeze to share files with others even my mother can do it: Dropbox materialized itself as a local directory synchronized in the cloud and subdirectories are sharable. The link I gave is a referral link and you get an extra 250 MB free if you use it.

Anyway, all the podcast participants must send you their audio file. Make sure to back them up right away (yes I know I’m paranoid). One solution is to leave them on Dropbox while you are mixing them on a different copy.

Other

That’s pretty much it for the technical side of it. Make sure to have fun when doing your podcast. You’ll be happier, people will notice the more natural tone and you will be more popular.

Another trick is regularity: record your podcast regularly. It could be once a week, once every two weeks, once a month. That will set your listeners expectations. Make sure not to overestimate your commitment: one a month is big enough. As you will see in the mixing blog post, it’s a lot of work especially when you are a beginner. It’s not unheard of to spend 6 or 7 times the final podcast length to record and publish it.

The second part will be about Mixing your podcast.

I will first talk about Hibernate Search and how the magic of approximation works in Full-text search and the next day I will cover Bean Validation and how it integrates in the Java ecosystem and JBoss AS 6 Milestone 2.

Come and say hi if you are in the Vienna area.