Microservices

Neben DevOps hört man viel über Microservices. Oft sogar zusammen. Der gute Gedanke bei Microservices ist meiner Meinung nach jeden Falls, dass eine gute Modularisierung angetrebt wird. Etwas was ich auch immer in meinen Projekten versuche, aber viele doch es immer wieder für zu kompliziert halten und bei riesigen monolithischen Klötzen bleiben wollen. Aber sich auch dann beschweren, dass das Deployment immer so lange dauert und dass einige Entwickler einfach so frech waren und ihre Methoden geändert haben. Bei diesen riesigen monolitisches Klötzen ohne Abschottungen neigen viele dazu direkt mit fremden Klassen oder NamedQueries zu arbeiten. Wenn ich aber eine Service-Fascade hat und dort meine Methode auf eine andere interne umleite, die sehr viel schneller ist als die alte und die alte entferne, kommen Beschwerden, weil die eine Methode nicht mehr auffindbar ist und ein anderer Teil der Anwendung jetzt nicht mehr funktioniert.
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"

Irgendwie hört man momentan über all von DevOps. Ein DevOp ist wohl jemand der nicht nur entwickelt sondern auch den operativen Betrieb mit überwacht und diesen vielleicht auch komplett in Eigen-Regie betreut. Jedenfalls liest man solch eine Interpreation oft (ob diese jetzt die korrekte Interpreation ist sei mal dahin gestellt...).
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

Im Grund ist das, was die meistens Frameworks machen, doch irgendwie sehr primitiv. Das OR-Mapping jetzt mal dabei nciht berücksichtigt. Es geht eigentlich immer darum ein URL mit der Hilfe der definierten Routes auf die Methode einer Controller-Klasse zu lenken. Dabei ist die Methode manchmal noch durch eine Action definiert.
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

Profilling ist wichtig. Das klassische Rausschreiben von microtime()-Werten ist nicht wirklich verlässlich, gerade wenn das Bootstraping und die Class-Loader teilweise vorher laufen. Da bei meinem Framework die Verbesserungen in der Performance zwar immer ein wenig was brachten, aber der Rest immer noch länger dauerte als der Code vermuten lies, habe ich mal xdebug aktiviert.

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

Wenn man Java gewohnt ist, ist es egal wo was her kommt.. solange es ein String ist, kommt es immer richtig raus. Bei PHP kann sich das alles noch toll mischen. String aus UTF8-Dateien, aus der Datenbank und aus anderen Quellen. Auch wenn alles aus Objekten kommt, kann es dann sein, dass ein Teil richtig dargestellt wird und ein anderer Teil nicht. Nervig! Werde ich also gerade für die neuen Module nochmal etwas nacharbeiten müssen.

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

Du kannst keinen klaren Gedanken mehr fassen? Du hast das Gefühl dein Gehirn wäre geschmolzen und nur noch ein Haufen Matsch? Du hast eine komplexe Klassen-Struktur im Kopf und wunderst auf dem Weg zum Auto warum dein Autoschlüssel sich da nicht richtig einfügt?

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

Eine der Sachen die ich mir schon immer mal ansehen wollte und nie dazu gekommen bin. Aber jetzt bin ich wirklich mal dazu gekommen und es hat sich mal wieder heraus gestellt, dass sich das sehr einfach implementieren auf JavaScript-Seite. Die Server-Seite ist da dann doch etwas komplexer aber sieht sehr viel einfacher aus als WebSocket-Server, da man alles über eine einfache Seite publishen kann und nicht Server intern eine Liste mit den Connections zu den Clients selbst pflegen musst.
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

Beim Zend Framework 2 muss man sich ja wieder mit ReWrite-Rules und sowas auseinander setzen. Beim der REST-Implementierung in meinem Framework habe ich die ja auch benutzt und mußte mich erstmal wieder mit dem Syntax auseinander setzen um auch die Request und Get-Parameter mit zu übergeben. Ich fragte mich dann warum ich nicht von anfang an darauf gesetzt hatte, weil man so ja auch Domain mit Text und Namen drin einfach realiseren kann.
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

Das Zendframework zu installieren sieht erstmal komplexer aus als es ist. Hier wird es gut erklärt. Wenn man mit dem WAMP-Paket von Bitnami das Framework mit installiert hat, findet man es unter frameworks/zendframework

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.

Passwörter

Ich versteh nicht warum so viele Personen Passwörter so negativ gegenüber darstehen. Passwörter sind wichtig und schützen einen. Aber es sind oft auch die Menschen, die das Internet grund sätzlich als unsicher ansehen und glauben jeder könnte jetzt alles von denen sehen. Aber in Firmen sollte es den meisten schon klar sein, dass man sich damit nicht nur selber schützt sondern auch seine Kunden. Also Datenschutz und so.
Windows 7 hat ein Problem. Man muss das Admin-Konto per Hand aktivieren:

net user administrator * /active:yes

Ideal wäre es, wenn man ein admin-Konto und ein normales Konto anlegen müsste. Das automatische Einloggen, sollte nur mit Konten gehen die keine
Admin-REchte haben und man sollte dann das Passwort für das Konto auch nur über eine Admin-Konto setzen dürfen. Nachdem ich erlebt hat wie eine Person 5 Rechner lahm legen konnte, nur weil dort plötzlich ein Passwort gesetzt wurde, sehe ich es als noch dringender an, auch alles über einen Server laufen zu lassen. Denn dann hätte man dort einfach das Passwort nochmals neu gesetzt und alles wäre wieder ok gewesen. Aber sowas kostet ja und viele kleinere Firmen sparen sich das Geld lieber, was man Ende dann bedeutet, dass jemand wie ich Geld damit verdient, Festplatten an USB-Adater zu hängen udn Daten zu kopieren.. da wäre ein Server nach 5 Rechnern schon fast günstiger gwesen, wenn man noch den Arbeitsausfall der Mitarbeiter dazu rechnet.

Magento Email-Templates

Das grobe Konzept habe ich wohl so weit verstanden. Erstmal müssen die keine wohl geformten XML oder HTML Dateien sein. Also man kann ein HTML-Dokument einfach in der Mitte teilen und als Header und Footer verwenden und in der Mitte wird dann einfach was dazwischen eingefügt bzw wird eher der Header und der Footer vor bzw hinter den speziellen HTML-Code eingefügt, wo durch ein komplettes Dokument entsteht.
Wenn Header und Footer nicht angezeigt werden ist es nicht schlimm. Es wird wohl nur angezeigt was die Core-Templates überschreibt. Also "neu" und dann das Core-Template auswählen und schon kann man seine eigene VErsion davon erstellen.

Von Java zu PHP - Part 3 - Alle Kochen mit Wasser

Nachdem mir geraten wurde, als Einstieg in das Zend Framework 2 mich mit der Skeleton Application auseinander zusetzen, bin ich auf einen doch ganz guten und verständlichen Artikel gefunden, der alles in kleine und verständliche Brocken herunter bricht. Geht es nur mir so oder haben auch andere Probleme mit diesen Tutorials und Beispiel die immer alles im Kontext einer einzelnen riesen Anwendung erklären wollen, anstatt in einigen kleinen und einfachen Code-Beispielen die fachlich nichts machen außer dass eine was zu zeigen ist zu zeigen?

Jedenfall hat der Artikel sehr Recht damit, dass am Ende alle mit Wasser kochen und es im Zend Framework 2 auch nur Lösungen für Probleme sind, die jeder der schon mal ein Framework geschrieben hat auch hatte oder hat. Wenn man mal sein Framework mit dem fremden vergleicht, erkannt man auch viele Gemeinsamkeiten, da am Ende viele auf die selbe Lösung gekommen sind. Also sich immer an den Gemeinsamkeiten orientieren und man sollte eigentlich sich schnell in neue Frameworks einarbeiten können.

Das Bootstrapping ist im Grunde immer gleich. Config-Dateien finden und laden. Dann aus den Verzeichnissen die entsprechenden Klassen und weitere Config-Daten laden.
Was mir gleich vertraut vorkam war der ServiceManager, der von der Aufrufstruktur und der Beschreibung genau dem entspricht was bei mir de AddonManager macht. Namen angeben, man bekommt die Instance mit wobei der Manager als Factory agiert und er sorgt dafür, das nur eine Instance davon existiert und nicht unnötig viele neue erzeugt werden müssen, was ja wieder sehr kosten intensiv wäre.

Wenn es so weiter geht sollte die Einarbeitung garnicht so schwer sein.. hoffe ich.

Zu viele Plattformen

Eigentlich wollte ich mein neustes Projekt in den nächsten Tagen mal online bringen... aber eben gemerkt, dass nicht auf einen New Nintendo 3DS XL läuft. Es gibt zu viele verschiedene Plattformen und deren Namen werden auch immer länger ;-) Mal gucken ob es AngularJS liegt oder an meinem File-Upload-Code.

PHP und Annotations

Ich habe lange Zeit mit PHPclipse in einem Eclipse 3.2 mein PHP entwickelt und bin dann mit Eclipse Luna doch irgendwie mal auf die Idee gekommen jetzt PDT verwenden zu können. PHPclipse nutzte eine Code-Vervollständigung, die einfach alle Methoden aller Klassen kannte und dann diese auch präsentierte und man mußte eben darauf achten dass man die Methode der richtigen Klasse hatte.
PDT bekam es nur selten hin einen Methoden anzu bieten. Nun habe ich heraus gefunden, dass PDT auch ganz anders arbeitet und extrem gut mit Annotations zusammenarbeit.
Wenn man mit den Annotations arbeitet ist das Entwickeln an sich genau so gut wie bei Java.

/**
* @param number $index
* @return XWBlogMedia
*/
public function getMedia($index){
return $this->list->get($index);
}

Fähigkeiten verbessern

In letzter Zeit habe ich mich doch etwas mehr durch Simple Programmer gelesen. An vielen Stellen wird es doch sehr dogmatisch und erinnert an diese amerikanischen Veranstaltungen, wo einer auf der Bühne steht, etwas ruft, alle rufen es zurück und am Ende hat er das Leben aller so extrem positiv beeinflusst. Aber man findet auch vieles darauf was interessant ist und einen dazu bringt mal über eigene Einstellungen und Vorgehensweisen nach zu denken.
Da ich auch in der letzten Zeit viel darüber nach dachte wie ich mich verbessern kann und das Gefühl hatte seit längerer Zeit auf der Stelle zu treten und somit in die Situation kam mich nach langer Zeit mal wieder gut verkaufen zu müssen (wobei müssen es nicht ganz trifft, weil ich es erstmal als Versuch sah), fand ich den Artikel 24 Quick Tips to Boost Your Career as a Software Engineer sehr interessant. Zu einigen Punkten würde ich deshalb gerne meine Meinung schreiben. Vieles wie "immer
was neues Lernen und informiert bleiben" ist an sich ja jeden klar. Und auch sich auf Bewerbungsgespräche vorzubereiten sind jetzt keine Tipps, die einen erstaunen sollten.

Tip #5: Create a blog
Das erste was ich gemacht habe, nachdem ich mich dafür entschieden hatte einen neuen Job zu suchen, war meine Homepage(s) auf einen neuen Stand zu bringen. Sie sollten aktuell sein/wirken und meine Projekte gut darstellen und besonders mich gut darstellen. Es sollte nicht so aussehen als würde ich vielleicht alle 3 Monate mal was in den Blog schreiben. Also hab ich angefangen mehr zu schreiben. Am Ende guckt es sich sowie so keiner
an, wenn man sich bewirbt.. aber es ist einfach ein guter Grund mal wieder alles aufzuräumen. Und seit dem sind die Impressions und Klickzahlen auch wirklich sehr angestiegen. Chefs suchen nach einen, wenn man sich bewirbt.. also will man auch gefunden werden. Am Ende beim Bewerbungsgespräch hat natürlich niemand etwas gelesen, aber das isst dann auch egal.

Tip #7: Launch a side project
Das sollte jeder haben und wenn möglich auch zu Ende bringen. Veröffentlichen ist toll, aber wohl nicht ganz so wichtig. Ohne meine Nebenprojekte hätte ich über 5 Jahre kein PHP mehr programmiert, wüsste nicht über AngularJS, HTML5, Canvas, FileAPI von JavaScript und Web-Anwendungen an sich. Also vieles was heute sehr wichtig ist, wenn man plötzlich mit der realen Software-Entwicklung konfrontiert wird. Und es gibt nichts besseres als etwas zu schreiben, was dann auch viele Menschen verwenden und wenigstens denen wohl etwas Spaß bereitet.
Man hat was zu zeigen und was vorzuweisen. Projekt aus der alten Firma kann man ja meistens nicht zeigen sondern nur von erzählen.

Tip #8: Wake up an hour earlier each morning
Wenn man keine Familie oder Freundin und so hat.. sonst.. nö! Alternativ.. einen Hund kaufen :-)

Tip #12: Join the community
Das ist der Punkt an dem ich noch hänge. Erstmal muss man diese Community finden. Dann gerne. Aber in kleineren Städten in Deutschland ist es schwer da auch lokal was zu finden. Im Internet findet man viel, aber ohne persönliche Kontakte nutzt einen das auch nichts. Und die paar Leute die man kennt sind dann auch noch lange keine Comunity. Aber ich arbeite daran!

Tip #18: Have your resume professionally written
Ich glaube, da sollte man eher selbst schreiben und lieber ein paar mehr Leute darüber gucken lassen und mit denen darüber reden, was man verbessern könnte. Da lernt man mehr und es kostet nichts. Gut wenn man sich um einen Chef-Posten bewirbt, dann könnte so etwas gut sein. Aber für einen einfachen Job wäre es schlecht, wenn das Geschriebene und der Mensch am Ende zu weit von einander entfernt sind.

Tip #19: Make connections now, not later
Ich gehe immer noch davon aus, dass man alles schaffen kann, wenn man nur die genug Leute kennt. Selbst kann man nicht alles können., aber solange man jemanden kennt, der das dann kann, kann man das Problem lösen. Es spricht sich auch mit der Zeit herum, dass man bestimmte Probleme lösen. Dass kann positiv oder auch negativ sein. Positiv wenn man Geld verdient oder von Freunden gefragt wird. Negativ wenn man von Leuten angeschrieben wird, die sich nur melden wenn sie ein Problem haben und Hilfe brauchen. a man nicht so einer sein will. Immer Kontakt halten, irgendwann zahl es sich aus. Es ist harte Arbeit und auch ich müsste mich mal wieder mit einen Leuten unterhalten, die ich zu sehr vernachlässigt haben. Aber auch wenn es Arbeit bedeutet, über Kontakte kommt viel zu Stande! Mit der wichtigste Tipp in der Liste überhaupt.

Tip #22: Upgrade your equipment
Den Sinn sehe ich nicht. Wer sich privat weiterbilden möchte und bereit ist Nebenprojekte zu haben, hat meistens schon einen entsprechenden PC oder Notebook. Wer in seiner Freizeit auch mal ein PC-Spiel spielt hat sowie so einen Rechner der für fast alles reichen sollte. Selbst alte Rechner sind noch sehr Leistungsfähig. In den Letzten 5-7 Jahren ist nicht ganz so viel passiert. CPUs sind etwas schnelle geworden und es gibt SSDs. Ich komme mit 2x L5320 mit 1,8GHz und 24GB RAM gut zurecht und nur eine SSD wäre nochmal eine Überlegung wert, da dann die Programm mal schneller starten würden. Aber für Windows + Eclipse und XAMPP im Hintergrund reicht das alles vollkommen aus. Sellbst ein JBoss oder Tomcat oder eine VM wären kein Problem.

Tip #23: Create a personal brand
Wenn man keine Schulungen oder Seminare verkaufen will, ist das eigentlich eher egal. Gerade in Deutschland.. wenn man mich hier kennen würde, wäre alles kein Problem mehr. Aber für einen guten Job ist es kein muss, auch wenn es toll wäre zu hören: "Ach Sie sind das!".

Jedenfalls ist mir mal wieder klar geworden, dass in Firmen Hardskills gefordert werden und manch mal sogar gefördert. Aber Softskills sind meistens egal. Es heißt immer "frag doch mal rum!", aber gefördert oder Strategien, um das in einer Abteilung oder einen Team zu fördern gibt es meistens nicht oder würden als Zeitverschwendung angesehen werden.