So, ja, das ist mein Talk, das wisst ihr schon. Ich stelle mich ganz kurz vor, ich bin David Rötzel und ich liebe Ruby. Meine Frau ist auch irgendwo hier, ich muss also vorsichtig sein, was ich sage.

Aber es ist tatsächlich so, Ruby hat mein Denken über Programmiersprachen im Allgemeinen geändert. Ich arbeite als freiberuflicher Entwickler und Trainer. Ich gebe Kurse zu Ruby und Rails und das schon seit einigen Jahren und habe festgestellt, dass ich auch eigentlich nichts anderes mehr machen möchte.

Ich habe ursprünglich genau hier in der Hochschule auch Informatik studiert und da war es so ein kleines Hobby von mir, neue Programmiersprachen zu lernen. Ich habe immer mal wieder mich mit neuen Sprachen beschäftigt, das hat mir irre viel Spaß gemacht. Ich habe vor kurzem festgestellt, dass das nicht mehr so ist. Ich gucke mir immer noch gerne neue Sprachen an, aber ich brauche zwei Codebeispiele, die ich mir anschaue

und dann wende ich mich ganz schnell wieder ab. Und das hat mich ein bisschen gewundert. Ich habe das mal hinterfragt, warum das so ist und ich habe festgestellt, das liegt einfach daran, dass Ruby für mich die passende Programmiersprache ist. Und ich möchte, bevor ich jetzt weitermache, auch ein bisschen was von euch wissen. Und zwar wüsste ich ganz gerne,

wer sich hier mit Ruby schon mal beschäftigt hat. Von denen, die sich jetzt aufgezeigt haben, bei wem ist das mehr als drei Jahre her? Okay, bei den anderen, irgendwer da beide regelmäßig mit Ruby arbeitet?

Euch muss ich leider enttäuschen, also ich werde euch nichts Neues erzählen können. Gut, wer hier interessiert sich für den Einsatz von Ruby mehr im Bereich der Systemadministration? Okay, und wer sieht sich eher als Entwickler? Gut, ja, ist schön gemischt. Ach so, vielleicht letzte Frage, ist hier jemand, der Ruby ins Auge fasst als allererste Programmiersprache?

Auch das? Ja wunderbar, haben wir eine schöne Mischung hier im Raum, freut mich. Bevor ich loslege, ganz wichtig, ein Warnhinweis, ja, ich habe gesagt, ich liebe Ruby, ich werde gleich so Begriffe benutzen wie schöner Code, eleganter Code und sowas. Man merkt schon an den Begrifflichkeiten, das ist alles hochgradig subjektiv.

Ja, ich lege hier nur meine persönliche Meinung da und ich habe überhaupt nicht den Anspruch, dass das auch die Meinung von allen anderen sein muss. Trotzdem bin ich der festen Überzeugung, dass sich die Beschäftigung mit Ruby lohnt und dass man auf jeden Fall was lernen kann, selbst wenn man nachher sagt, der Rötzl spinnt doch.

So, damit genug vorgeplänkelt, ich will ja was zu Ruby erzählen und dieser Mann hier, der hat es erfunden, dass das Yukihiro Matsumoto, ein Japaner, dessen Name gerade für Amerikaner scheinbar unaussprechlich ist, weswegen er im gesamten Internet nur unter seinem Pseudonym Mets bekannt ist. Und Ruby ist eine objektorientierte, interpretierte Programmiersprache. Es gibt also keinen

Compiler, der das Programm zunächst mal übersetzt, bevor es ausgeführt werden kann, sondern ich füttere ein Ruby-Programm direkt an den Interpreter und es wird unmittelbar ausgeführt. Es ist also eine, früher hat man Skriptsprache gesagt, ich mag diesen Begriff nicht besonders, aber es hat eine interpretierte Sprache, ähnlich wie Python,

Perl, PHP und so weiter. Und Mets Vorbilder für Ruby lagen ganz klar bei Perl und Smalltalk, vor allem bei Smalltalk, was eine, die praktisch die erste richtige objektorientierte Programmiersprache war, die das Konzept der Objektorientierung durch und durch umgesetzt hat und genau das macht Ruby auch.

Ruby ist circa 20 Jahre alt jetzt, nur um das mal so ein bisschen einzuordnen. Damit ist Ruby ein wenig jünger als Perl und Python, aber in etwa genauso alt wie Java. Trotzdem hat man hierzulande gerade immer den Eindruck, dass Ruby so ein bisschen jünger ist, so ein bisschen neuer ist und das liegt wahrscheinlich vor allem

daran, dass es jahrelang nur in Japan bekannt war. Es hat bis etwa 2001 gedauert, bis es erstmals englischsprachige Dokumentation zu Ruby gab und damit ist es erst weiter verbreitet worden. Es gibt so verschiedene Leute, die versuchen die Popularität von Programmiersprachen zu messen und je nachdem, wem man fragt, sieht man, dass also Ruby in den letzten zehn Jahren eigentlich

konstant unter den Top Ten oder Top Fifteen der bekanntesten, der beliebtesten Programmiersprachen residiert. Und besonders bekannt geworden ist Ruby vor allem durch drei Projekte, das sind Rails, Puppet und Chef. Rails, wie gesagt, das womit ich meistens arbeite, ein Framework zur Webentwicklung. Puppet und Chef sind beide Systeme

zum Konfigurationsmanagement, also eher was für den Systemadministrator. Ruby läuft auf verschiedenen Plattformen. Der Originalinterpreter von Ruby, der wird gerne MRI genannt für Mets Ruby Interpreter oder auch CRuby, weil er in C geschrieben ist, läuft auf allen gängigen Desktop- und Serverbetriebssystemen.

Es gibt aber auch noch alternative Interpreter, also andere Implementierungen dieser Programmiersprache Ruby. Und da gibt es zum Beispiel JRuby, das läuft auf der Java Virtual Machine. Es gibt mit IronRuby eine Implementierung für Microsoft.net. Und es gibt auch Ansätze Ruby nutzbar zu machen für die Appentwicklung.

Also wenn man Apps schreiben möchte für Apples iOS oder auch für Android, kann man das mittlerweile auch mit Ruby machen. Trotzdem, und das ist ein Grund, warum ich heute hier stehe, muss man ganz klar sagen, wie vorhin in der Einleitung schon erwähnt, der Hype um Ruby, der ist vorbei. Man sieht das ganz gut an den Google-Suchen.

Also der Peak war etwa so um 2007 herum und seitdem hat das Interesse an Ruby, zumindest wenn man Google fragt, abgenommen. Und das ist ein ganz normaler Zyklus für Programmiersprachen. Jede Programmiersprache, die mal eine gewisse Popularität erreicht hat, die macht das durch. Ich habe vor einiger Zeit einen sehr schönen Artikel zu dem Thema gelesen, den wollte ich für

diesen Vortrag eigentlich noch mal raussuchen. Stattdessen habe ich aber einen anderen Artikel gefunden von 2005 und da beschreibt Bruce Ackle, der unter anderem als Fachbuchautor für Java bekannt wurde, dasselbe Phänomen nur halt aus der Sicht von 2005 und für Java. Ihm ist aufgefallen, dass alle Leute,

die in der Java-Szene sehr bekannt waren, die viel publiziert haben, die viel auf Konferenzen gesprochen haben, dass die plötzlich alle kein Java mehr machen. Er hat diese Leute Hyper-Enthusiasten genannt und er hat die Frage gestellt, wo sind die denn alle hin? Seine Antwort damals war ganz klar, die machen jetzt alle Ruby.

Und jetzt, fast zehn Jahre später, ist Ruby in genau derselben Situation. All die Leute, die noch vor vielen Jahren ganz viele Blogposts geschrieben haben, die Bücher geschrieben haben, die auf Konferenzen geredet haben und Ruby überall bekannt gemacht haben, die machen heute fast alle irgendwas anderes. Nur im Gegensatz zu damals ist die Frage nicht so leicht zu beantworten, wo sind sie denn

hingegangen? Stattdessen hat sich das ganz deutlich aufgesplittert und das zeigt aus meiner Sicht klar, dass es nicht die eine neue Programmiersprache gibt, die besser ist als Ruby. Stattdessen gibt es viele verschiedene Ansätze, die ganz spezifische Aufgabenstellung vielleicht etwas besser lösen. Und das andere, was man daran sieht, ist es gibt einfach Leute, für die gilt immer, neu ist gleich besser und das sehe ich anders.

Also ich will ja eigentlich zeigen, was ich so schön und was ich so liebenswert finde an Ruby. Und das resultiert vor allem aus der Einstellung seines Hauptentwicklers, seines Erfinders. Metz hat gesagt, ihm ist nicht besonders wichtig, welche Features eine Programmiersprache hat. Es geht ihm nicht darum, die

schnellste Programmiersprache zu entwickeln oder sowas, sondern sein Ziel ist es, eine Programmiersprache zu entwickeln, die den Entwickler, also den Benutzer der Sprache praktisch glücklich macht. Und das finde ich, das merkt man. Und eine Sache, die da eine ganz große Rolle spielt aus meiner Sicht, ist die Syntax. Ich gucke mir, wie gesagt, auch heute noch

neue Programmiersprachen an und sobald ich da ein großes Gemisch von ganz vielen Sonderzeichen, runde Klammern, eckige Klammern, geschweifte Klammern und so weiter sehe, wende ich mich meistens schon angewidert ab, lese aber häufig

Kommentare von Leuten, die sagen, das ist doch alles egal. An Syntax kann man sich gewöhnen. Die Features sind das entscheidende. Und das sehe ich ganz anders. Wenn ich das jeden Tag schreiben muss, dann muss mir das Freude bereiten. Und das macht Ruby. Die Syntax von Ruby, die ist einfach, sie ist kurz und sie ist prägnant. Sie erlaubt es, mit sehr, sehr wenig Code viel auszudrücken und dabei

trotzdem noch lesbaren Code zu produzieren. Ich habe hier ein ganz, ganz kurzes kleines Beispiel, das von der Standard-Eingabe eine Zeile einliest, den Zeilenumbruch hinten wegschneidet, das Ganze in einer Variablen merkt. Das soll ein Name sein, der dort eingegeben wird und dann wird geprüft, wurde der Name eingegeben. Wenn ja, wird ein personalisierter Gruß ausgegeben und wenn nicht, dann wird

einfach Hello World ausgegeben. Und an diesem kleinen Beispiel sieht man schon eine ganze Menge. Das ist also wirklich ein vollständiges und lauffähiges Ruby-Programm. Weil man sieht, ich brauche keinen großen Umbau drum herum. Ich brauche keine Main-Funktion. Ich muss keine Klasse

implementieren, nur um ein kleines Programm zu schreiben. Ich muss keine Variablen deklarieren. Auch das sieht man hier hoffentlich. Also was Name sein soll, was da drin stehen soll und so weiter, das habe ich nirgendwo angegeben. Des Weiteren, im Vergleich zu anderen Spachen, fällt vielleicht auf, dass es keinen Semicolon gibt, das die Zeile hier abschließt. Ich schreibe einfach Anweisungen untereinander, muss

kein Zeichen verwenden, um eine Anweisung am Ende abzuschließen. Und Semicolon ist ein Sonderzeichen, das es in Ruby so nicht gibt. Ansonsten ist Ruby sehr sparsam mit Sonderzeichen. Die Ruby-Syntax verwendet im Vergleich zu anderen Programmiersprachen deutlich weniger

Sonderzeichen. Sie sind alle da. Also runde Klammern, geschweifte Klammern, eckige Klammern und so weiter findet man alle in Ruby. Aber sie werden grundsätzlich sehr sparsam verwendet im Vergleich zu anderen Sprachen. Und es gibt ganz viele Möglichkeiten, diese manchmal auch wegzulassen. Ich habe hier nochmal das exakt selbe Beispiel, aber ich habe jetzt mal alle optionalen Klammern gemacht.

Das ist genau dasselbe Programm, aber Ruby erlaubt es mir, diese Klammern, die man hier sieht, wegzulassen. Und hier sind wir jetzt auch wieder ganz klar bei einer Geschmacksfrage. Das ist eine ganz subjektive Einstellung, aber ich finde diese erste Variante hier deutlich übersichtlicher und

die reservierten Wörter in Ruby, die sind wie in anderen Programmiersprachen auch letztlich aus der englischen Sprache entliehen. Aber es gibt ein paar mehr als in anderen Sprachen und es hat einen ganz interessanten Effekt. Es führt nämlich dazu, dass wenn man zusätzlich seine Variablen und seine Methoden auch noch besonders ausdrucksstark benennt, dann kann man plötzlich Code schreiben.

Den muss man einfach nur laut vorlesen und kann ihn sofort verstehen. Ich habe hier drei Beispiele. Ich stört euch wahrscheinlich, wenn es jeder macht, aber könnt ihr mal so für euch vorlesen, leise und ihr solltet direkt verstehen, was hier passiert und das ist wirklich einzigartig.

Natürlich lernt jeder Entwickler seine Variablen sinnvoll zu benennen und seine Methoden sinnvoll zu benennen, aber wenn man mal ehrlich ist und zu anderen Programmiersprachen schaut, sieht man doch sehr häufig, dass der Programmierer faul ist, der möchte sich Tipparbeit sparen und der benutzt ganz schnell mal irgendwelche kryptischen Abkürzungen. In Ruby ist das ganz anders.

Wenn man sich Ruby Code anguckt, in Open-Source-Projekten und so weiter, wird man feststellen, dass die Leute sogar hingehen und sehr, sehr lange Variablen haben, sehr, sehr lange Methodennamen verwenden, fast schon absurd lange, aber das führt dazu, dass ich solchen Code schreiben kann. Den kann ich auch in einem halben Jahr noch verstehen.

Den kann ich wunderbar lesen und da brauche ich nicht viel mehr, um zu verstehen, was hier vor sich geht. Codeblöcke sind eine Eigenschaft von Ruby, die wirklich einzigartig ist. Jede moderne Programmiersprache heutzutage hat ein solches Konstrukt. Es wird meist als Closure bezeichnet. In Ruby gibt es das aber schon immer und ist so elegant und simpel in die Syntax integriert,

dass es wirklich ein ganz wunderbares Mittel ist. Die Idee dahinter ist an sich simpel, aber unglaublich mächtig. Die Idee ist, dass ich eine Menge von Code, also eine Reihe von Ruby-Anweisungen, als zusätzlichen Parameter bei einem Methodenaufruf mitgeben kann. Die Methode ist dann dafür verantwortlich, das auszuführen. Das bedeutet, die Methode kann entscheiden, es einfach komplett zu ignorieren.

Sie kann diesen Code genau einmal ausführen oder sie kann ihn auch mehrfach ausführen, wenn sie das möchte. Damit kann man unheimlich viele Sachen machen. Ich staune heute immer noch, weil ich ständig über neue kreative Einsatzmöglichkeiten von diesen Codeblöcken stolper.

Das, was man als Ruby-Neuling aber wahrscheinlich am ehesten lernt, ist, dass das Ganze als Ersatz für Schleifen benutzt wird, so wie in dem ersten Beispiel hier. Da wird dieser Codeblock nämlich genau fünfmal ausgeführt. Das kann ich hier ganz schön notieren mit five times und das geht aus meiner Sicht wirklich nicht viel lesbarer.

Aber wie gesagt, ich kann das auch noch für andere Dinge verwenden. Da gibt es unheimlich viele interessante Beispiele. In Ruby on Rails zum Beispiel gibt es die Möglichkeit, Tabellen in relationalen Datenbanken mit Hilfe solcher Codeblöcke zu beschreiben. Total abgefahren. Und es gibt viele ganz, ganz praktische Beispiele, wie das hier, das direkt aus der Ruby Core API kommt.

Da gibt es eine Klasse File, die ermöglicht, mir mit Dateien zu arbeiten. Und wer das schon mal in anderen Programmiersprachen gemacht hat, der weiß vielleicht, dass ich immer darauf achten sollte, wenn ich eine Datei einmal geöffnet habe, dass ich sie auch wirklich wieder schließe. Das kann man ganz schnell mal vergessen und das wird in der Regel auch nicht sofort zu einem Fehler führen,

kann aber irgendwann später ganz fiese Probleme verursachen. Also eine ganz gemeine Sache, die man schnell mal vergisst. Und diese Klasse File hier ermöglicht es mir mit der Hilfe eines Codeblocks, dieses Problem zu umgehen. In diesen Codeblock hinein kriege ich eine variable File. Das ist meine Datei. Da kann ich dann wie ein Beispiel hier was reinschreiben oder rauslesen und so weiter.

Und was Open also macht, ist, es öffnet die Datei, dann wird der Codeblock ausgeführt und dann wird die Datei wieder geschlossen. Das funktioniert vollautomatisch und ich als Entwickler, ich kann es nicht mehr vergessen. Ich hatte es gesagt, Ruby ist eine objektorientierte Programmiersprache und das ist wirklich unglaublich konsequent umgesetzt.

Das habe ich so noch in keiner anderen Sprache außer vielleicht Smalltalk gesehen. Smalltalk wie gesagt auch das große Vorbild an der Stelle für Ruby. Alle objektorientierten Sprachen, die ich vorher gelernt habe, machen irgendwelche merkwürdigen Kompromisse oder seltsame Ausnahmen. Java hat sowas wie primitive Datentypen, die doch keine Objekte sind.

Und man verbringt unglaublich viel Zeit damit, diese beiden Welten ineinander umzusetzen. Pearl und PHP, die haben die Objektorientierung erst später nachträglich hinzubekommen. Das merkt man wirklich an ganz vielen Stellen. Ruby setzt dieses Konzept der Objektorientierung absolut konsequent und konsistent um.

Und das bedeutet, dass in Ruby wirklich alles ein Objekt ist. Wir haben es eben im Prinzip schon gesehen, sowas wie eine ganz normale Ganzzahl. Die 23 hier, das ist ein Objekt, da kann ich Methoden darauf aufrufen. Eine Zeichenkette, ein String ist auch ein Objekt, auch da kann ich Methoden darauf aufrufen.

Ruby hat reguläre Ausdrücke fest eingebaut und auch das sind Objekte und so weiter und so fort. Das ist wirklich ganz konsequent umgesetzt. Und jedes Objekt kann ich fragen, von welcher Klasse bist du denn? Und wenn ich die 23 frage, von welcher Klasse sie ist, dann sagt die, ich bin ein Fixnam.

Fixnam ist also hier eine Klasse in Ruby, die so einen Ganzzahltyp mit repräsentiert. Und wenn ich Fixnam frage, von welcher Klasse bist du, kriege ich auch eine Antwort. Tatsächlich sind sogar Klassen in Ruby Objekte. Also da sieht man, dass das wirklich sehr, sehr konsequent, konsistent umgesetzt wurde. Ich kannte Objektorientierung als Konzept schon vorher aus vielen anderen Sprachen,

aber ich muss gestehen, erst durch Ruby hat es bei mir so wirklich Klick gemacht. Vorher habe ich das immer so empfunden, ich verstehe zwar, was es soll, aber es hilft mir nicht wirklich. In Ruby ist es wirklich eine wunderbare Hilfe, komplexe Programme zu strukturieren, weil es so konsequent und einfach umgesetzt wurde.

Was ich in Ruby auch sehr schätze, sind die eingebauten Datentypen, die wirklich unglaublich viel Funktionalität beinhalten. Viel mehr, als ich das aus anderen Sprachen gewohnt bin. Sowas wie Strings oder Arrays oder Hashes, die haben einfach mal über 100 Methoden, die ich drauf aufrufen kann.

Jede Menge Funktionalität, mit der ich unheimlich viel, mit ganz wenigen kurzen Aufrufen erreichen kann. Ich habe nur mal zwei Beispiele rausgepickt hier von Listen. Ich habe eine Liste von Werten von 1 bis 6, also Zahlen von 1 bis 6 und zwei Methoden Map und Select, die auf den ersten Blick sehr ähnlich aussehen, aber ein bisschen unterschiedlich funktionieren.

Map erlaubt es mir, eine Liste zu transformieren. Ich übergebe einen Codeblock und dieser Codeblock, der schreibt jetzt vor, was mit jedem einzelnen Element der Liste passieren soll. Wie jedes einzelne Element der Liste verändert werden soll. Und als Ergebnis bekomme ich eine neue Liste, mit denen auf diese Weise veränderten Werten.

Was ich hier mache ist, ich nehme einfach jeden Wert mal zwei. Und dann kriege ich als Ergebnis 2, 4, 6 und so weiter raus. Select im Gegenteil, sieht sehr ähnlich aus, ermöglicht es mir aber, eine Liste zu filtern. Also ganz gezielt Werte rauszusuchen aus einer Liste. Und das Kriterium dafür übergebe ich ja auch wieder in Form von so einem Codeblock.

Und was ich hier mache, ist, ich möchte alle geraden Zahlen aus der Liste rausfiltern. Und dann halte ich als Ergebnis entsprechend 2, 4, 6. Was wir hier auch sehen, ich kann jede Zahl fragen, ob sie gerade ist. Even Fragezeichen heißt die Methode. Auch das wieder sehr kurz prägnant, trotzdem sehr lesbar.

Und bei beiden Methoden kommt ja als Ergebnis auch jeweils wieder eine Liste heraus. Das bedeutet, ich kann diese Aufrufe, wenn ich das möchte, auch verketten. Und mit sehr, sehr wenig Code und trotzdem immer noch lesbar, große Mengen von Daten so massieren, wie ich das brauche.

Das Ergebnis ist ja hier wieder eine Liste, das heißt, ich könnte hier den Aufruf von Select direkt dahinter schreiben. Oder ich merke mir das Ergebnis in einem Zwischenschritt in einer Variable und rufe es dann da nochmal aus. Je nachdem, wie länglich und unübersichtlich das wird. Aber beide Möglichkeiten habe ich.

Was man immer wieder über Ruby hört, ist, dass es eine unglaublich dynamische Sprache ist. Man hört da sehr auf diesen Begriff des Metaprogrammings, also Code, der Code zur Laufzeit erzeugt oder manipuliert. Das ist etwas, was man in Ruby machen kann, sehr umfänglich machen kann. Ich habe nur ein ganz kleines Beispiel mir rausgepickt,

weil es sonst zu weit führen würde. Aber was man hier sieht, ist, dass man bestehende Klassen in Ruby zur Laufzeit erweitern kann. Wenn ich feststelle in meinem Programm, dass ich immer wieder die Aufgabenstellung habe, Vokale in Zeichenketten zu zählen, dann wünsche ich mir irgendwann die Möglichkeit, warum kann ich denn, wenn ich so eine String, so eine Zeichenkette habe,

den nicht direkt fragen, wie viele Vokale enthältst du. Und das kann ich tatsächlich hinzufügen, der bestehenden Klasse String. Das hier ist also keine neue Definition der Klasse String, sondern ich öffne die bestehende Klasse und füge eine neue Methode hinzu. Und anschließend kann ich auf jeder Zeichenkette diese Methode aufrufen.

Das ist etwas, das muss man natürlich mit großer Vorsicht genießen. Sobald ich mehrere Bibliotheken verwende, die das alle machen, kommt es ganz schnell mal zu einem Konflikt. Aber die Tatsache, dass ich es machen kann, finde ich persönlich sehr angenehm. Und was ich an Ruby besonders schätze, ist es skaliert. Und damit meine ich nicht Performance,

sondern damit meine ich Einsatzzwecke. Ich kann in Ruby genauso gut diese kleinen Kommandozeilen, Einszeiler schreiben wie in Perl. Ich kann in Ruby aber auch komplexe Systeme schreiben mit Tausenden von Zeilen Code. Und für alles dazwischen hat Ruby auch eine Antwort. Also Ruby ist unwahrscheinlich vielseitig. Ebenfalls schön an Ruby finde ich seine Community.

Die Leute drum herum, die an Ruby und rund um Ruby entwickeln. Und das liegt zum einen daran, dass viele Leute diese Idee von Meths verinnerlicht haben. Also wenn ich eine Bibliothek schreibe, dann schreibe ich die nicht für den Computer, ich schreibe sie für den Menschen, der die nachher benutzen muss. Und das spürt man an vielen Stellen.

Ich habe nur mal drei Beispiele rausgepickt. Das hier ist ein Beispiel aus Active Record, der Datenbankkomponente von Ruby on Rails. Und Active Record ist ein sogenannter Objekt-relationaler Mapper, der also die Welt der relationalen Datenbanken umsetzt in die der Ruby-Objekte. Und da passiert unheimlich viel vollautomatisch.

Aber Active Record kann nicht alles vollautomatisch machen. Ein paar Dinge muss ich konfigurieren. Und das geht aber wunderbar einfach. Was ich hier konfiguriert habe, ist jetzt also, dass ich in meiner Datenbank Benutzer verwalte. Und dass solche Benutzer, weil ich so ein Rollen- und Rechtemodell habe, also jetzt viele Rollen haben können.

Außerdem besteht so ein Benutzer mindestens aus einem Login-Namen und einem Passwort. Und ich möchte, dass Active Record sicherstellt, dass dieser Login-Name auf jeden Fall immer gesetzt ist. Und wenn ein Passwort angegeben ist, dann möchte ich, dass das nochmal bestätigt wird. Ja, das kennt man aus ganz vielen Registrierungsformularen. Ich muss ein Passwort immer zweimal eintippen zur Bestätigung,

weil ich nicht sehe, was ich dort eintippe. Und auch das kann ich hier sicherstellen. Und das Ganze passiert mit drei ganz kurzen, prägnanten Aufrufen, die wunderbar lesbar sind. Zweites Beispiel ist eine Bibliothek, die heißt Whenever. Und Whenever ermöglicht es mir, Einträge in der Krontab anzulegen.

Wenn ich in meinem Projekt die Notwendigkeit habe, um irgendwelche Prozesse zeitgesteuert anzustoßen, dann werde ich natürlich an der Stelle das Rad nicht neu erfinden, sondern ich möchte ja natürlich Krone verwenden. Das mache ich aber nicht so oft, deswegen kann ich mir die Syntax der Krontab wirklich nicht merken. Die Mainpage ist super, aber wenn ich ohnehin in Ruby unterwegs bin,

ist es vielleicht einfacher, sowas hier zu nutzen. Whenever gibt mir eine Methode, die heißt einfach Every, und dann kann ich sowas notieren wie Every Four Hours oder jeden zweiten Tag genau um 31.00 nachts. Und das ist auch wieder sehr eingängig und wunderbar lesbar. Das dritte und letzte Beispiel stammt auch wieder aus Ruby on Rails.

Active Support ist eine Bibliothek, die aus Ruby on Rails hervorgegangen ist, die ganz viele so kleine Erweiterungen für die eingebauten Datentypen in Ruby enthält. Darunter auch Erweiterungen für Datums- und Zeitwerte. Und ich benutze das schon viele, viele Jahre. Nächstes Jahr wären zehn Jahre, dass ich das mache.

Aber es zaubert mir trotzdem noch jedes Mal ein Lächeln aufs Gesicht, wenn ich sowas wie Two Days Ago schreiben darf. Was an der Ruby-Community aus meiner Sicht auch einzigartig ist, ist das Interesse an Code-Qualität. Natürlich hat keiner Interesse daran, schlechten Code zu schreiben, aber sowas wie Test-Frameworks,

so Dinge wie Code-Metriken, also der Versuch irgendwie zu messen, wie gut Code ist und auch der Einsatz von Konzepten wie Continuous Integration ist extrem weit verbreitet in der Ruby-Community. Und das sind alles Konzepte, die waren mir vorher schon bekannt. Ich muss jetzt vorsichtig sein, der Mann, der es mir beigebracht hat, sitzt hier vorne.

Es war mir vorher schon bekannt, aber den Nutzen, den habe ich nie so wirklich erfahren. Ich habe immer den Eindruck gehabt, Unit-Tests zu schreiben ist mehr Arbeit. Was habe ich denn davon? Ich habe immer gedacht, in meinen konkreten Fällen kann ich gar keine Tests schreiben, bis ich mal gelernt habe, dass das vielleicht an einem schlechten Entwurf meinerseits liegt.

Und es ist tatsächlich auch die Ruby-Community gewesen, die mir da die Augen geöffnet hat. Alleine zu sehen, dass viele Leute sich mit diesen Themen auseinandersetzen, allein viele gute Beispiele zu sehen, hat dazu geführt, dass ich da Interesse gewonnen habe und das Gefühl gehabt habe, ich muss da besser werden und auch Spaß daran gefunden habe,

mich stetig auch heute noch da weiterzuentwickeln. Meine Erfahrung ist auch, dass man mit Ruby-Entwicklern im Open-Source-Bereich sehr, sehr angenehm zusammenarbeiten kann. Und das liegt vor allem an zwei Dingen, wie ich finde. Zum einen der Wahl der Standard-Lizenz. Natürlich gibt es Ruby-Code in ganz vielen Open-Source-Lizenzen,

aber für fast alle Ruby-Entwickler ist der Standard einfach die MIT-Lizenz. Und das ist so die simpelste Open-Source-Lizenz, die es eigentlich gibt. Und die setzt praktisch keine Hürden für andere Leute, um an einem Projekt mitzuarbeiten. Und das ist besonders interessant zusammen mit dem zweiten Punkt. Die meisten Ruby-Open-Source-Projekte

sind bei GitHub gehostet. Man kann über GitHub sicherlich geteilter Meinung sein, aber wer einmal erlebt hat, wie dieser Workflow funktioniert, um bei einem fremden Projekt etwas beizutragen, er wird mir zustimmen, dass das wirklich wunderbar einfach gelöst ist. Ich kann auf Mausklick ein fremdes Projekt forken, dann mache ich da meine Änderung,

committe die Änderung und kann dann wieder auf Mausklick dem Maintainer upstream eine Nachricht schicken, hier guck mal, ich habe hier was verändert, willst du das nicht übernehmen? Und der kann auch letztlich wieder mit einem Mausklick entscheiden, ja, das übernehme ich ungeprüft, oder kann auch sagen, ne, das will ich nicht haben. Und das funktioniert wirklich wunderbar. Und wenn man sich an ein paar Spielregeln hält,

kann man so wirklich sehr angenehm, sehr schnell auch einsteigen darin, in Ruby-Projekten mitzuarbeiten. Und ich muss gestehen, ich freue mich immer noch wie ein kleines Kind, wenn ein völlig fremder Mensch im Internet ein Stück Code von mir übernimmt. Ja, und die Ruby-Community zu guter Letzt, die macht auch wirklich Spaß.

Das sind Leute mit sehr feinem Humor am Werk und man kann da viel entdecken. Wer sich neu mit Ruby beschäftigt, wird zwangsläufig irgendwann über Wise Point und Guide to Ruby stolpern. Eine Einführung in die Programmiersprache Ruby, gleichzeitig aber auch ein psychedelischer Comic. Ich habe sowas vorher noch nie gesehen und seitdem nie wieder gesehen. Das sollte man sich mal anschauen.

Ist nicht für jedermann, also wenn es nicht lustig findet, gar kein Problem, aber gesehen haben sollte man es. Und wenn man auf Ruby-Konferenzen unterwegs ist, dann darf man sich auch nicht wundern, wenn das Rails-Core-Team plötzlich auf der Bühne zu einem albernen YouTube-Meme tanzt. Ja, also auch sowas kann einem da passieren. So, jetzt habe ich euch erzählt,

was ich an Ruby so besonders schätze. Und das ist ein guter Zeitpunkt, denke ich, um einmal mit ein paar Vorurteilen aufzukommen. Das, was ich am häufigsten höre, ist dieses hier. Ruby ist langsam. Und das ist das, was man am schwersten widerlegen kann. Ich behaupte, man kann für jede Programmiersprache ein Benchmark finden, das die schlecht aussehen lässt.

Man muss fairerweise sagen, als interpretierte Sprache spielt Ruby in einer Liga mit Python, Perl, PHP und so weiter. Und wird wahrscheinlich nie die Performance erreichen von kompilierten Sprachen wie C, C++ oder auch Java. Trotzdem muss man sagen, für die meisten Anwendungsfälle sollte Ruby schnell genug sein.

Und, das wollte ich hier zeigen, den Ruby-Entwicklern ist dieses Problem durchaus bewusst. In allen wesentlichen Versionen, die in den letzten Jahren erschienen sind, hat sich performancemäßig immer was getan. Teilweise sogar wirklich viel. Das ist jetzt nur ein Benchmark, aber in den allermeisten sieht es eigentlich so aus. Und auch die nächste Version,

2.2, die schon angekündigt ist, die wird wieder signifikante Verbesserungen beinhalten, auch im Bereich Performance. Ein großer Kritikpunkt an Ruby ist, dass es keine sinnvoll eingebauten Möglichkeiten hat, um Nebenläufigkeiten zu programmieren. Wir haben heutzutage Multi-CPU, Multi-Core-Systeme,

die wollen ausgelastet werden. Und das geht mit so einer rein linearen Programmiersprache natürlich nicht besonders gut. Eines der ältesten und am weitesten verbreiteten Mittel dafür ist, dass man Threads verwendet, um quasi parallel zu programmieren. Und da hat der Original Ruby-Interpreter eine entscheidende Einschränkung.

Er hat ein sogenanntes Global Interpreter Log, oder GIL, das verhindert, dass zwei Threads gleichzeitig Ruby-Code ausführen. Das heißt, man kann damit zwar mit Threads arbeiten, aber nie so ein Multi-Prozessor-System wirklich sinnvoll auslasten. Für wen das wirklich ein Problem darstellt, der kann aber mal ein bisschen weiter schauen. Es gibt alternative

Implementierungen der Sprache Ruby, zum Beispiel dieses JRuby, was ich vorhin schon erwähnt habe, oder auch Rubinius, was eine weitere Alternative ist. Die haben kein GIL. Darüber hinaus gibt es auch Alternativen zu Thread-Programmierungen. Und da gibt es eine ganze Reihe von Bibliotheken, auch im Ruby-Bereich, die einem dort Alternativen ermöglichen.

Auch das kann man sich einmal anschauen. Und man muss auch gar nicht unbedingt Threads verwenden. Früher war es unter Unix gang und gäbe, wenn man Pseudoparallelität erreichen möchte, dass man einfach parallel mehrere Prozesse startet. Auch das kann auch heute noch ein gangbares Mittel sein. Das funktioniert zum Beispiel in der Webentwicklung

wunderbar, weil HTTP ist ein zustandsloses Protokoll. Und ich kann Einkommende anfragen wunderbar auf verschiedene Prozesse oder aber sogar auf verschiedene Server verteilen. Das geht ganz gut. Und zu guter Letzt muss man sich auch ernsthaft die Frage stellen, ist das für mich und für meinen Anwendungsfall wirklich

wichtig. Ich persönlich, mein Brot- und Buttergeschäft sind so klassische Intranet-Anwendungen für Unternehmen. Und da hat mich noch nie ein Kunde gefragt, wie gut ich denn seinen Multicore Prozessor auslaste. Also da spielt das wirklich keine Rolle. Es ist einfach schnell genug. Ja, selbstverständlich.

Also Ruby ist auf Unix-artigen Systemen groß geworden und unterstützt natürlich alles, was man so auf Unix-Systemen mit Prozessen, mit Dateien und so weiter machen möchte. Weiteres Vorurteil ist, dass Ruby-Entwickler arrogant sein. Und das ist eine Vorurteil, was ich häufig höre von Leuten, die zwei entscheidende Fehler machen.

Erstens verwechseln sie Ruby und Rails. Jeder Rails-Entwickler nutzt natürlich Ruby, aber nicht jeder Ruby-Entwickler nutzt auch wirklich Rails. Und der zweite Fehler ist, die Rails-Community zu reduzieren auf so ein paar Webhipster und den hier. Das ist der Erfinder von Ruby on Rails. David Heinemeyer oder DHH. Das ist eine etwas kontroverse Persönlichkeit.

Der sagt gerne seine Meinung und nutzt drastische Worte dafür. Und das kommt bei vielen als arrogant rüber. Aber tatsächlich, wenn es ein Vorbild gibt für Leute in der Ruby-Community, dann ist das eher er. Und Metz ist ein sehr ruhiger, ein sehr freundlicher, hilfsbereiter und zutiefst bescheidener Mensch. Und das sind eigentlich eher die Werte,

die man in der Ruby-Community vorfindet. Ich habe noch nicht ganz am Ende, aber ich habe noch ein paar Tipps, ein paar interessante Projekte in Ruby oder Dinge, die man mit Ruby machen kann, die vielleicht für euch interessant sind. Zum einen für System-Administratoren. Und da liegt es natürlich auf der Hand,

Ruby als Scriptingsprache zu verwenden. Also so, egal ob es jetzt kleine Fire-and-Forget-Skripte sind oder so diverse Skriptesammlungen, die vielleicht öfter zum Einsatz kommen. Wenn ich mit meiner Bash-Skripte nicht mehr Herr werde, dann sollte ich mal einen Blick auf Ruby werfen. Und ich hatte es vorhin schon gesagt, zwei der bekanntesten

Ruby-Projekte sind im Bereich Konfigurationsmanagement. Das sind auch zwei der Marktführer in dem Bereich. Das sind nämlich Puppet und Chef. Wenn man ehrlich ist, sind die sehr, sehr also, die tun sich nicht viel. Die Features sind sehr ähnlich. Wesentlicher Unterschied ist aber, dass Puppet eine eigene Konfigurationssprache verwendet. Und wenn man da ein bisschen Ruby beherrscht, ist das nicht schlecht, weil man kann

Puppet nämlich sehr schön erweitern. Chef hat keine eigene Konfigurationssprache, sondern nutzt tatsächlich Ruby auch als Konfigurationssprache. Die Beispiele machen eigentlich dasselbe. Es geht darum, sicherzustellen, dass auf einem System ein bestimmter Benutzer vorhanden ist. Und das sieht dann halt in Puppet in der eigenen Sprache so aus. Und in Chef

sieht es so aus, wenn man ganz genau hinguckt, wird man vielleicht schon erkennen von den vorangegangen Beispielen. Das hier ist Ruby Code. Also das ist ein kleiner Unterschied. Ein kleines Tool, was ich persönlich total gerne mag, was ich deswegen auch immer gerne vorstelle, ist Backup. Und das macht genau das, nämlich Backups. Es ist kein Ersatz für ein großes verteiltes System, wie

Bacula oder Amanda oder sowas. Aber wenn ich nur mal ganz schnell einen Server aufsetzen muss, vielleicht sogar unter Zeitdruck, möchte aber nicht darauf verzichten, ein ordentliches Backup zu haben. Dann kann man sich das mal anschauen. Backup ermöglicht es, Dateien oder Verzeichnisse zu sichern. Und es kann auch Dumps aus Datenbanken ziehen. MySQL,

Postgres zum Beispiel oder auch OpenLDAP. Wenn ich dann ganz viel Daten gesichert habe, möchte ich vielleicht Platz sparen und das Ganze ein bisschen komprimieren. Das kann Backup auch. Und dann möchte ich es irgendwo hinschieben. Zum Beispiel in lokales Verzeichnis oder per SFTP, SCP, irgendwo hin. Verzeichnisse kann ich auch

mit R-Sync synchronisieren, wenn ich das möchte. Und ich kann meine Backups auch auf den Cloud-Speicher hochladen, S3 oder ähnliches. Und wenn ich das mache, dann möchte ich vielleicht auch noch, dass meine Daten verschlüsselt sind. Und auch das kann Backup. Und das Ganze konfiguriere ich mit wenigen Zeilen Ruby Code. Sehr schönes Tool. Für Webentwickler

bietet sich Ruby natürlich an, ganz klar. Ruby on Rails ist mittlerweile 10 Jahre alt. Es ist eines der umfangreichsten Frameworks überhaupt, was Webentwicklung angeht. Wenn man bedenkt, dass es unzählige Plugins dafür noch gibt, die das Ganze erweitern, würde ich sogar behaupten, es ist das kompletteste Webframework außerhalb der PHP Welt. Und es lohnt sich, sich damit zu beschäftigen,

wenn man Webentwicklung machen möchte. Allerdings, weil es so umfangreich ist, fällt der Einstieg heutzutage nicht mehr ganz so leicht. Am anderen Ende des Spektrums gibt es deshalb auch noch andere interessante Frameworks, wie zum Beispiel Sinatra. Sinatra ist ein Webframework, das ganz schlank ist und ganz übersichtlich. Dieses Beispiel hier ist eine lauffähige Sinatra-Anwendung.

Mehr Code brauche ich nicht, um eine ganz kleine Sinatra-Anwendung zu schreiben. Die macht nicht viel, die wartet darauf, dass jemand die Startseite anfragt und gibt dann einfach den String Hello World zurück. Aber das kann ich so starten und ausführen, wird ein Server hochgefahren und dann läuft das. Die ganze Dokumentation zu Sinatra

ist eine einzige Datei, ein langes README, das natürlich sehr länglich ist, aber nicht ausufernd. Und da steht alles drin, was Sinatra kann. Trotzdem ist es ein ernsthaftes Tool, ein ernsthaftes Werkzeug, mit dem man auch durchaus aufwändige Anwendungen realisieren kann. Ja, und für alle anderen vielleicht auch noch ganz interessant, mit

GitLab und READMEIN gibt es zwei ganz schöne Projektmanagements, Software-Projektmanagement-Tools, die in Ruby geschrieben sind. Wer sich lieber spielerisch dem Thema annähern möchte, der findet vielleicht in der GOSU-Bibliothek die entsprechenden Bausteine zur Spieleprogrammierung. Und wer lieber GUI-Anwendungen schreibt, der findet ganz brauchbare Bindings

für GTK Plus und Qt. Zu guter Letzt will ich ehrlich sein, ich gucke mir natürlich immer noch gerne neue Programmiersprachen an. Zumindest dann gerne, wenn ich sehe, dass sie bei Ruby etwas gelernt haben. Und das sieht man tatsächlich, insbesondere bei zwei einigermaßen neuen Sprachen. Das ist zum einen CoffeeScript. CoffeeScript ist eine

Programmiersprache, die zu JavaScript kompiliert. Und das ist ganz wichtig, weil JavaScript heutzutage die am weitesten verbreitete Programmiersprache überhaupt ist. Heutzutage kann jedes Telefon JavaScript ausfügen. Aber JavaScript ist keine schöne Sprache. JavaScript macht nicht unbedingt Spaß. Und CoffeeScript versucht, das zu ändern, indem es all die Sachen,

die schlecht sind an JavaScript, verbirgt. Die macht es gar nicht nutzbar. Und all die Sachen, die gut sind an JavaScript, werden nutzbar gemacht durch eine Syntax, die sich ganz viel bei Python und Ruby abschaut. Und ich persönlich schreibe sehr, sehr gerne CoffeeScript. Das macht mir wirklich Freude. Die zweite Sprache, die man vielleicht im Auge

behalten sollte, ist Elixir. Und Elixir ist eine Sprache, die kompiliert zu Bytecode für die Erlangen-VM. Und Erlang ist eine Programmiersprache, die aus dem Telekommunikationsbereich stammt und die ein ganz interessantes Konzept für Nebenläufigkeiten hat. Da werden ganz viele parallele Prozesse aufgemacht, die auch auf mehrere Rechner verteilt werden können.

Und die alle gemein haben, dass sie darauf ausgelegt sind, auch mal zu scheitern. Also der Fall, dass das irgendwie schief geht und abgeschossen werden muss, ist da fest mit eingeplant. Und das bedeutet, dass man mit Erlang sehr gut und sehr einfach verteilte Systeme bauen kann, die extrem fehlertolerant sind. Und

Erlang ist keine besonders neue Entwicklung. Es ist eine funktionale Programmiersprache. Auch das ist für manche ungewohnt. Und hat eine sehr sparsame Syntax, also auch nicht so angenehm zu benutzen. Elixir ändert das, weil Elixir macht alle Features von Erlang nutzbar, mit einer Syntax, die sich ganz, ganz viel von Ruby abgeschaut hat. Noch nicht weiter verwunderlich.

Der Erfinder von Elixir ist ein Mitglied des Ruby on Rails Core Teams. Und Elixir ist noch nicht ganz fertig. Die arbeiten fieberhaft an einer 1.0 Version. Die wird aber bald rauskommen. Und Dave Thomas, der Autor des bekanntesten Buchs zu Ruby, hat gesagt, dass ihn keine Programmiersprache seit Ruby mehr so begeistert hat, wie Elixir.

Also ganz spannendes Thema. Sollte man mal auf dem Radar behalten. So. Und das war es dann fast von mir. Ich möchte nochmal abschließend also sagen, dass ich Ruby ganz besonders schön finde, weil es so vielseitig ist und auf so viele Anwendungsfälle passt. Ruby macht mich persönlich als Entwickler besser. Ich habe

heute noch, ich sehe immer wieder Sachen, die mir den Ansporn geben, mich selber zu verbessern. Und das habe ich so nur in Ruby kennengelernt. Und ich habe heute auch nach den ganzen Jahren immer noch unheimlich Spaß daran, Ruby Code zu schreiben. Viel mehr, als ich jemals hatte, in einer anderen Programmiersprache zu arbeiten. So und wer jetzt Lust bekommen hat

und direkt loslegen möchte, dem empfehle ich meinen Blick zu werfen auf die offizielle Website von Ruby. Da gibt es eine Linkdokumentation, wo erstaunlicherweise keine eigene Dokumentation vom Ruby Projekt zu finden ist. Aber es gibt ganz viele, ganz tolle Links zu verschiedenen Projekten. Zum Beispiel Try Ruby. Da kann ich Ruby direkt mal in meinem Webbrowser ausprobieren.

Es gibt Aufgabensammlungen, Tutorials und so weiter. Also alle Links, die man da findet, kann ich alle uneingeschränkt empfehlen. Wer lieber Papier in die Hand nimmt, der findet auch viele gute Bücher zu Ruby. Man muss ein bisschen aufpassen. Manche sind so ein bisschen in Jahre gekommen. Aber ich habe mal drei rausgepickt, die ich denke, die man immer noch nutzen kann. Wer noch nie programmiert

hat und Ruby als erste Sprache nutzen möchte, sich vielleicht auch spielerisch eher dem ganzen nähern möchte, der kann mal das Learn to Program sich anschauen. Das älteste und bekannteste Buch zu Ruby ist das sogenannte Pickaxe-Buch. Das ist dieses hier. Und das ist das einzige Buch, das auch heute noch regelmäßig aktualisiert wird.

Wer auf dem neuesten Stand sein möchte, der sollte sich dieses Buch angucken. Und das letzte ist schon ein bisschen in Jahre gekommen und auch um Himmels Willen keine Einführung. Das ist nichts für Anfänger. Aber dieses Buch hier hat Metz als Co-Autor. Und das heißt, da findet man tatsächlich so ein paar Dinge, die nirgends anders wirklich dokumentiert

sind. Deswegen ist auch das nach wie vor empfehlenswert. Und wer es gar nicht abwarten kann, der sollte gleich rübergehen in Raum C118. Da findet parallel hier die RedFrogConf statt. Das ist also ein Entwicklerraum hier, wo das ganze Wochenende Vorträge zu Ruby laufen.

Jetzt in diesem Augenblick läuft dort ein Einsteiger-Workshop in Ruby. Der läuft jetzt schon seit 14 Uhr. Aber ich habe mit den Leuten gesprochen. Sie freuen sich, wenn jetzt welche rüber wechseln möchten, also später ankommen. Sie sind dort ganz, ganz herzlich willkommen. Und ich wurde eben noch darauf hingewiesen, vom 26. bis 28.

September findet in Köln das RailsCamp statt. Und eine ganz interessante Veranstaltung, so eine Unconference zu Ruby- und Rails- Themen, aber auch zu anderen Dingen. Also wer klettern lernen möchte oder sowas kann das da auch tun. Kann man also gerne mal einen Blick drauf werfen. Gut, das war es von

meiner Seite. Ich bedanke mich ganz herzlich für die Aufmerksamkeit. Und ich glaube, wir haben noch ein bisschen Zeit für Fragen.

Ja, Closures hatte ich. Ach so, die Frage war, ob es Lambdas und Closures gibt. Closures hatte ich vorhin gezeigt, diese Code-Blöcke in Ruby. Das sind Closures. Es gibt auch ein Konstrukt, was Lambda tatsächlich wortwörtlich heißt.

Ich muss aber gestehen, ich bin der Funktionalprogrammierung nicht so bewandert. Ich habe mir sagen lassen, es ist ein bisschen was anderes, als man das aus funktionalen Sprachen kennt. Da kann ich jetzt aber nicht mehr mit großem Wissen glänzen an der Stelle. Die Frage ist nach Debuggern für Ruby.

Und Ruby hat einen Debugger mitgeliefert und eingebaut. Es gibt auch Alternativen dazu, also andere Projekte, die Debugger realisiert haben. Wenn man kein Problem damit hat, auf der Kommandozeile zu arbeiten, funktionieren die wunderbar. Also wirklich ganz tolle Tools. Wer gerne IDI verwenden möchte, es gibt

auch Ruby-IDIs. Mit Aptana gibt es ein Plugin für Eclipse. Es gibt ein Plugin für NetBeans und so weiter. Die haben dann auch grafisches Debugging eingebaut.

Die Frage ist, bei der Folie Ruby ist langsam. Da hatte ich eine Grafik, wo nicht stand, was die Y-Achse bedeutet. Mir ging es nur darum zu zeigen, dass es mit jeder Version schneller geworden ist. Dieser spezielle Benchmark wurde mit Hilfe von Ruby on Rails durchgeführt und es geht da um Request

pro Sekunde. Das heißt, mehr bedeutet schneller. Aber der Punkt war, wirklich die Ruby-Entwickler arbeiten an diesem Thema Performance kontinuierlich. Jede Version ist bisher eigentlich immer schneller geworden. Da ganz hinten.

Ja, also die Frage ist nach unterschiedlichen Ruby-Versionen. Das ist eine sehr, sehr gute Frage, weil genau dort hinten auf dem Rechner Ruby 1.8

abläuft. Das ist eine sehr, sehr alte Version. Die ist so alt, dass die nicht mehr weiter gepflegt wird. Das heißt insbesondere auch, nicht mehr mit Patches versorgt wird, wenn es Sicherheitslücken gibt. Das Ganze ist letztes Jahr schon mal ausgelaufen. Da hat sich dann Gott sei Dank ein Sponsor gefunden, eine Firma, die das gesponsert hat,

dass das jetzt noch ein Jahr weiter gepflegt wurde. Aber seit Juli, glaube ich, ist es vorbei. Also 1.8 ist eine Ruby-Version, die man nicht mehr produktiv einsetzen sollte. Alles ab 1.9.3 kann man bedenkenlos verwenden. Wenn man die Möglichkeit hat, empfehle ich allein schon wegen dieser Performance-Verbesserung, aber nach Möglichkeit die neueste Version zu nutzen.

Okay, also das war

offensichtlich keine Frage. Es geht darum, dass in der Ruby-Community vielleicht neuere Versionen stärker bevorzugt werden als anderswo, was insbesondere da das Problem ist, wo man noch sehr alte Systeme zu pflegen hat. Habe ich jetzt nicht so viel Erfahrung mit, kann ich nicht einschätzen, ob das in anderen Communities

besser gehandelt wird. Ich kann nur sagen, Ruby 1.8 wird seit, ich glaube, mittlerweile sechs, wenn ich sogar sieben Jahre nicht weiterentwickele. Und ich finde, das ist ein sinnvoller Zeitpunkt, mal zu sagen, Leute, wir können es nicht mehr machen. Es sind alles Freiwillige, oder viele Freiwillige, die an so einem Projekt mitarbeiten. Und da muss man irgendwann einen Schlussstrich ziehen. Und nach sechs, sieben Jahren, oder sogar acht Jahren, finde

ich das persönlich vernünftig.

Ich glaube, das führt jetzt hierzu weit. Die Diskussion kann man sicherlich gleich auf eine Tür weiterverhören. Aber eben hatten sich noch andere gemeldet.

Also, die Frage ist danach, wie man, wenn man jetzt einen Fehler entdeckt hat im Ruby-Projekt, da am sinnvollsten einsteigen kann, wenn man den fixen möchte, ob es da eine Anleitung oder sowas

gibt. Allgemeingültig gibt es das wahrscheinlich nicht. Bei den vielen Projekten wird man es aber entweder im ReadMe finden, oder in einer eigenen Datei, Contributing oder irgendwie sowas, wo eigentlich diese Regeln erläutert sind. Letztlich ist es aber common sense in der Regel. Die meisten Leute freuen sich, wenn man vorher mal nachfragt, bevor man einfach Code schickt.

Man sollte freundlich bleiben an der Stelle. Und der Rest ist dann mehr der Prozess, der meistens halt über GitHub abgebildet wird. Also da würde ich wirklich mal da

reinschauen, ob es dazu nicht Dokumentationen gibt. Im Wiki, im ReadMe, in einer speziellen Datei, die das erklärt. Also GitHub zum Beispiel forciert das mittlerweile auch. Die möchten, dass jedes Projekt so eine Datei zur Verfügung stellt, wo die Regeln zur Mitarbeit beschrieben sind. Und immer mehr machen das jetzt eigentlich auch.

Da vorne? Absolut. Die Frage ist, ob ich einem Python-Entwickler davon überzeugen kann, Ruby einzusetzen. Und ist die Antwort ganz klar, nein kann ich nicht.

Im Gegenteil, die Sprachen sind in vielen Dingen sehr eng beieinander. Muss man ganz klar sagen. Und es gibt manche Dinge, die vielleicht in der Ruby-Welt ein bisschen netter sind. Also wenn ich sowieso Puppet, Chef oder Rails einsetzen möchte oder muss, dann macht es natürlich Sinn, Ruby zu verwenden. Ich habe aber in Python auch Alternativen, auch in den Bereichen.

Und auch das ist eine wunderbare Programmiersprache. Da werde ich dich wohl nicht überzeugen können. Tut mir leid. Die Frage ist nach IDEs für Ruby und der Qualität von dem Qt-Binding. Zu letzterem kann ich leider nicht sagen,

habe ich selber noch nie benutzt. Das, was ich gelesen habe, ist, dass es brauchbar sein soll. Mehr weiß ich nicht. IDEs gibt es wie gesagt einige. Also wenn ich ohnehin schon Eclipse benutze, dann sollte ich mir dieses Aptana-Plugin angucken. Ich persönlich mag das nicht besonders, aber ich bin auch kein IDI-Benutzer. NetBeans hat ein ganz gutes Ruby-Plugin. Das ist deswegen vor allem

ganz gut, weil zumindest eine Zeitlang von Sun gesponsert wurde. Die haben da richtig auch Geld reingepumpt. Und wer ein kommerzielles Produkt sich mal anschauen möchte, mit RubyMine gibt es eine ganz beliebte IDI, die wie gesagt nicht Open Source ist, aber die hat auch sehr, sehr viele Anhänger.

Also auch da kann man mal einen Blick drauf werfen. Ja, wenn es keine Fragen mehr gibt, dann nochmal ganz herzlichen Dank. Hat mir viel Spaß gemacht.