Archiv
Unterlagen zu “Ruby und Rails für .Net Entwickler” (Luzern)
Die .Net User Group Zentralschweiz gab mir Anfangs Woche die Gelegenheit meinen Ruby und Rails Vortrag für .Net Entwickler zu präsentieren. Gut 6 Monate nach der ersten Präsentation bei der .Net User Group Bern konnte ich so nochmals rund 30 .Net Entwicklern zeigen das es neben C# noch andere interessante Programmiersprachen gibt.
In den letzten Monaten gab es bei Ruby und Rails einige entscheidende Neuerungen. Ruby ist zum 20. Geburtstag in der Version 2 erschienen und Rails 4 liegt nun als Beta vor. Für mich Grund genug neben dem Vortrag auch die Beispiele anzupassen.
Unterlagen
Die Präsentation findet sich auf Speakerdeck und kann dort auch als PDF heruntergeladen werden.
Beispiele
Die grössere Beispielanwendung zu den Alltagsszenarien habe ich in Rails 4 Beta 1 neu erstellt. Die Aufgabenstellung ist noch dieselbe, die Entwicklungswerkzeuge sind aber um die hilfreichen Tools rund um die Fehlerbehandlung erweitert worden.
Vergleicht man die neue Beispielanwendung mit der für Rails 3.2 kann man so auch die Unterschiede (wie Strong Parameters) zwischen den Rails-Versionen sehen.
Weiterführende Informationen
Damit man sich die Links nicht aus den Folien zusammensuchen muss:
Webseiten & Tools
Tools für Windows
Podcasts & Videos
Bücher
- Seven Languages in Seven Weeks (Rezension)
- Programming Ruby 1.9 (Rezension)
- Practical Object-Oriented Design in Ruby (Rezension)
- Rails 4 in Action
- The Rails View (Rezension)
- Continuous Testing (Rezension)
In meinem Blog sind alle Beiträge zu Ruby & Rails mit dem Tag “Ruby“ versehen.
Danke
Als Abschluss möchte ich mich nochmals bei der .Net User Group Zentralschweiz und den Teilnehmern bedanken. Neben der grossen Teilnehmerzahl freuten mich besonders die guten Gespräche in der Pause und nach dem Vortrag. Ich finde es toll dass es auch in Luzern eine so vielfältige .Net User Group gibt.
Buch-Rezension zu “Practical Object-Oriented Design in Ruby”
Ein gutes Buch über objektorientiertes Design (OOD) zu finden ist nicht einfach. Obwohl sich viele Bücher diesem Thema widmen fehlt doch immer wieder etwas: Entweder ist das Buch so theoretisch das es keinen Bezug zur Praxis hat oder die notwendige Theorie fehlt.
“Practical Object-Oriented Design in Ruby” (kurz POODR) von Sandy Metz findet den Mittelweg zwischen Theorie und Praxis. In einer direkten Sprache wird man Schritt für Schritt an die Thematik OOD herangeführt.
Auch wenn die Beispiele in Ruby sind so ist dieses Buch auch für andere Sprachen sehr zu empfehlen – das benötigte Wissen über Ruby ist minimal und schnell erklärt.
Wozu OOD?
Sandy Metz definiert OOD als die Art und Weise wie man Code in einem Programm anordnet. OOD ist somit nicht nur etwas für Experten sondern betrifft jeden Programmierer. Denn jeder der Code schreibt beeinflusst dessen Design.
Design is more the art of preserving changeability than it is the act of achieving perfection.
Ob eine Erweiterung später einfach einzubauen ist hängt von den heute getroffenen Entscheidungen ab. Oft fehlt aber die Erfahrung und das Wissen wie sich Entscheidungen auswirken. Dieses Buch zeigt einem wie kleine Veränderungen die Erweiterbarkeit beeinflussen und was für Vor- und Nachteile die einzelnen Ansätze von OOD mitbringen. Dies ersetzt zwar nicht das Sammeln von eigenen Erfahrungen, bietet einem aber eine gute Ausgangslage um nicht alle Fehler selber machen zu müssen.
Einfache Beispiele
Nach all den Banken und Blogs kommen hier Fahrräder für die Beispiele zum Einsatz. Durch die Optimierung für E-Reader sind die Beispiele recht kurz. So lässt sich der Code übersichtlich darstellen und ist als Nebeneffekt einfach zu verstehen. Im Gegensatz zu anderen Büchern kann man sich so auf die Beispiele konzentrieren und muss nicht ständig hin und her blättern.
Das entscheidende bei den Beispielen ist der Weg zum Ziel. Daher gibt es entsprechend viele kleine Schritte die ausführlich erläutert werden. Allerdings führen nicht alle Schritte in die richtige Richtung. Umwege und falsche Ansätze werden in diesem Buch ebenfalls thematisiert und erklärt.
So kann man auf wenigen Seiten Erfahrungen sammeln die bei einem richtigen Projekt Monate an Arbeit verursachen.
Tests
Dem Thema Tests widmet sich das letzte Kapitel. Die in den vorherigen Kapiteln erarbeiteten Beispiele werden hier nun getestet. Man sieht so rasch wie die verschiedenen Ansätze von OOD sich auf die Testbarkeit von Code auswirken.
Sehr gelungen finde ich wie die Stolperfallen präsentiert werden. Der Mock für die Tests mag noch so gut sein. Wenn sich die Klasse ändert und der Mock dies nicht mitbekommt ist zwar der Test grün aber die Software läuft nicht. Die gezeigten Lösungen sind zwar auf dynamisch typisierte Programmiersprachen ausgerichtet, können aber auch bei C# beim Erkennen von Veränderungen helfen.
Was fehlt
Die gewählten Beispiele sind alle recht Kurz und meist weniger als 100 Zeilen lang. Auch wenn kurze Klassen und Methoden anzustreben sind so ist die Realität doch oft anderes. Ein längeres Beispiel bei dem man mittels OOD Ordnung hinein bringt hätte ich sehr begrüsst.
Weitere Informationen
Wer sich für OOD interessiert aber nicht gleich ein Buch dazu lesen will wird auf Confreaks fündig. Dort gibt es als Video abrufbare Präsentationen von Sani Metz die einzelne Konzepte aus dem Buch aufgegriffen.
Wer lieber Podcasts hört findet in Episode 87 von Ruby Rogues eine ausführliche Buchbesprechung mit zahlreichen Tipps rund um OOD die im Buch keinen Platz gefunden haben.
Fazit
POODR ist ein angenehm zu lesendes Buch das sehr viel Wissen vermittelt. Obwohl ich mich schon länger mit OOD beschäftige konnte ich hier ganz neue Aspekte kennen lernen. Die Beispiele sind so einfach das man davon nicht abgelenkt wird und doch komplex genug um all die verschiedenen Möglichkeiten zu erklären.
Für mich ist dieses Buch definitiv ein „Must Read“ für alle die sich mit Software-Entwicklung beschäftigen.
Zum Buch
“Practical Object-Oriented Design in Ruby” von Sandy Metz, 2012 Addison-Wesley Professional, ISBN: 978-0-3217-2133-4, 272 Seiten, Englisch
Das passende Gem finden
Für Ruby und Rails gibt es unzählige Helfer. Diese als Gem bezeichneten Pakete zu finden ist eine Herausforderung. Nicht weil es zu wenig Gems gibt, sondern weil so viele verschiedene Ansätze zur Auswahl stehen. Nicht nur für Einsteiger ist es schwer sich zu entscheiden. Soll man nun das nehmen was gerade “In” ist oder ist ein älteres Paket besser? Wie steht es um die Aktualität? Und wo findet man die Dokumentation?
Vor diesen Problemen stand auch Christoph Olszowka. Seine Lösung dazu war ein Verzeichnis zu starten bei dem die einzelnen Gems gesammelt und bewertet werden. Seit Ende 2011 ist diese Sammlung auf Ruby-Toolbox.com abrufbar.
Die Gems werden nach Thema gruppiert und mit anderen Vertretern der gleichen Kategorie verglichen. Die Balkengrafik zeigt einem auf einen Blick welche Gems in der gewählten Kategorie beliebt sind. Links zur Webseite, der Dokumentation und zum Bug Tracker helfen einem sich schnell ein eigenes Bild zu machen. Und da man auch gleich sieht wie aktiv daran entwickelt wird erspart man sich böse Überraschungen.
Mir gefällt neben der Übersichtlichkeit der Seite vor allem die Erklärung wie die Werte zustande kommen. Hier gibt es keine “magische” Blackbox die die Projekte bewertet, sondern eine Formel die man selber überprüfen kann.
Ruby-Toolbox.com ist für mich die Anlaufstelle wenn ich ein Gem für eine spezielle Aufgabe suche. Darüber hinaus ist es auch ein guter Platz um zu schauen wie vielfältig das Ruby-Ökosystem ist und was es alles für fertige Lösungen gibt.
Mein Tipp: Unbedingt anschauen!
Bessere Fehlermeldungen in Rails
Log- und Fehlermeldungen können eine wichtige Quelle zum Erkennen von Problemen sein. Allerdings nur wenn die Meldungen aussagekräftig sind und man diese auch findet. Beim Entwickeln einer Rails-Anwendung stösst man häufig auf 2 Probleme:
- Die wichtigen Meldungen gehen in der Flut von Asset Pipeline Informationen unter.
- Die Fehlerseite zeigt einem nicht die gewünschten Informationen an.
Für beide Probleme gibt es einfache Lösungen, die einem mit geringem Aufwand viel Zeit sparen können.
Logmeldungen der Asset Pipeline abschalten
So lange man in der Development-Umgebung ist haben die vielen Meldungen der Asset Pipeline keinen grossen Nutzen. Sie sind einem viel mehr nur im Weg und verdecken die wichtigen Meldungen. Oder wer erkennt bei diesem einfachen Seitenaufruf das wirkliche Problem?
Started GET "/items" for 127.0.0.1 at 2013-01-20 14:46:02 +0100 Processing by ItemsController#index as HTML Item Load (0.1ms) SELECT "items".* FROM "items" Rendered items/index.html.erb within layouts/application (2.0ms) Completed 200 OK in 83ms (Views: 36.7ms | ActiveRecord: 1.2ms) [2013-01-20 14:46:02] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true Started GET "/assets/application.css?body=1" for 127.0.0.1 at 2013-01-20 14:46:02 +0100 Served asset /application.css - 304 Not Modified (10ms) [2013-01-20 14:46:02] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true Started GET "/assets/jquery.js?body=1" for 127.0.0.1 at 2013-01-20 14:46:02 +0100 Served asset /jquery.js - 304 Not Modified (8ms) [2013-01-20 14:46:02] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true Started GET "/assets/jquery_ujs.js?body=1" for 127.0.0.1 at 2013-01-20 14:46:02 +0100 Served asset /jquery_ujs.js - 304 Not Modified (2ms) [2013-01-20 14:46:02] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true Started GET "/assets/items.css?body=1" for 127.0.0.1 at 2013-01-20 14:46:02 +0100 Served asset /items.css - 304 Not Modified (2ms) [2013-01-20 14:46:02] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true Started GET "/assets/scaffolds.css?body=1" for 127.0.0.1 at 2013-01-20 14:46:02 +0100 Served asset /scaffolds.css - 304 Not Modified (2ms) [2013-01-20 14:46:02] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true Started GET "/assets/items.js?body=1" for 127.0.0.1 at 2013-01-20 14:46:02 +0100 Served asset /items.js - 304 Not Modified (2ms) [2013-01-20 14:46:02] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true Started GET "/assets/application.js?body=1" for 127.0.0.1 at 2013-01-20 14:46:02 +0100 Served asset /application.js - 304 Not Modified (8ms) [2013-01-20 14:46:02] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true
Das Gem Quiet Assets stoppt diese Meldungsflut. Dazu genügt es das Gemfile um diesen Eintrag zu erweitern:
gem 'quiet_assets', :group => :development
Nach einem anschliessenden bundle und einem Neustart mittels rails s gibt der gleiche Seitenaufruf nur noch diese Meldungen aus:
Started GET "/items" for 127.0.0.1 at 2013-01-20 14:46:59 +0100 Connecting to database specified by database.yml Processing by ItemsController#index as HTML Item Load (0.1ms) SELECT "items".* FROM "items" Rendered items/index.html.erb within layouts/application (1.9ms) Completed 200 OK in 83ms (Views: 54.3ms | ActiveRecord: 1.2ms) [2013-01-20 14:46:59] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true [2013-01-20 14:46:59] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true [2013-01-20 14:46:59] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true [2013-01-20 14:46:59] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true [2013-01-20 14:46:59] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true [2013-01-20 14:46:59] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true [2013-01-20 14:46:59] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true [2013-01-20 14:46:59] WARN Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true
Nun sieht man auf den ersten Blick die Meldungen zu „content-length“ und kann dem nachgehen.
Bessere Fehlermeldungen
Beim Entwickeln passieren einem immer mal wieder Fehler. Leider hilft einem die mit Rails ausgelieferte Fehlerseite oft nicht wirklich weiter:
Das Gem Better Errors ersetzt diese Seite und liefert einem viele hilfreiche Zusatzinformationen. Die Installation erfolgt wie immer über einen Eintrag ins Gemfile:
gem 'better_errors', :group => :development
Nach dem Speichern ist auch hier bundle auszuführen bevor man mit rails s wiederum den Webserver neu startet. Der Aufruf der gleichen Seite führt nun zu dieser Ausgabe:
Die Fehlermeldung findet sich nun im schwarzen Balken am Seitenanfang. Zusätzlich wird die Stelle im Code angezeigt bei der das Problem aufgetreten ist. Fürs Auffinden von Problemen sind die aufgelisteten Request Parameter oft äusserst hilfreich – vor allem wenn die von einem Formular übermittelten Daten nicht gefunden werden können.
Aufräumen
Wenn man die beiden Gems oft zusammen braucht kann man diese in einer einzigen Gruppe zusammenfassen. Statt den beiden oben gezeigten Varianten sieht der Eintrag im Gemfile dann so aus:
group :development do gem 'quiet_assets' gem 'better_errors' end
Fazit
Die beiden Gems Quiet Assets und Better Errors finde ich mittlerweile unverzichtbar für die Entwicklung von Rails-Anwendungen. Ohne lange zu suchen gleich den richtigen Code-Ausschnitt zu sehen hilft mir die Fehlersuche deutlich zu beschleunigen. Und kann man die Warnungen bereits in der Entwicklung erkennen muss man die Fehler nicht erst in der Produktionsumgebung suchen.
Rails aktualisieren
Anfangs Januar 2013 gab es 2 kritische Sicherheitslücken die ein sofortiges Update auf die aktuellste Version von Rails verlangten. Wie aber geht man so etwas an und wie wird man überhaupt über eine neue Version informiert? Dier Eintrag liefert Antworten zu diesen und weiteren Fragen rund um die Aktualisierung einer Rails Anwendung.
Neue Version?
Informationen über neue Versionen findet man auf der offiziellen Webseite RubyOnRails.org. Wem es zu Aufwendig ist diese Seite regelmässig aufzurufen kann auch @Rails auf Twitter folgen oder Podcasts wie Ruby 5 hören. Durch die grosse Verbreitung informieren auch Newsportale wie Heise.de oder Golem.de jeweils sehr zeitnah über neue Versionen oder Probleme mit Rails.
Zu aktualisierende Pakete finden
Das Tool Bundler hilft einem nicht nur bei der Paketverwaltung und dem auflösen von Abhängigkeiten, sondern es bietet auch eine Möglichkeit um veraltete Pakete zu finden. Dazu wechselt man ins Verzeichnis seiner Rails-Anwendung und führt diesen Befehl aus:
bundle outdated Fetching gem metadata from https://rubygems.org/........... Fetching gem metadata from https://rubygems.org/.. Outdated gems included in the bundle: * activesupport (3.2.11 > 3.2.8) * builder (3.1.4 > 3.0.4) * activemodel (3.2.11 > 3.2.8) * sprockets (2.8.2 > 2.1.3) * actionpack (3.2.11 > 3.2.8) * mail (2.5.3 > 2.4.4) * actionmailer (3.2.11 > 3.2.8) * activerecord (3.2.11 > 3.2.8) * activeresource (3.2.11 > 3.2.8) * railties (3.2.11 > 3.2.8) * rails (3.2.11 > 3.2.8)
Pakete aktualisieren
Sollte Bundler nur wenige Gems melden genügt es diese einzeln zu aktualisieren. Dazu ersetzt man
[name] durch den entsprechende Paketnamen:
sudo gem update [name]
Alternativ kann man auch gleich alle auf dem System installierten Gems aktualisieren. Dazu genügt es beim Befehlsaufruf keinen Paketnamen zu nennen:
sudo gem update
Neue Versionen von Gems können inkompatible Änderungen enthalten. Wenn der Autor eines Gems einen entsprechenden Hinweis hinterlegt kann die Ausgabe des oberen Befehls so aussehen:
...
Fetching: paperclip-3.4.0.gem (100%)
##################################################
# NOTE FOR UPGRADING FROM PRE-3.0 VERSION #
##################################################
Paperclip 3.0 introduces a non-backward compatible change in your attachment
path. This will help to prevent attachment name clashes when you have
multiple attachments with the same name. If you didn't alter your
attachment's path and are using Paperclip's default, you'll have to add
`:path` and `:url` to your `has_attached_file` definition. For example:
has_attached_file :avatar,
:path => ":rails_root/public/system/:attachment/:id/:style/:filename",
:url => "/system/:attachment/:id/:style/:filename"
Successfully installed cocaine-0.4.2
Successfully installed paperclip-3.4.0
...
Hier wird von Paperclip auf ein neues Verhalten beim Ablageort von Anhängen hingewiesen. Diese Informationen helfen einem abzuschätzen ob man die neue Version gleich verwenden will oder ob grössere Umbauten nötig sind.
Wird so ein Hinweis nicht hinterlegt bleibt einem nur das (automatisierte) testen der Anwendung nach dem Update um allfällige Probleme zu finden.
Rails aktualisieren
Nachdem die Pakete aktualisiert sind öffnet man das Gemfile und sucht die von Bundler als veraltet markierten Gems:
source 'https://rubygems.org' gem 'rails', '3.2.8' # Bundle edge Rails instead: # gem 'rails', :git => 'git://github.com/rails/rails.git' gem 'sqlite3' # Gems used only for assets and not required # in production environments by default. group :assets do gem 'sass-rails', '~> 3.2.3' gem 'coffee-rails', '~> 3.2.1' # See https://github.com/sstephenson/execjs#readme for more supported runtimes gem 'therubyracer', :platforms => :ruby gem 'uglifier', '>= 1.0.3' end gem 'jquery-rails'
Um die neue Version von Rails zu nutzen ersetzt man die Version 3.2.8 durch 3.2.11:
gem 'rails', '3.2.11'
Nach dem gleichen Muster geht man bei den anderen Gems vor. Ist man damit durch empfiehlt sich nochmals mit Bundler die Pakete zu aktualisieren und nach veralteten Paketen zu suchen:
bundle update bundle outdated Fetching gem metadata from https://rubygems.org/........... Fetching gem metadata from https://rubygems.org/.. Outdated gems included in the bundle: * builder (3.1.4 > 3.0.4) * sprockets (2.8.2 > 2.2.2) * mail (2.5.3 > 2.4.4)
Da diese Gems nicht im Gemfile aufgeführt sind handelt es sich um Abhängigkeiten anderer Pakete. Im Gemfile.lock kann man nachschauen welche Pakete nach dieser Version verlangen. So lange diese Pakete nicht auf die neue Version wechseln müssen die älteren Versionen auf dem System bleiben (und werden von Bundler entsprechend angezeigt).
Allfällige Konfigurationsänderungen an Rails werden über den Rake-Task rails:update durchgeführt. Dies ist vor allem bei grösseren Versionswechseln (wie 3.1 auf 3.2) nötig. Es schadet aber nicht diesen Task bei jeder Aktualisierung auszuführen:
rake rails:update
Sollte es dabei zu Problemen kommen kann man mittels der Eingabe von h die Hilfe aufrufen und mit d einen Diff der Änderungen anzeigen.
Fazit
Ein Update von Rails lässt sich bei kleineren Versionswechseln recht schnell und ohne grosse Probleme durchführen. Ob noch alles wie gewünscht funktioniert kann aber nur ein eingehender Test zeigen. Eine automatisierte Testsuite kann einem auch in diesem Fall viel Arbeit abnehmen.
Flickr Photos
|
