Archiv der Kategorie: Ruby On Rails

Ruby on Rails Entwickler gesucht

Wir unterbrechen dieses Blog für eine Nachricht in eigener Sache:

Ich suche einen Ruby-on-Rails Softwareentwickler zur Festanstellung. Alternativ auch gerne einen Studenten für 15h/Woche.

Geforderte Fähigkeiten:
– Objektorientiertes denken
– Ruby / RubyOnRails oder zumindest sehr gute OO Kenntnisse

Das Projekt:
– Sehr spannender und bekannter Startup

Einsatzort: Zwischen Köln und Düsseldorf.

Bei interesse, einfach per Mail melden.

Ruby On Rails Traps

Ich letzter Zeit habe ich eine größere Rails-Anwendung debugged. Dabei habe ich etwas über einige Stolperfallen gelernt. Wer also ähnliche Probleme hat, hier ein paar Tipps:

Niemals Mongrel und PStore zusammen einsetzen
Wir hatten einige Probleme mit Session-Handling. Der Grund lag daran, dass wir die Sessions im Filesystem gespeichert haben. Laut Mongrel-FAQ soll man das auch nicht machen. Aber weder ich, noch verschiedenste Entwickler und Firmen die ich mit meinem Problem genervt hatte, kamen auf diese Lösung.
Also: Sessions immer in der Datenbank, oder im memcache speichern!

Rails hat große Timeout-Probleme
Wenn Rails bei memcache in einen Timeout läuft, kann sich Mongrel aufhängen. Prinzipiell scheint die IO-Lib von Rails suboptimal programmiert zu sein. Ich bin durch einen Blog-Eintrag bei Rapleaf darüber gestolpert. Dort findet sich auch ein Code-Schnippsel, um das Problem mit memcache zu lösen.

memcache und gettext mögen sich nicht
Der ist auch super. Gettext (dient zur Lokalisierung von Web-Seiten) und der memcache-Client arbeiten nicht vernünftig zusammen. Details und Lösung gibt es hier.

Wenn ich jetzt noch herausfinde, warum memcache Probleme mit dem automatischen expire hat, wird es ein guter Tag.

mod_rails ist wieder draußen

Nach mehreren schlaflosen Nächten habe ich mod_rails aus einem großen Projekt wieder entfernt.
Jetzt werkeln nginx&mongrel_cluster wieder.

Das Problem lag daran, dass mit mod_rails nach 4-5 Stunden der Server keine Anfragen mehr angenommen hat. Außerdem lief ständig der Speicher über.

Ich hoffe nun auf die nächste Version, vielleicht klappt es ja damit besser.

Spaß mit modrails / passenger und Speicherproblemen

modrailsaka passenger ist wie mod_php für Rails (ja, jetzt wird es technisch).

Man kann mit passenger extrem einfach Rails Anwendungen unter Apache laufen lassen. Leider haben viele Leute Speicherprobleme im Zusammenhang mit passenger gemeldet. Ich hatte dazu letzte Nacht ein sehr seltsames Erlebnis:

Eine große Rails Anwendung sollte auf einen neuen (virtualisierten) Server umziehen. Sicherheitshalber habe ich dem Server 2GB Speicher gegeben. Leider schien dies für passenger nicht zu reichen. Selbst mit nur 3 oder 4 Instanzen habe ich den Speicher zu >80% verbraucht. Und nach spät. 1-2 Stunden fing die Maschine an zu swappen oder Apache wollte gar nicht mehr mitspielen.

Da ich aber mal schlafen wollte, habe ich den Server von 2GB auf 3GB erhöht. Das ging aber leider nicht, da nicht mehr gengu Speicher für diese virtuelle Maschine verfügbar war. Ok, aber 2.3GB waren möglich – besser als nichts.

Also die Maschine mit dem leicht höheren Speichern neu gestartet. Ergebnis: Statt 1.7GB haben die Anwendungen nur noch 500Mb Speicher verbraucht. Also hätten die 2GB auch gereicht…

Auf jeden Fall ist es extrem kompliziert, passenger und Apache vernünftig zu konfigurieren. Meine Ergebnisse bislang:

1. Lieber weniger Instanzen aufsetzen:
RailsMaxPoolSize 4
RailsPoolIdleTime 800

3 ist ok, ab 6 wird es bei mir komischerweise wieder langsamer. Standard für RailsMaxPoolSize ist 20 – das würde ich mich
nicht trauen.
RailsPoolIdleZime habe ich einfach hoch gesetzt. Warum sollte ich eine Instanz wieder beenden? Braucht duch nur Zeit zum Neustart. Die Gefahr ist natürlich, dass die einzelnen Prozesse immer mehr Speicher verbrauchen. Das werde ich beobachten.

2. Apache prefork vs. Apache worker: prefork
Bei den Einstellungen muss man einfach mal ein wenig experimentieren.
Hier sind meine, but ymmw:


StartServers 3
MinSpareServers 2
MaxSpareServers 4
MaxClients 50
MaxRequestsPerChild 0

Wenn das dann erstmal läuft, rennt der Server wirklich gut. Ich erkenne einen spürbaren Vorteil gegebenüber einem mongrel-cluster

Was für die Tekkies

Mal angenommen, man betreut eine recht erfolgreiche Webseite.
Und mal weiter angenommen, man speichert die Sessions im Dateisystem.
Und – nur mal so – angenommen, man würde aus irgendwelchen Gründen jetzt auch immer, diese Sessions monatelang nicht löschen.

Wie lange dauert es dann wohl, > 2 Mio. Session-Dateien per „rm *“ aus dem Verzeichnis zu löschen?

Richtige Antwort: Erstaunlich(*) lange.

Dinge, die man nur einmal falsch macht (bevor sich Hohn und Spott über mich ergießt, ich war nicht der Verursacher, ich habe es nur entdeckt)…

(*) Erstaunlich = Eine ganze Nacht

mod_rails

Bei aller Begeisterung für RubyOnRails gab es bislang immer eine unschöne Hürde: Kaum ein Massenhoster hat RoR unterstützt. Wer eine Raisl Applikation schreiben wollte, brauchte einen eigenen Root-Server.

Dazu kommt noch, dass es verschiebene Wege gibt, die Applikation zu betreiben. FCGI, Mongrep, Thin, ebb – so 100% hat sich noch nichts durchgesetzt. Auch wenn die Kombination aus Apache und Mongrel wohl die meisten User hat.

Das Problem war, dass es nicht so etwas wie z.B. mod_php gab – also eine extrem simple Möglichkeit, um Rails Programme auszuführen.

Das hat sich (hoffentlich) nun geändert. mod_rails (http://modrails.com/index.html) verspricht genau dieses Problem zu lösen. Es ist binne Minuten installiert und schon muss man sich um nichts mehr kümmern.

mod_rails ist eine kommerzielle Entwicklung die als Freeware veröffentlicht wurde.

Ich habe es auf einigen Testservern installiert und bin echt begeistert. Schnell, einfach, stabil – was will man mehr

Java vs. Ruby On Rails

Als Java populär wurde, gab es einige mittlerweile legendäre Projekte die an die Wand gefahren wurden. So gab es z.B. den Versuch, ein Office Paket vergleichbar mit MS-Office durch ein Java-Applet zu realisieren. Dummerweise war das Applet zu groß, dass damals die Ladezeiten unerträglich waren.

Auch das Projekt Cheops ist sicherlich noch einigen in Erinnerung.

Die Argumente der Java Gegner waren in etwa:
Java ist viel zu langsam, J2EE ist viel zu komplex, Java skaliert nicht, Java/J2EE bringt keine Vorteile gegenüber etablierten Ansätzen. Jedes gescheiterte Projekt war Wasser auf die Mühlen der Gegner.
Und wenn schon Java, dann aber Schnittstellen per CORBA um keine Insellösung zu bauen.

Ich habe in der Zeit sehr viele, sehr lange Gespräche mit Kunden gehabt und immer wieder auf die Vorteile von J2EE verwiesen. Teils aus Überzeugung, teils weil es mein Job war.

Wenn ich nun die Argumente gegen RubyOnRails höre, fühle ich mich doch irgendwie ein klein wenig in diese Zeit zurückversetzt. Allerdings mit umgekehrten Rollen. Damals waren die Java-Jungs die coolen Rebellen die gegen C++ und Co. zu Felde zogen.

Heute sind die RoR Jungs die coolen Rebellen und J2EE alt und etabiert.

Meine Meinung nach einigen RoR Projekten: RoR löst die Versprechen ein, die J2EE gegeben hat.

Endlich ist es tatsächlich möglich, schnell und einfach Komponenten zu bauen, auf die andere Anwendungen zugreifen können (an dieser Stelle natürlich der Hinweis, dass es nicht nur ein Verdienst von RoR, sondern auch und gerade ein Verdienst von RESTFull WebServices – dazu schreibe ich später mal etwas). Auch kann ich jetzt Software entwickeln, während mein Kunde neben mir sitzt und auf Änderungswunsche schnell und flexibel reagieren.

RoR macht aus einem Deppen keinen hervorragenden Entwickler, aber es macht aus einem guten Entwickler einen noch produktiveren Entwickler.

Wer misst, misst Mist

Es gibt ja in der Physik das Gesetz, dass man durch die Messung das Ergebnis beeinflusst. Wenn man z.B. den Ort eines winzig kleinen Teilchens messen will, muss man es sehen. Das bedeutet, man beschießt es mit Licht (besser, mit Photonen). Und dadurch wird das Teilchen beschleunigt (Unschärferelation)

Bei mir war das so:
Meine Internet Lernkartei (http://www.web-lernbox.de) hatte „Schluckauf“. Nachdem ich ein wenig am Server umgestellt hatte, antwortete die Seite manchmal nicht mehr. Auch der Wechsel von einem Server zu einem Mongrel-Cluster half nicht (machte es nur noch schlimmer, aber das habe ich erst später verstanden). Kurzer Einschub: Mongrel ist ein Server für RubyOnRails.

Um zu verstehen, wann der Fehler auftritt, habe ich Monit installiert. Monit ist ein sehr nettes Überwachungstool. Es ist einfach zu konfigurieren und kann Server selbstständig wieder starten.

Um nun Mongrel mit Monit zu überwachen, habe ich also folgendes gemacht:
– Monit herunterladen
– entpacken,
– der klassische Unix-Dreisprung: ./configure, ./make, ./make install

Meine Konfigurations sieht ungefähr so aus:
set daemon 60
set httpd port XXXX and
use address localhost # only accept connection from localhost
allow localhost # allow localhost to connect to the server and

##### mongrel 8000 #####
check process mongrel-8000 with pidfile /[PFAD ZUR WEB-LERNBOX]/log/mongrel.8000.pid
group lernbox
start program = "/usr/local/bin/ruby /usr/local/bin/mongrel_rails start -d -e production -p 8000 -a 127.0.0.1 -P /[PFAD ZUR WEB-LERNBOX]/log/mongrel.8000.pid -c /[PFAD ZUR WEB-LERNBOX]"
stop program = "/usr/local/bin/ruby /usr/local/bin/mongrel_rails stop -P /[PFAD ZUR WEB-LERNBOX]log/mongrel.8000.pid"

if totalmem is greater than 90.0 MB for 5 cycles then restart # eating up memory?
if cpu is greater than 50% for 2 cycles then alert # send an email to admin
if cpu is greater than 80% for 3 cycles then restart # hung process?
if loadavg(5min) greater than 10 for 8 cycles then restart # bad, bad, bad
if 3 restarts within 5 cycles then timeout # something is wrong, call the sys-admin

if failed port 8000 protocol http # check for response
with timeout 10 seconds
then restart

Das ganze muss leider für alle Mongrel Instanzen wiederholt werden. Monit kann natürlich alle Dienste überwachen. Hier ist eine nette Beispielkonfiguration.

Was passiert also: Monit schaut alle 60 Sekunden nach, ob meine Lernbox noch lebt.

Tja, und was ist passiert? Die Box stürzte nicht mehr ab. Durch die Messung wurde das Problem behoben.

Mittlerweise habe ich es auch verstanden. Es ist ein Bug: Die Datenbank (MySQL) bekommt einen Timeout, Mongrel wartet aber immer noch auf die Antwort. Dadurch hängt der Server. Durch die ständige Messung habe ich den Timeout natürlich verhindert. Und durch den Mongrel-Cluster habe ich es erst richtig schlimm gemacht. Nachts lernt natürlich kaum jemand. Also war wenig los und die Server haben sich reihenweise verabschiedet…

Wie auch immer: Wer sich in den letzten Tagen geärgert hat, weil er die Lernbox nicht erreichen konnte: Geht wieder…

Projekt P. Admin Oberfläche

Die letzten Tage habe ich ja Newsletter und Benutzerverwaltung eingebaut. Was noch fehlt, ist eine Admin-Oberfläche um „mal eben“ Daten zu ändern.

Nun bin ich ja erstmal faul. Also programmiere ich das nicht selber, sondern suche mir einen schon vorhandenen Generator. Eigentlich könnte man es natürlich auch schon mit Boardmitteln machen.
script/generate scaffold Modell-Name
erzeugt schließlich die rudimentären Oberflächen, um Daten zu bearbeiten. Aber auf der einen Seite sieht das nicht sonderlich hübsch aus und darüber hinaus haben wir dann noch keine Relationen abgedeckt. Gut, dass es noch andere Generatoren gibt.

Die Kandidaten sind:
Streamlined
Active-Scaffold und
Hobo

Hobo ist allerdings zuviel des Guten, damit kann man eher komplette Anwendungen bauen. Es spielt damit in der gleichen Liga wie z.B. Goldberg.
Goldberg hatte ich tatsächlich ins Auge gefasst, da ich eh‘ auch ein wenig CMS brauche. Aber leider ist mein Design zu komplex dafür.
Wie auch immer. Gewonnen hat Active-Scaffold.

Prinzipiell nutzt man in der Railsentwicklung sehr viele Plugins und Generatoren. Da diese Generatoren normalerweise recht wenig Code erzeugen kann man das Ergebnis gut verstehen und weiterentwickeln.

Die Installation und Konfiguration von Active-Scaffold ist erschreckend simpel. Super, also weiter zum CMS.