Re: [Rubyonrails-ug] State of the RoR-Nation?!
Willkommen im 21. Jahrhundert! Rails ist ok, aber es ist eben ein Framework, das man sich vor zehn Jahren für die Web-Entwicklung gewünscht hätte. Das ist jetzt vielleicht etwas unorthodox, aber jedes Framework ist ein aufgeblähtes Monster, eine Behelfslösung, ein Übergangslösung, für etwas, das eigentlich eine spezialisierte Sprache mit ihren core libraries erfüllen sollte. Das gilt für so etwas wie JQuery oder Moo im JS-Bereich oder im Ruby-Bereich für Rack mit Rails oder Sinatra. Daß Ruby im Moment so beliebt ist, und daß Javascript auf der Client-Seite so beliebt ist, das hängt doch wohl hauptsächlich damit zusammen, daß die Web-Frameworks so ausgefeilt sind. Und wenn Frameworks so fundamental für den Erfolg einer Sprache verantwortlich sind, dann ist es in meinen Augen klar, daß man sich mal über die Kernfunktionaliäten der entsprechenden Sprachen Gedanken machen sollte. Als Node und Go aufkamen, da waren die ersten Fragen in den entsprechenden Foren, ob es Web-Frameworks dazu gibt. Warum dann diese Sprachen nicht gleich als mit, zumindest einigen grundlegendenden, aber eben higher-level, Web-Funktionalitäten bereitstellen? Warten wir mal noch zehn Jahre ab. Viele Grüße Michael Kastner Am 22.03.2012 um 07:34 schrieb Stefan Frank: Liebe RUGler, es ist still geworden auf dieser Liste und ich frage mich momentan, woran das liegt. Vielleicht gibt es ja noch Leben da draußen und ich fände es spannend von euch zu hören, wie Ihr die Lage der Ruby/RoR-Nation einschätzt: Ich habe mal ein paar Punkte/Hypothesen zusammengefasst, über die ich in der letzten Zeit öfter gestolpert bin: • alle Rails-Probleme sind gelöst. Oder alle sind zu anderen Listen abgewandert entweder zu den englisch-sprachigen Listen oder zu den Listen für Spezial-Themen wie deployment/cloud, mongoDB/Mongoid usw.? Oder viele haben mittlerweile Rails wieder aufgegeben?! • die Verbreitung von Ruby/RoR beschränkt sich weitgehend auf die Startup- und Webszene: Es gibt sehr viele Social-Something-Anwendungen, CMS-Lösungen, Backends für Mobile-Apps aber ich habe noch nicht viel davon gehört, dass eine Versicherung jetzt Ihre Fallbearbeitung auf Rails umgestellt hätte oder ein Logistik-Konzern seine Lagerverwaltung mit Rails macht. Natürlich ist Rails nicht für alles geeignet, aber ich habe genügend Projekte in diesen altmodischen Brick-and-Mortar-Unternehmen gesehen, bei denen reflexartig Java/JEE eingesetzt wird und nicht mal eine Millisekunde über irgend etwas anderes nachgedacht wird - von Rails bei BMW oder Allianz oder Siemens habe ich noch nix gehört. Man kann diese Projekte vielleicht langweiliger als Social-Somethings finden, aber sie sorgen für einen erheblichen Teil des IT-Job-Markts. Und hier findet Ruby/RoR einfach nicht statt: Oder täuscht mich mein Eindruck da?! Oder ist das auch gut so und Rails gehört da auch gar nicht hin und wenn Versicherung dann bitte COBOL oder wenigstens Java?! • wohin entwickelt sich Rails? In letzter Zeit stolpere ich immer mal wieder über Rants mit so schönen Überschriften wie The Sun is setting on Rails style MVC Frameworks (http://caines.ca/blog/programming/the-sun-is-setting-on-rails-style-mvc-frameworks/), dann gibt es ein paar, die sich darüber beschweren, dass der Merb-Merger alles nur langsamer und unübersichtlicher gemacht hat, dann gibt es LightRails (https://github.com/lightness/lightrail/), das Rails wieder verschlanken will, oder die Leute, die sagen, dass man sowieso nur noch APIs braucht und deswegen am besten gleich alles mit Sinatra machen sollte. Oder gleich mit node, weil ist schneller und in 2 Jahren reden wir sowieso alle nur noch JavaScript (http://gilesbowkett.blogspot.de/2012/02/rails-went-off-rails-why-im-rebuilding.html oder http://blog.nodejitsu.com/scaling-isomorphic-javascript-code). Ist da was dran? Taugt Rails noch für die schöne neue App/HTML5/1-Page-App-Welt? Oder ist es mittlerweile Bloat-ware, weil es versucht alles für alle zu sein? • Ich selber ertappe mich dabei, dass ich Features, die ich zuerst noch zweifelhaft fand, plötzlich nicht mehr missen möchte. Die Asset-Pipeline ist so ein Fall: Ich fand das dubios und hatte das Gefühl das gehört eigentlich nicht da reines gibt schon tausend Alternativen dazu, aber mittlerweile sind fast alle größeren JavaScript-Libraries in gems eingepackt (z.B. https://github.com/anjlab/bootstrap-rails), natürlich ist coffeescript netter als rohes JS, precompiler für JavaScripts-Templates (z.B. für handlebars) gibt's als Bonus und rails funktioniert so als Rundum-Sorglos-build-System für JavaScript-Apps. Es ist praktisch, aber ist es auch der richtige Weg? Oder sieht für mich die ganze Welt wie ein Nagel aus weil ich nur einen Hammer habe? Ist das nur ein temporärer Hack, der den Umstand kaschiert, dass es für JavaScript (noch) kein Modul-Konzept gibt und ist node.js nicht auf lange Sicht
Re: [Rubyonrails-ug] State of the RoR-Nation?!
On Monday 26 March 2012, rubyonrails...@galt.de wrote: Willkommen im 21. Jahrhundert! Rails ist ok, aber es ist eben ein Framework, das man sich vor zehn Jahren für die Web-Entwicklung gewünscht hätte. Mit dieser Aussage provozierst du die Frage, was man sich denn heute (anderes) für die Web-Entwicklung wünscht. Weiter gedacht: Was müsste Rails leisten, um diese Wünsche zu erfüllen? Das ist jetzt vielleicht etwas unorthodox, aber jedes Framework ist ein aufgeblähtes Monster, eine Behelfslösung, ein Übergangslösung, für etwas, das eigentlich eine spezialisierte Sprache mit ihren core libraries erfüllen sollte. Das gilt für so etwas wie JQuery oder Moo im JS-Bereich oder im Ruby-Bereich für Rack mit Rails oder Sinatra. Daß Ruby im Moment so beliebt ist, und daß Javascript auf der Client-Seite so beliebt ist, das hängt doch wohl hauptsächlich damit zusammen, daß die Web-Frameworks so ausgefeilt sind. Und wenn Frameworks so fundamental für den Erfolg einer Sprache verantwortlich sind, dann ist es in meinen Augen klar, daß man sich mal über die Kernfunktionaliäten der entsprechenden Sprachen Gedanken machen sollte. Exkurs: Framework bezeichnet ein sehr allgemeines Konstrukt und sagt zunächst einmal nichts über die Größe oder Komplexität aus. Gegeben einen technischen Gegenstandsbereich, dann zeichnet sich ein Framework gegenüber einem Toolkit vor allem dadurch aus, dass es den Rahmen für eine Anwendung (eine Library, ein Modul, ein Plugin) vorgibt, in dem die Lücken gefüllt werden. Meist werden dabei vorgegebene Interfaces mit der spezifischen Funktionalität implementiert. Das etwas ein Framework ist, sagt dabei nichts über die Größe aus. Dir geht es aber um Frameworks für die Web-Entwicklung, Server- wie auch Client-seitig. Wenn ich dich richtig verstehe, behauptest du, dass Rails inzwischen zu groß und unübersichtlich geworden ist und beizeiten durch eine spezialisierte Sprache abgelöst wird, oder werden sollte. Ich finde diese Behauptung in zweierlei Hinsicht fragwürdig. Du unterstellst erstens, Rails sei ein Monster geworden. Zweitens behauptest du, dies wäre durch eine Integration der gebotenen Funktionalität in eine Programmiersprache vermeidbar. Ich stimme zu, dass Rails mit der Zeit immer umfangreicher geworden ist. Wenn jemand heute Rails komplett verstehen will, dann ist das zweifellos mehr Arbeit als es vor fünf Jahren gewesen wäre. Allerdings ist das kein Selbstzweck, sondern folgt den gestiegenen Anforderungen der Leute, die mit Rails arbeiten. Man sollte den Rails-Core-Entwicklern durchaus zugute halten, dass die Modularität von Rails mit der Zeit sogar besser geworden ist. Es ist heute möglich, Rails-Anwendungen ganz ohne Persistenzschicht zu schreiben, indem man nur ActiveModel für die Model- Schicht verwendet und ActiveRecord einfach ignoriert. Man muss nicht alle Teilframeworks im Detail kennen, sondern kann sich auf die konzentrieren, die man tatsächlich benötigt. Aber die meisten Entwickler wollen ja Persistenz in ihren Webanwendungen nutzen. Das hat einen Preis an Wissen über die verwendeten Mittel, ob es nun ActiveRecord ist oder Bestandteil einer spezialisierten Programmiersprache. Es geht einfacher, wenn man sich auf Anwendungen beschränkt, die einer bestimmten Schablone entsprechen. Auch dann braucht man keine neue Programmiersprache, sondern dank der Ausdrucksfähigkeit von Ruby könnte man die gewünschte Funktionalität in ein geeignetes Framework giessen. Und damit bin ich wieder am Anfang angekommen: Du müsstest ausreichend genau festlegen, auf welche Weise du Webanwendungen heute entwickeln möchtest. Wenn dir das gelingt, dann könnte man dafür auch ein Framework bauen. Michael -- Michael Schuerig mailto:mich...@schuerig.de http://www.schuerig.de/michael/ ___ rubyonrails-ug mailing list rubyonrails-ug@headflash.com http://mailman.headflash.com/listinfo/rubyonrails-ug
Re: [Rubyonrails-ug] State of the RoR-Nation?!
Du müsstest ausreichend genau festlegen, auf welche Weise du Webanwendungen heute entwickeln möchtest. Damit habe ich mich noch nicht ausreichend beschäftigt. Oder andersrum: ich weiß, daß mich Rails irgendwann so sehr nerven wird, daß ich vielleicht wirklich mal mal einen Notizzettel mit meinen Anforderungen schreibe. Du hast natürlich recht, lediglich zu kritisieren ist etwas uncool. Wenn dir das gelingt, dann könnte man dafür auch ein Framework bauen. Noch ein Framework? Das war's eigentlich nicht ;-) Ich finde diese Behauptung in zweierlei Hinsicht fragwürdig. Du unterstellst erstens, Rails sei ein Monster geworden. Zweitens behauptest du, dies wäre durch eine Integration der gebotenen Funktionalität in eine Programmiersprache vermeidbar. Ich hatte das vorhin mal so ins Blaue reingeschrieben. Die Aufblähung wäre halt nur vermeidbar, wenn andere Funktionalitäten weggelassen würden. Wenn HTML5 es fertig bringt, Semantik in die Präsentation zu bekommen, dann sollte es doch auch möglich sein, daß sich ähnliches auch auf der Datenseite und im Flow niederschlägt. HTTP bringt doch z.B. Beispiel eine Definition von bestimmten Verhaltensweisen oder Verben mit. Nur mußte die Reaktion auf diese Verben, sofern sie implenentiert waren, immer programmiert werden. _Das_ wäre für mich so ein Fall, der definitiv in einer speziellen Web-Programmiersprache verdrahtet sein müßte. Gut, wenn's der Browser nicht unterstützt, dann ist's auch mit den HTTP-Methoden nicht weit her. Aber war ja nur ein Beispiel. Waren nur meine 5 Cent. Am 26.03.2012 um 14:36 schrieb Michael Schuerig: On Monday 26 March 2012, rubyonrails...@galt.de wrote: Willkommen im 21. Jahrhundert! Rails ist ok, aber es ist eben ein Framework, das man sich vor zehn Jahren für die Web-Entwicklung gewünscht hätte. Mit dieser Aussage provozierst du die Frage, was man sich denn heute (anderes) für die Web-Entwicklung wünscht. Weiter gedacht: Was müsste Rails leisten, um diese Wünsche zu erfüllen? Das ist jetzt vielleicht etwas unorthodox, aber jedes Framework ist ein aufgeblähtes Monster, eine Behelfslösung, ein Übergangslösung, für etwas, das eigentlich eine spezialisierte Sprache mit ihren core libraries erfüllen sollte. Das gilt für so etwas wie JQuery oder Moo im JS-Bereich oder im Ruby-Bereich für Rack mit Rails oder Sinatra. Daß Ruby im Moment so beliebt ist, und daß Javascript auf der Client-Seite so beliebt ist, das hängt doch wohl hauptsächlich damit zusammen, daß die Web-Frameworks so ausgefeilt sind. Und wenn Frameworks so fundamental für den Erfolg einer Sprache verantwortlich sind, dann ist es in meinen Augen klar, daß man sich mal über die Kernfunktionaliäten der entsprechenden Sprachen Gedanken machen sollte. Exkurs: Framework bezeichnet ein sehr allgemeines Konstrukt und sagt zunächst einmal nichts über die Größe oder Komplexität aus. Gegeben einen technischen Gegenstandsbereich, dann zeichnet sich ein Framework gegenüber einem Toolkit vor allem dadurch aus, dass es den Rahmen für eine Anwendung (eine Library, ein Modul, ein Plugin) vorgibt, in dem die Lücken gefüllt werden. Meist werden dabei vorgegebene Interfaces mit der spezifischen Funktionalität implementiert. Das etwas ein Framework ist, sagt dabei nichts über die Größe aus. Dir geht es aber um Frameworks für die Web-Entwicklung, Server- wie auch Client-seitig. Wenn ich dich richtig verstehe, behauptest du, dass Rails inzwischen zu groß und unübersichtlich geworden ist und beizeiten durch eine spezialisierte Sprache abgelöst wird, oder werden sollte. Ich finde diese Behauptung in zweierlei Hinsicht fragwürdig. Du unterstellst erstens, Rails sei ein Monster geworden. Zweitens behauptest du, dies wäre durch eine Integration der gebotenen Funktionalität in eine Programmiersprache vermeidbar. Ich stimme zu, dass Rails mit der Zeit immer umfangreicher geworden ist. Wenn jemand heute Rails komplett verstehen will, dann ist das zweifellos mehr Arbeit als es vor fünf Jahren gewesen wäre. Allerdings ist das kein Selbstzweck, sondern folgt den gestiegenen Anforderungen der Leute, die mit Rails arbeiten. Man sollte den Rails-Core-Entwicklern durchaus zugute halten, dass die Modularität von Rails mit der Zeit sogar besser geworden ist. Es ist heute möglich, Rails-Anwendungen ganz ohne Persistenzschicht zu schreiben, indem man nur ActiveModel für die Model- Schicht verwendet und ActiveRecord einfach ignoriert. Man muss nicht alle Teilframeworks im Detail kennen, sondern kann sich auf die konzentrieren, die man tatsächlich benötigt. Aber die meisten Entwickler wollen ja Persistenz in ihren Webanwendungen nutzen. Das hat einen Preis an Wissen über die verwendeten Mittel, ob es nun ActiveRecord ist oder Bestandteil einer spezialisierten Programmiersprache. Es geht einfacher, wenn man sich auf Anwendungen beschränkt, die einer bestimmten Schablone entsprechen. Auch dann
Re: [Rubyonrails-ug] State of the RoR-Nation?!
Und damit bin ich wieder am Anfang angekommen: Du msstest ausreichend genau festlegen, auf welche Weise du Webanwendungen heute entwickeln mchtest. Wenn dir das gelingt, dann knnte man dafr auch ein Framework bauen. Und wenn ich damit auch noch mal wieder zum Ausgangspunkt der Diskussion zurck kommen darf: Mehr als dieses diffuse Bauchgrummeln, das an Rails "etwas" fehlt oder "etwas" zu viel ist, ist es ja momentan auch noch nicht - wobei man den Finger noch nicht wirklich genau auf dieses "etwas" legen kann. Ein vages Grummeln habe ich (und wenn ich das zaghafte Rauschen im Blog-Wald richtig interpretiere, auch noch andere...) an den Stellen, an denen sich die Webarchitekturen ber den Punkt hinaus weiter entwickelt haben, an dem Rails damals entstanden ist. Nur als Beispiel: Das hier gab es damals noch nicht als Rails und seine Clone entstanden sind, oder zumindest lngst nicht so ausgeprgt: A _javascript_-MVC-Frameworks(wie backbone), die ber json-Schnittstellen mit der Anwendung reden. Was dann zu Doppelungen und teilweise zu komischen MVC-MVC-Gebilden fhrt. B keine Anwendung mehr ohne API! Was quasi A auf die Spitze treibt aber zumindest sind dabei die Doppelungen nicht mehr unser Problem. C json-stores, bei denen zusammen mit A oder B Rails als ein Kreuzung aus Durchreiche und einer Art "DDL" funktioniert (z.B. mit mongoids field :name usw.) Es haben sich mittlerweile verschiedenste Anstze entwickelt solche Sachen __innerhalb__ und/oder __auerhalb__ von Rails zu entwickeln, von daher gibt es da schon viele verschiedene Antworten auf diese Fragen: Da denke ich, kann man zumindest mal drber nachdenken, welche Rolle Rails in diesen Architekturen einnimmt oder noch futuristischer: einnehmen sollte. Lieber Vielstimmigkeit oder lieber ein Framework, sie alle zu binden? Mehr als diese zugegeben diffusen Fragen habe ich momentan auch noch nicht - ich seh' auch nicht, dass es da drauen schon Antworten darauf gbe und vielleicht ist es auch einfach gut so, wie es ist: Rails im Wesentlichen als Integrations-Hub und alle anderen Sachen sind nicht und sollten nicht Teil des Frameworks sein... rubyonrails...@galt.de 26. Mrz 2012 12:25 Willkommen im 21. Jahrhundert!Rails ist ok, aber es ist eben ein Framework, das man sich vor zehn Jahren fr die Web-Entwicklung gewnscht htte.Das ist jetzt vielleicht etwas unorthodox, aber jedes Framework ist ein aufgeblhtes Monster, eine Behelfslsung, ein bergangslsung, fr etwas, das eigentlich eine spezialisierte Sprache mit ihren core libraries erfllen sollte. Das gilt fr so etwas wie JQuery oder Moo im JS-Bereich oder im Ruby-Bereich fr Rack mit Rails oder Sinatra.Da Ruby im Moment so beliebt ist, und da _javascript_ auf der Client-Seite so beliebt ist, das hngt doch wohl hauptschlich damit zusammen, da die Web-Frameworks so ausgefeilt sind. Und wenn Frameworks so fundamental fr den Erfolg einer Sprache verantwortlich sind, dann ist es in meinen Augen klar, da man sich mal ber die Kernfunktionaliten der entsprechenden Sprachen Gedanken machen sollte.Als Node und Go aufkamen, da waren die ersten Fragen in den entsprechenden Foren, ob es Web-Frameworks dazu gibt. Warum dann diese Sprachen nicht gleich als mit, zumindest einigen grundlegendenden, aber eben higher-level, Web-Funktionalitten bereitstellen?Warten wir mal noch zehn Jahre ab.Viele GreMichael Kastner___rubyonrails-ug mailing listrubyonrails-ug@headflash.comhttp://mailman.headflash.com/listinfo/rubyonrails-ug Stefan Frank 22. Mrz 2012 07:34 Liebe RUGler, es ist still geworden auf dieser Liste und ich frage mich momentan, woran das liegt. Vielleicht gibt es ja noch Leben da drauen und ich fnde es spannend von euch zu hren, wie Ihr die Lage der Ruby/RoR-Nation einschtzt: Ich habe mal ein paar Punkte/Hypothesen zusammengefasst, ber die ich in der letzten Zeit fter gestolpert bin: alle Rails-Probleme sind gelst. Oder alle sind zu anderen Listen abgewandert entweder zu den englisch-sprachigen Listen oder zu den Listen fr Spezial-Themen wie deployment/cloud, mongoDB/Mongoid usw.? Oder viele haben mittlerweile Rails wieder aufgegeben?! die Verbreitung von Ruby/RoR beschrnkt sich weitgehend auf die Startup- und Webszene: Es gibt sehr viele Social-Something-Anwendungen, CMS-Lsungen, Backends fr Mobile-Apps aber ich habe noch nicht viel davon gehrt, dass eine Versicherung jetzt Ihre Fallbearbeitung auf Rails umgestellt htte oder ein Logistik-Konzern seine Lagerverwaltung mit Rails macht. Natrlich ist Rails nicht fr alles geeignet, aber ich habe gengend Projekte in diesen altmodischen Brick-and-Mortar-Unternehmen gesehen, bei denen reflexartig Java/JEE eingesetzt wird und nicht mal eine Millisekunde ber irgend etwas anderes nachgedacht wird - von Rails bei BMW oder Allianz oder Siemens habe ich noch nix gehrt. Man kann diese Projekte vielleicht langweiliger
Re: [Rubyonrails-ug] State of the RoR-Nation?!
hi, Am 22.03.2012 11:16, schrieb Hendrik Mans: bis ein schönes, neues 80%-Framework die Leute für sich gewinnen wird stimmt - für Neuanfänge ist das sicher korrekt aber wenn du, wie Carsten das so korrekt beschrieb zu den Etablierten zu gehörst, deren Entwickler, die Rails verstanden haben, unter anderem deswegen schwer zu hören sind, weil sie unter Bergen von Aufträgen verbuddelt sind..., dann kannst du nicht alle Jahre wieder auf einen neuen Zug aufspringen. So entstehen keine großen Systeme wer Information erhalten will, muss die Grenzgeschwindigkeit bei Veränderung respektieren (http://www.mpg.de/495749/pressRelease200403081) und diese hängt wohl an der Komplexität des Systems, wenn ich den MPG-Artikel korrekt interpretiere die neuen Züge sind sicher notwendig, um die Entwicklung auf den Gleisen voranzutreiben, doch es gibt eben auch andere Entwicklungslinien. Informationsverarbeitung ist korreliertes Arbeiten, das lässt sich niemals durch wahlloses Zusammensuchen von Best Practices erreichen. Soll eine solche Ansammlung von Best Practices funktionieren, muss die Kategorisierungsenergie eben in die Auswahl und Verlinkung der Apps gesteckt werden, umgehen lässt sie sich nicht das, was Stefan in meiner Interpretation anzudeuten scheint, hat auch mich getroffen. Denn wenn du unter Bergen von Aufträgen verbuddelt bist und auf eigenen Lösungen aufbaust, die schon lange vor dem netten Schlagwort DRY als wiederverwendbare Blackboxes konzipiert waren, dann bringt es dich schon gewaltig aus dem Tritt, wenn du stellenweise bis zum Urknall zurück in den Sourcen deiner Middleware musst. Und ja, das ist, wie Michael so treffend meinte (sondern gehe gleich zur Quelle, also dem Sourcecode) auch für mich der einzige stets hilfreiche Weg und das seit meinem Urknall ;-) andererseits hat natürlich auch Thomas recht, wenn er meint Schließlich sind die Änderungen eigentlich doch immer besser als wie es vorher war - dass das freilich immer so gut ist, wenn es keine vernünftigen Migrationshilfen gibt, bezweifle ich gerade im Moment sehr. Denn das Problem großer Systeme ist immer ihre lange Entwicklungszeit. Sie müssen also notwendig aus Zeiten stammen, die weniger entwickelt waren, haben aber genauso natürlich ihre Berechtigung, weil die Evolution (auch in der Software) nichts am Leben erhält, was nicht gebraucht wird. Komplexe Systeme wird es immer geben, solange es komplexe Gehirne gibt, die alle möglichen Ordnungsstrukturen für sich neu erfinden können - und komplexe Systeme verbrauchen gewaltige Mengen von Kategorisierungs- und Konsolidierungsenergie, das lässt sich nicht einfach so per Order de Muffdi oder Wunschdenken auf die neueste Basis stellen. Und je häufiger es Rails von der Spielwiese herunterschafft, umso eher wird es in größeren Systeme verwendet und kann sich dann nicht einfach munter unabhängig davon weiter verbessern, ohne dass es den Anschluss an die echten Bedarfe verliert. Denn wer sieht, wie man sich mit Migrationen ohne richtige Hilfen herumärgern muss, der sucht sich im Falle von Neuentwicklungen konservativere (im guten Sinn des Wortes) Systeme, also solche, die beim Verbessern ihre Anwender nicht als Volltrottel bezeichnen, weil sie die wahre Lehre nicht anwenden oder den aktuellen Hype gerade mal verpasst haben, und sei es nur, weil ihre Kunden vor lauter Arbeit nicht wissen wohin und unbedingt Hilfe via Rails brauchten. Denn die Entwickler, die Rails verstanden haben (wenn auch nur in dem Umfang, den sie selbst benötigen ;-) ) und unter Bergen von Aufträgen verbuddelt sind, sehen Rails vermutlich gerade nicht als Gegenstand ihrer Arbeit, sondern als Werkzeug. Und Werkzeuge sollten eben nicht nur perfekt, sondern auch vertrauenswürdig sein und zum Schluss: Danke Hanno für diesen Satz und was für Technologien bei Twitter, Facebook und anderen eingesetzt werden, hat in aller Regel sehr wenig mit den Anforderungen und Budgets Deiner Kunden zu tun ;-) Grüße bevier -- IKI: Infinity Kills Information - how the knowledge of what you're doing betters the result http://bussole.de/ Level of Math limits Level of Technology http://infomath.bussole.de/ 4fF method to evaluate databases: compare - count http://dtp-isw.de/ ML method to grip problems: think - write - relate - count - program http://dtp-isw.de/ Information: wiederholbare und zusammenhängende Wertveränderung von Eigenschaften - als mathematische Gruppe erklärt sie einerseits die hohe Nützlichkeit mengenmathematischer Techniken in der Naturwissenschaft, andererseits die Notwendigkeiten des Lernens in offenen Umgebungen sowie Strategie und Aufbau von Informationsverarbeitungen ___ rubyonrails-ug mailing list rubyonrails-ug@headflash.com http://mailman.headflash.com/listinfo/rubyonrails-ug
Re: [Rubyonrails-ug] State of the RoR-Nation?!
Schönes Schlußwort. Nun aber mal weg vom Rechner/SmartPhone/Tablet und ab in die Sonne! Schönen Sonntag an alle! Beste Grüße Thomas von Deyen magic labs* (von unterwegs gesendet) Am 25.03.2012 um 10:40 schrieb bevier bev...@bussole.de: hi, Am 22.03.2012 11:16, schrieb Hendrik Mans: bis ein schönes, neues 80%-Framework die Leute für sich gewinnen wird stimmt - für Neuanfänge ist das sicher korrekt aber wenn du, wie Carsten das so korrekt beschrieb zu den Etablierten zu gehörst, deren Entwickler, die Rails verstanden haben, unter anderem deswegen schwer zu hören sind, weil sie unter Bergen von Aufträgen verbuddelt sind..., dann kannst du nicht alle Jahre wieder auf einen neuen Zug aufspringen. So entstehen keine großen Systeme wer Information erhalten will, muss die Grenzgeschwindigkeit bei Veränderung respektieren (http://www.mpg.de/495749/pressRelease200403081) und diese hängt wohl an der Komplexität des Systems, wenn ich den MPG-Artikel korrekt interpretiere die neuen Züge sind sicher notwendig, um die Entwicklung auf den Gleisen voranzutreiben, doch es gibt eben auch andere Entwicklungslinien. Informationsverarbeitung ist korreliertes Arbeiten, das lässt sich niemals durch wahlloses Zusammensuchen von Best Practices erreichen. Soll eine solche Ansammlung von Best Practices funktionieren, muss die Kategorisierungsenergie eben in die Auswahl und Verlinkung der Apps gesteckt werden, umgehen lässt sie sich nicht das, was Stefan in meiner Interpretation anzudeuten scheint, hat auch mich getroffen. Denn wenn du unter Bergen von Aufträgen verbuddelt bist und auf eigenen Lösungen aufbaust, die schon lange vor dem netten Schlagwort DRY als wiederverwendbare Blackboxes konzipiert waren, dann bringt es dich schon gewaltig aus dem Tritt, wenn du stellenweise bis zum Urknall zurück in den Sourcen deiner Middleware musst. Und ja, das ist, wie Michael so treffend meinte (sondern gehe gleich zur Quelle, also dem Sourcecode) auch für mich der einzige stets hilfreiche Weg und das seit meinem Urknall ;-) andererseits hat natürlich auch Thomas recht, wenn er meint Schließlich sind die Änderungen eigentlich doch immer besser als wie es vorher war - dass das freilich immer so gut ist, wenn es keine vernünftigen Migrationshilfen gibt, bezweifle ich gerade im Moment sehr. Denn das Problem großer Systeme ist immer ihre lange Entwicklungszeit. Sie müssen also notwendig aus Zeiten stammen, die weniger entwickelt waren, haben aber genauso natürlich ihre Berechtigung, weil die Evolution (auch in der Software) nichts am Leben erhält, was nicht gebraucht wird. Komplexe Systeme wird es immer geben, solange es komplexe Gehirne gibt, die alle möglichen Ordnungsstrukturen für sich neu erfinden können - und komplexe Systeme verbrauchen gewaltige Mengen von Kategorisierungs- und Konsolidierungsenergie, das lässt sich nicht einfach so per Order de Muffdi oder Wunschdenken auf die neueste Basis stellen. Und je häufiger es Rails von der Spielwiese herunterschafft, umso eher wird es in größeren Systeme verwendet und kann sich dann nicht einfach munter unabhängig davon weiter verbessern, ohne dass es den Anschluss an die echten Bedarfe verliert. Denn wer sieht, wie man sich mit Migrationen ohne richtige Hilfen herumärgern muss, der sucht sich im Falle von Neuentwicklungen konservativere (im guten Sinn des Wortes) Systeme, also solche, die beim Verbessern ihre Anwender nicht als Volltrottel bezeichnen, weil sie die wahre Lehre nicht anwenden oder den aktuellen Hype gerade mal verpasst haben, und sei es nur, weil ihre Kunden vor lauter Arbeit nicht wissen wohin und unbedingt Hilfe via Rails brauchten. Denn die Entwickler, die Rails verstanden haben (wenn auch nur in dem Umfang, den sie selbst benötigen ;-) ) und unter Bergen von Aufträgen verbuddelt sind, sehen Rails vermutlich gerade nicht als Gegenstand ihrer Arbeit, sondern als Werkzeug. Und Werkzeuge sollten eben nicht nur perfekt, sondern auch vertrauenswürdig sein und zum Schluss: Danke Hanno für diesen Satz und was für Technologien bei Twitter, Facebook und anderen eingesetzt werden, hat in aller Regel sehr wenig mit den Anforderungen und Budgets Deiner Kunden zu tun ;-) Grüße bevier -- IKI: Infinity Kills Information - how the knowledge of what you're doing betters the result http://bussole.de/ Level of Math limits Level of Technology http://infomath.bussole.de/ 4fF method to evaluate databases: compare - count http://dtp-isw.de/ ML method to grip problems: think - write - relate - count - program http://dtp-isw.de/ Information: wiederholbare und zusammenhängende Wertveränderung von Eigenschaften - als mathematische Gruppe erklärt sie einerseits die hohe Nützlichkeit mengenmathematischer Techniken in der Naturwissenschaft, andererseits die Notwendigkeiten des Lernens in offenen Umgebungen sowie Strategie und Aufbau von
[Rubyonrails-ug] State of the RoR-Nation?!
Liebe RUGler, es ist still geworden auf dieser Liste und ich frage mich momentan, woran das liegt. Vielleicht gibt es ja noch Leben da draußen und ich fände es spannend von euch zu hören, wie Ihr die Lage der Ruby/RoR-Nation einschätzt: Ich habe mal ein paar Punkte/Hypothesen zusammengefasst, über die ich in der letzten Zeit öfter gestolpert bin: * alle Rails-Probleme sind gelöst. Oder alle sind zu anderen Listen abgewandert entweder zu den englisch-sprachigen Listen oder zu den Listen für Spezial-Themen wie deployment/cloud, mongoDB/Mongoid usw.? Oder viele haben mittlerweile Rails wieder aufgegeben?! * die Verbreitung von Ruby/RoR beschränkt sich weitgehend auf die Startup- und Webszene: Es gibt sehr viele Social-Something-Anwendungen, CMS-Lösungen, Backends für Mobile-Apps aber ich habe noch nicht viel davon gehört, dass eine Versicherung jetzt Ihre Fallbearbeitung auf Rails umgestellt hätte oder ein Logistik-Konzern seine Lagerverwaltung mit Rails macht. Natürlich ist Rails nicht für alles geeignet, aber ich habe genügend Projekte in diesen altmodischen Brick-and-Mortar-Unternehmen gesehen, bei denen reflexartig Java/JEE eingesetzt wird und nicht mal eine Millisekunde über irgend etwas anderes nachgedacht wird - von Rails bei BMW oder Allianz oder Siemens habe ich noch nix gehört. Man kann diese Projekte vielleicht langweiliger als Social-Somethings finden, aber sie sorgen für einen erheblichen Teil des IT-Job-Markts. Und hier findet Ruby/RoR einfach nicht statt: Oder täuscht mich mein Eindruck da?! Oder ist das auch gut so und Rails gehört da auch gar nicht hin und wenn Versicherung dann bitte COBOL oder wenigstens Java?! * wohin entwickelt sich Rails? In letzter Zeit stolpere ich immer mal wieder über Rants mit so schönen Überschriften wie The Sun is setting on Rails style MVC Frameworks (http://caines.ca/blog/programming/the-sun-is-setting-on-rails-style-mvc-frameworks/), dann gibt es ein paar, die sich darüber beschweren, dass der Merb-Merger alles nur langsamer und unübersichtlicher gemacht hat, dann gibt es LightRails (https://github.com/lightness/lightrail/), das Rails wieder verschlanken will, oder die Leute, die sagen, dass man sowieso nur noch APIs braucht und deswegen am besten gleich alles mit Sinatra machen sollte. Oder gleich mit node, weil ist schneller und in 2 Jahren reden wir sowieso alle nur noch JavaScript (http://gilesbowkett.blogspot.de/2012/02/rails-went-off-rails-why-im-rebuilding.html oder http://blog.nodejitsu.com/scaling-isomorphic-javascript-code). Ist da was dran? Taugt Rails noch für die schöne neue App/HTML5/1-Page-App-Welt? Oder ist es mittlerweile Bloat-ware, weil es versucht alles für alle zu sein? * Ich selber ertappe mich dabei, dass ich Features, die ich zuerst noch zweifelhaft fand, plötzlich nicht mehr missen möchte. Die Asset-Pipeline ist so ein Fall: Ich fand das dubios und hatte das Gefühl das gehört eigentlich nicht da reines gibt schon tausend Alternativen dazu, aber mittlerweile sind fast alle größeren JavaScript-Libraries in gems eingepackt (z.B. https://github.com/anjlab/bootstrap-rails), natürlich ist coffeescript netter als rohes JS, precompiler für JavaScripts-Templates (z.B. für handlebars) gibt's als Bonus und rails funktioniert so als Rundum-Sorglos-build-System für JavaScript-Apps. Es ist praktisch, aber ist es auch der richtige Weg? Oder sieht für mich die ganze Welt wie ein Nagel aus weil ich nur einen Hammer habe? Ist das nur ein temporärer Hack, der den Umstand kaschiert, dass es für JavaScript (noch) kein Modul-Konzept gibt und ist node.js nicht auf lange Sicht besser als Build-System geeignet, wenn sowieso alles nur noch JS ist?! Oder ist das Ganze wirklich eine gute Idee und Rails entwickelt sich zu einer Art Integrations-Ökosystem für Webtechnologien (und klärt dann auch irgendwann die Frage welche Version der JavaScript-Bibliothek in dieser Version des gems verbaut ist)? Wie seht Ihr das? Geht es Rails gut oder müssen wir uns Sorgen machen, schreiben wir in 2 Jahren alle nur noch JS (oder GOtt bewahre GO oder Dart... ) und die Ratten suchen sich jetzt alle schon mal ein Node-Floß, um das sinkende Schiff zu verlassen?! Viele Grüße Stefan -- Stefan Frank Softwareentwicklung vierundsechzig.de Max-Wolf Str. 9 69120 Heidelberg Tel. +49 (0) 6221 7277049 Mobil +49 (0) 151 40155607 mail s.fr...@vierundsechzig.de web www.vierundsechzig.de ___ rubyonrails-ug mailing list rubyonrails-ug@headflash.com http://mailman.headflash.com/listinfo/rubyonrails-ug
Re: [Rubyonrails-ug] State of the RoR-Nation?!
moin, fang ich mal mit dem durchzählen an 1 :D für mich gibt es aktuell 3 themen die mir in rails fehlen: * ordentliches validationsystem für models. ich will dass das system nur mit typen intern z.B. :invalid oder :blank arbeitet und nicht bei error.add das kürzel nimmt und es direkt übersetzt. das ist z.b. wichtig für apis, wo man die kürzel wieder ausliefern muss, aber auch für Übersetzungen im form system. * ordentliches Fehlerhandling im form system. Ich hab sowas mal für 2.3 gebaut. https://github.com/traxanos/better_form_builder. Hier kann man sich anschauen wie die API aussehen sollten imho. * HAML Support in Rails per default, so dass devise und die anderen plugins auf haml umstellen. mfg marco Am 22. März 2012 07:34 schrieb Stefan Frank s.fr...@vierundsechzig.de: Liebe RUGler, es ist still geworden auf dieser Liste und ich frage mich momentan, woran das liegt. Vielleicht gibt es ja noch Leben da draußen und ich fände es spannend von euch zu hören, wie Ihr die Lage der Ruby/RoR-Nation einschätzt: Ich habe mal ein paar Punkte/Hypothesen zusammengefasst, über die ich in der letzten Zeit öfter gestolpert bin: - alle Rails-Probleme sind gelöst. Oder alle sind zu anderen Listen abgewandert entweder zu den englisch-sprachigen Listen oder zu den Listen für Spezial-Themen wie deployment/cloud, mongoDB/Mongoid usw.? Oder viele haben mittlerweile Rails wieder aufgegeben?! - die Verbreitung von Ruby/RoR beschränkt sich weitgehend auf die Startup- und Webszene: Es gibt sehr viele Social-Something-Anwendungen, CMS-Lösungen, Backends für Mobile-Apps aber ich habe noch nicht viel davon gehört, dass eine Versicherung jetzt Ihre Fallbearbeitung auf Rails umgestellt hätte oder ein Logistik-Konzern seine Lagerverwaltung mit Rails macht. Natürlich ist Rails nicht für alles geeignet, aber ich habe genügend Projekte in diesen altmodischen Brick-and-Mortar-Unternehmen gesehen, bei denen reflexartig Java/JEE eingesetzt wird und nicht mal eine Millisekunde über irgend etwas anderes nachgedacht wird - von Rails bei BMW oder Allianz oder Siemens habe ich noch nix gehört. Man kann diese Projekte vielleicht langweiliger als Social-Somethings finden, aber sie sorgen für einen erheblichen Teil des IT-Job-Markts. Und hier findet Ruby/RoR einfach nicht statt: Oder täuscht mich mein Eindruck da?! Oder ist das auch gut so und Rails gehört da auch gar nicht hin und wenn Versicherung dann bitte COBOL oder wenigstens Java?! - wohin entwickelt sich Rails? In letzter Zeit stolpere ich immer mal wieder über Rants mit so schönen Überschriften wie The Sun is setting on Rails style MVC Frameworks ( http://caines.ca/blog/programming/the-sun-is-setting-on-rails-style-mvc-frameworks/), dann gibt es ein paar, die sich darüber beschweren, dass der Merb-Merger alles nur langsamer und unübersichtlicher gemacht hat, dann gibt es LightRails (https://github.com/lightness/lightrail/), das Rails wieder verschlanken will, oder die Leute, die sagen, dass man sowieso nur noch APIs braucht und deswegen am besten gleich alles mit Sinatra machen sollte. Oder gleich mit node, weil ist schneller und in 2 Jahren reden wir sowieso alle nur noch JavaScript ( http://gilesbowkett.blogspot.de/2012/02/rails-went-off-rails-why-im-rebuilding.htmloder http://blog.nodejitsu.com/scaling-isomorphic-javascript-code). Ist da was dran? Taugt Rails noch für die schöne neue App/HTML5/1-Page-App-Welt? Oder ist es mittlerweile Bloat-ware, weil es versucht alles für alle zu sein? - Ich selber ertappe mich dabei, dass ich Features, die ich zuerst noch zweifelhaft fand, plötzlich nicht mehr missen möchte. Die Asset-Pipeline ist so ein Fall: Ich fand das dubios und hatte das Gefühl das gehört eigentlich nicht da reines gibt schon tausend Alternativen dazu, aber mittlerweile sind fast alle größeren JavaScript-Libraries in gems eingepackt (z.B. https://github.com/anjlab/bootstrap-rails), natürlich ist coffeescript netter als rohes JS, precompiler für JavaScripts-Templates (z.B. für handlebars) gibt's als Bonus und rails funktioniert so als Rundum-Sorglos-build-System für JavaScript-Apps. Es ist praktisch, aber ist es auch der richtige Weg? Oder sieht für mich die ganze Welt wie ein Nagel aus weil ich nur einen Hammer habe? Ist das nur ein temporärer Hack, der den Umstand kaschiert, dass es für JavaScript (noch) kein Modul-Konzept gibt und ist node.js nicht auf lange Sicht besser als Build-System geeignet, wenn sowieso alles nur noch JS ist?! Oder ist das Ganze wirklich eine gute Idee und Rails entwickelt sich zu einer Art Integrations-Ökosystem für Webtechnologien (und klärt dann auch irgendwann die Frage welche Version der JavaScript-Bibliothek in dieser Version des gems verbaut ist)? Wie seht Ihr das? Geht es Rails gut oder müssen wir uns Sorgen
Re: [Rubyonrails-ug] State of the RoR-Nation?!
moinmoin, schön, dass es Leben da draußen gibt :) -- Marco Scholl 22. März 2012 08:17 moin,fang ich mal mit dem durchzählen an "1" :Dfür mich gibt es aktuell 3 themen die mir in rails fehlen:* ordentliches validationsystem für models. ich will dass das system nur mit typen intern z.B. :invalid oder :blank arbeitet und nicht bei error.add das kürzel nimmt und es direkt übersetzt. das ist z.b. wichtig für apis, wo man die kürzel wieder ausliefern muss, aber auch für Übersetzungen im form system. und dann weiß ich nicht, ob man Thema client-seitige Validierung im Core drin haben will oder lieber nicht. Oder doch lieber nur als plugin (https://github.com/bcardarella/client_side_validations). Am schönsten wäre eine API, um Validations/Feldbeschreibungen auch an einen JSON-Client schicken zu können ... * ordentliches Fehlerhandling im form system. Ich hab sowas mal für 2.3 gebaut. https://github.com/traxanos/better_form_builder. Hier kann man sich anschauen wie die API aussehen sollten imho. ohne das jetzt im Detail zu kennen, aber inwiefern unterscheidet sich das jetzt von formtastic(https://github.com/justinfrench/formtastic) und dem ganzen Gesummse, dass sich mittlerweile darum gebildet hat? Scheint irgendwie immer die Frage zu sein, was ist Core und was ist plugin/gem... * HAML Support in Rails per default, so dass devise und die anderen plugins auf haml umstellen. **seufz** fänd ich auch schön, aber das scheint den Leuten wohl zu opinionated zu sein, sonst wär das schon längst drin... mfg marco ___rubyonrails-ug mailing listrubyonrails-ug@headflash.comhttp://mailman.headflash.com/listinfo/rubyonrails-ug Stefan Frank 22. März 2012 07:34 Liebe RUGler, es ist still geworden auf dieser Liste und ich frage mich momentan, woran das liegt. Vielleicht gibt es ja noch Leben da draußen und ich fände es spannend von euch zu hören, wie Ihr die Lage der Ruby/RoR-Nation einschätzt: Ich habe mal ein paar Punkte/Hypothesen zusammengefasst, über die ich in der letzten Zeit öfter gestolpert bin: alle Rails-Probleme sind gelöst. Oder alle sind zu anderen Listen abgewandert entweder zu den englisch-sprachigen Listen oder zu den Listen für Spezial-Themen wie deployment/cloud, mongoDB/Mongoid usw.? Oder viele haben mittlerweile Rails wieder aufgegeben?! die Verbreitung von Ruby/RoR beschränkt sich weitgehend auf die Startup- und Webszene: Es gibt sehr viele Social-Something-Anwendungen, CMS-Lösungen, Backends für Mobile-Apps aber ich habe noch nicht viel davon gehört, dass eine Versicherung jetzt Ihre Fallbearbeitung auf Rails umgestellt hätte oder ein Logistik-Konzern seine Lagerverwaltung mit Rails macht. Natürlich ist Rails nicht für alles geeignet, aber ich habe genügend Projekte in diesen altmodischen Brick-and-Mortar-Unternehmen gesehen, bei denen reflexartig Java/JEE eingesetzt wird und nicht mal eine Millisekunde über irgend etwas anderes nachgedacht wird - von Rails bei BMW oder Allianz oder Siemens habe ich noch nix gehört. Man kann diese Projekte vielleicht langweiliger als Social-Somethings finden, aber sie sorgen für einen erheblichen Teil des IT-Job-Markts. Und hier findet Ruby/RoR einfach nicht statt: Oder täuscht mich mein Eindruck da?! Oder ist das auch gut so und Rails gehört da auch gar nicht hin und wenn Versicherung dann bitte COBOL oder wenigstens Java?! wohin entwickelt sich Rails? In letzter Zeit stolpere ich immer mal wieder über Rants mit so schönen Überschriften wie "The Sun is setting on Rails style MVC Frameworks" (http://caines.ca/blog/programming/the-sun-is-setting-on-rails-style-mvc-frameworks/), dann gibt es ein paar, die sich darüber beschweren, dass der Merb-Merger alles nur langsamer und unübersichtlicher gemacht hat, dann gibt es LightRails (https://github.com/lightness/lightrail/), das Rails wieder verschlanken will, oder die Leute, die sagen, dass man sowieso nur noch APIs braucht und deswegen am besten gleich alles mit Sinatra machen sollte. Oder gleich mit node, weil ist schneller und in 2 Jahren reden wir sowieso alle nur noch _javascript_ (http://gilesbowkett.blogspot.de/2012/02/rails-went-off-rails-why-im-rebuilding.html oder http://blog.nodejitsu.com/scaling-isomorphic-_javascript_-code). Ist da was dran? Taugt Rails noch für die schöne neue App/HTML5/1-Page-App-Welt? Oder ist es mittlerweile Bloat-ware, weil es versucht alles für alle zu sein? Ich selber ertappe mich dabei, dass ich Features, die ich zuerst noch zweifelhaft fand, plötzlich nicht mehr missen möchte. Die Asset-Pipeline ist so ein Fall: Ich fand das dubios und hatte das Gefühl das gehört eigentlich nicht da reines gibt schon tausend Alternativen dazu, aber mittlerweile sind fast alle größeren _javascript_-Libraries in gems eingepackt (z.B. https://github.com/anjlab/bootstrap-rails), natürlich ist
Re: [Rubyonrails-ug] State of the RoR-Nation?!
Carsten, das kann ich nur genauso unterschreiben. Beste Grüße Thomas von Deyen magic labs* (von unterwegs gesendet) Am 22.03.2012 um 08:24 schrieb Carsten Bormann c...@tzi.org: On Mar 22, 2012, at 07:34, Stefan Frank wrote: es ist still geworden auf dieser Liste -- vielleicht haben wir einfach weniger Probleme? -- (und lösen sie dann in den englischsprachigen Sites?) Rails ist in der interessanten Situation, jetzt zu den Etablierten zu gehören -- man kann mit dem Hype keine Blumentöpfe mehr gewinnen. Wen an Rails immer nur interessiert hat, dass es neu ist, der sieht sich jetzt natürlich nach neuen Neuigkeiten wie node.js etc. um. (Und node.js ist eine feine Sache, aber löst eben ein anderes Problem.) Die Entwickler, die Rails verstanden haben, sind unter anderem deswegen schwer zu hören, weil sie unter Bergen von Aufträgen verbuddelt sind... Dass Versicherungen genug Geld haben, um weiter ihre wenig effiziente Java Enterprise Geschichte zu machen, sollte uns ebenso wenig verunsichern wie früher die Dominanz von COBOL in diesem Bereich. (Während die Versicherungen noch X.25 gemacht und X.400 ausprobiert haben, waren wir schon im Internet...) Natürlich war Rails nie für alle Anwendungen dieser Welt perfekt -- wer sich jetzt abwendet, hat dies für seinen Bereich oft nur einfach zu spät bemerkt. (Und es gibt genug Stellen, an denen noch etwas zu tun ist; darüber zu reden ist nur oft einfach nicht so sexy.) Rails gewinnt auch durch die Kombination mit anderen Technologien; es ist nicht falsch, z.B. Sinatra (oder einfache Rack-Anwendungen) ebenfalls in seinem Köcher zu haben, und JavaScript brauchen wir ohnehin für die Client-Seite. Ich habe gerade zum siebten mal meinen jährlichen Kurs Agile Webentwicklung durchgeführt -- so schöne Anwendungen in kurzer Zeit (zwei Wochen) mit so konsistenter Qualität wie die neun Arbeitsgruppen diesmal haben die Gruppen in den sechs Jahren davor nicht geschafft. Die inzwischen doch sehr hohe Qualität des Rails-Ökosystems hat daran einen wesentlichen Anteil. Ja, Rails wird erwachsen; die wilden Jahre sind vorbei. Das macht das Leben nicht uninteressanter. Grüße, Carsten ___ rubyonrails-ug mailing list rubyonrails-ug@headflash.com http://mailman.headflash.com/listinfo/rubyonrails-ug ___ rubyonrails-ug mailing list rubyonrails-ug@headflash.com http://mailman.headflash.com/listinfo/rubyonrails-ug
Re: [Rubyonrails-ug] State of the RoR-Nation?!
mfg marco Am 22. März 2012 08:35 schrieb Stefan Frank s.fr...@vierundsechzig.de: moinmoin, schön, dass es Leben da draußen gibt :) -- Marco Scholl deve...@marco-scholl.de 22. März 2012 08:17 moin, fang ich mal mit dem durchzählen an 1 :D für mich gibt es aktuell 3 themen die mir in rails fehlen: * ordentliches validationsystem für models. ich will dass das system nur mit typen intern z.B. :invalid oder :blank arbeitet und nicht bei error.add das kürzel nimmt und es direkt übersetzt. das ist z.b. wichtig für apis, wo man die kürzel wieder ausliefern muss, aber auch für Übersetzungen im form system. und dann weiß ich nicht, ob man Thema client-seitige Validierung im Core drin haben will oder lieber nicht. Oder doch lieber nur als plugin ( https://github.com/bcardarella/client_side_validations). Am schönsten wäre eine API, um Validations/Feldbeschreibungen auch an einen JSON-Client schicken zu können ... * ordentliches Fehlerhandling im form system. Ich hab sowas mal für 2.3 gebaut. https://github.com/traxanos/better_form_builder. Hier kann man sich anschauen wie die API aussehen sollten imho. ohne das jetzt im Detail zu kennen, aber inwiefern unterscheidet sich das jetzt von formtastic(https://github.com/justinfrench/formtastic) und dem ganzen Gesummse, dass sich mittlerweile darum gebildet hat? Scheint irgendwie immer die Frage zu sein, was ist Core und was ist plugin/gem... das problem ist formtastic versucht alles erstmal generisch zu lösen, das will ich aber nicht, da es in 90% aller Fälle nicht zu dem passt was der Kunde will. wobei formtastic gut für ein backend ist. Ich will ja eigentlich bessere Basisfunktionen haben. z.B. das Form fragen eb es einen Fehler auf dem Feld xy gibt. Das geht in dem ich das Model frage, das will ich aber nicht. Ich will das Form fragen, da es das Model kennt und ich so eine Fehlerquelle weniger habe und lesbaren/wartbareren Code entsteht. * HAML Support in Rails per default, so dass devise und die anderen plugins auf haml umstellen. **seufz** fänd ich auch schön, aber das scheint den Leuten wohl zu opinionated zu sein, sonst wär das schon längst drin... mfg marco ___ rubyonrails-ug mailing list rubyonrails-ug@headflash.com http://mailman.headflash.com/listinfo/rubyonrails-ug Stefan Frank s.fr...@vierundsechzig.de 22. März 2012 07:34 Liebe RUGler, es ist still geworden auf dieser Liste und ich frage mich momentan, woran das liegt. Vielleicht gibt es ja noch Leben da draußen und ich fände es spannend von euch zu hören, wie Ihr die Lage der Ruby/RoR-Nation einschätzt: Ich habe mal ein paar Punkte/Hypothesen zusammengefasst, über die ich in der letzten Zeit öfter gestolpert bin: - alle Rails-Probleme sind gelöst. Oder alle sind zu anderen Listen abgewandert entweder zu den englisch-sprachigen Listen oder zu den Listen für Spezial-Themen wie deployment/cloud, mongoDB/Mongoid usw.? Oder viele haben mittlerweile Rails wieder aufgegeben?! - die Verbreitung von Ruby/RoR beschränkt sich weitgehend auf die Startup- und Webszene: Es gibt sehr viele Social-Something-Anwendungen, CMS-Lösungen, Backends für Mobile-Apps aber ich habe noch nicht viel davon gehört, dass eine Versicherung jetzt Ihre Fallbearbeitung auf Rails umgestellt hätte oder ein Logistik-Konzern seine Lagerverwaltung mit Rails macht. Natürlich ist Rails nicht für alles geeignet, aber ich habe genügend Projekte in diesen altmodischen Brick-and-Mortar-Unternehmen gesehen, bei denen reflexartig Java/JEE eingesetzt wird und nicht mal eine Millisekunde über irgend etwas anderes nachgedacht wird - von Rails bei BMW oder Allianz oder Siemens habe ich noch nix gehört. Man kann diese Projekte vielleicht langweiliger als Social-Somethings finden, aber sie sorgen für einen erheblichen Teil des IT-Job-Markts. Und hier findet Ruby/RoR einfach nicht statt: Oder täuscht mich mein Eindruck da?! Oder ist das auch gut so und Rails gehört da auch gar nicht hin und wenn Versicherung dann bitte COBOL oder wenigstens Java?! - wohin entwickelt sich Rails? In letzter Zeit stolpere ich immer mal wieder über Rants mit so schönen Überschriften wie The Sun is setting on Rails style MVC Frameworks ( http://caines.ca/blog/programming/the-sun-is-setting-on-rails-style-mvc-frameworks/), dann gibt es ein paar, die sich darüber beschweren, dass der Merb-Merger alles nur langsamer und unübersichtlicher gemacht hat, dann gibt es LightRails (https://github.com/lightness/lightrail/), das Rails wieder verschlanken will, oder die Leute, die sagen, dass man sowieso nur noch APIs braucht und deswegen am besten gleich alles mit Sinatra machen sollte. Oder gleich mit node, weil ist schneller und in 2 Jahren reden wir sowieso alle nur noch JavaScript (
Re: [Rubyonrails-ug] State of the RoR-Nation?!
Das passt doch zum Thema: http://blog.alexmaccaw.com/rails-is-just-and-api-and-that-s-ok Gruß Thomas ___ rubyonrails-ug mailing list rubyonrails-ug@headflash.com http://mailman.headflash.com/listinfo/rubyonrails-ug
Re: [Rubyonrails-ug] State of the RoR-Nation?!
On Thursday 22 March 2012, Stefan Frank wrote: es ist still geworden auf dieser Liste und ich frage mich momentan, woran das liegt. Vielleicht gibt es ja noch Leben da draußen und ich fände es spannend von euch zu hören, wie Ihr die Lage der Ruby/RoR-Nation einschätzt: Ich habe mal ein paar Punkte/Hypothesen zusammengefasst, über die ich in der letzten Zeit öfter gestolpert bin: alle Rails-Probleme sind gelöst. Oder alle sind zu anderen Listen abgewandert entweder zu den englisch-sprachigen Listen oder zu den Listen für Spezial-Themen wie deployment/cloud, mongoDB/Mongoid usw.? Ich benutz -- Michael Schuerig mailto:mich...@schuerig.de http://www.schuerig.de/michael/ ___ rubyonrails-ug mailing list rubyonrails-ug@headflash.com http://mailman.headflash.com/listinfo/rubyonrails-ug
Re: [Rubyonrails-ug] State of the RoR-Nation?!
[Entschuldigung, beim ersten Versuch habe ich die falsche Taste zu früh gedrückt -- Koffeinmangel!] On Thursday 22 March 2012, Stefan Frank wrote: es ist still geworden auf dieser Liste und ich frage mich momentan, woran das liegt. Vielleicht gibt es ja noch Leben da draußen und ich fände es spannend von euch zu hören, wie Ihr die Lage der Ruby/RoR-Nation einschätzt: Ich habe mal ein paar Punkte/Hypothesen zusammengefasst, über die ich in der letzten Zeit öfter gestolpert bin: alle Rails-Probleme sind gelöst. Oder alle sind zu anderen Listen abgewandert entweder zu den englisch-sprachigen Listen oder zu den Listen für Spezial-Themen wie deployment/cloud, mongoDB/Mongoid usw.? Ich arbeite seit 2005, ~Rails 0.9, professionell mit Rails. In den ersten Jahren war ich auf der englischen ML recht aktiv, inzwischen lese ich sie noch nichteinmal mehr, weil mir die Masse zu groß geworden ist. Die Hoffnung, dass dort oder hier meine Fragen, die ich durchaus nach wie vor habe, beantwortet werden könnten, sind immer geringer geworden. Entsprechend frage ich nicht mehr, sondern gehe gleich zur Quelle, also dem Sourcecode, was sich über die Jahre eigentlich immer als die beste Strategie erwiesen hat. Was Rails selbst angeht. Perfekt ist es noch lange nicht, wird es wohl auch nie werden. Aber es ist mit der Zeit immer besser geworden -- finde jedenfalls ich. Aus meiner Sicht ist Rails 3 ein großer Fortschritt, weil die Codequalität deutlich besser geworden ist, insbesondere durch Modularisierung. Es bleibt die Möglichkeit, dass Rails zwar besser wird, aber die Nische, für die es geeignet ist, mit der Zeit immer enger wird. Ich kann das nicht erkennen, weil ich nicht erwarte, dass in naher Zukunft ein großer Teil klassischer Webanwendungen durch RIAs ersetzt werden. Michael -- Michael Schuerig mailto:mich...@schuerig.de http://www.schuerig.de/michael/ ___ rubyonrails-ug mailing list rubyonrails-ug@headflash.com http://mailman.headflash.com/listinfo/rubyonrails-ug
Re: [Rubyonrails-ug] State of the RoR-Nation?!
Ich sehe das nicht ganz so.Assets sind entweder in app/assets, lib/assets, vendor/assets oder in 'nem gem. Und auch die gems haben alle das selbe layout, da sie ja rails engines sind.Und welches Frontend Framework du benutzt war schon immer losgelöst von rails. Und das sollte es bitte auch.Ich komme mit dem standard out of the box rails immer noch gut klar. Außer halt die rspec Frage. Das wird sich aber mit Rails 4 eh ändern, da dort mini-test standard sein wird und sich das ja an die RSpec syntax hält. Auch hier gilt: Rails bringt einem dazu seine Gewohnheiten regelmäßig zu überdenken. Und das ist gut so! Schließlich sind die Änderungen eigentlich doch immer besser als wie es vorher war.LGTAm 22.03.2012 um 10:53 schrieb Stefan Frank:danke, dass trifft denPunkt: Gut genug für das Meiste ist momentan auch mein Eindruck: Mirging das so, als ich mal node angeschauthatte, dass mir plötzlich ganzviele Sachen fehlten, die man in rails schon für selbstverständlichnimmt. Mehr Ökosystem halt.Aber bleibt bei mir dann noch ein Bauchgrummeln: Einer derRiesenvorteile von Rails ist es bis jetzt gewesen, dass alle Anwendungengleich aussehen und jeder zumindest halbwegs weiß wo was ist. Das dasnicht mehr ganz so ist, ist schon eine notwendige Folge derModularisierung: Im Backend (mongoid+rspec oder mysql+rails usw.) wardas ja schon länger (und auch gut) so, aber das wird mit diesenRIAsnatürlich immer schlimmer: Benutzt man jetzt backbone oder spine oderember oder knockout oder rohes jquery, wie packaged man,wie werdenjs-dependencies verwaltet (in gems?! oder direkt in den Projekten?) oderbaut man diese JS-App gleich außerhalb von Railsund connectet sich nurüber eine API usw. - schön, dass man alle diese Freiheiten hat, aberjetzt muss man plötzlich über alle dieseSachen auch nachdenken. Undkann bei der ausgewählten Lösung natürlich auch falsch liegen - ich sehhier momentan nicht, ob sich dashier irgendwann alles setzt und sicheiner dieser Ansätze/best practices als Favorit rauskristallisiert.Schließlich machen ja auchhier viele immer wieder das Gleiche, nuranders. Aber die opinion hier ist wohl, dass es dazu keine opinion gibt,oder?!GrüßeStefan Thomas von Deyen 22. März 201209:48Das passt doch zum Thema:http://blog.alexmaccaw.com/rails-is-just-and-api-and-that-s-okGrußThomas___rubyonrails-ugmailing listrubyonrails-ug@headflash.comhttp://mailman.headflash.com/listinfo/rubyonrails-ug___rubyonrails-ug mailing listrubyonrails-ug@headflash.comhttp://mailman.headflash.com/listinfo/rubyonrails-ug___ rubyonrails-ug mailing list rubyonrails-ug@headflash.com http://mailman.headflash.com/listinfo/rubyonrails-ug
Re: [Rubyonrails-ug] State of the RoR-Nation?!
Moin. tl;dr Ist schon alles gut ;-) 2012/3/22 Stefan Frank s.fr...@vierundsechzig.de: die Verbreitung von Ruby/RoR beschränkt sich weitgehend auf die Startup- und Webszene: Es gibt sehr viele Social-Something-Anwendungen, CMS-Lösungen, Backends für Mobile-Apps aber ich habe noch nicht viel davon gehört, dass eine Versicherung jetzt Ihre Fallbearbeitung auf Rails umgestellt hätte oder ein Logistik-Konzern seine Lagerverwaltung mit Rails macht. Natürlich ist Rails nicht für alles geeignet, aber ich habe genügend Projekte in diesen altmodischen Brick-and-Mortar-Unternehmen gesehen, bei denen reflexartig Java/JEE eingesetzt wird und nicht mal eine Millisekunde über irgend etwas anderes nachgedacht wird - von Rails bei BMW oder Allianz oder Siemens habe ich noch nix gehört. Man kann diese Projekte vielleicht langweiliger als Social-Somethings finden, aber sie sorgen für einen erheblichen Teil des IT-Job-Markts. Und hier findet Ruby/RoR einfach nicht statt: Oder täuscht mich mein Eindruck da?! Oder ist das auch gut so und Rails gehört da auch gar nicht hin und wenn Versicherung dann bitte COBOL oder wenigstens Java?! Meiner Erfahrung nach sprechen solche Unternehmen nie über die von ihnen eingesetzten Technologien. Außer man kennt Leute, die dort in den Entwicklungsabteilungen arbeiten, ist es schwer an Informationen zu kommen. Ich kann nur aus meiner eigenen Erfahrung mit einem anderen Open-Source CMS schließen. Obwohl man davon nie auf Nachrichtenseiten oder Twitter gehört hat, wurde das doch intern irgendwo von Siemens, Bundeswehr, Universitäten, Regierungsorganisationen und vielen anderen in Deutschland eingesetzt. Oftmals gibt's da NDA's zu, die die Berichterstattung unterbinden. Wenn ich mir einige Statistiken ansehe, dann deutet da nichts darauf hin, dass es Rails schlecht ginge. Die sind natürlich alle mit Vorsicht zu genießen und man sollte sich deren Datenbasis genau angucken, bevor man daraus weitere Schlüsse zieht: http://trends.builtwith.com/framework/growth#!oneYear https://github.com/languages http://www.ohloh.net/languages/compare?commit=Updatel0=javal1=phpl2=pythonl3=rubyl4=-1measure=contributorspercent=true Und was diesen ganzen JavaScript-Hype angeht, vor Jahren haben wir uns über MooTools, Prototype, jQuery und Dojo gestritten - jQuery hat da wohl gewonnen, was aber nicht heißt, dass es die anderen nicht mehr gäbe. Genau das gleiche passiert immer wieder. Irgendwann fließen einige dieser Dinge in Webstandards zurück, wie CSS Grid Layout, bessere HTML5 Widgets oder Verbesserungen an JS-Modularisierung und Abhängigkeitserklärungen. Bis dahin bleibt das alles kunterbunt und ändert sich beständig. Rails hat eine aktive Community, die alle gleiche Probleme zu lösen haben. Daraus werden sich auch gleichartige Antworten finden lassen. Ich würde mich von diesen Silicon-Valley/Hacker News lastigen Nachrichten nicht täuschen lassen. Und was für Technologien bei Twitter, Facebook und anderen eingesetzt werden, hat in aller Regel sehr wenig mit den Anforderungen und Budgets Deiner Kunden zu tun. Letztlich sollte entscheidend sein, ob Rails Dir die Arbeit bei Deinen Projekten erleichtert und Du das Gefühl hast, dass dieses auch weiterhin der Fall sein wird. Viele Grüße, Hanno ___ rubyonrails-ug mailing list rubyonrails-ug@headflash.com http://mailman.headflash.com/listinfo/rubyonrails-ug
Re: [Rubyonrails-ug] State of the RoR-Nation?!
Thomas von Deyen 22. Mrz 2012 11:02 Ich sehe das nicht ganz so.Assets sind entweder in app/assets, lib/assets, vendor/assets oder in 'nem gem. Und auch die gems haben alle das selbe layout, da sie ja rails engines sind. ja, klar. Aber: Twitter Bootstrap besteht aus css,js und images - kommt aber als ein zip: das kann man dann entweder nehmen und auspacken und verteilen, oder man nimmt eines der vielen praktischen gems, in denen das bereits passiert ist (z.B. https://github.com/anjlab/bootstrap-rails) - und so entwickelt sich dieses "in gems einpacken" fr _javascript_-libs quasi zum Standard. Aber abgesehen davon, dass das praktisch ist, ist das auch der richtige Ansatz(woher wei man dann z.B. welche Version der JS-Bibliothek in dem gem ist?) oder sollte man da lieber hergehen und sagen: Das ist kein rails-issue, sondern ein client-issue. In der Praxis sorgt das dafr, dass man verschiedene Anstze hat, seine js-dependencies zu verwalten, das kann messy werden, wenn das viel ist: Die choices hier sind sicher wichtig, aber ich mag auch die starken opinions ... Und welches Frontend Framework du benutzt war schon immer losgelst von rails. Und das sollte es bitte auch. prototype/scriptaculous war schon eine "opinionated" Entscheidung. Ebenso der Schwenk zu jquery. Dann gab/gibt es noch das unselige rjs. Oder die ganzen remote-Helper - das greift schon ziemlich tief auf den Client durch. Das ist doch das Schne an rails, das man sich hier nicht zu schade ist, pragmatische Entscheidungen zu treffen, wenn sie einem das Leben nur leichter machen. Bis jetzt war also ein bestimmtes Model, wie AJAX geht, Teil von Rails. Ich finde auch, das gehrt da eigentlich nicht mehr rein, seit die Welt mit ihren tausend js-Frameworks zu bunt geworden ist Ich komme mit dem standard out of the box rails immer noch gut klar. Auer halt die rspec Frage. Das wird sich aber mit Rails 4 eh ndern, da dort mini-test standard sein wird und sich das ja an die RSpec syntax hlt. Auch hier gilt: Rails bringt einem dazu seine Gewohnheiten regelmig zu berdenken. Und das ist gut so! Schlielich sind die nderungen eigentlich doch immer besser als wie es vorher war. choice is good - und opinions auch :) ___ rubyonrails-ug mailing list rubyonrails-ug@headflash.com http://mailman.headflash.com/listinfo/rubyonrails-ug
Re: [Rubyonrails-ug] State of the RoR-Nation?!
Vielen Dank an alle für die lebhafte Diskussion: Ich habe zumindest daraus gelernt, dass es nach wie vor eine durchaus streitbare deutschsprachige Community gibt, auch wenn diese Liste hier mittlerweile weitgehend verwaist ist und die meisten Leute zu anderen Listen/Sites abgewandert sind. Um Rails in Deutschland mache ich mir jetzt schon deutlich weniger Sorgen, solange man hier noch mit der bloßen Erwähnung von node einen Sturm der Entrüstung entfachen kann sind wir glaub' ich gesund :) In diesem Sinne noch einen schönen Frühlingstag Stefan ___ rubyonrails-ug mailing list rubyonrails-ug@headflash.com http://mailman.headflash.com/listinfo/rubyonrails-ug
