Ruby aktualisieren mit rbenv

Die Aktualisierung einer Entwicklungsumgebung ist mit allen Abhängigkeiten und Werkzeugen meist keine einfache Sache. Für Ruby steht einem für diese Aufgabe das äusserst praktische Werkzeug rbenv zur Verfügung. Dies kümmert sich um alle Abhängigkeiten und führ die Pfad-Variablen automatisch nach. Es gibt allerdings einen kleinen Stolperstein, der einem unnötig viel Zeit kosten kann.

Kurz-Tipp: Pakete installieren wenn RubyGems nicht läuft

Wenn ein Service immer verfügbar ist macht man sich oft gar keine Gedanken wie man ohne diesen arbeiten kann. RubyGems.org ist so ein Service, der seit ich mich mit Ruby beschäftige, immer wie gewünscht seinen Zweck erfüllt hat. Egal was für ein Gem ich gesucht habe, RubyGems hat immer schnell und zuverlässig die benötigten Abhängigkeiten aufgelöst.

Anfang Dezember war dies für einmal nicht so. Infolge einer grossen DDOS-Attacke auf DNSimple war auch RubyGems.org nicht mehr erreichbar. Und ohne RubyGems.org gab es auch keine Chance mehr eine fehlende Bibliothek zu installieren.

Glücklicherweise liess sich das Problem schnell beheben. Um beim nächsten Ausfall weiterhin Gems installieren zu können beschreibe ich heute 2 mögliche Ansätze.

 

Gemfile anpassen

Nutzt man Bundler um mit einem Gemfile die Abhängigkeiten zu verwalten lässt sich bei einem Ausfall sehr einfach eine andere Paketquelle verwenden. Dazu genügt es die Zeile source mit einer alternativen Quelle zu versehen:

#source 'https://rubygems.org'
source 'http://production.cf.rubygems.org'

 

Neue Quelle hinzufügen

Abseits von Bundler kommt oft der Befehl gem install zum Einsatz. Da es dafür keine projektspezifische Konfigurationsdatei gibt muss man eine alternative Paketquelle für dass ganze System hinzufügen. Dazu kann man diesen Befehl verwenden:

gem sources --add http://production.cf.rubygems.org

Sobald RubyGems.org wieder funktioniert kann man diesen Eintrag nach dem gleichen Prinzip entfernen:

gem sources --remove http://production.cf.rubygems.org

 

Fazit

Ein solch wichtiger Dienst wie RubyGems.org schätzt man erst so richtig wenn dieser nicht mehr läuft. Wenn man aber weiss wie man eine alternative Paketquelle definieren kann muss man auch bei einem Ausfall seine Arbeit nicht unterbrechen.

5 Podcasts für Software-Entwickler

Podcasts sind für mich ein sehr angenehmes Format um mich auf dem Laufenden zu halten. Alles was es braucht ist eine Mobiltelefon und eine vernünftige App die Podcasts verwalten kann. Und natürlich die passenden Podcasts. Heute möchte ich 5 Podcasts vorstellen die ich regelmässig höre und ich für Software-Entwickler empfehlen kann.

Mir gefällt an diesen Podcasts vor allem der regelmässige Blick über den Tellerrand. Sich nicht nur auf ein spezifisches Thema oder eine Technologie zu limitieren macht angesichts der kurzen Halbwertszeit von Frameworks und Toolkits Sinn. So bleiben viele der besprochenen Themen auch dann noch relevant wenn wir schon den nächsten Hype vor uns haben.

 

Ruby Rogues

Ruby Rogues ist eine wöchentliche Diskussionsrunde die sich vorwiegend um Ruby dreht. Hat man sich einmal an das wilde Durcheinander gewöhnt schätzt man sehr bald den grossen Themenmix und das fundierte Wissen der Moderatoren.

Neben dem Book Club gefallen mir besonders die Episoden bei denen es um allgemeine Themen wie dem Lernen oder Software-Qualität geht. Hier kommen aus meiner Sicht die unterschiedlichen Erfahrungen der Rogues besonders gut hervor und ermöglichen sehr spannende Diskussionen.

Ein grosses Plus für diesen Podcast sind die Abschriften die es für jede Folge gibt. Damit kann man auch später einzelne Themen oder Links einfach finden ohne sich die genaue Folge merken zu müssen.

 

Hanselminutes

Scott Hanselman dürfte den meisten .Net Entwicklern durch seine Präsentationen rund um ASP.net bekannt sein. Sein Podcast Hanselminutes ist glücklicherweise keine Microsoft-Werbeveranstaltung sondern behandelt die Themen die ihn persönlich interessieren.

Jede Woche bespricht Scott mit einem Gast in rund 30 Minuten ein Thema aus dem IT-Bereich. Dabei ist es immer wieder erstaunlich mit wie viel Hintergrundwissen seine Gäste aufwarten können.

Besonders lustig wird es wenn Richard Campbell ein bis zwei Mal pro Jahr für eine Hanselminutiae Folge zu besuch kommt. Diese Gespräche über alles was die beiden gerade so machen sind sehr spannend und die Liste von Gadgets meist endlos.

 

This Developer’s Life

Leider nur sehr unregelmässig und mit grossen Pausen erscheint This Developer’s Life. Die Gemeinschaftsproduktion von Scott Hanselman und Rob Conery nimmt sich in rund einer Stunde grösseren Themen an, die einem meist sehr lange im Gedächtnis haften bleiben. Space, Typo, Cancer und Getting Fired sind nur eine kleine Auswahl der Themenvielfalt.

 

.Net Rocks!

Carl Franklin und Richard Campbell machen zusammen seit einer gefühlten Ewigkeit .Net Rocks. Thematisch sind die beiden in der .Net Welt beheimatet und kennen dort alles was Rang und Namen hat.

Mit 2 Folgen a 60 Minuten pro Woche ist es kaum möglich alle Folgen zu hören. Bei der Menge kann man aber problemlos einen „eigenen“ Kanal mit ausgewählten Episoden zusammenstellen und hat immer noch genug Material.

 

Herding Code

Herding Code erscheint rund alle zwei Wochen und wird von K. Scott Allen, Kevin Dente, Scott Koon und Jon Galloway moderiert. Thematisch ist dieser Podcast noch mehr auf .Net fokussiert als .Net Rocks, was einem durch die unterschiedlichen Meinungen ein recht genaues Bild über das .Net Ökosystem liefert.

 
Soweit meine Liste mit Podcasts. Da auch ich gerne neue Podcasts kennen lernen sind weitere Empfehlungen sehr willkommen.

Mittels Technologieradar die Übersicht behalten

Bei all den vielen neuen Werkzeugen, Techniken und (JavaScript-) Frameworks die wie Pilze aus dem Boden schiessen ist es äusserst schwer den Überblick zu behalten. Überall sieht man neue Dinge und vieles davon sieht so spannend aus dass man dies gleich ausprobieren will. Nur ist die Menge mittlerweile viel zu gross um dies auch zu tun.

Was man bräuchte ist eine Art Filter mit dem man sich gezielt auf einige ausgewählte Themen und Werkzeugen konzentrieren kann. Man müsste wichtigeres von unwichtigem trennen können ohne dabei zu viel Zeit mit dem Kategorisieren zu verlieren. Was ich bräuchte wäre etwas wie der Technology Radar von ThoughtWorks, nur halt für mich und meine Interessen.

 

Von ThoughtWorks zum eigenen Technologieradar

ThoughtWorks veröffentlicht in etwa alle 6 Monate eine Aktualisierung ihres Technologieradars. Die Grafik ist dabei eine Zusammenfassung der internen Diskussionen und zeigt auf in welche Richtung sich die IT-Branche aus ihrer Sicht bewegt. Statt grosser Dokumente hilft einem eine einzige Grafik abzuschätzen ob man Zeit in die entsprechende Technologie investieren soll oder besser gleich eine Migration plant. Dazu dienen diese 4 Ringen:

• Hold (abwarten): Keine neuen Projekte mit diesen Technologien starten.
• Assess (einschätzen): Genauer hinschauen ob sich daraus etwas entwickelt.
• Trial (ausprobieren): In kleineren und weniger wichtigen Projekten Erfahrungen sammeln.
• Adopt (umsetzen): Bereit um in kritischen Anwendungen verwendet zu werden.

Neal Ford ist nicht nur beim Radar von ThoughtWorks involviert, sondern spricht auch an Konferenzen über den Nutzen eines persönlichen Technologieradars. In diesem Blogpost erklärt Ford wie man damit auch einen Realitätsabgleich machen kann. Fixiert man sich zu sehr auf einen Hersteller bekommt man nicht mehr mit wie sich die Welt um einen herum verändert – bis es zu spät ist und man keinen neuen Arbeitgeber findet.

Das Festlegen auf die einzelnen Technologien und wo man diese sieht ist der aufwändigste Teil um selber einen Technologieradar zu erstellen. Hier kommt es ganz auf die eigene Einschätzung an, da angesichts der schnellen Veränderungen objektive Kriterien kaum weiterhelfen.
Sobald man alles beisammen hat geht es mit der grafischen Darstellung recht schnell. Dank der grossen Vorarbeit von Brett Dargan uns seinem Projekt Techradar braucht man nur noch eine JSON-Datei anzupassen und schon hat man seine Grafik.

 

Mein Technologieradar

Für meine Grafik bin ich recht schnell von ThoughtWorks abgewichen. Wenn auch etliche Technologien gleich sind so hat mir die Vorlage nicht ganz entsprochen. Der Quadrant „Techniques“ ist bei mir weiter gefasst und beinhaltet neben technischen Lösungsansätzen auch Verfahren und Methoden. Gleiches gilt für den Quadranten „Infrastructure“ der bei mir auch Plattformen und Services umschliesst.

 
 
Techniken, Verfahren & Methoden

In diesem Quadranten gibt es bei mir die meisten Einträge in den Ringen „Adopt“ und „Trial“. Dies war nicht so geplant, zeigt aber einen interessanten Nebeneffekt des Technologieradars: Durch die grafische Darstellung kann man eine thematische Häufung von Einträgen erkennen die einem so vorher nicht bewusst war.

Bei all den Dingen die ich anschauen oder umsetzen will gibt es eine grosse Ausnahme: Es muss aufhören aus reiner Bequemlichkeit in einer API 1:1 die Limitierungen der darunterliegenden Systemen weiterzureichen. Nur weil SQL Server Null-Werte als 1.1.1753 maskiert braucht ja nicht jeder Konsument der API in seiner Anwendung die Null-Konvertierung selber durchzuführen. Auch wenn ich dies bisher vor allem im Bereich von Datenbanken angetroffen habe gibt es keinen Grund dies nicht auch bei anderen Systemen zu beachten.

 
Infrastruktur, Plattformen & Services

Das grosse Thema in diesem Quadranten ist die Cloud. Trotz all der NSA Enthüllungen gibt es hier Chancen die zu gut sind um sie zu ignorieren. Angefangen bei GitHub über Code Climate bis hin zu Amazon und Azure gibt es unzählige Einsatzgebiete die auf eine Erkundung warten.

Bei RavenDB habe ich am längsten um die Einteilung gerungen. Da mir noch einige wichtige Informationen für den Produktiveinsatz fehlen blieb es schlussendlich beim Einsatz in kleineren Projekten. Die Wissenslücken für den Einsatz in geschäftskritischen Anwendungen sollte ich aber bald schliessen können.

 
Tools

Viel Auszuprobieren gibt es für mich bei den Tools. Rund um Ruby gibt es eine Vielzahl von Helfern fürs Testing und den Aufbau von Entwicklungsumgebungen. Bei .Net vermisse ich bisher so ausgereifte Werkzeuge. Daher wird es Zeit genau zu prüfen wie weit SpecFlow und MSpec, respektive Puppet und Chef gekommen sind.

Ein weiteres spannendes Thema sind für mich Micro ORMs. Realistisch betrachtet wechselt man kaum je die Datenbank bei einem Projekt aus. Daher sind OR-Mapper wie Entity Framework oder NHibernate mit ihren Abstraktionsschichten oft ein grosser Overhead der einem den Zugriff auf datenbankspezifischen Funktionen nur über Umwege erlaubt. Micro ORMs könnten da eine Alternative sein die eine vertiefte Abklärung verdienen.

 
Sprachen und Frameworks

Sowohl für C# wie für Ruby Entwickler dürften die meisten Einträge in diesem Quadranten nachvollziehbar sein. Wo es wohl einige Erklärung braucht ist der „Hold“ Ring.

Bei den Desktop-Frameworks wie WPF aber auch WinForms halte ich mich derzeit zurück. Angesichts verteilter Standorte, Home Office und der Verbreitung von Tablets setze ich viel eher auf die Webentwicklung. Diese allerdings abseits von WebForms und Silverlight. Da Silverlight selbst von Microsoft nicht mehr in allen IE-Varianten unterstützt wird ist diese Technologie definitiv gestorben – auch wenn die Supportseite einem eine andere Geschichte erzählen will.

Sehr skeptisch bin ich auch bei TypeScript. Hier handelt es sich aus meiner Sicht um eine Lösung auf der Suche nach einem Problem. Die Probleme vieler Entwickler mit JavaScript lassen sich nicht durch ein aufgepfropftes Typensystem lösen – viel eher muss man JavaScript als eigenständige Sprache akzeptieren und die Eigenheiten lernen. Und sollte TypeScript tatsächlich länger bleiben kann man später immer noch auf diesen Zug aufsteigen.

 

Fazit

Beim Zusammenstellen des Technologieradars muss man sich plötzlich festlegen. Es genügt nicht mehr nur eine vage Liste mit interessanten Technologien zu haben – nun wird auch eine Einteilung in die Kreise und Quadranten benötigt. Es bleibt einem nichts anderes übrig als die einzelnen Technologien zu ordnen und zu klassifizieren.

Der grosse Nutzen dieser Übung liegt für mich im bewussten Auseinandersetzen mit den einzelnen Technologien und der Entscheidung, ob diese nun einen Platz im Radar finden oder nicht. Dabei spielt es keine grosse Rolle wo genau sich diese auf der Grafik befinden. Viel wichtiger ist welche Technologien es überhaupt hinein schaffen.

Wieviel mir die ganze Übung am Ende bringen wird muss sich noch zeigen. Die ersten Erfahrungen waren allerdings so hilfreich dass ich die Erstellung eines eigenen Technologieradars sehr empfehlen kann.

5 Bücher die jeder Software-Entwickler kennen sollte (Ausgabe 2014)

Vor gut 1.5 Jahren habe ich bereits einmal eine Top 5 Liste mit Büchern veröffentlicht. Seither habe ich viel gelesen und es ist daher höchste Zeit die Leseempfehlungen zu aktualisieren.

Ich versuchte wiederum eine möglichst technologieneutrale Liste zusammenzustellen. Frameworks kommen und gehen und sind stellenweise in erschreckend kurzer Zeit wieder obsolet. Die hier vorgestellten Bücher behandeln Themen die schon länger aktuell sind und es allem Anschein nach noch einige Jahre bleiben werden.

 

Practical Object-Oriented Design in Ruby

Obwohl sehr viel über OO-Design geschrieben wird ist es sehr schwer ein gutes Buch für den Einstieg zu finden. Sandi Metz hat einen guten Mittelweg zwischen Theorie und Praxis gefunden und es gelingt ihr dieses Thema in verständlichen Schritten zu erklären. Auch wer sich mit Ruby nicht auskennt kann hier viel über OO-Design lernen.

Da die Beispiele recht kurz sind kann man sich auf genau den behandelten Teilaspekt konzentrieren. Dies hilft nicht nur Einsteigern sondern ist auch sehr gut als Auffrischung für erfahrene Programmierer geeignet.
(ISBN: 978-0-3217-2133-4 | detaillierte Rezension)

 

Refactoring

Trotz seines Alters ist Refactoring nach wie vor das Standardwerk zur Restrukturierung von Code. Der ausführliche Katalog mit Strategien zur Verbesserung der Codebasis ist aus meinem täglichen Entwicklerleben nicht wegzudenken.

Dies bedeutet keinesfalls dass ich alle darin vorgestellten Methoden auswendig kenne. Aber Refactorings wie das Umbenennen von Variablen oder das Extrahieren von Methoden sind Dinge die jeder beherrschen sollte. Diese sind sehr einfachen und verbessern den Code doch enorm.
(ISBN: 978-0-201-48567-7 | detaillierte Rezension)

 
 

The Art of Unit Testing (Second Edition)

Roy Osherove liefert das aus meiner Sicht bisher beste Buch über Unit Testing. Es gibt viele Bücher die gut sind, seine Erklärung von komplexeren Themen wie dem Mocken von Abhängigkeiten ist aber immer noch unerreicht. Und mit der 2. Ausgabe wurden die Praxisbeispiele und Tipps nochmals besser.

Gerade diese Praxisbeispiele helfen einem dabei auch die komplexeren Bereiche mittels Unit Tests abzudecken. Nur wenn man diese Herausforderungen meistern kann wird man Unit Tests in die eigenen Projekte integrieren.
(ISBN: 978-1-6172-9089-3 | detaillierte Rezension)

 
 

Clean Code

Unit Tests und Refactoring sind Techniken die den Code sauberer machen. Wenn einem diese Richtung gefällt ist Clean Code von Robert C. Martin der nächste Schritt.

Sein Buch geht den Weg weiter und verbindet verschiedenste Erkenntnisse in der Software-Entwicklung der letzten Jahre zu einem Ganzen.
Bei Clean Code ist es aus meiner Sicht aber besonders wichtig das man das Ziel bei all den Regeln nicht aus den Augen verliert. Verständlicher Code sollte immer vor einer in Stein gemeisselten maximalen Anzahl Zeilen für eine Methode gehen.
(ISBN: 978-0-13-235088-4 | detaillierte Rezension)

 
 

Patterns of Enterprise Application Architecture

Das 2. Buch von Martin Fowler in meiner Liste behandelt die Patterns rund um Geschäftsanwendungen. Die Problemstellungen in diesem Bereich sind so grundlegend dass die meisten Entwickler in ihren Projekten damit zu tun haben – ganz egal ob ihre Projekte den Stempel „Enterprise“ tragen oder nicht.

Fowler beschränkt sich nicht nur darauf die einzelnen Patterns aufzulisten, sondern erklärt auch die jeweiligen Vor- und Nachteile. Diese Gegenüberstellung macht für mich den Wert dieses Buches aus, da man nur so eine fundierte Entscheidung treffen kann.
(ISBN: 978-0-3211-2742-6 | detaillierte Rezension)

 
 

Soweit meine aktualisierte Liste von Büchern die ich als „Must-Read“ bezeichne. Ich würde mich freuen zu erfahren was andere Entwickler als unverzichtbare Bücher auflisten.