Hat jemand von Euch mal etwas in Ruby und/oder Ruby on Rails gemacht?
Ich habe gelesen, dass "Ruby die Programmiersprache der Neuzeit für Webapplikationen ist" und stelle das nun ohne wissen direkt in Fragen.

Habe mir letztens die beiden Buecher "Programming Ruby" und "Agile Web Development with Rails" gekauft und bin recht angetan von der Sprache und dem Framework. Dabei ist es natuerlich nicht der Weisheit letzter Schluss wie ueberall gepredigt wird. Ruby fuehlt sieht auf den ersten Blick sehr Python-aehnlich aus, wirkt auf jeden Fall wie eine Sprache mit Konzept, im Gegensatz zu PHP. Das Framework ist nett und erlaubt es in kurzer Zeit ein Prototyp der Application zu erstellen. Inkrementelles Design/Implementation (Agile Development) scheint den Autoren sehr wichtig. Ich habe allerdings kein "killer feature" gefunden das mich veranlasst haette, sofort auf Ruby/Rails umzusteigen. Fuer PHP oder Python gibt es mittlerweile aehnliche Frameworks, fuer PHP ist die Kombination Creole/Propel und Symfony Framework (http://www.symfony-project.com/, ein Mojavi Ableger) sehr Rails aehnlich.

Ich habe allerdings nur kurz mit Rail rumgespielt und noch kein Projekt damit entwickelt. Wenn ich mich von PHP wegbewege wird es wahrscheinlich eher Python werden, fuer Ruby gibt es noch nicht genug Libraries die einem das Leben erleichtern. Aber das koennte in ein paar Monaten schon anders aussehen.

Ich fand http://media.rubyonrails.org/video/rails_take2_with_sound.mov schon sehr eindrucksvoll. Mal sehen ob ich demnächst mal irgendwas mit rails machen, hab nur gerade keine konkrete Anwendung dafür.

Bei dem aktuellen Ruby und Rails-Hype sollte man gerade als Informatiker mehrere Dinge unterscheiden können. (Und ich halte mich jetzt mal kurz…)

1) Ruby die Sprache
IMHO zwischen Perl und Python angesiedelt. Nicht ganz so schmutzig wie Perl, aber auch nicht ganz so sauber wie Python. Je nach persönlicher Präferenz also "der goldene Mittelweg" oder "nichts ganzes und nichts halbes".

2) Ruby die Standardbibliothek
Nett. Kategorie in Etwa Python und Java, etwas weniger umfangreich allerdings.

3) Ruby die Implementation
Dank Hype recht weit verbreitet. D.h. man kann Ruby durchaus häufiger mal einsetzen. Perl und PHP haben da ja meistens das Monopol, Python und Ruby brechen da ein. Andere Sprachen sind hier klar im Nachteil.

4) Ruby on Rails das Framework
Wenn man es vom Rest der Sprache abkoppelt muss ich sagen, dass ich nicht sonderlich beeindruckt bin. Keine grandiose Innovation (wie z.B. continuations), aber es ist ziemlich vollständig. Bisher habe ich nur von kleinen Beispielen gehört, die total toll sind - aber es ist bei solchen Frameworks ja fast immer so, dass sie die leichten "Probleme" noch viel leichter machen, aber eben nicht wirklich auf große Probleme skalieren. Wäre mal interessant, wie sich RoR bei großen Webanwendungen - CMS etc. - im Vergleich zu z.B. Zope hält.

Zudem gibt es ja für verschiedene Sprachen Bemühungen, Rails-artige Frameworks zu erstellen. Auch hier ist abzuwarten, wieviel von Rails eigentlich ein genuines Feature von Ruby ist, und was nicht.

5) Das Zusammenspiel dieser Teile
Das ist natürlich ein wichtiger Punkt, wenn man auf Buzzwords wie "deployability" steht. Häufig vorhanden, gutes Framework für kleine bis mittlere Anwendungen, halbwegs wartbare Sprache - das sind schon gute Argumente. Die Frage ist: Wieviel davon ist noch hype, wieviel ist wirklich Erfahrung.

Wer's nich ausprobiert, wird's nich rausfinden. ;-)

(Anarch, bekennender Ruby&Perl-Hasser)

Für einen netten Vergleich zwischen J2EE und diversen Python basierten Web-Frameworks sowie Ruby on Rails kann man sich mal:

http://oodt.jpl.nasa.gov/better-web-app.mov

ansehen. Meiner Einschätzung nach ist Ruby on Rails nur ein momentaner Hype der im Wesentlichen durch ein paar gute Einführungsvideos ausgelöst wurde…

Hanno
—
Python/Zope/Plone Entwickler

Für einen netten Vergleich zwischen J2EE und diversen Python basierten Web-Frameworks sowie Ruby on Rails kann man sich mal:

http://oodt.jpl.nasa.gov/better-web-app.mov

ansehen.

Lustiges Video - Danke für den Link! :-)

Aber wieso glaubt der Sprecher, dass das nicht-starten des eigenen Editors und stattdessen eine Textarea zu benutzen in irgend einer Form was gutes ist? Ich meine, ich rege mich schon jedes mal auf, wenn ich so eine scheiß Textarea für normalen Text benutzen muss, und der schreibt da drin code? *brrr*

(Ich will ein aktuelles MozEX :-/)

Für einen netten Vergleich zwischen J2EE und diversen Python basierten Web-Frameworks sowie Ruby on Rails kann man sich mal:

http://oodt.jpl.nasa.gov/better-web-app.mov

ansehen.

Interessanter Vergleich. Aber auch wenn sich Mr. Kelly in alle Framework, respektive (Skript-)Sprachen eingearbeitet hat, um diesen Vergleich zu ermöglichen, werde ich das Gefühl nicht los, dass seine Fixierung auf "rapid turnarouts" andere Aspekte außer Betracht lässt. Mit Blick auf die aktuellen Stellenauschreibungen kann ich nur feststellen, dass fast ausschließlich nur Entwickler mit J2EE/Hibernate Kenntnissen gesucht werden. Angebote, die Zope- oder Railskenntnisse voraussetzen, sind mir dagegen kaum über'n Weg gelaufen.

Da stellt sich mir doch glatt die Frage nach dem Warum. Mir sind die Tücken der Java-basierten Webanwendungslösungen leidvoll bekannt und ich habe mir deswegen schon das eine oder andere mal gewünscht, die Veranwortlichen mitsamt ihren Bohnen in der Hölle rösten zu sehen, aber anscheinend scheint an dieser Java-Kiste ja was dran zu sein, mit dem Zope/Rails nicht mithalten können.

…aber anscheinend scheint an dieser Java-Kiste ja was dran zu sein, mit dem Zope/Rails nicht mithalten können.

Ja, das war dann wohl dieser gut gepushte Java-Hype…

Für einen netten Vergleich zwischen J2EE und diversen Python basierten Web-Frameworks sowie Ruby on Rails kann man sich mal:
http://oodt.jpl.nasa.gov/better-web-app.mov
ansehen.

Lustiges Video - Danke für den Link! :-)

Aber wieso glaubt der Sprecher, dass das nicht-starten des eigenen Editors und stattdessen eine Textarea zu benutzen in irgend einer Form was gutes ist? Ich meine, ich rege mich schon jedes mal auf, wenn ich so eine scheiß Textarea für normalen Text benutzen muss, und der schreibt da drin code? *brrr*

(Ich will ein aktuelles MozEX :-/)

Die Möglichkeit in Zope direkt Through-the-web irgend etwas zu programmieren, ist deutlich umstritten. Alle 'echten Programmierer' fangen meist gleich mit einem ordentlichen Produkt auf dem Dateisystem an, aber für Leute, die nur mal schnell die Inhalte eines Formulars wegmailen möchten, ist dieses eine brauchbare Möglichkeit.

Interessanter Vergleich. Aber auch wenn sich Mr. Kelly in alle Framework, respektive (Skript-)Sprachen eingearbeitet hat, um diesen Vergleich zu ermöglichen, werde ich das Gefühl nicht los, dass seine Fixierung auf "rapid turnarouts" andere Aspekte außer Betracht lässt. Mit Blick auf die aktuellen Stellenauschreibungen kann ich nur feststellen, dass fast ausschließlich nur Entwickler mit J2EE/Hibernate Kenntnissen gesucht werden. Angebote, die Zope- oder Railskenntnisse voraussetzen, sind mir dagegen kaum über'n Weg gelaufen.

Die Fixierung auf Rapid Turnaround ist schon sehr gross, doch beurteilt er im zweiten Teil durchaus auch nach anderen Kriterien. Eine der für mich komplett fehlenden Kategorien ist die Verfügbarkeit von bereits existierenden Modulen / Plugins für bestimmte Standardaufgaben dieser Frameworks und die Integrationsfähigkeit in andere Systeme. Wenn ich ein Forum, einen Webshop oder ein CMS brauche, möchte ich dieses nicht komplett neuentwickeln und auch nicht auf eine Programmiersprache oder ein Framework festgelegt sein.

Da stellt sich mir doch glatt die Frage nach dem Warum. Mir sind die Tücken der Java-basierten Webanwendungslösungen leidvoll bekannt und ich habe mir deswegen schon das eine oder andere mal gewünscht, die Veranwortlichen mitsamt ihren Bohnen in der Hölle rösten zu sehen, aber anscheinend scheint an dieser Java-Kiste ja was dran zu sein, mit dem Zope/Rails nicht mithalten können.

Rails ist schlichtweg zu neu. Es gibt zwar einen gewissen Hype um das Ganze, aber dieser beschränkt sich noch auf Open-Source interessierte Entwickler. Leider werden die Platform-Entscheidungen aber nicht unbedingt von den Entwicklern sondern vom Management getroffen und wenn man da ein neues Framework vorschlägt, von dem das Management noch nie gehört hat, hat man schlechte Karten.

Für Zope gilt ein ähnliches Argument. Es ist zwar alles andere als neu, doch schlichtweg unbekannt. Hinzu kommt, dass es mit Python auf einer wiederrum eher unbekannten Sprache beruht. Wenn ich meinen Chef nach Programmiersprachen frage (und der hat immerhin einen Doktor in Informatik) so kennt er C - für schnelle Applikationen, Java - das muss man jetzt wohl machen, ist außerdem platformunabhängig und PHP - wenn's denn kleine Webapplikationen sein sollen.

Sicherlich ist das nicht repräsentativ, doch habe ich den Eindruck das die wenigsten Manager viele Sprachen darüber hinaus kennen.

Weiterhin muss sich die Umstellung auf ein neues Framework auch wirtschaftlich rechnen. Alle meine Programmierer müssen eine neue Sprache, ein neues Framework und damit eventuell auch noch eine neue Methodik lernen; der Benefit muss diese Kosten erstmal aufwiegen.

Ich glaube eher diese Art von Trägheitsargumenten steckt hinter der Beliebtheit von Java / J2EE als tatsächlich qualitative Argumente. Sobald sich einmal das 'das benutzten doch auch alle anderen' Argument eingeschlichen hat, ist es schwer dagegen etwas zu machen.

Der Vergleich war sehr eindrucksvoll. Interessant ist für mich aber auch, wie der Vergleich bei einer mittleren bis großen Codebase mit mehreren wechselnden Entwicklern ausfällt. Ich bin mir sicher, dass Java da punkten kann.

Bei seinen 2 Headaches hab ich mich schlappgelacht, das kenne ich nur zu gut..

Also Video war wirklich sehr interessant. Das ganze hatte aber schon was von J2EE und XML bashing. Seine Beispiele waren so gewählt, dass die anderen Frameworks da sicherlich besser als J2EE geeignet waren (sehr unkomplex). Außerdem hat er J2EE Programmierung ohne aufgesetzte Frameworks (Struts, JSF …) gegen Frameworks angesetzt, die ganz stark auf dynamische Webseiten Erstellung ausgerichtet waren. Außerdem benutzt er bei Zope eine "Entwicklungsumgebung", bei anderen Sprachen wieder nicht. Ich würde gerade bei J2EE sagen, dass es von den Configdateien her stark auf eine Entwicklungsumgebung ausgerichtet ist, und man eben nicht alles im Emacs per Hand schreibt. XML hat seine stärken halt nicht unbedingt bei der handbearbeitbarkeit (lesbarkeit finde ich dafür sogar ganz schön) sondern vor allem im automatischen Erstellen/Parsen der Dateien. Außerdem denke ich, dass man das 2. Beispiel auch deutlich unter der angegebenen Zeit entwickeln kann (mit J2EE).

Ich bin natürlich bei J2EE Entwicklung auch schon auf starke Kopfschmerzen gestoßen. Wie hier auch schon andere schrieben denke ich, dass J2EE seine Stärken ausspielt wenn es komplexer (mehrere Personen) wird, man wirkliche Tool Unterstützung zur Rate zieht und nicht nur die UI sondern tatsächlich das Programmieren von Funktionalität im Fordergrund steht. Wenn man nur Daten in eine Datenbank reinstopfen will bzw. sie anzeigen will, sind schmalere Lösungen natürlich definitiv vorzuziehen.

Außerdem benutzt er bei Zope eine "Entwicklungsumgebung", bei anderen Sprachen wieder nicht.

Aber nur das mitgelieferte, sonst hätte man sicherlich in allen noch wesentlich mehr rausholen können.

Außerdem denke ich, dass man das 2. Beispiel auch deutlich unter der angegebenen Zeit entwickeln kann (mit J2EE).

Ja eine interessante Frage wäre, wie gut er die einzelnen Frameworks jetzt wirklich kannte.

Wie hier auch schon andere schrieben denke ich, dass J2EE seine Stärken ausspielt wenn es komplexer (mehrere Personen) wird, man wirkliche Tool Unterstützung zur Rate zieht und nicht nur die UI sondern tatsächlich das Programmieren von Funktionalität im Fordergrund steht. Wenn man nur Daten in eine Datenbank reinstopfen will bzw. sie anzeigen will, sind schmalere Lösungen natürlich definitiv vorzuziehen.

Das wird ja auch durchaus dort schon gesagt. Die gesamte Funktionalität ist dort ja sicherlich auch nicht ohne Grund in J2EE geschrieben, Fokus dieser Geschichte war es ja einen Thin-Client obendrauf zu setzen.

Außerdem denke ich, dass man das 2. Beispiel auch deutlich unter der angegebenen Zeit entwickeln kann (mit J2EE).

Ja eine interessante Frage wäre, wie gut er die einzelnen Frameworks jetzt wirklich kannte.

Er sagt, dass seine aktuelle Firma für jeden Scheiß J2EE benutzt. Ziemlich am Anfang. Ich vermute mal daher, dass er nicht ganz unerfahren damit ist.

Ich nehme an, dass dieses Video entstanden ist, um seine Firma von J2EE wegzubekommen. Daher wird er sich wohl etwas mit den anderen Frameworks beschäftigt haben. Er behauptet von sich selbst ein Rails-Fan zu sein. Also wird er RoR davon wohl am besten kennen.

Mir fehlt momentan die Zeit, auf die Punkte einzeln einzugehen, aaaaber für alle die ein wenig zu dem Thema hören und diskutieren wollen: [shameless_plug]Am Dienstag gibt es ab 17:15 Uhr in dem SWT-Seminar im Raum D-220 einen Vortrag zu Ruby + RubyOnRails, an welchem yours truly auch beteiligt ist.[/shameless_plug]

Macht hier eigentlich jemand aktiv etwas mit ruby on rails? Ich bin noch Neuling und der mosert immer darüber herum, dass er keine Datei unter /tmp/mysql.sock findet. Ist ja auch richtig, da die unter /opt/lampp/var/mysql/ liegt. Drum habe ich ihn die database mal socket: /opt/lampp/var/mysql/mysql.sock eingetragen. MySQL und den Railswebserver habe ich beide neugestartet und er guckt immer noch unter /tmp/. Google hat mir bisher nichts anderes als den Tipp mit socket gezeigt.

Ah, ein Symlink macht ihn glücklich.

Ich hab bisher nur kleine Sachen in Ruby gemacht… RoR+Ajax find ich aber superspannend, werd's mir mal reintun, wenn ich einen Anwendungsfall habe.