Das Problem mit dem Segway 4

Posted by Jens on August 17, 2010

This is a translation of the essay: The Trouble with the Segway from Paul Graham to the german language.

Der Segway hat sich, gelinde gesagt, nicht wie erhofft verkauft. Dafür gibt es mehrere Gründe. Einer davon ist das die Leute nicht auf einem Segway gesehen werden wollen. Jemand der einen Segway fährt sieht aus wie ein Idiot.

Mein Freund Trevor Blackwell hat seinen eigenen Segway gebaut, genannt Segwell. Er hat auch eine Version mit einem Rad gebaut, das Eunicycle, das aussieht wie ein normales Einrad, bis man erkennt das der Fahrer nicht treten muss. Er ist mit beiden Gefährten nach Mountain View zum Kaffeetrinken gefahren. Wenn er das Eunicycle fährt, lächeln ihn die Leute an. Aber wenn er den Segwell fährt wird er beschimpft: “Zu faul zum laufen, du Trottel?”.

Warum provozieren Segways solche Reaktionen? Der Grund das man wie ein Idiot aussiehst wenn man einen Segway fährt, ist das es so selbstgefällig aussieht. Es sieht so aus als würde man sich nicht genug anstrengen.

Ein Motorrad zu fahren ist nicht wirklich schwerer. Aber weil man beim Motorradfahren rittlings sitzt, sieht es so aus als müsste man sich anstrengen. Wenn man einen Segway fährt steht man einfach da. Wenn man so an jemandem vorbeifährt, ohne sich anzustrengen – zum Beispiel an jemandem der in seinem Auto sitzt – sieht das einfach selbstgefällig aus.

Mit folgendem Gedankenexperiment wird es klar: Stell dir etwas vor was wie ein Segway arbeitet, aber mit einem Fuß vor dem anderen, wie ein Skateboard, gefahren wird. Das würde nicht mal annähernd so uncool aussehen.

Es mag einen Weg geben mehr von dem ursprünglich angepeilten Marktanteilen zu bekommen: Macht eine Version bei der es nicht so einfach für den Fahrer aussieht. Es würde auch helfen wenn das Design mehr an Skateboards oder Fahrräder erinnern würde, statt an medizinischen Geräte.

Seltsamerweise, was Segway diese Problem eingebracht hat war das die Firma selber eine Art Segway ist. Es war zu einfach; die Firma war zu Erfolgreich bei der Geldbeschaffung. Wenn die Firma Schritt für Schritt hätte wachsen müssten, mit Iterationen über verschiedene Versionen, die an wirkliche Kunden verkauft worden wären. Sie hätten sehr schnell gelernt, das Leute auf einem Segway idiotisch aussehen. Stattdessen konnte im geheimen gearbeitet werden. Es gab haufenweise Focusgruppen, da bin ich sicher, aber es gab keine Leute die Beleidigungen aus ihren Autos schrien. So haben Sie nie realisiert das Sie auf dem Holzweg sind.

E-Book about software pricing

Posted by Jens on June 25, 2010

Through this entry in the Teambox blog from Pablo Villalba I discovered the E-Book “Don’t just roll the dice – A usefully short guide to software pricing”. The book written by Neil Davidson is available for free as pdf on the official site or as physical copy in bookstores.

Here are the, in my opinion, most important points in the book:

Choosing the right pricing model

When choosing your pricing model, here are two recommendations. Firstly, be boring. Secondly, license your software as your customers expect it be licensed – fit in with their business model.

What is your product?

You might think that your software product is just the bits and bytes that your customers download, but you’d be wrong. In reality, your product is much broader than that. It’s not just the software – it’s the documentation, the help required to get it working and the promise of support when things go wrong. It’s the future roadmap of the product, the pledge to carry on developing future versions. In some cases, it’s a dream; a way of life.

Differentiating your product

Ultimately, it comes down to differentiating your product. It almost doesn’t matter on what – features, benefits, the way that you sell, the service that you provide, the country you’re based in – more or less anything will do.

Don't just role the dice

The state of ssd in personal computing

Posted by Jens on May 20, 2010

For christmas I got a new Laptop from SantaClaus :-). After months of using it I finally found time to blog about it. The Laptop is a 15-inch MacBook Pro with an Intel Core 2 Duo 2.66 Ghz. I updgraded it to 8Gb RAM and bought an Intel X25-M SATA SOLID-STATE-DRIVE with 160 Gb.

Here are some pictures I took while replacing the original Harddisk:

HSS vs. SSD

HSS vs. SSD

Put the ssd in the laptop

Put the ssd in the laptop

Fixing the ssd inside the macbook

Fixing the ssd inside the macbook

Finished

Finished

The SSDs are the biggest performance boost in personal computing (which today means laptop computing for most people). The performance boost is incredible. Especially in software development, where you use a lot of small files, your workflow feels much smoother.

The startup time from OS X changes from 27 seconds to 16 seconds. The XBench score increased from 133.26 points to 191.70 points. This means the performance boost of the ssd adds up to 43.8%!

Here are the full xbench results in an iframe or in a new window.

Extreme feedback device – The Batman Lamp 6

Posted by Jens on April 20, 2010

In my current project my coworker Christoph an I decided to build our own eXtreme feedback device for our continious build. We started with the NET-PwrCtrl HOME a power outlet controlled over ethernet.

Then we looked for a fancy lamp. Bears and Lava lamps are already out there. So we looked for something different.

We came out with the idea to project the batman sign on our office ceiling. That was pretty straight forward. Christoph bought a bright led spot and cut out the batman sign of paperboard. Fixed it with some wire on the lamp and ready was our office batman projection.

We control the power outlet with a small Java program Christoph has written. The software PowerControl is available github. The PowerControl.jar is called from an ant target in our project cruisecontrol server when our build fails, and we have a fancy batman sign on our office ceiling that remembers us to fix the build.

Power outlet

Batman lamp 1

Batman lamp 2

Batman sign

Singletons in Java mit dem Holder-Pattern

Posted by Jens on April 14, 2010

Das Singleton-Pattern ist eines der bekanntesten Entwurfsmuster. Es wird verwendet, wenn nur eine Instanz einer Klasse existieren darf. Ein klassisches Anwendungsbeispiel ist das Schreiben von Logfiles in eine zentrale Datei. Auf Wikipedia kann man Haufenweise Nachteile des Singleton-Patterns nachlesen. Aller Kritik zum Trotz hat dieses Pattern für bestimmte Anwendungsfälle seine Berechtigung.

Ein Singleton in Java sollte mit dem Holderpattern implementiert werden. Es initalisiert den Singleton so spät wie möglich, nämlich bei der ersten Verwendung.

Die Initalisierungsphase einer Klasse ist durch die Java Language Specification (Kapitel 12.4) garantiert nicht nebenläufig.

Weil die statische Variable INSTANCE in einer seriellen Operation geschrieben wird ist keine Synchronisation von getInstance() mehr notwendig ist. Damit ist der Singleton implizit Threadsafe.

Das Pattern wurde von William Pugh im Rahmen seiner arbeiten zum Java Memory Model entwickelt. Eine gute Erklärung ist in der englischen Wikipedia unter dem “offiziellen” Namen initialization on demand holder idiom zu finden.

  1. public class Singleton
  2. {
  3.     /**
  4.      * Privater Konstruktor verhindert externe Instanzierung
  5.      */
  6.     private Singleton()
  7.     {
  8.     }
  9.  
  10.     /**
  11.      * Innere statische Holder-Klasse
  12.      */
  13.     private static class Holder
  14.     {
  15.         private static final Singleton INSTANCE = new Singleton();
  16.  
  17.             private Holder()
  18.             {
  19.             }
  20.     }
  21.  
  22.     /**
  23.      * Statische Factory-Methode
  24.      */
  25.     public static Singleton getInstance()
  26.     {
  27.         return Holder.INSTANCE;
  28.     }
  29. }

Danke an André Janus für die hilfreichen Kommentare.