Programmer At Work

"Adding manpower to a late software project makes it later." -- Fred Brooks, 1975

The Mythical Team-Month ist eine großartige Präsentation von Justing Searls (u.a.) über erfolgreiche Teams und schnellere Feedbackzyklen in der Softwareentwicklung. Die Folien stehen für sich alleine und sind aufgrund der angeschlagenen Audioqualität fast besser als die die 40minütige Aufzeichnung der Präsentation (siehe unten):



Hier die Videoaufzeichnung:

The Mythical Team Month from Justin Searls on Vimeo.

"Cuz if I didn't write it, the code obviously sucks."

JavaScript marschiert unaufhaltsam auf seinem Weg Richtung Weltbeherrschung. Während die einen noch über Prototype Inheritence jammern, haben es die anderen längst verstanden und bauen moderne large-scale Webapplications der nächsten Generation.

Devon Govett berichtet auf Badass JavaScript regelmässig über beachtenswerte Projekte und Neuigkeiten rund um JavaScript. In 2011: A Badass JavaScript Year In Review gibt er einen Rückblick auf einige der Projekte die im vergangenen Jahr herausstachen.

Allen voran auf der Liste natürlich jslinux von Fabrice Bellard, dem französischen Überhacker dem nach:

• LZEXE, dem ersten weitverbreiteten MS DOS EXE-Packer mit dem man Executables kompromieren und ausführen konnte ohne sie vorher wieder dekompromieren zu müssen
• einer Java Virtual Maschine und einem Java Bytecode nach C Compiler (Harissa)
• QEmacs, einem schnellen Emacs Klon
• einem kleinen und sehr schnellen ISO C99 kompatiblen C Compiler (TCC)
• FFmpeg, dem digitalen Video-/Audio-(De)kodierungsherzstück von MPlayer, VLC, Xine, HandBrake und Co
• der Virtualisierungssoftware QEmu
• dem mehrmaligen Gewinn des International Obfuscated C Code Contests
• und dem Weltrekord in Pi Nachkommastellen berechnen

mal wieder etwas fad war und deshalb jslinux, einen (32 Bit x86) PC Emulator in JavaScript der Linux bootet, gehackt hat. D.h. wer mal qemacs oder tcc ausprobieren möchte, das geht jetzt auch im Browser

Ein anderes eindrucksvolles Beispiel für "da-tut-sich-was!" ist pdf.js, einem PDF Parser und Renderer in JavaScript der ohne nativen Code auskommt, von Mozilla Labs.

Und das sind nur zwei von vielen spannenden Projekten im JavaScript Umfeld von 2011 und Projekten wie CoffeeScript, Node.js, diversen JavaScript MVC/MVVM Frameworks wie Knockout.js oder auch Emscripten, dem LLVM-to-JavaScript Compiler, die schon ein wenig älter sind.

Frei nach Wolle's New Years Law:

"Embrace Change und beginne jedes neue Jahr in einer neuen Stadt!" -- Wolfgang Kaufmann

zog es uns für den Jahreswechsel von 2011 auf 2012 in die slowakische Hauptstadt Bratislava.

Vom zentral gelegenen Hotel Avance aus erkundeten wir bei herrlichem Sonnenschein die Stadt. Über viele europäische Städte wachen Burgen oder Schlößer und diese bieten meist einen perfekten Platz um das imposante Feuerwerksschauspiel (Ausnahme Budapest) der zu Füßen liegenden Stadt zu beobachten.
So hatten wir auch diesesmal geplant um Mitternacht auf der (hübsch renovierten) Burg Bratislava anzustoßen, allerdings versperrten Sicherheitskräfte Michael mit seinen Feuerwerkskörpern den Weg durch die Stadt und wiesen uns darauf hin, dass das beeindruckende Stadt-Feuerwerk ohnehin in der gegensätzlichen Richtung, am Donauufer, nur wenige Meter von unserem Hotel entfernt, stattfindet. Tipp: Nach dem Anstoßen in die Bar Corrida de toros feiern und neue Leute kennenlernen gehen.

Tipp: Auf einen Besuch im Restaurant Hacienda Mexicana verzichten. Essen & Ambiente okay, aber unverständlich lange Wartezeiten trotz einer überschaubaren Anzahl an Gästen, nicht sauberes Besteck und wenig bemühte Servicekräfte bei gehobenen Preisen sprechen gegen eine Empfehlung.

Fazit: Bratislava ist eine nette Stadt. Nicht so schön wie Budapest, Prag oder Wien, aber dafür auch von Touristen nicht so überlaufen.

Einführende Videos über Scrum gibt es viele. Dieses hier zählt definitiv zu den Besseren. Gerade mal acht Minuten braucht Hamid Shojaee um seinen Zusehern viele Kernelemente von Scrum gespickt mit einigen persönlichen Erfahrungen zu vermitteln.



Klar, so manches Scrum -Artifakt oder -Meeting kommt in einem 8minütigen-Crash-Course zwangsläufig etwas zu kurz, aber dennoch ein gutes Video. Bemerkenswert finde ich neben der Gleichsetzung von ScrumMastern und Projektmanagern vorallem seine Einstellung zu Daily Scrums:

"The idea behind a standing meeting is that if everyone is standing nobody will waste time and therefore meeting will be short. And by meeting daily you can feel confident that everyone is on top of their tasks. The daily scrum is a great idea and especially useful in less experienced teams but I wouldn't call it a core or essential part of scrum. Insisting on these meetings in an already efficient and experienced team, especially teams that work in close proximity with one another could actually backfire by lowering team morality. Keep that in mind when deciding on having daily scrums." -- Hamid Shojaee über Daily Scrum

Heißt das also "Erfahrenes eingespieltes Team + aufrechter Kommunikationsfluss innerhalb des Teams" == "Daily Scrum kontraproduktiv"?

Auf keinen Fall! Schließt dieser aufrechte Kommunikationsfluss auch den Product Owner und vor allem auch den Scrum Master mit ein? Für beide ist das Daily Scrum von wesentlicher Bedeutung. Für den SM ist es ein Kanal um Impediments klar aufgezeigt zu bekommen, die zuvor vielleicht einem einzelnen Teammitglied aber nicht der ganze Gruppe bewusst waren. Blockaden die vielleicht bisher einfach nie angesprochen wurden. Außerdem ist das Daily Scrum nicht nur für das Team da. Es bietet auch Außenstehenden - allen Interessierten, wie etwa Marketing, Geschäftsführung, Kunden, potentiellen Nutzern... - eine Möglichkeit in ein Team und in ein Projekt hinein zu sehen.

"It's the meeting to end all meetings." -- Jonathan Rasmusson

Vor allem aber sollte das Daily Scrum natürlich seinen Teammitgliedern (und dem Projekt!) dienen. Es sollte Teil einer gefestigten Routine sein, die den (Tages-)Rhythmus vorgibt. Es ist mehr als ein Synchronisationsmeeting um sich über den Stand der Dinge zu informieren, es ist vor allem auch eine Gelegenheit ein Team noch enger zusammen zu schweißen und zu motivieren!

Aber es stimmt, einerseits sind auch erfahrene eingeschworene Teams die seit langem zusammen arbeiten, co-located sind, sich permanent austauschen und mit Scrum beginnen nicht vor schlechten Meetings sicher. Anderseits kann bei agilen Teams die tägliche taktische Planungskomponente (wer übernimmt welche Aufgaben?) mit der Zeit an Reiz verlieren kann. Oftmals begleitet von zusätzlichen Lästigkeiten, wie z.B. dass sich das Meeting verzögert, weil immer irgendjemand noch schnell irgendetwas fertig machen möchte. "Einen Moment noch! Muss nur noch schnell diese eine E-Mail fertig schreiben, dieses eine Telefonat führen, den Server neustarten, den Buildprozess anstoßen? (und dann unvorbereitet zum Daily Scrum)"

In solchen Fällen könnte ein Funkwecker im Teamraum helfen oder das automatisierte Abspielen eines bestimmten Songs, wie z.B. die Anfangssequenz von The Final Countdown von Europe oder irgendeinem anderen Song aus Rocky.

Aber klar, wenn jemand gerade im Flow ist, ist jede Unterbrechung schlecht.

"The purpose is not to meet... it is to improve." -- Joe Ely

Ein weiterer positiver Aspekt von Daily Scrums: Wenn man als Entwickler morgens beim Daily Scrum seinem Team - quasi öffentlich - erklärt, dass man die Funktion »Speichern« bis zum nächsten Daily Scrum liefern wird, dann erhöht das auch die Chance, dass das Feature tatsächlich geliefert wird (=commitment/forecast to each other). Jeder Mensch möchte stolz auf sich sein, möchte von anderen wertgeschätzt werden und niemand möchte seine Kollegen enttäuschen. Dieses Verhalten und der Wunsch etwas Qualitatives zu liefern ist meiner Erfahrung nach unter Softwareentwicklern besonders ausgeprägt.

Abschließend ein Tipp aus Jason Yips Artikel: It's Not Just Standing Up: Patterns for Daily Standup Meetings

"Instead of thinking of the daily stand-up as a ritual for the people, think of it as a ritual where the Work Items Attend (e.g., User Stories in an Agile context) and the people attend only to speak for the work items... since obviously the work items can't actually talk." -- Jason Yip

[...] How computer programmers store the vital product of their labours – source code. The (for now) final end product seems incredibly obvious.

[...] Yet it took decades of iterative innovation, from some of the cleverest minds in the field, to make something so apparently simple yet powerful.

Francis Irving, der Autor von TortoiseCVS, über die Meilensteine in der Geschichte von Versionskontrollsystemen.

Wer sich ein bisschen bishin zu sehr viel mit Softwareentwicklung - und Scrum im Besonderen - beschäftigt, aber den Scrum et al. Talk von Ken Schwaber auf Google Video noch nicht gesehen hat: Halt! Sofort anschauen und heute noch etwas Neues lernen oder im schlechtesten Fall: von einem Ex-Marine gut unterhalten werden.

Scrums assumption is that you are intelligent or at least as intelligent as you'll ever be and that you will use that intelligence and your experience to come up with the best solution for whatever circumstance you're in right then.

When we first [...] announced Agile, 2001 there were a number of comments that agile was really, really good. This way from [...] people who were kind of a little troubled with Agile. They said really, really good if you have a team of outstanding engineers that are using excellent engineering tools, have engineering practices down pat, understand the business domain, the technology domain inside out and aren't interrupted and have all the resources they need, then you can use Scrum. While it's true that people like that can build an increment of software every iteration. That's good.

However, Scrum works with idiots. You can take a group of idiots, that maybe didn't even go to school, don't understand computer science, don't understand software engineering techniques, hate each other, don't understand the business domains, have lousy engineering tools and uniformly they will produce crap every increment. This is good!

You want to know - at the end of every iteration - where you are. And part of the point of Scrum [...] is transparency. So that everyone knows where you are all the time. -- Ken Schwaber

"A language that doesn't affect the way you think about programming, is not worth knowing." -- Alan Perlis, Epigrams on Programming

Tolle Präsentation mit anschaulichen Beispielen. Von Perl im Namen nicht irritieren lassen.

Was haben Flugzeugabstürze, Viren und fliegende Robots gemeinsam? Sie sind Teil der Reihe von TED Talks für die ich am Wochenende endlich Zeit hatte. TED Talks sind eine wunderbare Quelle an inspirierenden Präsentationen. Die Inhalte sind unterhaltsam, abwechslungsreich, originell, geistvoll und mit vielen Aha-Momenten bestückt.

Markus Fischer, A robot that flies like a bird, 2011, 6:20 min

Marco Tempest, The magic of truth and lies (and iPods), 2011, 5:07 min

Harald Haas, Wireless data from every light bulb, 2011, 12:52 min

Mikko Hypponen, Fighting virus, defending the net, 2011, 17:35 min

Mike Matas, A next-generation digital book, 2011, 4:35 min

Matt Cutts, Try something new for 30 days, 2011, 3:28 min

Ron Gutman, The hidden power of smiling, 2011, 7:27 min

Ric Elias, 3 things I learned while my plane crashed, 2011, 5:03 min

Philip Zimbardo, The demise of guys?, 2011, 4:47 min

Adam Ostrow, After your final status update, 2011, 5:30 min

"Something like This American Life but for geeks" -- Rob Conery

This Developer's Life ist eine ausnahmslos großartige Podcastserie über Entwickler und die Dinge die unser Leben ausmachen von Rob Conery und Scott Hanselman.

Ich wollte schon lange auf den Podcast aufmerksam machen, aber erst die aktuelle Episode über Schriften, Typografie und Bill Hill, einem Schotten der gerne surft, in der Wildnis Spuren liest, lange bei Microsoft gearbeitet hat, an der Entwicklung von ClearType, Berling, Verdana, Georgia beteiligt war und der viel über The Future of Reading nachdenkt, haben das Fass zum Überlaufen gebracht.


Hört euch das mal an! Ich hoffe wirklich, in seinem Alter noch genauso fit und voller Elan sein.

(Große) Logfiles lesen mit Vim macht gerade auf Remote Rechnern nicht immer Spass, daher nimmt man für Read-Only Dateien in der Regel etwas Schlankeres wie less oder tail (und grep, awk, sed, ...)

Um Änderungen an Live Logfiles in Vim mitzubekommen, hilft das Plugin TailBundle (:TabTail theLog.file), welches Änderungen an Dateien auf Wunsch (Ctrl-K) oder automatisch wieder einliest (siehe :tabh updatetime).

Für das Suchen in Logfiles empfiehlt es sich das farbliche Markieren von Suchergebnissen mit :set hlsearch einzuschalten. Mit :nohlsearch lassen sich die aktuellen Markierungen entfernen, mit :set nohlsearch lässt sich das Markieren wieder ganz abschalten. Noch angenehmer geht das mit dem MultipleSearch-Plugin (:Search PATTERN), mit welchem mehrere Suchergebnisse unterschiedlich farblich markiert werden können.

Vier Tage vor seinem ersten Turniereinsatz hat sich mein Yonex Arcsaber 10 bei einem relativ harmlosen Ballwechsel mit einem Rahmenbruch verarbschiedet.

Auf der Suche nach einem Terminal Emulator mit Unicode Support, vernünftigem Font-Handling, der sparsam mit Ressourcen umgeht, aber dennoch Schmankerl wie Tabs, transparente Fenster oder URL-Recognition bietet, bin ich vor Jahren bei rxvt-unicode (urxvt) gelandet und seitdem wirklich glücklich.

Download: Meine ~/.Xresources Konfiguration