Give your project a voice

We are all very into Extreme Feedback Devices (XFD), so we decided to use all our senses to gather feedback from our projects. This becomes a real challenge once you think about it, because we are naturally very focused on (and limited to) visual feedback.

So we decided to put audible feedback to work.

All our projects get continuously built by two servers in parallel. The first server checks for compilation and test errors, just like a good CI server should. The second server applies every quality metric we found helpful to the code and spits out huge amounts of numbers for every single build.

We identified the numbers that really matter to us and established a simple mechanism to scrape them from the result web pages. Then we associated a sound sample with all possible changes and plugged some speakers to our feedback server.

So now, expect our projects to clearly articulate their news.

To give you an idea of how it sounds, here’s a short list of possible audio samples:

  • Fixed an important bug: “Impressive”
  • Reduced code crap: “Excellent”
  • Introduced a bug: “Humiliation”

Imagine the words spoken like in an old Quake game. Now you can have an eventful build and be yelled at like “Impressive Excellent Humiliation”.

We reserved the biggest coding failure we can imagine happening here to a special audio sample. If somebody introduces new code crap (as determined by Crap4J), he gets ordered to “CUT THE CRAP!” at incredible volume. We used the voice of the inventor of XFDs, Alberto Savoia, taken from his delightful training video for management by numbers (position 2:03ff). The audio quality isn’t convincing, his command surely is.

If you wonder what it’s like to be suddenly interrupted by different voices rebuking or praising you – it’s healthy. You get used to it very quickly, yet the information always catches on. And the information is always relevant.

We call it our “audible remorse”.

Read more about our Extreme Feedback Devices:

We are changing our locale

This is a bilingual posting:

We decided to continue this blog in english language, though we are no way of native speakers. Old postings may be translated in the future, if worth the effort.

The Softwareschneiderei remains a german-speaking company.

—-

Dies ist ein zweisprachiger Eintrag:

Wir haben uns entschieden, diesen Blog auf englisch weiterzuführen, obwohl wir keine englischen Muttersprachler sind. Alte Einträge könnten zukünftig übersetzt werden, wenn sie den Aufwand wert sind.

Die Softwareschneiderei bleibt eine deutschsprachige Firma.

Der blinde Fleck von Continuous Integration

Blinder FleckAn english version of this blog entry can be found at https://schneide.wordpress.com/2009/12/28/a-blind-spot-of-continuous-integration/

Am Montag früh brach nach einem Routine-Update unseres CI-Servers und anschließendem manuell gestartetem Baudurchgang plötzlich ein Test in einem Projekt, das seit Wochen keine Änderung mehr erfahren hatte.

Die Analyse des Tests zeigte relativ schnell, dass offensichtlich die A-TRIP Regeln für gute Unit Tests verletzt wurden und der Test unter Verwendung des aktuellen Zeitpunkts Datumsberechnungen in die Zukunft und die Vergangenheit testet. Am Sonntag früh wurde auf Sommerzeit umgestellt, so dass dem Test plötzlich eine Stunde in der Vergangenheitsberechnung fehlte.

Den Test zu beheben war einfach, allerdings war er bereits seit Mai 2006 im Projekt enthalten. Seitdem muss dieses Projekt immer um die Zeitumstellung herum inaktiv gewesen sein. Unser Continuous Integration hat das Problem jedenfalls erst jetzt (und auch da nur durch den Zufall einer CI-Aktualisierung zum richtigen Zeitpunkt) gefunden.

Die Phänomene, die durch ungeschickte Unit Tests hervorgerufen werden, sind mit einem verdachtunabhängigen Nightly Build scheinbar zuverlässiger zu finden als mit Continuous Integration. Eine Kombination beider Techniken scheint uns nach dieser Erfahrung lohnenswert zu sein.

Unabhängig von CI oder Nightly Builds gilt: Ein Unit Test, der den Konstruktor von Date, DateTime, Calendar oder einer ähnlichen Klasse aufruft, ist vermutlich ein schlechter Unit Test.

Gedanken zu Online-Hilfen

Eine gute moderne Software hat eine kontextbezogene Online-Hilfe. Bei einer sehr guten modernen Software wird diese nie benutzt, aber das ist ein anderes Thema.

Wir haben in der Schneide verschiedene Ansätze ausprobiert, die alle einen großen Nachteil hatten: Die eingestellten Inhalte waren an manchen Stellen unverständlich oder zu knapp und der Benutzer konnte nicht viel dagegen tun. Daher befassen wir uns gerade mit der Idee, eine Online-Hilfe mit einem Wiki zu koppeln. Auf diese Weise könnten die Benutzer ihre Online-Hilfe selbst verbessern und fortschreiben, so dass die Inhalte hilfreicher werden.

Um die Vor- und Nachteile dieses Ansatzes nicht erst durch den Kunden testen zu lassen, haben wir einen Selbstversuch gestartet. Die Online-Hilfe betrifft allerdings keine Software, sondern die Schneide selbst.

Eine Online-Hilfe für den Arbeitsplatz

Wir haben uns das Konzept der “WikiTags” ausgedacht, kleine Aufkleber mit einer Wiki-Adresse und einem Symbol, das auf diesen Umstand hinweist.

Thumb Spoon WikiTag 

Mit diesen WikiTags rüsten wir gerade alle Räume und Gegenstände in Reichweite aus, so dass sie einem Eintrag in unserer Firmen-Online-Hilfe (unserem Wiki) zugeordnet sind. Über ein kleines Eingabefeld in unserem Intranetportal gelangt man direkt auf die betreffende Wiki-Seite (der sogenannte WikiWarp), kann dort die Informationen zum Gegenstand (z.B. Bedienhinweise oder Bezugsquellen) einsehen und auch gleich verbessern und ergänzen.

Spoon Wiki Page

Wir haben also eine halbautomatisch aktivierbare Online-Hilfe für unsere Firma implementiert und die ersten Erfahrungen damit gesammelt. Was ist die einprägsamste Erfahrung? Wir brauchen kleine, portable Anzeigegeräte für spezielle Anwendungsfälle (siehe Bild).

Special WikiTag

“Poor man’s reporting” oder Ultraleichtgewichtiges Java Reporting

In den meisten unserer Softwarelösungen wird irgendwann irgendeine Form von Reportdokument erstellt. Meist fällt dem Kunden ein, dass er gerne ein hübsches Pdf mit Messwerten und ein paar Diagrammen hätte. Im Laufe der Zeit haben wir diverse freie (sowohl wie in Bier als auch Rede) als auch kommerzielle Lösungen ausprobiert und eingesetzt. Darunter sind u.a. Jasper Reports und RReport, jedoch hatten sie alle ihre mehr oder weniger großen Haken und Ösen. Die meisten teureren kommerziellen Lösungen (wie z.B. Big Faceless PDF) kamen wegen des jeweiligen Projektumfangs und den wenigen benötigten Features nicht in Betracht.

Nach der Lektüre von iText in Action zur Pdf-Erzeugung und -Manipulation und der Suche nach einem Werkzeug, mit dem man einfach und bequem Acroforms erzeugen kann kristallisierte sich eine neue, extrem leichtgewichtige Lösung für das Reporting-Problem heraus: OpenOffice und iText. Carl Young beschreibt in seinem Blog die Benutzung von OpenOffice als Designwerkzeug für Acrobat Forms.OpenOffice Form

Solche Pdf-Formulare lassen sich relativ einfach mit iText ausfüllen und mit Bildern versehen und dann abspeichern.

Form in AcrobatFilled Form

Damit hat man eine pure Java-Lösung in der Software und ein mächtiges, plattformübergreifendes Designwerkzeug für die Reports.

Die augenscheinlichsten Vorteile dieser Lösung sind:

  • Reportvorlagen liegen in Pdf vor, sind somit von jedem einsehbar und kontrollierbar
  • Die Quellen für die Reportvorlagen können mit OpenOffice erstellt und geändert werden und einfach per Knopfdruck als Pdf exportiert werden
  • Die Reportdaten können in beliebigen Formaten abgelegt oder im Programm generiert werden und dann mithilfe von iText in das Pdf-Formular übertragen werden

Die bisher festgestellten Nachteile sind je nach Einsatzzweck vernachlässigbar, können aber auch zum Showstopper werden:

  • Man muss immer feste Bereiche für die Daten festlegen, sind diese zu groß, werden sie wahlweise skaliert oder abgeschnitten (geht sowohl mit Bildern als auch mit Text!). Hat man also einen langen Fließtext und der Platz im Formularfeld reicht nicht aus, so hat man ein ziemliches Problem.
  • Man bekommt kein Format für die Formulardaten selbst geschenkt, sondern muss sich selbst um deren Speicherung kümmern, um den selben Report zu einem späteren Zeitpunkt neu zu erstellen oder die Reportdaten zur weiteren Verarbeitung bereitstellen zu können. Die programmatische Extraktion der Reportdaten aus dem fertigen Pdf-Report ist extrem aufwändig bis unmöglich.

Die bisherigen Erfahrungen mit dieser OpenOffice+iText-Lösung sind sehr positiv und helfen auch sehr bei der Kommunikation mit dem Kunden. In manchen Fällen fühlt sich dieser aufgrund der Textverarbeitung sogar in der Lage, selbst Layoutänderung auszuprobieren und durchzuführen. Selbst ungeschickte Entwickler bekommen durch OpenOffice mit vergleichsweise geringem Einarbeitungsaufwand ansehnliche Reports hin oder können die Sekretärin damit beauftragen. Kostenlos ist die ganze Lösung noch dazu.

Das Ende einer Ära

Seit kurzer Zeit hat die Schneide den ersten Vertreter einer neuen Ära in der Computertechnik in Besitz: einen mechanikfreien Rechner.

Bisherige Elektronik funktionierte nie ohne einen Restbestand an Mechanik, die dann in bester Tradition auch zu den beliebtesten Verschleißteilen gehörte. Herausragendstes Beispiel waren/sind Festplatten (hier sei besonders die IBM DTLA/IC35-Todesserie genannt, die in der Schneide damals in Massen starb). Aber auch Lüfter gehören unüberhörbar zur Mechanik.

Unser neuer Rechner ist ein Hilfsserver, d.h. ein “Immer-an”-Rechner mit einer Aufgabe, die nur geringe Anforderungen stellt. Mehr zu dieser Aufgabe in den folgenden Beiträgen. Dementsprechend ist er kompakt und stromsparend konzipiert.

Ozone von vorne Ozone von der Seite

Wir entschieden uns für den kochbuchgroßen Thin-Client “Linux Via C7” der deutschen Firma Thinking Wires. Der Via C7 Prozessor ist als Nachfolger des in der Schneide vielfach eingesetzten C3 ein gerne gesehener, endlich vollständig 686-kompatibler Rechenknecht. Er lässt sich lüfterlos betreiben, so dass die Kühlung lautlos geschieht. Das passende Netzteil ist ein ebenfalls lautloses externes 65 Watt Netzteil. Die Festplatte wird durch ein sogenanntes Flash-IDE-Modul ersetzt, das bei uns mit 2GB Kapazität genug Platz für eine Ubuntu Server Installation hat.

Dieses Flash-Laufwerk ist garantiert kein Geschwindigkeitswunder (die Installation des Betriebssystems dauerte fast zwei Stunden gegenüber 10 Minuten auf einem normalen Server), aber dafür wirklich komplett lautlos.

Der ganze Rechner liefert im Betrieb nur ein leises Summen (bzw. Bruzzeln, wenn man pessimistisch formuliert), das in einem Meter Abstand nur noch hörbar ist, wenn sonst keine Geräuschquelle in der Nähe ist. Da unser Rechner direkt neben dem Code Flow-O-Meter steht und dieses entsprechend unserer Produktivität meistens läuft, ist das kein Problem.

Wir haben den Rechner “Ozone” genannt. Dabei ist uns selbst nicht klar, was der Name wirklich aussagen will:

  • Ozon: Mehr als Ozon wird durch den Rechner nicht emittiert
  • 0Sone: Das Betriebsgeräusch liegt bei fast Null Sone
  • Onoez: Mal wieder alles falsch geschrieben…

Und wofür brauchen wir diesen Rechner? Das verraten wir erst in den nächsten Beiträgen. Nur ein Tipp: Die ONOZ-Lamp gehört zum Einsatzzweck dazu.

Mein Bug, dein Bug

Historisch wertvolles TerminalIm Jahr 2002 entwickelten wir Software für eine Messapparatur, die unter anderem mit einer historisch wertvollen Datenbank über eine VT3270-Terminalemulation kommunizieren musste. Der Datenaustausch geschah über kleine Textdateien, die ausgelesen oder geschrieben wurden. Das Format der Textdateien war strikt spezifiziert und auf ein Minimum reduziert. Einige Messwerte mussten im “wissenschaftlichen Format” übergeben werden:
1.32E-01 ist gleichwertig zu 0.132

Wichtig an der Spezifikation war, dass das Format nach dem Exponententrenner “E” immer ein Vorzeichen haben musste, d.h. es wurde für den Wert 132 nicht 1.32E02, sondern 1.32E+02 erwartet.

Dummerweise hatte das damals verwendete Java 1.4.0 genau an dieser Stelle einen Bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4691683
Das Format +0.00000E00 erzeugt Wertrepräsentationen wie “+1.32E+02”, aber auch solche Kuriositäten wie “+1.32E-+01”.

Interessant ist dabei, dass das Vorzeichen des Formats im Exponenten wiederholt wird. Manuelles Entfernen der überflüssigen “+”-Zeichen brachte damals das gewünschte Ergebnis in die Dateien.

Dummerweise war das nicht der einzige Bug in Hinsicht auf das wissenschaftliche Formatieren in Suns DecimalFormat, so dass mit der Version Java 1.5 das Format “+0.00000E00” Wertrepräsentationen wie “+1.32E02”, aber auch Kuriositäten wie “+-1.32E02” erzeugt.

Mit der Änderung der Java-Version kam also ein vor Jahren durch Workaround behobener Fehler zurück, da jetzt (unter anderem) der Workaround zum Fehler wurde.

Was habe ich aus dieser Episode gelernt? Liefere möglichst kein spezifiziertes Format aus, das nicht mit Unit Tests vollständig abgesichert wurde. Und vor allem: Sichere jeden Bugreport, der nach außen geht, mit einem entsprechenden Test ab. Denn wenn der Bug nicht mehr da ist, wird auch der Workaround hinfällig und im schlimmsten Fall sogar selbst zum Bug.

Lethal risks of bugfree software

Bei der routinemäßigen Kontrolle unserer Continous Integration Server Hardware fanden wir heute eine tote Spinne auf dem Mainboard. Das ist sehr bedauerlich für das arme Tier, wir glauben aber zu wissen, woran sie gestorben ist: Verhungert wegen zu wenigen Bugs.

Eventuell hätte sie in einen Entwicklerrechner ziehen sollen.

It’s not a bug, it’s coolness

In alten Eclipse-Versionen wurden Anwendungen meistens über den “Run-Button” gestartet. Ein Klick und die vorher gestartete Anwendung wurde erneut gestartet. Das war an sich ganz praktisch, aber für “Code->Run Test->Run Application”-Zyklen leider unpassend.

Also erfanden das Eclipse-Team eine neue Funktionalität für den alten Knopf: Context launching. Leider wurde vergessen, dies dem Benutzer mitzuteilen. Der Knopf sieht aus wie früher, verhält sich (meistens) wie früher und hat auch sonst keine neuen Features. Nur manchmal, heimlich, wechselt der Kontext und man startet völlig unvorhergesehene Dinge.

Zuerst mal ein paar gute Nachrichten zu diesem Feature:

Damit hören die guten Nachrichten aber auch schon auf und die Probleme fangen an. Eine kleine Sammlung an Bugs zum Thema findet sich in den Links.

Das Feature wird bleiben – und damit eine meiner Meinung nach mittlere Usability-Katastrophe.

  • Alle Veteranen des “Run-Button” müssen umlernen oder die Funktion deaktivieren (anstatt es bei geeigneter Coolness bewusst zu aktivieren). Ok, das ist nur ein temporäres Problem der nächsten Monate
  • Der Kontext, und damit die “Intelligenz” im Hintergrund der Entscheidung, bleibt unsichtbar. Keine Farbe, kein Sinnbild, kein Ton. Ich bin wahrlich geübt im Umgang mit interrelationsreichen Computerprogrammen und Geräten, aber diesen Kontext habe ich nicht intuitiv erfasst.
  • Der Knopf bietet keinerlei Hinweis darauf, dass er jetzt etwas anderes tun wird als gerade eben noch. Er bietet auch keinen Hinweis darauf, was er jetzt tun wird. Schon eine leichte Umfärbung bei einem Kontextwechsel wäre zumindest ein Anfang.
  • Der Knopf funktioniert entweder mit Kontext oder ohne (im sogenannten Last-launch-Modus). Eine Art “Modus-Umschaltung” durch gedrückte Shift-Taste oder ähnlich gibt es nicht. Hier hilft nur der Weg durch die globalen Einstellungen oder das Bewusstmachen des Kontextes.

Fazit: Intention des Eclipse-Teams war die Erhöhung der Coolness der IDE. Erreicht wurde meiner Meinung nach eine Verhöhnung versierter Anwender: “Ihr habt es nicht mehr im Griff!”. Echte Coolness braucht den Überraschungsmoment nicht, um zu wirken.

Nachtrag/Ergänzung: In einem Kommentar zum verlinkten Blog-Eintrag des Eclipse-Teams wird davon geredet, dass das Feature sehr praktisch ist, wenn Eclipse im Tutor-Betrieb vor Studenten eingesetzt wird. Ich hoffe, trotz der unbestrittenen Wichtigkeit der Lehre, dass dies nicht der anvisierte bzw. hauptsächliche Einsatzzweck für Eclipse sein soll.

Flattening the namespace again

In sehr frühen Zeiten der Programmierung mussten Namen von Variablen oder Funktionen mit Bedacht gewählt werden, da sie alle global sichtbar waren. Dann wurden Namensräume, d.h. Namespaces erfunden und später über Objekte und für Java auch Packages weiter verfeinert.

Das Package-System von Java, auch schonmal als “Übel Nummer Eins” bezeichnet, hielt selbst gleichnamige Klassen, beispielsweise java.awt.List und java.util.List, zuverlässig auseinander.

Mit dem Aufkommen von modernen IDEs und deren Fähigkeit zur automatischen Namensergänzung (Code Completion, Content Assist, etc.) werden die Namensräume allerdings wieder klein. Dies merkt man besonders dann, wenn man eine gutgemeinte Bibliothek integriert, die beispielsweise eine eigene Klasse File mitbringt.

Die Lösung wird sein, heuristische Verfahren für die Code Completion einzusetzen, mit Prefixen (JList, etc.) zu arbeiten oder sich wieder deutlich mehr Gedanken über die Namensgebung zu machen. Wir haben das Problem nicht gelöst, sondern nur auf eine neue Ebene gehoben.