Das war sie nun unsere zweite Iteration der Germany.rb am 20. und 21. August 2011. Es waren ca. 25 Leute da und es gab insgesamt 13 auf Video aufgezeichnete Vorträge. Hier eine kleine Zusammenfassung wie es ablief und wie es weitergehen könnte.
Method chaining - also die implementierung einer Methode durch verketten mehrerer anderer ist durch Ruby on Rails zu einer gewissen Popularität gelangt. Während sich Rails hier auf ein einfaches Namenschema und alias verlässt, bietet DataMapper hier eine Technik an, die sich vorzüglich für einen Ausflug in Rubys Objektmodell eignet. Diese Gelegenheit will ich nicht an mir vorüber gehen lassen und die Implementierung namens Chainable hier vorstellen.
Sequel ist wohl die DB-Zugriffsschicht, mit der sich die wenigsten Rubyisten auskennen. Dabei ist sie meiner Meinung nach die beste reine Skripting-Bibliothek von allen dreien. Das äussert sich schon darin, dass Sequel mit keinerlei Core-Extensions wie ActiveSupport oder Extlib daher kommt. Einige werden zwar optional mitgeliefert, aber nicht standardmässig geladen.
Wie bereits erwähnt, beschäftigt sich Sequel nur mit SQL und das mit nur minimalen Abstraktionen - Sequel ist also kein ORM. Dafür kommt Sequel mit der größten Anzahl an Datenbank-Adaptern, momentan über 20. Implementierungen für verschiedene Connection-Pooling-Strategien und Sharding finden sich auch.
Plugins gibt es für viele interessante SQL-Funktionen, zum Beispiel für Windows (also, nicht das OS) oder Recursive Table Expressions.
Darüber hinaus kommt Sequel mit einem Kommandozeilentool, dass sich als Ersatz für den datenbankspezifischen Client verwenden lässt, allerdings im Grunde nur IRB mit vorgeladener Datenbank ist.
Auf einem der letzten germany.rb-Treffen kam zwischendurch eine Frage auf, die wohl doch viele beschäftigt: was unterscheidet eigentlich die drei großen Persistenzbibliotheken ActiveRecord, DataMapper und Sequel? Ein Thema, dass schon so manchen hat fragen lassen, aber selten ordentlich beantwortet wurde. Daher will ich in einer kleinen Serie von Posts alle drei im Detail vorstellen. Dieser Post wird als Auftakt dienen und eine grobe Unterscheidung versuchen.
Eine Weile (mehr als 4 Jahre) ist es inzwischen her, das Murphy hier zuletzt etwas zu rescue geschrieben hat. In der Erwartung, dass sich der Stoff inzwischen gesetzt hat, will ich hier zwei rescue-Varianten nochmal näher unter die Lupe nehmen: die Modifikator-Variante und die Methoden-Variante. Ist zwar kein Sonntag, aber hier mal wieder etwas Syntax.
Das eigentlich unter dem Titel "Forentreffen" geborene, aber spontan in "Germany.rb" umbenannte Treffen im Sublab in Leipzig ist nun vorbei. Zu allererst an dieser Stelle: vielen Dank an das Sublab für den Ort, das Fachgesimple und die herzliche Aufnahme. Die spontan gefundenen Themen gingen von Encoding über Concurrency-Abstraktionen bis auf der Suche nach den letzten 2 Byte in CodeGolf-Problemen. Zum Schluss gab es eine interessante Diskussion über das Projekt, die ich im Folgenden zusammenfassen will. Wiederholung wahrscheinlich.
Ein kleiner Nachschlag: Manchmal gehen Dinge plötzlich schnell. Nachdem das MRI-Team mit der Dual-Lizensierung unter GPL2 + Ruby License nicht besonders glücklich ist, wird momentan diskutiert, die GPL gegen die 2-clause BSD-Lizenz auszutauschen. Wer also Spass an Lizenz-Diskussionen hat, ist da genau richtig. Eine kurze Zusammenfassung der Gründe findet sich in den Notizen für das Ruby Developers Meeting 2010.
Ab Revision 29262 ist es dann auch so weit.
Gute Programmierer kommen ja bekanntlich in den Himmel. Das problematische ist, dass wir uns auf dem Weg dorthin durch das Fegerfeuer der Flamewars und Plattform-Kriege kämpfen müssen. Cross-Plattform-Umgebungen wie die JVM haben die Sache nicht einfacher gemacht: ich kann mich jetzt nicht nur um mein Betriebssystem, sondern auch mein Laufzeitsystem trefflich streiten. (Fast alle) Rubyisten nehmen die Abkürzung: wir kommen überall hin. Ein nicht immer ganz ernst gemeinter Überblick über die letzten Wochen: einmal Hype für alle.
Ruby 1.9.2 ist jetzt eine Weile draussen und mit Rails 3 empfiehlt nun auch das größte Ruby-Projekt seinen Einsatz. Daher werde ich mal den Syntax-Sonntag wieder aufleben lassen und ein paar der Neuigkeiten in 1.9.2 vorstellen. Erster Kandidat: die verbesserte String#%-Methode. Die hier verwendeten Beispiele stammen aus der Doku von Sven Fuchs i18n-Bibliothek.
Wie Laurent Sansonetti auf dem MacRuby Blog ankündigt, findet sich auf der Downloadseite nun die erste Beta zu MacRuby 0.5.
MacRuby hat sich eine nahtlose Integrierung in das Ruby-ähnliche Objective-C-Objektsystem auf die Fahnen geschrieben. Auch ansonsten ist MacRuby ein interessantes Projekt: es basiert zwar auf dem Standardinterpreter MRI, tauscht aber dessen virtuelle Maschine (YARV) gegen einen LLVM-Unterbau aus.
0.5 ist bei weitem noch keine komplette Implementierung. Während die Kernsprache inzwischen fast komplett implementiert ist, werden nur 80% der Tests der Core-Bibliothek und 72% der Standardbibliothek erfüllt.
Beim basteln bin ich wieder über einen kleinen, aber feinen Unterschied zwischen Ruby 1.9 und Ruby 1.8 gestoßen, der eventuell verwunderlich sein kann: der Lookup von Konstanten wurde geändert. Meistens wird das nicht auffallen, allerdings gibt es einige Fälle, die einen erstmal etwas ratlos zurück lassen...
Bildquelle: http://www.flickr.com/photos/piulet/ / CC BY-NC-ND 2.0
Ist zwar ein halbes Jahr her, aber jetzt gibt es endlich die Mitschnitte der EuRuKo 2009 auf Blip.tv zu sehen. Angeboten werden die Videos im Flashstream, als Download, als Streams für iTunes, Miro, Channels.com oder einfach nur als RSS.
Besonders möchte ich auf den Talk von Stephan Kämper hinweisen, den Usern unseres Forums besser bekannt als Zehnbambusgarten. Meinen Rant über die Dokumentationsmoral von Rubyisten ("A Blues in Doc-Minor") findet ihr in der Lightning Talk Session 1, in etwa bei 25:40, Mikroprobleme und PHP-Werbeshirt inklusive ;).
Coverity ist ein Hersteller von Tools zur statischen Codeanalyse. In Kooperation mit dem amerikanischen Department of Homeland Security prüft er unter anderem kostenlos die Qualität von Open Source-Software. Sowohl Python, Perl und Ruby liefern sich seit einiger Zeit einen freundschaftlichen Wettstreit darum, ihre Software bei Coverity-Scans bugfrei zu halten.
Die seit 2008 verstärkten Bemühungen um die Qualität des MRI-Teams scheinen sich auszuzahlen, zumindest wenn man den diesjährigen Report liest (Registrierung nötig, Zusammenfassung in der Presseerklärung). Der MRI erhält neben 3 anderen Projekten (Samba, tor und OpenPAM) eine Rung 3-Zertifizierung. Das Rung-System (Rung = Sprosse einer Leiter) ist eine Art Belohnungssystem für Entwickler: wer alle in einer Stufe gefundenen Bugs bereinigt, wird in eine höhere Stufe aufgenommen. In dieser werden andere - angeblich fortgeschrittenere - Tests ausgeführt. 3 ist die aktuell höchste Stufe.
Besonders interessant ist, dass das MRI-Projekt zwar seit 2006 an Coveritys Angebot teilnimmt, bis 2008 aber keinerlei besonderen Bestrebungen gezeigt hat, sich um die gefundenen Probleme aktiv zu kümmern. 2008 wurden die Tests dann als wichtiger Indikator gesehen und gefundene Bugs mit Nachdruck gefixed.
Ein wenig Vorsicht sollte man natürlich walten lassen: Zum einen testet Coverity nur die C-Komponenten. Große Teile der Ruby-Distribution sind in Ruby selbst geschrieben, über die keine Aussage getroffen wird. Da diese Teile jedoch auch in anderen Interpretern zum Einsatz kommen, sind sie auch keine spezielle Eigenschaft des MRI. Auch sind große Teile der Core-Api des MRI in C geschrieben, werden also durchaus erfasst.
Zuletzt ist natürlich zu sagen, dass diese Scans sich nur auf statisch erkennbare Bugs beziehen, meist Fehler in der Speicherverwaltung oder der inkorrekten Verwendung verschiedenster Low-Level-Funktionen. Die nachlässige Quellcodedokumentation und die fehlende Hackers Guide werden leider nicht erfasst.
Trotzdem an dieser Stelle von mir: herzlichen Glückwunsch an das MRI-Team zu ihrem neu gefundenen und konsequent umgesetzten Qualitätswillen.
Nachtrag: Heise berichtet auch
Yugui hat in einer Mail an die Core-Mailingliste mitgeteilt, dass die Release-Schedule von Ruby 1.9.2 abgesagt wird. Diese war bereits recht weit fortgeschritten: die dritte Preview für 1.9.2 war für den 25. September angekündigt, einhergehend mit einem Feature Freeze. Als Begründung führt sie den Entschluss des MRI-Entwicklerteams an, dass der 1.9.2-Interpreter vor dem Release die RubySpec erfüllen muss. Diese Entscheidung würde aber einiges an Arbeit nach sich ziehen und ist somit nicht innerhalb des Rahmens zu erfüllen.
Die Bedeutung dieses Ereignisses ist nicht zu unterschätzen: lange Zeit war die RubySpec eine Bemühung, das Verhalten des MRI so zu beschreiben, dass andere Implementierungen ihre Konformität zu ihm testen können. Nach dieser Entscheidung ist die RubySpec nun eine Testsuite, die Ruby interpreterunabhängig beschreibt. Zu diesem Zweck bringt sie sogar eine simple Implementierung einer Specsuite mit, die es leicht machen soll, einen unvollständigen Miniinterpreter zu erstellen, der dann zumindest die Testsuite ausführen kann - auch, wenn er bei weitem Ruby nicht komplett implementiert.
Der Sommer geht zwar langsam zuende (oder: an meinem Ende der Welt ist er es schon), trotzdem kann man seinen Ruby-Code noch sommerlich kleiden (und in der CPU ist eh immer wohlig warm). Wie wärs mal mit Flip-Flops?
Bildquelle: http://www.flickr.com/photos/stuckincustoms/ / CC BY-NC-SA 2.0