90 Tage bis zum Sommer

Ich habe mich entschlossen, quasi inoffiziell beim Summer Blog Contest von Tom Venuto mitzumachen. Inoffiziell, weil ich keine Lust habe, mich irgendwo zu registrieren und weil ich keine Lust auf irgendwelche Preise habe.

Im Prinzip werde ich also in den nächsten 90 Tagen ein Trainingstagebuch mit Vergleichsbildern, Messungen und Einträgen führen und am 31. August in besserer körperlicher Verfassung dastehen.

Meine Startdaten

Gewicht 81,1kg
Körperfett 12mm

Mein Trainingsprogramm

Mein Trainingsprogramm wird aus 3x Krafttraining und 5x Lauftraining pro Woche bestehen. Ausserdem eine anständige Diät, die lowcarb sein und mit wenigen Süssigkeiten auskommen wird.

Da ich mittlerweile autofrei bin, werd ich ausserdem jeden Tag ein paar Schritte zu Fuss gehen. Zum einen natürlich ins Büro und zurück, ausserdem zum Einkaufen und zum Papier/Glas-Container. Ich bin gespannt, wieviele Schritte ich zurücklege. Sobald mein Fitbit ankommt, wird natürlich damit gemessen – bis dahin muss es das Iphone mit Footsteps Pedometer tun.

Flattr als neuer Bezahlansatz für die Internetgemeinschaft

Gerade habe ich meinen Invite-Code für Flattr bekommen und sofort die Registrierung abgeschlossen. Der Bezahldienst für Jedermann befindet sich im Moment noch in der unvermeidlichen Beta-Phase, wird aber in Deutschland schon rege genutzt. Über die Internetseite lassen sich im Internet kleine Geldbeträge bequem per Mausklick an Inhaltersteller verteilen. Man braucht nur auf einen der Flattr-Buttons klicken, der neben dem für gut befundenen Inhalt steht und am Ende des Monats bekommt der Inhaltersteller anteilig zu allen Klicks die der Nutzer gemacht hat, einen kleinen Betrag auf sein Flattr-Konto.

Klingt interessant: Ein Facebook-Like-Button mit Bezahlfunktion. Man gibt also nicht nur dem Provider Flattr vermarktbare Informationen, nämlich “Was mag der Benutzer”, sondern gleichzeitig einen (symbolischen?) Betrag an den Ersteller der Inhalte, die gefallen. Sehr, sehr interessant.</p>

Und da ich sowieso der Meinung bin, dass die Leute gerne für interessante Dinge etwas Geld bezahlen, wenn es nur bequem und einfach funktioniert, wollte ich bei Flattr einsteigen. Ich erwarte dadurch –genauso wenig wie bei der Adsense-Werbung im Aikidoforum– einen nennenswerten Betrag. Aber der Ansatz ist so neu und gut, dass ich unbedingt mitmachen will – und sei es nur, um informiert zu bleiben.

Köhler tritt zurück

Heute mittag hab ich über den Schreibtisch weg gehört, dass unser (Ex-)Bundespräsident Horst Köhler zurückgetreten ist. Von seinen Äusserungen hab ich zuerst bei Fefe gelesen, danach kamen ja noch einige Blogs. Dass Köhlers Rücktritt durch Blogs ausgelöst wurde, will mir noch nicht so recht einleuchten…

Und jetzt gibt es bei Fefe noch ein schönes Detail zur Sicherheitspolitik, nämlich einen Link auf diesen Artikel bei Telepolis von 2006:

Bereits 1975/76 benennt das militärpolitische “Weißbuch” die Verknappung von Erdöl
und anderen Rohstoffen als “sicherheitspolitische Bedrohung” der Bundesrepublik. CDU-Minister
Volker Rühe formuliert in seinen Verteidigungspolitischen Richtlinien (26.11.1992) als Auftrag
der Bundeswehr: “Aufrechterhaltung des freien Welthandels und des ungehinderten Zugangs zu Märkten
und Rohstoffen”. Deutschland gilt als “kontinentale Mittelmacht mit weltweiten Interessen”.</blockquote>

(via TP: Deutsche Kriege für das “nationale Interesse”?)

Mich persönlich stört der Rücktritt nicht, ich bedauere ihn nicht und ich freue mich auch nicht. Köhler hat auf mich wenig Eindruck hinterlassen und ich bin jetzt eher gespannt, wer neuer Präsident (oder -in) wird.

Ein neues Gadget: Fitbit

Nachdem Marc David auf Twitter wieder von seinem Fitbit gesprochen hat, habe ich mir die Webseite www.fitbit.com noch einmal genau angesehen und mich mit dem Produkt beschäftigt. Das Gadget bringt einige nützliche Funktionen:

  • Pedometer
  • Schlafanalyse
  • Kabellose Synchronisation
  • Ernährungstagebuch

Ein Ernährungstagebuch führe ich ja schon seit Jahren in der fddb und eine Schlafanalyse mache ich im Moment mit Sleep Cycle alarm clock auf meinem Iphone. (Das Wakemate ist im Moment wohl noch Vaporware…) Daher habe ich mich entschlossen, das Fitbit zu kaufen. 🙂 Das Gadget gibt es leider noch nicht ausserhalb der US, aber ich habe einen Händler mit annehmbaren Preis und guten Bewertungen bei ebay gefunden. Ich bin gespannt, wie lange eine Sendung aus den USA bis zu uns braucht – und wo ich sie dann aus dem Zoll fischen darf…

Die Technik

Die Basisstation übernimmt das Laden und die Synchronisation des Fitbit. Die Datenübertragung erfolgt kabellos, d.h. sobald man in Reichweite ist, werden alle 15min die Daten übertragen. Das funktioniert natürlich nur mit den Pedometerdaten (den zurückgelegten Schritten), nicht mit dem Ernährungstagebuch. Bis mein Fitbit hier ist, habe ich mit Footsteps ein Pedometer auf dem Iphone und werde damit die großen Strecken erfassen.

Die Webseite

www.fitbit.com ist zur Verwaltung der Daten zuständig. Ich nutze die Webseite schon und finde sie sehr übersichtlich und leicht zu bedienen. Natürlich ist sie in Englisch, also muss auch das Ernährungstagebuch in Englisch gepflegt werden. Aber es können auch eigene Produkte eingeben werden, komplett mit detaillierten Nährwertangaben.

Das angeschlossene Forum ist nicht sehr groß und etwas unübersichtlich. Aber die sozialen Funktionen sind sehr nett: Profile, Ranglisten, Vergleich mit Freunden – alles da. Neben den Lebensmitteln wird die Wasseraufnahme gepflegt. Ausserdem können zusätzlich zum Schrittzähler andere Aktivitäten angegeben werden. Lauftraining bzw Bodybuilding findet also auch seinen Platz in der Kalorienauswertung.

Fazit

Fitbit ist ein nettes Stück Technik und mit der Webseite erschlage ich 3 verschiedene Punkte, in denen ich meine Daten im Moment pflege. Im Forum las man bereits, dass auch eine API angeboten werden soll, mit der man auf seine Daten zugreifen kann. Ich hoffe, das wird bald Realität und man kann dann programmgesteuert seine Datensätze exportieren und manipulieren. Sobald das Gerät hier ist gibt es natürlich weitere Berichte. 😉

FadeIn mit JQuery

Ich habe gerade einen kleinen Schnippsel JQuery in mein Theme eingefügt, mit dem die Metainformationen zu den Artikeln erst bei Mausbewegungen sichtbar werden. Das ganze ist im Moment noch Spielerei, aber vielleicht blende ich demnächst noch ein paar Dinge aus. Die Google Startseite gefällt mir ja auch wieder besser, seit sie nur das Suchfeld anzeigen bis man die Maus bewegt.

Und JQuery muss ich sowieso mal üben. 🙂

Barfuss laufen

Gestern bin ich die erste Runde mit den Vibram Fivefingers gelaufen. Eine kleine Runde, nur rund 1km – aber das reicht erstmal. Sofort nach dem Start musste ich meine Lauftechnik anpassen, um noch stärker auf dem gesamten Fuss zu landen, damit der Stoss weiter gedämpft wird. Ein Laufschuh vergibt eben viel mehr als die dünne und flexible Sohle der Fivefingers. Nach ungefähr der Hälfte konnte ich bereits meine Schienbeine fühlen. Die fehlende Sohle unter dem Hacken macht die Verkürzung meiner Muskeln und Sehnen im Bein noch deutlicher (asiatische Kniebeuge anyone?).

Irgendwann hatte ich dann auch das Gefühl als würde sich ein Krampf in der rechten Wade zusammenziehen – das wäre dann mein erster Krampfüberhaupt. Jedenfalls an den ich mich erinnere… Ich habe die Runde aber gut überstanden. Heute Nachmittag folgt die zweite. Vielleicht etwas länger, aber ich will’s nichtübertreiben. Im Moment zieht und zwickt es sowieso an allen Gelenken. 🙁

Update Wenn man nicht vorher schweres Kreuzheben trainiert, läuft es sich auch in den Fivefingers gleich viel besser. Ich konnte direkt am nächsten Tag die Runde verlängern und ohne Beschwerden durchlaufen. 🙂

Einstieg in Brownfield-Projekte

Da ich mich gerade mitten in einem sog. Brownfield-Projekt befinde, d.h. einem Projekt mit hauptsächlich gewachsener Architektur, mit fehlender Testabdeckung, mit manuellem Build- und Deploymentprozess und mit hohem manuellen Test- und Änderungsaufwand, will ich hier meine Erfahrungen schildern und einen Weg aufzeigen, wie man in solche Projekte einsteigen kann. Auf heise developer gibt es gerade eine Artikelserie zum Thema Brownfield, die von den beiden Clean Code Initiatoren Stefan Lieser und Ralf Westphal verfasst wird. Und nachdem ich den Artikel gelesen habe, habe ich festgestellt, dass ich genau der dort beschriebenen Vorgehensweise folge. 🙂

Der Buildprozess

Der erste Schritt für mich war das Verstehen des Buildprozess. Ohne einen funktionieren Buildprozess hat man als Entwickler keine Möglichkeit, überhaupt einen Fehler in seinem Code festzustellen, der das fehlerfreie Übersetzen der Software verhindert. Als allererstes muss man also (nach dem Einrichten des VCS natürlich) die Software bauen – möglichst in einem einzigen Schritt. Ein Merkmal von Brownfield-Projekten ist aber gerade, dass der Buildprozess manuell, kompliziert und fehleranfällig ist. Es gilt also herauszufinden, wie der Ablauf aussieht, wo evtl. festverdrahtete Pfadnamen im Spiel sind, wo die Ergebnisse abgelegt werden und was in welchem Schritt weiterverwendet wird. Anschliessend habe ich angefangen, die weit verstreuten Verzeichnisse mit Ergebnissen in Form von JAR, WAR und EAR-Dateien zusammenzuführen und in einem Verzeichnis abzulegen, dass ich auch in meinem Eclipse-Workspace sehen konnte. So habe ich direkt nach dem Build das Ergebnis gesehen und konnte die Änderungen und neu erstellten Dateien mitverfolgen.

Testautomatisierung

Der zweite Schritt ist eigentlich kein Schritt, sondern ein Prozess. In Brownfield-Projekten sind automatisierte Tests so gut wie nicht vorhanden. Weder Unit- noch Integrationstests werden regelmässig und automatisiert ausgeführt. Daher sind Änderungen mit einem hohen Risiko verbunden und als Entwickler neige ich dazu,Änderungen so klein wie möglich zu halten und es ist immer eine latente Furcht mit Änderungen verbunden. Wer weiß schon so genau, was man alles kaputt macht. Der Code ist in den Jahren so weit verrottet, dass man keine Möglichkeit hat, alle Seiteneffekte und Auswirkungen der Änderung zuüberblicken. Also besteht der zweite Schritt in der stetigen Erstellung von automatisierten Tests. Vor jeder Änderung versuche ich Unit Tests zu schreiben, die eine Dokumentation des aktuellen Verhaltens sein sollen. Anschliessend kann ich Änderungen am Code vornehmen, und die unveränderte Funktion durch meine Testsüberprüfen. Leider ist es im Brownfield-Projekt sehr schwer, auf Unit-Ebene Tests zu schreiben, da es sehr viele innere Abhängigkeiten zwischen den Softwaremodulen gibt. Die Tests sind daher eher Integrationstests, aber durch intensives Mocking (mit meinem Lieblingsmockframework JMockIt) versuche ich die Abhängigkeiten so niedrig wie möglich zu halten. Das gelingt manchmal gut, manchmal schlecht. Es ist nicht immer möglich, gute Tests zu schreiben – aber es ist immer möglich, überhaupt Tests zu schreiben.

Automatisierter Build

Als nächsten Schritt nehme ich mir den automatisierten Build vor, der auch die Ausführung der automatisierten Tests enthält. Dazu muss der Buildprozess angepasst werden, in meinem Fall also einige neue Targets in die Ant-Skripte eingefügt werden. Das ganze werde ich erstmal auf meinem Rechner machen, aber früher oder später sollte der gesamte Build auf einem dedizierten Rechner ausgeführt werden. Es gibt bereits zu viele Umgebungsvariablen, zu viele Bibliotheken, die auf den Entwicklungsrechner installiert und eingerichtet werden müssen, damit der Build läuft. Egal, ob der Build auf einem (beliebigen) Entwicklerrechner oder auf einem eigenen Buildrechner erfolgt, er muss immer mit einem einzigen Klick zu starten sein. Alle manuellen Schritte müssen eliminiert werden, alle vor- oder nachbereitenden Tätigkeiten müssen automatisiert werden. Erst wenn jeder Mitarbeiter einen Build erstellen kann, ist schluss. Dann verliert der Vorgang seinen Schrecken und muss nicht immer vom selben „Buildbeauftragten“ ausgeführt werden.

Continuous Integration

Der nächste logische Schritt ist dann die Einführung von Continuous Integration, wahrscheinlich mit Hudson. Damit soll bei jederÄnderung im VCS ein Build ausgelöst werden, so dass auch die Notwendigkeit von „Build-Tagen“ entfällt. Ausserdem muss man nicht mehr einen Entwickler mit der Erstellung von Builds belästigen, wenn er eigentlich etwas besseres zu tun hätte… 😉 Und schliesslich gehört zur CI auch die Festlegung von Orten, wo die Ergebnisse erwartet werden. Jeder weiß dann, wo die letzte Version liegt. Und jeder kann sich dort bedienen.

Continuous Deployment

Das wäre die Krönung. Automatisches Deployment auf alle Umgebungen. Aber bis dahin ist der Weg noch so weit, dass ich mich erst später damit beschäftige.

Kunstraub in Paris

Unglaublich, das hört sich echt an wie im Film: Einbruch in das Museum für moderne Kunst in Paris.

  • 100 Millionen Euro erbeutet
  • Unbemerkt in das von 3 Wächtern bewachte Museum eingedrungen
  • Noch keine Informationen&uuml;ber Aufnahmen der Überwachungskameras

Ich stell mir da jetzt die Musik von Hudson Hawk und ein paar schwarz bestrumpfte Einbrechertypen vor, nicht die waffenschwingenden Irren, die’s wahrscheinlich waren…

Vollbildmodus in Google Chrome

Jeder gute Browser hat mittlerweile einen Vollbildmodus. Auch Google Chrome, mein aktueller Lieblingsbrowser. Drückt einfach F11 (funktioniert auch im Firefox und sogar im Internet Explorer) und schon verschwinden die ganzen überflüssigen Statusleisten, Lesezeichen, Menüs und sonstiger Schnickschnack.

Am meisten Spass macht der Vollbildmodus übrigens mit Instapaper. So wird man auch nicht durch Desktophintergründe oder andere Fenster im Hintergrund abgelenkt.

Tools zur Qualitätsanalyse

Weil ich sowieso gerade dabei bin, will ich hier auch noch eine kurze Liste mit meinen Lieblingstools zur Analyse von Codequalität posten. Das ganze zielt auf Java als Entwicklungssprache, da ich am meisten dort unterwegs bin. Ich setze diese Tools selbst gern und oft ein und sie können ohne Ausnahme auch in einer Continuous Integration (z.B. via Hudson) eingesetzt werden:

Welche Tools setzt ihr ein? Und mit welchem Ziel?

(Kleine Anmerkung: Die Beobachtung von Metriken wie Testabdeckung oder LOC macht eigentlich nur Sinn, wenn man historische Daten zur Auswertung speichert. Aber auch während der Entwicklung, z.B. bei Refaktoring kann man die Kenngrößen im Auge behalten. Tools wie FindBugs und Checkstyle sollten eigentlich immer mitlaufen.)