Google Merchant Module for ROME

Google Merchant is the way a company can feed their products into Google Shopping and ROME is a Java Library to create and parse RSS and ATOM feeds. Google Merchant allows RSS as one of the feed formats you can use to feed them their data. In order to get additional information into ROME created feeds you have to implement 4 classes, so it is not really easy to get your data there.

I created a small Library to make RSS feeds that conform to Google Merchants requirements:

        final SyndFeed feed = new SyndFeedImpl();
        feed.getModules().add( new GoogleMerchantModuleImpl() );

        final SyndEntry entry = new SyndEntryImpl();

        entry.setTitle( "Title" );

        final GoogleMerchantModule merchantData = new GoogleMerchantModuleImpl();
        merchantData.setImageLink( "SOME IMAGE URL" );

        entry.getModules().add( merchantData );

It’s under MIT License up in Github, you can direct download the Version 0.1 here.

Code with style: Readability is everything

So, by now everybody got it: Code is there to be read by people, to be analyzed by people and to be understood by people. The fact that you can put it through a compiler and run it is a nice sideffect, but nothing to focus on. Besides writing readable tests of course.

But when software is growing and many different hands touch the same spots, it somehow gets dirty. So even when you have usually quite high coding standards, it still can happen that I stumble upon something like this:

User user = userService.createNewUser( email, password,
                                       false, true, null, 5 );

I like to be able to read a line of code like a line of text. Which means that I at least want to be able to get the “words” without the surrounding context.

So what would you be able to tell about the above snipplet? I would say: it apparently creates a new user, using some service and it requires an email and a password, which might be stored somewhere. And the point that makes me cry: apparently some magic flags, a nullable parameter and a magic number.

So lets see how we can clean this up with some new patterns. I usually make up my own names, if someone has a rather more common name for them feel free to comment, I will  be happy to replace them.

Enum as Flag Pattern (aka do not use boolean literals) 

enum FailIfExists { YES, NO };
enum NewPasswordChecks { YES, NO }

User user = userService.createNewUser( email, password,
                                       null, 5 );

So, what can you tell about the method call now. The problem of methods that react to flags aside, the readability is better. You at least can deduct now that there might be no error if the user already exists and that it uses the “new” password checks. It is even easier to refactor to use the third password validation algorithm should it ever be changed again.

When setting up a new project you might try to disallow all boolean literals in certain high level classes, I don’t know if it works that well with third party libraries. This might be a cool Checkstyle rule to try.

No nullable Parameters Pattern (aka keep your implementation details internal)

So what is my next problem? Well, the given null parameter value. I believe that the ability to cope with null values is an implementation detail that belongs in the class that defines a method. So the UserService interface should provide us with an overridden version createNewUser that does not have the fifth parameter. Then the implementation could hide the fact that this parameter is really nullable. And it avoids the clutter of methods that have n optional object parameters.

If you use Findbugs in combination with the great JSR 305 annotations, which by the way can be enforced using a Checkstyle plugin, you might try to disallow using the Nullable Annotation in public methods. Maybe even for protected methods. In any case, you should never have to use a null parameter while calling a visible method of another class.

No literals outside constant definitions (aka give names to your magic numbers)

The last thing is a classic, but there are still a couple of people who do not use constants instead of literals. I think the general rule is that you should never use a numeric literal inside a method, but always a class declared constant. Furthermore this might even be extended to be valid for String literals and as told in the first point to boolean literals.

So let’s revisit my short (and bad) example taking the above mentioned points into consideration:

enum FailIfExists { YES, NO };
enum NewPasswordChecks { YES, NO }

private static final int INITIAL_NUMBER_OF_INVITES = 5;

User user = userService.createNewUser( email, password,
                                       INITIAL_NUMBER_OF_INVITES );

Given that you might see this lines of code during a review, where you can’t browse the complete source of your project, one might now be able to better understand what this method does: it creates a new user with the given email and passwords, succeeds even when the user already exists, uses some mythical new password check and gives him an initial number invites of five. This can be guessed by just reading code, without a single line of JavaDoc and even without once visiting the declaring class or interface.

So in future, when writing code, try to consider if you would understand your method calls without ever having seen the implementation or even the declaration of the called method.

Quickhacks: Visualizing contributions with git

Contributions for Git

So I had a little fun with git history visualization. Gource is there to show the progress of a repo over time, but I always wanted to get an actual snapshot of the repo at a given point in time. I wrote a little program, that basically does a “git ls-files” and then a “git blame -e” for all files that seem to  be source files. Then it resolves the Email-Addresses using gravatar and scales the image relative to the amount of lines the contributor is currently blamed for. The above image shows the visualisation for Git itself. It still needs some polishing, the algorithms for packing and sizing are all a bit off and not really correct, but mostly it creates nice imags. It is up on github if you want to play with it.

Contributions by Author for Prototype (the js library)
Contributions for pdf.js

Quickhacks: Github Event Widget for WordPress

A couple of days ago Github announced their new Event timeline API. As I wanted to have a nice widget for this blog but didn’t want to write any PHP I thought maybe they would do PJSON and I could implement a client side pure JavaScript solution. Apparently, they accept a “?callback=” Parameter to the request, so I using jQuerie’s excelent Ajax abstraction it’s plain simple to get your own feed:

var user = "marcus";
var url = "" + user  "/events?callback=?";

jQuery.ajax( {
             url : url,
             dataType : 'jsonp',
             success : handleData
            } );

Now you just have to implement the handleData method to do something nice to the data. Throw  in the excelent Moment.js and you got what you see to the right. The full script is in a Gist. 150 lines is still a little long but I’m not really in a golfing mood right now.
To integrate use a plain Text Widget for WordPress which includes the two scripts, given that jQuery is already somewhere there:
<script src=""></script>
<script src=""></script>

<ul id="github"><ul/>
Feel free to fork and create your own. I did not map all events because I just wanted a selection to be displayed.

Code with style: Exception handling antipatterns

There a couple of exception handling patterns that I come across regularly that I believe to be plain wrong or harmful. In order to get rid of them I’d like to present them here and explain the reasons why they should be avoided:

Log-Log-Log and Rethrow

Imagine a typically layered application design where you have a DAO layer at the bottom, a service or business logic layer in between and a frontend layer on top. Now imagine that you decided to wrap most exceptions from the lower layer and rethrow them with an exception which is more apropriate to the level of abstraction that you are currently on:

DAO Layer:

public T getById( Id id ) {
try {
 } catch( Exception e ) {
 LOG.error( e.getMessage(), e );
 throw new WrapperException( e );

Service Layer:

public T doSomething( Id id )
try {
 T foo = getById( id );
 } catch( Exception e ) {
 LOG.debug( e.getMessage(), e );
 throw new WrapperException( e );

This happens again in the UI layer. You usually do not have per layer logfiles, as this would make it harder to see the flow of the application. But when you log the exception on every layer, it leads to a lot of log clutter. The best way is to define a layer that logs the exception, the business layer being the obvious candidate here. Thus you have a defined way to handle lower layer exceptions. This pattern does not appear that often anymore, as unchecked exceptions are generally considered the better solution today.

Fail Silently

There are two versions of the fail silently antipattern:

Version 1:

 try {
} catch (Exception e ) {
// empty block<

Version 2:

 try {
 return true;
} catch (Exception e ) {
 return true;

The two versions of the Fail Silently Pattern have the same problem: you will never know that an exception happened. Combined with the fact that Exception is caught all kinds of runtime problems can be hidden. Usually, you should always catch specialized exceptions that you expect and can handle. If you’re doing frameworks or using libraries that might throw all kinds of exceptions, or you write handling code that needs to handle all kinds of exceptions on some way you still must log what is happening there. Otherwise you will never be able to explain certain behavior in production. And an exception handling block should never return the same value as the usual code path. After all it is an exception handling block.

Fail with least possible information

 try {
} catch (Exception e ) {
LOG.error("Something went wrong");

There are two simple rules when handling exceptions: always log the exception including the stacktrace and always include any data which might have lead to the stacktrace. I still see it today that people discard all information directly at their fingertips to log out what they think might have happened at that point. Or what they have expected to happen. Together with to wide catch clauses this leads to the problem that you do not really know what happened in production, you just believe you know. Even worse, you might stick to assumption someone else made about the error at the point. So when you write a try-catch-block, always see that the variables used in the try are also logged out in the catch.

Deduct from vagueness

 try {
} catch ( Exception e ) {
 throw new CustomerNameTakenException( "The user already exists" );

This is somehow the worst case of the above mentioned pattern. Here not only the wrong information is logged but it is used to create error messages. This might lead to all kinds of wrong behavior. Just because you know that a certain layer or lower level function behaves in a certain way does not make it an interface. Maybe a different exception is thrown, maybe something else went wrong.

As usual, these points are open for discussion. But I believe that these are some general rules everyone needs to apply when writing exception handling code.

Was hilft wirklich bie Muskelkater

Inspiriert durch die steigende Nutzung von Fitocracy und den dadurch quasi erreichten Zustand von Dauermuskelkater habe ich mich mal ein wenig zu Muskelkater umgesehen:

Fakt ist wohl das Muskelkater durch die Beschädigung der Muskelfasern durch die Belastung entsteht und nicht durch Milchsäure. Dabei liegen die Schmerzen wohl tatsächlich an entzündlichen Reaktionen auf diese Verletzungen. Dazu gibt es folgende Infos:

Treatment and prevention of delayed onset muscle soreness
Delayed Onset Muscle Soreness Treatment Strategies and Performance Factors
Various Treatment Techniques on Signs and Symptoms of Delayed Onset Muscle Soreness


Sauerkirschsaft ist wohl entzündungshemmend, daher gibt es eine Studie die wohl belegt das man bei regelmäßiger Einnahme vor, während, nach dem Sport weniger Muskelater bekommt:

Ascorbinsäure/ASS/Aspirin/Paracetamol etc.
Widersprüchlich, im Endeffekt schwächt wohl Paracetamol sowohl die schmerzen als auch den Effekt von Training ab, daher wohl eher nicht so zu empfehlen. An die Studie für Aspirin komme ich nicht dran, die ist aber auch von 1988 und das scheint jetzt nicht das silver Bullet gewesen zu sein.

Warmes Wasser
Oh wunder, warmes Wasser, also schön in die heiße Badewanne, hilft wohl:

Hilf nicht:

Vitamin C:
Kann man ja mal ausprobieren, hilft aber nicht:

Massagen und Stretching:
Hat alles keinen großen Einfluss, ist wohl beides wegen der zusätzlichen mechanischen Belastung eher schlecht.

Am Besten ist es übrigens gar keinen Muskelkater zu verursachen, bringt nämlich auch nix: Muscle damage and muscle remodeling: no pain, no gain?

Gleichheit unter Schmerzen

Und da findet sich auch der erste Hinweis für die Vermutung, dass es bei der Ablehnung des Feminismus nicht um inhaltliche, sondern eine emotionale handelt. Und so geht es ans Eingemachte. Die Teilnehmer berichteten von ihrem Dasein als frauenferne Nerds, von den Demütigungen in der Pubertät und der gefühlten Ohnmacht gegenüber Frauen. Es wird deutlich: Mit der Behauptung Frauen seien strukturell benachteiligt wird die eigene Erfahrung konterkariert, der Schmerz, die Demütigung scheinbar negiert.

Quelle: Telepolis

Was passiert, wenn man einen Haufen Nerds nimmt, sie in einen Raum lockt und über Equalismus spricht? Anscheinend erzählen die Dinge die einen dann zu einer interessanten These bringen: Männliche Nerds sind irrational, da emotional, antifeministisch, da sie nicht mit Frauen umgehen könne. Genauer: Wenn ich mit 16 keine abbekomme kann ich mit 26 nicht sehen, dass in dieser Gesellschaft so einiges schief läuft.

Das finde ich, um es freundlich auszudrücken, provokant. So zumindest formuliert es Julia Schramm (@laprintemps) in ihrem Artikel auf Telepolis. Da die gute im Moment wohl Emanzipation und den Feminismus für sich entdeckt hat ist das wohl im Moment ganz ihr Thema. Wobei ihre Blog Artikel auch eher etwas sind was der normale Durchschnittsleser wohl besser mit gezücktem Bleistift zum markieren und einem Glas Rotwein genießt.

Doch zurück zu dem doch eigentlich so schönen Thema Equalismus. Nehmen wir mal das Thema strukturelle Benachteiligung, weil ich denke das das auf jeden Fall etwas ist das überhaupt nicht für eine emotionale Herangehensweise taugt. Fakt ist, das z. B. Frauen immer noch weniger verdienen als Männer in gleicher Position und mit gleicher Qualifikation. Fakt ist auch das es dafür keinen Begründung gibt, die am Anfang des 21. Jahrhundert noch irgendwas bedeutet. Und aus diesen Fakten entsteht nicht nur das Gefühl der Ungerechtigkeit, sonder der Fakt das dies nicht Gerecht ist.

Daneben sehe ich es auch als Fakt an das Nerds und vor allem Leute die auf einer OpenMind rumhängen doch sehr gebildete Menschen sind. Das heißt auch das sie die beiden vorher genannten Fakten nicht einfach aus emotionalen Gründen ignorieren können. Und mal im Ernst, das ist doch kein Haufen von antifeministischen Psychos? Oder doch? Ich war ja nicht dabei, aber so sehr kann dort die Atmosphäre doch nicht gekippt sein.

Meines Erachtens hat das Eine mit dem Anderen gar nichts zu tun. Persönliche Erfahrungen mit dem anderen Geschlecht und daraus evtl. entstandene Verletzungen sollten nie einen Einfluss auf die tief sitzende Weltsicht haben. Tatsächlich würde diese Beobachtung nämlich bedeuten das es nicht wenige Menschen gibt, für die der Schluss “ich habe Schmerzen erfahren, daher sehe ich deine nicht” als Lebensmotiv funktioniert. Und wenn wir immer noch da sind, dann ist sehr viel in unserer Gesellschaft schief.

Ich hoffe irgendwie inständig das dieser Punkt falsch ist, weil ich doch hoffe das es in der Allgemeinheit dieses beschriebene Handlungsmotiv so nicht gibt. Und erst recht nicht unter Nerds. Gleichheit muss im Zweifel auch unter Schmerzen ein hohes Gut bleiben. Und ich hoffe auch das ich das nicht nur so sehe weil ich mit 16 eine Freundin hatte.

Nina Pauer: Wir haben keine Angst

“Luxusprobleme sind keine Pseudoprobleme”

Da ich gerade bei einer Lesung in der überaus schönen Buchhandlung cohen+dobernigg in der Schanze war bin ich immer noch ganz beseelt. Nina Pauer ist freie Autorin bei der Zeit, bloggt, ’82er Jahrgang und hat ein wunderbares Buch über unsere Generation geschrieben. Naja, eigentlich hat sie ein Buch über uns geschrieben. Uns ist in dem Falle die endzwanziger Akademikerkinder, die festgestellt haben das sie ja jetzt langsam 30 werden und somit schon seit 10 Jahren im Hamsterrad sind. Oder so ähnlich. Im großen und ganzen geht es um die Probleme die wir trotzdem haben, über die Angst und Überforderung die dieses “die Welt steht euch offen” manchmal verursacht. Das ganze ist schön verpackt in zwei extremen Charakteren, die es aber so auf jeden Fall geben kann und einem sehr angenehmen Schreibstil. Ich persönlich denke das das eines der besten Bücher ist die ich dieses Jahr gelesen habe. Lösungen hat sie nicht parat, aber wenn wir nicht alle langsam einsehen das es auch in unserer Welt grenzen gibt dann werden die meisten nicht sonderlich alt, oder nicht sonderlich glücklich, oder beides.

Auf jeden Fall sollte jeder zwischen 25 und 35 “Wir haben keine Angst” lesen, um zu sehen wo man selber steht. Und um zu reflektieren wo man sein möchte. Und vielleicht um einfach etwas glücklicher zu werden, in dem Wissen das man nicht alleine ist.

Quickhacks: Git Swap: Swapping the two topmost commits

Maybe my workflow is broken, but I often have the problem that I need to swap the last two commits I did to my git repository. That is due to the fact that my last commit is usually what I’m really working on. I know I could use more branches, but still. When I’m cleaning up this commit, e.g. to get it past all the static (Findbugs, Checkstyle) checks bevore publishing it, I sometimes come along stuff that is broken or ugly but has nothing to do what I’m currently doing. Not beeing able to leave wrong code untouched I fix it and commit it away. But now the last commit is not what I’m “–amend“ing to anymore. What I always wanted to do is “git swap“, to just swap the commit before the last one to the top of my chain. I know that I can do a combination of git rebase –i or git reset, but I like stuff to be simple. I opted to write a script that rewrites the git-rebase-todo in order to make handling of conflicts more straight forward. So now I can do this:

$ mkdir git_swap_test
$ cd git_swap_test/
$ git init
Initialized empty Git repository in /tmp/git_swap_test/.git/
$ echo 'foo' > file1
$ git add file1
$ git commit -m 'First Commit'
[master (root-commit) 14b55a7] First Commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 file1
$ echo 'bar' > file2
$ git add file2
$ git commit -m 'Second Commit'
[master c9f97e4] Second Commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 file2
$ echo 'baz' > file3
$ git add file3
$ git commit -m 'Third Commit'
[master 40f98d8] Third Commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 file3
$ git log --format=oneline
40f98d8bfbc4edaede576e18b7f4fa20dfde02bf Third Commit
c9f97e42e2ecd0821e3edf45c4dd599540972b46 Second Commit
14b55a753ea9ed291ec511d42effdf190e44ad09 First Commit
$ git swap
Reversing all commits up to HEAD~2
Successfully rebased and updated refs/heads/master.
$ git log --format=oneline
569fd69259bcf7ca8a4a25fe4c3e82e860e995d8 Second Commit
7414eee241877e0f0c0d4d317c4f06384bd27715 Third Commit
14b55a753ea9ed291ec511d42effdf190e44ad09 First Commit
$ git swap
Reversing all commits up to HEAD~2
Successfully rebased and updated refs/heads/master.
$ git log --format=oneline
300c358d4d6e2b26a4f06c41e438068a7d6b630e Third Commit
87ac4cf567bcab51a57c1599de8b5faee1b7cfb7 Second Commit
14b55a753ea9ed291ec511d42effdf190e44ad09 First Commit

What I did to do this is first write a small Shellscript that basically overrides GIT_EDITOR with my own Perl implementation: is what makes it possible to call “git swap“. Acutally, you could call it with any commitish, in order to swap up to there, but that might not be what you want.  It just defaults to the two topmost commits. The real work is done in the file:
This reads the git-rebase-todo (which comes as the first command line parameter), reads all it’s lines and reverses the order. That is what git rebase -i uses to change the order of the commits. That’s it. Now I save at least 5 seconds per extra commit, because that is the time my Emacs needs to boot up ;).


Contagion FilmplakatContagion ist ein sehr guter Film, vor allem ist er sehr unaufgeregt.
Der SPIEGEL hat schon eine sehr schöne Kritik verfasst, somit kann ich nicht viel hinzufügen. Im großen und ganzen schöne Starbesetzung und vor allem: ruhig. Der Film baut nicht auf diese Outbreak-Artige Konfrontation, wir hier, die bösen da, sondern zeigt einfach was passiert. Und das eher dokumentarisch als nach den großen Effekten zu suchen. Doch dabei macht er echt nachdenklich, wenn er einfach Menschen in der Zeit der Seuche zeigt, wie jeder einzelne reagiert und wie Menschen halt so sind.
Für Lacher sorgt dann doch wenn jemand im Kino hustet. Und vor allem an dem Tag meines eigenen Flu-Shot ist es besonders komisch das zu sehen.
Ich kann den Film also hiermit sehr empfehlen.