bezahlt von Permission vs FileNotFound
Auch wenn hier eine FileNotFoundException kommt.. das mit der Permission ist der Fehler. Ist in solchen Fällen immer schnell klar, aber kann doch etwas verwirren.
Blog: Latest Entries (15):
Auch wenn hier eine FileNotFoundException kommt.. das mit der Permission ist der Fehler. Ist in solchen Fällen immer schnell klar, aber kann doch etwas verwirren.
ROI... die reale Welt
Außerdem ist es einfach schwer zu bestimmen wie hoch der ROI bei etwas ist. Was ist besser? Wenn ich von JavaFX auf AngularJS wechseln möchte und damit mir 3 Wochenarbeit spare oder wenn mein Teamleiter, der ja mehr verdient, selbst noch mal Zeit investieren muss um meinen Wunsch verstehen, bewerten und nachvollziehen zu können. Beides kostet Geld. Am Ende würde auch die Abteilung von den 3 Wochen profitieren. Entweder weil die die Anwendung 3 Wochen früher bekommen und 3 Wochen früher als gedacht produktiver arbeiten können oder weil die Zeit in weiter Verbesserungen fließt und dann die Abteilung noch effektiver und produktiver arbeiten kann.
In kleinen Firmen mit direkten Draht zu Kunden ist so etwas immer sehr viel einfacher zu messen. Ich kann pro Monat so und so viele Auftrage der Kunden erledigen und bringe so und so viel Geld. Geld ist messbar.. spätestens auf den Kontoauszügen.
Schwer den ROI zu bestimmen ist, wenn du interne Frameworks entwickelst. Weil es ist nichts was eine andere Abteilung oder ein Kunde jemals bemerken wird. Die anderen werden schneller Entwickeln und einen höheren ROI haben. Aber man muss sehr hinterher sein auch immer mal fest zu stellen, dass es auch am guten Framework liegt. In Meetings immer erzählen, was sich verbessert hat und am besten ein Beispiel bringen, was nun ganz einfach möglich ist, was vorher andere viel Zeit gekostet hat. Ein gutes Framework ist für den Anwender unsichtbar.. ein schlechtes.. dann wird man nicht so schnell übersehen.
Am Ende finde ich es aber doch momentan sehr gut, direkt mit so etwas zu tun zu haben. Etwas wo Zeit Geld ist und gute Lösungen, die einen Zeit sparen, nicht als etwas neues und damit potenziell unsinniges gesehen wird und Zeitersparnis eher neben sächlich ist.
News-Seiten und andere
Es sind alles Seiten, die einen gewissen Output pro Tag/Woche haben. Es gibt viele tolle Blogs, aber meistens kann man die sich auch schnell komplet durchlesen und muss dann wieder Wochen warten, bis was neues kommt. Es steht sehr viel sehr nützliches in solchen Blogs, aber für den täglichen "Gebrauch" sind sie eher nicht so geeignet.
Allgemeine News-Seiten
http://www.heise.de/ (kennt wohl jeder...)
http://www.golem.de/ (manchmal fehlt die Tiefe, aber insgesamt eine gute News-Seite)
http://arstechnica.com/ (daher übernimmt golem gerne auch mal was)
Entwicklung (Java,PHP,Web)
http://www.heise.de/developer/ (allgmein)
https://webmagazin.de/ (Web allgemein)
https://jaxenter.de/ (Java,Web.. viele gute Videos)
http://jaxenter.com/ (Java,Web)
http://simpleprogrammer.com/ (geht über das Entwickeln hinaus, geht mehr um Lebenseinstellungen und Tipps für den Job. Wird gerne von den jaxenter-Seiten als Grundlage für eigene Artikel verwendet)
Video vs Text
Die Zahlen am Anfang mögen zwar alle stimmen und für sich konsistent sein, nur die Schlussfolgerungen daraus halte für falsch oder es wird Ursache und Wirkung vertauscht. Vielleicht irre ich mich auch total, aber meine Menschenkenntnis sagt mir etwas anderes.
Wenn es um den Verkauf eines Produktes geht, muss die Präsentation auf dem ersten Blick stimmen und die Infos liefern, die der potentieller Käufer braucht. Käufer vergleichen Produkte, bevor sie sich für ein Produkt entscheiden. Das ist mit Nachrichten. Dort will ich auch schnell die
Infos haben um zu entscheiden, ob ich mich mit dem Thema nochmal genauer beschäftige.
Ich liebe ja die Videos von http://www.simpleprogrammer.com, weil immer ein komplettes Transcript darunter steht. Da kann ich schnell nach Stichworten suchen, Infos herauskopieren, langweilige/uninteressante Teile überspringen (ohne lange das Ende im Video suchen zu müssen). Ein Video kostet immer mehr Zeit, wenn man sich einen schnellen Überblick verschaffen möchte.
Wenn ich Produkte vergleichen möchte, ist ein zusammenfassender Text immer besser als ein Video. Wenn ich 5 ähnliche Produkte habe und mir dauernd ein Video immer und immer wieder angucken müsste, um die Daten aus dem Video zu extrahieren, damit die vergleichen kann, verbringe ich gut 60% der Zeit damit die richtige Stelle im Video zu finden. Man könnte die sich dann natürlich notieren, um nicht eine Stelle in einem Video 5mal ansehen zu müssen, weil ich bei der Menge der Artikel wieder vergessen hab bei welchen Artikel was wie war.
also 20% Verweildauer halte für untertrieben. Dafür kosten einen Videos viel zu viel Zeit. Wenn die wichtigen Infos nur im Video zu finden sind, suche ich mir eine andere Seite, da mir meine Zeit zu schade ist sie mit der Suche in Videos zu verschwenden.
85% entscheiden sich für ein Produkt wenn sie ein Video gesehen haben. Hier glaube ich, dass Ursache und Wirkung vertauscht sind. Die grobe Entscheidung ob ich ein Produkt überhaupt interessant finde geschieht an den groben Daten. Dann vergleiche ich beim Rest die speziellen Eigenschaften und setze diese in Relation zum Preis. Wenn ich dann noch zwischen 2 oder 3 Produkten schwanke und ein Video vorhanden ist, würde ich mir das nochmal ansehen um vielleicht noch mal einen besseren optischen Eindruck vom Produkt zu bekommen. Aber mit hoher Wahrscheinlichkeit habe ich mich sogar schon für das Produkt entschieden und will nur die letzte Bestätigung haben mit dem Video.. wenn es dann nicht passt, würde die Auswahl nochmal komplett von vorne beginnen.. ohne dieses Produkt.
Also liegt die Wahrscheinlichkeit zum Kauf des Produktes schon sehr sehr hoch, wenn das Video angesehen wird. Also kommen die 85% für den Kauf nicht durch das Video, sondern das Video wurde angeguckt weil die Wahrscheinlichkeit für den Kauf bei ca. 85% lag. Es wäre interessant, ob ein Video einen nach der Entscheidung rein nach Daten noch groß umstimmen kann.
Video für bessere Positionen bei der Suche oder weil man dann voll hip erscheint, ist ein gutes Argument. Aber man sollte Videos nur als Ergänzung zum Text verstehen und nicht als Ersatz.
Die perfekte Service-Umgebung, oder so
gedanklich beschäftigt habe (in Staus hat man viel Zeit für so etwas), habe ich mal angefangen in paar kurzen Gedanken zusammen zu fassen, wie ich mir eine Umgebung vorstelle, mit der man sehr flexibel und fehler-tollerant arbeiten und entwickeln kann.
Es geht hier hauptsächlich um REST-Services, die man z.B. von einer AngularJS Anwendung oder einen Java-Desktop-Client Aufruft. Oder auch REST-Services die zwischen Servern zur Kommunikation verwendet werden.
Wichtig dabei ist auf jeden Fall, dass man Config-Dateien an einem separaten Ort ablegen kann. Also getrennt vom Service-Code, so dass man ohne Probleme eine neue Version deployen kann, ohne sich darum Gedanken machen zu müssen, ob man die Config überschreibt oder eine für ein falsches System darin enthalten sein kann. Die Anpassung des Services wird extern von der Umgebung gemanagt.
Sollte keine eigene Config-Datei vorhanden sein, sollte der deployte Service mit default Einstellungen laufen.
Die Umgebung sollte einen Service deployen, undeployen und pausieren können. So dass man einen Service für Wartungen deaktivieren kann und das System Anfragen entweder so lange hält (bis der Service wieder da ist oder eine Timeout kommt) oder eine allgemeine Antwort zurück liefert, die dem Anfragenden darüber informiert, dass der Service zur Zeit nicht verfügbar ist.
Es sollte auch ein Reload eines Services möglich sein, um z.B. geänderte Config-Daten zu erkennen. Da würde ja ein Call auf eine Methode des Service-Objekts reichen, dass in einem bestimmten Interface vorgegeben wird.
Wenn man eine große Anwendung hat, muss man früher oder später die Services auch untereinander kommunizieren lassen. Konzept wie @ejb halte ich für zu unflexibel, da man direkte Pfade und so berücksichtigen muss. Ein Service sollte intern einen selbst gewählten eindeutigen Namen haben. Der alleine reicht um einen Service anzufordern. Da wird dann aber auch nicht ein Interface un eine Proxy-Klasse zurück geliefert sondern ein Descriptor-Objekt, dass angibt ob der Service verfügbar ist und die Root-URL. Es müsste auch eine Version mit in der Anfrage nach dem Service sein, um zu verhindern, dass Dependencies ein nicht handhabbares Problem werden. Wenn man die Verfügbarkeit über das Objekt prüft, wird immer der aktuelle Status des Services ermittelt.
Man kann also Versionen abhängige Logiken implementieren, falls der eigene Service sich mit einer aktuelleren Version anders verhalten sein, weil die vielleicht eine bessere Methode für irgendwas hat. Sollte ein Service gar nicht vorhanden sein oder plötzlich offline gehen, muss man gucken, ob meinen Fehler zurück liefert oder eine Fallback-Lösung bemüht. Wenn man z.B. einen zentralen Logging-Service verwendet und dieser während der Laufzeit in den Wartungsmodus versetzt wird, könnte man für die Zeit auf eine eigene Datei-basierte Lösung zurück greifen, bis der Logging-Service wieder verfügbar ist.
Die Umgebung hat ein zentrales Verzeichnis mit allen deployten Services. Man könnte überlegen, dass dieses Verzeichnis die Request nicht nur auf die Objekte mapped sondern auch auf andere Server weiterleiten könnte, so dass man Services sogar über verschiedene Server verteilen kann,
aber für den Client weiterhin einen zentralen Aufrufpunkt hat.
Auch könnte man implementieren, dass ein Service eine asynchrone Nachricht an das System schickt und die Nachricht dann an jeden Service verteilt wird.
Wichtig wäre bei der Kommunikation zwischen Services auf jeden Fall, dass Requests es auch asynchron bearbeitet werden können. Also das z.B. bei unserem Logging-Service zwar die Verfügbarkeit geprüft wird dann aber nach dem Fire-And-Forget Prinzip weiter verfahren wird. Ansonsten ist es auf der Service-Seite gerade mit inter-Service Kommunikation es wohl meistens einfacher synchron zu arbeiten. Auf Client-Seite sollte man ja asynchron arbeiten, da es die UX sehr verbessert.
DataSources und Transaction-Management sollte auch von der Umgebung alles bereit gestellt und verwaltet werden. In der Config-Datei für einen Service trägt man dann ein "verwende DataSource 'CRM_ARTICLES'". Der Service alleine darf sich selbst keine Datenbankverbindungen erstellen.
Mit soetwas sollten sich auch größere Anwendungen mit getrennten Modulen/Services entwickeln lassen ohne zu schnell in Probleme zu laufen.. natürlich nur wenn man die Möglichkeiten nutzt und nicht versucht am System vorbei Dinge zu erledigen. Ob so ein System für solche Service-Module performant realisieren kann, müsste man einfach mal ausprobieren.. wenn man die Zeit dafür hätte. In Java sollte sich so etwas gut Umsetzen lassen. In PHP sehe ich viele Probleme, weil man keine zentralen Application-Scope oder so hat.
Entwickler vs. Programmierer
Diese Diskussion hat bestimmt jeder schon mal geführt der in der Berufsschule den Beruf des FI-Anwendungsentwickler gelernt hat. Spätestens dann wenn einen der Lehrer erzählte, dass man vom Prinzip her ja nicht mal Programmieren können muss, um den Beruf auszuüben.
Der Anwendungsentwickler würde die Anwendung entwickeln und dann würden Programmierer die Ergebnisse in ausführbaren Code umwandeln. Das es in der Realität nicht so funktioniert, merkt man spätestens wenn einem klar wird, dass man den Beruf des Anwendungsentwicklers lernen kann, aber nicht den des Programmierers.
Es soll diese ominöse Zwischensprache geben. Der Entwickler fasst sein Konzept und seine Planung in der dieser Sprache zusammen, übergibt alles an den Programmierer und dieser übersetzt es einfach in eine Programmiersprache. Das Übersetzen ist einfach und man braucht kein fachliches Wissen über die Anwendung. Das ist die Theorie, die man lernt. Leute die glauben, dass so etwas funktioniert, glauben auch wenn man ein Buch vom Englischen in Deutsche übersetzen will, brauche man nur ein Wörterbuch, die englische Sprache zu beherrschen wäre nicht nötig, weil man schließlich kein englisches Buch schreiben will.
Nehmen wir uns mal einen JBoss-AS und entwickeln eine größere Anwendung darauf. Ich als Entwickler hab natürlich von Java und JEE keine Ahnung (ich kann ja nicht programmieren), aber ich weiß wie das System aussehen soll. Dann kommt der Programmierer, der keine Ahnung hat was ich da eigentlich mir überlegt habe oder warum es so funktioniert, weil der nur Vokabeln runter schreiben kann. Der programmiert jetzt die Anwendung in Java. Es wird dann deployed.. und .. es läuft nicht. Ich als Entwickler komme nun und guck mir den Java-Code an, wovon ich natürlich keine Zeile verstehe, aber ich sehe den Klassen-Namen, damit geh ich wieder auf meine Seite und überprüfe, ob in meiner Überlegung der Fehler lagt.......
Ein Programmierer, der nicht Entwickeln kann, ist genau so nutzlos wie ein Entwickler, der nicht Programmieren kann. In der Realität wird man diese Trennung auch nie wirklich erleben. Jedenfalls nicht auf so einem Level, wo Technologie und alles irrelevant ist.
Ich würde sogar soweit gehen, dass selbst wenn eine Person die fachlichen Anforderungen aufnimmt, analysiert, die Oberflächen, Schnittstellen und den Workflow entwirft, auch die Person die dass in Code umsetzt "entwickelt", weil es kein stupides 1:1 übersetzen ist, sondern der jetzt sich was überlegen muss, dass alles performant, sicher und ohne Fehler laufen wird. Er muss dafür sorgen, dass die Ideen des Entwicklers am Ende auch wirklich produktiv laufen können. Sollte der erste Entwickler aber schon alles bis auf dieses Level hinunter entwickelt haben, bräuchte man keinen Programmierer mehr, weil sich dass alles dann auch automatisiert in Code konvertieren lassen könnte.
Microservices
Antworten wie "Benutz einfach die Service-Methode, die liefert dir immer genau was du brauchst", sind dann aber nicht gerne gehört.
Microservices haben eben diesen Vorteil, dass viel mit Schnittstellen gearbeitet werden muss. Damit kommt dann vielleicht auch ein Gefühl dafür Service-Methoden kompatibel zu halten. Nicht einfach vorhandene Methoden von der Aufrufstruktur zu vrerändern, sondern eine neue Methode anzulegen und die alte dann mit standard Werten auf die neue weiter zu leiten.
Der einfachste Gedanke zu Microservices ist bei mir immer eine WAR-Datei. Eine Anwendung auch auf mehrere WAR zu verteilen. Die inter-Modul Kommunikation ist dann auch über URLs oder intern über vielleicht JNDI zu realisieren. Aber alles ist sehr isoliert und man kann einzelene
Teile deployen ohne dass andere auch neu deployed werden müssen.
In PHP habe ich das mit meinem Framework von Anfang an (bzw es hat sich entwickelt) so umgesetzt. Module sind 100%ig getrennt und ein Update eines Modules ist durch einfaches Kopieren in das richtige Verzeichnis möglich. Die Module orientieren sich an sich schon etwas an klassischen WAR-Dateien aus der Java-Welt. Jedes Modul bringt seine eigenen Klassen, seine eigene Admin-Oberfläche, seinen eigenen REST-Service und eben Views mit. Es ist nichts fest in Config-Dateien eingetragen, deswegen sich das System auch nicht beschweren kann, wenn ein Modul plötzlich weg ist. Das dynamische Zusammensuchen und Instanzieren von Modulen und Addons kostet natürlich Zeit, aber hält das System sehr flexibel und robust, weil meistens nichts vom Grundsystem vorraus gesetzt wird. Caching ist hier natürlich doch ein gewisses Problem, aber das kann man auch lösen. Meistens reicht es Module zu dekativieren und man muss sie nicht löschen. Neue Klassen werden einfach gefunden und Klassen bei denen sich der Pfad geändert hat sind nach ein oder zwei Refreshes meistens auch wieder da. Das System ist also im Notfall sogar in der Lage sich selbst zu heilen.
Aber in den meisten Fällen kommt ja immer nur neues hinzu.
Also jeden Teil einer Anwendung als eigenes Modul realisieren. Module isoliert von einander halten und so ein unabhängiges Deployment ermöglichen.
Ein wirkliches Problem sind dann nur Oberflächen und Oberflächen-Fragmente. Wären ich es oft über die Addons gelöst habe wäre es bei Anwendungen mit AngularJS und REST-Backend sehr viel einfacher über einzelene Templates zu realisieren, die dann immer bei Bedarf und Vorhandensein nachgeladen werden können.
Aber es ist und bleibt so erst einmal mit das größte Problem.
Wirklich "micro" sind die Services am Ende auch nicht, aber sie sind doch sehr viel kleiner und einfacher zu handhaben als eine riesige monolithische Anwendung, wo alles von einander abhängig ist und eine Änderung an einem Teil theortisch Auswirkungen auf andere Teile haben kann, weil man nicht sicherstellen kann, dass nicht andere Entwickler die geänderten Klassen wo anders auch direkt verwenden. Auch wenn Microservices nicht die Lösung für alles ist und viele Problem
dadurch auch nciht gelöst werden können, sollte man wenigstens das Prinzip der isolierten Module und deren Fähigkeit unabhängig von einander deployed werden zu können aus diesen Konzept mitnehmen. Wenn das Deployment dann nur noch 5 Sekunden an Stelle von 30 Sekunden dauert, hat man oft gefühlt schon viel gewonnen. (Ich hab mit solchen Zeiten gearbeitet und es ist sehr nervig immer solange warten zu müssen nur um eine kleine Änderung in einer Zeile testen zu können!)
DevOps oder "warum man alles besser selber machen sollte"
Dieses Konzep ist jetzt nichts neues. In kleine Firmen ist sowas einfach normal (und läßt sich nicht ändern, weil man einfach zu wenig Personen hat und man alles eben übernhmen können muss) und in großen Firmen setzt sich sowas wohl auch immer mehr durch. Wenn man meine Arbeit betrachtet, könnte man auch mich als DevOp bezeichnen.
Dann wäre ich voll hip und modern. Aber am Ende will ich dass nicht unbedingt sein. Arbeitsteilung ist an sich gut und bringt viele Vorteile:
* Man kann sich auf eine Sache konzentrieren
* Wissen ist nicht in einer Person konzentriert (Wenn diese Person ausfällt bleibt Wissen vorhanden)
* Es ist alles transparenter, da mehrere Leute eingebunden sind
* Man kann sich nicht überall perfekt auskennen, deswegen sollte man nichts machen, wo man sich nur halb auskennt, wenn jemand da ist der sich damit besser auskennt
Warum aber gibt es diesen DevOps-Gedanken und warum soll damit alles so viel schneller und einfacher gehen?
* Weil es unglaublich schwer ist brauchbare Schnittstellen zwischen Teams und Abteilungen zu etablieren
* Weil es schneller geht etwas selber zu machen, als jemanden es zu erklären und einzuarbeiten
* Weil man nicht viel Doku schreiben muss, weil man es ja selber schon alles weiß
* Weil die Software so komplex ist, dass Deployment und Fehler-Analyse nur mit tiefgreifenden Kenntnissen der Software möglich ist
* Weil Menschen schlecht skalieren... weil Menschen bei der Zusammenarbeit viel Overhead erzeugen
Das Problem ist einmal die Schnittstellen innerhalb der Firma sowie deren Prozesse und einmal die Komplexität der Software. Gerade im Java-Bereich (JEE) ist es sehr ausgeprägt. Frameworks. Es gibt tausende von Frameworks. Für jeden Zweck und wenn man alles kombiniert und alles an Libs in den richtigen Versionen hat, hat man meistens schon so ein komplexes Konstrukt, dass es dann schon oft eine Tagesaufgabe ist den Workspace auf einem anderen Rechner einzurichten.
Einen JBoss/Wildfly zu installieren, zu starten und zu stoppen ist ja noch gut möglich. Datasources einrichten und Anpassungen vornehmen braucht schon etwas wissen. Wenn man dann für eine Anwendung noch eigene Module und Adapter braucht, wird es oft schon so speziel und spezifisch für die eine Anwendung, dass man ohne grundlegendes Wissen schnell Probleme bekommt.
JPA, Logging, Module + Versionen... alles exakt so einrichten, dass es so läuft wie auf dem Entwicklungsrechner.. viel Arbeit.
Bevor man nun anderen Personen alles erklärt und dann bei Problemen tausend nachfragen kommen, denkt man sich oft: "Mache ich es doch lieber selber!".
Also am Besten einfach alles genau so übernehmen wie es auf dem eigenen Entwicklungsrecher eingerichtet ist. Aber jede Änderung abgleichen ist natürlich auch doof. Deswegen wird all das möglichst mit in die Anwendung gezogen. Besonders die Konfiguration.
Ich erinnere mich noch an meine ersten Web-Projekte mit dem Tomcat. Damals noch mit Tomcat 4. DataSource hab ich in der server.xml eingetragen und mein Projekt als WAR deployed. Dann lief es. Es gab nur die DataSource mit einem bestimmten JNDI-Pfad. Wenn diese vorhanden war lief es. Die WAR jemanden zu geben, der sie dann deployte war kein Problem.
Aber dass war dann irgendwann nicht mehr so toll, weil für jede deployte Anwendung die server.xml anzupasen war nicht toll. Die Server wurden von Administratoren verwaltet, die aber sich nicht wirklich mit Tomcat auskannten und die zentralle server.xml anzupassen konnte natürlich dazu führen, dass andere Anwendungen dann nicht mehr liefen, wenn man was falsch machte.
Also wanderte viel die in context.xml. Mit JPA kam noch die persistence.xml dazu und weil man ja Unit-Tests machen wollte, hat man den Datenbank-Server dort direkt eingetragen und keine Datasources von der Server-Umgebung mehr verwendet. Das Logging ging auch gleich mit in die Anwendung und die Anwendung hat bestimmt in welche Datei gelogt wurde und was wie gelogt wird. Wenn man mal was anderes
Loggen wollte.. tja.. Anwendung neu bauen und neu deployen.
Wenn man jetzt noch mehr Framworks hat, die auch gerne Config-Daten haben wollen, nimmt man natürlich die auch gleich mit rein, weil der Entwickler es ja einmal alles eingestellt hat und man die Dateien dann nicht kopieren muss oder am Ende sogar noch mal komplet selbst anlegen muss.
Man bekommt also eine komplet vorkonfigurierte Anwendung die man dann deployed, die aber dann auch nur für diesen ganz speziellen Fall funktioniert. Datenbankserver ändern oder URLs zu externen System wechseln.. das geht nicht so einfach und die Anwendung muss komplett neu gebaut werden, wenn sowas mal passieren sollte.
Das macht natürlich alles für die Server-Admins simpler, da einen sauberen Server zu installieren einfach ist. Der Entwickler übernimmt dafür alles. Konfigurierbare Anwendungen sehe ich immer seltener. Was aber den Admins natürlich auch einen Teil der Kontrolle über die von denen betreuten Systeme nimmt und das gefällt natürlich auch nicht wirklich.
Was wären Lösungen? Schwer zu sagen. Meine Ideen wären:
* Anwendungen sollten möglichst "unkomplex" sein
* Die Anwendung sollte nicht vorkonfiguriert sein bzw die config sollte sich im Server überschreiben lassen
* Der Admin sollte sich mit der Umgebung auskennen und sollte wissen wie man die Anwendung und Umgebung konfiguriert
* Einfaches Deployment: Anwendung + Deployment-Descriptor (Config-Daten) in die Umgebung kopieren und Deployment starten
* Anwendungen sollten gut von ein ander isoliert sein
* Anwendungen sollten sich von Außen so gut anpassen und konfigurieren lassen, so das der Admin mit etwas Glück kleine Probleme beheben kann ohne das Code angefasst werden muss
* Die Umgebung aus AppServer/Servlet-Container mit einer Zusammenstellung der benötigten Frameworks sollten bei allen Projekten standardisiert werden. Also eine Person stellt immer aktuelle Zusammenstellungen zusammen, die dann von den Entwicklern verwendet werden und wenn möglich auch immer auf die aktuellen Versionen updaten.
Natürlich sollte sich jeder Entwickler grundlegend mit allem von AppServer bis zum Logging-Framework auskennen. Aber er sollte sich auf die Entwicklung konzentrieren und den normalen Betrieb der Anwendungen jemanden überlassen der die Serverumgebung sehr gut kennt und dort auch Performance- und andere Probleme lösen kann und die gesamte Infrastruktur verwaltet. Die Infrastruktur ändert sich laufend und die Anwendung sollte sich einfach und unkompliziert darauf anpassen lassen. Eine XML in einem Package in einer JAR im Lib-Verzeichnis einer WAR in einem Tomcat ist genau so schlimm, als wenn man die Daten direkt hart in eine Klasse kodiert hätte. Meiner Meinung nach müssen Config-Daten (ob aus einer Datei oder der Datenbank) zur Laufzeit änderbar sein.
Aber am Ende muss man sagen, dass ich auch schon oft genug gedacht habe "Hätte ich es doch einfach gleich selber gemacht...". Man braucht Vertrauen und einen Draht zu einander. Deswegen sollte man Teams vielleicht nicht horizontal aufbauen, sondern vertikal. Die Idee, dass einer alles macht, ist wohl auch weniger die grundlegende Idee hinter DevOps gewesen. Auch dass alles wieder in Software-Tools und so enden muss, sehe ich eher kritisch, weil man Komplexität oft nicht durch mehr Komplexität lösen kann.
Am Ende darf es eben nur ein DevOp-Team geben, wenn man das Konzept umsetzen möchte. Ein DevOp in einer Person ist unsinnig bzw bedingt sich selbst. Im Team müssen die Schnittstellen und die Rücksichtnahme zwischen den Fachbereichen geschafen und gelebt werden. Man sollte also Kompetenzen nicht versuchen zusammen zu fassen, sondern diese nur dichter zu einander bringen.
Links:
http://slott-softwarearchitect.blogspot.com/2015/03/it-appears-that-devops-may-be-more.html
http://jeffknupp.com/blog/2014/04/15/how-devops-is-killing-the-developer/
https://www.codecentric.de/kompetenzen/publikationen/die-devops-bewegung/
Von Java zu PHP - Part 5 - andere Frameworks
Erinnert mich am Ende alles sehr stark an die alten JSF-Webanwendungen. Damit zur arbeiten war nicht immer einfach. Aber mit JSF2.2 soll sich da viel getan haben. Aber eigetnlich waren die Probleme immer bei den Templates zu finden und deren Unfähigkeit mit normalen HTML gemischt zu werden (damals.. zu 1.2 Zeiten).
Die Templates die ich bei Laravel und Symphony2 gesehen habe sind jetzt auch alles andere als "hübsch". Die besten Templates momentan kenn ich von AngularJS. Die sind einfach und übersichtlich.
In diesen Controller-Methoden wird dann meist der Renderer angestossen, der das Model un die View zusammen bringt und das Ergebnis wird dann von der Controller-Methode zurück geliefert.
Aber das zentrale sind immer die Routen. ORM ist dass wo sich alle unterscheiden. Aber ansich finde ich die ORMs jetzt alle nicht so berauschend. JPA ist schon sehr gut und dass hat ja auch seine Probleme. Es wäre für Anfänger in den meisten Fällen sehr viel übersichtlicher, wenn die ganzen Tutorials das ORM erstmal weg lassen würden. ORMs sind meistens der Teil wo Tutorials anfangen unübersichtlich zu werden, weil da eben viel automatisch passiert und es teilweise nicht so benannt wurde, dass man gleich erkennt, worum es geht. up() und down().. warum nicht execute() und rollback()? Dann wäre sehr schnell klar wozu die beiden Methoden gedacht sind. Auch dass man bei Laravel so viel über das CLI machen muss, finde ich eher irritierend. Der Aufruf der Views und so ist einem schnell klar. Artsan und migrate machen einfach zu viel "magic" um für einen Einsteiger ohne Vorkenntnisse sofort verständliche Ergebnisse zu liefern.
Aber an sich sieht Laravel auch nicht verkehrt aus. Es werden wohl viele SingleTons verwendet, was wohl dafür spricht, dass es ein wohl ein relativ schnelles Framework sein wird.
Gute Tutorials für Laravel sind (jedenfalls nach meinem Gefühl):
http://blog.dirk-helbert.de/blog/2015/01/24/laravel-anfaenger-tutorial-zum-mitmachen-fuer-dich/
http://www.sitepoint.com/bootstrapping-laravel-crud-project/
XDebug mit PHP
xdebug.profiler_enable=1
xdebug.profiler_output_dir=C:/test/profile
Mit WinCacheGrind dann die dort erzeugte Datei nach einem Seiten-Aufruf analysiert. Es gab wirklich einen Fehler im Class-Loader der dafür sorgte, dass das system/classes/ Verzeichnis immer wieder gelesen wurde, wenn nur die Klasse noch nicht eingebunden war, aber schon der Pfad dorthin bekannt war. Dateizugriffe kosten extrem und selbst mit den PHP internen Caches sollte man so wenige wie möglich verwenden. Übersetzungsdateien werden nun in der Session gecached. Das Einlesen war auch sehr aufwendig.
Ein dummy User-Objekt versuchte, die eigenen UserGroups zu laden. Da die Id aber 0 war kam natürlich nie ein Ergebnis aus der DB, aber der Overhead wurde erzeugt. Also eine Prüfung auf id==0 und schon lief alles besser.
Meine Grundregeln sind jetzt:
* wenige Zugriffe auf das Dateizugriff
* Caching von Daten
* unnötige DB-Connections verhindern
* Objekte instanziieren kostet viel, wenn möglich SingleTons für DAOs und ToolKits verwenden
* nur laden was man braucht
* ob JSON oder XML ist am Ende nicht so wichtig, solange die Dateien keine unnötigen Daten enthalten (schnell Parsen und Cachen)
* Profilling ist wichtig und sollte man immer mal wieder machen (auch ohne konkreten Anlass)
* Das Bootstraping des Frameworks/der Anwendung muss schnell sein, der Rest liegt in der Hand des Entwicklers und er sollte so entwickeln können, also würde das Framework keine Zeit benötigen (er soll sich auf seinen Code konzentieren können)
Wichtig bei der oben gezeigten Config in der php.ini ist, dass dasVerzeichnis shon exisieren muss,da xdebug es nicht von sich auch anlegen würde.
PHP und UTF8
Das wird noch etwas Arbeit bis hier alles wieder normal aussieht.
http://blog.al-aqel.com/programming/fix-and-store-unicode-in-mysql-php hilft aber gut bei den Grundlagen alte Scripte umzustellen. Ich hab es jetzt so umgebaut, dass das Datenbank-Layer für UTF-8 verantwortlich ist und der Rest kann jetzt darauf vertrauen UTF-8 String zu bekommen.
Doku-Schreiben oder das schmelzende Gehirn
Dann hast du wohl denn ganzen Tag Doku geschrieben.
Doku schreiben schlaucht einen irgendwie immer extrem. Endlose Listen von Klassen, die man alle beschreiben soll. Bei den meisten ist vom Namen her schon eigentlich klar was die machen und bei den wenigen Ausnahmen, weiß man nicht wie man es gut Beschreiben soll oder ob man gleich refactoren sollte.
Der der das Projekt übernimmt soll ja möglichst ohne die Doku damit zurecht kommen. Die Doku sollte nur zur Einleitung und bei Unstimmigkeiten bemüht werden.
Nach ein paar Wochen intensiven Doku-Schreibens habe ich mir folgende Regeln aufgestellt:
* Pausen machen und abschalten. Dann noch mal in Ruhe das davor geschriebene nochmal lesen bevor man weiter macht
* Die Punkte für den Tag aufschreiben und abarbeiten
* dazu am Besten noch sich den Roten-Faden vorher auf schreiben (habe ich am Anfang nicht gemacht und bereue ich jetzt sehr)
* Sich lieber mal wiederholen als irgendwelche Verweise auf andere Textstellen einbauen
* Immer auch beschreiben, warum etwas so gemacht wurde und welche Überlegungen und Ideen dahinter stehen
* Wenn man auf nicht mehr verwendete Klassen, Code, etc trifft.. sofort löschen
* lieber Refactoring als viel Text schreiben nur weil man bei einem Namen einer Klasse mal nicht gut überlegt hatte
* 10min schreiben oder 10min etwas aufräumen und in 5min beschreiben? Immer das zweite, denn dem der das Projekt übernimmt wird dadurch mehr Zeit sparen als du mehr aufgewendet hast
Was die Pausen angeht frage ich mich auch immer wieder, ob so etwas nicht fest zur Arbeitszeit dazu zählen sollte. Die Pause um den Kopf wieder so frei zu bekommen um gut weiter arbeiten zu können und Geschriebens noch mal mit Abstand neu zu betrachten geschieht nicht einfach so neben bei. Manchmal ist Pause machen schwieriger als weiter zu arbeiten, weil man sich zwingen muss jetzt an was ganz anderes zu denken... dann bleibt auch die Frage an was man dann denken soll.
Wie macht man effizient Pause?
Server-Sent Events
Nun werde ich mal gucken, ob ich doch mal etwas damit machen werden. Benachrichtigungen über neue Posts oder doch ein Backend für einfache kleine Multiplayer-Spiele. Z.B. eine Multiplayer-Version von Bottle-Spin oder sowas, sollte sich damit relativ einfach umsetzen lassen, da man im Spiel nur noch auf Events reagieren muss und ab und zu mal über REST eine Methode aufruft. Eine bidirektionale Verbindung bei Websocket braucht auch erstmal wieder ein eigenes Protokoll. Bei SSEs hat man den Event-Type und den Payload (einfach String oder JSON) und die Infrastruktur mit den Events umzugehen ist auch schon fertig.
Mal gucken, ob ich die Zeit finde das mal irgendwie einzu bauen. Erstmal stehen andere Projekte auf dem Plan, die mal fertig werden müssen.
ReWrite-Mod und Rules
Nachdem ich dann beim Zendframewprk wieder damit kämpfen durfte, war es mir wieder klar. Get-Parameter sehen nicht toll aus, aber funktionieren immer! Wirklich immer egal auf welchen Server und mit welcher Konfiguration auch immer!
Das Zend Framework macht ja nichts anderes als mein Framework und biegt die URLs auf die index.php um und liefert dann die ursprüngliche URL zum Parsen mit. Vielleicht sollte ich doch noch mal die Rules meiner htaccess weiter verbessern, dass man doch Pages mit Namen und weiterer Beschreinung wie einer Überschrift aufrufen kann (die Beschreibung dann dynamisch auslesen oder so.. was auch bei URLs im Blog-Module toll wäre).
Wenn ich auch das Servlet-Mapping aus dem Tomcat mit dem ReWrite-Rules im Apache vergleiche.. der Servlet-Container macht es einem doch sehr viel einfacher. Da geht mal ein Punkt an die Java-Welt.
Von Java zu PHP - Part 4 - Installation
Darin legt man sich die Datei install.bat an:
../../php/php.exe composer.phar self-update
../../php/php.exe composer.phar install
starten.
Wenn man sich jetzt den Stress mit dem VirtualHost nicht machen will.. oder wir bei mir wo es einfach nicht so recht klappen wollte... kopiert man sich das Verzeichnis einfach in apache2/htdocs.
Wenn es mit dem VirtualHost nicht klappt, darauf achten dass der include der VirtualHost-Datei aus extra nicht auskommentiert ist.
Ausser dem:
Require all granted
Anstelle von
Order allow,deny
Allow from all
Dann sollte es auch klappen. Ansonsten dem hier folgen.
Older posts: