Einfaches Client/Server-System à la SAP?
-
Fletcher schrieb:
Bei .NET und Java wird ganz offen gesagt, daß der interne Programmoverhead durch die Rechenleistung heutiger Prozessoren kompensiert wird. Dafür bekommt man recht schnell eine Anwendung fertig.
Du hast einfach eine falsche Vorstellung von Softwarearchitektur
-
@Fletcher
Du hast eine vollkommen falsche Vorstellung von .NET. Was du schreibst ist völliger Quatsch. Der Schluss von einem .NET Programm auf .NET im Allgemeinen entbehrt jeglicher Logik. Der Vergleich VBA <-> C# ist auch reichlich lächerlich. Und ich garantiere dir dass du die Komplexität der Sache unterschätzt.Was Softwarearchitektur angeht: wenn man das kann, dann kann man durchaus auch recht komplexe Software so bauen dass Änderungen leicht möglich sind. Und wenn man es nicht kann, dann braucht es keine 30 oder 100 Jahre bis man vor einem völlig unwartbaren Haufen steht. Je nachdem wie schlecht man wirklich ist, und wie oft man Änderungen vornimmt kann man das in ein paar Wochen hinbekommen.
Aber OK, nachdem du vollkommen beratungsresistent bist und nur das bestätigt bekommen wolltest was du sowieso schon vor hattest: ja, lern C++ und schreib ne Anwendung die direkt auf den SQL-Server hingreift. Ist ne richtig gute Idee
-
OK Leute, mag sein daß ich von Softwarearchitektur nicht viel verstehe; ich weiß aber ganz genau wie das Endprodukt aussehen soll und wie es performen soll. Schaffe ich es nicht die Anwendung so zu erstellen, daß sie nach meinem Begriff gut performed, muß ich das ohnehin mit mir selbst ausmachen.
Ich habe nie behauptet daß mein Vorhaben zwischen 2 Tassen Kaffee erledigt werden kann. Ich habe auch nie gesagt, daß die Combo C++ und SQL-Server das gelbe vom Ei ist. Ich wollte einfach Meinungen dazu hören, und ich habe sie gehört. Die Bringschuld liegt jetzt bei mir, damit zu Beginnen und eventuell an dieser Stelle über erste Ergebnisse zu berichten - was aber viele Wochen dauern kann, weil --> Freizeitprojekt neben einem Nicht-IT-Fulltimejob.
Das schöne an der IT ist, daß von Anfang an absolute Gleichberechtigung herrscht: Während man bei vielen Berufen eine höhere Ausbildung oder gar ein Studium vorweisen muß, spricht es für sich wenn es 14-Jährige gibt die in den Pentagon-Computer eindringen können (nur ein symbolisches Beispiel). Der 14-Jährige hat per sofort bewiesen, daß er über stark überdurchschnittliche Computerkenntnisse verfügen muß.
Ich erinnere nocheinmal an mein 1.Posting in diesem Thread: Eine 70er-Jahre Kiste mit Terminal-Emulatoren bringt angeforderte Daten in weniger als 0,3s auf den Bildschirm, während heutige Plattformen schon 0,3s brauchen damit sie das "Loading"-PopUp mit dem drehenden Kreis anzeigen?!?! Hier stimmt doch etwas nicht!
-
Fletcher schrieb:
OK Leute, mag sein daß ich von Softwarearchitektur nicht viel verstehe; ich weiß aber ganz genau wie das Endprodukt aussehen soll und wie es performen soll. Schaffe ich es nicht die Anwendung so zu erstellen, daß sie nach meinem Begriff gut performed, muß ich das ohnehin mit mir selbst ausmachen.
Nur weil ich weiss wie eine Rakete aussieht, bin ich noch lange kein Raktentechniker.
Ich erinnere nocheinmal an mein 1.Posting in diesem Thread: Eine 70er-Jahre Kiste mit Terminal-Emulatoren bringt angeforderte Daten in weniger als 0,3s auf den Bildschirm, während heutige Plattformen schon 0,3s brauchen damit sie das "Loading"-PopUp mit dem drehenden Kreis anzeigen?!?! Hier stimmt doch etwas nicht!
Solche Aussagen machen mich sprachlos und lassen mich an der Menschheit zweifeln.
-
Was genau bitte macht dich an meiner Aussage sprachlos? Ich glaube ich habe es genau auf den Punkt gebracht worum es mir geht.
Aber nocheinmal anders gefragt: "Wieso ist ein 70er-Jahre System schneller als eines aus den 2010er Jahren?"Hier geht es gar nicht um C++, .NET, Java oder sonst was - völlig uninteressant in dem Fall! Der Laie sieht nur, daß das neue System langsamer antwortet...
Die Programmiersprache bei unserem Uraltsystem war übrigens COBOL!
-
Fletcher schrieb:
[...] Anwendung [...] erstellen [...]
Dann gehe hin, und erstelle mal.
-
Fletcher schrieb:
"Wieso ist ein 70er-Jahre System schneller als eines aus den 2010er Jahren?"
Ist es nicht.
-
Ist es nicht.
So eine Aussage macht jetzt mich sprachlos! Ich habe jedenfalls 13 Jahre mit diesem System gearbeitet, und ich sehe was ich sehe. Es gab eine Übergangszeit, wo beide Systeme verfügbar waren und es haben ALLE bis zur letzen Minute mit dem alten System gearbeitet weil schneller.
Ja nachdem was am alten System zu tun war, konnten unsere Power-User bis zu 3 Inputs (Transmits) pro Sekunde (!) per Hand einegeben.Unsere IT hat immerhin zu keiner Zeit behauptet, daß das neue System besser sei; man war gezwungen auf ein neues System umzustellen, weil die alten Programmierer (COBOL) in Pension gehen und niemand mehr da ist, der COBOL kann.
Selbst wenn jemand COBOL könnte, hätte er es beim Gesamtsystem mit 1 Mio Code-Zeilen zu tun gehabt - in Form von Spaghetti-Code und ohne Dokumentation. (Info vom Abteilungsleiter dort, der selbst noch in die Schule ging, als man begann das System zu programmieren).
Trotz dieser beiden No-Go's war man in der Lage das System mehrere Jahrzehnte am Laufen zu halten.Was hat man eigentlich in den 90ern verwendet wenn man über eine Windows-Oberfläche in eine SQL-Datenbank hineinwollte? Da kannst Du einige Sub-Foren hier streichen weil manche Dinge damals gar nicht gab!
-
Fletcher schrieb:
Die Bringschuld liegt jetzt bei mir, damit zu Beginnen und eventuell an dieser Stelle über erste Ergebnisse zu berichten - was aber viele Wochen dauern kann
Das ist ja gar nicht das Problem... Ich bin mir sogar ziemlich sicher, dass die ersten Ergebnisse kommen und du was halbwegs lauffähiges hinbekommst. Ich würde sogar behaupten, je weniger man sich auskennt, desto schneller kommt man voran
Die Probleme kommen aber später, wenn es darum geht, aus dem Prototypen ein Produkt zu machen (damit mein ich nicht unbedingt etwas, was man verkaufen kann, reicht auch etwas, was man guten Gewissens intern einsetzen und dann auch anpassen/erweitern kann).
Als ich angefangen habe zu programmieren (nur programmieren und noch keine Ahnung von Softwareentwicklung hatte), habe ich jahrelang an einem Animationsprogramm gearbeitet. Und es konnte erstaunlich viel. Es lief überhaupt nicht sauber, aber es waren sehr viele fortgeschrittene Features drin. Das Problem war, dass es reinster Spaghetticode war, aus dem ich niemals ein Produkt hätte machen können. Das habe ich aber auch erst Jahre später verstanden. Heute wär ich nicht mehr in der Lage, ansatzweise so weit zu kommen, wie damals. Allein, weil ich wahrscheinlich Jahre für die Planung gebraucht hätte. Damals habe ich einfach direkt angefangen und alles was ich mir vorgestellt habe dann auch möglichst direkt implementiert. Und dann sind die ganze Zeit immer mehr Abhängigkeiten und Sondefälle reingekommen, die sich überall durchgezogen haben, aber ich habs eine Weile im Griff gehabt. Sowas könnte ich heute gar nicht mehr machen. Allein bei den grundlegenden Klassen könnte ich nicht einfach anfangen, ohne ein Gesamtkonzept zu haben, auf dem alle Features aufbauen. Und wenn ich soweit wäre, würde ich allein für die Basis (wo man noch gar nichts sieht oder ausprobieren kann) viel länger brauchen, als ich damals für das ganze Programm gebraucht habe, wo man schon viel sehen konnte. Und da ich das schon weiß, würde ich so ein Programm nicht mehr anfangen
Bei deinem Client-Server System verhält es sich ähnlich. Natürlich kann man einfach mal anfangen und irgendwas funktionierendes hinbekommen. Aber du wirst sicherlich über tausend Stellen stolpern, wo sich schon Entwickler vor dir Gedanken gemacht haben und wahrscheinlich bessere Lösungen gefunden haben, als du. Und du wirst sehr wahrscheinlich immer wieder über irgendwas stolpern, was nicht in dein Konzept passt, und du wirst es deswegen umbauen müssen. Deswegen halte ich es für wenig erfolgversprechend, ohne die entsprechenden Kenntnisse und Erfahrung einfach mal mit so einem Projekt anzufangen. Auf lange Sicht wird es ziemlich sicher nichts...Fletcher schrieb:
Das schöne an der IT ist, daß von Anfang an absolute Gleichberechtigung herrscht: Während man bei vielen Berufen eine höhere Ausbildung oder gar ein Studium vorweisen muß, spricht es für sich wenn es 14-Jährige gibt die in den Pentagon-Computer eindringen können (nur ein symbolisches Beispiel). Der 14-Jährige hat per sofort bewiesen, daß er über stark überdurchschnittliche Computerkenntnisse verfügen muß.
So hab ich vor 15 Jahren auch gedacht... Erstens, vergiss die Märchen, wo irgendwelche 14 jährigen Genies irgendwas hacken. Und zweitens würde ich niemanden einstellen, der kein Studium vorweisen kann. Ja, es gibt Leute, die ohne Studium ganz brauchbar programmieren können (und es gibt welche mit Studium, die es überhaupt nicht können). Aber die sind meist noch sehr sehr weit davon entfernt, gute Entwickler zu sein. Ausnahmen sind vielleicht studierte Mathematiker und Physiker mit entsprechender Erfahrung. Aber sicher keine 14 jährigen Schüler oder irgendwelche Amateure, die daheim neben dem Beruf programmieren gelernt haben. Als ich Schüler war, habe ich meine Fähigkeiten als Entwickler auch sehr stark überschätzt. Programmieren können und viele spezielle Kenntnisse zu haben reicht noch bei weitem nicht.
-
Danke Mechanics, für die wohlwollenden Worte.
Mein größtes VBA-Programm besteht aus ca. 2000 Zeilen. Ist jetzt nicht so groß, daß die Gefahr eines Spaghetti-Codes entsteht. Demnächst werde ich aber einen sehr komplizierten Programmteil von Grund auf neu schreiben, weil ich inzwischen wieder selbst dazugelernt habe und es unterm Strich die schnellste Lösung ist. Eine externe Dokumentation gibt es sowieso nicht, nur die Kommentare im Programm-Code.
Wegen dem Client-Server-System: Ich denke vorerst nicht daran eine tatsächlich verkaufbare Software zu entwickeln, denn dazu müßte ich eine Firma gründen, meinen derzeitigen eigentlich gut bezahlten Job kündigen (ich bekomme mehr als offiziell ausgebildete C++ und SQL Programmierer, wenn sie eine entsprechende ausgeschriebene Stelle annehmen würden); dann geht's noch weiter mit Kundensupport und ISO-Zertifizierung. Ich käme vom hundertsten in tausendste, aber all das ist nicht notwendig, denn mein Client-Server-Ding ist für mich nur ein Rahmenprogramm innerhalb dessen ich mir C++ und SQL selbst beibringe.
Sobald ich einen 2. oder 3.Programmierer beiziehe, geht es nicht doppelt oder 3-fach so schnell voran sondern eben weniger, weil man sich untereinander absprechen muß (Scrum?). Ist wie bei zwei Grafikarten im SLI-Verbund - läuft bestenfalls 80% schneller aber nicht 100% schneller.
Und wer eine rennomierte Client-Server Software sucht, kann ohnehin gleich zu SAP gehen. SAP hat 60000 Mitarbeiter, für irgendwas müssen die gut sein. Es wäre vermessen zu glauben als Einzelner alleine so eine Software zu erstellen.
-
Fletcher schrieb:
Und wer eine rennomierte Client-Server Software sucht, kann ohnehin gleich zu SAP gehen. SAP hat 60000 Mitarbeiter, für irgendwas müssen die gut sein. Es wäre vermessen zu glauben als Einzelner alleine so eine Software zu erstellen.
SAP Client-Server-Architektur ist der reinste Mist, wenn überhaupt ist das einzige technische gute ihre MaxDB. Außerdem brauchen sie ihre Programmierer nicht für den Kern sondern für die Business-Lösung.
-
Fletcher schrieb:
Ist es nicht.
So eine Aussage macht jetzt mich sprachlos! Ich habe jedenfalls 13 Jahre mit diesem System gearbeitet, und ich sehe was ich sehe. Es gab eine Übergangszeit, wo beide Systeme verfügbar waren und es haben ALLE bis zur letzen Minute mit dem alten System gearbeitet weil schneller.
Du schliesst von einem Programm auf alle Programme.
Das ist nicht klug.
-
Fletcher schrieb:
Wegen dem Client-Server-System: Ich denke vorerst nicht daran eine tatsächlich verkaufbare Software zu entwickeln, denn dazu müßte ich eine Firma gründen, meinen derzeitigen eigentlich gut bezahlten Job kündigen (ich bekomme mehr als offiziell ausgebildete C++ und SQL Programmierer, wenn sie eine entsprechende ausgeschriebene Stelle annehmen würden); dann geht's noch weiter mit Kundensupport und ISO-Zertifizierung. Ich käme vom hundertsten in tausendste, aber all das ist nicht notwendig, denn mein Client-Server-Ding ist für mich nur ein Rahmenprogramm innerhalb dessen ich mir C++ und SQL selbst beibringe.
Wie gesagt, was ich gesagt habe, bezieht sich nicht nur auf Programme, die man verkaufen will, sondern auch auf interne Lösungen. Als Lernprojekt wärs zwar ok, aber vielleicht gibts auch bessere Projekte zum Üben. Das Problem das ich sehe ist, dass du dabei zwar Programmieren lernen kannst (C++, SQL), aber von der Architekturseite kaum die Möglichkeit hast, eine wirklich brauchbare Plattform aufzuziehen. Du fängst also etwas an, wo von vornherein klar ist, dass es wenig durchdacht und suboptimal ist.
Fletcher schrieb:
In der Datenbank sind nicht nur die zu verwaltenden Daten abgelegt, sondern es gibt zusätzlich eigene Tabellen, wo in Form einer (noch zu erstellenden) Skriptsprache, der Client-Anwendung (.exe) mitgeteilt wird, welcher Text und welche Standard-Steuerelemente wo zu zeigen sind, und wie nach erfolgtem "Transmit" mit den eingegebenen Daten zu verfahren ist.
Das hört sich so nach den ersten Gehversuchen einer solchen Plattform an. Wird aber nicht der Weisheit letzter Schluss sein. Kann sein, dass nach paar Jahren Arbeit an deinem Programm dann immer mehr neue Ideen hast, wie man das flexibler und eleganter machen könnte. Vielleicht wirst du dann auch ähnliche Systeme kennenlernen und schauen wie die aufgebaut sind. Vielleicht wirst du dann auch völlig anders denken und merken, dass ASP.NET oder J2EE doch ganz interessante Plattformen sind, die dir weit mehr bieten, als deine erste "naive" Lösung.
Das soll jetzt kein Plädoyer für ASP.NET oder J2EE sein, ich würde keine Empfehlung abgeben, ohne mich intensiv in das Problem reingedacht zu haben (wobei ich persönlich bei einer Webanwendung zu J2EE und einem Application Server zu .NET tendieren würde, und wirklich nur bei einer ganz komplexen Anwendung mit sehr viel serverseitiger Logik zu C++, was ich hier nicht sehe). Ich will nur darauf hinweisen, dass andere schon auch mal deine Probleme hatten und vielleicht weitergedacht haben und dein Konzept hört sich wirklich ein bisschen naiv an.
Es passt auch zu deinem anderen Thread über "Personenabhängigkeit bei Software". Stell dir vor, du stellst das Progamm fertig und es funktioniert (durchaus realistisch) und wird eingesetzt (in deiner Firma wohl unwahrscheinlich?) und alle sind eine Weile zufrieden. Dann bist du weg und es läuft eine Weile und es sammeln sich neue Anforderungen an. Oder du bist vielleicht nicht ganz weg, hast aber keine Zeit oder kennst dich nicht gut genug aus, um die Anforderungen umzusetzen. Dann wird eine Softwareschmiede beauftragt, sich das Programm anzuschauen. Glaubst du, die werden mit sowas weitermachen? Die werden sicher sagen, was für ein Unsinn, sammeln wir zuerst mal die Anforderungen, dann machen wir ein Konzept auf der Basis bewährter Standardtechnologien. Aber vielleicht wollen die das gar nicht mit .NET oder J2EE umsetzen sondern wollen tatsächlich dein Client-Server System wiederverwenden oder erweitern. Dazu müsste die Basis entsprechend leistungsfähig sein. Eine Scriptsprache, die die Zuordnung von Datenbankspalten auf Steuerelemente in der GUI beschreibt, reicht bei weitem nicht aus. Die denkbaren neuen Anforderungen sind praktisch grenzenlos und dein Basiskonzept scheint mir sehr eingeschränkt zu sein. Somit würdest du nur eine Insellösung schaffen, die kaum erweiterbar ist.
-
@Zeus: Soll mir recht sein, daß du SAP als "Mist" bezeichnest; ich bin weder Freund noch Feind davon. Sowas artet aber sowieso in Glaubenskriege aus: Bentley vs Rolls-Royce, Boeing vs Airbus, Apple vs Microsoft, Fleischesser vs Vegetarier usw...
@Mechanics: Natürlich ist mein Ansatz "naiv". Zu Beginn möchte ich es absichtlich so einfach halten. Ich will einmal sehen wieviel Potential mein Ansatz überhaupt hat; sollten schon die ersten Gehversuche hinken, werde ich es sowieso mit etwas anderem Versuchen.
Bei mit meiner Idee geht es neben der Transaktionsgeschwindigkeit vor allem um den Benutzerkomfort bei der Eingabe: Ich möchte z.B. daß der einloggende User seine Short-Keys selbst bestimmen kann. Häufige Wörter und Phrasen sollen ebenfalls individuell einer Taste zugeordnet werden können. Geht alles im IE nicht!
Das Endprodukt so superflexibel wie möglich zu machen mündet am Ende darin, daß ich erst wieder eine Sprache wie ASP.NET entwickle (soferne ich das alleine überhaupt schaffe); das will ich bewußt vermeiden.
Bei unserem früheren uralt System, war die wesentliche Limitierung jene, daß man nur 80x25 Text anzeigen konnte. Die Schrift war pixelorientiert und immer scharf lesbar - ohne verschwommenen Clear-Type-Scheixx. Änderte man die Fenstergröße wurde automatisch die Schriftart geändert, sodaß die Buchstaben immer im richtigen Verhältnis zur Fenstergröße standen.Ich gehe gar nicht davon aus daß meine Anwendung irgendwann in der Praxis zum Einsatz kommt (nur Lern- und Übungsprojekt), deshalb ist es momentan meine 195.Sorge ob das Konzept in ferner Zukunft erweiterbar ist oder nicht.
Es kann ja z.B. sein, daß man mit ASP.NET und/oder J2EE in 10 Jahren in einer Sackgasse landet, die jetzt noch nicht ersichtlich ist. Sowas müßte ich bei jeder Plattform befürchten und dürfte daher mit gar keiner beginnen; Zurück zu Bleistift und Papier?
-
Fletcher schrieb:
Geht alles im IE nicht!
Ja ne, is klar.
Fletcher schrieb:
Zurück zu Bleistift und Papier?
Das sollte zumindest Dein Anfang sein!
-
Du wirst zu vieles in einen Topf
Es ist erstmal sehr unwahrscheinlich, dass man mit .NET oder J2EE in einer Sackgasse landet, das sind erstmal nur sehr allgemeine Frameworks, mit denen man alles machen kann. Wenn mit der Zeit neue Ideen entwickelt werden, können sie in die Frameworks integriert werden. .NET hat sich z.B. recht schnell weiterentwickelt und es wurden interessante Konzepte wie Linq oder PLinq aufgenommen. Natürlich könnte man aber darüber diskutieren, ob die ganzen Produkte an sich überleben, solche Diskussionen hatten wir ja schon. So gesehen wärs dann zukunftssicherer, alles "von Hand" in C++ zu implementieren. Was du ja auch machen kannst. Mir gings eigentlich primär überhaupt nicht um die Programmiersprache/Framework, sondern um dein Grundkonzept und die Architektur.
Ich sags dir nur, weil ich das alles auch schon selber durchgemacht habe. Auch oft mit "kleinen" Eigenentwicklungen angefangen, bis das alles immer schneller ausgeartet ist und ich bei jeder kleinen Änderung alles umbauen musste und irgendwann auch einsehen musste, dass die Idee an sich nicht ausgereift war. Ich will dich nicht davon abhalten, was zu schreiben oder zu lernen. Aber du solltest dir viel mehr Zeit nehmen, über dein Konzept nachzudenken. Versuch das im Detail durchzudenken, fang nicht einfach an zu implementieren. Du wirst (hoffentlich) merken, dass das nicht der Weisheit letzter Schluss ist.
-
Ich sags dir nur, weil ich das alles auch schon selber durchgemacht habe....
Ja, Danke. Freundlich gemeinte Hinweise nehme ich gerne zur Kenntnis :xmas1:
Bezüglich der Konzepte: Eine Zeit lang war das Konzept "wir speichern nur die letzten beiden Ziffern der Jahreszahl" ganz gut, bis kurz vor dem Jahr 2000 alle die Panik bekamen....
Oder: "Mehr als 640 kByte werden sie nie brauchen"....
Später: 32 Bits werden lange für die Speicheradressierung ausreichen. (Warum noch findet man jezt ständig x86- und x64-Versionen?)Ich will damit sagen, daß so wie manche heute irgendwen belächeln, wegen dem was vor 10-20 Jahren programmiert wurde, werden die gleichen Leute in 10-20 Jahren von anderen belächelt werden. Klopft euch also nie zu viel auf die Schultern!
Wenn man immer alles früher gewußt hätte, hätten ja schon die alten Römer auf Computern gearbeitet....
-
Fletcher schrieb:
Ich will damit sagen, daß so wie manche heute irgendwen belächeln, wegen dem was vor 10-20 Jahren programmiert wurde, werden die gleichen Leute in 10-20 Jahren von anderen belächelt werden.
Ja schon, aber was du machen willst wäre in etwa so, wenn du jetzt sagen würdest, niemand braucht mehr als 640KB Speicher, obwohl alle schon längst wissen, dass es nicht wahr ist
Wenn alle schon ein Stück weiter sind, macht es keinen Sinn, komplett von vorne anzufangen, ohne zu verstehen, was die anderen schon erreicht haben. Aber fang ruhig einfach mal an, du willst ja was lernen, und das wirst du wohl auf jeden Fall.
-
Um ehrlich zu sein:
mach das ganze mit PHP und Symfony.Das ist sehr einfach und du hast innerhalb eines produktiven Wochenendes einen funktionierenden Prototyp.
-
Fletcher schrieb:
Ich will damit sagen, daß so wie manche heute irgendwen belächeln, wegen dem was vor 10-20 Jahren programmiert wurde, werden die gleichen Leute in 10-20 Jahren von anderen belächelt werden. Klopft euch also nie zu viel auf die Schultern!
Wenn man immer alles früher gewußt hätte, hätten ja schon die alten Römer auf Computern gearbeitet....Du hast von der Materie keine Ahnung...
Du interpretierst diese Sachen allesamt komplett falsch.PS:
Niemand erwartet dass Software die man jetzt schreibt 1:1 in 20 Jahren noch modern ist. Aber wenn das Design der Software gut ist, dann laeuft sie in 20 Jahren noch - mit entsprechenden Anpassungen natuerlich, die aber eben durch das gute Design moeglich waren.OS X wird gemeinhin als ein sehr modernes Betriebssystem gesehen. Aber das Design von OS X enstammt direkt aus NeXTSTEP, welches 1989 released wurde. dh das Design von OS X ist bereits mehr als 20 Jahre alt und immer noch Top.
Der Kernel von Windows wurde 1993 veroeffentlicht - dh auch hier ist das Urdesign 20 Jahre alt.
Es gibt unzaehlige solcher Beispiele - gutes Design ist insofern zeitlos, als dass es sich an alle gegebenheiten anpassen laesst.
