Um eine Anmeldung wird gebeten.

Weitere Informationen auf der Mailingliste.

Die dreitägige Konferenz hat rundum überzeugt, die Vorträge waren besser und nützlicher als im letzten Jahr. Das Interesse, Rails in die sogenannten Enterprise-Bereiche (“Websfear“) zu bringen, prägte sehr viele Vorträge und auch die Paneldiskussion, an der u.a. Yehuda Katz (Rails & jQuery Core Entwickler) teilnahm.

Auch Rails 3 und Hosting waren heisse Themen die von mehreren Vorträgen behandelt wurden.

Hier eine Sammlung mit Links zu den Slides, sofern mir bekannt:

Montag

Dynamic Language VMs: Ruby 1.9
Lourens Naudé
http://www.slideshare.net/methodmissing/railswaycon-2010-dynamic-language-vms

Push it to the limit – An intro to Websockets and Rails applications
Michael Johann

CouchDB on Rails
Jonathan Weiss
http://www.slideshare.net/jweiss/couchdb-on-rails-railswaycon-2010

Cross-browser testing in the real world
Martin Kleppmann
http://www.slideshare.net/martinkleppmann/crossbrowser-testing-in-the-real-world

Ruby on Rails Security Updated
Heiko Webers
http://www.slideshare.net/heikowebers/ruby-on-rails-security-updated-rails-3-at-railswaycon

Small is Sexy – We need Components in Rails!
Nick Sutterer

Be Authentic – Get into LDAP, Users and Roles
Michael Johann

mongodb and mongomapper 4 real!
Jan Krutisch
http://slidesha.re/aSNEan

Command your Domain
Lourens Naudé
http://www.slideshare.net/methodmissing/railswaycon-2010-command-your-domain

Dienstag

Rails 3: Dashing to the Finish
Yehuda Katz
http://www.slideshare.net/wycats/rails-3-dashing-to-the-finish

A Testing Survival Guide
Thilo Utke
http://www.slideshare.net/freaklikeme/testing-survival-small

Rails in the Cloud – Lessons learned from building a platform on EC2
Jonathan Weiss
http://www.slideshare.net/jweiss/rails-in-the-cloud-experiences-from-running-on-ec2

Enterprise Rails Hosting
Julian Fischer
http://www.slideshare.net/avarteq/enterprise-hosting-2448821

betterplace.org: Crashing and uncrashing a social startup
Phillip Oertel, Till Behnke

10 fun projects to improve your coding skills
Jan Krutisch
http://slidesha.re/aFHE0O
http://jan.krutisch.de/en/fun_projects/

SOLID Rails, SOLID Ruby – practical patterns applied
Jens-Christian Fischer, Michael Mahlberg
http://github.com/MichaelMahlberg/RailsWayCon2010

Productive Rails development with RubyMine
Oleg Shpynov, Dennis Ushakov
http://www.slideshare.net/olegshpynov/productive-rails-development-with-rubymine

Evolutionary programming with Ruby
Julian Fischer
http://www.slideshare.net/avarteq/evolutionary-algorithms-in-ruby

Improved performance with client side optimization
Patrick Hüsler

Culerity: Full stack Rails testing with Cucumber and Celerity
Patrick Hüsler

Mittwoch

Establishing an integrated JRuby/Rails – Stack in a Legacy environment
Rubén Parés-Selders

The State of RESTful Rails
Stefan Tilkov
http://www.innoq.com/blog/st/presentations/2010/2010-06-02-REST-Rails–RailsWayCon.pdf

Rails/Ruby Coding Dojo
Jens-Christian Fischer, Michael Mahlberg
http://github.com/jcfischer/RwcCodingDojo

Ruby and Redis – Simple meets Awesome
Mathias Meyer
http://redis-railswaycon2010.heroku.com/

Using jQuery with Rails
Yehuda Katz

The Anatomy of Ruby I18n: Overview of the Gem’s architecture and advanced features
Sven Fuchs

Deliver Software with MacRuby
Thilo Utke
http://www.slideshare.net/freaklikeme/mac-ruby-deployment

Fazit:

Die RWC2010 hat mir dieses Jahr deutlich besser gefallen als 2009. Die Talks waren nützlich und fast ausnahmslos sehr gut präsentiert. Es ergab sich durch das tägliche gemeinsame Mittagessen auch eine gute Möglichkeit zum Netzwerken. Die Party am Dienstag habe ich leider verschlafen, verweise aber auch deshalb gerne auf Twitter (#railswaycon) .

Ich würde mich sehr über eine RailsWayConf 2011 oder 2012 freuen, wenn man die Überschneidung mit der Euruko 2011 in Berlin vermeiden möchte.

Am letzten Tag dann noch eine wunderbare Art des Reality-Checks: Ein Panel der Webinale, die für alle Teilnehmer geplant wurde, zeigte uns unbeabsichtigt auf, wie weit die deutsche Internet/Web/Medienszene im letzten Jahrhundert verankert ist:

Die von vielen von uns eingesetzten agilen Methoden, testgetriebene oder zumindest testgestützte Entwicklung in Kombination mit guter Usability braucht sich keinesfalls verstecken und ist noch immer Lichtjahre den etablierten voraus. Lasst uns also gemeinsam den Leuten zeigen wie es besser geht

Termin

Donnerstag, 8. Oktober 2009 19:00 Uhr

iCal: http://tinyurl.com/adj4hp

Vorträge

+ Marco Otte-Witte: Excellent (http://simplabs.github.com/excellent)

+ Peter Schrammel: Share-Nothing Private Assets Server

+ Sven C. Koehler: Localmemcache (http://localmemcache.rubyforge.org/ + http://github.com/sck/localmemcache)

+ … Du?

Ort & Anmeldung

Wir treffen uns dieses Mal bei der Experteer GmbH. Vielen Dank an Peter und das Experteer-Team für die Einladung!
Bitte gebt uns auch wieder Bescheid ob Ihr teilnehmen möchtet um die Planung zu erleichtern. Bitte bis Mittwoch 7.10. per Mail an:

anmeldung AT munich-on-rails.com

Adresse:

Experteer GmbH
Lenbachplatz 3
80333 München

schema_search_path:  myschema,otherschema,public

angibt, werden Datebankobjekte zunächst in myschema, dann in otherschema und schließlich in public gesucht.

Ein Anwendungsbeispiel wären z.B. temporäre Tabellen, die man während der Laufzeit erzeugen und mit einem ‘DROP SCHEMA xyz’ wieder löschen kann.

Will man hingegen eine ganze Railsanwendung in einem Schema laufen lassen, stößt man unweigerlich auf ein Problem mit den Tests. Bei Tests wird ein “DROP testdatenbank” durchgeführt und das nimmt natürlich nicht nur das verwendete Schema mit ins Datennirvana.

Deshalb muß der Task ‘create_database’ und die Methode ‘drop_database’ ein wenig gepatcht werden. Man erstellt also in ‘/lib/tasks/core.rake’ (oder wie man es auch immer nennen mag) eine Date folgenden Inhalts:

namespace :db do
  namespace :create do
    def create_database(config)
      #ensure the database exists:
      begin
        ccopy=config.dup.merge('schema_search_path' => 'public')
        ActiveRecord::Base.establish_connection(ccopy)
        ActiveRecord::Base.connection
      rescue
        @encoding = config[:encoding] || ENV['CHARSET'] || 'utf8'
        begin
          ccopy=config.dup.merge('database' => 'postgres',
                       'schema_search_path' => 'public')
          ActiveRecord::Base.establish_connection(ccopy)
         ActiveRecord::Base.connection.create_database(config['database'],
           config.merge('encoding' => @encoding))
        rescue
          $stderr.puts $!, *($!.backtrace)
          $stderr.puts "Couldn't create database for #{config.inspect}"
        end
      else
        $stderr.puts "#{config['database']} already exists"
      end
 
      #ensure the schema exists:
      if schema_name=config['working_schema']
        begin
          ActiveRecord::Base.establish_connection(config)
          ActiveRecord::Base.connection
        rescue ActiveRecord::StatementInvalid => e
          puts e.class.ancestors.inspect
          begin
            ccopy=config.dup.merge('schema_search_path' => 'public')
            ActiveRecord::Base.establish_connection(ccopy)
            ActiveRecord::Base.connection.execute("CREATE SCHEMA \"#{schema_name}\"")
            ActiveRecord::Base.establish_connection(config)
          rescue
            $stderr.puts $!, *($!.backtrace)
            $stderr.puts "Couldn't create database for #{config.inspect}"
          end
          #some error
        end
 
      end #schema
    end
  end
end
 
def drop_database(config)
  ActiveRecord::Base.establish_connection(config.
      merge('database' => 'postgres', 'schema_search_path' => 'public'))
 
  if schema_name=config['working_schema']
    ActiveRecord::Base.connection.execute "DROP SCHEMA IF EXISTS \"#{schema_name}\" CASCADE"
  else
    ActiveRecord::Base.connection.drop_database config['database']
  end
end

Die config/database.yml könnte wie folgt aussehen:

test:
  adapter: postgresql
  database: development
  schema_search_path: test,base_data,public
  working_schema: test
  host: myhost
  username: username
  password: password

Durch diesen Patch kann man ein “working_schema” wie eine richtige Datenbank verwenden. Wozu das gut ist?

• Mehrere Applikationen können sich eine Datenbank teilen.
• Die Applikationen können sich Basisdaten (User, Geolocations, …) und andere Datenbankobjekte teilen.
• Man benötigt keine DROP/CREATE DATABASE Privilegien.
• Im Gegensatz zu Datenbanken können Abfragen schemata-übergreifend formuliert werden.

Lasst euch was einfallen und viel Spaß beim einem interessanten Setup (und das bestimmt nicht nach Schema F).

Keynotes

Die erste Keynote hielt Ola Bini, dem JRuby Guru und Erfinder der Sprache Ioke. Sehr humorvoll legte er die Geschichte von Programmiersprachen dar und machte einen Ausblick auf deren Zukunft. Die Relevanz von Java wurde dabei relativiert, da es ja die JVM sei, die die Stabilität gewährleistet und nicht die Sprache darüber. Bini räumte Ruby einen grossen Part ein, war aber auch der Meinung dass in Zukunft eher “Multi-Language-Programming” zur Disziplin werden würde und auch der Fokus in Richtung Domain-Specific-Languages gehen würde.

Bei der zweiten liess uns Yehuda Katz einen Blick in das 2009 erwartete Rails 3.0 Framework werfen. Ein grosser Schritt wird dabei die Einführung von ActiveORM sein, einer Abstraktion der Datenbankdriver. Dadurch können Schnittstellen zu Datenbanken wie z.B. CouchDB oder SimpleDB geschaffen werden, die besser mit ActiveRecord zusammenarbeiten als es bisher möglich ist. Durch den Einsatz von Rack für die Abstraktion des Controllerdesigns lassen sich in Zukunft alternative Frameworks wie Sinatra oder Merb in Rails einbauen, so dass man die Flexibilität erhält in der Anwendung diese Framewerks parallel zu verwenden. Rails3 ist allerdings nicht vor Ende des Google Summer of Code zu erwarten.

Vorträge

Die Vorträge waren bunt gemischt und oft fiel die Wahl sehr schwer, welchen man nun besuchen sollte daher kann ich hier auch nur einige erwänen.

Jan Krutisch machte den Besuchern die Verwendung von HAML und SASS schmackhaft. Beides sind Templatesprachen, die das Erstellen von HTML und CSS sehr vereinfachen und strukturierten Code erzeugen. SASS hat den enormen Vorteil dass man Konstanten für das Styling benutzen kann und somit beispielsweise Farbangaben einmal definiert und beliebig verwenden kann. Ein anschliessender Einblick in das CSS Metaframework Compass schloss das Thema rund ab.

Stefan Tilkov von innoQ gab einen tieferen Einblick in das Konzept von RESTful Rails und welches die besten Praktiken dafür sind. Dabei wurden die Standardmethoden (GET,PUT,POST,DELETE) erleutert und wann sie zu benutzen sind. Sehr interessant dabei war, dass man durchaus eigene Methoden hinzufügen kann auch wenn es nicht notwendigerweise Sinn ergibt. Da REST über HTTP optimal implementiert ist, schlug Tilkov vor durchaus kleinere Anwendungsteile mit Rails zu erstellen und REST-Schnittstellen zu schaffen, da die Operabilität zu anderen Anwendungsteilen dadurch gewährleistet ist.

Ein Vortrag auf den ich mich besonders gefreut hatte war “Rails sitting on the Couch” von Alexander Lang. Er stellte sein Plugin Couch Potato vor, das eine Schnittstelle zur der dokumentbasierten Datenbank CouchDB bietet. Diese ist leider nicht ActiveRecord kompatibel, was jedoch auch nur schwer möglich ist, da es keine Tabellen und somit auch keine Tabellenbezüge gibt. Lang vertrat die Ansicht, dass durch eine DB, die wie CouchDB eine REST-Schnittstelle bietet der Server als “Middleware” komplett wegfallen könne und somit die Anwendungen auf reinen Javascript-Frameworks wie Sammy laufen könnten und direkt mit der Datenbank sprechen. Hier bin ich persönlich sehr skeptisch da schon allein der Sicherheitsaspekt problematisch wird.

“JQuery mit Rails” hiess ein Vortrag von Yehuda Katz, bei dem es um den Einsatz von JQuery parallel zu Prototype ging. Dabei wurden das Konzept von JQuery erklärt und einige konkrete Beispiele gezeigt. Katz vertritt die Meinung, dass RJS unbrauchbar ist und zeigte best practises wie man Templates von JS-Code entkoppelt.

Ein ähnliches Thema präsentierte Steven Bristol (Less Everything). Ihm ging es um “Advanced Javascript and Rails”. Dabei vertrat er jedoch die gegenteilige Meinung als Yehuda Katz, da mit Hilfe von JRails, einem Plugin das Prototype in Rails ersetzt, alle Helper benutzt werden können und der eigentliche Rubycode somit sauber bleibt. Da Katz mit im Publikum saß gab das natürlich eine Grundsatzdiskussion, jedoch akzeptierten beide die Meinungen des jeweils anderen. Interessant bei dem Vortrag waren auch die aufgezeigte Möglichkeit des Monkey Patching in JavaScript, sowie elegate OOP Vorgehensweisen.

Michael Johann, Chefredakteur des RailsWay-Magazins, gab einen großartigen Einblick darüber wie man in JRuby auf Swing und EJB 3.0 zugreifen kann. Sehr beeindruckend war wie man über die (J)Ruby-Konsole on-the-fly interaktiv eine GUI erstellen kann. Mit vielen praktischen Beispielen zeigte Johann, wie einfach sich EJB-Klassen mit Rails verbinden lassen und man dadurch bestehende Webanwendungen in Rails-Anwendungen integrieren kann. Dies eröffnet dem Ruby-Programmierer die komplette Java-Welt und umgekehrt können Javaentwickler Rails benutzen ohne auf gewohnte Frameworks verzichten zu müssen.

Des weiteren stellte Ralph von der Heyden, Mitarbeiter bei Xing, Möglichkeiten zur Verbessung von Frontend Performance vor und Vladimir Dobriakov (innoQ) zeigte uns wie evil “eval” beim Metaprogramming sein kann.

Fazit

Wie schon erwähnt kann der Artikel nur einen kleinen Einblick in die RailsWayCon bieten, die von Anfang bis Ende als voller Erfolg zu bezeichnen ist. Schade dass es vorbei ist, die Woche hätte man meinetwegen gerne voll machen können. Aber da bleibt nur übrig sich auf nächstes Jahr zu freuen.

Die Plattform wurde in nur 6 Wochen from scratch entwickelt. Ausgangslage waren lediglich ein mehr oder weniger grobes Konzept sowie ein darauf basierendes und damit zwangsläufig zu Anfang ebenso grobes Design. Eine Vielzahl von wichtigen Entscheidungen zu Design und Funktionalität wurde also erst relativ spontan während der Entwicklungsphase getroffen.

Dieser Artikel geht auf einige technische Aspekte des Projekts ein und zeigt auf wie viel man mit Rails in kurzer Zeit bei hoher Qualität und Flexibilität erreichen kann.

Infrastruktur

Am Anfang eines jeden Projekts steht das Aufsetzen der Infrastruktur wie Versionskontrolle, Ticketing System etc. Hier muss man sich entscheiden ob man alles selbst aufsetzen möchte (SVN, Trac etc.) oder lieber auf SaaS Angebote zurückgreift. Diese haben den Vorteil, dass keinerlei oder nur sehr geringer Aufwand entsteht und sie (evtl. mit Ausnahme von github zuverlässig laufen.

Für dieses Projekt habe ich mich für die Kombination aus gihub, Lighthouse und Hoptad entschieden, die sich auch in vergangenen Projekten schon bewährt hat. Insbesondere die Integration der einzelnen Services ist dabei ein großer Vorteil. So kann man bspw. in Commit Messages Lighthouse-Tickets referenzieren oder sogar modifizieren und seit neuestem auch aus in Hoptoad angezeigten Backtraces direkt auf den entsprechenden Code in der entsprechenden Revision auf github wechseln.

Testing

Obwohl ich selbst ein großer Freund von Testing bzw. Specs bin (siehe auch meinen Vortrag zu RSpec) muss man bei einem Projekt wie diesem, mit straffem Zeitrahmen und zunächst mehr oder weniger ungenauen Anforderungen, abwägen zwischen Flexibilität und Entwicklungsgeschwindigkeit auf der einen und gut getestetem Code auf der anderen Seite. Wenn die Anfoderungen nicht einigermaßen eindeutig bekannt und insb. formuliert sind, ist es fast kontraproduktiv, zunächst eine umfassende Test- bzw. Spec- Suite zu schreiben, da das durch eine solche Suite spezifizierte Verhalten ja noch gar nicht ausreichend bekannt ist. Es fließt in diesem Fall also viel Arbeit in die permanente Aktualisierung der Specs so dass es sicher mehr Sinn macht, mindestens den Prototypen quasi auf althergebrachte Art und Weise zu entwicklen und die Anwendung erst in der Konsolidierungsphase umfassend zu testen. Ich habe daher weitestgehend auf Specs verzichtet und lediglich Dinge wie Validations etc. spezifiziert um sicherzugehen, dass das grundlegende Model korrekt ist. Das eigentliche Acceptance Testing wurde jeweils zum Abschluss der einzelnen Milestones vom Kunden selbst durchgeführt. So erhält der Entwickler frühzeitig Feedback vom Kunden, der widerum frühzeitig einen Blick auf seinen zukünftige Anwendung werfen und den Entwicklungsverlauf verfolgen kann.

Per Scaffolding zum (fast) fertigen Backend

Das oftmals zu recht kritisierte Scaffolding kann für prototypische Anwendungen und insbesondere Backend-Funktionalität gute Dienste leisten. Bei einem Content getriebenen Dienst wie Globago.com, bei dem die Hauptaufgabe des Backends das Anlegen, Bearbeiten, Löschen etc. von unterschiedlichem Content ist, kommt man per Scaffolding – selbst wenn man die generierten Controller, Views etc. noch anpassen muss, innerhalb kürzester Zeit zum fertigen Backend. Alternativ macht sicher auch der Einsatz von Plugins wie Hampton Catlins make_resourceful Sinn, die im Gegensatz zu ./script/generate scaffold ... DRY- konformer sind, allerdings nicht das manuelle Anlegen von Views ersparen.

Deployment

Für das Deployment von Rails Anwendungen gibt es mittlerweile eine Vielzahl von Optionen. Die mit dem geringsten Aufwand ist aber sicherlich Passenger, das in der neusten Version jetzt auch für Nginx verfügbar ist. Gegenüber anderen Ruby Webservern wie Mongrel oder Thin hat Passenger zwar keinen signifikanten Performance Vorteil, in der Regel aber einen deutlich kleineren Memory Footprint. Vor allem wird aber das Deployment deutlich vereinfacht. Anstatt mongrel_cluster oder thin start --socket ..., wobei man ggf. noch darauf achten muss, die einzelnen Prozesse zeitversetzt neu zu starten um Downtimes zu vermeiden (siehe auch Poor mans rolling restart for thin + god), genügt bei Passenger ein einfaches touch restart.txt im RAILS_ROOT und Passenger startet die Anwendung automatisch neu, spawnt Prozesse etc. Auch ist kein Monitoring von Prozessen mehr nötig wie es bei Mongrel oder Thin praktisch unverzichtbar ist. Auch die Konfiguration von Passenger ist denkbar einfach – insbesondere in Kombination mit Nginx:

  http {
    passenger_root /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/passenger-2.2.1;
    passenger_ruby /opt/ruby-enterprise-1.8.6-20090201/bin/ruby;
    ...
    server {
        listen       80;
        server_name  *.globago.com;

        root <path to RAILS_ROOT/public>;
        passenger_enabled on;
    }
    ...
  }

Fazit

Das Projekt Globago.com zeigt deutlich, wie viel sich in kurzer Zeit mit Rails realisieren lässt. Es lassen sich extrem schnell Features umsetzen (auch ohne die komplette Anwendung einfach zu scaffolden ohne dass die Qualität des Ergebnisses leidet. Mit anderen Frameworks mag sich ebenso viel in ebenso kurzer Zeit realisieren lassen, das Ergebnis ist aber mit relativ hoher Sicherheit minderwertiger. Auch existiert mit github, Lighthouse, Hoptoad und anderen Diensten eine hervorragende Projekt- Infrastruktur als SaaS.

Das Projekt

Letzten Donnerstag (02.04.2009) hielt ich bei der Münchner Ruby on Rails User Group einen Vortrag zum Thema “Was ist Rack?”.

Der Talk dauert gute 20 Minuten und beantwortet unter anderem:

• Was ist Rack?
• Wie sieht eine einfache Rack-Anwendung aus?
• Welche Vorteile bietet Rack?
• Wer verwendet Rack?
• Wie profitieren Rails-User? Wie können Rails-User Rack verwenden?
• Rack in anderen Sprachen
• Q&A

Download (650 MB, 720HD 16:9, Quicktime)

Die Folien gibts direkt auf meiner Website.

Weitere Links:

• http://rack.rubyforge.org/
• http://github.com/rack/
• Weitere Vorträge zu Rack

wc -l app/models/* | sort

Fertig? Ok. Alle Nicht-Windows-User sollten eine hübsche Liste an Zahlen und Dateinamen zurück bekommen haben. Alle Leser, bei denen in den letzten 3 Einträgen der Liste die Datei user.rb auftaucht, oder ein Eintrag mindestens vierstellig ist, würde ich bitten diese Zeile in einen Kommentar zu pasten. Danke.

Warum Kate Moss keine Rails-Entwicklerin wurde

Im Lebenszyklus einer Webanwendung werden ständig neue Features entwickelt. Nach dem Credo “Skinny Controller – Fat Model” wandert die Business-Logik der Features in das Model, und das ist auch richtig so. Für viele Rails-Entwickler ist Model aber gleichbedeutend mit ActiveRecord, und so wachsen diese Klassen oft auf unübersichtliche Größen an. Das User-Model ist hier ein besonders populäres Opfer, insbesondere wenn es nicht um ein Profile- oder Person-Model ergänzt wurde.

Höchste Zeit also für ein wenig Refactoring! Und das geht so:

Ruby-Lego: Module und Mixins

Die einfachste Möglichkeit besteht darin, thematisch verwandte Methoden in Modulen zu sammeln und per include im Model verfügbar zu machen. Idealerweise werden diese Module dann in einem separeten Namespace gruppiert:

# app/models/user.rb
class User < ActiveRecord::Base
  include UserStuff::Admin
end
 
# app/models/user_stuff/admin.rb
module UserStuff
  module Admin
    def schedule_backup
      # ...
    end
  end
end

Wird die gleiche Funktionalität von verschiedenen Klassen benötigt, lassen sich solche Mixins bei entsprechendem Design auch wiederverwenden:

# app/models/user.rb
class User < ActiveRecord::Base
  include Authentication
end
 
# app/models/api_client.rb
class ApiClient
  include Authentication
end
 
# lib/authentication.rb
module Authentication
  def authenticate(credentials)
    # authenticate via ldap, kerberos etc.
  end
end

Der Unterschied zwischen Klassen in Ruby und Postschaltern zur Mittagszeit

Als Alternative zu Modulen, lässt sich der Umstand ausnutzen, dass Klassen in Ruby immer offen sind. Es können jederzeit weitere Methoden hinzugefügt werden, wodurch sich lange Klassendefinitionen einfach aufzusplitten lassen um sie in separaten Dateien abzulegen:

# app/models/user.rb
class User < ActiveRecord::Base
  def name
    "#{first_name} #{last_name}"
  end
end
require_dependency 'user/admin'
 
# app/models/user/admin.rb
class User < ActiveRecord::Base
  def schedule_backup
    # ...
  end
end

Jake Howerton hat dieses Muster in seinem (ganze 7 LOC umfassenden) Gem, concerned_with, mit etwas syntaktischem Zucker versehen:

class User < ActiveRecord::Base
  concerned_with :admin, :validations, ... 
  # ...
end

Hier werden automatisch die Dateien app/models/user/admin.rb und app/models/user/validations.rb geladen.

Kosmetik für Models

Sowohl Module als auch “concerned_with” haben leider einen gravierenden Nachteil: Es ist meist reine Kosmetik. Die Methoden werden lediglich in eine andere Datei verschoben, verschmutzen aber weiterhin den Namensraum der ursprünglichen Klasse. Werden Methoden der Urprungsklasse überschrieben, gibt es auch keine einfache Möglichkeit auf die Originalimplementierung zurückzugreifen. Allein die Lösung mit Modulen lässt zumindest zu, eine von der Klasse überschriebene, aber in einem Modul definierte Methode mittels super zu referenzieren. In der Regel ist aber eher der umgekehrte Fall erwünscht, nämlich die Methode der Klasse zu überschreiben. Zudem führt ein solches Vorgehen zu einer unschönen Kopplung von Modul und Klasse – die Methode der Klasse muß von der Existenz des Moduls wissen.

Ein weitaus größerer Nachteil ist jedoch, dass die Methoden selbst dafür sorgen müssen, nie im falschen Kontext aufgerufen zu werden. Im obigen Beispiel würde dies vermutlich wie folgt aussehen:

def schedule_backup
  raise "Security Error!" unless has_role?(:admin)
  #...
end

Die Methode muß sich hier unnötigerweise mit administrativer Logik herumschlagen, die nichts zu ihrem eigentlich Auftrag, dem Anstoßen eines Backups, beiträgt. Möchte man nicht auch noch Aspektorientierung aus der Trickkiste hervorholen, müsste der entsprechende Code zudem in jeder verwandten Methode dupliziert werden – ein klarer Verstoß des in Rails heiligen DRY-Prinzips.

Zur Verteidigung von “concerned_with” darf nicht unerwähnt bleiben, dass das kanonische Beispiel für dieses Gem die Auslagerung von Validations und ähnlichem ist. Für solche Zwecke ist es bei komplexen Klassen durchaus nützlich.

Erbschaften sind immer willkommen!

Eine klassische, objektorientierte Herangehensweise an solche Probleme ist ohne Zweifel Vererbung:

# app/models/user.rb
class User < ActiveRecord::Base
  def name
    "#{first_name} #{last_name}"
  end
end
 
# app/models/admin.rb
class Admin < User
  def schedule_backup
    # ...
  end
end

Durch diesen Ansatz wird sichergestellt, dass jedes Objekt nur die Methoden besitzt, die es auch besitzen darf. Zusätzliche Prüfungen im Code, wie im obigen Beispiel, sind daher nicht notwenig. Aus überschriebenen Methoden in Admin lässt sich auch einfach per super die gleichnamige Originalmethode in User aufrufen.

Rails unterstützt Vererbung in ActiveRecord-Models sehr bequem mittels STI (Single Table Inheritance) durch Hinzufügen einer type-Spalte zur jeweiligen Tabelle.
Dieser Ansatz ist aber nur sinnvoll, wenn tatsächlich eine “is_a”-Beziehung vorliegt. Er funktioniert auch nur 1x pro Klasse, da Ruby keine direkte, mehrfache Vererbung erlaubt. Letzteres lässt sich in manchen Fällen durch komplexe Vererbungshierarchien abbilden, aber unnötige Komplexität ist ja gerade das, was wir mit Ruby vermeiden wollen.

“Das Ganze ist mehr als die Summe seiner Teile”

Entscheidend für ein gelungenes Refactoring ist oft die Erkenntnis dass der bestehende Code nicht mehr hinreichend die Realität abbildet.
Dinge in der realen Welt bestehen immer aus anderen Dingen, die wiederum aus weiteren Dingen bestehen.
Solche Beziehungen werden in Rails üblicherweise durch die gängigen Assoziationsmakros has_many, has_one usw. implementiert. Diese Makros eignen sich jedoch nur für persistente ActiveRecord-Objekte. Da der gemeine Rails-Entwickler an sich eher faul ist, ignoriert er mangels bequemer Makros gerne die Tatsache, dass nicht alle Teile einer solchen Composition persistent sein müssen.

Jamis Buck hat im Blog von 37signals ein sehr schönes Beispiel veröffentlicht, wie er vormalig im User-Model definierte Methoden zur Manipulation von Avataren in eine eigene, nicht persistente, Avatar-Klasse auslagern konnte. Im obigen Beispiel würde sich diese Lösung wie folgt gestalten:

# app/models/user.rb
class User < ActiveRecord::Base
  # ...
  def admin
    @admin ||= AdminCapability.new(self) if has_role?(:admin)
  end
end
 
# app/models/admin_capability.rb
class AdminCapability
  def initialize(user)
    @user = user
  end
 
  def schedule_backup
    # ...
  end
  # ...
end

Um dem ganzen mehr Composition-Character zu verleihen, sind administrative Methoden jetzt in der AdminCapability-Klasse untergebracht. Aufgerufen werden sie wie folgt: user.admin.schedule_backup. Der Vorteil gegenüber der Lösung mit Vererbung liegt auf der Hand: Wir können beliebig weitere Capabilities erfinden und sauber vom Code der User-Klasse getrennt implementieren.

Für komplexere Szenarion bietet ActiveRecord im Aggregations-Modul das composed_of-Makro. Zweck von Aggregations ist es hauptsächlich Value-Objects abzubilden. Für den Anwendungsfall, “Avatar”, von Jamis Buck wäre es also durchaus ebenso geeignet.
Ein weiteres, beliebtes Beispiel sind Adressen: Möchte man, z.B. aus Performance-Gründen, keine separate addresses-Tabelle, können die Felder in der users-Tabelle angelegt und mittels composed_of als Address-Objekt zur Verfügung gestellt werden. Die Address-Klasse selbst kann dann komplexe Methoden – etwa Geocoding – implementieren.

Verlängerte Beziehung

Beziehungen zwischen Klassen benötigen häufig Funktionalität die in Beziehung stehenden Objekte zu manipulieren oder zu verwalten. Die gängigsten Operationen, wie das erzeugen, löschen oder finden assoziierter Objekte, werden durch die Association-Makros (has_many etc.) bereits zur Verfügung gestellt:

user = User.first
user.addresses.create :street => "Musterstr. 2", :city => "München"
user.addresses.destroy_all

Funktionen die darüber hinausgehen und selbst implementiert werden müssen, landen allzuoft einfach in der Klasse selbst, bei unseren Codebeispielen war dies etwa has_role?.
Dabei bietet ActiveRecord eine sehr saubere Möglichkeit diese assoziationsspezifische Logik zu kapseln: Association Extensions.

Solche Extensions können entweder als Blockparameter des Assoziationsmakros, oder in eigenständigen Modulen implementiert sein. In unserem Beispiel sähe dies so aus:

# app/models/user.rb
class User < ActiveRecord::Base
  has_and_belongs_to_many :roles, :extend => RoleManagement
end
 
# app/models/role_management.rb
module RoleManagement
  def got?(role_name)
    exists? :name => role_name.to_s
  end
end

Anstatt user.has_role?(:admin) kann das Vorhandensein der Rolle nun mit user.roles.got?(:admin) geprüft werden.

Automatische Beziehungsverlängerung

Mit einem kleinen Griff in die Metaprogrammierungs-Trickkiste lässt sich aber noch mehr erreichen. In unserem Beispiel gibt es sowohl eine Rolle namens “admin”, als auch eine Klasse, zuletzte AdminCapability genannt, die die dazugehörige Business-Logik implementiert.

Wäre es nicht nett wenn je nach zugewiesenen Rollen automatisch die entsprechenden Capability-Objekte zur Verfügung stünden?

Um es kurz zu machen: Ja – das wäre nett! Und so gehts:

# app/models/role_management.rb
module RoleManagement
  def method_missing(method, *args)
    @capabilities ||= {}
    @capabilities[method] ||= begin
      return super if method.to_s == 'exists?' || !exists?(:name => method.to_s)
      "#{method.to_s.camelize}Capability".constantize.new(proxy_owner)
    end
  end
end

method_missing sorgt hier dafür dass falls der proxy_owner, also hier der User, über die gegebene Rolle verfügt, exists?(:name => method.to_s), ein entsprechendes Capability-Objekt erzeugt wird. Wurde es bereits erzeugt und im @capabilities-Hash abgelegt, wird einfach dieses zurückgegeben.
Andernfalls wird mittels super die nächste Implementierung von method_missing aufgerufen. Dies ist wichtig, da die Association-Proxies von ActiveRecord selbst sehr viel mit method_missing arbeiten: Z.B. wird auch der Aufruf von exists? über diesen Mechanismus abgefangen, daher muß er hier explizit behandelt werden.

Angenommen wir fügen jetzt noch eine Rolle “author” und die dazugehörige Klasse AuthorCapability ein, lässt sich diese neue API wie folgt nutzen:

user.roles.admin.schedule_backup  #=> ...
user.roles.author                 #=> NoMethodError: undefined method author...
user.roles << Role.find_by_name("author")
user.roles.author                 #=> #<AuthorCapability:0x22384d8>
user.roles.author.publish_post!   #=> ...

Kommen wir endlich zum Schluß

Ich hoffe, ich konnte in diesem Artikel zeigen, dass Models nicht zwingend an Übergewicht leiden müssen. Auch wenn es vielleicht nicht für Heidi Klums Show reicht, so können unsere Models mit der Modul-Diät, der concerned_with-Kur, der Composition-Diät oder der Association-Extension-Formel genug überflüssige Pfunde verlieren um eine erfolgreiche Karriere auf den virtuellen Laufstegen des Webs machen.

Die Freiheit in der Syntax half sehr zu einem schnellen Ergebnis zu kommen und das bewegte mich dazu zu recherchieren, wie denn andere Entwickler mit deren Background an die Sache rangehen. Resultat waren einige interessante Konstrukte deren Performance ganz unterschiedlich ist.

Vorab möchte ich den/die Leser/in bitten, sich nicht auf den Schlips getreten zu fühlen, falls er/sie sich in Syntax oder Semantik der ausgegrabenen Beispiele wiedererkennen sollte. Die Klassifizierung der Beispiele in “Entwicklertypen” ist lediglich humorvoll gemeint. Im Prinzip kann jeder auf jede der Lösungen kommen, bis auf eine vielleicht und ich meine nicht meine.

Das Problem, dass ich am liebsten in neue Sprachen umsetze sind Primzahlen. Die einfachste Möglichkeit hierbei ist es von 2 bis max zu interieren und dabei jede Zahl zu prüfen ob von 2 bis sqrt(max) die Modulooperation 0 ergibt. Das ist jedoch nicht die beste. Der griechische Mathematiker Eratosthenes von Kyrene hatte sich hierbei ein “Sieb” ausgedacht, was im Prinzip ein Array darstellt in dem alle Vielfachen einer Zahl gestrichen werden. Dieser Alorithmus stellt demnach auch die Standardimplementierung im Schulungsbereich dar, da man sie einfach visualisieren kann.

Doch wie stellen sich die Umsetzung nun Entwickler vor? Da hätten wir als erstes mal den

C-Programmierer

Er denkt kompakt und liebt kurze Variablennamen. Sein einziger Gedanke gilt der optimalen Speicherauslastung bei maximaler Effizienz. So könnte seine Lösung aussehen:

1
2
3
4
5
6
7
8

def prim_cway(max)
  i=l=1
  while ((l*=i) && (i<max))
    if ((l%i+=1)>i-2) then
      printf("%d ",i);
    end 
  end
end

Natürlich hätte man sich hier auch an das Sieb halten können, aber die Primzahlen sollen ja möglichst schnell berechnet werden und ausserdem liegt Tosthi hier völlig falsch, da er ja noch nicht auf embedded Prozessoren hacken musste und Doppelschleifen sowieso saugen.

Aber wie funktioniert der Code nun in nur einer Schleife? l wird pro Durchlauf immer um i vervielfacht. In der if-Anweisung erfolgt die Erhöung von i um 1 allerdings noch bevor das Modulo ausgeführt wird, weil Zuweisungen in Operationen vorgezogen werden. Das Ergebnis ist also nicht größer als i-1. Handelt es sich bei i um eine Primzahl, so wird l % (i+1) = 0 werden und ist somit kleiner als i-2. Im Prinzip könnte man auch hier auf 0 vergleichen, jedoch würden dann die 1 und 2 mit ausgegeben, die eine Ausnahme bilden. Diese Lösung implementiert übrigens die sogenannte Lineare Rekursion basierend auf dem kleinen Satz des Fermat. Aber lasst uns die Franzosen bei Seite schieben und wieder zurück zu unserem Griechen kommen.

Der Java-Programmierer wird sich hier eher am Sieb orientieren und vorhandene Klassen und Methoden genauer betrachten und auch einsetzen.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

def prim_erat1(limit)
  return [] if limit < 2
 
  length = ((limit/2) - 1 + limit%2)
 
  sieve = [true] * (length+1)
 
  0.upto((Math.sqrt(limit).to_i >> 1) - 1) do |i|
    next if not sieve[i]
 
    (((i*(i+3) << 1) + 3)...length).step((i << 1) + 3) do |j|
      sieve[j] = false
    end
  end
 
  primes = [2]
 
  0.upto(length-1) do |i|
    primes << (i << 1)+3 if sieve[i]
  end
 
  primes
end

Die Vorgehensweise hier ist erst einmal ein Array mit “max” Keys mit true-Werten zu füllen. In der Schleife werden mit einer weiteren inneren Schleife durch die Benutzung von step die Vielfachen ausradiert und anschliessend befüllt man das Ergebnisarray mit den Zahlen für denen die true-Werte im Siebarray übrig geblieben sind. Diese Version ist wesentlich umfangreicher als die des C-Programmierers, jedoch versteht man die Logik eher.

Wobei wir auch schon beim PHP-Programmierer ankommen

Er denkt ähnlich wie der Java-Programmierer, wobei er es nicht so mit komplexen Iteratoren hat. Da man ihn jedoch bei Ruby seiner geliebten C-ähnlichen for-Schleife beraubt hat, muss er sich wohl oder übel mit step auseinandersetzen, was er jedoch schnell intus hat.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

def prim_erat2(max)
  sieve = []
 
  for i in 2 .. max
    sieve[i] = i
  end
 
  for i in 2 .. Math.sqrt(max)
    next unless sieve[i]       
 
    (i*i).step(max, i) do |j|
      sieve[j] = nil
    end
  end
  sieve.compact
end

Auch diese Lösung implementiert das Sieb wie es ursprünglich gedacht war. Nur wird hier direkt auf dem Array operiert, das alle Zahlen bis max enthält. Gestrichene Werte werden durch nil ausradiert und das Array wird anschliessend wieder komprimiert.

Objective-C

Der Homo Sapiens Cocoaensis, auch Objective C Mensch genannt, ist es gewöhnt C mit funktionalen Elementen zu mischen und dabei mehr drauf zu achten, dass man große Teile des Algorithmus möglichst singen kann. Die Performance wird erst nachträglich über Tools wie XCode Instruments angepasst.

1
2
3
4
5
6
7

def prim_asearch(max) 
  a=Array.new
  for i in 2..max do
    a << i unless (2..i-1).find {|j| i % j == 0}
  end
  a
end

Ganz brutal werden hier mittles der find Methode für jede Zahl i zwischen 2 und max die Werte über ein anonymes Array mit dem Blockiterator j gefunden, für die i modulo j gleich 0 zutrifft. Es funktioniert, jedoch ist die Performanz suboptimal.

Smalltalk

Der Smalltalk Typus liebt es untypisiert und objektorientiert und packt das ganze am liebsten in eine Zeile. Er steht in der Evolutionsstufe noch über dem Objective-C Menschen. Dabei ist es ihm sogar egal, ob er selbst den Code noch lesen kann und singen wird er ihn gleich zweimal nicht. Es stellt eher eine Art Gebet dar.

1
2
3

def prim_inject(max) 
  (2..max).inject((2..max).to_a) {|res, i| res.select{|n|n==i||n%i!=0} }
end

Hier muss man zweimal hinschauen um zu verstehen was passiert. Das inject erhält als Initialwert ein Array mit der gleichen Range. Im Block ist nun jeder Memowert gleich dem Array. Aus diesem werden alle Werte selektiert für die der Ausdruck im Bock false ergibt. Hier verwirren die vielen Pipes etwas. Das |n| ist schlicht der Blockiterator und die zwei Pipes in der Mitte stellen eine oder-Verküpfung dar. Das select liefert einen Wert zurück, wenn der Ausdruck true ergibt. Dies trifft zu, wenn der Iterator i gleich dem Iterator n oder n modulo i ungleich 0 ist also für die Fälle dass die “innere” Schleife durchlaufen ist oder der innere Schleifenwert modulo äusserer Schleifenwert über einen Teilerrest verfügen.

Sehr ineffizent in diesem Beispiel ist die Tatsache, dass hier der Initalwert des injects als Schleife missbraucht wird und dieser dann auch im memo-Teil des Blocks landet. Wie bei allen Lösungen mit Doppelschleifen steigert sich die Laufzeit proportional zu der Range. Bei dieser Funktion ist es jedoch noch schlimmer, da hier ganze Arrays als Parameter übergeben werden was auch sehr schnell zu einem Stackproblem führen wird.

Dass es noch kryptischer und lastreicher gehen kann soll uns das letzte Exempel zeigen.

Der Perl-Programmierer

Er ist der Meister der Skripte wenn es um das schnelle Verarbeiten von Listen, Texten geht, ganz gleich welchem Format sie auch ganz oder teilweise unterliegen mögen. Er kann das weil er das mächtigste Werkzeug aller sein Eigen nennt: den regulären Ausdruck. Diese Genies der Musterkennung bestehen den Turingtest mit Leichtigkeit und es gibt nichts was man damit nicht lösen kann. Nicht einmal das Finden von Primzahlen. Das glauben Sie nicht? Dann sehen und staunen Sie:

1
2
3
4
5
6
7

def prim_regex(max)
  a=Array.new
  2.upto(max) do |n| 
    a << n if (("1" * n) !~ /^1?$|^(11+?)\1+$/)
  end
  a  
end

Obiges ist zugegebenermassen die nerdigste Umsetzung des Siebs und auch die langsamste. Die Regular Expression macht sich hier die Möglichkeit des Backreferencing zu eigen. Erst wird ein String mit einer Anzahl von Einsen erzeugt, die dem momentanen Interatorwert n entspricht. Die RegEx matcht links wenn der String leer ist oder eine 1 enthält. In diesem Fall handelt es sich nicht um eine Primzahl (weil !~ den Match negiert). Jetzt kommt der zweite Teil. Der Teil in den Klammern prüft erst ob “11″+? matcht. Das ist der Fall und es wird “11″ in die Backrefvariable \1 geschrieben. Dort wird jetzt geschaut ob “11″+, also ein oder mehrere Vorkommnisse den String matchen. Ist das nicht der Fall. Dann wird nochmal der gesamte Rechte Teil geprüft, wobei jetzt der Klammernteil mit “111″+? matchen muss (was er immer tut, weil ganz oder gar nicht gegeben ist) und der hintere Teil mit “111″+. Dadurch erreicht man die Prüfung auf Vielfache und somit die Umsetzung des Siebs, wenn auch auf Kosten von sehr langen Ausführungszeiten.

Benchmarks

Führt man nun einen Bechmarktest aus und vergleicht die Laufzeiten, so kommt man sehr schnell zu einem Schluss. Alle Varianten, die zwei verschachtelte Schleifen benötigen sind der korrekten Umsetzung des Siebs, also der wirklichen Bereinigung eines Arrays weit unterlegen. Am stärksten schlägt hier die Injectionmethode zu buche. Sie wird nur noch von der RegEx-Variante getoppt, wobei man die nicht wirklich ernsthaft ins Rennen schicken darf, da die Ausführgeschwindigkeit stark von der Implementierungsart ihres Algorithmuses abhängt. Die “C-Variante” ist nur deshalb so schnell, weil sie nicht das Sieb implementiert wird aber wegen des exponentiellen Anstiegs des Dividenden schnell zum Überlauf führen. asrc und inj haben zusätzlich zu den vielen Arrayoperationen das Problem eines teueren Modulos auf das er1 und er2 gewinnbringend verzichten konnten.

1
2
3
4
5
6
7

           user     system      total        real
reg    3.070000   0.260000   3.330000 (  3.354881)
er1    0.000000   0.000000   0.000000 (  0.002403)
er2    0.000000   0.000000   0.000000 (  0.004381)
c      0.240000   0.000000   0.240000 (  0.244020)
asrc   0.910000   0.000000   0.910000 (  0.929468)
inj    2.320000   0.020000   2.340000 (  2.362957)

Meine Lösung

Wenn der/die Leser/in jetzt ein Glanzstück an Effizienz und Geschwindigkeit erwartet, so muss ich ihn/sie leider enttäuschen. Über das schon zu oft benannte weil synonymlose Sieb des Eratosthenes habe ich mir einfach zu oft den Kopf zerbrochen. Daher wird genommen was man geboten bekommt.

1
2
3
4
5
6
7
8
9

require 'mathn'
 
def prime_mine(max) 
  pa=Array.new
  pn=0;
  p=Prime.new
  pa << pn while ((pn=p.next()) < max)
  pa
end

Was den Benchmark angeht, der liegt irgendwo zwischen c und asrc. Der Alorithmus, der hier benutzt wird ist mir leider nicht bekannt. Wer jetzt Lust verspürt es herauszufinden und gegebenenfalls sogar zu optimieren, der möge bitte walten und darf auch gerne einen Kommentar hierzu hinterlassen.

Fazit

Welche Lösung gewinnt jetzt eigentlich? Natürlich jede, denn jede ist funktionierender Ruby Code. ) Scherz beiseite, hier geht es natürlich nicht um Gewinner und Verlierer. Es soll lediglich klar gemacht werden, dass die Lernkurve bei Ruby dank der Flexibilität in der Syntax sehr niedrig gehalten ist. Auch wird verdeutlicht, dass man mit Ruby sehr effizienten und schnellen Code liefern kann und das bei guter Lesbarkeit.

Mit DSLs will man folgende Ziele erreichen:

• weniger Redundanz
• deklarative Beschreibung eines Sachverhaltes
• bessere Lesbarkeit
• weniger technischer Code
• leichte Erlernbarkeit aufgrund des beschränkten Umfangs

Die DSLs lassen sich grob in zwei Klassen unterteilen:

Externe DSLs werden durch einen, meist speziell dafür geschriebenen, Parser eingelesen und dann interpretiert.

Vorteile:

1. Die DSL kann vollkommen frei aufgebaut werden.
2. Ein Dokument der DSL wird Interpretiert (gelangt also nicht direkt zur Ausführung) wodurch mögliche Sicherheitslücken vermieden werden.

Nachteile:

1. Für jede DSL muss ein Parser geschrieben werden.
2. Enthält das Dokument dynamische Elemente müssen diese ebenfalls geparst und interpretiert werden.

Beispiele für DSLs sind eine Reihe von Konfigurationsdateien:
crontab, Makefile ,…
Neuere Systeme gehen dazu über die DSL in From von XML Dateien zu verarbeiten. Das hat den Vorteil, dass ein gewöhnlicher XML-Parser verwendet werden kann. Der Nachteil ist, dass die DSL nicht mehr frei ist und evtl. mehr Tipparbeit erforderlich ist (hohe Redundanz). Dynamische Inhalte müssen ebenfalls nachträglich interpretiert werden.

Interne DSL benutzen Komponenten der Wirtssprache  um die DSL zu parsen und auszuwerten. Die Vor/Nachteile sind genau umgekehrt zu den externen DSL.

In der Ruby Gemeinschaft werden, da Ruby selbst eine sehr freie Syntax hat, meist interne DSLs verwendet. An einem Beispiel soll die Implementierung einer DSL erläutert werden.

Der folgende Code stellt die Klassen Lexicon, Word und Wordform zur Verfügung. Damit soll der Aufbau eines einfachen Lexikons möglich sein.

class Lexicon
  def initialize
    @words={}
  end
  def add_word(word)
    @words[word.uname]=word
  end
  def show
    @words.each_value do |word|
      puts word
    end
  end
end
 
class Word
  attr_reader :uname, :forms, :categories
  def initialize(uname)
    @uname=uname
    @forms=[]
  end
  def add_form(form)
    @forms << form
  end
  def to_s
    forms.inject("#{uname}:\n") do |out, form|
      out << form.to_s << "\n"
    end
  end
end
 
class WordForm
  attr_reader :form, :categories
  def initialize(form, categories)
    @form=form
    @categories=categories
  end
  def is?(value)
    @categroies.values.include?(value.to_s)
  end
  def to_s
    "#{form} - #{categories.inspect}"
  end
end

Ein Lexikon lässt sich wie folgt aufbauen:

l=Lexicon.new
w=Word.new('gehen')
wf=WordForm.new('ging', :tempus => :imperfect, :numerus => :sg3, :genus => :m)
wf2=WordForm.new('ging', :tempus => :imperfect, :numerus => :sg1)
w.add_form wf
w.add_form wf2
l.add_word(w)

Zum Testen:

l.show
 
gehen:
ging - { :tempus => :imperfect, :numerus => :sg3, :genus => :m }
ging - { :tempus => :imperfect, :numerus => :sg1 }

Der erste Ansatz

Der erste Schritt zur Vereinfachung des Aufbaus soll wie folgt aussehen:

l=Lexicon.new do |lex|
  lex.word('gehen') do |word|
    word.form('ging', :tempus => :imperfect, :numerus => :sg3, :genus => :m)
    word.form('ging', :tempus => :imperfect, :numerus => :sg1)
  end
end

Dafür müssen die Klassen erweitert/ergänzt werden:

class Lexicon
  def initialize
   @words={}
   yield self
  end
  def word(*attr)
    wrd=Word.new(*attr)
    yield wrd
    add_word(wrd)
  end
end
class Word
  def form(*attr)
    frm=WordForm.new(*attr)
    add_form(frm)
  end
end

Drei Dinge sind an diesem Ansatz “unvorteilhaft”:

1. Die Verknüpfung der Klassen untereinander durch Aufruf der Konstruktoren (Lexikon <-> Word und Word <-> WordForm). Der Nachteil wird bei der Vererbung der Klassen sehr deutlich.
2. Die klare Struktur der Klassen wurde durch die Methoden, die für die DSL benötigt werden verunreinigt. Die DSL sollte auf dem Model aufsetzen und diese so wenig wie möglich beeinflussen.
3. Die DSL ist noch immer “unschön”. Am besten wäre es, wenn das Lexikon sich wie folgt aufbauen liesse:

l=lexicon do
  word 'gehen' do
    form 'ging', :tempus => :imperfect, :numerus => :sg3, :genus => :m
    form 'ging', :tempus => :imperfect, :numerus => :sg1
  end
end

Der richtige Weg

Wir wenden uns also wieder der ursprünglichen Form zu und führen eine neue Klasse LexiconBuilder ein:

class LexiconBuilder
  attr_reader :lexicon
  def initialize(lexicon)
    @lexicon=lexicon
  end
  def word(*attr)
    @word=Word.new(*attr)
    yield
    @lexicon.add_word(@word)
    nil
  end
  def form(*attr)
    frm=WordForm.new(*attr)
    @word.add_form(frm)
    nil
  end
end

Dann benötigen wir noch die Definition von lexicon:

def lexicon(&block)
  lexikon=Lexicon.new
  builder=LexiconBuilder.new(lexikon)
  builder.instance_eval &block
  lexikon
end

Hier liegt ein wenig Ruby Magie in der Luft. Nachdem das Lexicon und der LexiconBuilder erzeugt werden, wird der übergebene Block im Kontext des Builders ausgeführt. Jegliche Methodenaufrufe erfolgen also auf der Instanz von LexiconBuilder.

LexiconBuilder übernimmt hier die Rolle des Parsers. Es stellt alle (word, form) syntaktischen Elemente der DSL bereit und baut die Struktur wie gewünscht auf.

Die Vorteile liegen auf der Hand:

1. Keine Einführung neuer Abhängigkeiten in bestehenden Klassen
2. Alle Ahängigkeiten sind in LexiconBuilder gekappselt, LexiconBuilder lässt sich austauschen um eine andere DSL zu unterstützen.

Dieser relativ einfache Builder hat den Nachteil, dass es die “Syntax”, in unserem Fall die Abfolge der Methodenaufrufe, nicht überprüft. So wäre das folgende Programm durchaus korrekt, würde aber falsche Ergebnisse liefern:

l=lexicon do
  word 'gehen' do
    word 'foobar' do
      form 'ging',:tempus => :imperfect, :numerus => :sg3, :genus => :m
      form 'ging',:tempus => :imperfect, :numerus => :sg1
    end
  end
end

Wie man sieht, ist der Aufbau von DSLs keine Raketenwissenschaft und sollte, wenn der Code “häßlich” wird, auf jeden Fall in Betracht gezogen werden.

Geokit macht das Erstellen von Location-Based-Applikationen sehr einfach. Es stellt mittels einer sehr klar strukturierten API nützliche Funktionen zum Ermitteln eines Standortes, Entfernungsberechnungen und Rückwärtsberechnungen zur Verfügung.

In einem aktuellen Projekt verwenden wir Geokit um auf einer Landkarte die Herkunft unserer Besucher darzustellen und um den Aufbau einer Community zu fördern. „Befindet sich in der näheren Umgebung jemand mit den gleichen Interessen?“

1. Falls noch nicht geschehen müssen wir unserem System zuerst mitteilen wo es das Geokit gem finden kann:

gem sources -a http://gems.github.com

2. Installation des Geokit gems:

sudo gem install andre-geokit

3. Erstellen einer neuen Rails Applikation:

rails -d mysql geokit && cd geokit

4. Die interaktive irb Konsole starten:

irb

5. Das Geokit gem einbinden:

require "rubygems"
require "geokit"

Bei einer erfolgreichen Einbindung sollten folgende Zeilen zu sehen sein:

>> require "rubygems"
=> true
>> require "geokit"
=> true
>>

Als erstes teile ich Google mit wo ich mich momentan befinde:

hier = Geokit::Geocoders::MultiGeocoder.geocode("Hauptstrasse 86, Eislingen")
 
#<Geokit::GeoLoc:0x127b9a0 @city="Eislingen", @lng=9.7082073, @country_code="DE", @provider="google", @street_address="Hauptstra\303\237e 86", @lat=48.7015365, @full_address="Hauptstra\303\237e 86, 73054 Eislingen, Germany", @zip="73054", @precision="address", @state="Baden-W\303\274rttemberg", @success=true>

Dann sage ich Google wo sich mein Büro befindet:

office = Geokit::Geocoders::MultiGeocoder.geocode("Stuttgarter strasse 177, uhingen")
 
#<Geokit::GeoLoc:0x121798c @city="Uhingen", @lng=9.5676341, @country_code="DE", @provider="google", @street_address="Stuttgarter Stra\303\237e 177", @lat=48.7137968, @full_address="Stuttgarter Stra\303\237e 177, 73066 Uhingen, Germany", @zip="73066", @precision="address", @state="Baden-W\303\274rttemberg", @success=true>

Übersichtlicher wird das ganze mit folgendem Aufruf:

>> office.display
Provider: google
Street: Stuttgarter Straße 177
City: Uhingen
State: Baden-Württemberg
Zip: 73066
Latitude: 48.7137968
Longitude: 9.5676341
Country: DE

Wenn ich “nur” die Angaben zu den Breiten- und Längengraden habe kann ich auch eine Rückwärtsabfrage durchführen um die Andresse zu ermitteln:

reverse = Geokit::Geocoders::GoogleGeocoder.reverse_geocode "48.7137968,9.5676341"

und ich erhalte wieder die Adresse meines Büros:

#<Geokit::GeoLoc:0x1280838 @city="Uhingen", @lng=9.5676341, @country_code="DE", @provider="google", @street_address="Stuttgarter Stra\303\237e 177", @lat=48.7137968, @full_address="Stuttgarter Stra\303\237e 177, 73066 Uhingen, Germany", @zip="73066", @precision="address", @state="Baden-W\303\274rttemberg", @success=true>

Wenn ich nun wissen will wie weit mein momentaner Standort von meinem Büro entfernt ist benutze ich folgendes:

>> hier.distance_to(office)
=> 6.47237916523715

Ich muss als jeden Tag ca. 6.5 Kilometer fahren um ins Büro zu kommen.

So, hier ist der Teil 1 auch schon zu Ende. In den nächsten Teilen bauen wir uns Stück für Stück eine eigenständige Rails Applikation welche intensiv mit Google Maps arbeitet. Bis denne.