Ruby-Mine

mruby

2012-04-20T18:32:00Z

Das mruby Repository wurde soeben auf Github geöffnet. Sofern es nicht bekannt sein sollte: mruby ist eine vollständige Neuimplementierung von Ruby mit dem Fokus auf Embedded-Systems, Mikrocontroller oder auch als Integration in vorhandene Applikationen (ähnlich zu Lua). Insofern sehr interessant da die Entwicklung von der japanischen Regierung gesponsert wurde und von matz angeführt wird.

Germany.rb 2011 review

2011-09-23T15:47:00Z

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.

Ort

Wie auch letztes Jahr trafen wir uns wieder im sublab (ein Hackerspace in Leipzig). Positiv war die offene Atmosphäre, welche uns die Freiheit gab auch abseits der Vorträge in einer anderen Ecke zu diskutieren und zu hacken. Der bereitgestellte Internetanschluss gab uns weitere Freiheiten mit denen wir nichtmal gerechnet hatten. Unsere spendenbasierte Nutzung hatte laut Feedback der sublab Betreiber gut geklappt. Dabei hatten wir die Teilnehmer darum gebeten, eine kleine Spende nach eigener Wahl im sublab zu hinterlassen. Als Kontrapunkte wurde von Teilnehmern die Sanitäranlage und die Raumtemperatur erwähnt.

Sponsoren

Überraschenderweise hatten sich zwei Sponsoren gefunden. Das ifbbw hat uns mit einer tollen Kameraausrüstung ausgestattet und castaclip hat den Beamer bezahlt und für alle Teilnehmer Essen für beide Tage gesponsert.

Auch wenn nicht direkt als Sponsoring gedacht, haben wir uns am Samstag abend das Essen der im Sublab stattfindenden Phantomspeisung schmecken lassen. Vielen Dank auch an diese Seite.

An dieser Stelle ein grosses Dankeschön – im Namen der Teilnehmer, welche sich sehr über das Essen gefreut haben und im Namen vieler anonymer Internetnutzer, die sich die Vorträge im Nachhinein noch einmal als Video hier anschauen können.

:next

Um eine nächste Inkarnation möglich zu machen, hatten wir nach Herkunftsort und Feedback gefragt. Es kamen Leute aus Leipzig (was wohl klar war), Berlin (die meisten), Kamen (NRW), Unna (NRW), Offenbach/Main und Beijing. Als Feedback gab es u.a. die folgenden konkreten Vorschläge:

Abends länger :D
Pro: Hbf-Shuttle, “Kostenlosigkeit”, lecker Essen ;)
Con: Sanitäre Anlagen, Raumtemperatur
War zwar nicht da aber etwas zentraler wäre cool ;)

Nach einigen Diskussionen sind wir zu den folgenden Schlüsselelementen gelangt, welche die Zukunft der Germany.rb umrahmen sollen. Was wollen wir weiterhin erreichen und was wollen wir vermeiden:

Wir wollen keine bisher existierende Veranstaltung ersetzen. Weder wollen wir eine Konkurrenz zur EuRuKo aufbauen noch wollen wir den Platz einer deutschen Ruby Konferenz einnehmen.
Wir wollen einen Ort für Leute bieten, die normalerweise keine Ruby Konferenzen besuchen. Sei es aus finanziellen oder organisatorischen Gründen.
Wir sind zufrieden mit der derzeitigen Art und Anzahl der Vorträge und wollen dies so beibehalten.
Wir wollen die Möglichkeit ausbauen, parallel oder nach dem Vortragsprogramm an Ideen zu hacken. Dazu wollen wir die Möglichkeiten der gemeinsamen Kollaboration ausbauen und den Teilnehmern die Möglichkeit bieten auch bis in die tiefe Nacht zusammen zu sitzen und an Ideen zu arbeiten. Das ganze soll also um ein Hackfest Attribut ausgebaut werden.
Wir wollen den niedrigen Kostenfootprint beibehalten oder sogar noch weiter senken.
Wir wollen mit der Teilnehmeranzahl nicht stetig wachsen. Die derzeitige Teilnehmeranzahl von weniger als 30 Leuten lässt sich leicht und kostengünstig unterbringen. In Zukunft müssen wir austesten bis zu welchem Limit dies weiterhin möglich ist. Sollte die Teilnehmerzahl steigen, würden wir lieber die Häufigkeit der Veranstaltung erhöhen anstatt Gebühren zu verlangen.

Da wir beim nächsten Mal nicht blind davon ausgehen können, das wir erneut das Glück haben so tolle Sponsoren zu finden, würden wir gerne nach weiteren Möglichkeiten forschen, die Veranstaltung in diesem Rahmen weiterzutreiben. Jeder ist dazu aufgerufen, Ideen zu äussern die es ermöglichen die nächste Germany.rb in diesem Rahmen weiterhin so zu organisieren.

Vorträge

Hier nun ein Rundumschlag mit Details zu jedem einzelnen Vortrag.

“Intro” von Florian

Eröffnungsrede von Florian mit einer Zusammenfassung der wichtigsten Eckdaten und einer groben Planung des Ablaufes.

“ruby-lang.org” mit allen Germany.rb Teilnehmern

Eine kleine Einführung in die unserer Meinung nach wichtigsten Online-Ressourcen von Ruby für die Ruby Einsteiger beim Treffen. Da viel Input vom Publikum gekommen ist, ist die Tonqualität rech sub-optimal. Sorry für das und das unstrukturierte Vorgehen.

“Treating Code As an Essay” von Jan

Vortragsfolien

Jan gab einen Einführungsvortrag in die Grundlagen von Ruby. Basierend auf dem Aufsatz von Matz “Treating Code As an Essay”.

“Wie arbeitet eigentlich RDoc” von Marvin

Vortragsfolien

Marvin spricht über den internen Aufbau von RDoc, mit dem Ziel eigene Erweiterungen für diese Bibliothek zu schreiben.

“RDoc PDF Output” von Marvin

Vorstellung von Marvins RDoc Erweiterung Papyrus, mit der eine Generierung von PDF Dokumentation möglich ist.

“Redmine Fork ChiliProject” von Felix

Felix spricht über den Redmine Fork ChiliProject.

“Vagrant” von Sebastian

Sebastian spricht über Vagrant, ein Verwaltungsprogramm für Virtuelle Maschinen von Virtual Box.

“Padrino” von Florian

Florian spricht über das Webframework Padrino.

“Operations” von Felix

Felix spricht über den gesamten Deployment-Prozess von Webapplikationen und stellt die jeweiligen Alternativen vor.

“API Leipzig” von Martin

Martin spricht über die Opendata Initiative API Leipzig.

“Tweak your Ruby Console” von Jan

Vortragsfolien

Jan spricht über Möglichkeiten seine eigene Ruby Konsole zu erweitern respektiv zu optimieren.

“OMG, Modules!” von Florian

Unser Metraprogramming Vortrag von Florian der allerlei Spielereien mit Modulen erklärt.

“CodeRay 1RC1” von Kornelius

Vortragsfolien

Kornelius spricht über das baldige CodeRay Release 1.0

RubyKaigi 2011

2011-08-14T14:04:00Z

Vom 16 bis 19. Juli 2011 fand die 6. und letzte RubyKaigi in Tokyo statt. Dabei handelt es sich neben der RubyConf und EuRuKo um die wichtigste jährliche Ruby Konferenz.

Hier gibt es ein paar Notizen von den aus meiner Sicht interessantesten Vorträgen.

“Ruby ruined my Life” von Aaron Patterson

Die erste Keynote wurde von Aaron Patterson gehalten. Seines Zeichens Ruby- und Rails-Core Committer welcher bei AT&T Interactive zur Open Source Pflege angestellt ist. In seiner Keynote verglich er die Entwickungsprozesse der Ruby und Rails Community und vertrat die Meinung, dass die beiden Teams sich gegenseitig befruchten könnten indem sie Gewohnheiten der anderen übernehmen würden. So z.B. die nicht fest zugeschriebene Verantwortlichkeiten des Railsteams, welche im Rubyteam stark den Fortschritt behindert. Oder das koordinierte Release Management von yugui welches innerhalb von Rails nicht dediziert von einer Person durchgeführt wird und deshalb oft auf der Strecke bleibt.

“Next version of Ruby 1.8 and 1.9” von CRuby Development Team

Während der Q&A Session mit den Core Entwicklern wurden die folgenden Punkte für die Zukunft der CRuby Entwicklung mitgeteilt:

Die nächste und letzte Version von Ruby 1.8.6 wird in etwa zwei Monaten erscheinen. Sie wird ausschließlich Fehlerbereinigungen enthalten. Der aktuelle Maintainer hat angekündigt danach seine Arbeit daran einzustellen.

Seit 1.9.3 gibt es mithilfe von private_const eine Konstante als private zu markieren.

Seit kurzem ist sorah_h neuer Ruby Committer. Seine erste Integrationsaufgabe war für 1.9.3 test/unit zu parallelisieren.

Es wurden Anpassungen am GVL vorgenommen um Aktivitäten um diesen herum zu beschleunigen.

Koichi stellte eine Änderung am Thread Timer vor. Dieser verhält sich nun etwas intelligenter. U.a. deaktiviert er sich beim nicht Vorhandensein von multiplen Threads. Dies sorgt dafür das die kontinuierliche Prozessorlast von Ruby sinkt, da das permanente Scheduling alle 10ms in vielen Fällen wegfällt.

Ruby 1.9.3 wird nach aktuellem Plan Ende August veröffentlicht. Eine erste Preview steht bereits in den Startlöchern.

Nach dem 1.9.3 Release wird der Support für 1.9.1 eingestellt.

“Ruby, that Community and me” von sora_h

sorah_h, der seit kurzem Core Committer ist, stellte seinen Werdegang als jüngstes Mitglied des Core Teams vor. Er erklärte welche Dinge es Ihm ermöglicht haben sehr früh bereits mit Ruby in Kontakt zu kommen (u.a. Hackety Hack) und warb darum die jüngere Generation zu motivieren es Ihm gleich zu tun.

“The Real-Time Profiler for Ruby” von Takahiro Sunaga

Es wurde der Real Time Profiler llprof vorgestellt, welcher es ermöglicht, ohne den hohen Overhead von ruby-prof Ruby Programme zu profilen. Dies findet weiterhin im Gegensatz zu ruby-prof in Echtzeit im Browser statt. Dort kann u.a. ein Graph oder eine Baumstruktur des aktuell laufenden Ruby Prozesses begutachtet werden.

“Dynamic Component System and Memory Reduction of VM for Embedded Systems” by Kiyoshi Ikehara

Es wurde ein patch für Ruby 1.9.2 vorgestellt welcher es ermöglicht mehrere Prozesse getrennt innerhalb einer VM auszuführen. Als Beispiel wurde Sinatra verwendet.

“Lightweight Ruby” by Lightweight Ruby Development Team

Der aktuelle Stand der Entwicklung des neuen Ruby Interpreters für Embedded Systeme wurde von matz vorgestellt. Eine erste Alpha Version soll ende Juli 2011 fertigstellt sein. Ein offizielles Release wird frühstens in der ersten Hälfte 2012 als Open Source veröffentlicht.

“Parallel world of CRuby’s GC” by nari

Der GC Maintainer nari stellt seine Ideen vor um die GC Mark and Sweep Implementierung parallel zu gestalten. Es wird dabei ein (wie er es nennt) “Task Steal” Ansatz verwendet. Dabei wird verhindert das der GC blockiert, in dem Aufgaben von GC Prozessen entwendet werden die selbst gerade blockiert sind.

“Ruby Interpreters in the Parallel Worlds” by Koichi Sasada

Koichi stellt den aktuellen Stand der Entwicklung im Ruby trunk vor und erklärt Konzepte um die Ausführung auf Multiprozessor Maschinen zu beschleunigen. Es wird erneut die “Multiple Virtual Machine” erwähnt, wobei es sich um die Idee handelt, mehrere VM in einem Ruby auszuführen und so den “Global Lock” zu umgehen.

JIS Standardization von Shugo Maeda

Shugo sprach über den abgeschlossenen Standardisierungsprozess von Ruby. Er erklärte wie der Standard zu lesen sei, was er enthält und was ausgespart wurde.

Lightning Talks – Erste Runde

Trunk Changes Statistic - 9.2 commits a day

OS made by Ruby (Yoshihara Haruka) - PerlOS

Creating Global Japanese Rubyist - creating of TokyuRubyistMeetup

Rurima - Japanese Ruby Referrnce Manual

James - MacRuby speech talk dialog system - codebrawl.com

Asp.Net vs Rails - rails lost

Technology support rubykaigi.org

Rios:Proxy – Proxy Framework for CLI – emulate input/output

MacRuby Rainbow – rewritten IRB – integrated into Carbon – github.com/alloy

erb

Limiting Red

Lightning Talks – Zweite Runde

Agile UCD - Agile UX Live result - Meetup CMS

Floating Point - hard to use right - decimal notation für Rational

BioRuby - DNA Analyse

Chatting with Anime Voice Actors via Skype

Study Group versus Meetup Group

define_method

What Rubyists are missing is accounting

ActiveLdap - Rails 3.1 Integration

MmapScanner

pebbles - propose namespace for joke gems

C die hard

The Gate von Kakutani

Die treibende Kraft hinter der RubyKaigi – Shintaro Kakutani – hielt eine Präsentation rund um die japanische Ruby Community und welchen Stellenwert die RubyKaigi darin einnahm. Er thematisierte die Zukunft ohne diese Konferenz und die eventuellen Möglichkeiten wie z.B. eine Kooperation mit der RubyConf.

Pendulum, PG, and the Hundred Year Old Language von matz

Matz Keynote über die Gegenwart und Zukunft von Ruby.

Matz wechselt den Arbeitgeber

2011-07-12T20:24:00Z

An sich ist ihm das ja komplett frei gestellt, aber ich dachte, es könnte doch interessant sein: Matz arbeitet neuerdings bei Heroku.

Das Anzählen hat begonnen

2011-07-08T08:39:00Z

Irgendwann kommt die leidige Diskussion ja immer wieder auf. Ruby 1.9 oder 1.8? Wer Argumente gegen 1.8 für neue Projekte sucht, der wird ab heute ein neues bekommen: Die Gespräche über das End-Of-Life von Ruby 1.8 haben begonnen. Das altehrwürdige 1.8.6 wird eh kaum mehr gepflegt und 1.8.7 ist seit Jahren im Maintenance-Mode. Beide entwickeln sich nicht mehr fort, können allerdings auf eine breite Installationsbasis verweisen, was die Pflege durchaus noch sinnvoll macht. Gerade 1.8.7 wurde vor einigen Tagen mit einer neuen Version bedacht.

Wer die Diskussion gleich live verfolgen will, kann das im Redmine Issue 4996 tun. Momentan steht ein Ende der Maintenance im Juni 2012 im Raum, die Einstellung von sicherheitsrelevanten Fixes im Juni 2013. Aber das ist erstmal nur ein Vorschlag, es wäre nicht das erste Mal, dass sich in solch einer Situation ein Maintainer findet, der die Pflege unbedingt fortführen will.

Ruby + 10 Quine

2011-07-04T02:38:00Z

Ich habe gerade folgendes Quine von Yusuke Endoh gefunden:

1
2

# ruby
l=92.chr;eval s="s=s.dump[r=1..-2].gsub(/("+l*4+"){4,}(?!\")/){|t|'\"+l*%d+\"'%(t.size/2)};5.times{s=s.dump[r]};puts\"# python\\nprint(\\\"# perl\\\\nprint(\\\\\\\"# lua"+l*4+"nprint("+l*7+"\"(* ocaml *)"+l*8+"nprint_endline"+l*15+"\"-- haskell"+l*16+"nimport Data.List;import Data.Bits;import Data.Char;main=putStrLn("+l*31+"\"/* C */"+l*32+"n#include<stdio.h>"+l*32+"nint main(void){char*s[501]={"+l*31+"\"++intercalate"+l*31+"\","+l*31+"\"(c(tail(init(show("+l*31+"\"/* Java */"+l*32+"npublic class QuineRelay{public static void main(String[]a){String[]s={"+l*31+"\"++intercalate"+l*31+"\","+l*31+"\"(c("+l*31+"\"brainfuck"+l*64+"n++++++++[>++++<-]+++++++++>>++++++++++"+l*31+"\"++(concat(snd(mapAccumL h 2("+l*31+"\"110"+l*31+"\"++g(length s)++"+l*31+"\"22111211100111112021111102011112120012"+l*31+"\"++concatMap("+l*32+"c->let d=ord c in if d<11then"+l*31+"\"21002"+l*31+"\"else"+l*31+"\"111"+l*31+"\"++g d++"+l*31+"\"22102"+l*31+"\")s++"+l*31+"\"21002111010120211222211211101000120211021120221102111000110120211202"+l*31+"\"))))))++"+l*31+"\","+l*63+"\""+l*64+"n"+l*63+"\"};int i=0;for(;i<94;i++)System.out.print(s[i]);}}"+l*31+"\")))))++"+l*31+"\",0};int i=0;for(;s[i];i++)printf("+l*63+"\"%s"+l*63+"\",s[i]);puts("+l*63+"\""+l*63+"\");return 0;}"+l*31+"\");c s=map("+l*32+"s->"+l*31+"\""+l*63+"\""+l*31+"\"++s++"+l*31+"\""+l*63+"\""+l*31+"\")(unfoldr t s);t[]=Nothing;t s=Just(splitAt(if length s>w&&s!!w=='"+l*31+"\"'then 501else w)s);w=500;f 0=Nothing;f x=Just((if x`mod`2>0then '0'else '1'),x`div`2);g x= reverse (unfoldr f x);h p c=let d=ord c-48in(d,replicate(abs(p-d))(if d<p then '<'else '>')++"+l*31+"\"."+l*31+"\");s="+l*31+"\"# ruby"+l*32+"n"+l*31+"\"++"+l*31+"\"l=92.chr;eval s=\"+(z=l*31)+\"\\\"\"+s+z+\"\\\""+l*31+"\"++"+l*31+"\""+l*32+"n"+l*31+"\""+l*15+"\""+l*7+"\")"+l*4+"n\\\\\\\")\\\")\"########### (c) Yusuke Endoh, 2009 ###########\n"

Das besondere an diesem Quine?

$ ruby QuineRelay.rb > QuineRelay.py
$ python QuineRelay.py > QuineRelay.pl
$ perl QuineRelay.pl > QuineRelay.lua
$ lua QuineRelay.lua > QuineRelay.ml
$ ocaml QuineRelay.ml > QuineRelay.hs
$ runghc QuineRelay.hs > QuineRelay.c
$ gcc -Wall -o QuineRelay QuineRelay.c && ./QuineRelay > QuineRelay.java
$ javac QuineRelay.java && java QuineRelay > QuineRelay.bf
$ beef QuineRelay.bf > QuineRelay.ws
$ wspace QuineRelay.ws > QuineRelay.unl
$ unlambda QuineRelay.unl > QuineRelay2.rb

Und abschliessend:

$ diff QuineRelay.rb QuineRelay2.rb

Ich bin verstört…

Germany.rb 2011 Ruby User Treffen in Leipzig

2011-06-23T14:44:00Z

Wir haben wieder einen Termin gefunden! Am 20. und 21. August 2011 treffen wir uns zur zweiten Germany.rb in Leipzig im sublab. Wie immer gibt es keine Teilnahmegebühr und kein statisches Programm. Statt dessen gibt es Platz für Jeden um seine Ideen vorzutragen und sein Wissen zu teilen und zu erweitern.

Mehr Informationen gibt es auf der offiziellen Ruby Webseite.

Der Bericht mit allen Videos zur Germany.rb 2010 ist auch verfügbar.

Ruby-Talk-ML und comp.lang-ruby getrennt

2011-06-21T20:54:00Z

James Edward Gray II. hat heute überrschend das Gateway zwischen der Ruby-Talk-Mailingliste und der Newsgroup comp.lang.ruby heruntergefahren, da ihm die Wartung ein zu großer Aufwand würde und er meint, dass die Ruby-Community zu groß für diese Verbindung geworden sei, sie habe sich ohnehin schon in einzelne Themenbereiche aufgespalten. Die ursprüngliche Funktion, die Ruby-Community zusammenzuhalten, als sie noch klein war, sei überholt und nicht mehr vonnöten.

Heute um 22:25 Uhr hat James verkündet, dass das Gateway geschlossen sei. Das bedeutet, dass die Usenet-Posts auf comp.lang.ruby nun nicht mehr auf der Mailingliste erscheinen werden, und umgekehrt auch Postings auf der Mailingliste die Newgroup nicht mehr erreichen.

Methoden in Ketten legen

2011-04-02T14:44:00Z

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.

Ein kleiner Usecase

Wozu brauchen wir das Ganze eigentlich? Ruby ist eine Sprache, die besonders viel Wert auf die Komponentenweise konstruktion von Klassen legt. Anders als in Sprachen wie Java ist es durchaus erwünscht, Klassen in einzelnen Modulen zu implementieren und dann zusammen zu "mixen". Was aber, wenn bestimmte Methoden einer Klasse Verhalten gewinnen, wenn bestimmte Module inkludiert sind?

Nehmen wir als kleines Beispiel eine Klasse, die gespeichert werden kann:

class Person
  def save
    #speicher-fu!
  end
end

Hierzu schreiben wir uns ein Validierungsmodul. Validierung sollen immer ausgeführt werden, bevor die Person gespeichert wird:

module Validations
  def save
    validate!
    super
  end
end

class Person
  include Validations
end

Das sieht zwar schön aus, funktioniert aber leider nicht. Schauen wir uns die Ableitungskette von Person an, fällt auch sofort auf, wieso:

12	> Person.ancestors=> [Person, Validations, Object, Kernel, BasicObject]

Wird ein Modul per include in eine Klasse eingebunden, landet es zwischen der Klasse und dem nächsten Objekt in der Ancestors-Kette. Ruft man also save auf, erwischt man stets die save-Methode von Person.

Wege heraus

Um kurz den Rails-Weg anzureissen, hier deren Variante, dieses Problem zu lösen:

class Person
  def save_with_validations
    validate!
    save_without_validations
  end

  alias :save_without_validations :save
  alias :save :save_with_validations
end

Wir benennen also die alte Methode um, implementieren eine neue, die den neuen Namen der alten Methode verwendet und geben der die neue dann den alten Namen. Diese Lösung hat ihren Charme und durchaus Vorteile (ich kann z.B. immernoch sehr bequem save_with_validations aufrufen), aber auch Nachteile: ich muss diesen Code zum Beispiel immer beim Einmixen eines Moduls ausführen, wenn das Feature an einem Modul hängt. Auch ist die Kette schwer nachzuverfolgen.

Chainable geht einen anderen Weg. Die Implementierung ist kurz:

module Chainable
  def chainable(&block)
    mod = Module.new(&block)
    include mod
    mod
  end
end # module Chainable

Die Anwendung ist auch einfach:

class Person
  extend Chainable

  chainable do
    def save
      #speicher-fu!
    end
  end
end

module Validations
  def save
    validate!
    super
  end
end

class Person
  include Validations
end

Ich markiere also eine oder mehrere Methode als verkettbar, was mir im Folgenden erlaubt, diese Methode als Anfang einer Methodenkette zu verwenden. Ein Blick auf Hierarchie zeigt, wo die Magie liegt:

12	> Person.ancestors=> [Person, Validations, #<Module:0x000001009bb6e8>, Object, Kernel, BasicObject]

Chainable erstellt also ein anonymes Modul und mixt dieses in die Klasse ein, auf die chainable aufgerufen wurde. Das führt dazu, dass die innerhalb des Block definierten Methoden innerhalb der Hierarchie eine Ebene nach oben rutschen. Damit ist sie sowohl für die Klasse als auch für alle danach eingemixtend Module als super verfügbar, worüber dann die Kette aufgebaut werden kann.

Der Ansatz hat den Vorteil, dass alle Methoden einer Kette denselben Namen tragen und es ein klassisches Modell der Methodenverkettung verwendet: super. Ersteres kann natürlich von Nachteil sein, wenn man Methoden ohne Features nach Namen aufrufen will (z.B. save_without_validations). Allerdings stellt sich hier die Frage, ob Verkettung für solche Fälle die richtige Lösung ist: Welche Methode rufe ich auf, wenn ich auf 2 Features verzichten will?

Ein weiterer Vorteil ist die bessere Inspizierbarkeit: folgende kleine Methode gibt mir die volle Methodenkette für einen Namen aus, zusammen mit dem Ort, wo die Methoden definiert wurden (Achtung, source_location gibt es nur unter 1.9):

def filter_chain(klass, meth)
  chain = klass.ancestors.map do |a| 
    begin
      m = a.instance_method(meth)
      next if m.owner != a
      [m, m.source_location]
    rescue NameError
      next
    end
  end
  chain.compact
end

filter_chain(Person, :save)

Viel Spaß beim in Ketten legen, der volle Text über DataMapper kommt dann auch bald.

Ruby demnächst nur noch Closed-Source

2011-03-31T22:00:00Z

Wie unterrichtete Kreise erfahren haben wollen, übernimmt die Oracle Corporation die maßgeblich an der Ruby-Entwicklung beteilgte Firma EngineYard für umgerechnet 240 Millionen Euro. Dem Sprecher von Oracle zufolge solle Ruby nun "um die Qualität, Produktivität und Attraktivität der Sprache zu fördern" nur noch als Closed-Source entwickelt werden. Die Binaries, die auf der noch nicht öffentlich zugänglichen Website ruby.oracle.com zu haben sein werden, sollen jedoch nach wie vor kostenlos sein. Man werde auch weiterhin Binaries für Linux- und Mac-Systeme anbieten, verspricht die amerikanische Firma. Oracle werde aber eine kostenpflichtige "Cloud Edition" von Ruby veröffentlichen, die offenbar anstelle der bisherigen Makro-Funktion von Oracles "Cloud Office" benutzt werden kann.

Der Hauptentwickler und Erfinder von Ruby, der Japaner Yukihiro "Matz" Matsumoto, äußerte sich bestürzt. Er werde sich fortan vollständig aus der Ruby-Entwicklung zurückziehen, und mit ihm der größte Teil des bisherigen Core-Teams. Er empfehle für die Zukunft einen Boykott der Sprache, postete er auf einer japanischen Ruby-Mailingliste:

私たちに向かって、Oracleの敵対的な態度は、私たちは、Rubyプログラミング言語で開発を停止させる。これは、私が言うのは難しいが、もうRubyを使用しないでください。そのような組織をサポートしていません。

Zugleich kündigte Oracle an, mit der demnächst erscheinenden Version 7 der Programmiersprache Java deren Lizenz so abzuändern, dass jegliche Software, die auf der Java Virtual Machine aufsetzt, nur noch als Closed-Source vertrieben werden darf. Dies veranlasste den führenden Kopf der JRuby-Implementation, Charles Oliver Nutter, zu einem hier nicht weiter zitierten, aber überaus unhöflichen Statement gegenüber Oracle. Alle Hoffnungen ruhen nun auf der letzten freien Ruby-Implementation Rubinius, deren Entwicklungsteam sich zwar gleichfalls geschockt zeigte, aber verlauten lies, man werde nun mit Hochdruck an der Fertigstellung von Rubinius 1.5 arbeiten, das vollständige Kompatibilität zum bisherigen MRI 1.9.2 besitzen solle.

Update

Kommando zurück, das war nur ein Aprilscherz. Das Matz-Zitat ist auch nur ein passender vom Google-Übersetzer von Englisch nach Japanisch übersetzter Text. :-)

Mono 2.10 veröffentlicht

2011-02-17T11:04:00Z

Novell hat die Version 2.10 der alternativen .NET-Implementierung Mono veröffentlicht. Inwiefern ist das für Rubyisten relevant? Ab diesem Release enthalten die Installer für Linux und OS X einen Release von IronRuby und IronPython. Wer also bequem mal IronRuby ausprobieren möchte, kann nun den Installer installieren und einfach ir aufrufen:

[ skade Florian-Gilchers-MacBook-Pro ~ ] ir
IronRuby 1.1.2.0 on 2.10 (tarball Mon Feb 14 16:04:48 MST 2011)
Copyright (c) Microsoft Corporation. All rights reserved.

>>> RUBY_VERSION
=> "1.9.2"
>>>

Für FOSS-Anhänger wie mich: IronRuby ist übrigens seit geraumer Zeit zusammen mit der DLR (Dynamic Language Runtime) unter Apache 2.0 veröffentlicht.

Die drei Großen (2): Sequel

2011-02-11T17:25:00Z

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.

Setup

Sequel kommt komplett mit allen Plugins in einem Gem, eventuell benötigte Datenbankkonnektoren sind dabei ausgenommen. Wer also zum Beispiel sqlite3 verwenden will, benötigt also noch den sqlite3-gem oder alternativ data_objects und do_sqlite3.

Am Anfang steht wie immer `require`, bei Sequel gibt es da eigentlich nur 2 Varianten: core oder mit Modelschicht. Hierbei ist zu beachten, dass sequel standardmässig die Modelschicht mitlädt, core ist der Sonderwunsch.

12	require 'sequel'require 'sequel-core'

Die Datenbankverbindung stellt man über Connection-Strings her:

12	db = Sequel.connect 'postgres://postgres@localhost/my_example?encoding=utf8', :max_connections => 10, :logger => Logger.new('log/db.log')

Wer schnell nur ein wenig rumspielen will, kann eine der convenience-Methoden verwenden, am praktischsten ist #sqlite, das sofort eine SQLite-DB im Speicher erstellt.

db = Sequel.sqlite

Extrem praktisch, wenn man nur mal schnell rumspielen will.

Queries

Sequel lebt vor allem von einem Objekt: Dataset. Datasets repräsentieren die Beschreibung eines Datensatzes (also, einen SQL-Query ;)) und können beliebig weiter verwendet und manipuliert werden. Dazu besitzen sie verschiedene Methoden, die dann einen Query auslösen. Datasets werden in der Anwendung immer durch das Datenbank-Objekt erstellt:

 people = db[:persons] #alternativ db.from(:persons)

Gibt uns einen Query für alle Zeilen der Tabelle “persons”. Ausgeführt wird der Query, wenn wir irgendeine Methode aufrufen, die auf Elemente des Datasets zugreift:

123	people.all #=> hoffentlich steckt dahinter nicht die Weltbevölkerungpeople.first #=> der erstepeople[:age => 13] #=> alle, die endlich auf rubyforen.de dürfen

Manipulationen eines Dataset-Objekts sind nicht-destruktiv und geben immer ein neues Dataset zurück:

12	children = people.filter { age < 13 }silver_surfers = people.filter { age > 65 }

Gegenüber handgeschriebenen WHERE-Conditions hat die Filter-Methode auch den Vorteil, dass sie beliebig häufig aufgerufen werden kann:

male_silver_surfers = silver_surfers.filter(:sex => :male)

Ähnlich lassen sich SELECTs und andere Klauseln hinzufügen:

male_silver_surfers.select(:age, :sex)

Als letztes Stück Code Einführung möchte ich noch 2 Beispiele aus der Doku zeigen, JOINs und Graphing:

DB[:items].join(:order_items, :item_id => :id)
=> {:id=>order_items.id, :item_id=>order_items.item_id}

DB[:items].graph(:order_items, :item_id => :id).first
=> {:items=>{:id=>items.id}, :order_items=>{:id=>order_items.id, :item_id=>order_items.item_id}}

Sequel kann also die flachen Rückgaben von JOINs wieder zu geschachtelten Strukturen verwandeln. Eine äusserst praktische Funktion, die es einem erspart, diese Verbindungen selbst wieder aus dem Result zu ziehen.

Ab hier übergebe ich an die Doku, die Queries sehr genau beschreibt. Es gibt da noch viel zu finden.

Das interessante an Sequel-Datasets ist weniger, dass sie eine schöne DSL zum schreiben von SQL-Queries sind, sondern eher ihre Eigenschaft, beliebig weitergefiltert und verfeinert werden zu können. Statt also in meiner Applikation halbfertige SQL-Strings rumzureichen bietet Sequel einen manipulierbaren Datentyp und verwaltet alle Klauseln für den Nutzer und bleibt dabei so datenbankunabhängig wie möglich.

Die beschreibende Rolle von Datasets nutzt Sequel für einen eleganten ORM-Mechanismus, der einem die Arbeit mit rohen Datensets weiter vereinfacht: Sequel::Model.

Models

Sequel Models sind eigentlich ein Dekorator über einem Datenset. Zuerst mal sehen sie nicht anders aus als die, die man aus ActiveRecord kennt:

123	class People < Sequel::Modelend

Wer eine andere Tabelle mit etwas Zucker haben will, kriegt sogar ein kleines Stückchen Ruby-Magie präsentiert:

123	class People < Sequel::Model(:my_table)end

Fängt man aber mit den Abfragen an, wird schnell klar, dass diese Models eigentlich nur aufgehübschte Datasets sind:

People.filter(:name => "Daniel").first

Wenig verwunderlich lassen sich also z.B. sehr einfach Models über gefilterten Datasets implementieren:

class SilverSurfers < Sequel::Model
  set_dataset DB[:people].filter ("age > ?", 65)

  def besitzt_internet_ab_60?
    # logik
  end
end

Assoziationen und Validierungen werden auch unterstützt, sollen hier aber nicht vorgestellt werden. Wer eine Lib dafür kennt, kennt sie alle.

Wer die Dataset-API kennt, kommt mit Models sofort zurecht. Sequels einziger zusätzlicher Job ist hier das Mapping roher Datenbankantworten auf Objekte.

Fazit

Sequel in einem Satz: Angenehmer als SQL, sehr featurereich und sehr fokussiert. Wer alles aus seiner SQL-Datenbank herausholen will oder Skripte schreibt, die komplexe Transformationen der Datenbank durchführen müssen ist mit Sequel sehr gut bedient. Darüber hinaus ist die Bibliothek vorzüglich dokumentiert, solange man weiss, was hinter den SQL-Konzepten steckt. Wer den Unterschied zwischen WHERE und HAVING nicht kennt, wird hier auch nicht schlauer. Die Modelschicht ist zwar ein klein wenig spartanisch, bringt aber alles, was man sich so wünscht. Wer sich nur für Objektmodellierung und nicht für SQL interessiert, greift hier besser zu anderen Lösungen. Wer im großen Stil die Features von SQL-Datenbanken ausnutzt, wird hier schnell fündig und glücklich, da Sequel hier wenige Umwege zum Ziel einbaut.

Zuletzt: Jeremy Evans “Blog II” (Das Sequel zu Blog ;) ) ist sehr lesenswert, vor allem für jeden, der sich für SQL interessiert. Und solltet ihr Jeremy auf einer Konferenz treffen: sprecht mit ihm, man trifft selten nettere und kompetentere Programmierer.

Syntax-Sonntag: Noch mal picky

2011-01-09T08:00:00Z

Diesmal nur ein ganz kurzer. Über das Picky Lambda kann man gerne ewig lange diskutieren, aber mir ist gestern noch folgende, selten erwähnte Kleinigkeit aufgefallen: wenn man das picky lambda verwendet, können die Argumentklammern weggelassen werden.

12	f = -> a,b { puts a,b } f[1,2]

(Eigentlich will ich ja nur wissen, ob CodeRay damit zurecht kommt.)

Die drei Großen (1): AR, DM, Sequel

2011-01-08T14:45:00Z

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.

Die beiden Fowlers: DataMapper und ActiveRecord

DataMapper und ActiveRecord beschäftigen sich beide mit Objektpersistenz. Sie versuchen also, Ruby-Objekte auf Objekte in einer Persistenzschicht (z.B. Zeilen in einer relationalen Datenbank) zu passen und dabei einen Teil der Komplexität der Datenhaltung zu verbergen. Das macht sie selbst wiederum zu sehr komplexen Gebilden.

Wer nach dem Namensgeber der beiden Bibliotheken sucht, wird sofort 2 von Martin Fowler eingeführte Persistenzmodelle finden, die sich vor allem in ihrer Abstraktionsrichtung unterscheiden. In ActiveRecord wird die Struktur der Daten zuerst einmal von der Datenbank beschrieben. ActiveRecord inspiziert dann zur Laufzeit die Datenbank, um herauszufinden, wie deren Struktur ist, um sie dann nachzubilden. Im Falle der ActiveRecord-Implementierung in Rails funktioniert das nur teilweise: da Rails auf Features von SQL-Datenbanken wie Fremdschlüssel und Constraints verzichtet, müssen Relationen zwischen ActiveRecord-Klassen immernoch von Hand angegeben werden, es ist also noch Handarbeit erforderlich.

DataMapper geht anders vor: hier werden gleich alle zu persistierenden Eigenschaften am Ruby-Objekt definiert, DataMapper kümmert sich darum diese in die Datenbank zu bringen. DataMapper inspiziert dabei die Storage nicht, kann aber bestimmte Änderungen am Store selbst vornehmen: wird an einem DataMapper-Model eine Eigenschaft hinzugefügt, kann DataMapper zum Beispiel automatisch eine Spalte in einer SQL-Datenbank hinzufügen. Selbstverständlich geschieht das nur bei nicht-destruktiven Operationen. Ein Nebeneffekt der Sache ist, dass sich dieses Konzept auch sehr leicht auf andere Datenbanken als SQL-Datenbanken übertragen lässt, weshalb DataMapper auch andere Stores ausser SQL unterstützt. DataMapper unterstützt auch von Haus die Verwendung mehrerer Datenbanken auf einmal, was zum Beispiel in Mandantensystemen sehr praktisch ist. DataMapper kann auch Relationen zwischen verschiedenen Datenstores herstellen: so kann man zum Beispiel problemlos Verbindungen zwischen Objekten ziehen, die in zwei verschiedenen Datenbanken liegen, z.B. Redis und einer SQL-Datenbank.

SQL auf Steroiden: Sequel

Jeremy Evans Sequel wird gerne mit DM und AR in einem anderen Satz genannt, hat mit ihnen aber eher wenig gemein. Sequel hat zwar als Plugin eine Objekt-Modellierungsschicht wie DataMapper und ActiveRecord, ist jedoch in dieser Hinsicht am wenigsten geeignet. Sequel legt mit seinem Namen die Marschrichtung vor: SQL, aber so richtig. Wenn man das erste Mal Sequel sieht, sieht das Ganze wie eine Alternativsyntax für SQL-Queries aus, was häufig die Frage aufwirft: “warum dann nicht gleich SQL?”. Einmal natürlich, weil SQL-Queries zusammenbauen immer ein bisschen abstrahiert gehört: einmal Quotes vergessen, schon sind die Kreditkartendaten kaputt oder für 1.50$ pro Stück irgendwo im Internet erhältlich. Zum zweiten, weil bestimmte Operationen (zum Beispiel Auswahl einer zufälligen Spalte) in verschiedenen Datenbanksystemen subtil unterschiedlich funktionieren, die man sich nicht immer merken will. Sequel bietet darüber hinaus eine ganze Reihe weiterer angenehmer Sachen: lazy queries zum Beispiel, die sich in mehreren Schritten weiter verfeinern lassen sowie viele Plugins, die das arbeiten mit reichlich diffizilen Sachen und abstrusen Datenbankfeatures erleichtern. Zwar ist Sequel ohne Plugins auf die Schnittmenge aller SQL-Datenbanken beschränkt, wer aber gerne z.B. rekursive Subqueries in Postgres verwenden will, der wird in der Plugin-Sammlung fündig. Der generierte SQL-Code ist richtig schick.

Weiteres vorweg

Die drei hier vorgestellten Bibliotheken sind einer der Gründe, warum ich gerne Ruby verwende: alle 3 haben einen genauen Fokus und keine ist die Kopie einer anderen. Alle drei haben ihre Stärken und Schwächen und sind einen Blick wert. ActiveRecord und DataMapper sind zum Beispiel eher schlecht im Umgang mit nicht nach ihren Vorstellungen konstruierten SQL-Datenbanken, während Sequel hier die besten Ergebnisse liefert. Umgekehrt bedeutet Sequel relativ viel Arbeit, wenn eine Applikation nur Standardfälle der anderen beiden abdeckt.

Allen dreien ist eins gemein: eine lange Entwicklungszeit und die damit erreichte Einsatzreife. Bleibt nur die Frage, was die drei jetzt genau ausmacht, die ich in weiteren Folgen beantworten werde.

EuRuKo2011.initialize

2011-01-06T23:29:00Z

Beim rug-b Treffen in Berlin scheinen heute weitere Neuigkeiten über die nächste EuRuKo bekanntgegeben worden zu sein. U.a. ist die Veranstaltung auf den 28. und 29. Mai 2011 fixiert worden. Und der Veranstaltungsort wird das Kino International sein, nur knapp 600m von meinem Zweitwohnsitz in Berlin entfernt. Sehr cool!

Quelle: http://dnbutler.com/