Manchmal funktionieren ein paar Snippets nicht. Ich vermute es liegt daran wie ein Theme über nicht immer sehr gradlinige Wege überschrieben und erweitert wurde.
Z.B. steht dann "orion.footer.certificates" auf der Seite, obwohl die Snippets korrekt für alle Sprachen in der Administration gefunden werden. Also an sich sollte es dann ja funktionieren.
Lösung: Einmal den Übersetzungen ein 'X' anhängen, speichern, das 'X' wieder entfernen und erneut speichern. Dann sind sie in der Storefront auch richtig.
Weil sie dann aus der Datenbank geladen werden und nicht aus dem Theme/Plugin/App.
Manchmal sind ganz einfache Dinge sehr komplex. CSS-Ellipsis ist an sich einfach. Aber mit Flexbox kann es plötzlich dazu kommen, dass es einfach nicht funktioniert. Alles funktioniert nur die "..." sind nicht zusehen, weil es einfach alles zur Seite rausragt und die Breite hält.
Ich habe einmal versucht Docker mit der WSL 2 based engine laufen zu lassen. Es war alles extrem langsam und alles dauerte ewig. Vorher lief Docker selbst auf einem langsameren Notebook ganz gut. Das hier beschreibt das Problem sehr genau. Am Ende bin ich auch wieder auf die Hyper-V Engine zurück gewechselt. Meine Daten in das WSL Dateisystem zu kopieren gefiel mir nicht wirklich, weil ich von Windows aus mit PHPStorm darin entwickel. Hyper-V deinstallieren klingt zwar auch interessant und ich könnte Virtual Box wieder verwenden.. aber so ganz traue ich dem nicht.
Heute Nacht um 1:00 kam eine Email, dass bei einer GMX-Adresse das Passwort geändert worden sei. Man konnte sich nicht mehr anmelden, also war die Email korrekt.
Das Problem ist nun: 0900-Hotline ist über Mobile und VoIP nicht erreichbar. Live-Chat, Twitter, Email... gibt es alles nicht. Die einzige Hotline die geht, ist nur für zahlende Kunden.
Das Passwort selbst ändern würde gehen, wenn die alte dort angegebene Email-Adresse von Hotmail noch existieren würde. Bei den meisten Benutzern wird wohl eine Email-Adresse angegeben sein, die nicht mehr im Zugriff ist. Handy-Nummer werden viele auch nicht angegeben haben.
Zum Glück war die Email Adresse nicht wichtig und alt.. aber bei einer aktuellen und genutzten Adresse wäre das jetzt eine wirklich Katastrophe, weil davon auszugehen ist, dass alle möglichen Dienste, wo die Adresse zum Login verwendet wurde, gefährdet sind und man keine Möglichkeit hat mit GMX in Kontakt zu treten, um den Account sperren zu lassen.
Hat wer eine Lösung bzw einen alternativen Kommunikationsweg als die 0900-Nummer?
Bei den wichtigen Adressen ist, jetzt auf jeden Fall Handynummer und eine Email-Adresse, die 100%ig unter meiner Kontrolle ist, angegeben und mal gucken, ob man nicht von GMX weg geht mit den dort vorhandenen Adressen.
Bei Yahoo hatte ich trotz alles Security-Leaks nie solche Probleme, wohl auch weil ich immer Weiterleitungen davor schalte.
Wenn der Fehler auftritt, dass ein Windows-PC die Domain in Netzwerk nicht finden kann und keine Verbindung zum Active Directory-Domaänencontroller hergestellt werden kann, kann es helfen das IPv6-Protokoll zu deaktivieren.
Sollte der PC dann in der Domain registriert sein, sollte man das IPv6 wieder aktivieren können und es sollte alles ohne Probleme funktionieren.
Weil es ja Probleme mit TLS-SNI-01 gibt, kann man auch einfach eine Domain neu installieren. Dann wird ein neuer Eintrag mit dem Postfix 0001 angelegt.
Wenn beim Versuch Shopware zu updaten, der Prozess-Dialog ewig läuft und dann irgendwann das Backenend einfach neu lädt, kann es am media/ Verzeichnis liegen. Ich hab, als das Problem bei meinem lokalen Entwickler-Shop auftrat erst einmal alle leeren Verzeichnisse entfernt mit
sudo find media/ -type d -empty -delete
Dann noch mal die Rechte für die Dateien neu gesetzt (wegen über SCP hochgeladene Plugins oder so) und nachdem das Backend zwei mal neugeladen wurde, lief das Update sofort und ohne Probleme an. Hat mich zwar einige Stunden gekostet, bis alles soweit war, aber endlich wieder Updaten zu können ist es auch wert.
Wenn man mit dem XML-Parser von jcabi-xml arbeitet und der direkt am Anfang der Datei behauptet, es würde nicht nach einer XML aussehen, kann es am UTF8-BOM liegen.
Ich hatte einfach keine Lust eine neue Modul-Version in meinen lokalen 10er zu basteln. Also auch wenn man seit JBoss 7 an sich Pause hatte und erst jetzt wieder mit WildFly 10 angefangen hat... es sind immer noch genau die selbe Art von Problemen die einen Ärgern.
Man hört es ja immer im TV, es wird viel versprochen was die Geschwindigkeit bei Internetleitungen
angeht, aber am Ende ist das Internet sehr viel langsamer. Es wird dann immer dazu aufgerufen, dass man selbst seinen Internet-Anschluss mit einer der dort genannten Websites testen sollte, um heraus zu bekommen ob auch bei einem selbst das Internet zu langsam ist.
Viele machen das auch schon gleich prophylaktisch, wenn der Anbieter z.B. die Bandbreite erhöht oder ähnliches. Dann kommt oft der Schock. Das geschah auch bei jemanden vor ein paar Tagen.
Bei dieser Person wurde von 16MBit auf 50MBit erhöht. Änderung wurde durch geführt und bei der Messung über eine Internetseite kam heraus dass nur 8MBit im Download ankamen. Auch nur 8Mbit beim Upload, wo es eigentlich 25Mbit sein sollten. Der Ping war ok.
Der Anbieter verhielt sich wie den TV-Sendungen immer beschrieben und behauptete es wäre alles ok und die 50MBit wären verfügbar.
Wer mal mit dem Computerproblemen von privaten Personen zu tun hatte wird die eine Regel kennen, die man immer befolgen sollte: "Glaube dem Kunden nichts, was du nicht selbst gesehen hast und lasse dich nicht mit Ausreden abwimmeln, es wird dir nur unnütze Aufwände bescheren."
Also über Teamviewer wurde das Problem bestätigt.. bzw die Messung wurde wiederholt und zeigt ein entsprechendes Ergebnis. Wichtig ist jetzt verlässliche Werte zu bekommen, also heraus zu finden mit welcher Geschwindigkeit der Router die DSL-Verbindung ausgebaut hat und synchronisiert hat. Natürlich war das Passwort zur Fritzbox unbekannt. Aber einmal Strom trennen und auf Werkseinstellungen zurück setzen hilft. Die wenigstens Personen haben Port-Weiterleitungen eingestellt, also kann bis auf ein paar Telefonnummernzuordnungen eigentlich nichts verloren gehen.
Die Fritzbox sage 63MBit down und 30MBit up. Mehr als an sich erwartet wurde. Bloß weil man diese Bandbreite zugeteilt bekommt, bedeutet es natürlich nicht, dass man sie auch komplett nutzen kann. Fehlerkorrekturen im Protokoll und ähnliches kosten natürlich auch Bandbreite.
Der normale Benutzer ist jetzt natürlich überfragt, auf der einen Seite funktioniert es nicht wie es gerne hätte und auf der anderen Seite wird der Anbieter sich quer stellen und sich auf die Angaben im Router berufen. Was kann er also nur machen? Immer wieder beim Anbieter anrufen, die werden ihn abwimmeln oder sagen, dass sie es noch mal prüfen werden, aber am Ende wird nichts passieren. Verstanden wird sich der Benutzer bei bestimmten nach Jahreszahlen benannten TV-Sendungen fühlen, die ihm auch klar machen, dass man den Anbieter nur genug unter Druck setzen muss, damit der das Problem behebt.
Das ist für den Benutzer leider etwas unschön, aber Ende leider auch genau die Lösung, die den Benutzer zufrieden stellen wird. Der Anbieter ist Schuld, man selber kann nichts tun und ist nur ein Opfer. Benutzer kennen sich mit Computern meistens sehr wenig aus und sind zu meist auch sehr Stolz auf ihre Leistung sich einen PC oder ein Notebook gekauft zu haben. Sie haben sich beraten lassen, dann alles abgewogen und das für ihre Zwecke beste und günstigste Gerät gekauft. Meistens haben sie das Gerät dann auch selbst mit dem Router verbunden. Bei WLAN ja nicht so einfach mit Key, aber immer noch besser als irgendwelche Kabel durch die Wohnung zu verlegen.
Dies ist wirklich eine gute Leistung für jemanden, der eigentlich keine Ahnung davon hat warum es am Ende eigentlich alles funktioniert und was dieses ominöse WLAN überhaupt ist. Sein Kabelloses Internet funktioniert und er ist glücklich und stolz. 2 wichtige Faktoren... besonders der zweite. Keiner mag es, wenn man viel Zeit und Energie in etwas investiert hat und dann jemand kommt und sagt einen, dass man ja sehr bemüht war.. also.. am Ende doch nur Rotz raus kam. Dann ist man weder glücklich noch stolz.
Wir messen also über zwei Netzwerke, einmal das vom Anbieter und einmal das vom Router zum Gerät, dass meistens WLAN sein wird. Jetzt sprechen alle Indikatoren (Anbieter-Messung und Router) dafür, dass das Netzwerk des Anbieters nicht das Problem ist. Dem Benutzer wird zu 99% nicht mal klar sein, dass das WLAN kein Teil des Anbieternetzwerkes ist, sondern ein 2. Netzwerk, dass ganz allein ihm untersteht und für dass er auch die Verantwortung trägt.
WLAN ist praktisch, aber bringt viele Probleme mit sich:
* Wände können das Signal stark stören
* Wenn über USB angeschlossen sollte man keinen langsamen USB-Standard nutzen
* Viele WLAN Geräte blockieren sich gegenseitig
* Es sind meistens kleine und schwache Antennen verbaut
Das sind alles Probleme, die so sind und die der Physik und Implementierung geschuldet sind. WLAN ist ein Standard und es wird auch bei den Routern nur WLAN dieses Standard angeboten. Mit dem Kauf des Routers sollte der Benutzer sich dieser Probleme bewusst sein und auch dass er auf diese Dinge achten muss, um ein gut funktionierendes WLAN zu betreiben.
Wenn das Internet zu langsam ist wird sich das Problem zu meiner Erfahrungen nach zu 80% beim Anwender finden lassen. Beim normalen Surfen fällt nichts auf und erst wenn man solche Messungen durchführt kommt heraus dass die Datenrate, die beim Gerät ankommt, zu gering ist. Benutzer hören das überhaupt nicht gerne. Die sind glücklich wenn die Schuld beim Anbieter liegt. Das sie das Problem selbst verursacht haben, wollen sie nicht hören, gerade wenn sie alles selbst eingerichtet haben. Benutzer die schon beim Kauf um Hilfe fragen, haben kein Problem damit, dass die Probleme z.B. durch einen alten WLAN-Stick verursacht werden. Die anderen halten zu Viel auf ihr Werk, als dass sie Zugeben wollen, dass sie nicht wussten was sie taten und es wohl deswegen teilweise falsch gemacht haben. Das sind die Personen die man dann im TV sieht, weil gerade Hotlines wissen wie solche Benutzer reagieren, wenn man denen sagt, dass das Problem wohl bei denen liegt und man da nicht für Zuständig ist, wenn der Benutzer bei sich zu hause was falsch eingerichtet hat.
Hier nochmal eine kleine Checkliste, wie man richtig überprüfen kann, ob das Problem im eigenen Netzwerk zu suchen ist:
* Ein LAN-Kabel benutzen und direkt mit dem Router verbinden
* Ein PC/Notebook nutzen das "sauber" ist. Am besten von jemanden der viel Spiele im Internet spielt.. am besten Shooter.. die achten darauf dass deren System
keine Probleme beim Netzwerk hat
Wenn sich damit nun heraus stellt, dass es wirklich nicht am Anbieter liegt:
* WLAN richtig eingerichtet? (Anleitung lesen, jemanden fragen der sich damit auskennt)
* wie gut ist der Empfang? (Repeater kaufen, extra Antenne kaufen)
* Wie alt ist die verwendete Hardware? (was neues Kaufen.. sich beraten lassen.. nicht im Geschäft)
* Was ist an Software installiert? (Es gibt Software, die PCs schneller und sicherer macht.. XPAntiSpy, TuneUp, etc... zu 99% sind diese Programme Verursacher der Probleme.. deinstallieren und nie wieder installieren)
Wenn man kein LAN-Kabel über große Strecken verlegen mag, helfen Powerline Adapter, die LAN über das hausinterne Stromnetz ermöglichen. Was sehr gut funktioniert.
Sollte das Problem beim Anbieter liegen, diesen bitten die Leitung einmal zu überprüfen oder einen Techniker vorbei zu schicken. Immer kooperativ und nett sein.
Probleme bei denen müssen nicht immer bekannt sein und können Hinweise für den Anbieter auf defekte Hardware oder Kabel sein. Teilweise auch in Bereichen, wo der Anbieter selbst keinen Einfluss hat.
Es gibt heute so viel Bandbreite... und ob ich mit 30MBit Downloade oder mit 50Mbit ist nur ein Unterschied in den Minuten, die ich benötige für den Download, aber der Traffic beim Anbieter wird gleich bleiben. Es würde ihn nur Kosten sparen, wenn er auf wenige MBit herunter drosselt um mich davon abzuhalten viele Downloads durch zuführen.. so 1-2Mbit. Wenn man >=8Mbit hat ist es unwahrscheinlich, dass es an einer Drosselung der Leitung liegt.
Ich wollte nur mal kurz Magento 2 installieren (XAMPP und Windows 10 Pro). Aber das Adminpanel wollte nicht funktionieren und auch viele CSS und JS Dateien wurden nicht gefunden.
Ich habe eine Lösung aus zwei Lösungen im Internet gefunden, mit denen es am Ende dann doch alles lief.
Zuerst habe ich alles bis auf die htaccess aus pub\static gelöscht.
Dann die app\etc\di.xml editiert. Die Strategie von Symbolic-Link auf Copy geändert.
Und dann ein PHP Script ausgeführt, dass alles noch mal neu anlegt. bin\magento.
3 Monitore anzuschließen, wenn schon 2 dran sind, klingt jetzt erst einmal nicht nach einem Problem.. dachte ich auch. Das Setup sollte folgendes sein: Über HDMI ist der Fujitsu Haupt-Monitor angeschlossen. Über einen eine DVI auf VGA Adapter läuft noch ein älterer Medion Monitor. Nun sollte ein Wacom Cintiq 13HD angeschlossen werden, das nur einen HDMI-Stecker angeschlossen werden kann. Dafür wurde ein Mini-Displayport auf HDMI Adapter verwendet.
Das Problem ist, dass man den ersten Monitor nicht darauf spiegeln kann, weil der Monitor 1920x1200 und das Grafik-Tablett nur 1920x1080. Das Erweitern des Desktops klappte nicht, da sich dann immer einer der beiden anderen Monitore abschaltete.
Das Problem war am Ende der passive DisplayPort Adapter. Mit diesem aktiven Adapter klappte dann alles. Bei einer AMD Radeon 7950 und anderen der Serie kann man wohl nur 3 Monitore oder mehr betreiben, wenn alles über 2 Monitor über native DisplayPort Verbindungen angebunden sind. Ein passiver HDMI Adapter erfüllt das wohl nicht und wird wie eine HDMI Verbindung behandelt und nicht wie eine DisplayPort Verbindung.
Wer erstmal eine Windows 10 Version installiert hat und erst später den Key eingeben möchte, könnte das Problem haben, dass der Button im "System"-Fenster nicht reagiert.
Dann kann das hier helfen:
slui.exe 3
Damit wird ein Fenster geöffnet in das man den Key direkt eingeben kann.
Nachdem ich noch bei einem Abschiedsessen mit meinen alten Kollegen, doch noch mal auf der Thema der Entwicklungsgeschwindigkeit und Qualität an dem Abend gekommen bin, werde ich mir dieses Thema hier doch mal annehmen. Es ist ein kompliziertes Thema, dass keine richtige einzelne richtige Lösung kennt, aber dafür Raum für viele Fehler bereit hält. Ich stütze mich jetzt einfach mal auf 10 Jahre Erfahrung in der Softwareentwicklung und der Mitarbeit in Teams, die eben auch mit diesen Problemen zu kämpfen hatten und auch noch haben. Denn auch wenn man Lösungen kennt, muss man den Weg immer noch gehen.
Neben der verlorenen Zeit stellen diese Probleme auch für die Entwickler eine nicht zu unterschätzende Belastung da.
Frameworks vs eigenen Code
Einer der größten Fehler wurde gleich am Anfang gemacht. Es sollte schnell los gehen und da wurde auf Abstraktion und der Suche nach vorhandenen Lösungen verzichtet. Es wurde alles auf der untersten Ebene begonnen. Also keine Kapselung oder ähnliches. Entitäten-Objekte wurden direkt vom Service an den Client geschickt. Eine allgemeine Kommunikationsstruktur zwischen den beiden wurde nicht entwickelt.
Oberflächen und Logik wurden einfach zusammen in eine Klasse geschrieben. DTOs, DAOs und DataBindung waren aber schon da keine neuen Konzepte mehr. Das alles führte dazu, dass man sich mit EJB und SWT jeweils auf der untersten Ebene auseinander setzen muss, selbst um einfache Oberflächen und Service zu implementieren.
Es entwickelte sich zu der Vorgehensweise, dass man es lieber alles schnell selbst machten sollte, als externe Frameworks und Libs zu verwenden. Wenn man nur genug eigene Dinge implementieren würde, würde am Ende schon ein fertiges Frameworks dabei heraus kommen. Das Ein Framework in seiner Gesamtheit durchdacht sein muss und eine gewisse Konsistenz in der Benutzung und im Verhalten zeigt, war dabei egal. Die Idee, jeder Entwickler würde mal so nebenbei für sich ein oder zwei Komponenten entwickeln und wenn man nach einem Jahr alles zusammen wirft, würde ein fertiges GUI-Framework heraus kommen, war zu verlockend und so wurden auch alle komplizierteren Ansätze, die so etwas beachten wollten, als nicht notwendig erachtet.
Wenn man ein auch nicht mehr ganz so neues AngularJS nun betrachtet, dass einmal für die GUI-Elemente auf HTML5 setzen kann und für die Oberflächen eine sehr gute und flexible Template-Engine mitbringt, merkt man erst wie viel Zeit allein mit dem Kampf des SWT-Gridlayouts oder der selbst gebauten Input-Box für Zahlenwerte verbracht wurde.
Das Problem, dass zu viel grundlegende Technologie selbst entwickelt wird und dann alles zu sehr mehr der eigentlichen Anwendungslogik verzahnt wird, ist in so fern ein wirklich großes Problem, als dass hier sehr schnell sehr viel Code produziert wird und durch die fehlende Abstraktion Änderungen mit fortlaufender Zeit immer schwieriger werden. Am Anfang müsste man einige Klassen neu schreiben, aber ein Jahr später, kann man schon die halbe Anwendung weg werfen. Ob man das vielleicht auch tun sollte, werde ich später noch mal ansprechen.
Jedenfalls braucht man entweder jemanden aus dem Team der das Framework für das Team(!) entwickelt und auch die Zeit dafür bekommt oder aber man muss einige Woche am Anfang einplanen, um ein geeignetes Framework zu finden.
Hier lauter schon der nächste Fehler. Oft wird eine Person dazu abgestellt, sich über Frameworks zu informieren und eins oder zwei vorzuschlagen. Da aber viele Entwickler damit arbeiten sollen, sollten auch alle bei dem Findungsprozess mit wirken können. Jeder achtet auf andere Dinge und erkennt Vor- oder Nachteile wo andere nur eine weitere aber nicht so wichtige Komponente sehen. Und auch hier werde ich auf die Probleme,
die hierbei entstehen können, später noch mal eingehen. Es hängt alles zusammen und beeinflusst sich gegenseitig, so führen Probleme zu anderen Problemen.. vielleicht.
Vertrauen in die Technologie muss da sein
Gehen wir mal davon aus, dass wir nun jemanden haben, der das Framework entwickelt oder man eines gefunden hat, das auf dem Papier echt toll aussieht, aber viele Fehler hat und Lösungen dafür kaum zu finden sind.
Das kann an Fehler, einer schlechten Dokumentation oder einem eher ungewöhnlichen Benutzungskonzept liegen. Aber am Ende besteht das Problem, dass die Entwickler dem Framework nicht vertrauen. Das für dann oft auch zu Punkt 1 zurück, in dem dann lieber eine Funktionen und Methoden geschrieben und verwendet werden, weil man diesen mehr traut als dem Framework. Weiter werden dann mindestens 2 Entwickler das Selbe nochmals neu implementieren, aber natürlich dann so verschieden, dass man nicht eines davon wieder abschaffen könnte. Wenn diese mindestens Doppelung an gleicher Funktionalität auffällt, muss das Framework so angepasst werden, dass es mindestens seine und die beiden anderen Funktionsweisen abbilden kann und hoffentlich dabei nichts kaput geht. Dadurch haben wir dann wieder eine große Inkonsistenz Framework, weil es plötzlich Sachen machen soll, die einfach anders sind und anderer Herangehensweisen haben. Weil es inkonsistent geworden ist kommen die Entwickler nicht mehr wirklich damit klar und schreiben sich im besten Falle eine eigene Abstraktionsschicht für das Framework, oder versuchen es wieder zu umgehen, was dann am Ende mindestens die 4. Implementation für die selbe Funktionalität mit sich bringt.
Ich ziehe hier mal wieder AngularJS als positives Beispiel heran. Wenn man ein Problem hat, wird man eine Lösung im Internet finden. Irgendwer hatte das Problem schon und irgendwer hat den Fehler schon behoben, die richtige Vorgehensweise noch mal erklärt oder eine passende Direktive geschrieben. Es stellt sich nicht die Frage, ob etwas an sich möglich ist. Es ist möglich und man versucht es erst einmal und wenn es nicht funktioniert, guckt man eben wie die anderen es gelöst haben. Im Notfall gibt es immer noch das native JavaScript mit document.getElementById().
In Java versuchen Frameworks einen oft komplett in sich gefangen zu nehmen und alle anderen Wege als den eigenen unmöglich zu machen. Durch Interfaces die eingehalten werden müssen, klappt es ganz gut. Das verhindert, dass andere Lösungen entwickelt werden, die das Framework um gehen. Aber es schränkt oft auch mehr ein als es hilft. Das Framework soll dem Entwickler helfen und nicht über ihn bestimmen. Als Entwickler mag man es nicht, nur die Konzepte und Denkweisen eines anderen unterworfen zu sein, der, wie man schnell merkt, das ganze nicht mit dem Anwendungsfall im Hinterkopf entwickelt hat, den man selber gerade umsetzen möchte.
Deswegen muss ein Framework alles bieten und so flexibel sein, dass auch Abweichungen vom Konzept möglich sind und sich direkt ins Framework integrieren lassen, dass es zu einem Teil des Frameworks wird. So wird verhindert, das Entwickler das Framework umgehen oder eigene Lösungen einbauen, die zwar den Anwendungsfall entsprechen aber sich komplett als Fremdkörper im Framework präsentiert. Das wichtigste ist aber eine gute Doku und eine zentrale Stelle wo man Probleme zusammen beheben kann. Für ein eigenes Framework ist daher ein Forum im Intranet vielleicht gar nicht so verkehrt. Man kann suchen, nachlesen und diskutieren. Auch weiß der Entwickler des Frameworks, wo er die Dokumentation verbessern oder nochmal überarbeiten sollte. Auch werden Ansätze etwas neu zu schreiben oder zu umgehen schneller erkannt und es kann mit Aufklärung oder Fehlerbehebung und neuen Features darauf reagiert werden.
Ich habe auch schon erlebt, dass ich von einer Lösung erfahren habe, wie man etwas im Framework bewerkstelligen kann und ein Ergebnis erhält wie man es möchte und das auch schon von einige Entwicklern so eingesetzt wurde und die auch ganz Stolz auf diese Lösung waren. Das Problem war nur, dass das Framework an der Stelle eigentlich genau das liefern sollte, was die über Umwegen dann auch bekommen haben und eine einfache kleine
Meldung bewirkt hätte, dass aufgefallen wäre, dass es ein einfacher Bug im Code war, der dann auch in 5min behoben war. Aber dadurch dass eine alternative Lösung jetzt ein falsches Ergebnis erwartete, war es viel Arbeit alles mit der Fehlerfreien Komponente des Frameworks wieder zum laufen zu bekommen.
Da fehlte dann auch das vertrauen ins Framework. Denn wenn man Vertrauen hat und etwas nicht wie erwartet funktioniert, geht man von einem Bug aus und nicht von einem normalen Verhalten, dem man selbst entgegen wirken muss.
Entscheidungen überdenken und schnell reagieren
Manchmal klingt etwas sehr gut und die Beispiele liefen gut und die Tutorials im Internet ging schnell von der Hand. Entität anlegen, laden, ändern, löschen und eine Liste der vorhandenen Entitäten laden. Alles super.
Aber dann kommt die Komplexität der echten Welt, wo man nicht nur Listen lädt und etwas hinzufügt oder ein Element hinzufügt. Hier beginnen Probleme und manchmal zeigt sich erst hier, ob dass alles wirklich so gut war wie gedacht. Bei JavaFX kann ich einfache DTOs in Tabellen verwenden. Wenn sich aber ein Wert in einem der DTOs ändert wird es nur erkannt, wenn es ein Property ist. Das ist dann plötzlich ein Sprung von "geht ja ganz einfach" zu "jetzt muss alles in Properties umkopiert werden und die normalen Getter und Setter reichen nicht mehr und also doch wieder eine Wrapper-Klasse bauen."
Oder wir treffen auf das Problem aus Punkt 1. Entweder probieren wir es erst einmal weiter und bauen erst einmal eine Version und damit und gucken dann mal oder aber wir haben uns doch am Anfang darauf festgelegt und die Entwickler haben gerade gelernt damit umzugehen.. oder aber ganz radikal: Zusammen setzen, noch mal Alternativen suchen und wenn es was gibt schnellst möglich wechseln. Erstmal mit einer nicht passenden Technologie oder so einem Framework weiter zu arbeiten ist das schlimmste was man machen kann. Denn es müssen Teile neu geschrieben und angepasst werden und dass sollte man machen, wenn noch nicht zu viel davon entstanden ist. Wenn man ein Jahr wartet, wird es zu viel und die Ansicht wird sich durch setzen, dass fertig machen nun doch schneller geht als "neu" machen. Es wird aber mit den Jahren immer langsamer und langsamer entwickelt und es zeigt sich, dass die Annahme falsch war und man doch schon viel weiter wäre, wenn man gewechselt hätte.
Nie mit etwas entwickeln was Probleme macht ohne das die Möglichkeit gegeben ist, das entwickelte später in einem besseren Technologie-Kontext weiter verwenden zu können. Hier Zahlt sich Abstraktion wie MVC/MVVM oder auch einfaches Databinding dann schnell aus, wenn man mit einfachen DTOs und POJOs gearbeitet hat.
Hier ist aber oft die Angst vor dem Mehraufwand und auch vor neuen Technologien das Problem, was die Entwickler daran hindert, schnell und angemessen zu reagieren. Denn die Entwickler kennen fehle Technologien und Frameworks und können bestimmt eine oder zwei Alternativen nennen. Man sollte immer dafür offen sein, dass es etwas besseres gibt und vielleicht ein Umstieg die Zukunft einfacher macht. Auch ohne zu große Probleme sollte so ein Vorschlag immer mal wieder überdacht werden. Es kann auch helfen sich andere Lösungen anzusehen und davon zu lernen in dem man Konzepte übernimmt (wenn diese dann in die alte Struktur passen!)
Ich habe bei meinen Frameworks, die ich so geschrieben habe gelernt, dass man manchmal einfach alte Dinge weg werfen muss, Kompatibilität gut ist aber nicht bis in die Steinzeit reichen muss und man teilweise ein neues Framework anfängt, dass alles besser machen soll und am Ende portiert man es in das alte Framework zurück und wundert sich wie flexibel man das erste doch entwickelt hat, dass man die Konzepte am Ende auch dort in wenigen Stunden komplett implementieren konnte.
Mutig sein und Entwickler dafür abstellen sich auf dem Laufenden zu halten und die Aufgabe zu geben Vorhandenes zu hinterfragen und zu kritisieren.
Die eine zukunftssichere Technologie
Damit kommen wir direkt zum nächsten Problemkomplex. Es wird analysiert und diskutiert und sich für eine Technologie entschieden. Das geht auch erst einmal ganz gut und so lange niemand danach über den Tellerrand schaut bleibt auch alles gut.
Um eine Technologie für ein Projekt, das auch mal mehrere Jahre laufen wird, muss sie stabil sein, gut zu benutzen, es darf sich nichts groß an ihr ändern, damit man nicht dauernd alte Module anpassen muss und sie sollte gut unterstützt werden (also schon viel im Internet darüber zu finden sein). Das alles ist am Anfang gegeben. Aber es soll ja auch so bleiben. Eine Technologie bei der sich in 3 Jahren nichts mehr groß ändern wird ist an sich tot. Was vor paar Jahren noch sehr toll war z.B. SOAP-Webservice über Annotationen zu erzeugen wird heute keiner mehr wirklich benutzen wollen. SOAP war mal komfortabel, wirkt heute aber einfach umständlich im Vergleich zu REST-Services.
Es gibt keine Technologie, die über Jahre hinweg die beste und einfachste Lösung bleibt. Man kann sich aber auch modernen Entwicklungen nicht komplett entziehen. Das Grundsystem wie der Application-Server und das GUI-Framework sollten immer bei neuen Versionen mit geupdatet werden. Es bedeutet nicht, dass die produktiven Server jedes mal ein Update erhalten müssen, aber die Anwendung sollte immer auch auf der aktuellsten Version laufen können. Das kostet den Entwickler natürlich immer etwas Zeit, aber sollt wirklich mal ein Wechsel der Produktivumgebung anstehen, wird dies wenigstens kein Problem mehr sein und es entsteht kein Zeitdruck alles
doch noch schnell auf die neue Version anzupassen. Wir wissen ja das solche Ankündigen nie rechtzeitig vor her kommuniziert werden.
Es muss nicht immer eine neue Technologie sein, aber wenn man bei der Entwicklung der benutzen Technologie nicht mit macht wird man schnell Probleme bekommen und von allen Vorteilen der neuen Versionen nicht profitieren können. Das deprimiert die Entwickler und gibt denen das Gefühl, als würde man ihnen bewusst Steine in den Weg legen. Man siehe nur den Wechsel von EJB2 auf EJB3.
Jeder Entwickler ist anders
Wir brauchen ein Konzept, damit nicht alles wild durch einander geht und jeder so programmiert wie er gerne möchte und kein Modul aussieht wie das anderen. Also soll jemand festlegen, wie der Code-Style, die Packages und die Oberflächen auszusehen haben. Das geht natürlich ganz schnell, es wird programmiert wie man es selber machen, weil man ist überzeugt von seinem vorgehen und man selbst kommt damit ja super zurecht. Oberflächen guckt man sich seine Anwendungsfälle an... andere werden ja wohl keine Anwendungsfälle haben, die sich von der Struktur her groß unterscheiden. Aber leider dreht sich die Welt nicht um einen. Jeder kommt mit seinen Sachen gut zurecht, sonst hätte man es ja schon längst geändert. Also muss man davon ausgehen, dass auch der der die Dinge entwickelt hat, mit denen wir nicht zurecht kommen, damit super zurecht kommt. Also sich im Team zusammensetzen und am Besten mit offenen Standards anfangen. Ein Tab ist fast immer 4 Zeichen lang. Warum sollte man 3 nehmen? Eine persönliche Vorliebe, weil man ein besseres Lesegefühl dabei hat? So etwas hat sich nicht umsonst durchgesetzt und es haben sich Menschen Gedanken gemacht. Wichtig ist zu realisieren, dass vor einem schon andere Leute über solche Dinge nachgedacht haben und diese Leute auch nicht dumm waren oder sind. Wer glaubt er hätte die einzige wahre Lösung gefunden und jegliche kleine Abweichung wäre falsch, der sollte alles wegwerfen und noch mal von vorne beginnen.
Das Framework sollte verschiedene Ansätze von sich auf unterstützen. JavaFX mit Objekten, FXML, HTML im Web-View und auch sonst noch die alte SWT-Variante. Klingt nach viel, aber es gibt für jeden dieser Ansätze einen Anwendungsfall wo er besser als der Rest ist. Das Framework sollte den Entwickler unbemerkt dazu bringen, dass egal wie er an die Aufgabe heran geht, der Code am Ende den der anderen Entwickler ähnelt. Gleich wird der Code nie sein. Es ist schwer so ein flexibles Framework zu entwickeln, wo sich jeder ransetzen kann und ohne viel Lernen und Anpassungen damit anfangen kann zu entwickeln. Databindung oder direkt Zugriff auf das Element.
POJOs oder komplexe Beans. Wiederverwendbare Komponenten oder eine Komponente aus einzelnen kleinen Komponenten direkt beim Aufbau der GUI konstruieren. Alles ist manchmal nötig und manchmal ist das Gegenteil der bessere Weg. Aber nie ist eines davon an sich falsch. Jeder Entwickler ist anders und geht anders an Probleme heran und in einem Projekt sollte es nie so sein, dass sich die Entwickler darin an einen anderen anpassen müssen, weil sie dann nicht mehr die Leistung bringen, die sie könnten.
Unit-Tests
Unit-Tests sind meiner Erfahrung oft eher Belastung als eine Hilfe. Ein wirklich guter Test braucht Zeit und meistens sind diese Test nichts weiter als Entität speichern, laden, freuen, dass der selbe Wert drin steht, wie beim Speichern. Bei Berechnungen sind die Tests super, weil man schnell prüfen kann, ob eine Berechnung noch korrekt ausgeführt wird. Aber für komplexe Workflows und Anwendungsfälle sind diese Tests meistens sinnlos. Ein paar gute Tester bringen mehr als Unit-Tests. Lieber keine oder wenige Unit-Tests und dafür genug Tester haben. Ein Tester ist ein Mensch und für Schnittstellen, die von Menschen verwendet werden, sind Menschen die besseren Tester,
weil sie an Dinge unterschiedlich heran gehen. 2 Tester können eine Workflow-Schritt durch testen und 2 unterschiedliche Fehler finden, während der Entwickler ohne Fehler getestet hat.
Bloß weil etwas toll ud hip ist, ist es für das eigene Projekt nicht auch immer die beste Lösung. Man muss gucken, ob es einen etwas bring und sich klar sein, dass es nicht die eine richtige Lösung für alles gibt. Unit-Tests für Services sind toll und für GUIs meistens vollkommen unbrauchbar.
Dokumentation ist genau so ein Thema. Ein freier Text kann viel mehr erklären wie ein JavaDoc, wären JavaDoc toll ist während des Programmieren kleine Infos zur Methode zu erhalten. Aber brauch ich eine Info was die Methode load($id) macht?
Team-Leader und Lead-Developer als Unterstützung und nicht als Diktatoren
Ich hatte ja schon mehr Mals im Text erwähnt, dass man viele Dinge im Team klären muss und nicht eine Person, wichtige Dinge für alle entscheiden lassen sollte. Es ist die Aufgabe eine Lead-Developers das Team zu fördern und die Leistung zu steigern und dem Team die Probleme vom Hals zu halten. Es ist nicht die Aufgabe des Teams alles zu tun um dem Team-Leader zu gefallen. Lead-Developer und Team-Leader sind undankbare Jobs und man muss sie machen wollen. Wenn man das nicht will und nur etwas mehr zusagen haben möchte, ist man dort falsch. Auch wenn man nur immer zu allen "Ja" sagt, was von oben kommt und dann die Probleme direkt nach unten zum
Team leitet.
Wenn das Team das Gefühl hat sich in bestimmten Situationen nicht auf den Team-Leader verlassen zu können, hat man ein Problem. Es muss deutlich sein, dass er Verantwortung übernimmt und hinter oder besser noch vor seinem Team steht.
Das selbe gilt für den Lead-Developer und seine Entscheidungen. Er muss Erfahrung haben und seine Entscheidungen erklären können und auch die Verantwortung dafür übernehmen, wenn er eine falsche Entscheidung getroffen hat und den Mut haben diese zu Korrigieren. Wenn also ein falsches Framework ausgewählt wurde mit dem kein Entwickler zurecht kommt, ist es sein Fehler und nicht der Fehler der Entwickler. Dann muss er handeln und
den Fehler beheben.
Fazit Das waren jetzt meine groben Gedanken zu dem Thema und meinen Erfahrungen. Es ist aber klar, dass zur Behebung eines Problems erst einmal das Gespräch gesucht werden muss, denn die Entwickler wissen schon meistens sehr genau was schief läuft. Eine Lösung für das Problem müssen die aber deshalb nicht präsentieren können. Wenn nicht ganz klar sein, sollte wo das Problem liegt und man wirklich mit dem Projekt in Bedrängnis kommt, sollte man sich jemanden holen der Erfahrung hat und solche Situationen kennt und am besten mal durchlebt hat. Auch hier wieder die Feststellung, dass vieles immer sehr ähnlich ist und man von den Problemen und Fehler der anderen oft sehr viel lernen und dann verwenden kann.
Solche Leute sind nicht günstig, aber wenn man mal dagegen rechnet wie viel Zeit eingesperrt werden kann, sind die oft ihr Geld wert.
Probleme innerhalb des Teams könnte auch da sein. Aber das ist ein sehr sensibles Thema und dort gibt es noch weniger als bei den deren Problemfeldern keine einfache Lösung.
Nachdem man in Tine 2.0 einen Account aus einem alten DB-Backup per Hand über SQL wiederherstellt, muss man in GROUP_MEMBERS den Account auch wieder hinzufügen und die Contact-Id überprüfen, sonst kann man den WebDAV-Service für alle Benutzer lahmlegen!
Entity not im WebDAV-Service deutet auf so ein Problem hin.
Blog-entries by search-pattern/Tags:
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?
bezahlt von 
Blog: Blog-entries by search-pattern/Tags:
