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
