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 Informationsverarbeitungen > > _______________________________________________ > 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
