Ruby Grundlagen

Installation ......................................................................................................................... 7 Vorbereitung des Systems ............................................................................................................................................... 7 Installation von Ruby mittels RVM .............................................................................................................................. 7 Installation von RVM .......................................................................................................................................................... 7 Installation von Ruby ......................................................................................................................................................... 8 Auswahl der Ruby-‐Version ............................................................................................................................................... 8 Update von RVM ................................................................................................................................................................... 8 Literaturempfehlungen .................................................................................................................................................... 9 Gratis ......................................................................................................................................................................................... 9 Editoren ................................................................................................................................................................................... 9 Editoren .................................................................................................................................................................................... 9 IDEs ............................................................................................................................................................................................ 9 Git Crashkurs .................................................................................................................... 10 Standard Workflow ......................................................................................................................................................... 10 Klonen des Repositories .................................................................................................................................................. 10 Updaten des Repositories .............................................................................................................................................. 10 Hinzufügen und Löschen von Dateien ...................................................................................................................... 10 ................................................................................................................................................................................... 11 Commit Einspielen der Änderungen ........................................................................................................................................... 11 Branching ............................................................................................................................................................................. 11 Literaturempfehlungen ................................................................................................................................................. 11 Gratis ...................................................................................................................................................................................... 11 Ruby Basics ...................................................................................................................... 12 Variablen .............................................................................................................................................................................. 12 Typisierung .......................................................................................................................................................................... 12 Variablentypen und –namen ........................................................................................................................................ 12 Mathematische Funktionen ......................................................................................................................................... 13 Standardoperationen ...................................................................................................................................................... 13 Weitere Funktionen ......................................................................................................................................................... 13 Strings (Zeichenketten) ................................................................................................................................................. 14 Deklaration .......................................................................................................................................................................... 14 Informationen über einen String ............................................................................................................................... 14 Veränderung eines Strings ............................................................................................................................................ 15 Type Casting ........................................................................................................................................................................ 15 Methoden ............................................................................................................................................................................. 15 Deklaration und Verwendung ..................................................................................................................................... 15 © 2011, Julian Fischer und Clemens Kofler

Query-‐/Predicate-‐Methoden ........................................................................................................................................ 16 Arrays (sortierte Listen) ............................................................................................................................................... 16 Deklaration .......................................................................................................................................................................... 16 Zugriff auf Elemente ........................................................................................................................................................ 17 Informationen über Arrays ........................................................................................................................................... 17 Transformationen ............................................................................................................................................................. 17 Set-‐Operationen ................................................................................................................................................................. 18 Queue-‐/Stack-‐Operationen ........................................................................................................................................... 18 Weitere Anwendungsfälle ............................................................................................................................................. 18 .................................................................................................................................. 18 Hashes (Schlüssel-‐Wert-‐Paare) Deklaration .......................................................................................................................................................................... 19 Zugriff auf Elemente ........................................................................................................................................................ 19 Informationen über Hashes .......................................................................................................................................... 19 Transformation .................................................................................................................................................................. 20 Symbole ................................................................................................................................................................................ 20 Enumerable ......................................................................................................................................................................... 21 ............................................................................................................................................................. 21 Häufige Methoden Minimum und Maximum ................................................................................................................................................ 22 Informationen über Enumerable ............................................................................................................................... 22 Sortiertung ........................................................................................................................................................................... 22 Verwendung von externen Iteratoren ...................................................................................................................... 23 lambdas, procs und Blöcke ........................................................................................................................................... 23 Deklaration und Verwendung ..................................................................................................................................... 23 Blöcke ..................................................................................................................................................................................... 24 Kontrollstrukturen .......................................................................................................................................................... 25 Boolsche Operatoren ....................................................................................................................................................... 25 Conditionals (if, else etc.) ............................................................................................................................................... 25 case/when ............................................................................................................................................................................ 26 Loops (for, while etc.) ...................................................................................................................................................... 27 Literaturempfehlungen ................................................................................................................................................. 27 Gratis ...................................................................................................................................................................................... 27 Kostenpflichtig ................................................................................................................................................................... 27 Standard-‐Library und Gems .............................................................................................. 29 Standard-‐Library .............................................................................................................................................................. 29 Verwendung ........................................................................................................................................................................ 29 Verfügbare Pakete ............................................................................................................................................................ 29 © 2011, Julian Fischer und Clemens Kofler

Status der Standard-‐Library ........................................................................................................................................ 29 Gems ....................................................................................................................................................................................... 29 Verwendung ........................................................................................................................................................................ 30 Verfügbare Pakete ............................................................................................................................................................ 30 ............................................................................................................................................... 30 Auswahl passender Gems Empfohlene Gems .............................................................................................................................................................. 30 Bundler ................................................................................................................................................................................. 33 Literaturempfehlungen ................................................................................................................................................. 33 Gratis ...................................................................................................................................................................................... 33 Objektorientierte Programmierung mit Ruby – Grundlagen ............................................. 34 Klassen und Instanzen ................................................................................................................................................... 34 Methoden ............................................................................................................................................................................. 34 Instanzmethoden .............................................................................................................................................................. 34 Klassenmethoden .............................................................................................................................................................. 35 Hash-‐Parameter ................................................................................................................................................................ 35 Multi-‐Parameter ................................................................................................................................................................ 35 Variablen .............................................................................................................................................................................. 36 Instanzvariablen ............................................................................................................................................................... 36 .............................................................................................................................................................................. 36 Accessors Access Control (Zugriffskontrolle) ........................................................................................................................... 38 Vererbung ............................................................................................................................................................................ 38 Methoden .............................................................................................................................................................................. 39 super ....................................................................................................................................................................................... 39 Literaturempfehlungen ................................................................................................................................................. 40 Gratis ...................................................................................................................................................................................... 40 Objektorientierte Programmierung mit Ruby – Fortgeschrittene Themen ........................ 41 Ruby Objektmodell .......................................................................................................................................................... 41 Klassenhierarchien ........................................................................................................................................................... 41 Module ................................................................................................................................................................................... 41 Methoden ............................................................................................................................................................................. 43 Messages und Receiver ................................................................................................................................................... 43 self ............................................................................................................................................................................................ 44 Duck Typing ........................................................................................................................................................................ 44 Interne und externe APIs .............................................................................................................................................. 46 ................................................................................................................... 46 Zugriff auf die interne API mittels send Wann sollte man send nicht verwenden? ............................................................................................................... 46 © 2011, Julian Fischer und Clemens Kofler

Monkeypatching ............................................................................................................................................................... 47 ActiveSupport ..................................................................................................................................................................... 47 Metaprogramming ........................................................................................................................................................... 49 .................................................................................................................................... 49 Methoden dynamisch erstellen method_missing ................................................................................................................................................................. 50 Weitere Hooks .................................................................................................................................................................... 53 Literaturempfehlungen ................................................................................................................................................. 53 Gratis ...................................................................................................................................................................................... 53 Kostenpflichtig ................................................................................................................................................................... 54 Webservices mit Ruby ...................................................................................................... 55 REST-‐Grundlagen ............................................................................................................................................................. 55 Gängige Anwendungsfälle ............................................................................................................................................. 56 Sinatra ................................................................................................................................................................................... 56 Installation ........................................................................................................................................................................... 56 Hello World .......................................................................................................................................................................... 56 Beispiel: Einfacher Kontaktmanager ....................................................................................................................... 57 Beispiel: Einfacher Kontaktmanager mit Datenbank ....................................................................................... 58 Beispiel: Content Type Negotiation ........................................................................................................................... 61 Rails ........................................................................................................................................................................................ 62 Konsumieren eines REST-‐Webservice .................................................................................................................... 64 ActiveResource ................................................................................................................................................................... 64 RestClient .............................................................................................................................................................................. 65 Literaturempfehlungen ................................................................................................................................................. 66 Gratis ...................................................................................................................................................................................... 66 Kostenpflichtig ................................................................................................................................................................... 66 Integration Testing mit Cucumber und Capybara .............................................................. 67 Integration Testing .......................................................................................................................................................... 67 Cucumber ............................................................................................................................................................................. 67 ....................................................................................................................................................................... 67 Einsatzgebiet Installation ........................................................................................................................................................................... 68 Konfiguration ..................................................................................................................................................................... 68 Struktur ................................................................................................................................................................................. 68 Beispiel ................................................................................................................................................................................... 69 Backgrounds ....................................................................................................................................................................... 69 .......................................................................................................................................................... 70 Ausführen der Tests Implementierung der Schritte ..................................................................................................................................... 70 © 2011, Julian Fischer und Clemens Kofler

Capybara .............................................................................................................................................................................. 70 ....................................................................................................................................................................... 70 Einsatzgebiet Installation ........................................................................................................................................................................... 71 Konfiguration ..................................................................................................................................................................... 71 Adapter .................................................................................................................................................................................. 71 Kommandos ......................................................................................................................................................................... 71 Literaturempfehlungen ................................................................................................................................................. 72 Gratis ...................................................................................................................................................................................... 72 Kostenpflichtig ................................................................................................................................................................... 72 Deployment mit Capistrano ............................................................................................. 73 Grundlagen .......................................................................................................................................................................... 73 Funktionsweise ................................................................................................................................................................... 73 Voraussetzungen ............................................................................................................................................................... 73 Setup ....................................................................................................................................................................................... 73 Anatomie eines Capistrano-‐Setups ............................................................................................................................ 74 Minimalkonfiguration ..................................................................................................................................................... 74 ........................................................................................................................................................... 75 Erstes Deployment Vorbereitung der Server ................................................................................................................................................ 75 Applikationsspezifisches Setup ................................................................................................................................... 75 Deployment .......................................................................................................................................................................... 76 Weiterführende Themen ............................................................................................................................................... 76 Definition eigener Tasks ................................................................................................................................................ 76 Handhabung von sensiblen Daten ............................................................................................................................. 77 Persistenz über Deployments ....................................................................................................................................... 78 Literaturempfehlungen ................................................................................................................................................. 79 Gratis ...................................................................................................................................................................................... 79 Kostenpflichtig ................................................................................................................................................................... 79 © 2011, Julian Fischer und Clemens Kofler

Installation In diesem Kapitel wird das Setup einer Ruby-‐Entwicklungsumgebung unter Linux (z.B. Ubuntu) beschrieben. Vorbereitung des Systems Zunächst müssen, sofern nicht bereits vorhanden, einige Bibliotheken installiert werden: apt-get install build-essential openssl libreadline6libreadline6-dev curl git-core zlib1g zlib1g-dev libssl-devlibyaml-dev libxml2-dev libxslt-dev autoconf libc6-devncurses-dev automake libtool bison subversionJe nachdem, welche Datenbanksysteme verwendet werden sollen, müssen auch hierfür noch Bibliotheken installiert werden: apt-get libsqlite3-0 libsqlite3-dev sqlite3apt-get install libmysqlclient16-devapt-get install libpq-devInstallation von Ruby mittels RVM Der Ruby Version Manager (RVM) wird ist ein beliebtes Werkzeug, um verschiedene Versionen von Ruby auf demselben System zu betreiben. Dies ist beispielsweise notwendig, wenn in verschiedenen Projekten verschiedene Versionen von Ruby im Einsatz sind. Installation von RVM RVM bietet ein automatisches Installationsskript, das via bash und curl direkt installiert werden kann: bash < <(curl -shttps://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )Außerdem muss RVM in bash_profile geladen werden: echo [[ -s "$HOME/.rvm/scripts/rvm" ]] && ."$HOME/.rvm/scripts/rvm" # Load RVM function >>~/.bash_profilesource ~/.bash_profile© 2011, Julian Fischer und Clemens Kofler

Hinweis: Bei Verwendung einer anderen Shell muss ggf. eine andere Konfigurationsdatei bearbeitet werden. Installation von Ruby RVM bietet eine Funktion, die alle verfügbaren Ruby-‐Versionen anzeigt: rvm list knownMit folgendem Kommando kann anschließend die gewünschte Version installiert werden (Beispiel 1.9.3-‐p0): rvm install 1.9.3-p0Auswahl der Ruby-‐Version Um eine bestimmte Version von Ruby zu aktivieren, wird rvm use verwendet: rvm use 1.9.3Die gewählte Version gilt nur in der aktuellen Konsolensitzung, d.h. alle weiteren Sitzungen behalten die vom System definierte Standardversion von Ruby. Um eine andere Version als Standards zu setzen, kann rvm use mit dem Flag --default aufgerufen werden: rvm use 1.9.3 --defaultProjektspezifische Konfiguration RVM unterstützt projektspezifische Konfigurationen. Dazu muss eine Datei namens .rvmrc im Verzeichnis des jeweiligen Projekts angelegt werden. Beim Wechsel in dieses Verzeichnis führt RVM automatisch diese Datei aus. So kann z.B. die Ruby-‐Version jedes einzelnen Projekts in der jeweiligen .rvmrc Datei definiert werden. rvm use 1.9.3Update von RVM RVM sollte häufig geupdatet werden, um stets Zugriff auf die neuesten Releases der einzelnen Ruby-‐Versionen zu haben. rvm get headrvm get stablervm get 1.9.2© 2011, Julian Fischer und Clemens Kofler

Literaturempfehlungen Gratis https://rvm.beginrescueend.com/ http://screencasts.org/episodes/how-‐to-‐use-‐rvm http://ryanbigg.com/2010/12/ubuntu-‐ruby-‐rvm-‐rails-‐and-‐you/ Editoren Die meisten gängigen Editoren unterstützen Ruby ab Werk oder bieten Erweiterungen für Ruby an. Hier bieten wir eine unvollständige Liste von Editoren, die wir bereits im Einsatz mit Ruby gesehen haben. Editoren TextMate: http://macromates.com/ (Mac OS X) vim: http://www.vim.org/ emacs: http://www.gnu.org/s/emacs/ redcar: http://redcareditor.com/ jEdit: http://jedit.org/ gedit (gmate: https://github.com/gmate/gmate) e Text Editor: http://e-‐texteditor.com/ IDEs RubyMine: http://www.jetbrains.com/ruby/ RadRails: http://aptana.com/products/radrails Aptana Studio: http://aptana.com/products/studio3 NetBeans: http://netbeans.org/ (Ruby Plugin: http://plugins.netbeans.org/plugin/38549/ruby-‐and-‐rails) © 2011, Julian Fischer und Clemens Kofler

Git Crashkurs Git ist ein mächtiges Versionskontrollsystem. In diesem Abschnitt soll eine kurze Übersicht über den wichtigsten Workflow gegeben werden. Details und tiefer gehende Themen können im gratis eBook “Pro Git” nachgelesen werden. Standard Workflow Klonen des Repositories Das erste Auschecken des Repositories erfolgt mittels git clone: git clone git://url/pathDabei werden sämtliche Daten des Repositories (inkl. Branches und Tags) auf die locale Maschine kopiert. Updaten des Repositories Um die neuesten Updates aus dem Repository zu erhalten, wird git pull verwendet: git pullDabei werden etwaige Änderungen mit lokalen Änderungen zusammengeführt (merge), wobei es zu Konflikten kommen kann. Häufig können Konflikte vermieden werden, indem git pull mit dem Flag --rebase verwendet wird: git pull --rebaseHier nimmt Git zunächst alle lokalen Änderungen seit dem letzten Update zurück, spielt das Update vom Server ein (fast forward) und fügt anschließend die lokalen Änderungen wieder einzeln hinzu. Wenn eine der lokalen Änderungen einen Konflikt auslöst, kann dieser behoben werden, was üblicherweise einfacher ist, als alle Konflikte auf einmal zu beheben. Hinzufügen und Löschen von Dateien Um Dateien für den nächsten Commit hinzuzufügen, wird git add verwendet: git add READMEgit rm wird zum Löschen verwendet: git rm README© 2011, Julian Fischer und Clemens Kofler

Commit Im Gegensatz zu anderen Versionskontrollsystemen wie z.B. Subversion erfolgt ein Commit in Git lokal, d.h. die Änderungen werden nicht sofort am Server abgelegt. Das notwendige Kommando heißt git commit und wird üblicherweise zusammen mit dem Modifikator -m (Message) verwendet: git commit -m I made a changeEinspielen der Änderungen Um die Änderungen auf dem Server einzuspielen, wird git push verwendet: git pushDieses Kommando funktioniert nur, wenn lokal die aktuellste Version des Servers vorhanden ist – man sagt, der Branch ist “fast forwardable”. Branching Das Branching-‐Modell von Git ist wohl am leichtesten anhand des Git Flow Workflow zu verstehen. Details und Illustrationen finden sich im entsprechenden Blogpost: http://nvie.com/posts/a-‐successful-‐git-‐branching-‐model/. Literaturempfehlungen Gratis http://progit.org/ (Pro Git; auch als gedrucktes Buch erhältlich) http://yehudakatz.com/2010/05/13/common-‐git-‐workflows/ http://nvie.com/posts/a-‐successful-‐git-‐branching-‐model/ © 2011, Julian Fischer und Clemens Kofler

Ruby Basics Variablen Typisierung In Ruby ist, im Gegensatz zu Java und anderen strenger typisierten Sprachen, weder eine Deklaration noch eine Typdefintion notwendig. Die Festlegung des Typs erfolgt bei der Initialisierung. a = 5 # a ist nun eine Ganzzahl mit dem Wert 5s = “Hallo Welt” # s ist nun eine ZeichenketteDa kein Typ festgelegt wird, kann sich der Typ einer Variable bei Bedarf ändern. a = 5 # a ist nun eine Ganzzahl mit dem Wert 5a = “Hallo Welt” # a ist nun eine ZeichenketteVariablentypen und –namen Ruby unterscheidet verschiedene Typen von Variablen: • Lokale Variablen: Der Name beginnt mit einem Kleinbuchstaben. • Globale Variablen: Der Name beginnt mit $. • Konstanten: Der Name beginnt mit einem Großbuchstaben. • Instanzvariablen: Der Name beginnt mit @. • Klassenvariablen: Der Name beginnt mit @@. Abgesehen von den erwähnten Regeln überlässt Ruby die Benennung der Variablen dem Programmierer. In der Ruby-‐Community gibt es einige Konventionen, die befolgt werden sollten, um die Lesbarkeit des eigenen Codes für andere Programmierer zu verbessern: • Lokale Variablen sowie Instanz-‐ und Klassenvariablen werden im snake_case geschrieben, d.h. einzelne Wörter werden klein geschrieben und durch einen Unterstrich (_) getrennt. • Konstanten und globale Variablen werden im UPPER_SNAKE_CASE geschrieben, d.h. einzelne Wörter werden groß geschrieben und durch einen Unterstrich (_) getrennt. • Klassennamen bilden einen Sonderfall: Obwohl sie streng genommen Konstanten sind, werden sie üblicherweise im CamelCase geschrieben, d.h. einzelne Wörter © 2011, Julian Fischer und Clemens Kofler

werden haben einen großen Anfangsbuchstaben und werden ohne Trennzeichen aneinander gekettet. • Umlaute und ähnliche Sonderzeichen sind zwar möglich, sollten aber vermieden werden. • Englische Variablennamen werden bevorzugt. Mathematische Funktionen Rubys mathematische Funktionen sind weitgehend ähnlich, wie sie auch in Java, C++ etc. zu finden sind. Standardoperationen puts 4 + 1 # => 5puts 4 - 1 # => 3puts 4 * 2 # => 8puts 4 / 2 # => 2Wie auch in anderen Sprachen wird der Typ automatisch auf Fließkomma angepasst, wenn ein Operand mit Fließkommatyp in der Berechnung verwendet wird: puts 4 + 0.5 # => 4.5puts 4 * 1.5 # => 6.0puts 4 / 3 # => 1puts 4 / 3.0 # => 1.33333333333333Mathematische Grundregeln wie „Punkt vor Strich“ werden befolgt: puts 4 + 2 * 3 # => 10puts (4 + 2) * 3 # => 18Weitere Funktionen Das Math-‐Modul bietet komplexere mathematische Funktionen wie z.B. trigonometrische Funktionen (sin, cos etc.), Wurzeln (sqrt), Logarithmen (log, log2, log10, exp) etc. puts Math.sqrt(9) # => 3.0puts Math.log10(100) # => 2.0Außerdem bietet das Math-‐Modul die Konstanten PI und E. © 2011, Julian Fischer und Clemens Kofler

Strings (Zeichenketten) Deklaration Strings können in Ruby single-‐ oder double-‐quoted sein. Hallo Welt # => single-quoted"Hallo Welt" # => double-quotedDie beiden Varianten unterscheiden sich lediglich beim Interpolationsverhalten: Ein double-‐quoted String kann Variablen interpolieren, ein single-‐quoted String jedoch nicht: lang = "Java"puts "Sprache: #{lang}" # => Sprache: Javaputs Sprache: #{lang} # => Sprache: #{lang}Quotes müssen ggf. escapet werden: puts "Ich sage: "Hallo Welt""puts Ich sage: Hallo WeltFolgende Varianten können verwendet werden, um auf Escaping zu verzichten: puts %(Ich sage: "Hallo Welt") # dasselbe wie %Qputs %Q(Ich sage: "Hallo Welt") # double-quotedputs %q(Ich sage: Hallo Welt) # single-quotedWeiters kennt Ruby die Heredoc-‐Notation: poem = <<POEMWer reitet so spät durch Nacht und Wind?Es ist der Vater mit seinem Kind.POEMputs poemHinweis: Wenn dem Begrenzer ein -‐ vorangestellt wird, kann der End-‐Begrenzer beliebig eingerückt werden. Informationen über einen String lang = Javaputs lang.length # => 4puts lang.include?(e) # => falseputs lang.index(a) # => 1© 2011, Julian Fischer und Clemens Kofler

Veränderung eines Strings puts lang + Script # => JavaScriptputs lang.capitalize # => Javaputs lang.downcase # => javaputs lang.upcase # => JAVAputs lang.reverse # => avaJputs lang.gsub(a, i) # => JiviBei diesen Operationen wird ein neuer String erzeugt – der originale String wird dabei nicht verändert. Es gibt jeweils “destruktive” Operationen, die den originalen String verändern: lang << Scriptputs lang # => JavaScriptlang.downcase!puts lang # => javascriptlang.reverse!puts lang # => tpircsavajlang.gsub!(a, i)puts lang # => tpircsivij Type Casting Ein String kann in andere Typen umgewandelt werden, wenn er entsprechend formatiert ist: puts 1.9.to_f # => 1.9puts 1.to_i # => 1puts 1.9.to_i # => 1Methoden Methoden werden verwendet, um Funktionalität zu kapseln. Deklaration und Verwendung Im Gegensatz zu Java ist es in Ruby nicht notwendig (und nicht möglich), Parameter und Rückgabewerte zu typisieren. Wie auch bei Variablen werden die Typen automatisch festgelegt. def multiply(a, b)© 2011, Julian Fischer und Clemens Kofler

a * bendputs multiply(4, 3) # => 12Query-‐/Predicate-‐Methoden Als Query-‐ oder Predicate-‐Methoden werden Methoden bezeichnet, die mit einem Fragezeichen (?) enden. Diese Methoden geben per Konvention einen Boolean-‐Typen (true oder false) zurück. lang = Javaputs lang.include?(a) # => trueputs lang.include?(i) # => falseBang-‐Methoden Als Bang-‐Methoden werden Methoden bezeichnet, die mit einem Rufzeichen (!) enden. Die Bang-‐Methode zeigt üblicherweise an, dass die “normale” Methode (= ohne !) mit zusätzlichen Effekten ausgeführt wird. lang = Javalang.upcase # verändert das Original nichtputs lang # => Javalang.upcase! # verändert das Originalputs lang # => JAVA# in ActiveRecord wird versucht, eine Person anzulegenPerson.create # => im Fehlerfall wird false zurückgegebenPerson.create! # => im Fehlerfall wird eine Exception geworfenArrays (sortierte Listen) Ararys sind sortierte Listen von Elementen. Deklaration Arrays werden mit einer Literal-‐Syntax deklariert. Die Größe des Arrays wird automatisch bestimmt und erweitert und muss daher nicht explizit angegeben werden. numbers = [1, 3, 3, 7]p numbers # => [1, 3, 3, 7]languages = [Java, Ruby]© 2011, Julian Fischer und Clemens Kofler

p languages # => ["Java", "Ruby"]Aufgrund der dynamischen Typisierung kann ein Array in Ruby Elemente beliebiger verschiedener Typen enthalten (vgl. untypisierte ArrayList in Java). mixed = [1, Java, 2, Ruby]p mixed # => [1, "Java", 2, "Ruby"]String Arrays können mit einer alternativen Literal-‐Syntax deklariert werden: languages = %w(Java Ruby)p languages # => ["Java", "Ruby"]script = Scriptlanguages = %W(Java#{script} Ruby)p languages # => ["JavaScript", "Ruby"]Zugriff auf Elemente Arrays sind mit Ganzzahlen indexiert. Die Indexierung beginnt wie in vielen anderen Sprachen mit 0. Der Zugriff auf ein nicht existierendes Element gibt nil zurück. Ein negativer Index beginnt vom Ende des Arrays. languages = [Java, Ruby]p languages[1] # => "Ruby"p languages[2] # => nilp languages[-1] # => "Ruby"Das Schreiben von Werten funktioniert ähnlich: languages[0] = JavaScriptp languages # => ["JavaScript", "Ruby"]languages[2] = C#p languages # => ["JavaScript", "Ruby", "C#"]Informationen über Arrays languages = [Java, Ruby, C#]puts languages.length # => 3puts languages.empty? # => falseputs languages.index(C#) # => 1Transformationen p [[Java, C#], [Ruby, JavaScript]].flatten# => ["Java", "C#", "Ruby", "JavaScript"]© 2011, Julian Fischer und Clemens Kofler

puts [Java, C#, Ruby, JavaScript].join(, )# => Java, C#, Ruby, JavaScriptp ["Java", "Ruby", "Java"].uniq # => ["Java", "Ruby"]Set-‐Operationen Arrays in Ruby unterstützen gängige Set-‐Operationen wie Schnitt (intersect), Vereinigung (union), Ausschuss (diff) und Addition. p ["Java", "Ruby"] & ["Ruby", "JavaScript"]# => ["Ruby"]p ["Java", "Ruby"] | ["Ruby", "JavaScript"]# => ["Java", "Ruby", "JavaScript"]p ["Java", "Ruby"] + ["Ruby", "JavaScript"]# => ["Java", "Ruby", "Ruby", "JavaScript"]p ["Java", "Ruby"] - ["Java", "JavaScript"]# => ["Ruby"]Queue-‐/Stack-‐Operationen Arrays können wie Queues/Stacks verwendet werden. languages = [Ruby]languages.unshift(Java)p languages # => ["Java", "Ruby"]languages.push(C#)p languages # => ["Java", "Ruby", "C#"]puts languages.shift # => Javap languages # => ["Ruby", "C#"]puts languages.pop # => C#p languages # => ["Ruby"]Weitere Anwendungsfälle Für weitere Anwendungsfälle bietet die Ruby Standard Library die Klassen Set und SortedSet, die jeweils Duplikate verhindert. Hashes (Schlüssel-‐Wert-‐Paare) Hashes sind Schlüssel-‐Wert-‐Paare. Sie werden besonders gern für Parameterlisten verwendet, wo die Reihenfolge der Parameter keine Rolle spielt. © 2011, Julian Fischer und Clemens Kofler

Deklaration Hashes werden mit einer Literal-‐Syntax deklariert. hash = { a => 100, b => 50, c => 10 }p hash # => {"a"=>100, "b"=>50, "c"=>10}Aufgrund der dynamischen Typisierung kann ein Array in Ruby Elemente beliebiger verschiedener Typen enthalten. hash = { a => 100, b => Hallo Welt }p hash # => {"a"=>100, "b"=>"Hallo Welt"}Obwohl theoretisch jedes Objekt als Key verwendet werden kann, werden in der Regel Strings oder Symbole (mehr dazu später) verwendet. Hashes können auch direkt aus Name-‐Wert-‐Paaren erzeugt werden: p Hash[a, 100, b, 50] # => {"a"=>100, "b"=>50}p Hash[[[a, 100], [b, 50]]] # => {"a"=>100, "b"=>50}Zugriff auf Elemente Der Zugriff auf Hash-‐Elemente erfolgt auf dieselbe Art wie bei Arrays: hash = { a => 100, b => 50, c => 10 }puts hash[a] # => 100Es können auch mehrere Werte auf einmal ausgelesen werden: p hash.values_at(c, a) # => [10, 200]Ein Ausschnitt eines Hashes kann wie folgt erzeugt werden: p hash.slice (a, c) # => {"a"=>100, "c"=>10}Wie bei Arrays erzeugt ein Zugriff auf ein nicht existierendes Element keinen Fehler, sondern gibt nil zurück. puts hash[d] # => nilDas Setzen eines Wertes erfolgt ebenfalls auf dieselbe Art wie bei Arrays: hash[a] = 200puts hash[a] # => 200Informationen über Hashes p hash.keys # => ["a", "b", "c"]puts hash.size # => 3© 2011, Julian Fischer und Clemens Kofler

puts hash.empty? # => falseputs hash.has_key?(b) # => trueputs hash.has_value?(500) # => falseTransformation p hash.invert # => {50=>"b", 200=>"a", 10=>"c"}p hash.to_a # => [["a", 200], ["b", 50], ["c", 10]]puts hash.delete(a) # => 200p hash # => {"b"=>50, "c"=>10}p hash.merge(a => 50) # => {"a"=>50, "b"=>50, "c"=>10}p hash # => {"b"=>50, "c"=>10}Hinweis: merge verändert den originalen Hash nicht. Um den originalen Hash direkt zu verändern, kann die Bang-‐Variante (merge!) verwendet werden. Symbole Symbole sind benannte Literale, die an einer speziellen Stelle im Speicher, der so genannten symbol table, abgelegt sind. Sie sind durch einen führenden Doppelpunkt (:) gekennzeichnet. Im Gegensatz zu Strings behält ein Symbol stets seine Speicheradresse und ist daher immer “identisch”. puts Test.object_id # => 2152459300puts Test.object_id # => 2152449720puts :test.object_id # => 144328puts :test.object_id # => 144328Verwendung von Symbolen Symbole werden hauptsächlich als Keys für Hashes verwendet: hash = { :a => 1, :b => 2 }puts hash[:a] # => 1Außerdem dienen sie häufig als Ersatz für (Integer-‐)Konstanten. NORTH = 1EAST = 2SOUTH = 3© 2011, Julian Fischer und Clemens Kofler

WEST = 4def move(direction) if direction == NORTH moveNorth # ... endendmove(NORTH)Dieser Code wird in Ruby tendenziell so geschrieben: def move(direction) if direction == :north moveNorth # ... endendmove(:north)Enumerable Enumerable ist ein Modul bzw. Mixin (vgl. Interface in Java), das verschiedene Iterator-‐Methoden zur Verfügung stellt. Jede Klasse, die “enumerable” sein will, muss eine Methode Names each bereitstellen. Die Klassen Array und Hash verwenden Enumerable: numbers = [50, 40, 30, 20, 10]numbers.each { |n| puts n }hash = { a => 100, b => 50, c => 10 }hash.each { |key, value| puts "#{key}: #{value}" }numbers.each_with_index { |n, i| puts "#{i}: #{n}" }Häufige Methoden • map (Alias: collect): wendet den übergebenen Block auf jedes Element an • select (Alias: find_all): selektiert alle Elemente, für die der übergebene Block true zurück gibt © 2011, Julian Fischer und Clemens Kofler

• reject: selektiert alle Elemente, für die der übergebene Block false zurück gibt • detect (Alias: find): gibt das erste Element zurück, für das der übergebene Block true zurück gibt (nil, wenn keines gefunden wird) p numbers.map { |n| n * 2 } # => [100, 80, 60, 40, 20]p numbers.select { |n| n < 25 } # => [20, 10]p numbers.reject { |n| n < 25 } # => [50, 40, 20]puts numbers.detect { |n| n < 25 } # => 20Minimum und Maximum numbers = [50, 40, 30, 20, 10]puts numbers.min # => 10puts numbers.max # => 50p numbers.minmax # => [10, 50]languages = [Java, Ruby, C#]puts languages.max # => Rubyputs languages.min { |l1, l2| l1.length <=> l2.length } # =>C#puts languages.min_by { |language| language.length } # => C#Informationen über Enumerable p numbers.any? { |n| n > 100 } # => falsep numbers.none? { |n| n > 100 } # => truep numbers.all? { |n| n < 100 } # => truep numbers.one? { |n| n >= 50 } # => trueSortiertung Auch Sortierung ist Teil des Enumerable Mixins. p numbers.sort# => [10, 20, 30, 40, 50]p hash.sort_by { |k, v| v }# => [["c", 10], ["b", 50], ["a", 100]]Hinweis: Beide Sortierungsfunktionen verändern das originale Objekt nicht. Wenn das originale Objekt direkt sortiert werden soll, gibt es jeweils destruktive Bang-‐Methoden dafür (sort! bzw. sort_by!). © 2011, Julian Fischer und Clemens Kofler

Verwendung von externen Iteratoren Es ist möglich, eigenständige (externe) Iterator-‐Objekte zu verwenden, die ähnlich wie Iteratoren in Java funktionieren. Dazu wird der gewünschte Iterator ohne Block aufgerufen. enumerator = [1, 2, 3].eachputs enumerator.next # => 1Diese Variante wird jedoch eher selten verwendet. lambdas, procs und Blöcke lambdas und procs sind Blöcke von Code, die als Objekte durchgereicht und dynamisch ausgeführt werden können. Am ehesten sind sie mit Callback-‐Funktionen in JavaScript und anonymen inneren Klassen in Java (z.B. ActionListener) zu vergleichen. Deklaration und Verwendung greeter = proc { |name| "Hallo #{name}" }puts greeter.call("Matz") # => "Hallo Matz"Wie bereits erwähnt, sind procs Objekte und können z.B. als Parameter an Methoden übergeben und dort mittels call aufgerufen werden: def output_greeting(greeter_proc, name) puts greeter_proc.call(name)endoutput_greeting(greeter, "Matz") # => "Hallo Matz"lambdas unterscheiden sich von procs dadurch, dass die Parameter eines lambda verpflichtend sind: a_proc = proc { |a| puts "a: #{a}" }a_proc.call(1) # => a: 1a_proc.call(1, 2) # => a: 1a_proc.call # => a:a_lambda = lambda { |a| puts "a: #{a}" }a_lambda.call(1) # => a: 1a_lambda.call(1, 2)# => wrong number of arguments (2 for 1) (ArgumentError)a_lambda.call© 2011, Julian Fischer und Clemens Kofler

# => wrong number of arguments (0 for 1) (ArgumentError)Blöcke Methoden können optional einen Parameter als so genannten Block entgegen nehmen. Ein Beispiel sind Iteratoren. numbers = [1, 2, 3]numbers.each { |n| puts n }Der Abschnitt { |n| puts n } wird dabei als Block bezeichnet und wird für jedes Element des Arrays aufgerufen. Weitere Beispiele: # ohne Blockf = File.open(/Users/clemenskofler/test.txt)puts f.readf.close# mit Block: Ruby öffnet die Datei, lässt uns damit arbeitenund kümmert sich automatisch um das Schließen der DateiFile.open(/Users/clemenskofler/test.txt) { |f| puts f.read }Man kann auch selbst Methoden mit Block-‐Parametern definieren. def handle_file(file, &block) f = File.open(file) block.call(f) f.closeendfile = /Users/clemenskofler/test.txthandle_file(file) { |f| puts f.read }Statt den Block direkt mit call aufzurufen, kann auch yield verwendet werden. Dabei kann auf die explizite Deklaration des Block-‐Parameters verzichtet werden. def handle_file(file) f = File.open(file) yield(f) f.closeendfile = /Users/clemenskofler/test.txthandle_file(file) { |f| puts f.read }© 2011, Julian Fischer und Clemens Kofler

Kontrollstrukturen Ruby kennt ähnliche Kontrollstrukturen wie Java, um den Fluss des Programms zu steuern. Boolsche Operatoren Ruby kennt dieselben boolschen Operatoren wie Java: • &&, and: logisches Und • ||, or: logisches Oder • !, not: logisches Nicht • <, <=, >, >=: kleiner/größer (gleich) • ==: gleich Die Operatoren folgen den üblichen Regeln der boolschen Algebra. Allerdings kann im Gegensatz zu anderen Sprachen nicht nur ein boolscher Wert sondern jeder beliebige Wert an einem boolschen Ausdruck teilnehmen. In Ruby evaluiert in einem boolschen Ausdruck jeder Wert außer false und nil auf true. Conditionals (if, else etc.) today = Time.nowif today.wday == 6 puts "Hausarbeit!"elsif today.wday == 7 puts "Relax"else puts "Arbeit"endWie bei anderen Programmiersprachen sind die Abschnitte elsif und else optional. Außerdem kann bei negierten Bedingungen unless verwendet werden: x = 41if x != 42 puts "Die Antwort ist 42, nicht #{x}!”end© 2011, Julian Fischer und Clemens Kofler

unless x == 42 puts "Die Antwort ist 42, nicht #{x}!”endHinweis: unless + else sollte der Klarheit wegen vermieden werden. Als Kurzform für if/else kann der ternäre Operator verwendet werden: d = today.wdayif d == 6 || d == 7 puts "Wochenende"else puts "Noch nicht Wochenende"endputs d == 6 || d == 7 ? "Wochenende" : "Noch nicht Wochenende"Im Gegensatz zu anderen Sprachen hat in Ruby auch ein if/else-‐Konstrukt einen Rückgabewert: d = today.wdayoutput = if d == 6 || d == 7 "Wochenende"else "Noch nicht Wochenende"endputs outputFür einzelne if/unless-‐Konstrukte wird gerne die Inline-‐Variante verwendet, wo die Bedingung nachgestellt wird: puts "Mach irgendwas Sinnvolles" if today.wday == 6puts "Noch immer nicht Sonntag" unless today.wday == 7case/when Ein case-‐when-‐Ausdruck ist das Ruby-‐Pendant zum aus Java bekannten switch-‐case. case today.wday© 2011, Julian Fischer und Clemens Kofler

when 7 puts "Sonntag"when 6 puts "Samstag"else puts "Immer noch nicht Wochenende :("endFür kurze Abschnitte gibt es auch hier eine Inline-‐Variante: case today.wdaywhen 7 then puts "Sonntag"when 6 then puts "Samstag"else puts "Immer noch nicht Wochenende :("endEs können auch mehrere Werte in einem when verwendet werden: case today.wdaywhen 6, 7 then puts "Wochenende"else puts "Immer noch nicht Wochenende :("endKomplexere case-‐when-‐Varianten werden später behandelt. Loops (for, while etc.) Ruby kennt verschiedene Schleifen: for, while, do ... while und until. Diese funktionieren im Wesentlichen gleich wie in Java. In den meisten Fällen werden jedoch Iteratoren (z.B. each) vorgezogen, weil sie einfacher zu handhaben sind. Literaturempfehlungen Gratis http://mislav.uniqpath.com/poignant-‐guide/book/ (Kapitel 3+4) http://ruby-‐doc.org/docs/ (allerlei Links zu Dokumentationen) http://ruby-‐doc.org/docs/ProgrammingRuby/ (ältere Version von Programming Ruby) Kostenpflichtig http://www.amazon.de/dp/0596516177 (The Ruby Programming Language) © 2011, Julian Fischer und Clemens Kofler

Standard-‐Library und Gems Ruby unterteilt sich in eine Core-‐ und Standard-‐Library: Während die Core-‐Library automatisch zur Verfügung steht, müssen Elemente der Standard-‐Library vor Verwendung explizit mittels require geladen werden. Zusätzlich liefert Ruby seit Version 1.9 den Paketmanager RubyGems aus (in älteren Ruby-‐Versionen wurde dieser in der Regel manuell dazu installiert). Ein Gem ist ein Programmpaket, das eigenständig ausgeliefert und von Anwendungen verwendet werden kann. Standard-‐Library Verwendung Pakete der Standard-‐Library können mittels require geladen und anschließend verwendet werden. require dateputs Date.today # => 2011-12-15Dasselbe Paket kann ohne weiteres mehrmals mittels require eingebunden werden: Tatsächlich ignoriert Ruby mehrfache Aufrufe. Verfügbare Pakete Eine Liste aller verfügbaren Pakete für die aktuelle Ruby-‐Version (aktuell: 1.9.3) findet sich stets unter http://www.ruby-‐doc.org/stdlib. Status der Standard-‐Library Viele Pakete der Standard-‐Library sind veraltet und/oder schlecht gewartet. Viele Ruby-‐Programmierer haben daher Gems geschrieben, die weniger geeignete Pakete der Standard-‐Library ersetzen sollen. Je nach Themenbereich können alternative Lösungen auf Ruby Toolbox (https://www.ruby-‐toolbox.com/) und RubyGems.org (https://rubygems.org/) recherchiert werden. Gems Gems sind Programmpakete, die mithilfe des Paketmanagers RubyGems installiert werden und anschließend in der Applikation verwendet werden können. © 2011, Julian Fischer und Clemens Kofler

Verwendung Gems können entweder direkt über RubyGems oder mit Bundler verwendet werden. require rubygemsrequire activesupportputs .blank? # => trueVerfügbare Pakete Gems werden grundsätzlich auf https://rubygems.org/ gehostet, wo alle Informationen (z.B. Versionen, Paketabhängigkeiten etc.) einsehbar sind. Eine strukturiertere Auflistung vieler Gems findet sich auf https://www.ruby-‐toolbox.com/. Auswahl passender Gems Gems unterliegen grundsätzlich keiner Qualitätskontrolle, d.h. die Auswahl geeigneter Gems mit guter Qualität obliegt dem Programmierer. Mit Hilfe von Ruby Toolbox (https://www.ruby-‐toolbox.com/) lässt sich anhand einiger Kriterien mit großer Wahrscheinlichkeit feststellen, ob das Gem von guter Qualität ist: • Hat das Gem eine verständliche und ausführliche Readme? • Hat das Gem eine automatische Test-‐Suite? • Ist das Gem von einem angesehen Autor? • Wird das Gem aktiv gewartet? • Wie lange gibt es das Gem bereits? • Wird das Gem von vielen Leuten verwendet (häufig gedownloadet)? • Wird das Gem auf GitHub (de-‐facto-‐Standard) gehostet? • Hat das Gem viele offene Bugmeldungen auf GitHub? Empfohlene Gems Im Folgenden sind einige gängige Anwendungsfälle sowie passende, häufig verwendete Gems zusammengetragen. File Uploads (+ Image Processing) • Carrierwave • Paperclip User Authentifizierung und Autorisierung © 2011, Julian Fischer und Clemens Kofler

• Devise • Sorcery • OmniAuth (externe Auth Provider, z.B. Facebook) • CanCan Formulare • Formtastic • SimpleForm Permalinks • friendly_id XML • hpricot (simpel) • Nokogiri (komplexer) SOAP • handsoap • savon HTTP • httparty • faraday • curb Payment • activemerchant Tagging • acts_as_taggable_on Testing • rspec • Capybara (+ Cucumber) • capybara_webkit • FactoryGirl • DatabaseCleaner • Timecop • FakeWeb • vcr • Faker © 2011, Julian Fischer und Clemens Kofler

Automatisierung • guard • foreman Internationalisierung • i18n • globalize State Machine • AASM (Acts As State Machine) Paginierung • will_paginate • kaminari Deployment • Capistrano • Vlad Monitoring • Exceptional • Airbrake • NewRelic • Scout (Lokaler) Webserver • Mongrel • pow • unicorn • thin Log Analyse • request-‐log-‐analyzer Code Qualität • SimpleCov / rcov • metric_fu (+ darin enthaltene Gems) © 2011, Julian Fischer und Clemens Kofler

Bundler Bundler wird verwendet, um Abhängigkeiten unter verschiedenen Gems zu verwalten und aufzulösen. Bevor Bundler verwendet wurde, gab es häufig Versionskonflikte, weil der RubyGems Paketmanager lediglich einen unzureichenden Algorithmus zur Auflösung von Paketabhängigkeiten bereitstellt. Wir halten an dieser Stelle eine dedizierte Einführung in Bundler nicht für sinnvoll, weil die Problematik, die Bundler löst, sich erst in der tatsächlichen Entwicklung mit Ruby erschließt. Dennoch wollten wir den Dependency Manager an dieser Stelle erwähnen, damit zumindest der Begriff bekannt ist. Literaturempfehlungen Gratis http://www.mikeperham.com/2010/11/22/the-‐ruby-‐stdlib-‐is-‐a-‐ghetto/ https://www.ruby-‐toolbox.com/ https://rubygems.org/ http://gembundler.com/ http://railscasts.com/episodes/201-‐bundler © 2011, Julian Fischer und Clemens Kofler

Objektorientierte Programmierung mit Ruby – Grundlagen Klassen und Instanzen Ruby ist – wie Java – eine klassenbasierte objektorientierte Sprache. Klassen werden definiert und dienen als Vorlage für konkrete Objektinstanzen. class PersonendNeue Instanzen werden erzeugt, indem die Methode new auf die Klasse aufgerufen wird. matz = Person.newp matz # => #<Person:0x100139b50>Methoden Methoden definieren die Funktionalitäten von Klassen und Objekten. Man unterscheidet zwischen Klassen-‐ und Instanzmethoden. Instanzmethoden Instanzmethoden sind Methoden, die innerhalb einer Instanz zur Verfügung stehen. class Person def says_hello puts Hello! endendmatz = Person.newmatz.says_helloDie Methode initialize ist ein Spezialfall einer Instanzmethode und dient als Konstruktor. Hier wird die Objektinstanz für die Verwendung vorbereitet. class Person def initialize puts in initialize endend© 2011, Julian Fischer und Clemens Kofler

matz = Person.newKlassenmethoden Klassenmethoden sind Methoden, die für eine Klasse zur Verfügung stehen. class Person def self.test puts Person.test endendPerson.testHash-‐Parameter Häufig wird in Ruby ein Hash als letzter Parameter einer Methode verwendet. Besonders bei Ruby on Rails nennt man diesen gern “options hash”. def content_tag(name, content, options = {}) html = "<#{name}" options.each do |key, value| html << %( #{key}="#{value}") end html << ">#{content}</#{name}>" htmlendputs content_tag(:p, Hello, { :class => greeting })# => <p class="greeting">Hello</p>Wenn, wie in diesem Fall, der Hash der letzte Parameter des Methodenaufrufs ist, werden die geschwungenen Klammern üblicherweise weggelassen: puts content_tag(:p, Hello, :class => greeting)# => <p class="greeting">Hello</p>Multi-‐Parameter In Ruby ist es möglich, mehrere Parameter zu übergeben, und diese in einem Array statt als einzelne Parameter engegenzunehmen. def values_in_hash(hash, *fields) fields.map { |field| hash[field] }© 2011, Julian Fischer und Clemens Kofler

endhash = { :a => 1, :b => 2, :c => 3, :d => 4 }p values_in_hash(hash, :a, :c) # => [1, 3]Auch der umgekehrte Weg ist möglich: Man kann die Werte in einem Array als mehrere Einzelparameter übergeben: hash = { :a => 1, :b => 2, :c => 3, :d => 4 }fields = [:a, :c]p hash.values_at(*fields) # => [1, 3]Wenn der * Operator einem Array vorangestellt wird, nennt man ihn “Splat”. Variablen Wie bereits zu Anfang erwähnt, unterscheidet Ruby zwischen Instanz-‐ (beginnen mit @) und Klassenvariablen (beginnen mit @@). Instanzvariablen Instanzvariablen stehen innerhalb einer Instanz zur Verfügung. class Person def initialize(name) @name = name end def says_hello puts "Hello from #{@name}!" endendmatz = Person.new(Matz)matz.says_helloAccessors Ruby verwendet einen Accessor-‐/Property-‐basierten Ansatz, um Instanzvariablen nach außen zur Verfügung zu stellen. class Person attr_accessor :name© 2011, Julian Fischer und Clemens Kofler

# attr_reader :name # attr_writer :nameendmatz = Person.newmatz.name = Matzputs matz.name# ohne Accessorclass Person def name @name end def name=(new_name) @name = new_name endendmatz = Person.newmatz.name = Matzputs matz.nameEin Accessor greift dabei immer auf die Instanzvariable mit demselbem Namen zu. class Person attr_accessor :name def initialize(name) @name = name endendmatz = Person.new(Matz)puts matz.namematz.name = Yukihiro Matsumotoputs matz.name© 2011, Julian Fischer und Clemens Kofler

Access Control (Zugriffskontrolle) Methoden können vor dem Zugriff geschützt werden. Dafür stehen die Deklarationen protected und private zur Verfügung. Ohne explizite Deklaration sind alle Methoden public. class Person def dont_call_me puts "Dont call me!" end private :dont_call_meendPerson.new.dont_call_me # => NoMethodError: private method‘dont_call_me’ called for #<Person:0x1001352f8>Es ist auch möglich, mehrere Methoden auf einmal als public/protected/private zu deklarieren: class Person public # ... everythings public from now on protected # ... now protected private # ... now private public # ... and public againendHinweis: protected und private unterscheiden sich marginal und können in der Regel synonym betrachtet werden. Vererbung Jede Klasse in Ruby kann von einer anderen Klasse, der so genannten Superklasse, erben. Wenn eine Klasse keine Superklasse hat, erbt sie von Object (wie in Java). Der Vererbungsoperator ist <. class Personend© 2011, Julian Fischer und Clemens Kofler

class Programmer < PersonendMethoden Klassen erben alle Methoden ihrer Superklasse. class Person def initialize(name) @name = name end def about_me @name endendclass Programmer < Personendmatz = Programmer.new(Matz)puts matz.about_meKlassenmethoden und Accessors werden ebenso wie Instanzmethoden geerbt. super Klassen können Methoden ihrer Superklasse überschreiben und die originale Methode bei Bedarf mit super aufrufen. class Person def initialize(name) @name = name end def about_me @name endend© 2011, Julian Fischer und Clemens Kofler

class Programmer < Person def about_me "#{super} (Programmer)" endendmatz = Programmer.new(Matz)puts matz.about_meLiteraturempfehlungen Gratis http://langref.org/ruby/oop http://zetcode.com/lang/rubytutorial/oop/ http://bandwagonblog.wordpress.com/2009/01/12/ruby-‐oop-‐intro/ © 2011, Julian Fischer und Clemens Kofler

Objektorientierte Programmierung mit Ruby – Fortgeschrittene Themen Ruby Objektmodell Alles in Ruby ist ein Objekt – selbst die vermeintlich “primitiven Datentypen” wie Zahlen. Die Klasse jedes Objekts kann mit .class überprüft werden: puts 1.class # => Fixnumputs 1.5.class # => Floatputs a.class # => Stringputs [].class # => Arrayputs ({}).class # => HashSelbst Klassen sind Objekte – und zwar vom Typ Class. puts Array.class # => Classputs Hash.class # => ClassKlassenhierarchien Die Hierarchie einer Klasse kann mit der Methode superclass geprüft werden. puts Array.superclass # => Objectputs Object.superclass # => BasicObjectputs BasicObject.superclass # => nilAlle inkludierten Module und Superklassen sind mit der Methode ancestors einsehbar. p Array.ancestors# => [Array, Enumerable, Object, Kernel, BasicObject]Module Ruby Module sind am ehesten mit Java Interfaces zu vergleichen. Der wesentliche Unterschied besteht darin, dass Ruby Module in der Regel nicht nur ein Interface zur Verfügung stellen, sondern auch eine Implementierung. module Naming def full_name "#{first_name} #{last_name}" end© 2011, Julian Fischer und Clemens Kofler

endclass Person attr_reader :first_name, :last_name include Naming def initialize(first_name, last_name) @first_name = first_name @last_name = last_name endendmatz = Person.new(Yukihiro, Matsumoto)puts matz.full_name # => Yukihiro MatsumotoPerson inkludiert das Modul Naming. Dadurch wird implizit ein Vertrag geschlossen, in dem Person garantiert, die Methoden first_name und last_name, die von Naming benötigt werden, zur Verfügung zu stellen. Wir haben einen derartigen Vertrag bereits beim Modul Enumerable gesehen: Jede Klasse, die Enumerable verwenden will, garantiert, dass seine Methode each zur Verfügung gestellt wird, auf der die restlichen Iteratoren aufsetzen. So kann eine jede Klasse iterierbar gemacht werden. class PersonRepository include Enumerable def initialize(people) @people = people end def each(&block) @people.each { |person| block.call(person) } endendclass Person© 2011, Julian Fischer und Clemens Kofler

attr_reader :name def initialize(name) @name = name end def inspect name endendpeople = [Person.new(Matz), Person.new(Clemens),Person.new(Julian)]person_repository = PersonRepository.new(people)p person_repository.collect { |person| person.name }# => ["Matz", "Clemens", "Julian"]p person_repository.sort_by { |person| person.name }# => [Clemens, Julian, Matz]Methoden Zum Verständnis von Rubys Objektmodell ist es essentiell, zu verstehen, wie Methoden aufgerufen werden. Messages und Receiver Wenn man in Ruby vom Aufruf einer Methode spricht, meint man streng genommen, dass eine Message (Nachricht) mit einem bestimmten Namen an ein Objekt – den so genannten Receiver (Empfänger) gesendet wird: name = "Matz"puts name.lengthIn diesem Beispiel wird eine Message mit dem Namen length an das Objekt name gesendet. Das Objekt name ist somit der Receiver der Message length. © 2011, Julian Fischer und Clemens Kofler

self Wenn bei einem Methodenaufruf kein expliziter Receiver angegeben wird, sendet Ruby die Nachricht automatisch an das spezielle Objekt self. self wird dabei je nach Kontext angepasst. Das kann in einem kurzen Testprogramm überprüft werden: p self # => mainclass Test p self # => Test def test p self # => #<Test:0x100132558> endendTest.new.testEs sind drei verschiedene Kontexte von self sichtbar: • Außerhalb jedes Kontextes ist self an das spezielle Objekt main gekoppelt. • Innerhalb des Körpers einer Klasse entspricht self der Klasse selbst. Von daher kommt die Möglichkeit, Klassenmethoden zu definieren: Tatsächlich werden dabei Methoden auf dem self-‐Objekt definiert. • Innerhalb einer Instanzmethode entspricht das self-‐Objekt der konkreten Instanz. Um den Fluss seines Programms zu verstehen, sollte man sich zu jeder Zeit bewusst sein, an welchen Kontext self gerade gebunden ist. Duck Typing Wie bereits erwähnt, ist Ruby dynamisch typisiert: Der Wert von Variablen und Parametern wird bei Zuweisung festgelegt und kann sich auch jederzeit ändern. Es gibt keinen Compiler, der hilft, für Parameter von Methoden bestimmte Typen zu forcieren. Man kann durchaus beim Methodenaufruf die Typen von Parametern prüfen: class Duck def quack puts "Quack!" end© 2011, Julian Fischer und Clemens Kofler

endclass Goose def quack puts "Quock!" endenddef quacker(duck) raise ArgumentError.new(I can only handle Duck objects)unless duck.is_a?(Duck) duck.quackendquacker(Duck.new) # Quack!quacker(Goose.new)# => ArgumentError: I can only handle Duck objectsDurch die strenge Typprüfung wird die Methode unnötig eingeschränkt: Die einzige Voraussetzung, damit die Methode verwendet werden kann, ist, dass das übergebene Objekt die Methode quack zur Verfügung stellt. Daher kann auf genau diese Fähigkeit geprüft werden: def quacker(quacking) raise ArgumentError.new(I can only handle quackingobjects) unless quacking.respond_to?(:quack) quacking.quackendquacker(Duck.new) # => Quack!quacker(Goose.new) # => Quock!Es wird ein implizites Interface angenommen und gegen dieses Interface statt gegen eine Implementierung programmiert. Diese Technik heißt Duck Typing: In other words, dont check whether it IS-‐a duck: check whether it QUACKS-‐like-‐a duck, WALKS-‐like-‐a duck, etc, etc, depending on © 2011, Julian Fischer und Clemens Kofler

exactly what subset of duck-‐like behaviour you need to play your language-‐games with. Alex Martelli (2000), http://en.wikipedia.org/wiki/Duck_Typing#History In den meisten Fällen ist es besser, gegen des Interface eines Objekts zu programmieren statt gegen dessen Implementierung. Interne und externe APIs Wie schon im Kapitel Zugriffskontrolle erwähnt, dienen die Deklarationen protected und private dazu, den Zugriff auf Methoden von außen zu beschränken. Man spricht hier von der Unterscheidung zwischen einer externen (öffentlichen) API und einer internen (privaten) API: Die externe API darf von fremden Objekten verwendet werden, die interne API nur vom Objekt selbst. Zugriff auf die interne API mittels send Gemäß dem Prinzip, dass in Ruby alles jederzeit möglich ist, kann unabhängig von allen Zugriffsdeklarationen jederzeit auf alle Methoden zugegriffen werden. Dafür dient die Methode send. class Person def dont_call_me puts "Dont call me!" end private :dont_call_meendPerson.new.dont_call_me# => NoMethodError: private method ‘dont_call_me’ ...Person.new.send(:dont_call_me) # => Dont call me!Hinweis: Wenn die Methode send aus irgendeinem Grund überschrieben wurde und nicht zur Verfügung steht, kann stattdessen __send__ verwendet werden. Wann sollte man send nicht verwenden? Der Zugriff mittels send sollte generell nur dann erfolgen, wenn externer Code – d.h. z.B. Code des verwendeten Frameworks (Rails, Sinatra, …) – verwendet wird und geschützte Methoden aufgerufen werden sollen. © 2011, Julian Fischer und Clemens Kofler

Wenn eigener Code häufig mittels send aufgerufen wird, sollte man hinterfragen, ob die betreffenden Methoden nicht vielleicht Teil der externen API und damit public sein sollten. Vorsicht ist geboten, wenn die Dokumentation der betreffenden Methode explizit in einem Kommentar als intern deklariert ist (z.B. https://github.com/rails/rails/blob/master/actionpack/lib/abstract_controller/base.rb#L155) oder der Methodenname mit einem Unterstrich beginnt (z.B. https://github.com/rails/rails/blob/master/actionpack/lib/action_view/lookup_context.rb#L91): Der Autor des Codes drückt damit aus, dass diese Methode sich jederzeit verändern oder sogar verschwinden kann – d.h. ein Update auf neuere Versionen führt evtl. uu unerwarteten Nebeneffekten. Monkeypatching Alles in Ruby ist dynamisch – auch Klassen und Objekte. Beinahe jeder Aspekt der Programmiersprache kann zu jeder Zeit an die Bedürfnisse der jeweiligen Applikation angepasst werden. String.class_eval do def to_permalink downcase.gsub( , -) endendputs Monkeypatch sensibly.to_permalinkHier wird die String-‐Klasse geöffnet und die Methode to_permalink hinzugefügt, die anschließend allen String-‐Objekten zur Verfügung steht. Diese Vorgehensweise wird Monkeypatching (manchmal auch Duck Punching) genannt: A monkey patch is a way to extend or modify the run-‐time code of dynamic languages without altering the original source code. http://en.wikipedia.org/wiki/Monkey_patching ActiveSupport Das ActiveSupport Gem (Teil des Ruby on Rails Frameworks, kann aber auch eigenständig genutzt werden) kann als gute Vorlage dienen, wie sauberes © 2011, Julian Fischer und Clemens Kofler

Monkeypatching funktioniert. Im Ordner lib/active_support/core_ext finden sich allerlei Erweitertungen für Klassen der Ruby Core-‐ und Standard-‐Library. class Float alias precisionless_round round private :precisionless_round # Rounds the float with the specified precision. # # x = 1.337 # x.round # => 1 # x.round(1) # => 1.3 # x.round(2) # => 1.34 def round(precision = nil) if precision magnitude = 10.0 ** precision (self * magnitude).round / magnitude else precisionless_round end endend if RUBY_VERSION < 1.9Vor Ruby 1.9 war es nicht möglich, eine Fließkommazahl auf eine bestimmte Anzahl Dezimalen zu runden. Ruby 1.9 stellt diese Funktion aber zur Verfügung: # Ruby 1.8.71.66666.round(2)# => ArgumentError: wrong number of arguments (1 for 0)# Ruby 1.9.21.66666.round(2) # => 1.67# Ruby 1.8.7 mit ActiveSupport1.66666.round(2) # => 1.67Da Rails mit allen Ruby Versionen ab 1.8.7 kompatibel sein will, wird die Methode zur Verfügung gestellt. Das passiert nur für ältere Ruby-‐Versionen, weil die Methode in © 2011, Julian Fischer und Clemens Kofler

neueren Versionen ohnehin bereits zur Verfügung steht – sie wird also nicht überschrieben (siehe letzte Zeile). Metaprogramming Metaprogramming ist ein fortgeschrittenes Thema, dessen Behandlung den Rahmen sprengen würde. Dennoch soll ein kleiner Vorgeschmack gegeben werden, welche Möglichkeiten sich hierdurch bieten. Methoden dynamisch erstellen Ruby stellt mehrere Varianten zur Verfügung, um Methoden dynamisch zur Laufzeit zu erstellen. Die wahrscheinlich einfachste und flexibelste Variante ist class_eval: Hier wird der übergebene String als Ruby-‐Code auf dem jeweiligen Receiver evaluiert. So könnten wir beispielsweise die find_by_xxx-‐Methoden von ActiveRecord mit dynamisch generierten Methoden simulieren: class Contact FIELDS = %w(id first_name last_name) attr_accessor *FIELDS def initialize(attributes = {}) attributes.each do |name, value| send(:"#{name}=", value) end end FIELDS.each do |field| class_eval %{ def find_by_#{field}(value) CONTACTS.detect { |contact| contact.#{field} == value} end } end CONTACTS = [ Contact.new(:id => 1, :first_name => Yukihiro,:last_name => Matsumoto),© 2011, Julian Fischer und Clemens Kofler

Contact.new(:id => 2, :first_name => Clemens,:last_name => Kofler), Contact.new(:id => 2, :first_name => Julian,:last_name => Fischer) ]endHier wird für jedes Feld eine dynamische Methode generiert, die anschließend verwendet werden kann: matz = Contact.find_by_first_name(Yukihiro)p matz # #<Contact:0x100137148 @id=1, @last_name="Matsumoto",@first_name="Yukihiro">method_missing method_missing ist eine von Rubys Hook-‐Methoden. Sie wird jedes Mal automatisch ausgeführt, wenn versucht wird, eine nicht existierende Methode aufzurufen. class Test def method_missing(*) puts method missing! super endendTest.new.doesnt_exist# => NoMethodError: undefined method ‘doesnt_exist’ for#<Test:0x100137ad0>method_missing folgt dabei Rubys üblichen Vererbungsregeln und versucht, die fehlende Methode in einer der Superklassen zu finden: class ChildTest < Test def method_missing(*) puts method missing (ChildTest)! super endendChildTest.new.doesnt_exist© 2011, Julian Fischer und Clemens Kofler

# => NoMethodError: undefined method ‘doesnt_exist’ for#<ChildTest:0x1001374e0>Ein typisches Beispiel für method_missing findet sich in ActiveRecord: Dynamische Finder-‐Methoden erlauben das Finden von Objekten basierend auf Attributen: matz = Contact.find_by_first_name(Yukihiro)Ein solcher dynamischer Finder kann einfach nachgebaut werden: class Contact attr_accessor :id, :first_name, :last_name def initialize(attributes = {}) attributes.each do |name, value| send(:"#{name}=", value) end end def self.method_missing(name, *args, &block) if name.to_s =~ /^find_by_(w+)$/ CONTACTS.detect { |contact| contact.send($1) ==args.first } else super end end CONTACTS = [ Contact.new(:id => 1, :first_name => Yukihiro,:last_name => Matsumoto), Contact.new(:id => 2, :first_name => Clemens,:last_name => Kofler), Contact.new(:id => 2, :first_name => Julian,:last_name => Fischer) ]endmatz = Contact.find_by_first_name(Yukihiro)p matz© 2011, Julian Fischer und Clemens Kofler

# #<Contact:0x100137148 @id=1, @last_name="Matsumoto",@first_name="Yukihiro">Wichtig: Es sollte immer super aufgerufen werden, sodass ggf. der method_missing Hook der Superklasse(n) aufgerufen werden kann. Kombiniert mit dynamisch erstellten Methoden ergeben sich interessante Möglichkeiten: Statt jedes Mal den method_missing Hook auszulösen, kann beim ersten Aufruf eine Methode definiert werden. Nachfolgende Aufrufe der vormals fehlenden Methode verwenden nun diese neu definierte Methode, anstatt erneut method_missing aufzurufen. class Contact attr_accessor :id, :first_name, :last_name def initialize(attributes = {}) attributes.each do |name, value| send(:"#{name}=", value) end end def self.method_missing(name, *args, &block) puts method missing called if name.to_s =~ /^find_by_(w+)$/ class_eval %{ def self.#{name}(value) puts "#{name} called" CONTACTS.detect { |contact| contact.send(:#{$1}) ==value } end } send(name, *args) else super end end CONTACTS = [© 2011, Julian Fischer und Clemens Kofler

Contact.new(:id => 1, :first_name => Yukihiro,:last_name => Matsumoto), Contact.new(:id => 2, :first_name => Clemens,:last_name => Kofler), Contact.new(:id => 2, :first_name => Julian,:last_name => Fischer) ]endmatz = Contact.find_by_first_name(Yukihiro)p matzclemens = Contact.find_by_first_name(Clemens)p clemensWeitere Hooks Ruby bietet viele Möglichkeiten, den Lebenszyklus des Programms mit Hooks zu überwachen und zu manipulieren. Neben method_missing gibt es noch eine Reihe weiterer Hooks: • inherited • append_features • included • extended • extend_object • initialize_copy • const_missing • method_added, singleton_method_added • method_removed, singleton_method_removed • method_undefined, singleton_method_undefined Die Behandlung all dieser Hooks würde an dieser Stelle zu weit führen, aber die Funktionsweisen sind leicht im Internet zu recherchieren. Literaturempfehlungen Gratis http://blog.madebydna.com/all/code/2011/06/24/eigenclasses-‐demystified.html © 2011, Julian Fischer und Clemens Kofler

http://rubybestpractices.com/ (Kapitel 3 – Mastering the Dynamic Toolkit) http://avdi.org/devblog/2008/02/23/why-‐monkeypatching-‐is-‐destroying-‐ruby/ http://www.codinghorror.com/blog/2008/07/monkeypatching-‐for-‐humans.html http://mislav.uniqpath.com/poignant-‐guide/book/ (Kapitel 5+6) http://www.khelll.com/blog/ruby/ruby-‐callbacks/ Kostenpflichtig http://pragprog.com/screencasts/v-‐dtrubyom/the-‐ruby-‐object-‐model-‐and-‐metaprogramming http://www.amazon.de/dp/0321490452 (Design Patterns in Ruby) http://www.amazon.de/dp/0321584104 (Eloquent Ruby) http://www.amazon.de/dp/1934356476 (Metaprogramming Ruby) © 2011, Julian Fischer und Clemens Kofler

Webservices mit Ruby Ruby eignet sich hervorragend, um schnell und unkompliziert Webservices zu erstellen. Der hierfür bevorzugte Architekturstil ist Representational State Transfer, kurz REST. REST-‐Grundlagen Einige Prinzipien von REST sind am leichtesten im Kontrast zu weit verbreiten SOAP-‐Webservices zu erklären. Mit SOAP wird ein applikationsspezifisches Vokabular definiert, auf das üblicherweise mit HTTP POST Requests zugegriffen wird. In einem Onlineshop könnte es z.B. eine Methode getShoppingCartForUser geben, die als Parameter die ID des Users erwartet und ein XML-‐Dokument zurückliefert, das den Warenkorb des übergebenen Users enthält. getShoppingCartForUser(string userID)deleteShoppingCartForUser(string userID)addProductToShoppingCartForUser(string userID, stringproductID)updateItemQuantityFromShoppingCartForUser(string userID,string itemID, integer newQuantity)deleteItemFromShoppingCartForUser(string userID, stringitemID)Die Grundlage von REST sind Ressourcen, die durch eine eindeutige URI mit Hilfe des HTTP abgefragt und manipuliert werden können. HTTP stellt viele Dinge, die bei SOAP als Parameter oder Teil eines Methodennamens angegeben werden müssen, bereits in seiner Protokolldefinition bereit (z.B. welche Aktion mit der Ressource ausgeführt werden soll). GET /users/1/cartDELETE /users/1/cartPOST /users/1/cart/productsPUT /users/1/cart/items/1DELETE /users/1/cart/items/1Durch das HTTP Verb wird vorgegeben, was mit der jeweiligen Ressource passieren soll. Die Schachtelung von Ressourcen (/users/1/cart) ermöglicht es, die logische Datenstruktur im Webservice zu reflektieren. © 2011, Julian Fischer und Clemens Kofler

Gängige Anwendungsfälle Ein weiterer Content Type (z.B. Darstellung des Warenkorbs als PDF) ist einfach einzuführen, ohne dafür eine eigene Ressource definieren zu müssen: GET /users/1/cart.pdf# (bessere) Alternative: Accept: application/pdfAuf ähnliche Weise kann eine Ressource in alternativen Sprachen angefordert werden: GET /en/users/1/cart# (bessere) Alternative: Accept-Language: enSinatra Sinatra ist ein Mikroframework zur Erstellung von Webapplikationen mit Ruby. Aufgrund seiner Struktur eignet sich das Framework besonders für schlanke, hochspezialisierte Webservices. Installation Wie die meisten Bibliotheken wird auch Sinatra als Gem installiert: gem install sinatraWeitere Konfiguration ist nicht notwendig. Hello World require rubygemsrequire sinatraget / do Hallo Welt!endDer Server kann anschließend auf der Konsole gestartet werden: ruby hello_world.rbStandardmäßig startet der Server auf Port 4567. Die Applikation kann daher im Browser auf http://localhost:4567 abgerufen werden. © 2011, Julian Fischer und Clemens Kofler

Beispiel: Einfacher Kontaktmanager Einige Konzepte lassen sich am einfachsten in einem konkreten Beispiel erklären. Im ersten Schritt erstellen wir die Liste aller Kontakte (/contacts) sowie die Ansicht eines einzelnen Kontakts (/contact/:id). require rubygemsrequire sinatrarequire jsonclass Contact CONTACTS = [ { :id => 1, :first_name => Yukihiro, :last_name =>Matsumoto }, { :id => 2, :first_name => Clemens, :last_name =>Kofler }, { :id => 2, :first_name => Julian, :last_name =>Fischer }, ] def self.find(id) all.find { |contact| contact[:id] == id.to_i } end def self.all CONTACTS endendget /contacts do Contact.all.to_jsonendget /contacts/:id do contact = Contact.find(params[:id]) if contact.nil?© 2011, Julian Fischer und Clemens Kofler

# Kontakt nicht gefunden => korrekter HTTP Status solltegesetzt werden status 404 {}.to_json else contact.to_json endendHinweis: Der Einfachheit wegen wurde hier auf Persistenz verzichtet. Die Applikation kann wie vorher auf der Konsole gestartet und im Browser ausprobiert werden. Ein Aufruf von /contacts sollte alle Kontakte als JSON zurückliefern. Ein Aufruf von /contacts/1 sollte die Details von Yukihiro Matsumoto zurückliefern, ein Aufruf von /contacts/4 sollte einen leeren JSON Hash zurückliefern und den HTTP Status Code auf 404 setzen. Beispiel: Einfacher Kontaktmanager mit Datenbank Im nächsten Schritt binden wir eine echte Datenbank an und ergänzen Methoden zum Erstellen, Verändern und Löschen einzelner Kontakte. Dazu installieren wir zunächst das Gem sinatra-activerecord: gem install sinatra-activerecordAnschließend legen wir eine Datei namens app.rb: require rubygemsrequire sinatrarequire sinatra/activerecordWeiters benötigen wir eine Rakefile: require apprequire sinatra/activerecord/rakeAnschließend erstellen wir die Tabelle contacts mit Hilfe einer Migration: rake db:create_migration NAME=create_contactsIn dieser Migration legen wir die Tabelle mit den gewünschten Feldern an: class CreateContacts < ActiveRecord::Migration def self.up© 2011, Julian Fischer und Clemens Kofler

create_table :contacts do |t| t.string :first_name, :last_name, :twitter_handle end end def self.down drop_table :contacts endendUm die Tabelle zu erstellen, führen wir folgenden Rake Task aus: rake db:migrateWir können nun Code für das Model in app.rb hinzufügen: class Contact < ActiveRecord::Base validates_uniqueness_of :twitter_handleendHinweis: Die Validierung besteht lediglich, um später eine Möglichkeit zu haben, einen Fehler zu produzieren. Der bestehende Code für die URLs /contacts und /contacts/:id aus dem vorherigen Beispiel kann beibehalten werden: get /contacts do Contact.all.to_jsonendget /contacts/:id do begin Contact.find(params[:id]).to_json rescue ActiveRecord::RecordNotFound status 404 {}.to_json endendUm den Webservice sinnvoll verwenden zu können, brauchen wir nun Daten. Gemäß REST-‐Prinzipien sollte ein neues Element einer Ressource erstellt werden, indem ein POST Request auf die betreffende Ressource geschickt wird. © 2011, Julian Fischer und Clemens Kofler

post /contacts do contact = Contact.new(params[:contact]) if contact.save status 201 contact.to_json else status 422 info = { :message => "Could not create Contact.", :errors=> contact.errors } info.to_json endendBei Erfolg wird der neu erstellte Kontakt direkt als JSON zurückgegeben, im Fehlerfall ein JSON Hash mit Informationen zum Fehler – jeweils mit passendem Status Code. Wir können die neu hinzugekommene Funktion auf der Konsole mittels cURL testen: curl -i -X POST -dcontact[first_name]=Yukihiro&contact[last_name]=Matsumoto&contact[twitter_handle]=yukihiro_matzhttp://localhost:4567/contactsWir erhalten den neu erstellten Kontakt als JSON (inkl. id) zurück. Wenn wir dasselbe Kommando erneut ausführen, erhalten wir eine Fehlermeldung, da das Twitter Handle yukihiro_matz bereits verwendet wird. Außerdem wollen wir eine Möglichkeit bereitstellen, die Daten eines bestehenden Kontakts zu ändern. Gemäß REST passiert das mittels HTTP PUT auf die zu verändernde Ressource: put /contacts/:id do begin contact = Contact.find(params[:id]) if contact.update_attributes(params[:contact]) status 200 contact.to_json else status 422© 2011, Julian Fischer und Clemens Kofler

info = { :message => "Could not update Contact.",:errors => contact.errors } info.to_json end rescue ActiveRecord::RecordNotFound status 404 {}.to_json endendWir können die neue Funktion erneut auf der Konsole testen: curl -i -X PUT -d contact[twitter_handle]=matz_translatedhttp://localhost:4567/contacts/1Zuletzt fügen wir noch die Funktion zum Löschen eines Kontakts hinzu. Hierzu verwenden wir gemäß REST einen HTTP DELETE Request auf die zu löschende Ressource: delete /contacts/:id do begin contact = Contact.find(params[:id]) if contact.destroy status 200 else status 400 end rescue ActiveRecord::RecordNotFound status 404 endendWir testen die neue Funktion auf der Konsole: curl -i -X DELETE http://localhost:4567/contacts/1Beispiel: Content Type Negotiation Als finales Beispiel soll der Kontaktmanager noch die Möglichkeit erhalten, nicht nur JSON sondern auch XML zu unterstützen. © 2011, Julian Fischer und Clemens Kofler

Hierzu ergänzen wir zunächst einen Helper, der den bevorzugten Content Type aus dem Request Objekt extrahiert: helpers do def negotiated_type request.accept[0] == application/xml ? :xml : :json endendHinweis: Wir nehmen als Standard weiterhin JSON an und liefern nur dann XML, wenn es explizit angefordert wird. Außerdem setzen wir den Content Type für jede Route in einem before Block fest: before do content_type negotiated_typeendSchließlich ersetzen wir noch jeden Aufruf von to_json mit folgendem Code: send(:"to_#{negotiated_type}")# z.B.:contact.send(:"to_#{negotiated_type}")Nun können wir das Ergebnis auf der Konsole testen: curl -i -H Accept: application/xml -X GEThttp://localhost:4567/contacts/1Wir erhalten nun den Kontakt in seiner XML-‐Repräsentation. Hinweis: Wir hätten bereits in den vorangegangenen Beispielen den Content Type jeweils explizit mit content_type :json deklarieren sollen, um nicht text/html als Content Type zu erhalten. Der Einfachheit halber wurde aber darauf verzichtet. Rails In diesem Abschnitt wollen wir den Kontaktmanager aus dem Abschnitt Sinatra in Rails mit kleinen Änderungen umsetzen. Rails übernimmt dabei automatisch die Content Type Negotiation. Wir erstellen dazu eine neue Rails-‐Applikation: rails new contactsAnschließend generieren wir ein Model samt Migration: © 2011, Julian Fischer und Clemens Kofler

rails g model Contact first_name:string last_name:stringtwitter_handle:stringIm Model app/models/contact.rb ergänzen wir die Validierung: class Contact < ActiveRecord::Base validates_uniqueness_of :twitter_handleendAnschließend fügen wir in config/routes.rb die Ressource contacts hinzu: Contacts::Application.routes.draw do resources :contactsendAußerdem legen wir im Verzeichnis app/controllers eine Datei contacts_controller.rb an und legen fest, dass die Ressource als JSON oder XML repräsentiert werden kann: class ContactsController < ApplicationController respond_to :json, :xmlendAnschließend ergänzen wir Schritt für Schritt die Aktionen zum Lesen und Schreiben der Ressource: class ContactsController < ApplicationController respond_to :json, :xml def index contacts = Contact.all respond_with(contacts) end def show contact = Contact.find(params[:id]) respond_with(contact) end def create contact = Contact.create(params[:contact]) respond_with(contact)© 2011, Julian Fischer und Clemens Kofler

end def update contact = Contact.find(params[:id]) contact.update_attributes(params[:contact]) respond_with(contact) end def destroy contact = Contact.find(params[:id]) render :nothing => true, :status => contact.destroy ? :ok: :unprocessable_entity endendNun kann der Server gestartet werden und wie vorher der Webservice mit cURL getestet werden: rails s…Konsumieren eines REST-‐Webservice Ein bestehender REST-‐Webservice kann auf einfache Weise mit Ruby konsumiert werden. Wenn sich der zu konsumierende Service weitestgehend an Rails-‐Konventionen hält, kann hierfür ActiveResource (als Teil einer Rails-‐Applikation oder eigenständig) verwendet werden, ansonsten bietet sich die Verwendung des beliebten Gems RestClient an. ActiveResource Um ActiveResource zu verwenden, muss lediglich eine Klasse definiert werden, die ActiveResource::Base als ihre Superklasse ausweist und angibt, auf welchem Host die Resource zu finden ist: class Contact < ActiveResource::Base self.site = http://somewhere.comend© 2011, Julian Fischer und Clemens Kofler

Anschließend kann die Klasse weitgehend mit derselben API wie ActiveRecord verwendet werden (d.h. find, save, create, destroy, update_attributes etc.). RestClient RestClient macht im Gegensatz zu ActiveResource keine Vorannahmen über die genaue Struktur des konsumierten Webservice: Theoretisch kann auch ein Webservice konsumiert werden, der sich nicht oder nicht vollständig an den REST-‐Architekturstil hält. RestClient kann in einem imperativen oder Resourcen-‐orientierten Stil verwendet werden. In den folgenden Beispielen wird der Resourcenstil verwendet. Zunächst wird die Resource definiert: contacts =RestClient::Resource.new(http://localhost:5678/contacts)Anschließend können alle oder auch einzelne Elemente via HTTP GET abgerufen werden: contacts.getcontacts[1].getHTTP Header können jeweils als Hash-‐Parameter übergeben werden: contacts[1].get(:accept => application/json)contacts[1].get(:accept_language => de)Um eine Resource und alle Subresourcen immer mit denselben Headern zu verwenden, können diese bereits an den Konstruktor übergeben werden: contacts =RestClient::Resource.new(http://localhost:5678/contacts,:headers => { :accept => application/json })Parameter für POST und PUT Requests können ebenfalls als Hash-‐Parameter übergeben werden: contacts.post(:contact => { :first_name => Yukihiro,:last_name => Matsumoto })contacts[1].put(:contact => { :first_name => Clemens,:last_name => Kofler })Hinweis: Dieses Codebeispiel geht davon aus, dass sich die Parameter eines Kontakts wie in Rails üblich in params[:contact] befinden. Schließlich können natürlich auch DELETE Requests abgesetzt werden: © 2011, Julian Fischer und Clemens Kofler

contacts[1].deleteDie Responses können auf verschiedenste Arten verarbeitet werden, die den Rahmen dieses Skriptums sprengen würden. Informationen dazu finden sich in der Dokumentation. RestClient ist damit sehr flexibel und hauptsächlich durch die unterstützten Resourcen, Header und Informationen des konsumierten Service beschränkt. Literaturempfehlungen Gratis http://en.wikipedia.org/wiki/REST http://www.ics.uci.edu/~taylor/documents/2002-‐REST-‐TOIT.pdf (Roy Fieldings Dissertation) http://www.w3.org/Protocols/rfc2616/rfc2616.html (HTTP 1.1 Protokollspezifikation) http://www.sinatrarb.com/intro.html http://sinatra-‐book.gittr.com/ http://screencasts.org/episodes/activerecord-‐with-‐sinatra http://screencasts.org/episodes/configuring-‐activerecord-‐in-‐sinatra http://blogs.plexibus.com/2009/01/15/rest-‐esting-‐with-‐curl/ https://github.com/archiloque/rest-‐client http://www.scribd.com/doc/3003/Active-‐Resource-‐Objectoriented-‐REST-‐services http://railscasts.com/episodes/94-‐activeresource-‐basics http://railscasts.com/episodes/95-‐more-‐on-‐activeresource Kostenpflichtig http://www.amazon.de/dp/0596805829 (REST in Practice: Hypermedia and Systems Architecture) http://www.amazon.de/dp/0596529260 (RESTful Web Services) http://www.amazon.de/dp/0596801688 (RESTful Web Services Cookbook) http://www.amazon.de/dp/0321659368 (Service-‐Oriented Design with Ruby and Rails) © 2011, Julian Fischer und Clemens Kofler

Integration Testing mit Cucumber und Capybara Die dynamische Natur von Ruby erfordert rigoroses Testen: In kompilierten Sprachen wie Java hilft der Compiler dabei, zumindest offensichtliche Fehler wie Syntaxfehler und Typfehler direkt zu finden. Da Ruby-‐Code komplett zur Laufzeit interpretiert wird und jederzeit veränderbar ist, ist dieses Vorgehen nicht möglich. Integration Testing Im Gegensatz zu Unit Testing werden beim Integration Testing nicht einzelne Elemente einer Applikation in Isolation sondern deren Zusammenspiel getestet. Im Falle einer Webapplikation kann beispielsweise der gesamte Prozess einer User-‐Registrierung in einem Integration Test abgedeckt werden: Am Anfang steht der Klick eines Users auf einen Link, der zum Registrierungsformular führt. Anschließend füllt der User einige Felder aus und sendet das Formular ab. Nach diesem Prozess sollte der User eine Information erhalten, dass er nun registriert ist. Außerdem sollte ein neuer Datensatz in der Datenbank abgelegt worden und ggf. eine E-‐Mail an den User versendet worden sein. Cucumber Cucumber ist in der Ruby-‐Community ein beliebtes Tool für Integration Testing. Die beste Beschreibung von Cucumber findet sich auf der Website selbst: Cucumber lets software development teams describe how software should behave in plain text. The text is written in a business-‐ readable domain-‐specific language and serves as documentation, automated tests and development-‐aid -‐ all rolled into one format. http://cukes.info/ Einsatzgebiet Cucumber kann und sollte vor allem dann eingesetzt werden, wenn es innerhalb eines Projekts einen aktiven (internen) Kunden – d.h. einen Kunden, der sich laufend und aktiv in die Entwicklung einbringen will – oder ein Team für Testing und Qualitätssicherung gibt. In diesen Fällen ist der Kunde bzw. das QS-‐Team für die Pflege und Kontrolle der Text-‐Features verantwortlich, die das Verhalten der Applikation © 2011, Julian Fischer und Clemens Kofler

textuell beschreiben. Das Entwickler-‐Team ist für die technische Implementierung der einzelnen Feature-‐Definitionen sowie deren Umsetzung in der Applikation verantwortlich. Wenn das Entwickler-‐Team selbst ohne Zutun von Kunde/QS die Text-‐Features verfasst und von Seiten des Kunden/QS kein oder wenig Interesse an der regelmäßigen Prüfung der Features besteht, ist der Einsatz von Cucumber nur eingeschränkt sinnvoll. Hier kann die Komplexität reduziert werden, indem die Integration Tests ohne Textbeschreibungen komplett ausprogrammiert werden. Installation An dieser Stelle wird der Installationsprozess in einem Rails-‐Projekt dargestellt. Die Installation in einem anderen Framework bzw. eigenständige Installation sind weitestgehend ähnlich. gem install cucumber-railsrails generate cucumberHier werden zunächst das Gem cucumber-rails und etwaige Abhängigkeiten (u.a. auch Capybara) installiert und anschließend mit einem Rails Generator ins Framework eingebunden, indem einige Verzeichnisse und Dateien erstellt werden. Konfiguration Die gesamte Konfiguration von Cucumber findet im Verzeichnis features/support statt. Die primäre Anlaufstelle ist die Datei env.rb. Die vom Generator erzeugte Datei entspricht für ein Rails-‐Projekt bereits unseren Vorstellungen und muss daher nicht weiter angepasst werden. Für etwaige Anpassungen geben die Kommentare die Richtung vor. Struktur Eine Integration Test Suite besteht aus Sicht von Cucumber aus einer Ansammlung von Feature Definitionen, die das Verhalten der Applikation beschreiben. Innerhalb eines Features wird zunächst das Feature benannt und optional beschrieben. Anschließend wird das Feature in Szenarien (Scenario) geteilt, die verschiedene Fälle innerhalb des Features beschreiben. So können z.B. bei einer User-‐Registrierung Szenarien für den erfolgreichen Fall sowie Fehlerfall vorhanden sein. Szenarien sind ihrerseits in Schritte (Steps) unterteilt, die nacheinander ausgeführt werden. Dabei gibt es drei Typen von Schritten: © 2011, Julian Fischer und Clemens Kofler

• Given: definiert Vorbedingungen, z.B. bestehende Einträge in der Datenbank • When: Aktionen, die der User in der Applikation durchführt, z.B. Klicks auf Links, Ausfüllen von Formularen etc. • Then: Ergebnisprüfung, z.B. Fehlermeldungen werden angezeigt, E-‐Mails werden verschickt etc. Given-‐Schritte sollten nur zum Anfang eines Szenarios stehen, When-‐ und Then-‐Schritte können sich während eines Szenarios abwechseln, um z.B. einen Zwischenstand zu prüfen. Beispiel Nehmen wir den in der Einleitung beschriebenen Prozess der User-‐Registrierung als Beispiel. Die User-‐Story in Cucumber könnte wie folgt aussehen: Feature: User Registration In order to start using the service As a visitor I want to sign up for the service Scenario: Registering Given I am on the homepage When I follow "Register" And I submit the registration form Then I should see "Youve successfully registered for ourservice" And I should have received a registration confirmationvia emailHinweis: And wiederholt den vorherigen Schritt-‐Typ, d.h. ein And-‐Schritt nach einem Given-‐Schritt wird zu einem weiteren Given-‐Schritt etc. Außerdem kann But verwendet werden, um einen Gegensatz auszudrücken (z.B. Then I should see …But I should not see …) Backgrounds Wenn mehrere Szenarien dasselbe Setup, d.h. dieselben Given-‐Schritte, verwenden, kann ein Background definiert werden, um die Wiederholung der Schritte zu vermeiden. Ein gängiges Beispiel sind Features, für deren Verwendung man als User eingeloggt sein muss. © 2011, Julian Fischer und Clemens Kofler

Feature: My Account Background: Given I am logged in Scenario: Updating bank details Given I am on the dashboard page # ... Scenario: Updating address details Given I am on the dashboard page # ...Hinweis: In diesem Beispiel könnte der Schritt Given I am on the dashboardpage theoretisch auch Teil des Background sein. Es wird jedoch empfohlen, die Einstiegsseite eines Szenarios der Klarheit wegen immer innerhalb des Szenarios zu halten. Ausführen der Tests Die Tests können jederzeit mit folgendem Kommando ausgeführt werden: rake cucumberImplementierung der Schritte Text-‐Beschreibungen für sich alleine können nicht ausgeführt werden, sondern müssen zunächst in Ruby interpretiert werden. Hierfür wird gewöhnlich Capybara verwendet. Capybara Capybara ist ein Integration Test Werkzeug, mit dem User-‐Prozesse (z.B. Klicks, Ausfüllen von Formularen etc.) simuliert werden können. Es ist grundsätzlich unabhängig von Cucumber, wird aber häufig zusammen mit Cucumber verwendet. Einsatzgebiet Wie bereits erwähnt, wird Capybara häufig zusammen mit Cucumber verwendet. Während Cucumber Text-‐Dateien interpretiert und in Schritte übersetzt, werden die Schritte an sich mit Capybara ausgeführt. © 2011, Julian Fischer und Clemens Kofler

Capybara kann auch eigenständig eingesetzt werden. Dies ist vor allem dann zu empfehlen, wenn es keinen aktiven Kunden bzw. kein QS-‐Team gibt, das sich um das Schreiben der Text-‐Features in Cucumber kümmern kann oder will. Installation Capybara wird als Gem installiert: gem install capybara Konfiguration Für die Verwendung in einem Rails-‐Projekt ist keine weitere Konfiguration notwendig. Adapter Capybara bietet verschiedene Adapter, um die Aktionen von Usern zu simulieren. Folgende Adapter werden unterstützt: • rack-‐test: Standard; simuliert einen Browser • Selenium: startet einen echten Browser (z.B. Firefox) und führt dort Features aus • HtmlUnit (Plugin): verwendet das Java-‐Werkzeug HtmlUnit • WebKit (Plugin): verwendet den WebKit Browser • env.js (Plugin): purer JavaScript Browser Alle erwähnten Adapter außer rack-‐test unterstützen das Testen im Zusammenspiel mit JavaScript. Selenium ist insofern speziell, als hier ein Browser-‐Fenster geöffnet wird und der Testprozess als Ganzes beobachtet werden kann. Kommandos Capybaras DSL versucht, das Testen durch natürliche Sprache möglichst einfach zu gestalten. Eine vollständige Liste inkl. weiterführender Links ist in der Readme-‐Datei (https://github.com/jnicklas/capybara/blob/master/README.rdoc) zu finden. Ein Tipp zur Verwendung von Selektoren: Capybaras mächtige Selektor-‐Engine unterstützt theoretisch die Verwendung von Labels bei Formularelementen. Die Erfahrung zeigt, dass sich Labels durchaus ändern, wodurch dann jeweils die Tests angepasst werden müssen. Daher sollten DOM IDs vorgezogen werden. Beispiel: # nicht:fill_in Email, :with => bob@example.com# sondern:© 2011, Julian Fischer und Clemens Kofler

fill_in user_email, :with => bob@example.comAlternativ kann, sofern das Markup verändert werden kann, auch das rel-‐Attribut verwendet werden – siehe hierzu http://blog.steveklabnik.com/posts/2011-‐12-‐20-‐write-‐better-‐cukes-‐with-‐the-‐rel-‐attribute. Literaturempfehlungen Gratis http://cukes.info/ https://github.com/cucumber/cucumber/wiki/ http://railscasts.com/episodes/155-‐beginning-‐with-‐cucumber http://railscasts.com/episodes/159-‐more-‐on-‐cucumber http://railscasts.com/episodes/257-‐request-‐specs-‐and-‐capybara http://blog.steveklabnik.com/posts/2011-‐12-‐20-‐write-‐better-‐cukes-‐with-‐the-‐rel-‐attribute Kostenpflichtig http://pragprog.com/book/achbd/the-‐rspec-‐book http://pragprog.com/book/hwcuc/the-‐cucumber-‐book © 2011, Julian Fischer und Clemens Kofler

Deployment mit Capistrano Capistrano ist das de-‐facto Standardwerkzeug für das Deployment von Ruby Applikationen auf einen oder mehrere Server. Grundlagen Funktionsweise Capistranos Funktionsweise ist einfach erklärt. Jede Applikation enthält vordefinierte und angepasste Kommandos (so genannte Tasks). Eine Liste aller vorhandenen Tasks kann mit dem Kommando cap -T angezeigt werden. Jeder Task kann weitere Tasks ausführen, was in einer Reihe von Shell-‐Kommandos resultiert, die auf den vordefinierten Servern via SSH ausgeführt werden. Um eine ausführlichere Beschreibung (falls vorhanden) eines Tasks anzuzeigen, kann das Kommando cap -e <task name> verwendet werden (z.B. cap -edeploy:setup). Capistrano ist somit ein Werkzeug zur Automation: Statt sich selbst einzuloggen und alle Kommandos händisch auszuführen, macht Capistrano das Deployment robuster, indem es zusammengesetzte Kommandos reproduzierbar ausführt. Voraussetzungen Um Capistrano verwenden zu können, müssen alle Server, die am Deployment beteiligt sind, per SSH zugänglich sein und eine POSIX-‐kompatible Shell verwenden. Es wird außerdem empfohlen, zur Sicherung des Zugangs nicht Passwörter sondern Public Keys zu verwenden. Setup Capistrano wird in zwei einfachen Schritten installiert (Annahme: wir befinden uns im Verzeichnis der Applikation): gem install capistranocapify .Wenn die Applikation Bundler verwendet, muss das capistrano Gem in die Gemfile eingetragen und das bundle Kommando ausgeführt werden. bundle© 2011, Julian Fischer und Clemens Kofler

capify .Das capify Kommando legt die Dateien Capfile und config/deploy.rb an, sofern diese nicht bereits existieren. Anatomie eines Capistrano-‐Setups Der Computer, von dem aus das Deployment durchgeführt werden soll, benötigt eine Datei namens capfile (oder Capfile) im Verzeichnis der Applikation, die ausgeliefert werden soll. In dieser Datei finden einige Setup-‐Prozesse statt, in denen etwaige Capistrano-‐Plugins sowie die Datei mit der Basiskonfiguration geladen werden. Die Datei für die Basiskonfiguration heißt per Standard deploy.rb und liegt im Unterordner config. Auf Servern, die die Applikation hosten sollen, geht Capistrano von folgender Verzeichnisstruktur aus: Es gibt ein Verzeichnis für die zu hostende Applikation (z.B. friendscout24) und in diesem Verzeichnis liegen folgende Unterverzeichnisse: • current: symbolischer Link auf das aktuelle Release • releases: beinhaltet Releases in Unterordnern, die nach dem Timestamp des jeweiligen Releases benannt sind • shared: beinhaltet Dateien, die über Deployments hinweg beibehalten werden (z.B. Konfigurationsdateien und File Uploads) Auch diese Struktur kann auf Wunsch angepasst werden, es wird jedoch empfohlen, dem Standard zu folgen. Minimalkonfiguration Die Datei config/deploy.rb beinhaltet bereits einigen Code als Hilfestellung für die Konfiguration. Für eine funktionierende Minimalkonfiguration muss die Datei überarbeitet und ergänzt werden. # Name der Applikationset :application, "friendscout24"# Git wird als Source Control Management System verwendetset :scm, :git# URL des Git Repositorysset :repository,"git@github.com:friendscout24/friendscout24.git"© 2011, Julian Fischer und Clemens Kofler

# Der Server friendscout24.de wird als Applikations-, Web- undDatenbankserver verwendetserver "friendscout24.de", :app, :web, :db, :primary => true# Der User namens "deploy" soll fürs Deployment verwendetwerdenset :user, "deploy"# Es soll kein sudo verwendet werdenset :use_sudo, false# Die Applikation soll in /var/www/friendscout24 liegenset(:deploy_to) { "/var/www/#{application}" }Anschließend kann die Konfiguration getestet werden, indem man mit Capistrano via SSH ein Kommando auf dem Server ausführt: COMMAND=whoami cap staging invokeDieses Kommando sollte mit der obigen Konfiguration den Namen des Users (deploy) zusammen mit einigen weiteren Informationen anzeigen. Erstes Deployment Vorbereitung der Server Um die Server fürs Deployment vorzubereiten, muss die bereits erwähnte Verzeichnisstruktur mit korrekten Zugriffsrechten hergestellt werden. Capistrano stellt dafür das Kommando cap deploy:setup bereit: cap deploy:setupAnschließend kann das Setup überprüft werden: cap deploy:checkMit diesem Kommando können etwaige Probleme diagnostiziert und behoben werden. Sobald Capistrano mitteilt, dass das Setup funktioniert, muss der Server applikationsspezifisch vorbereitet werden. Applikationsspezifisches Setup Capistrano hat per se keine Vorannahmen über Dienste außerhalb der Applikation wie z.B. die verwendete(n) Datenbank(en). Bevor mit dem Deployment begonnen werden © 2011, Julian Fischer und Clemens Kofler

kann, muss sichergestellt werden, dass sämtliche von der Applikation benötigten Dienste korrekt konfiguriert und gestartet sind. Illustriert am Beispiel Datenbank: • MySQL ist installiert, konfiguriert und gestartet. • Die Datenbank, die von der Applikation verwendet werden soll, ist angelegt. • Für die Applikation steht ein MySQL-‐Account zur Verfügung, der alle notwendigen Rechte für die zu verwendende Datenbank hat. Deployment Wenn der Server für Capistrano und die Applikation konfiguriert ist, kann ein erstes Deployment angestoßen werden. Dafür dient der Task deploy:cold: cap deploy:coldEs wird ein reguläres Deployment ausgeführt und, sofern keine Fehler auftreten, die Applikation gestartet. Einige Entwickler raten von der Verwendung von deploy:cold ab und schlagen vor, das erste Deployment komplett von Hand durchzuführen, weil während des ersten Deployments einige Probleme auftreten können, die in einer händischen SSH-‐Sitzung einfacher nachzuvollziehen sind als in einem automatischen Capistrano-‐Task. Es bleibt jedem selbst überlassen, deploy:cold auszuprobieren und festzustellen, ob es für die konkrete Applikation auf dem verwendeten Server wie erwartet funktioniert. Für weitere Deployments kann der Task deploy verwendet werden: cap deployStatt den Server zu starten, wird hierbei ein Restart durchgeführt. Weiterführende Themen Definition eigener Tasks Capistrano verhält sich abseits des bereits erwähnten simplen Deployments (Auschecken des Codes und Restart des Servers) völlig agnostisch gegenüber Applikationen: Die Handhabung aller weiteren Services (z.B. Indexing und Neustart eines Lucene-‐Servers) muss selbstständig ergänzt werden. Dafür können Tasks angelegt werden, die dann entweder händisch oder (bevorzugt) mit Hilfe von Callbacks ausgeführt werden können. © 2011, Julian Fischer und Clemens Kofler

Hier ein vereinfachtes Beispiel, das den Sphinx-‐Suchserver vor dem Checkout des Codes stoppt und anschließend mit ggf. neuer Konfiguration wieder startet: namespace :sphinx do desc "Generate the Sphinx configuration file" task :configure do rake "sphinx:configure" end desc "Start the Sphinx daemon" task :start do configure rake "sphinx:start" end desc "Stop the Sphinx daemon" task :stop do configure rake "sphinx:stop" endendbefore deploy:update_code, thinking_sphinx:stopafter deploy:update_code, thinking_sphinx:configure,thinking_sphinx:startHandhabung von sensiblen Daten Sensible Daten, wie z.B. jegliche Passwörter und Signaturen, sollten nicht ins Versionskontrollsystem eingecheckt werden. Da das Deployment aus dem Versionskontrollsystem erfolgt, müssen diese Daten während des Deployments nachgezogen werden. Die gängige Praxis ist, die Daten im Verzeichnis shared abzulegen. Ein Beispiel ist die database.yml Datei eine Ruby on Rails Applikation, die die Konfiguration der Datenbank enthält. Die übliche Vorgehensweise ist, die Datei im Verzeichnis shared anzulegen. production: adapter: mysql2© 2011, Julian Fischer und Clemens Kofler

encoding: utf8 reconnect: false database: friendscout24 pool: 5 username: friendscout24 password: icanhazcheezburger socket: /tmp/mysql.sockWährend des Deployments muss ein symbolischer Link angelegt werden, um die Datei in der Applikation verwenden zu können. Dazu wird die Datei deploy.rb wie folgt ergänzt: namespace :deploy do desc <<-DESC Symlink shared directories and files. DESC task :symlink_dependencies do run "ln -s #{shared_path}/config/database.yml#{release_path}/config/database.yml" endendbefore deploy:finalize_update, deploy:symlink_dependenciesZuerst wird ein neuer Task namens symlink_dependencies im Namespace deploy definiert, in dem ein symbolischer Link von der Datei database.yml angelegt wird. Anschließend wird ein Callback registriert: Bevor der Task deploy:finalize_update ausgeführt wird, soll der eben hinzugefügte Task ausgeführt werden. Dieser Task kann für alle weiteren Dateien mit sensiblen Informationen ergänzt werden. Persistenz über Deployments Manche Dateien müssen über Deployments hinweg persistiert werden, z.B. hochgeladene User Avatare, Fotos etc. Auch hier ist die gängige Praxis, symbolische Links zu Ordnern anzulegen, da die Applikation möglichst wenig über ihre Deployment-‐Umgebung wissen sollte. Hier kann auf Wunsch auf eine weitere Konvention von Capistrano zurückgegriffen werden: Capistrano legt automatisch ein Verzeichnis shared/system an. Beim © 2011, Julian Fischer und Clemens Kofler

Deployment wird automatisch ein symbolischer Link nach public/system angelegt. Jede Datei, die in public/system abgelegt wird, ist damit automatisch persistent über alle Deployments. Wenn weitere Verzeichnisse und Dateien persistiert werden sollen, kann ähnlich wie bei der Handhabung von sensiblen Daten vorgegangen werden. Anwendungsfall: In der Applikation gibt es ein Verzeichnis private_uploads, das persistiert werden soll. namespace :deploy do desc <<-DESC Symlink shared directories and files. DESC task :symlink_dependencies do run "mkdir -p #{shared_path}/private_uploads" run "ln -s #{shared_path}/private_uploads#{release_path}/private_uploads" endendbefore deploy:finalize_update, deploy:symlink_dependenciesZunächst muss sichergestellt werden, dass das betreffende Verzeichnis in shared angelegt ist. Anschließend kann dieses gelinkt werden. Literaturempfehlungen Gratis https://github.com/capistrano/capistrano/wiki https://github.com/leehambley/capistrano-‐handbook/blob/master/index.markdown http://help.github.com/deploy-‐with-‐capistrano/ Kostenpflichtig http://pragprog.com/book/fr_deploy/deploying-‐rails-‐applications (Deploying Rails Applications) © 2011, Julian Fischer und Clemens Kofler

Ruby Grundlagen

by Avarteq GmbH on Jan 18, 2012

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

Ruby Grundlagen — Document Transcript