Zustandsforschung

Mit offenen Augen durch die Welt

Meine Leseliste 2013

Wie jedes Jahr habe ich auch letztes Jahr über gelesene Bücher buch geführt:

  • Gormenghast von Mervyn Peake:
    Nachdem der erste Teil “Titus Groan” mehr so dazu gedient hat, die beteiligten Figuren und das Setting einzuführen, wandelt sich die Story in diesem Buch in eine spannende Geschichte über einerseits das Erwachenwerden von Titus und andererseits der Kampf gegen einen Emporkömmling, der versucht die Hierarchie in Gormenghast zu unterwandern.
  • Titus Alone von Mervyn Peake:
    Im letzten Teil der Gromenghast-Trilogie nimmt die Geschichte eine eher überraschende Wendung – allerdings muss ich sagen, dass ich hier die düstere Atmosphäre der beiden anderen Bücher vermisst habe. Auch finde ich die Charaktere nicht mehr so stark gezeichnet wie vorher.
  • Nein aus Liebe von Jesper Juul:
    Ein Plädoyer für klare Ansagen gegenüber den Kindern und dem Partner. Weicht nicht wirklich von der Art ab, wie wir versuchen in meiner Familie miteinander zu reden.
  • Understanding Exposure von Bryan Peterson:
    Für Anfänger verständlich erklärt, was es mit diesem ganzen Belichtungskrams beim Fotografieren mit einer DSLR auf sich hat und welche Einstellungen wichtig sind und welche nicht. Außerdem hat’s sehr viele Beispielbilder, auf denen die Konzepte nochmal sichtbar gemacht werden.
  • You Can Buy Happiness (and It’s Cheap) von Tammy Strobel:
    Was im ersten Moment nach billiger Lebensberatung klingt ist tatsächlich der Bericht von Tammy Strobel über ihren eigenen Weg vom durchschnittlich überverschuldeten amerikanischen Konsumisten zu ihrem momentanen minimalistischen Leben.
  • Neverwhere von Neil Gaiman:
    Fantasy-Kram: Richard Mayhew stellt fest, dass es außer dem London in dem er bisher gelebt hat, noch ein “London Below” gibt, wo es ihn im Verlauf des Romans dann hin verschlägt. Klingt jetzt irgendwie langweiliger als es ist – ich kann außer dem Roman noch das zugehörige BBC-Hörspiel von Anfang des Jahre empfehlen.
  • Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman von Dave Hoover und Adewale Oshineye:
    Fällt ein bisschen in die Kategorie Karriere- bzw. Weiterbildungsratgeber für Softwareentwickler. Hat allerhand nützliche Ratschläge wie man mit welchen Situationen im Entwicklerleben umgehen kann/sollte – das ist so ein Buch, wo man immer mal wieder reinschauen kann.
  • The Lord of the Rings von J.R.R. Tolkien:
    Ich finde, so einmal alle 10 Jahre sollte man den Herrn der Ringe lesen. Fühlt sich ein bisschen an, wie alte Freunde treffen oder so…
  • Die Brautprinzessin von William Goldman:
    Völlig alberne aber sehr geniale Fantasy-Story. Ich war vor kurzem schwer begeistert von der Verfilmung und als ich dann das Buch in unserer Bücherei entdeckt habe, musste ich einfach zugreifen.
  • Just a Geek von Wil Wheaton:
    Der großartige Wil Wheaton beschreibt in diesem Buch seinen Weg weg von “prove to everyone that quitting Star Trek wasn’t a mistake”.
  • Little Brother von Cory Doctorow:
    Eigentlich ein Science-Fiction-Jugendbuch darüber was es bedeutet in einem Überwachungsstaat zu leben – bedauerlicherweise seit seiner Veröffentlichung im Jahr 2008 in vielen Bereichen von der Realität bereits überholt. Gibt’s wie fast alle Bücher von Cory Doctorow auch als kostenloses eBook.
  • Machine of Death:
    Eine Sammlung von Stories verschiedener Autoren, die sich alle um ein makaberes Gedankenexperiment drehen: Was wäre, wenn es eine Maschine gäbe, die vorhersagen kann woran man sterben wird. Interessant wird’s vor allem dadurch, dass man zwar weiß woran, aber nicht wann man stirbt und die Maschine auch einen Sinn für Ironie hat.
  • Inferno von Dan Brown:
    Spannend – aber nicht so spannend wie der “The Lost Symbol”. Fast ein bisschen Schade, dass der Roman verfilmt wird und der andere nicht.
  • Tarzan of the Apes von Edgar Rice Burroughs:
    Der Original-Tarzan-Roman. Drei Dinge sind mir besonders aufgefallen: Ganz schön brutal, ganz schön rassistisch und ein ganz schön gelungenes Ende.
  • Spin von Robert Charles Wilson:
    Hab’ ich eigentlich eher zufällig gelesen – ist aber genau das wofür gute Science-Fiction steht: Zwischenmenschliche Dramen im Vordergrund und das Science-Fiction-Setting nur als Rahmenhandlung.
  • Don’t Make Me Think! von Steve Krug:
    Ein Standardwerk in Sachen Usability. Mittlerweile gibt es die 3rd Edition – ich hab’ die 2nd Edition gelesen und obwohl die ein paar Jahre Alt ist, ist so ziemlich alles was dort beschrieben wird noch topaktuell. Unbedingte Leseempfehlung für alle, die sich beruflich mit dem Thema beschäftigen.
  • A Game of Thrones von George R. R. Martin:
    Ich kann mich gar nicht entscheiden, ob ich die Fernsehserie besser finde oder das Buch. Auf jeden Fall ist beides ganz großartige Fantasy für Erwachsene (und nicht so weichgespült wie Herr der Ringe ;-) ).

Außerdem war mal wieder viel von Lovecraft dabei – ich habe ein kostenloses eBook entdeckt (Free Complete Works of H.P. Lovecraft for Nook and Kindle), das die meisten seiner Werke enthält und da ich mir diese Jahr einen Kindle gegönnt habe, hat das ganz gut gepasst.

Raspberry Pi Audioplayer: Installation und Konfiguration

Dieser Artikel ist der zweite Artikel in einer Artikelserie, die sich mit dem Bau eines Audioplayers auf Basis des Raspberry Pi beschäftigt. Bisher habe ich folgende Artikel zu diesem Thema veröffentlicht:

Hier geht es nun eben um Konfiguration und Problembehebung – zum Teil wird’s da ziemlich technisch. Für einen einfachen Überblich empfehle ich den o.g. ersten Artikel der Serie.

Installation

Als Betriebssystem verwende ich Raspbmc, das eine speziell für den Raspberry Pi angepasste Version von XBMC mitbringt. Raspbmc bringt einen Installer mit, so dass man neben einem Rechner von dem aus man die Installation durchführen kann theoretisch nix anderes braucht.

Bei meinem Linux-Notebook allerdings wollte sich die SD-Karte nicht so richtig mounten lassen (so dass der Installer keine Liste verfügbarer Devices angezeigt hat). Mit “sudo fdisk -l” kann man sich aber anzeigen lassen, wo das Ding liegt und wie es heißt, um dann den richtigen Gerätenamen rauszufinden (bei mir “mmcblk1″).

Dann wird alles was an Hardware da ist zusammengesteckt, Netzwerk- und HDMI-Kabel dran (fürs Setup hab’ ich den Pi an den Fernseher angeschlossen) und direkt nach dem Einstecken des Stromsteckers beginnt der Pi mit der Installation von Raspbmc. Der rödelt jetzt einige Minuten mit dem Download und der Installation der Software rum und kurze Zeit und einige Reboots später wird man vom XBMC-Startbildschirm begrüßt.

Die erste Hürde war nun, dass die Tastatur nicht funktioniert hat. Hier war die Lösung sich per SSH einzuloggen (Benutzername ist “pi” und Passwort “raspberry”) und dann die Schritte die dort angeboten werden durchzuführen (Time-Zone-Auswahl und Tastaturlayout). Nach einem weiteren Reboot funktionierte dann auch die Tastatur und es konnte weiter gehen.

Basiskonfiguration

In XBMC sollte man nun neben der Sprache noch einige weitere Einstellungen tätigen:

Settings -> Music -> Playback -> Visualization: None

Da der Pi ja ohne Monitor betrieben wird, brauch man die CPU mit einer Visualization nicht zu belasten.

Settings -> Services -> Webserver: Allow control of XBMC via HTTP

Erlaubt die Steuerung des Pi durch die iPad-Apps. Zusätzlich sollte man dem Pi im Router eine feste IP-Adresse zuweisen. Damit das dann auch greift, muss man dann wieder bei Programs -> Raspbmc Settings -> Network ConfigurationUse DHCP” abschalten und die im Router eingetragene IP-Adresse eintragen, “Update Now” aktivieren und dann auf “OK“.

Settings -> Services -> Airplay: Allow XBMC to receive Airplay content

Hier gab’s bei mir allerdings das Problem, dass das iPad zwar erstmal den Airplay-Button angeboten hat, nach ein paar Minuten aber die Verbindung verlor und dann auch keinen Airplay-Button mehr angezeigt hat. Was schnell klar war, war dass es hier wohl ein Problem mit meinem Router gab – was mich allerdings länger gebraucht hat war die Lösung zu finden: Mein Router hat einen “Wireless Enhance Mode“, der das Problem verursacht hat – nachdem ich den abgeschaltet hatte ging’s dann.

Settings -> Appearance -> Navigation sounds: Off oder Skin default

Das ist ein bisschen merkwürdig bei mir: Eigentlich man eh keine Navigation Sounds, wenn man das Ding ohne Fernseher betreibt. Aaaaaaaber: Bei mir fängt die Musik übel an zu Rauschen, wenn ich hier auf “Off” stelle. Als Workaround habe ich den Quartz Skin installiert, und dann die Navigation Sounds wieder auf “Skin default” gestellt.

USB-Audio

Da meine Stereoanlage noch aus der Zeit stammt bevor es HDMI gab, muss ich den Sound per USB-Soundkarte ausgeben (und dann via Cinch-Kabel in den Verstärker leiten). Das funktioniert mit Raspbmc 12.1 folgendermaßen (siehe auch Raspmc: Probleme mit Sound und Soundblaster play USB):

Via SSH ALSA installieren:

sudo apt-get install alsa

Dann die Zeile options snd-usb-audio index=-2 in /etc/modprobe.d/alsa-base.conf auskommentieren und anschließend in den “Raspbmc Settings” in XBMC die Audio Engine aktivieren. Danach muss man dann neu booten.

Sinnvoll ist es offenbar noch bei den “Raspbmc Settings” unter “System Configuration” die Option “keep Raspbmc updated” abzustellen: Bei mir hat ein automatisches Update nämlich den Sound abgeschaltet (in der neuen Version war offenbar kein PulseAudio drin) und ich musste auf einen Nightly Build gehen (bzw. auf Version 12.1 zurück): Nightly Build Configuration -> Install XBMC Nightly

Musik hinzufügen

Bevor man Musik zum Pi hinzufügt, sollte man noch bei Settings -> Music -> LibraryDownload additional information during updates” anhaken, damit beim Scannen der Musikbibliothek gleich auch Cover-Art und Künstlerbilder von XBMC runtergeladen werden. Wer mag kann noch bei Settings -> Music -> LibraryInclude artists who appear only on compilations” weggehaken.

Für mich persönlich ist die Last.fm-Integration ein wichtiges Feature: Bei Settings -> Music -> Song submission lässt sich ganz einfach “Submit songs to Last.fm” aktivieren, Username und Passwort eintragen und schon kann gescrobbelt werden :-)

Dann hab’ ich per FTP meine Musik auf den Pi rüberkopiert und entsprechend der XBMC-Anleitung hinzugefügt. Das dauert einen Moment wegen dem gerade erwähnten Download von Artist- und Cover-Art.

Beim ersten Versuch hat der Album-Art-Download wohl zwischendurch irgendwo abgebrochen. Also hab ich bei den Settings -> Add-ons mal alle Quellen aktiviert (v.a. auch Last.fm) und dann in der “Music -> Library -> Artists” im Kontextmenü (”c”) ausgewählt “Query info for all artists” (bzw. bei “Music -> Library -> Albums” dann “Query info for all albums“). Danach hatte ich dann für so dreiviertel meiner Musiksammlung korrekte Cover-Art. Wie man für den Rest noch die Cover-Art hinzufügen kann, beschreibe ich dann in einem anderen Artikel.

Log-File-Troubleshooting

Ein besonderes Problem hatte ich noch mit den Log-Files. Das /var/log/syslog hat sich mit folgender Nachricht gefüllt:

May 11 07:12:37 raspbmc kernel: delay: estimated 0, actual 89

Und zwar mehrmals pro Sekunde. Da Raspbmc dem Log-Verzeichnis nur 10 MB einer RAM-Disk einräumt war das Ruckzuck voll und ich konnte nicht sehen, was so an wirklich wichtigen Meldungen ins Log geschrieben wurde.

Also hab’ ich mich im Raspbmc-Forum erkundigt und folgende Lösung bzw. Workaround eingebaut:

In /etc/rsyslog.conf kann folgende Rule eingebaut werden, um die Ausgabe der o.g. Log-Meldung einfach zu unterdrücken (ist zwar dann quasi noch da, wird aber nicht mehr ins Log geschrieben):

:msg,contains,"delay: estimated 0" ~

Schlusswort

Wie man hier lesen kann, ist die Konfiguration nicht so ganz trivial und man stößt immer mal wieder auf Probleme, die man ohne ein paar Linux-Skills nicht lösen kann. Wenn man die aber hat, dann kommt man nicht zuletzt wegen der extrem guten und hilfsbereiten Community eigentlich immer zu einer Lösung.

Raspberry Pi Audioplayer: Hardware und Features

Dieser Artikel ist der erste Artikel in einer Artikelserie, die sich mit dem Bau eines Audioplayers auf Basis des Raspberry Pi beschäftigt. Bisher habe ich folgende Artikel zu diesem Thema veröffentlicht:

Nachdem mein mittlerweile mehr als 6 Jahre alter iPod so langsam seinen Geist aufgibt, habe ich beschlossen, mich nach einer neuen Lösung in Sachen Musik umzuschauen.

Das neu anzuschaffende Gerät sollte natürlich ein bisschen mehr können als die “iPod-mit-Kabel-an-Stereoanlage”-Lösung. Die hat nämlich unter anderem den Haken, dass man bei Neuzugängen in der mp3-Sammlung erstmal den iPod wieder an den Computer anschließen muss, um das Zeug rüberzuschaufeln. Außerdem hätte ich gerne die Möglichkeit gehabt, Musik vom iPad via Airplay an die Stereoanlage zu schicken (und nicht mit einer “mach-das-Kabel-am-iPod-ab-und-an-das-iPad-dran”-Lösung). Und natürlich muss ich bei all den kabelgebundenen Lösungen im Moment immer erst von der Couch aufstehen, wenn ich ein anderes Album hören möchte…

Klar, ich hätte auch irgendwas fertiges kaufen können, was das alles schon kann – aber abgesehen davon, dass das unter Umständen auch gerne mal relativ teuer werden kann: Wo bleibt denn da der Spaß? Also habe ich mich entschieden, wieder mal was zu basteln :-)

Hardware

Raspberry Pi Model B

Ausgehend von den beiden Lifehacker-Artikeln “Turn a Raspberry Pi Into an AirPlay Receiver for Streaming Music in Your Living Room” und “Turn a Raspberry Pi Into an XBMC Media Center in Under 30 Minutes” und ein bisschen Internet-Recherche hab’ ich folgende Hardware bestellt:

  • Raspberry Pi Model B:
    Das Herzstück des Gerätes – Für ca. 40 € bekommt man einen vollständigen Computer im Miniformat mit 512 MB RAM und 700 MHz-Prozessor.
  • Hübsches Gehäuse (PCSL Brand – Case for Raspberry Pi):
    Ganz ohne Gehäuse möchte ich das Ding nun doch nicht rumstehen haben – allerdings ist jetzt der Pi fast zu hübsch zum verstecken (was ich eigentlich nämlich machen möchte).
  • 64 GB SD-Karte (SanDisk Extreme SDXC 64GB Class 10):
    Meine Musiksammlung ist nicht so übermäßig groß (ca. 40 GB) und da Stromverbrauch offenbar für den Pi ein Problem werden kann, hab’ ich erstmal auf eine Festplatte verzichtet.
  • Netzteil für den Pi (mumbi Netzteil Garmin nüvi 3790 T):
    Muss mindestens 1000 mA bei 5V liefern – die meisten Handy- bzw. Navi-Ladegeräte mit Micro-USB-Anschluss können das.
  • USB-Soundkarte (Creative Soundblaster Play):
    Der Pi hat zwar einen analogen Soundausgang auf der Platine, aber nach allem was ich so gelesen habe ist da die Soundqualität eher so mittelmäßig – und da meine Stereoanlage keinen HDMI-Eingang hat, muss ich eben auf eine USB-Soundkarte zurückgreifen.
  • Netzwerkkabel:
    Klar – irgendwie muss Internet rein in das Ding. Könnte man auch mit ‘nem USB-WLAN-Dingens machen, aber so isses einfacher und billiger – zumal der Pi in unmittelbarer Nähe meines Routers steht.
  • USB-Tastatur und Maus:
    Braucht man nur für die initiale Einrichtung des Systems – der Rest lässt sich über die XBMC-Remote-App oder den XBMC-Commander steuern.
  • HDMI-Kabel:
    Brauche ich auch nur für “Wartungszwecke” – wenn ich irgendwas im XBMC einzustellen habe, was nicht per SSH geht.
  • iPad oder iPhone:
    Damit wird das ganze gesteuert (entsprechende Apps gäbe es aber auch für Android-Geräte wer das lieber mag…)

Sinnvoll ist dabei, dass man jeweils mal auf der “Verified Periphals“-Seite nachschaut, ob die ausgewählte Hardware-Komponente auch mit dem Raspberry Pi zusammenarbeitet.

Features

Nach erfolgreichem Zusammenbau und Konfiguration (was ich in einem Folgeartikel noch genauer beschreiben werde) kann ich jetzt

  • meine Sammlung an MP3-Files abspielen,
  • Musik via AirPlay an den Pi streamen (für Webradio oder Spotify oder so),
  • das alles bequem per iPad von der Couch aus steuern,
  • weiterhin meinen betagten aber guten Stereoanlagen-Receiver dafür benutzen und
  • außerdem jegliche Musik die ich damit höre scrobbeln (hat also ‘ne Last.fm-Integration).

Womit ich immer noch nicht so ganz glücklich bin ist das Übertragen von Musik: Das lässt sich zwar jetzt um einiges bequemer als vorher per FTP erledigen, aber mir wäre ja am liebsten eine vollautomatische Aktualisierung bei Änderungen in meiner MP3-Bibliothek. Falls irgendjemand mal Dropbox auf dem Raspberry Pi zum Laufen bringt, wäre das Thema zusammen mit dem “XBMC Library Auto Update”-Addon aber auch erledigt.

Insgesamt muss ich sagen für die ca. 150 – 160 € an Kosten bin ich mit dem Ergebnis sehr zufrieden. Ich habe auch nochmal 2,69 € in die XBMC-Commander-App investiert (kann ungefähr das gleiche wie die kostenlose Standard-App XBMC Remote – sieht aber deutlich hübscher aus). Damit sieht die Bedienung meines Raspberry Pi Audioplayers auf dem iPad folgendermaßen aus (die ganzen Künstlerbildchen und Coverart läd XBMC weitgehend selbständig runter):

XBMC-Commander (Lenny Kravitz ausgewählt)

“Irgendwas mit Menschen”

Ich vermute, wenn ich damals bei der Berufsberatung beim Arbeitsamt gesagt hätte, ich will “irgendwas mit Menschen” machen (statt “ich mag Mathe – was soll ich studieren”), hätte man mir nicht zum Informatikstudium geraten. Auch wer sich heutzutage für ein Studium oder einen Beruf entscheidet und gerne “irgendwas mit Menschen” machen möchte denkt vermutlich nicht gerade an Softwareentwicklung. Aber meine Erfahrung nach mittlerweile fast einem Jahrzehnt als Entwickler ist, dass die Interaktion mit Menschen – neben dem Programmieren – genau das ist, worauf es dabei ankommt.

Dabei meine ich nicht, dass man es auf Stackoverflow oder via Twitter mit anderen Menschen zu tun hat. Ich meine auch nicht das Gespräch an der Kaffeemaschine oder das Meeting mit dem Chef. Sondern tatsächlich Arbeit mit Menschen in Person von Angesicht zu Angesicht – direkte Kommunikation also, mit deren Qualität auch die Qualität des Arbeitsergebnisses steht und fällt.

“Wie kann das sein, wenn Entwickler doch hauptsächlich Code schreiben”, mag sich der ein oder andere jetzt fragen. Aber wer denkt, dass Softwareentwicklung sich nur auf Schreiben von Code beschränkt, hat da etwas grundsätzliches nicht verstanden. Natürlich schreiben Softwareentwickler auch Code – aber gerade im professionellen Umfeld tun sie das nur in den allerseltensten Fällen allein und im Reinraum.

Denn wenn mit Softwareentwicklung Geld verdient werden soll, ist es normalerweise nicht der Entwickler, der sich ausdenkt, was er als nächstes Entwickeln soll, sondern der Auftraggeber – sei es der Fachbereich in der eigenen Firma oder beim Kunden. Klar – ein gewisser Teil (je nachdem ob man eher agil oder eher wasserfallig unterwegs ist) ist in einer Art Spezifikation verschriftlicht. Oft ist es aber so, dass derjenige, der die Spezifikation schreibt, eine andere (domänenspezifische) Sprache spricht als der Entwickler. Das bedeutet, dass Unklarheiten und Missverständnisse normal sind, wenn man nur mit dem Dokument arbeitet. Hier ist es dann extrem wichtig, die Anforderungen direkt mit demjenigen zu diskutieren, der sie gestellt hat. Und genau hier kommt es darauf an, so kommunizieren zu können, dass die beiden Welten “Fachbereich” und “Entwicklung” einander auch verstehen. Scrum versucht diesem Umstand Rechnung zu tragen durch die Rolle des “Product Owner”, der viel unmittelbarer in den Entwicklungsprozess eingebunden ist. Beim Extreme Programming wird der “Onsite Customer” gefordert, um das Projekt zum erfolgreichen Abschluss bringen zu können.

Üblicherweise ist es dann ein Team das die Anforderungen umsetzt, da die Anforderungen meist zu umfangreich sind um von einer Person abgearbeitet werden zu können. Da gibt es dann außer den Entwicklern noch Tester, Projektleiter, Scum Master und Product Owner, manchmal auch Designer und Konzepter. Hier hat man es mit allen Beteiligten mehr oder weniger zu tun. Der Projektleiter muss in der Lage sein zu verstehen, wo das Projekt steht und der Entwickler muss ihm vermitteln können, warum “Kann man schon was sehen?” manchmal eine ziemlich dumme Frage ist. Entwickler und Tester können gemeinsam vor dem gleichen Bildschirm sitzend viel schneller ein komplexe Fehlerreproduktion durchführen als über ein Ticket-System. Der Scrum Master muss das Problem verstehen, das den Entwickler am Weiterarbeiten hindert, bevor er sich an dessen Beseitigung machen kann. Design und Konzept sollten eng mit der Entwicklung zusammenarbeiten, um frühzeitig die Realisierbarkeit der Entwürfe prüfen zu können.

Das alles geht natürlich umso effizienter, je kürzer die Kommunikationswege sind und natürlich auch je besser die Beteiligten in der Lage sind, miteinander zu kommunizieren. Und natürlich müssen sich auch die Entwickler untereinander austauschen – zum KnowHow-Aufbau, wie Anforderungen umgesetzt werden sollen, wo es sowas ähnliches im System schon gibt oder beim Pair Programming.

Ich kenne fast kein Projekt, in dem nicht Pair Programming zumindest punktuell nutzbringend eingesetzt werden konnte. Pair Programming bedeutet, dass tatsächlich zwei Entwickler gemeinsam am gleichen Bildschirm eine Anforderung umsetzen oder ein Problem lösen. Das heißt bei dieser Art der Zusammenarbeit hat man es nicht nur ab und zu zur Abstimmung mit einem anderen Menschen zu tun, sondern man sitzt im Zweifelsfalle den ganzen Tag gemeinsam vor dem Rechner und diskutiert Lösungen, Vorgehensweisen und Probleme. Vorzugsweise nicht immer mit der gleichen Person sondern möglichst oft mit unterschiedlichen Paaren. Für meine Begriffe ist das die Königsdisziplin in Sachen “irgendwas mit Menschen”.

Das sind zwar noch längst nicht alle Aspekte, wo man bei der Softwareentwicklung “irgendwas mit Menschen” macht, aber das soll mal genügen, um hier anhand von ein paar Beispielen verdeutlichen, dass das Klischee vom “Kellerentwickler”, der alleine vor sich hinprogrammiert einen völlig falschen Hinweis darauf gibt, welcher Typ Mensch als Entwickler geeignet sein könnte – und dass der Umgang mit Menschen ein zentraler und extrem wichtiger Bestandteil der professionellen Softwareentwicklung ist.

Gitshots für Windows

Vor ein paar Monaten habe ich bei einem Kollegen ‘gitshots‘ im Einsatz gesehen. Das macht immer dann einen Schreenshot, wenn man ein git commit ausführt. Allerdings ist die Anleitung wie das geht eher so für die Mac-Welt gedacht. Das nutzt mir mit meinem Windows-Notebook natürlich nicht so viel.

Aber weil das so dermaßen cool ist, habe ich mich auf die Suche nach einer Alternative gemacht, und das Tool “CommandCam” gefunden. Das tut nix anderes als beim Aufruf mit der Webcam ein Foto machen und das als Datei ablegen. Damit und einem Git Post-Commit-Hook ließ sich das dann relativ einfach umsetzen:

Zunächst “CommandCam” herunterladen und in ein Verzeichnis legen – dort kommen später auch die Bilder hin (ist bei mir I:\Tools\CommandCam).

Dann folgenden Post-Commit-Hook in C:\Program Files (x86)\Git\share\git-core\templates\hooks\post-commit (bzw. im jeweiligen Repository in .git/hooks/post-commit eintragen (Pfade selbstverständlich entsprechend ersetzen):

cd I:/Tools/CommandCam
number=$[ ( $RANDOM % 4000 )  + 1000 ]
CommandCam.exe //filename gitcc`date +%s`.bmp //quiet //delay $number

Das war’s dann schon – ab jetzt macht eure Webcam bei jedem Commit ein hübsches Foto von euch (mit zufällig zwischen 1 und 5 Sekunden Verzögerung).

Beni beim Coden