Quantified Self

Wer mich kennt, der weiß vielleicht, dass ich ein paar persönliche Daten mit diversen Gadgets, Tools und Tabellen tracke. Mein Gewicht kann ich z.B. fast 5 Jahre zurückverfolgen, meine Nahrungsaufnahme tracke ich seitdem auch. Ausserdem benutze ich seit ungefähr einem Jahr mein Fitbit, um meine täglichen Schritte zu zählen und seit 4 Wochen auch noch ein Wakemate, um meinen Schlaf zu analysieren. Und beim Training führe ich ein Trainingslog, in dem ich meine Übungen und die verwendeten Gewichte in den Sommer 2008 nachlesen kann.

Wieso mache ich das alles? Weil es Spass macht.

Hauptsächlich jedenfalls. Ausserdem glaube ich, dass man nur ändern kann, wenn man messen kann. Wenn ich also wissen will, ob ich mich viel oder wenig bewege, ob ich gut oder schlecht schlafe, ob ich viel oder wenig esse, dann muss ich es messen.

Im Prinzip brauch man dazu auch gar nicht die vielen kleinen Hilfsmittel und Dienste, man kann auch einfach ein gutes altes Notizbuch führen.

Trainingslog

Wenn man also seine persönlichen Aktivitäten misst und versucht, daraus Schlüsse zu ziehen, dann heißt das auf englisch quantified self. Mittlerweile gibt es dazu eine ganze Bewegung, hauptsächlich aber in den USA. Das ganze hat auch eine gewisse Tradition, denn schon vor 200 Jahren haben Privatpersonen versucht, aus ihren Beobachtungen Erkenntnisse zu ziehen.

Leider gibt es in Deutschland noch nicht viel Resonanz dazu. Die Gadgets tauchen auch erst in den USA auf und kommen erst langsam zu uns nach Deutschland. Bei Meetup gibt es ein paar Gruppen zu Quantified Self, aber in Deutschland wieder keine Interessierten.

Wenn ihr euch also auch trackt und versucht, aus euren Beobachtungen irgendwelche Schlüsse zu ziehen, dann schreibt mir doch einfach mal. Vielleicht gibt es ja doch noch ein paar Verrückte in Deutschland, die Tabellen und Notizbücher füllen… 😉

Samsung Galaxy S2 (I9100)

Irgendwann in den nächsten zwei Wochen kommt das Samsung Galaxy S2 (I9100) (Wikipedia) hier bei mir an. Ich konnte einfach nicht widerstehen und nachdem meine Freundin mit dem Iphone 3G nicht mehr so richtig zufrieden ist (und ich schon seit ein paar Tagen über ein Tablet bzw. ein schickes Smartphone nachgedacht hab), hab ich mir heute das SG2 geklickt.

Das Display soll ja ziemlich gut sein und es ist ein ganzes Stück größer als mein Nexus One. Die Hardware-Specs sind auch überragend, ein Dual Core Prozessor ist schon mit verbaut – und hoffentlich kommt auch ein Android 3.0 ROM für das SG2 raus, damit die Kerne auch verwendet werden. Darf auch gern ein Community-ROM sein, ich brauch nicht unbedingt eine offizielle Firmware des Herstellers.

Ein Grund für meine Entscheidung für das SG2 war auch die Einstellung Samsungs, die vor ein paar Tagen den Entwicklern von cyanogen ein SG2 zur Verfügung gestellt haben:

Samsung Galaxy S2 für Cyanogen

Jetzt bin ich gespannt, wann ich die Tracking ID bekomme – und wie lange die Lieferung dann dauert. 🙂

Wie geht man mit Legacy Code um?

Beim morgendlichen Blättern durch programmers.stackexchange.com hab ich zur Frage „How do you overcome your own coding biases when handed legacy code?“ folgende Antwort gefunden:

Pick your battles. Know the difference between „I wouldn’t write it this way“ and „this creates a serious maintainence or support challenge“ (link)

Mehr gibt’s dazu eigentlich nicht zu sagen. 😉

Unmarshal a CSV file with Apache Camel

Today I tried to work with Apache Camel for the first time. I’m currently reading the book Camel in Action and want to try the example with data that has a meaning to me. I decided to follow the examples of Chapter 3: Transforming data with Camel and try to read rows from a CSV file and convert them with Bindy into annotated POJOs.

But, oh boy, is the documentation lacking. And the book is not helping me at all at this point. The examples there look easy and when you’re reading the book you can follow the thoughts. But when I actually tried to write my first unit test without pasting the whole examples into your project, I got lost. The documentation of Bindy is very confusing if you only start writing tests for Camel. And the examples tests they show in the docs are so complicated I couldn’t strip them down to a minimal version that would just read the CSV and unmarshal the rows into POJOs.


And what do you do if you can’t figure out how to do stuff? You post a question on StackOverflow.

And right after I posted that question, I got the test running. Isn’t it always like that? As soon as you ask for help, you find the solution to your problem. As if I’m afraid to let others see how much I suck. Anyway, here is a working junit test that will unmarshal a CSV into POJOs with the use of an annotated java bean:

CsvBean.java

CsvToBeanWithBindyTest.java

You can get the complete example in this gist.

The confusing thing is that I don’t get a list of CsvBeans, but a list of Maps that have an entry with the key set to the name of my class and the value set to the actual unmarshalled CsvBean. That was a surprise, and I don’t know yet what that means. I think there’s more to the CSV than I can see now, maybe having multiple bean classes unmarshalled from the CSV when there is a different number of columns in the rows.

HTH.

Lang gesucht und doch gefunden

In den letzten 3 oder 4 Tagen war ich auf der Suche nach einem verzwickten Bug. Eine Funktion ging von heute auf morgen kaputt – so sah es jedenfalls aus. Was monatelang funktioniert hat und eine zentrale Funktion der Software ist, an der ich seit über 12 Monaten arbeite, ist kaputt gegangen.

Natürlich nicht nach einem erkennbaren Muster, sondern anscheinend völlig willkürlich. Und selbstverständlich gab es keine offensichtlichen Fehlermeldungen in den Logs oder Crashes. Die Software hat diese Funktion für einige Nutzer einfach nicht ausgeführt.

Heute mittag hab ich dann aus Verzweiflung im Zuge meiner gründlichen Analyse meine Suche auf weitere Bereiche ausgedehnt und tatsächlich eine Änderung ausserhalb meiner Software gefunden, die eine Auswirkung haben konnte. Ich habe ungefähr 1 Minute gebraucht, um die Stelle im Code eines anderen zu finden, die bei mir einen Fehler ausgelöst hatte.

Das es diese Abhängigkeit gibt, war mir nicht mehr bewußt. Sie war auch dem Entwickler nicht bewußt, der die Änderung gemacht hat. Hinterher war allen klar, daß diese Änderung natürlich Auswirkungen auf andere haben kann. Aber hinterher ist man ja immer klüger. Und die Korrektur hat ungefähr 2 Minuten gedauert…

Was ich aus dieser Episode schließe: wenn man schon Abhängigkeiten zu anderen hat, muss man diese so deutlich wie möglich markieren. Und man muss sie so klein wie möglich halten.

Und morgen früh schreibe ich als erstes einige Tests, mit denen ich solche Probleme beim nächsten Mal ausreichend dokumentiere. Ich muss mir also einen Weg einfallen lassen, bei einer Änderung in der Zukunft meine Tests so fehlschlagen zu lassen, dass ein anderer Entwickler daraus genug Informationen bekommt, um die Abhängigkeit zu finden und den Fehler sofort zu erkennen.

Ja, und ich werde daran arbeiten, die Abhängigkeit aufzulösen. Aber manchmal muss man mit solchen Sachen leben.

Jekyll auf Amazon CloudFront hosten

Heute nachmittag hab ich mal ausprobiert, wie man den eigenen Jekyll-Blog auf einem Amazon S3-Bucket hosten und mit Amazon CloudFront weltweit verteilen kann. Mein erster Eindruck: fast so einfach wie Schuhe anziehen.

Einrichten des S3-Buckets

Als erstes hab ich mich auf der Amazon Management Console eingeloggt und ein neues Bucket angelegt:

aws-s3-bucket-fuer-jekyll

Jetzt muss ich noch mit s3cmd mein AWS-Zugang konfigurieren. Dazu rufe ich folgendes Kommando auf und folge den Hinweisen auf dem Bildschirm:

s3cmd --configure

Im Prinzip muss man da nur seine Zugangsdaten zum Amazon Webservice angeben.

Hochladen der statischen Inhalte

Ich habe lokal meine statische Seite mit Jekyll generiert. Danach habe ich im Verzeichnis _site alle Dateien, die ich für die Seite brauche. Die kann ich jetzt auf mein vorher angelegtes Amazon S3-Bucket hochladen:

s3cmd sync --delete-removed _site/ s3://{bucketname}

Jetzt kann ich bereits meinen Blog auf dem S3-Bucket aufrufen: http://blog.kopis.de.s3-website-eu-west-1.amazonaws.com/

Einrichten von Amazon CloudFront

Als erstes muss ich eine Distribution anlegen, wieder in der Amazon Management Console:

aws-cloudfront-fuer-jekyll

Beim Einrichten wähle ich den Type download und mein S3-Bucket aus. Jetzt kann ich wieder meinen Blog aufrufen, diesmal auf dem CloudFront Content Delivery Network (CDN): http://d3ln3qjv5hffnc.cloudfront.net/

Einstellen der CNAMEs

Damit ich meine Daten unter eine besseren Domain aufrufen kann, muss ich noch einige Einstellungen im Domain Name Server meiner Domain kopis.de vornehmen. Ich möchte einen CNAME einrichten und die Daten in der CloudFront anschliessend über blog2.kopis.de aufrufen.

Das Einrichten eines CNAME Records ist aber so abhängig vom Hoster der Domain, dass ich euch nicht damit langweilen möchte. Als letzter Schritt bleibt dann eigentlich nur noch der Aufruf des Blogs bzw. das Setzen von Links auf die statischen Inhalte in der CloudFront.

Ich hoste dann meinen Blog unter blog.kopis.de, während die meisten Inhalte aber von blog2.kopis.de kommen. Das ganze könnt ihr auch für einen dynamischen Blog machen, der z.B. nur statische Inhalte wie CSS, Javascript und Bilder aus der CloudFront lädt. Da mein Blog mit Jekyll nur noch aus statischen Inhalten besteht, kann ich alle Inhalte aus der CloudFront bedienen. Ich brauche dann gar keinen eigenen Webspace mehr und könnte mein Hostingpaket auf die reine Domain abspecken.

Github mit Proxy unter Windows nutzen

Falls ihr ein Github-Repository per HTTPS unter Windows clonen wollt und dazu einen Proxy nutzen müsst, dann hilft euch vielleicht folgender Tipp:

git config --global --add http.sslverify false
export http_proxy=http://euer.proxy:1234
export https_proxy=http://euer.proxy:1234
git clone https://euer.host/repo.git

Ohne die Variable https_proxy war bei mir kein clonen möglich, ausserdem bekam ich einen Fehler bei der Validierung des Zertifikats – das wird mit dem Config-Eintrag in der ersten Zeile ignoriert.

Umzug zu Github & Jekyll

Mein Blog liegt jetzt bei Github, ich verabschiede mich also doch von WordPress. Das liegt nicht unbedingt an WordPress, sondern eher an meiner Vorliebe für statische HTML-Seiten. 😉

Die Kommentare sind auch wieder da, aber es könnten noch ein paar andere Fehler im Blog versteckt sein. Also, Augen offen halten

Evil Apple

Wer noch Zweifel daran hat, dass Apple wirklich böse ist:

The leading computer company plans to build a system that will sense when people are
trying to video live events – and turn off their cameras.

Gut, Quelle ist The Sun, aber trotzdem: technisch ist das gar kein Problem, softwareseitig erst recht nicht. Und Apple hat schon in der Vergangenheit gezeigt, dass sie sich einen Dreck um die Nutzer ihrer Technik scheren und keine Rücksicht auf Eigentumsansprüche nehmen. Lest dazu auch gleich noch The “walled garden” becomes a prison for reality.

Wer ein Iphone gekauft hat, kauft bei Apple eben nur ein Nutzungsrecht. Die Hardware und die Software soll gefälligst unter der Kontrolle von Apple bleiben. Natürlich nur zum Besten des Nutzers. Damit Apple eine tolle Erfahrung bieten kann.

Und dann wird eben fröhlich die Position getrackt, Anwendungen gekillt, Downgrades verhindert… und ich behaupte immer noch, dass dieser Trend auch auf die Macs übergreifen wird. Der erste Schritt ist mit dem Appstore schon getan.

Greasemonky-Skript: Externe Links in Tab öffnen

Ich mache mittlerweile eigentlich alle Links, die nicht auf die Domain zeigen, auf der ich eh gerade bin, in einem Tab auf. Und weil das ein Tastendruck zuviel für einen faulen Typen wie mich ist, hab ich mich mal nach einem Greasemonkey-Skript umgesehen – und tada:

open external links in background tab.

Das Skript könnt ihr auch einfach im Google Chrome nutzen, der versteht nämlich Greasemonkey.