bezahlt von 
Blog: Latest Entries (15):
Entwicklungsgeschwindigkeit und Probleme
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.
Simple Programmer - Some Advice On Becoming a Lead Developer
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.
Win10 Upgrade Problem-Lösungen - Fehler 80240020
Wie man das Upgrade erzwingt:
http://www.golem.de/news/windows-10-verteilung-des-gratis-upgrades-erzwingen-1507-115482.html
Falls es sich nicht installieren lässt und ein Fehler kommt:
http://www.pcgameshardware.de/Windows-10-Software-259581/Tipps/Fehlercode-80240020-Loesung-1166410/
Wie man die alte Windows Version komplett entfernt:
http://www.win-10-forum.de/artikel-windows-10-tipps-tricks/319-windows-10-datentraegerbereinigung-upgrade-schafft-speicherplatz.html
Neue Domain
Neue Cherry Tastatur und Win10
etwas herunterfahren in den nächsten Wochen, aber es weiterhin professioneller machen als noch am Anfang des Jahres. Daher versuche ich es auch mal mit dem
Amazon-Partner-Programm. Ich glaube nicht wirklich Geld damit zu verdienen.. aber ich wollte es einfach mal ausprobieren und meine Homepage wurde
auch angenommen. Das allein war schon schön.
Als ich am Freitag nach Hause kam, hatte meine Frau mir eine neue Tastatur schon angeschlossen, die sie mir geschenkt hat. Denn bei Blogs muss man
viel schreiben und dass soll ja möglichst gut gehen. Bisher hatte ich eine billige Microsoft Tastatur. Die war nicht schlecht, aber eben eine einfache
billige Tastatur.
Microsoft Wired Keyboard 600 USB Tastatur
Jetzt habe ich eine Cherry Tastatur. Die haben einen guten Ruf und ich mag die einfach. Das Schreibgefühl ist einfach toll. Gut sie ist lauter. Aber dafür fühlt
es sich nicht so an als würde man mit Gummi-Tasten schreiben.
Cherry G83-6105 LUNDE-2
So eine hatte ich auch bei meinem alten Job und ich werde versuchen so eine auch bei meinem nuen Job zu bekommen.
Und als ich schon mal dabei war meinen PC den neuen Anforderungen anzupassen, kamen noch 2 schnellere Stromspar CPUs (Xeon L5335) in mein System. Es gibt nichts schlimmeres
als mit Systemen zu arbeiten, die längere Ladezeiten haben oder mal hängen. Zweites ist damit jetzt erledigt. Aber eine SSD kommt irgendwann doch noch mal.
CPUs reichen weil zum Schreiben braucht man nicht so viel Leistung und auch Web-Development ist in Relation zu z.B. J2EE-Entwicklung sehr sparsam mit CPU-Leistung.
Windows 10 kam heute dann auch gleich mit rauf. Virtuelle Desktops funktionieren.. mal gucken wie gut die dann auch benutzbar sind. Aber es funktioneirt an sich erstmal gut.
Aber allein die Tastatur wird mir schon sehr helfen!
Blog-Update, Kommentare, etc
Als nächstes folgt eine bessere Integration von Bildern und Videos.
Das Theme der ganzen Seite hatte ich ja schon vor kurzen angepasst und es sieht nun auch etwas moderner alles aus. Das alte dunkle Theme gefiel mir auch eher nicht mehr. Das neue wirk auch irgendwie einladener.
Ich hoffe dass damit jetzt alles noch ein Stückchen professioneller wird (obwohl es nur meine private Homepage ist) und auch die Google-Suche nun etwas besser mit allem hier zurecht kommt. SEO ist ja doch schon eine Wissenschaft für sich.
PS: eine neue Version von aoop, auch mit dem neuen Blog-Module werde ich in den nächsten Tagen zum Download bereit stellen.
Tastatur und Maus reinigen
Zuhause wäre das kein Problem, dann dort habe ich das ultimative Reinugungs-Mittel für sowas und noch viel mehr... nicht für alles.. die Einzugsrollen von Druckern sollte man damit nicht versuchen zu säubern. Sonst muss man mit den Fingern die darauf kleben gebliebene Schicht mühseelig abbreiben. Sauber waren sie am Ende dann doch.. aber als gut gemeinter Tipp.. es einfach nicht machen!
CyberClean Reinigungsmasse
Und für Tasturen auch sehr praktisch:
Hama Blasebalg Dust Ex
... vielleicht hat man sowas ja schon bei der Fotoausrüstung liegen.
Ist jedenfalls alles viel besser als die Tastur über Kopf zu halten und zu schütteln.
Einfache Verwendung der indexedDB
Hier wird erklärt wie man ein Objekt mit einer einfachen Id speichern und wieder laden kann.
Heise Dev. Podcast zu AngularJS
http://www.heise.de/developer/artikel/Episode-43-Single-Page-Apps-mit-AngularJS-2180387.html
Für Entwickler die schon aktiv mit AngularJS arbeiten bietet er wenig bis nichts neues.
SEO, wtf?
Dabei fällt mir immer wieder auf wie ungelaublich und durchsichtig diese ganze Sache mit dem Ranking in Google ist. Wärend ich mit der WebM-Maker-Seite das letzte mal sehr viel Glück hatte, weil die von Anfang an auf mobile Geräte ausgerichtet war. Da war die Bewertung nach Eignung für Mobile-Devices dann kein Problem. Aber die Schwankungen bei den Impressions sind teilweise oder eher oft, kaum nach zu vollziehen. Gerade mit entsprechenden Suchbegriffen auch nicht wirklich nachvollziehbar. Alle Optimierungen mit Title, Description, H-Tags und so, sind gemacht und die Begriffe stimmen auch. Aber dennoch stürzten die Impressions in den letzten Tagen sehr ab. Bei der Analyse der echten Zugriffszahlen gingen die Zugriffe aber sogar leicht nach oben. Ok wenn man die Seite gefunden hat und ein Bookmark benutzt oder den Link direkt eingibt geht es natürlich an Google vorbei. Das spricht für Benutzer die wieder kommen. Das ist sehr schön, aber ich hätte auch gerne noch neue Benutzer.
Ich werde dann wirklich mal die WebM-Maker App versuchen im Firefox Marketplace unter zu bringen. Mit etwas Glück bringt dass noch ein paar neue Benutzer. Und Links auf die Seite wären auch nicht schlecht.
Da steckt noch viel Arbeit hinter....
Asynchrone REST-Abfragen mit JavaFX
Firefox OS auf beliebigen Android-Phones
Da gute und Leistungsfähigere Smartphones mit Firefox OS selten sind, wäre ich doch sehr interessiert Firefox OS mal auf einem wirklich schnellen Smartphone zu sehen und dann vielleicht auch WebM-Maker mal in den Firefox Marketplace einzustellen. Dann wäre es auch mal interessant zu versuchen live Video zu capturen und in GIF oder WebM umzuwandeln.
Vielleicht auch dann mit einem Filtern, um die auch in schwarz-weiss umzuwandeln zu können. Wäre eine nette Spielerei, wenn auch nur selten wirklich interessant. Es ist ja kein Bild-/Video-Bearbeitungsprogramm, sondern nur ein einfacher kleiner Converter für zwischendurch. Und das wäre auf einem Smartphone ja genau richtig aufgehoben.
Wenn ich mal wieder etwas mehr Zeit habe, werde ich mich auf jeden Fall wieder mehr mit Firefox OS beschäftigen.
Jobs, Bewerbungen und der ganze Rest
Menschen und Veränderungen passen ja nie wirklich so gut zusammen. Wenn etwas läuft, tut man sich schwer es zu ändern und ein Risiko einzugehen. Hier ist es gerade genau das, was mich bewegt. Wenn man 10 Jahre bei einer Firma war, hat man sich doch stark an vieles gewöhnt. Die Abläufe, der Tagesrhythmus, die Kommunikationskultur.. alles wird danach anders sein und man muss sich umgewöhnen. Am Ende wird es kein Problem sein, da man doch sehr viel flexibler ist als man denkt, aber man denkt doch immer wieder darüber nach, ob man da nicht auffällt, weil es anders gewohnt ist.
Das Ende hier kommt jetzt auch nicht wirklich plötzlich und überraschend. Ich will es ja so. Ich möchte andere Strukturen, Umgebungen und neue Möglichkeiten mich weiter zu entwickeln. Ich weiß, dass ich dafür weiter ziehen muss und allein diese Erkenntnis und es in Angriff zunehmen hat mir in den letzten Monaten schon viel gebracht.
Ich gehörte nie zu denen, die sich mit einer Technologie zufrieden geben. Ich halte es für vollkommen falsch eine Technologie zu wählen und dann zu glauben man könnte Jahre damit arbeiten, weil alles ja so zukunftssicher ist und dann alles neue kategorisch ablehne. Neben meiner Arbeit mit Java EE und Desktop-Clients, habe ich den Web-Bereich nie aus den Augen verloren und dann auch privat viel Zeit investiert um mich dort auf einem aktuellen Stand zu halten. Neue Konzepte und Technologien... aber nichts was ich in meinem Job gebrauchen konnte oder durfte.
Also kam die Entscheidung, dass ich mich mehr mit neuen als mit alten Dingen beschäftigen möchte und dafür einen neuen Job brauche. Damit fing die erste Phase an. Denn man muss sich bewerben. Ich brauchte einen aktuellen Lebenslauf, dafür musste ich erst einmal wissen, was ich kann, was ich in den letzten Jahren in meinem Job eigentlich alles gemacht habe. Dann musste ich mir erst einmal darüber klar werden was ich privat alles gemacht habe, gelernt habe, was ich wie gut kann und was davon vorzeigbar ist.
Während man die Projekte im Job, wenn man nur firmeninterne Software entwickelt, nicht wirklich zeigen kann (ich als Chef hätte keine Lust, um einen neuen Bewerber zu beurteilen, mir eine Oracle DB, einen Application Server und alle möglichen Libs einzurichten, um dann mit etwas Glück ein fremdes Projekt deployen zu können). Also mussten als Beispiele eher die privaten Projekte herhalten.
* lieber wenige gute Dinge zeigen, als viele wo die Hälfte nicht funktioniert oder nur ein einfaches Beispiel einer Funktion ist * Der Zweck und die Benutzung muss sich innerhalb weniger Sekunden erschließen, keiner will erst einmal 20 Seiten eines Handbuchs lesen müssen
* Es sollte modern sein und zeigen, dass man ausbaufähig ist
Dann das Problem mit der Homepage. Hübsch machen, aktualisieren und es wenigstens so aussehen lassen, als hätte man sie nicht die letzten 2 Jahre total vernachlässigt. Also alle alten Blog-Einträge entfernen bzw. nur die wirklich guten, die einen was bringen, behalten. Alles mehr so ausrichten, dass der Besucher sieht, in welche Richtung man will. Alle Konzepte, Ideen und halb-fertigen Dinge einfach löschen bzw. ausblenden. Das bringt einen schon einmal was, da man die Anzahl der Projekte verringert und sich klar wird, was einen wirklich was bringt und wo es sich lohnt mehr Zeit zu investieren.
Dann muss man auch gefunden werden. Weil Chefs sollen ja laut Medien bei Google nach den Bewerbern suchen... oft lesen sie die Bewerbung nicht mal wirklich durch.. aber falls es doch mal passiert, sollen sie einen auch gut bei Google finden können und genau darauf gestoßen werden, dass man genau das macht und kann, was die brauchen. SEO. Ein leidiges Thema, aber nötig. Google Webmaster-Tools einrichten für alle Websites und Projekte. Hätte man vorher schon mal machen sollen, auch wenn der Erfolg der eigenen Projekte an sich egal war, ist es doch gut zu wissen was Menschen mögen und verwenden. Es gibt einen auch ein gutes Gefühl etwas geschaffen zu haben, was von anderen verwendet wird.. aber Vorsicht... am erfährt eher, dass es keinen interessiert was man so gebaut und entwickelt hat.
Erst nach dem ich versucht habe gefunden zu werden, sind bei einigen Projekten auch wirklich mal Zugriffe zu verzeichnen. Nicht viele, aber endlich mal wenigstens regelmäßig.
Den Blog wieder aufleben lassen. Über Dinge schreiben, die man kann und macht. Es ist egal, ob es nur Grundlagen sind oder einfache Anleitungen. Es zeigt, dass man in sein Wissen Vertrauen hat und etwas erklären kann bzw. es wenigstens versucht. Man fasst sein Wissen auch mal strukturiert zusammen und erschafft sich damit auch sein eigenes kleines Nachschlagewerk auf das man selbst mal wieder zurück greifen kann, wenn man sich denkt: "Wie war das noch mal mit ....?".
Also auch wenn es niemand liest, kann man es immer noch zur Selbstreflektion verwenden.
Wenn man dann nach ca. 2 Wochen mit dem Aufräumen und Verschönern seiner Präsenz im Internet fertig ist, kann man den Lebenslauf schreiben. Ich bin ja immer noch dafür es selbst zu machen und niemanden dafür zu bezahlen. Gerade im IT-Bereich, wo man doch sein können gerne mal darin an den Arbeitgeber anpasst, um spezialisierter zu wirken. Wie man einen Lebenslauf schreibt lernt man in der Schule und jeder hat eine andere Meinung über Form und Inhalt. Ich habe immer gut damit gelebt, dass es reicht wenn er gut zu lesen ist und alles enthält was der Arbeitgeber wissen soll und dafür auch gerne mal gegen ein oder zwei Form-Regeln verstoßen kann.
Das Foto sollte gut sein. Da sonst zu einem echten Fotografen oder selbst mal wieder die Blitze, Schirme, Softboxen und Funkauslöser raus kramen. Kann auch mal ganz erfrischend sein ein andere Hobby kurz wieder aufleben zu lassen und mehr Kontrolle über das Ergebnis zu haben.
Ich geh mal davon aus, dass man schon vorher mindestens ein Stellenangebot gefunden hat, dass einen interessiert. Jetzt wo die Unterlagen fertig sind und man im Internet hoffentlich zu finden ist, kann man anfangen die erste Bewerbung zu verschicken. Wenn die draussen ist, dann gleich weiter machen und mehr Angebote suchen. Mir hat es immer viel gebracht, die Homepages der Firmen mir sehr genau anzusehen, da konnte man dann schon relativ gut sehen, ob es etwas ist, wo man sich bewerben kann oder es doch nichts für einen ist.
Die Hälfte der Firmen wird sich nie melden, einige werden Absagen schicken (teilweise auch erst Monate später) und einige wenige werden einen einladen.
Das Gespräch.. man weiß nie wie es sein wird. Soll man einen Anzug anziehen? Wenn man sich dann besser fühlt oder alle dort so rumlaufen sicher. Ansonsten muss man ein Gefühl bekommen, wie die Firma wohl läuft und funktioniert.
Eben von der Homepage oder aus Emails und Telefonaten. Hier in der Firma wo ich gerade meine letzten Tage hier verbringe, erkannt man Bewerber immer sofort. Es sind die einzigen Leute, die mit einem Anzug herum laufen und dann wenn sie eingestellt wurden auch nie wieder mit einem Anzug zu sehen sind. Aber am Ende ist immer besser zu gut als zu schlecht angezogen zu sein.
Bis man soweit ist, kann es einen Monat dauern. Aber ich hatte einfach die Zeit und es war insgesamt gut diese auch zu investieren und nichts zu überstürzen. Der Blog läuft auch weiterhin noch, auch wenn ihn wohl kaum einer liest... vielleicht sollte ich doch mal anonyme Kommentare ermöglichen und auch share-Buttons für soziale Netzwerke.. aber auch da gilt: Ich habe die Zeit und auch wenn es langsam voran geht, geht es doch stetig voran.
REST-Services (mit APF2 und aoop)
Meine Erfahrungen mit dem Parsen von XML und JSON in PHP ist aber, dass beide eigentlich gleich schnell sind. Ein Wechsel bei Config-Files von XML auf JSON hat keine Verbesserung der Ladezeiten ergeben. Auch die Serialisierung von Objekten bei Java war mit JSON nur minimal schneller als mit XML, wobei es dort auch sehr vom Verwendeten Framework abhängig war. Also kann es sein, das es in neueren PHP-Versionen doch Unterschiede geben wird, wenn dort noch mehr optimiert wird.
Mit das größte Problem auf dass ich bei REST-Services in PHP gestoßen bin ist das Parsen der URLs. Hier besteht einfach das Problem, dass es immer viele Methoden pro Service gibt und das einlesen der Mapping-Patterns somit doch relativ aufwendig sein kann. Während man in einem Java-Servlet nur einmal am Anfang alles parsen muss, muss man in PHP bei jeden Request von vorne beginnen. Eine Lösung wäre das Speichern der Ergebnisse in der Session, wobei hier dann aber das Problem bleibt, dass man bei Änderungen diese erkennen und den Inhalt der Session erneuern muss. Man kann das XML als String lesen und einen MD5-Hash bilden. Damit könnte man verschiedene Versionen des Services in der Session identifizieren. Am schönsten wäre natürlich den Zugriff auf das Dateisystem komplett einsparen zu können, aber dass scheint erstmal so nicht machbar zu sein.
Das Gleiche gilt auch für das Objekt, dass die Methoden enthält auf die die URLs gemappt werden. Man muss sich auch deutlich machen, dass ein REST-Service im Grunde kein Konstrukt der objekt-orientierten Programmierung ist, sondern die Facade im Grund klassischen prozedualen Prinzipen folgt. Gerade wenn man Sicherheits-Token und so verwendet und nicht die Session für die Speicherung des eingelogten Benutzer verwendet, merkt man dass man auch ohne Klasse mit einfachen functions hier genau so gut arbeiten könnte. Aber wir verwenden eine Klasse, die den Service beschreibt, um auch keinen Stilbruch zu haben. Ein Objekt zu erzeugen ist teuer und theoretisch könnte man sich dieses hier ersparen.
Mein AFP2-Framework benutzt die selben Klassen wie mein älteres aoop-Framework. Es implementiert momentan noch kein wirkliches Routing sondern nutzt einfach Regex-Ausdrücke um die gesamte URL mit einem Match auf die richtige Methode zu mappen. Hier wird also einfach von oben nach unten die Liste durch laufen und immer ein preg_match durchgeführt. Routing mit beliebig tiefer Verschachtelung und Sub-Routen, würde hier viel Zeit ersparen, da damit die Anfangs-Liste relativ klein wäre und schnell abzuprüfen wäre und erst dann in der nächsten Liste weiter geprüft wird. Das kommt dann später nochmal um etwas schneller zu werden.
Ein ganz einfacher REST-Service kann so aussehen:
rest.xml
<service name="walls" class="PostWallREST">
<method name="loadWall" pattern="/^\/rest\/\w+\/wall\/(\d+)(\?.+)?$/">
<argument type="int" requestvalue="false" group="1"/>
<argument type="int" pattern="userId" requestvalue="true"/>
<argument type="string" pattern="_XW_SESSION_SEC" requestvalue="true"/>
</method>
</service>
PostWallREST.php
class PostWallREST{
private $security=null;
private $conv=null;
private $am=null;
public function PostWallREST(){
$this->security=new XWSearchStringParser();
$this->conv=new PWDTOConverter();
$this->am=XWAddonManager::instance();
}
public function loadWall($id,$userId,$secToken){
$resp=new XWRESTResponse();
$resp->singleResult=true;
if(isset($_SESSION["XWUSER"]) && $this->am->getAddonByName("XWUserSession")->checkSessionSecToken($secToken)){
if($_SESSION["XWUSER"]->getId()==intval($userId) && intval($id)>0){
$wall=new PWWall();
$wall->load($id);
if($wall->checkRight($_SESSION["XWUSER"])){
$dto=$this->conv->convertWall($wall,$_SESSION["XWUSER"],true);
$resp->results[0]=$dto;
}
else{
$resp->restMethodSuccess=false;
}
}
else{
$resp->restMethodSuccess=false;
}
}
else{
$resp->error=true;
$resp->errorMessage="no valid session";
}
$resp->newSecToken=$this->am->getAddonByName("XWUserSession")->getURLParameterWithSessionSecTokenValueOnly();
return $resp;
}
}
Wie man erkennt wird im service-Tag die Klasse angeben, auf die die URLs gemappt werden sollen. Das Mapping der einzelnen Methoden wird dann innerhalb genauer definiert. Jede Method einen grundlegenden Pattern, der für ein Match auf die URL verwendet wird. Wenn dieser passt wird versucht die Argument (die Reihenfolge in der XML muss der Reihenfolge in PHP entsprechen!) aus der URL oder dem Request zu rekonstruieren. Jedes Argument kann ein eigenes Pattern haben. Wenn es ein Request-Value ist, entspricht das Pattern dem Namen im Request. Sollte kein Pattern angeben sein, wird dass Pattern der Method verwendet. Das erspart viel Text, weil man so nur ein allgemein gültiges Pattern schreiben muss. Mit group wird die Gruppe beim preg_replace angeben. Also die die den benötigten Wert enthält, der als Argument übergeben werden soll. Im Pattern der Method können also schon alle Werte in Gruppen markiert werden und bei den Arguments muss immer nur noch angegeben werden, welche Gruppe verwendet werden soll.
URLs zu REST-Services folgen in aoop und APF2 folgender Regel:
http://..../rest/{modulename}/.....
Über den Modul-Namen wird gesteuert welche rest.xml geladen wird. /rest/ ist die Markierung, dass hier ein REST-Service angesprochen werden soll. Der Rest der URL kann nach Belieben definiert werden.
Für unser Beispiel wäre z.B. folgende URL lauffähig:
http://..../rest/PostWall/wall/1?userId=1&_XW_SESSION_SEC=XXXXX
Das Ergebnis der Methode wird dann in JSON umgewandelt und auch der Header entsprechend auf "text/json" gesetzt.
Damit lässen sich nun pro Modul REST-Services definieren und deployen. Bei PHP hat man zum Glück nicht das Problem, dass sich ändernde Klasse von anderen REST-Services anderer Module zu Laufzeitfehlern führen können. Wenn man ein Modul ändert, wird die Klasse ja beim nächsten Request erneut geladen und nicht wie bei Java in der VM gehalten. Probleme kann es nur geben, wenn man die Session verwendet und versucht dort gespeicherte serialisierte Daten einer alten Version in ein Objekt der neuen Version der Klasse zu deserialisieren.
Das macht diese Umgebung in PHP für Microservices interessant. Da man hier wirklich einzelne Module zur Laufzeit austauschen kann, ohne dabei die anderen Module zu beeinflussen (wenn man natürlich vorher drauf geachtet hat, dass Klassen, die auch von anderen Modulen verwendet werden, nicht zu Fehlern bei diesen führen). Zu überlegen wäre auch diese Klassen zwischen den Services als JSON und nur über eine URL dem anderen Service verfügbar zu machen. Also die URL auch zu Intra-Service Kommunikation zu verwenden.
Also sowas wie:
$req=$_REQUEST;
$req["userId"]=0;
$req["_XW_SESSION_SEC"]="XXXXX";
$json=XWRESTServicesLocal::call("/rest/PostWall/wall/1",$req);
Und den JSON-String dann auf eine eigene Klasse zu mappen. So etwas werde ich für die nächste Version dann einbauen.
Das war jetzt ein grober Überblick wie meine Frameworks REST-Services implementieren und versuchen dabei möglichst flexibel zu sein, aber auch nicht dabei zu sehr auf Kosten der Performance zu arbeiten. Die Arbeiten an APF2 sind noch in Gange und deswegen kann sich da auch noch einiges Ändern und vielleicht lerne ich von anderer Seite noch einiges, wie sich auch die letzten Probleme lösen lassen, um so REST-Services noch besser implementieren zu können.
Eine VMDK für VirtualBox vergrößern
Also erstmal über den Manager für die Laufwerke eine Kopie als VDI erzeugt. Dauert .. geht aber gut.
Dann aus dem VirtualBox Verzeichnis heraus die neue Größe setzen:
vboxmanage "c:\.....\disk2.vdi" --resize 20000
Also auf 20GB vergrößert.
Nun muss nur noch die Partition angepasst werden. Nach einige Versuchen und googeln habe ich diese Anleitung gefunden:
http://derekmolloy.ie/resize-a-virtualbox-disk/
GParted lief bei mir in der 0.17.0-4 Version. Eine aktuelle wollte nicht starten. Aber damit ging es leicht.
Erstmal eine neue VM mit der ISO und der disk2.vdi erstellt. Dann starten und alles so lassen wie vorgeschlagen. Resize wählen. Per Drag and Drop die Größe anpassen und dann auf "apply" drücken. Warten.
VM ausschalten und die Oracle Linux VM wieder starten. Alles super!
Older posts: