Nieder mit IT! #Pigor

Pigors Abrechnung mit der IT. Sehr hübsch. Und er hat in allen Punkten Recht…

Daniel Pink – The surprising truth about what motivates us

An inspiring talk about our motivation at work – visualized with great animation.

Thanks to haha.nu!

Pixels: Short film by Patrick Jean for all fans of 8-bit games

New York invasion by 8-bits creatures, by Patrick Jean. Nice. Feels a little strange after 9/11, though.

Thanks to Nic for the link.

Who broke the build? #flexgangsta

Mal was für die Nerds im Publikum.

Danke an Björn von der JUGHH.

Comic: XKCD

Made me laugh: XKCD is a funny stick man comic for all them nerds out there. If you like Dilbert, then go and check it out.

Usability gone wrong

Dear wanderer, is it the price above the item or the price below? Choose wisely…

Sec-C

Secure Computing (Sec-C) is an interesting blog about computing and security. It got pretty much attention for its image analysis of a photoshopped advertisement.

The postings have a wide range, including airplane security, website security, photoshop and advertisments.

Don’t believe what you see, kids.

The color red is beauty

The color red is associated with lust, passion, love, and beauty as well.

My new 11,6” Netbook/Subnotebook (Acer Aspire Timeline 1810TZ) with matching sleeve (Crumpler) and matching DVD-Rom-Drive (Samsung SE-S084C) and matching pomegranat.

Pfandautomaten

Jedes Mal, wenn ich meine große Tüte mit Pfandflaschen zum Supermarkt trage, nehme ich mir vor mich nicht aufzuregen. Aber irgendwie… ist es immer so: Der eine Automat ist kaputt. Direkt bevor ich dran bist, ist der andere auch voll. Die Mitarbeiterin kommt, hat nicht so richtig Lust auf Arbeit und stellt den fast vollen Behälter des kaputten Automaten in den vollen Automaten. Es kommt, wie es kommen muss: Kurz vor Schluss ist dieser Container dann auch voll. Drei Flaschen habe ich noch, die sie an der Kasse natürlich nicht unbürokratisch annehmen können. Und drei Dosen, die aus irgendwelchen Gründen zwischen dem Penny-Pfand waren. Immerhin musste ich heute nicht jede Flasche dreimal in den Automat stecken.

Am schlimmsten ist es, dass Informatiker so etwas bauen. Ebenso wie Hotline-Warteschlagen und IVRs. Und dabei bin ich doch selber Informatiker. Argl.

So blue

Starting yesterday I am working at a new company, Blau Mobilfunk.

Seems to be a pretty good choice, a friendly company and team. Our team is developing inhouse software using Scrum, Java and Rails.
More plus points: The company is located in Hamburg’s Schanzenviertel, which means a lot of nice choices for the lunch break. And we already had and won our first table soccer match : )

Firefox plugin: AutoPager

Normally I am somehow reluctant when it comes to Firefox plugins, but with AutoPager I think I found a really useful one.

AutoPager automatically loads next pages when you reach the end of a page. It works on a ton of sites,Google,Yahoo..

That means that you will no longer have to press the “next page” button – the next page will be added at the bottom of the current pages – very useful when e.g. scrolling Google result sets. Two Thumbs up.

Clean code

Was ist guter Code? Auf Basis des Buchs Clean Code von Robert C. Martin haben Ralf Westphal und Stefan Lieser die Web-Seite Clean Code Developer eingerichtet, die Seite ermöglicht das Erwerben verschiedener Grade auf dem Weg zu einem professionellen Softwareentwickler. Sehr lesenswert: bei den Beschreibungen der CCD-Grade findet man eine Zusammenfassung der wichtigsten Prinzipien und Regeln für sauberen Code.

Dilbert

If you need a litmus test whether you are a geek, it’s Dilbert: If you love Dilbert, you’re one. Somehow most other people can’t relate… Here are two not-so-well-known links:

• The current Dilbert strips without flash-overhead.
• A blog by Scott Adams, the creator of Dilbert.

PS: Talking of nerd humor:

“Resistance is futile.”

Best programming books

I guess I like making lists.  So here they come, my favourite programming books (in no particular order):

• Domain-Driven Design / Eric Evans

  This books talks about the essence of writing software: Creating a model for some real life domain. This book is based on object oriented design, but goes much farther and contains a well of experience and guidelines.

• The Pragmatic Programmer. From Journeyman to Master /
  Andrew Hunt, David Thomas, Ward Cunningham

  Collected wisdom how to be a (pragmatic) programmer, ranging from the little detail to the big concept.

• Agile Web Development with Rails /
  Sam Ruby, Dave Thomas, David Heinemeier Hansson

  The one book on concrete technology to be included. Even if you don’t plan to use Rails, it is so much of an eye opener how simple (not only) web development can be when done right.

• The Deadline: A Novel About Project Management /
  Tom DeMarco

  One of many great books by Tom DeMarco on the the psychology and social interaction of programmers and teams.

• Getting real / 37Signals

  A (free online) book about the business- and programming philosophy of 37signals, a company developing web applications. A lot of thought provoking statements, often contrary to common wisdom.

A honorable mention goes out to Tips, Tricks & Recipes for Sybase ASE by Rob Verschoor for discussing every Sybase question we ever had in epical depth. We never found out how he read our minds in advance : )

Game Mechanics for Interaction Design

Interesting interview about mechanics from computer games being implicitly used on websites like Youtube or Twitter.

Cute cat theory

The “Cute cat theory” is a peculiar but interesting talk on web 2.0 and political activism.

Thoughts on programming – Exceptions

Exceptions bring many benefits:

• Separation between function’s results and error information
• When being part of the interface, they communicate cleary what special cases should be handled by the caller. (That’s why I in gererally prefer throwing an exception over returning null – returning null is too easy to oversee for the caller)

There are several discussions about error handling that i would not want to reopen, since I can see arguments for both sides:

• Reusing existing Exceptions vs. creating your own, meaningful Exceptions (e.g. BookNotFound vs. NoSuchElementException, especially if there is more than on potential “element”)
• Throwing exceptions for exceptional situations only, e.g. “Should a select throw a NotFound exception, or return null?”
• Checked vs. unchecked exceptions?

One of my favourite strategies for error handling is to fail early: Your program wants to be as intolerant as possible.
A configuration value is missing? Throw an exception, don’t use a default value. Fixing a missing configuration value takes about 1 minute, finding out why the program uses an unexpected value might cost you hours. Make the program opinionated and simple.

In the coding: When your program notices an error, locally it seldom has the knowledge how to fix this. Make it somebody elses problem: Throw an exception, forget about it, continue with the normal flow.

In most programs I also introduced an “InternalException”: An exception thrown for all programming errors and “can’t happens”, if they do happen. Just in case – check, throw, and forget about it.
This can occur everywhere, hence it is an unchecked exeception.

In contrast to “can’t happen” there are some exceptions that are unavoidable in real life, so these should be dealt with in a manner that is understandable for a dummy user. Don’t show the user a stack trace for this classes of exceptions:

• Configuration errors, installation errors, file not found
• Invalid user input (parameters/values)
• Other component (server, database) not reachable

When using exceptions, don’t clutter your code with try/catch. Throw everywhere, but catch only rarely: Everytime you catch, you should be able to fix/handle the problem (most times by signaling it to the user).
If you cannot handle the exception, let it flow until someone can.

This is only half the truth: One of the main other reasons for try/catch is exception mapping, the rational for this is seemingly good: Implementation hiding, especially at component borders.

try
{
    doSomething();
}
catch (JDBCConnectionException e)
{
    throw ComponentUnavailableException (e.getMessage());
}

Note there is one common mistake in the code above: You loose the valuable original stack trace. You would want to wrap the original Exception instead:

    throw ComponentUnavailableException (e.getMessage(), e);

Stack traces are a gift by mother Java, don’t throw them away light heartily.

The other major problem is that this mapping leads to a lot of duplicated try/catch code, especially if you want to map more than one exception in more than one method. As Ruby On Rails teaches us, mapping is seldom a good thing.

Untyped exceptions and your framework (Spring!) might help, but this is one of the tricky situations where code duplication is sometimes hard to avoid.

Thoughts on programming

Many programming techniques are quite complicated, but there are also some simple rules that might improve everybodies code:

Rule 1: Don’t copy code.

Everybody knows this, but how comes I find copied code almost everytime I review some project? One of the reason might be that not-copying code is a simple rule, but not an easy thing to do. Many technologies have been invented to help with this task, firstmost functional abstraction, and also Command Pattern, generics, frameworks, Aspect oriented programming etc. Still sometimes its hard, and in this situations I recommend: Find someone and talk about it, and find a solution. One of the biggest benefits of pair programming might be that it prevents copied code – you seldom commit crimes if someone is watching.

Rule 2: Minimize nesting

In respect to indentation, your code wants to be as left as possible.

Compare this code:

Version 1:

    if (myVariable.isValid())
    {
        doSomething();
        ...
        doSomethingMore();
    }
    else
    {
        throw new InvalidValueException();
    }

Version 2:

    if (!myVariable.isValid())
    {
        throw new InvalidValueException();
    }
    doSomething();
    ...
    doSomethingMore();

Version 2 is better IMHO. If you can get rid of e.g. an else, do it. This often leads to code that checks for errors/special conditions first, and makes a shortcut return (e.g. exception).

Rule 3: Don’t use abbreviations

While long names might be annoying, abbreviations come from hell. You want someone not familiar with your domain and code to understand it at a glance. Don’t let anyone puzzle if the “no” stood for “not” oder “number”.

Note that long names often signalizes that a class/method/variable hasn’t a clear purpose. I will prefer a long name over an abbreviation anyway.