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.
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.
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.
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.
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.
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:
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.
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.
Am Ende hab ich jetzt doch das Alcatel One Touch Fire per Hand auf Firefox OS 1.4 gebracht. Läuft soweit auch sehr gut. Keine Probleme mit Akku oder so, aber ganz so geeignet für den normalen Nutzer ist das Selbst-Flashen dann doch nicht. Die Treiber über den Geräte Manager zu installieren ist an sich noch ganz einfach. Batch-File zum Flashen starten und Ein/Aus-Taste + die - Zaste für die Lautstärke drücken,
wenn der Startbildschrim auf dem Handy auftaucht ist auch nicht so schwer.
Dann läuft es durch und blieb bei mir mit einem Fehler hängen. recovery.img wurde nicht gefunden. "something went wrong".. ok.. Handy reagiert dann auch nicht mehr, oder ich hätte 10min warten sollen. Akku raus und wieder rein. Handy startet und möchte dann neu eingerichtet werden. Kurzer Blick ins Menü.. 1.4 ist trotzdem fehlerfrei installiert worden.
Was man nun noch tun muss:
* Entwickler-Menü aktivieren
* darin den Hardware-Composer abschalten. Dann läuft auch Wormy wieder ohne zu extremes Ruckeln
* USB-Speicher wieder aktiveren. Sonst wird das Handy zwar als Laufwerk erkannt, aberman kann nicht drauf zu greifen. Verwirrend
* Wenn gewünscht noch mal die Debugger-Einstellungen anpassen.
Am Ende lief es dann auch mit dem App-Manager im Firefox und ich konnte Apps zum Handy pushen.