 | Ruby Weblog Winfried Mueller www.reintechnisch.de |
Wer Skriptsprachen und Objektorientierung mag, findet in Ruby eine ästhetische Ausdrucksmöglichkeit seines Könnens. Plattformübergreifend.
28.01.2010 Ruby-Mysql für Ruby 1.8.4
Es ist gar nicht so einfach, noch ein für Ruby 1.8.4 (Ubuntu Dapper) kompatibles ruby-mysql zu finden. Die Historie dieses Projekts ist nirgendwo mehr vollständig zu finden. Auf github findet man nur die aktuelle Version 2.9.x, die mindestens Ruby 1.8.7 braucht.
Die letzte Version, die noch mit 1.8.4 laufen sollte, scheint mir die 0.2.6 oder 0.2.7 zu sein. Die 0.2.6 findet man hier, wenn man schnell genug im Browser auf Stop klickt, damit die eingerichtete Weiterleitung nicht aufgerufen wird. Oder man nutzt diesen Direktlink.
Die Version 0.2.7 findet sich an anderer Stelle auf github. Sie soll auf jeden Fall unter Ruby 1.8.6 laufen, ein erster Test auf Ruby 1.8.4 war aber erfolgreich.
Unter Ubuntu Dapper braucht es jedoch eine Anpassung. Die Zeile 29 von mysql.rb versucht den mysql Socket an falscher Stelle zu suchen.
unix_socket = socket || ENV["MYSQL_UNIX_PORT"] || MYSQL_UNIX_ADDR ändern in unix_socket = "/var/run/mysqld/mysqld.sock"
Interessant an ruby-mysql ist, dass es im Gegensatz zu mysql-ruby nativ in Ruby programmiert ist, also keine Kompilierung von C-Code braucht. Damit wird es gut auf Systemen einsetzbar, wo man keine Kompiliermöglichkeit zur Verfügung hat, z.B. auf fremd gehosteten Webservern.
Weblinks:
28.01.2010 Low-Level Webentwicklung
Ich brauch ein paar kleine Werkzeuge mit Weboberfläche. Nachdem ich vor 3 Jahren schonmal einen Versuch startete, mich in Rails einzuarbeiten und daran glaubte, damit ganz schnell und unkompliziert Webanwendungen zu schreiben, will ich jetzt nicht wieder den Fehler machen und auf diesen Zug aufspringen. Damals investierte ich etwa 200 Stunden und ja, es sind auch erste lauffähige Anwendungen dabei rausgekommen. Und doch war mein Gefühl, dass ich mindestens nochmal 1000 Stunden hätte reinstecken müssen, um mit Rails wirklich sattelfest zu werden. Auch Rails ist keine Zauberwaffe. Auch wenn manches im Entwicklungsprozess verlockend einfach wird, gibt es viele Baustellen, wo man ewig rumfummelt.
Apropos Baustelle - ich war erschreckt, wie extrem sich in den letzten Jahren rund um Rails alles verändert hat. Meine Bücher, die gerade mal 3 Jahre alt sind, sind hoffnungslos veraltet. Viele neue Projekte rund um Rails sind aufgetaucht. Ich kann mir vorstellen, dass viele eine Menge Spaß daran haben, jeden Tag neue spannende Dinge auszuprobieren. Für mich ist das derzeit eher nichts. Ich will ein System, was sich schon so weit stabilisiert hat, dass ich auch in 5 Jahren mit meinem Know-How noch was anfangen kann. Und ich hab nicht die Zeit, sämtliche Projekte ständig an den neuesten Stand anzupassen.
Man muss sich mal klarmachen, wie viel Zeit man damit verbringt, immer auf dem neuesten Stand zu bleiben. All die Mailinglisten, Foren und Weblogs, die man durchforstet, all die Bücher und Videos, die man studiert, nur um etwas zu begreifen und unter Kontrolle zu haben, was in einem Jahr schon wieder veraltet ist. Jetzt macht man schon wieder alles ganz anders - vielleicht etwas besser und faszinierender, aber wieviel Bedeutung hat das neben dem Spielreiz wirklich für die reale Softwareentwicklung? Kann man schlussendlich all diese Zeit wieder einsparen, weil nun alles viel leichter wird? Ich bin da skeptisch, es sei denn, ich mach den ganzen Tag nichts anderes, als Webentwicklung mit Rails.
Ich will jetzt mal einen anderen Weg einschlagen: Mit ein paar einfachsten Techniken eine Webanwendung zusammenzimmern. Das Zielsystem gibt auch nicht viel her, es läuft noch ein relativ altes Ubuntu Dapper mit Ruby 1.8.4 auf einem 700MHz Server. Dort lässt sich auch nur die gute alte cgi-Schnittstelle verwenden.
Hauptproblem bei vielen neueren Bibliotheken ist die lange anfängliche Ladezeit, womit sie sich nicht für cgi-Webanwendungen eignen. Ich wollte z.B. das interessante Haml zum rendern einsetzen, aber nur das require "haml" dauert schon 4-5 Sekunden. Ähnlich erging es mir damals mit ActiveRecord - das ist alles nicht für cgi geeignet, wo bei jedem Aufruf ein neuer Ruby-Interpreter gestartet wird und erstmal alles laden muss. Der erb + ruby-mysql + cgi lädt hingegen in <1 Sekunde, dass ist brauchbar. Bei den Anwendungen geht es auch um Intranet-Sachen, wo nur wenige Nutzer gleichzeitig drauf zugreifen. Da macht es nichts, wenn mal einige wenige Interpreter parallel laufen.
Froh bin ich übrigens, dass das Entwicklungstempo bei Ruby selbst nicht so schwindelerregend ist. Ich werd wohl noch 3-4 Jahre mit dem 1.8er Zweig arbeiten können. Das Know-How, was ich mir vor 7 Jahren angeeignet habe, ist auch heute noch fast genauso gültig. Und 2014 freue ich mich dann, das bis dahin gut stabilisierte Ruby 1.9.x kennenzulernen.
24.01.2010 Haml Online Renderer
Zum schnellen Ausprobieren für HAML-Code: http://rendera.heroku.com/
<< | RubyWeblog | Archiv 2007 >>