Blog: Latest Entries (15):


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.

Performance und PHP

Um Java-Anwendungen schnell zu bekommen, habe ich schon viel gelernt. Das meiste basiert darauf möglichst viel Caching zu verwenden, andere Serialisierungen (die default Serialisierung von Java ist wirklich extrem langsam), Reflections richtig zu verwenden (method.setAccessible(true)) und am Ende eigentlich so wenig neue Objekte wie möglich zu erzeugen.
Das alles ist toll, aber man muss immer daran denken, dass Datebank- und Dateizugriffe immer sehr aufwenig sind. Dafür gibt es dann Connection-Pooling und NIO.

Bei PHP ist es an sich sehr ähnlich. Nur hat man hier das Problem, dass man keinen Application-Scope hat und somit alles auch mindestes für jeden Benutzer machen muss, um es dann in der Sesion zwischen zu speichern, was am Ende wieder Serialiserung bedeutet.
Mit Aoop habe ich viel über Performance gelernt in einem Framework auf PHP gelernt. Dateizugriffe sind
das schlimmste! SingleTon-Beans helfen um global zu vermeiden oder dass man einige Dinge mehrfach durchführen muss.
Was erstaunlich schnell ist, ist die Datenbank. Natürlich abhängig von den Daten, Struckturen und Queries. In Java wird immer gesagt, man solle ORMs verwenden und dann bei Schulungen zum Thema Performance lernt man die Constructor-Queries kennen und lernt wie man mit nativen SQL arbeitet. In PHP habe ich bis jetzt nur natives SQL verwendet und kann sagen, dass selbst ohne Connection-Pooling, es oft schneller ist als ORMs/JPA in Java.
Aber Connection-Pooling mit PHP wäre echt toll. ES geht.. über Umwege. Vor ein paar Jahren hatte ich mal mit Java-Bridge herum experimentiert und da war es dann auch relative einfach (da man eben Java aus PHP heraus aufrufen kann) auf JDBC zuzugreifen oder eben auch auf das JNDI und dich dort eine DataSource vom Tomcat zu holen. Mit Quercus habe ich hier noch nicht weiter getestet, aber ich gehe mal davon aus, dass man hier sehr viel mehr Performance bekommen kann. Quercus an sich soll schnell sein und mit Connection-Pooling und NIO sollten sich Anwortzeiten und Laufzeiten stark reduzieren lassen.

Vor ein paar Tagen bin ich auf ein seltsames "Problem" gestossen. Vieleicht lag es auch an was anderen aber es hat mich irritiert.


$pattern="";
$pattern=substr($result,$from,$len);


Das obere war immer schneller als wenn ich den Substring direkt zugewiesen habe ohne die Varibale vorher zu initialisieren.


$pattern=substr($result,$from,$len);


Das finde ich seht seltsam. Entweder greift hier die dynamische Typisierung ein... oder.. keine Ahnug.. aber ich werde mal weiter nachforschen.

Auch die moderneren MySQL-Funktionen werde ich mal durch testen. Hier köntne sich auch was getan haben.

Am Ende wäre es aber natürlich toll zu sehen was PHP7 oder die HHVM bringen würden. Wenn sie halten was sie versprechen würde für Lösungen wie Java-Bridge oder Quercus nur noch das Connection-Pooling bei Datenbank-Abfragen sprechen.

Von Java zu PHP - Part 2 - WAMP

Nach langen Jahren der XAMPP Treue habe ich heute mir mal das WAMP Paket von Bitnami installiert.
Positiv war auf jeden Fall schon mal dass ich das Zend Framework bei der Installation gleich mit installieren
konnte (ist auch sogar gleich das ZF2). Also kann ich mir dann sicher dort auch mal das Beispiel drauf ansehen oder ein neues einrichten.

Der Rest wie aoop war wieder schnell eingerichtet. Einfach Einstellungen aus der Apache Config und der php.ini übernommen. Dann Datenbank importiert und Benutzer angelegt. Lief alles gleich wieder ohne Probleme und auch das Mapping für den REST-Service funktionierte gleich.

Also wird es ab jetzt dann einfach mit WAMP weiter gehen.

Damit habe ich auch gelich den Test von aoop auf PHP 5.4.40 abgeschlossen.. wie erwartet.. lauft!

XML oder JSON Config-Files

Momentan überlege ich die auf XML basierenden Config-Dateien in meinem PHP-Framework durch JSON-Dateien
zu ersetzen. Das Parsing bei JSON scheint gefühlt schneller zu sein. Gerade bei der Implementierung der
REST-Services muss die XML-Datei mit den Mappings bei jeden Aufruf neu geparst werden und ich vermute, dass es sehr viel schneller gehen würde, wenn man mit JSON und einen assoc-Array arbeiten würde.

Ich werde wohl demnächst mal paar Tests durchführen. In Java hatte man den Vorteil, dass man die Objekte im Servlet halten konnte und es deswegen relativ egal war wie lange das Parsen dauerte, da es nureinmal erledigt werden musste. Bei PHP kann man die Methoden Mappings in der Session halten, muss aber das Object, dass als Service Endpoint agiert, jedes Mal neu aus der XML lesen.

Die neue Page-Implementierung des Framework verwendet JSON und ist alles andere als langsam dabei.

Regeln für Entwickler

Da ich mich momentan verstärkt wieder im PHP-Umfeld rumtreibe, bin ich über diese Auflistung von Tipps/Regeln für Programmierer gestolpert, die viele Probleme sehr genau erkennt. Aber meiner Erfahrung nach wird oft genau entgegen gesetzt dazu gehandelt und diese Lösungen den regelkonformen auch oft vorgezogen.

Zu 1. Technologie ist nur das Tool, aber nicht die fertige Lösung
Oft wird am Anfang eines Projektes eine Technologie gewählt und es wird Erfahrungen damit gesammelt. Bei den nächsten Projekten wird diese Erfahrung höher eingestuft, als die Erleichertungen, die andere Technologien bieten würde. Grundsätzlich kann immer mit jeder Technologie fast alles lösen, aber jede Technologie wurde mit einem bestimmten Augenmerkt entwickelt. JavaFX ist z.B. toll um vorhandene
Desktop-Anwendungen zu erweitern oder zu er setzen. Beim Versuch eine komplexere Webanwendung durch eine JavaFX-Anwendung zu erstzen wird man eher scheitern, weil die Konzepte einfach zu weit auseinander sind.

Zu 2. „Geschickt“ ist der Feind von „eindeutig“
Es gilt irgendwie die Annahme, dass es eine einfache Lösung schnell überlegt ist und wenn man länger nachdenkt eine komplexe Lösung dabei raus kommt. Ich würde behaupten, dass es genau anders herum ist. Erst wenn man alles ausreichend durch schaut hat und verschiedene Lösungswege durch gegangen ist, kann man etwas auf das Elementare herunter brechen. Nach 2h nachdenken wird die Lösung einfacher und klarer als, als wenn ich das erste nehme was mir nach 2min in den Kopf kam.

Zu 3. Nur dann Code schreiben, wenn es wirklich nötig ist
Hier würde ich nicht nur unnötigen Code und unbenutzte Funktionen aufführen sondern auch Templates, wenn es um die Darstellung geht. Es ist schlecht und bringt mehr mögliche Fehlerquellen mit, wenn ich Dinge die ich mit einem Template erledigen könnte im Code formulieren müsste. HTML-Tables + CSS in Kombination mit z.B. AngularJS ist sehr viel Übersichtlicher und da durch weniger fehleranfällig als z.B. ein TableView in JavaFX wo ich für jede Zeile und Spalte einen eigenen Renderer schreiben muss, wenn es über die einfache Darstellung eines String hinaus geht. Jeder Renderer implementiert ein bestimmtes Interface oder leitet einen schon vorhandenen Renderer ab, der wiederrum Code enthält den man nicht kennt und der aber in Wechselwirkung mit dem eigenen Code auch mal lustige Seiteneffekte haben kann. Eine Hintergrundfarbe zusetzen mit einer Angabe im style des TD oder dafür einen Renderer schreiben macht nicht nur zeitlich einen Unterschied sondern sorgt auch für viel mehr Code und weniger Übersicht.

Zu 4. Kommentare sind meist „böse“
Kommentare sind nicht verkehrt, aber meistens nutzlos und machen alles Unübersichtlich. Oft hört man "man braucht mindestens einen Kommentar der beschreibt wozu die Methode da ist. Weil wenn du nach einem halben Jahr dir deinen Code wieder ansiehst weißt du dass oft nicht mehr." FALSCH! Wer Methoden schreibt, die er nach 6 Monaten nicht mehr zuordnen kann, macht grundsätzlich etwas falsch. Zu glaube man würde vergessen was loadArticleById($id) macht, ist genau so weltfremd. Wenn man Methoden und Klassen richtig und beschreibend benennt, wird jeder der den Namen liest auch verstehen, was da passiert ohne die Implementierung betrachten zu müssen. Also keine Abkürzungen verwenden und lieber längere Namen verwenden. Wenn man das macht wird man auch loadArticleByCategoryIdAndMaxPrice($catId,$maxPrice) verstehen. Die ganz extremen wollen auch Kommentare an jedem Getter und Setter sehen, aber da wird nicht erklärt was das zu setzende fachlich bedeutet sondern nur das dort was gesetzt wird.
Also zu glauben das unnütze Kommentare besser sind als gar keine Kommentare ist meiner Meinung nach falsch.

Zu 5. Vor dem Code-Schreiben wissen, was der Code bewirken soll
Am Ende muss man die Anforderung verstanden haben. Da muss richtig Kommuniziert werden. Aber selbst wenn man es falsch versteht... niemand wird anfangen eine Methode zu schreiben, ohne zu wissen was am Ende dabei raus kommen soll. Allein wenn man sich den Methodennamen überlegt, wird man diesen Schritt ja schon erfüllen.

Zu 6. Code testen, bevor man ihn an das Qualitätsmanagement weitergibt
Entwickeln und Testen kann man nicht trennen. Wer Entwickelt muss, dass es auch testen. Alles andere würde auch unnötig Zeit kosten. Einen abschliessenden Test sollte dann jemand anderes machen. Aber die grundlegenden Tests kann man nicht auslagern.

Zu 7. Jeden Tag etwas neues lernen
Jeder kennt einen oder mehrere, der oder die mal vor Jahren etwas gelernt haben und seit dem alles immer damit lösen. Leute die immer Desktop-Anwendungen gebaut haben und Server irgendwie noch akzeptieren aber Webanwendungen für totalen Unsinn halten.
Das ist immer kein Problem, solange diese Personen nicht große Entscheidungen für ein Projekt zu treffen haben. Dann wird schnell ein Web-Client abgelehnt, weil JavaScript dynamische Typsierung nutzt. Allgemeine Tendenzen bei Entwicklungen sowie so komplett ignoriert und als Unsinn bezeichnet, wenn jemand mal was in die Richtung vorschlägt. Es wäre alles Unsicher, man hätte keine Erfahrungen, es müsste sich erst einmal zeigen ob es sich durchsetzen wird (das habe ich erst vor kurzen zum Thema Multithreading gehört), usw. Sich was neues mal wenigstens anzusehen, wird als Zeitverschwendung gesehen und mit den alten Sachen, die man schon immer nutzt, würde da ja auch irgendwie gehen. Auch wenn man die alte Technologie nutzen kann, die neuen
Konzepte bringen trotzdem oft etwas, und wenn es nur eine neue Sichtweise ist, warum etwas weiterhin so mach wie bisher.

Zu 8. Nicht vergessen: Code schreiben macht Spaß
Hier merkt man eindeutig, dass der Original-Text nicht aus Deutschland stammt. Programmieren ist eine erste Sache! Wer bei der Arbeit Spaß hat, der erledigt seinen Job ja offensichtlich nicht richtig.
Wenn man einfach und schnell zum Ziel kommt, macht es Spaß und die Qualität von Dingen die mit Spaß an der Sache gemacht werden ist meistens sehr hoch. Aber bei allen was auch so intern an Frameworks oder Libs entwickelt wird, ist leicht und schnell nie ein Argument warum etwas benutzen sollte. Leicht zu verstehen muss nichts sein, man könne ja die rudimentär vorhandene Anleitung lesen.
Anleitungen lesen ist genau so Spannen wie Kontoauszüge lesen.. was aber in Deutschland wohl immer noch als super lustige Freizeitbeschäftigung gilt. Ich habe genug interne Frameworks und Libs erlebt die einfach schrecklich zu benutzen waren. Sie machten was sie sollten, aber die Zeit um die benutzbar zu machen, galt gleich wieder als sinnlose Zeitverschwendung.
Man muss den Spaß am Programmieren sich bewahren und wenn das am Ende mit privaten Projekten umgesetzt wird.

Zu 9. Man kann nicht alles wissen
Das kann man nicht. Man muss nur wissen wo man suchen oder wen man fragen muss. Es gibt nur ganz wenige, die meinen, dass das was sie nicht wissen, damit auch gleichzeitig unbedeutend wird. Einen guten Programmierer macht nicht aus alle Klassen-Referenzen und Protokoll-Spezifikationen auswendig zu kennen. Aber wenn man etwas nicht weiß, kann es lernen und das ist leider auch immer Arbeit.

Zu 10. Best Practices hängen vom Kontext ab
Web-Anwendugnen brauchen andere Best Practices als Desktop-Anwendungen. Java ist anders als PHP. Es gibt immer viele Überschneidungen aber am Ende machen es auch gerade die kleinen Unterschiede aus. In Java sollte man den Application-Scope verwenden und nicht die Session, wenn man für die gesamte Anwendungen einmal etwas laden/parsen muss. In PHP sollte man die Session verwenden, weil es nichts auf Applikationsebene gibt.
Wenn jemand Best Practices erstellt und meint es wäre jetzt die Lösung für alles, kann man davon ausgehen, dass es mit etwas Glück für einen Fall passt oder eher für gar keinen.

Zu 11. Immer nach Vereinfachung streben
Wie schon weiter oben beschrieben wird leider oft einfach mit schnell verwechselt. Um eine einfache und gute Lösung zu finden braucht man Zeit und die sollte man sich nehmen dürfen. Die Zeit wird man am Ende wieder einsparen, weil der Code dadurch viel einfacher zu pflegen und zu erweitern ist.

Von Java zu PHP - Part 1 - Erste Gedanken

Den Großteil meiner Zeit habe und verbringe ich momentan noch mit Java. Tomcat, JavaFX, REST-Services und Clients. Neben JavaFX sehr verstärkt auch AngularJS. Nun wird es gegen Sommer dahin gehen, dass ich Java soweit hinter mir lassen werde (als Option halte ich mir Daten-Importer mit Multithreading frei.. weil da Java gegenüber einem PHP-Script doch weit vorne liegt).

Jetzt stellt sich mir die Frage wie man sich am besten in PHP einarbeitet.. wobei es eher weniger um PHP geht als um das Zend Framework 2. PHP kann ich... und ich bin der Meinung, dass wenn ich mir mein eigenes PHP Framework schreiben kann (das schon relativ viel kann und seit der Erweiterung um eine native REST-Unterstützung und das bald neue foglende Page-Format wirklich gut super für meine eigenen Apps auf Angular-Basis funktioniert), ich mich wohl auch ohne größere Probleme darin einarbeiten können sollte.
Viele Konzepte sind mir auch nicht neu und vieles er kennt man auch wieder, wenn man mal ein eigenes Framework geschrieben hat (ich bei JavaScript-Frameworks das selbe, wobei ich da beschlossen habe cJS zu Gunsten von AngularJS nicht mehr weiter zu entwickeln und cJS nur noch
für die kleinen gepackten Firefox OS Apps zu verwenden).

Erstmal muss ich heraus finden welche Umgebung zum Entwickeln unter Windows ideal wäre und man wenig per Hand nach installieren müßte. PHPStorm habe ich schon gestestet und das Generieren von Gettern und Settern ist schon mal super. Aber Eclispe ist schon mehr fertig eingerichtet.
XAMPP oder WAMP? WAMP scheint eine Zend Framework Installation mit Beispiel Modul mitzubringen.
Aber dann mal gucken ob als VM oder Installation. Eine VM mit Linux und Spiegeln des Verzeichnisses über WinSCP hätte natürlich schon seine Vorteile.

Aber meien Feststellungen bis jetzt ist, dass das Zend Framework 2 mit seinen Namespaces sehr viel dichter an Java dran ist, als die 1.x Version oder auch mein eigenes aoop-Framework.. das bald mal umbenannt wird.

Aslo werde ich erstmal in den nächsten Tagen, analysieren welche Umgebung für mich die beste ist und sich am einfachsten Installieren läßt.

Porting cJS zu AngularJS

AngularJS ist toll, das steht ausser Frage, aber an einigen Stellen, stört es doch sehr,dass man auch einer sehr abstrakten Ebene arbeitet und nicht direkt mit nativen Elementen und Events arbeiten kann, bzw etwas tun muss um an diese heran zu kommen.

Nun habe ich anfangen mein cJS als AngularJS-Direktiven zu portieren, um das beste aus beiden Welten zu haben. Hier erstmal die Umsetzung von cjs-binding-element. Damit wird das aktuelle Element in das über nge-element angebene Feld des $scope geschrieben.


var nativeElement=function(){
return {
link:function($scope,el,attrs){
var value=attrs.ngeElement;
console.log("init nge-element: "+value);
if(el){
var ang_element = angular.element(el);
var raw_element = ang_element[0];

$scope[value]=raw_element;

}
else{
console.log("el is null");
}
}
};
};

Neue BottleSpin Version

Neue Version meiner "erfolgreichsten" Firefox OS App (>4000 Installationen). Die App ist eigentlich sehr primitiv und simuliert eine sich drehende Flasche. Jetzt kann man aber auch Aufgaben eingeben, die auf-popen, wenn die Flasche stopt.
Das Interessanteste sind bei der App die CCS3-Animations, die per JavaScript angepasst werden, um das drehen bis zu einem bestimmten Punkt umzusetzen. Das drehen über ein Timeout oder Intervall in Javascript war nicht so schön wie die CSS3-Animation.

BottleSpin-Seite im Firefox Marketplace

Neue Version wartet noch auf Freischaltung und sollte zum nächsten Wochenende hoffentlich dann
freigeschaltet sein.

JavaScript und Enterprise-Anwendungen

Wenn man sich etwas mit JavaScript beschäftigt und auch sich mit Java gut auskennt, lernt man schnell die Vorteile von nicht statischen Typen zu schätzen (kein aufwendiges Parsen und Casten bei REST-Operationen auf Basis von JSON, etc). Aber manchmal fehlen Typen und so doch etwas.. hier wird sehr gut erklärt wie man moderne und struktirierte JavaScript Anwendungen schreibt, die wartbar beleiben und auch in Unternehmen dann vielleicht akzeptiert werden.

AngularJS, require.js, JQuery, TypeScript, Bower.. wird alles mal kurz angesprochen und erklärt.

Video bei jaxenter.de

HipHop vs Quercus

Schade dass es die HHVM nicht für Windows gibt, aber dafür sieht Quercus sehr gut aus. Ein kleines Script zum Hochladen von Dateien lief sofort.. demnächst wird mal aoop damit getestet. Damals mit Java-Bridge lief es mal ganz gut auf einem JBossWeb. DB Connection-Pools mit PHP wären schon eine tolle Sache.

Tine 2.0 Account wiederherstellen

Nachdem man in Tine 2.0 einen Account aus einem alten DB-Backup per Hand über SQL wiederherstellt, muss man in GROUP_MEMBERS den Account auch wieder hinzufügen und die Contact-Id überprüfen, sonst kann man den WebDAV-Service für alle Benutzer lahmlegen!

Entity not im WebDAV-Service deutet auf so ein Problem hin.

WebM-Maker.com und WebWorker

WebWorker sind cool! Mit Whammy.js

Nach meinen ersten Erfahrungen mit WebWorkern beim http://www.webworkercontest.net/ hatte ich mich lange Zeit nicht mehr damit beschäftigt. Doch als ich anfing den WebM-Export in http://www.mp4togif.com zu implementieren, musste ich auf eine 3rd-Party Lib zum erstellen von WebP-Bildern zurück greifen, um am Ende mit Whammy.js das Video erstellen zu können. Das war für den Firefox zuviel und die Script brachen regelmässig ab, da diese zulange liefen (Chrome konnte zum Glück direkt WebP aus dem Cavnas als Data-URL erzeugen).
Das Script schnelelr zu bekommen war nicht groß möglich und es auf asm.js zu optimiren ging auch nicht, da mir doch etwas die Erfahrung damit fehlte. Also am Ende kamen mir die WebWorker wieder in den Kopf. Der Test lief schon sehr gut. Leider kann man kein Canvas-Context im WebWorker verwenden, weswegen der Chrome die WebWorker nicht verwendet sondern nur alle Browser, die auf die Lib angewiesen sind.
Aber momentan bin ich mehr als zufrieden. Keine Abbrüche mehr.. auch bei Laufzeit über einer Minute. Das Updaten des DOMs macht keine Probleme und so funktioniert der Dialog mit der Status-Anzeige auch wieder ohne Probleme.

Das Konzept ist sehr einfach. Ein Post mit dem Image-Data wird an den Worker geschickt (aus einer Schleife heraus) und dieser wandelt das Bild in ein Webp im Data-URL um und schickt es zurück. Das Bild wird ein Array geschireben (der Index wurde mitgegeben).
Wenn alle Bilder wieder da sind, werden die Webps in einer Schleife Whammy.js hinzugefügt und der rendert dann das Video.
Was sehr viel schneller geht als das Erzeugen der einzelnen Bilder.

Wenn man also viel zu rechnen hat, sollte man auf jedenfall WebWorker verwenden.

Zu finden ist das Projekt WebM-Maker.com nun unter http://www.webm-maker.com

aoop 0.6 + Start von cJS

zum Jahres Ende kommt mal ein Update von aoop auf 0.6, was sich jetzt immer mehr zur Middleware für JS-Webapps entwickelt. Die Neuerungen sind:

* mehr Singletons für bessere Performance
* seperates Theme für das Admin-Panel einstellbar
* REST-Services Unterstützung im Kernsystem (definierbar über module/desploy/rest.xml)
* Login Sicherheit (Sperrung für 5min nach 3 gescheiterten Loginversuchen)
* Begonnen requireJS für JS-Module zu integrieren
* schon mal der Begin einer Entwickler-Dokumentation um selbst aoop als Middleware zu verwenden.

Download

Neben bei entsteht ein eigenes kleines JS-Framework, das Controller-Objekte für Views und passendes Databindung ermöglicht. Kein Templating.. dafür aber sehr klein und Übersichtlich. Erste Test-App gibt es schon damit:

LINK

QRCodes + Alcatel

Leider haben sehr günstige Smartphones ein Problem.. die Kamera ist so schlecht, dass das Lesen von QRCodes teilweise nicht funktioniert. Der JS-Code erkennt die Codes auf Beispielbildern, auf Fotos vom Samsung Wave 1.. nur beim kleinen FirefoxOS Smartphone will er nicht. Die Qualität ist aber auch wirklich nicht so toll.. gerade die Ecken und Kanten sind oft sehr unscharf.

ADB Helper

Wenn ein Firefox OS Smartphone nicht im App-Manager erkannt wird, einfach den ADB-Helper noch mal neu installieren. Hat bei mir jetzt schon 2 mal geholfen.

Older posts:

Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?