Zweitag auf der Baruco 2014 - Tag 2

Brian Shirai: Types As Premature Optimization

Brian Shirai erläuterte in seinem Vortrag, dass das Programmieren eine Tätigkeit ist, die den gleichen kognitiven Prozessen unterliegt wie auch alle anderen Bereiche menschlichen Wirkens. Die in der Wahrnehmungspsychologie erlangten Erkenntnisse in diesem Bereich können wir somit teils nutzen, um uns vor Trugschlüssen zu schützen. In der Praxis lässt sich dies jedoch nur begrenzt umsetzen, da es sich um unterbewusste Effekte handelt. Um solche Probleme zu vermeiden, muss man erstens aktiv dagegen arbeiten, und zweitens a priori von etwaigen Fallstricken wissen, um diese im Falle ihres Eintretens erkennen zu können. Daher stellte Shirai in Anlehnung an die Eight Fallacies of Distributed Computing eine Reihe von acht „Trugschlüssen der Programmierung“ vor. Darunter wurden einige Probleme aus den Bereichen der Skalierbarkeit behandelt, z. B. der Irrtum, dass wenn man etwas einmal ausführen kann, sich dies beliebig oft wiederholen lässt. Weitere Effekte lassen sich dadurch erklären, dass das menschliche Gehirn stets das Wahrgenommene vereinfacht und abstrahiert. Somit besteht die Gefahr, dass wir z. B. ein chaotisches System als zu einfach modellieren, oder aber auch versuchen, Programmierkonzepte für Dinge wiederzuverwenden, für die sie eigentlich nicht geeignet sind. Die vorgestellten Tipps können Programmierer in ihre Toolbox aufnehmen und so möglicherweise die nächste Fehlentscheidung schon dort bekämpfen, wo sie entsteht. (Slides)

Erik Michaels Ober: Writing fast Ruby

Ein in der Informatik weit verbreitetes Zitat von Don Knuth verkündet, dass vorzeitige Optimierung die Wurzel alles Bösen sei. Erik Michaels-Ober milderte diese Aussage in seinem Vortrag ab, indem er einige Beispiele für Refactorings zeigte, bei denen nicht nur die Performance, sondern auch die Lesbarkeit des Codes verbessert werden. Solche Optimierungen können dann bedenkenlos zu jedem Zeitpunkt umgesetzt werden. Er zeigte darüber hinaus, wie man eine Erfolgskontrolle mit der Standard-Library benchmark, sowie mit dem Gem benchmark-ips durchführen kann. Im Gegensatz zu Eingriffen, die den Code in seiner Lesbarkeit verbessern, führen jedoch leider die meisten Optimierungen zu schlechterem Code. Allerdings laufen viele dieser Optimierungen sehr mechanisch ab, womit diese zu Aufgaben werden, die vom Computer übernommen werden können. Michael-Obers regte dazu an darüber nachzudenken, ob es nicht an der Zeit für einen Compiler für CRuby sei, der uns diese Aufgaben in Zukunft automatisiert abnehmen könne, wie es z. B. bereits bei Rubinius (rbx compile) und JRuby (jrubyc) der Fall ist. Zwar waren sprachenunabhängige Optimierungen auf der Ebene des Designs wie z. B. die Eliminierung von n+1-Queries und die Verbesserung von Algorithmen nicht Gegenstand des Vortrags, jedoch kann man davon ausgehen, dass diese in der Praxis schnellere Erfolge im Bezug auf die Performance bringen, als die gezeigten Optimierungen auf der syntaktischen Ebene. Wer also mit seiner Applikation Performance-Probleme hat, sollte zunächst an seinem Design feilen und erst im zweiten Schritt auf diese kleinen Optimierungen zurückgreifen, um auch noch das letzte Quäntchen Performance herauszukitzeln. (Slides)

Jason R. Clark: Spelunking in Ruby

Jason R. Clark zeigt Wege auf, die „dunklen Höhlen“ des eigenen oder fremden Codes zu erforschen, um dessen (Fehl-(Verhalten zu verstehen. Sein Vortrag bildet eine Aneinanderreihung verschiedener Ansätze des Debuggings bzw. der Code-Analyse. Diese teilt er in die drei Kategorien Built-in, Gems und Tools auf.

Während er im Built-in-Teil die Verwendung von in Ruby eingebauten Bestandteilen erläutert, wie z.B. puts oder caller, geht er bei Gems im Wesentlichen auf pry und die darauf aufbauenden Gems z.B. pry-nav oder pry-stack_explorer) ein.

Die Techniken, die Jason in diesen beiden Teilen (Built-in und Gems) anspricht, sind hilfreich und sinnvoll, aber für die meisten bereits weitestgehend bekannt. Im Tools-Teil jedoch erläutert er Werkzeuge, die vermutlich nicht im Toolset eines jeden Ruby-Entwicklers enthalten sein dürften. Beispielsweise empfiehlt er den gdb z.B. zur Identifikation von Deadlocks oder rbtrace zur Auflistung aller Ruby-Calls während einer Programmausführung. Dies erlaubt sehr tiefe Einblicke in die Funktionsweise des betrachteten Codes, erfordert jedoch insbesondere beim Lesen der Logs ein größeres Maß an Übung.

Mit dieser sehr hilfreichen und praxisrelevanten Auflistung seines persönlichen Debugging-Toolsets will Jason vor allem auch eines zum Ausdruck bringen: Suche dir passende Tools für jeden Teil deines Technologie-Stacks und schrecke nicht davor zurück, dich auf zunächst kompliziert wirkende Tools einzulassen. (Slides)

Evan Phoenix: Services, Services, Everywhere!

Evan Phoenix spricht in leidenschaftlicher Weise über das Thema Services. Leidenschaftlich deshalb, weil man ihm anmerkt, dass vieles von dem Wissen, das er mit seiner Zuhörerschaft teilt, durch leidliche Erfahrung angeeignet wurde.

Das Kernstück seines Vortrags bildet der Evan’s Practical Guide to ServicesTM, der viele wertvolle Tipps und Regeln enthält, die es bei der Entwicklung von Services zu beachten lohnt. Angefangen von der intuitiven Definition von Service-Grenzen, über den Appell ActiveRecord Models niemals für mehrere Services wiederzuverwenden, hin zur Standardisierung des Deploymentvorgehens spricht Evan eine Vielzahl von Empfehlungen aus.

Zudem verwendet er einen großen Teil seiner Redezeit darauf, zu unterstreichen, wie wichtig eine robuste Inter-Service-Kommunikation ist. Es geht ihm darum, das Netzwerk als fragilen Faktor wahrzunehmen, von dem Fehler zu erwarten sind und deshalb geeignete Gegenmaßnahmen ergriffen werden müssen. Beispielsweise regt er an, die Art der Kommunikation über alle Services hinweg zu standardisieren, Tracing durch RequestIDs zu ermöglichen oder die Parallelität durch die Verwendung von Futures zu fördern.

In seiner zentralen Take-Away-Message appelliert Evan daran, Decoupling bei Services nicht als Selbstzweck zu betrachten, sondern immer nach einer sinnvollen Abgrenzung der einzelnen Services zu streben und dabei insbesondere das Netzwerk als Hauptfehlerquelle zu betrachten. Die meisten der zahlreichen von Evan angeführten Ratschläge spiegeln sich auch in unseren Erfahrungen wider, weshalb wir diesen Vortrag jedem, der sich mit Services beschäftigt nur wärmstens empfehlen können. (Slides)

Tom Stuart: Refactoring Ruby with Monads

Tom Stuart spricht in seinem Vortrag über die Überführung des Konzepts der Monade aus der funktionalen Programmierung in die Ruby-Welt. Dabei versucht er gar nicht erst, die nicht ganz triviale Theorie hinter Monaden zu erklären. Vielmehr gibt er eine Reihe von Beispielen, die er schließlich als Typen von Monaden bezeichnet.

Im ersten Beispiel definiert er z.B. einen Decorator mit dem Namen Optional (in Haskell bekannt als Maybe), der es ermöglicht bei einer Methoden-Verkettung auf Aufrufe von try verzichten zu können und trotzdem nicht Gefahr zu laufen, NoMethodErrors zu erhalten, sobald eine der Methoden in der Kette nil zurückliefert. Die beiden folgenden Beispiele sind ganz ähnlich aufgebaut, wobei er zunächst die Verkettung von Listen (Many) und dann die Behandlung von asynchronem Code (Eventually) thematisiert.

Am Ende des gesamten sukzessiven Refactoring-Prozesses, den Tom in seinem Vortrag durchläuft, sieht der Code deutlich aufgeräumter aus. Allerdings wählt er Ausgangsprobleme, die für sich genommen schon fragwürdig sind. Bei der Verkettung von

project.try(:creator).try(:address).try(:country).try(:capital).try(:weather)

ist die Verwendung von try sicherlich nicht das vordergründige Problem.

Während des Vortrags wird nicht deutlich, welche Implikationen der gewählte Weg hat und welche Nachteile sich dadurch ergeben könnten. Ein weiterer Punkt der von Tom vollständig ignoriert wird, ist, dass er sich nur eines Teils des Monaden-Konzepts bedient, das z.B. in Haskell u.a. dafür eingesetzt wird, einen veränderbaren State abzubilden oder I/O-Operationen zu ermöglichen. Es wäre schön gewesen, hier ein bisschen mehr Hintergrundinformationen zu den Zusammenhängen zu erhalten. (Slides)

Matt Aimonett: Go Auth Urself

Matt Aimonetti demonstrierte die verschiedenen Sicherheitsmechanismen in Rails, die Session-Informationen vor Veränderung und Missbrauch schützen sollen. Er nutzte das fiktive Beispiel einer Dating-Plattform für Haustiere, die Nutzerinformationen in einer Rails-Anwendung und einem separaten Go-Prozess verarbeiten muss. Hierfür werden Session-Informationen zwischen den einzelnen Komponenten geshared.

Matt beschrieb zunächst den naiven Ansatz, Nutzerinformationen in Plaintext in der cookiebasierten Session abzulegen. Da ein missgünstiger Nutzer diese Daten auslesen und verändern kann, besteht hier ein offensichtliches Sicherheitsrisiko. Diesem begegnet Rails mit signierten Cookies, die zwar nicht mehr verändert, aber dennoch ausgelesen werden können. Seit Rails 4.0 werden Cookies standardmäßig verschlüsselt, so dass auch das Auslesen verhindert wird. Matt machte darüber hinaus auf Probleme des standardmäßig verwendeten Marshal-Serializers aufmerksam: Rubys „Marshal“-Implementierung führt nach der Deserialisierung die Methode „marshal_load“ aus, wodurch unter bestimmten Voraussetzungen (geleakter Secret Key, verwundbarer Code) beliebige Befehle ausgeführt werden können. Um diesen (arg konstruierten) Fall auszuschließen, riet er zur Verwendung des „hybrid“-Serializers, der seit Rails 4.1 verfügbar ist.

„Evil“ Tom Stuart: Smalltalk, Lisp, Bash: Three Interesting Languages

Tom Stuart, der zur Unterscheidung von seinem Namensvetter das Präfix „Evil“ erhielt, hielt einen Exkurs über die Grundkonzepte von Smalltalk, Clojure und Bash. Er stellte Smalltalk anhand der zugrundeliegenden 3 Konzepte „Objekte & Klassen”, „polymorphe Nachrichtenweiterleitung“ und “Blöcken” vor. Dabei erzählte er über bedingte Anweisungen, die über ifTrue und ifFalse Befehle ermöglicht werden. In Clojure, einem für die Java Virtual Machine entwickelter Lisp-Dialekt, beschrieb er das Konzept von Makros. Makros ermöglichen es in Clojure Compiler-Funktionalitäten durch Nutzerquellcode zu erweitern. Im Anschluss zeigte er in der Präsentation, wie man mit Hilfe von Makros den Befehl unless umsetzen kann. Als letztes Beispiel sprach er die Grundlagen der Unix-Shell Bash an. Er erklärte die Grundlagen des Umleiten und Pipelining über die typischen Bash Operatoren (, |) und ging darauf ein, dass alles in der Bash ein Kommando ist. Sogar eckige Klammern, die für bedingte Anweisungen notwendig sind, sind Kommandos für die auch eine Man-Page existieren ($man [).

Zum Abschluss stellte Tom Stuart die Frage in den Raum, ob es nicht großartig wäre, wenn es tatsächlich eine Programmiersprache geben würde, die alle Konzepte der zuvor vorgestellten Sprachen als Grundlage hätte. Ob er damit auf „Ruby“ anspielte, ließ er dabei offen.

Julian Cheal: Dancing with Robots

Julian Cheal mag Tweed und Roboter, deswegen erschien er für seinen Vortrag im feinen Tweed und mit einer ganzen Tasche voll elektronischem Spielzeug. Die Intention seines Vortrages war es dem Publikum zu zeigen, wie einfach und wieviel Spaß es machen kann, elektronische Geräte (Arduino bis hin zur Drone) mit Ruby zu programmieren. Dazu stellte er die Ruby Bibliothek artoo vor, mit welcher man mit einer einfachen DSL die unterschiedlichsten elektronischen Endgeräte ansteuern kann. Im Folgenden demonstrierte er eine Menge an unterschiedlichen Beispielen, auf welche Art und Weise man Artoo einsetzen kann. Julians abgedrehte und lustige Art machten die Demonstrationen zu einem urkomischen Highlight. Wie ein konfuser Magier zauberte er eine Idee nach der anderen hervor und brachte das Publikum immer wieder zum lachen. Ging es zu Beginn nur um das Programmieren von Micro-Controller wie den Arduino, Spark, DigiSpark oder BeagleBone, so zeigte er im weiteren Verlauf einen Leap Motion Controller, mit dem er eine Gesten-gesteuerte HarderFasterStrong-Karaoke vorführte, einen Ouya-Controller mit dem man seine Playlist steuert und als Highlight eine Playstation Dance Mat, mit der Julian zu Psys Gangnam Syle eine Drone zum tanzen brachte. Im großen und ganzen war es einer der lustigsten Vorträge der Konferenz und ein gelungener Abschluss des offiziellen Teils.

Am Abend krönte die Beach Party im Bambú Beach am Levant Strand eine rundherum gelungene Konferenz. Bei Beachvolleyball, Cocktails und Bier konnten alle Teilnehmer bei angenehmen Temperaturen von über 20 Grad die Nacht genießen.

Hier gehts zum ersten Teil unserer Baruco Zusammenfassung.