Blog: Latest Entries (15):


File-Upload - Part 1 - Grundlagen

Ein einfacher Fileupload ist einfach zu erstellen. Ein <input> vom Typ "file" in eine Form. "method" auf "post" und "action" auf die Zielseite. enctype="multipart/form-data" nicht vergessen und schon ist alles erledigt.

Nun hat diese Implementierung natürlich ihre Grenzen und bei heuten Web-Anwendungen will man oft nicht mehr nur einfach eine Datei hochladen. Man will Bilder vorher bearbeiten und skalieren. Den Fortschritt des Uploads sehen und mehrere Dateien in einer Queue hochladen lassen. Früher nutzte man für sowas Flash.. aber Flash ist tot. Heute hat man HTML5 und JavaScript. Damit kann man alles realisieren was man sich für einen File-Upload wünscht. Die File-API hilft die Dateien zu Laden (aus einem <input> oder auch per Drag and Drop). Per Notification kann man den Benutzer über den Zustand der Uploads informieren, z.B. eine Benachrichtigung ausgeben wenn eine besonders große Datei fertig hochgeladen wurde.

Der hier entworfene File-Upload ist natürlich auch nicht perfekt, aber er funktioniert gut in mehreren Projekten und Scripte um die Hochgeladenen Dateien entgegen zunehmen und zu Speichern, lassen sich gut in PHP oder als Servlet realsieren.

Für Tests reicht ein einfaches PHP-Script:

PHP:

<?php
//see $_REQUEST["lastChunk"] to know if it is the last chunk-part or not
if(isset($_FILES["upfile"])){
file_put_contents($_REQUEST["filename"],file_get_contents($_FILES["upfile"]["tmp_name"]),FILE_APPEND);
}
?>


oder für Java (FileIOToolKit ist eine eigene Klasse wo append einfach das byte[] an eine Datei ran hängt oder damit eine neue Datei erzeugt, wenn diese noch nicht existieren sollte):

@Override
protected void doPost(HttpServletRequest request, HttpServletResponse resp) throws ServletException, IOException {
try {
String appPath = request.getServletContext().getRealPath("");

String filename = request.getParameter("filename");
for (Part part : request.getParts()) {
if (part.getName().equals("upfile")) {
byte[] out = new byte[part.getInputStream().available()];
part.getInputStream().read(out);

FileIOToolKit.append(appPath + File.separator + filename, out);
System.out.println(appPath + File.separator + filename + " saved!");
}
}
}
catch (Exception e) {
e.printStackTrace();
}
}


Wie man hier schon sieht wird die Datei nicht als ganzes hochgeladen sondern in mehreren Stücken. Das hat den Vorteil, dass man sehr sein den Fortschritt beim Upload bestimmen kann.

Das Laden einer Datei ist relativ einfach. Das Drag and Drop oder das onChange einer <input> vom Typ "file" liefern jeweils ein Event, dass die Dateien enthält (es können immer mehrere sein!).

Hier ein einfaches Beispiel, wobei ein boolean verwendet wird, um die beiden Arten zu unterscheiden:


var files = null; // FileList object
if(!nodragndrop){
files=evt.dataTransfer.files; //input
}
else{
files=evt.target.files; //drag and drop
}


Wir werden aber das Laden ignorieren und davon ausgehen, dass man ein File-Object hat, egal ob aus einer Datei oder vielleicht auch vom JavaScript-Code erzeugt (eine Anleitung wie man die Data-URL in sowas umwandelt findet man in einem älteren Beitrag, wo man lernt wie man ein Bild vor dem Upload automatisch verkleinert).

Im nächsten Teil wird das File dann in kleine Teile zerlegt.

Native-Events und AngularJS

Ich hatte zwar schon mal eine Variante dieser AngularJS Directive gepostet, aber das hier ist die verbesserte Version und sie funktioniert sehr erfolgreich im http://www.schoo-toi.net Projekt.

Anstelel von ng-change="reload()" ( das auf $scope.reload() geht) kann man nge-event="change:reload" schreiben und es geht auch $scope.reload(event) und gibt das native JavaScript Event an die Methode weiter. Um mehrere Event-Listener zu definieren kann man diese mit ; trennen. nge-event="click:open;change:reload".


var nativeEvent=function(){
return {
link:function($scope,el,attrs){
var value=attrs.ngeEvent;
console.log("init nge-event: "+value);
if(el){
var parts=value.split(/[,;]/);
for(var i=0;i<parts.length;i++){
if(parts.length>0){
var func=function(controller,method){
return function(event){
console.log("call method: "+method);
$scope[method](event);
};
};

var subparts=parts.split(/:/);
if(subparts.length==2){
var m=subparts[1].replace(/\(event \)/,"");
m=subparts[1].replace(/\(\)/,"");

var ang_element = angular.element(el);
var raw_element = ang_element[0];

raw_element.addEventListener(subparts[0],func($scope,m),false);
}
}
}
}
else{
console.log("el is null");
}
}
};
};

angular.module('xxx.directives', []).directive("ngeEvent",nativeEvent);
angular.module("xxx",["xxx.directives"]);


xxx ist hier natürlich nur ein Platzhalter.

JavaFX, FXML vs HTML5, AngularJS

Ich durfte jetzt doch einige Monate mit JavaFX für den Client meiner Anwendung verbringen. JavaFX wurde mir gegenüber jeden Falls als der große Heilbringer beworben. Es wäre Swing, SWT und HTML5 weit überlegen. Es wäre schneller und würde Oberflächen ermöglichen die mit HTML nie möglich wären (im besten Falle mit Flash) und würde auch einfach Dinge können, die mit HTML5 unmöglich wären.. Drag and Drop zum Beispiel.

Weitere Vorteile wären, dass man es im Web verwenden könnte, weil es ja als Applet liefe und man könnte es ohne Probleme auf Tablet laufen lassen. Mit VMs von Drittanbietern sogar auf iOS. Android sowie so.

Die Logik meiner Anwendung ist komplett in einem REST-Service implementiert und somit macht der Client wirklich nur eine Sache: Daten und Masken darstellen.

Ein weiterer Vorteil soll auch sein, dass man super einfach selbst Oberflächen zeichnen könnte und man somit nicht auf fertige Komponenten angewiesen wäre. Und das aller Beste wäre FXML wo man die Oberflächen mit einem GUI-Designer bauen könnte und keinen Code schreiben müsse. MVC und Templates. Auch gäbe es super viele Hilfen im Internet.

Also wäre noch auf HTML5 setzen würde, würde auch schlechte und veraltete Technologie setzen.

Jetzt nach dieser Zeit mit JavaFX weiß ich eins, der viel beschworene HTML5-Killer ist JavaFX bei weitem nicht. JavaFX hat noch unglaublich viele Bugs und Probleme. Es killt sich eher mal selber als HTML5. Aber gehen wir die Argumente einfach mal durch:

* HTML5+CSS5 sind sehr viel flexibler was GUIs angeht und der Code ist immer noch vom Menschen lesbar. FXML ist alles andere gut lesbar. JavaFX als Java Code ist da deutlich angenehmer als FXML.
* Flash ist tot und das aus gutem Grund. Selbst Oracle sieht in JavaFX keinen Flash-Ersatz mehr.
* Drag and Drop.. funktioniert in HTML5 sehr viel besser und mit einigen wenigen Zeilencode. Wenn mir jemand erzählt, dass es mit JavaFX in gerade mal 1000 Zeilen-Code nun alles super läuft und ich sehe dass man dafür in HTML5 vielleicht 20 Zeilen gebraucht hätte, kommt mir der Aufwand in JavaFX unglaublich groß vor.
* Applets.. ja.. wer hat das Java Plugin im Browser noch aktiv? Kaum jemand. Applets waren um 2000 rum beliebt. Wer heute noch Applets als tolle Möglichkeit verkauft Java und das Web zusammen zubringen hat die letzten 15 Jahre verschlafen.
* JavaFX und Tablets... HTML5-Apps auf Mobilengeräten sind seit einige Jahren alltag und verdrängen immer mehr native Apps. JavaFX-Unterstützung wurde erst Anfang des Jahres aus der ARM-Distribution des JDK entfernt. RoboVM soll gut laufen, aber an die optimierten Render-Engines wie Gecko oder WebKit wird eine einzelne kleine VM nicht so schnell rankommen. Da zählt auch einfach Erfahrung+Man-Power und da sind Web-Browser sehr weit vorne.

Oft hat man das Gefühl als die Wahl für JavaFX vieler nicht darauf basierend, dass JavaFX besser wäre sondern einfach auf der Ablehnung von JavaScript. Dann kommen Argument wie dass es nativ ja viel einfacher wäre auf System-Resourcen zu zugreifen... mit HTML5 ist der Zugriff auf die Kamera eines Devices sehr viel einfacher als in JavaFX (dank WebRTC).

http://de.slideshare.net/rcuprak/javafx-versus-html5-javaone-2014

JavaFX ist ein tolles Grund-Framework, aber man muss jeden kleinen Furz mehr sich selbst implementieren. Bei HTML5 ist einfach sehr viel schon mit bei (datalist für autocomplete Inputs, Inputs vom Typ "number", AJAX, gegen CSS3 ist das CSS von JavaFX garnichts). Auch das Argument "man muss ja nur einmal implementieren" ist an sich unsinnig, weil auch es kein Mal implementieren zu müssen immer noch weniger Zeit braucht als es einmal zu implementieren.
Eine vorhandene Maske hübscher zu machen dauerte bei jemanden 6h. Mit dem Vorwissen meinte er, er bräuchte nun nur noch 2h. Mit HTML hätte man ca. 20min gebraucht. Ich habe viele Masken auch noch mal in HTML nachgebaut und habe jeweil nicht Stunden sondern Minuten dafür benötigt und sie sahen dafür dann gleich gut aus.

Ein weiteres Argument für JavaFX ist immer wieder dass es eben Java ist. Java ist nicht dynamisch Typisiert was in JavaScript-Anwendungen ja immer zu Problemen führen würde. Diese Probleme konnte ich in den letzten 2 Jahren nicht mehr groß erleben. Besonders bei einem Client für einen REST-Service wo sowie so alles als String in der URL oder im Request landet ist es Ausgabe des Services die Konvertierung in die Datentypen zu übernehmen. Ich hatte bei dem Projekt nicht an einer Stelle ein Problem, dass JavaScript Zahlen und Strings verwechselt hätte.

Für JavaScript gibt es unendlich viele Frameworks. Besonders AngularJS ist hier zu erwähnen. Nun gibt es ja die Behauptung von JavaFX als HTML5-Killer, der HTML5 schon "sehr bald" überflüssig machen werde. Auch hier laufen die Argumentation meist darauf hinaus, dass JavaScript schlecht sein und Java soviel besser. Auch ansonsten sind die Argumentationen sehr interessant.

https://jaxenter.de/javafx-ist-stabiler-als-html5-und-angular-18526

Wenn man diese Argumentation nun nach vollzieht, ist die Aussage grob, dass JavaFX in seiner jetzigen Form länger bestehen bleibt, als bis AngularJS 2.0 released wird (AngularJS 2.0 wird AngularJS 1.x nicht direkt ersetzen), weil einfach bei JavaFX keine große Weiterentwicklung in nächster Zeit erwartet wird.
Ob das jetzt ein Vorteil ist.. da bin ich mir nicht sicher. Weil dann wären nur tote Technologien stabile Technologien.

Seit neusten unterstützt JavaFX nun auch endlich Dialoge. Es hat lange gedauert.

FXML... das ist noch etwas, wo ich mir nicht sicher bin was es überhaupt bringen soll. Es ist keine brauchbare Template-Lösung, da man die Bindings immer noch im Controller machen muss und auch das Befüllen der Komponenten nur im Java-Code möglich ist. Was man mit AngularJS direkt zusammen mit dem HTML-Code schreibt, muss man bei JavaFX also einmal zum Teil im FXML und zum anderen Teil im Java-Code machen. Einträge aus ResourceBundles lassen sich nur sehr schlecht verwenden, weil man diese nicht mit einfachen Strings mischen kann. Ausdrücke wie title="%time (%time_format)" funktionieren einfach nicht. title="%time_and_time_format" wäre mögich.

$http.get().success() durfte man sich so halb-brauchbar nachbauen. Aber immer hin hat JavaFX eine gute Lösung für asynchrone Vorgänge implementiert (Task), damit man Änderungen an der GUI relativ einfach trotz Berechnungen und Abfragen in einem anderen Thread durchführen kann.

Und Hilfe findet man für JavaFX meistens nicht so einfach. Für FXML sowie so so gut wie gar nicht. Wo für HTML5 oder AngularJS Probleme spätestens der 2 Eintrag bei Google eine Lösung liefert, kann es sein dass man bei JavaFX nur Verweise auf deren Bug-Tracker findet.

Insgesamt fühlt sich Entwickeln mit JavaFX an, als würde man gerade an einem Beta-Test teilnehmen. Vieles geht schon, aber es gibt noch grundlegende Bugs und einiges Fehlt auch einfach. Dokumentation ist oft nichtssagend und bei Problemen sind Lösungen oft noch einfach unbekannt.

Am Ende würde ich allein der Entwicklungszeit möglichst immer HTML5+AngularJS JavaFX vorziehen. Wer JavaScript immer noch aus einem Blickwinkel von vor 10 Jahren betrachtet, verpasst viele Entwicklungen, die JavaScript Ding ermöglichen, die vor einigen Jahren niemand für möglich gehalten hat. JavaFX hat mich nur unnötig viel Zeit gekostet und war nicht ansatzweise der Heilsbringer, der es sein sollte. Wäre JavaFX 2 rausgekommen als JavaFX 1 rauskam, wäre es eine echte Alternative für RIAs gewesen. Aber so kommt es einfach viel zu spät und würde schon von vielen anderen Technologien überholt. Wenn man eine vorhandene Java-Anwendung in SWT oder Swing um neue Oberflächen ersetzen will, ist JavaFX toll, aber eine neue Anwendung, die nicht nativ laufen muss, sollte eher portabel in HTML5 entwickelt werden und kann dan auch Desktops und Tablets laufen.

Das ist jeden Falls meine Meinung zu JavaFX.

Side-Projects und diese zu Ende bringen

Erstmal klingt es ja gar nicht so schwer, etwas was man angefangen hat zu Ende zu bringen. Bei kleineren Projekten geht es auch immer ganz gut. Aber gerade bei größeren Projekten braucht man auch die Motivation über längere Zeit. Oft beginnt man ein Projekt weil einen die Technik gerade sehr spannend und toll vorkommt. Wenn man nun längere Zeit daran arbeitet und bei Nebenprojekten kommen einfach immer mal längere Pausen hinzu, stolpert man schon wieder über die nächste Technologie mit der man gerne etwas bauen würde. Also selbst bei seinen Nebenprojekten darf man nicht jeden Hype folgen, weil man sonst nie fertig wird. Um Dinge auszutesten und neue Erfahrungen mit Technologie zu sammeln sind kleine Projekte, meiner Erfahrung nach einfach besser.

Aber selbst wenn man mit gewohnter Technologie arbeitet und auch gerade kein Hype da ist, dem man hinter laufen könnte, bekommt man manche Projekte nie zum Ende. Da würde ich zwischen 2 Sorten unterscheiden:

* Projekte, die einfach nicht weiter kommen. Hier kann es an der Technologie liegen, dass sie instabil ist oder einfach die falsche Wahl war. Denn nicht alles was neu ist funktioniert besser und bei manchen passt der eigene Stil und deren Philosophie einfach nicht zusammen, egal wie gut diese auch in der Theorie sein mag. Oder es stellt sich heraus dass das Projekt an sich in eine falsche Richtung geht oder am Anfang schon falsche Überlegungen und Annahmen getroffen wurden (Selbst wenn eine Idee, das "erst einmal drüber schlafen" überlebt kann sie sich immer noch als totaler Unsinn heraus stellen)

* Projekte die an sich fertig sind, aber wo man das Gefühl hat es würde einfach noch was elementares fehlen. Hier gilt Features allein machen noch keine Anwendung. Vielleicht ist die Anwendung zu komplex, schlecht zu bedienen oder die Features greifen nicht so perfekt in einander wie man es sich gedacht hat. Anders gesagt.. die Anwendung fühlt sich unrund an.

Während bei der ersten Sorte, die Lösung ist, es einfach sein zulassen, das Projekt von vorne zu beginnen oder einfach das nächste Projekt zu starten, besteht bei der zweiten Art ja noch Hoffnung. Hier sind meist kosmetische Änderungen die Lösung und oft hilft auch eine zweite Meinung. Ich hänge auch gerade bei so etwas. Es läuft alles perfekt, lässt sich sogar gut bedienen, aber irgendwas fehlt. Es sind nicht irgendwelche Features, wo ich sogar schon eine Idee hätte was man noch einbauen könnte (wäre mal was mit der Geolocation-API in JavaScript).

Es ist ein Image-Board was aber eher wie ein klassisches Internet-Forum strukturiert ist. Mit Benutzer-Konten, Sichtbarkeiten, etc. Man kann seine eigenen Unter-Boards erstellen, Freunde haben, daran die Sichtbarkeit einstellen aber auch anonyme Boards erstellen.. Bilder und Texte posten und nach Themen suchen. Für Smartphones mit wenig Leistung optimiert. An sich etwas wo drin ich mich auch wohl fühlen würde.
Aber ich weiß nicht warum es mir immer noch als nicht-fertig erscheint. Jede Funktion ist getestet und funktioniert. Die Optik scheint das Problem zu sein. Es ist das standard Bootstrap-Theme.
Es ist nicht individuell. Wenn ich rauf gucke fehlt die Wiedererkennung. Ein Logo ist da. Aber das ist klein und so.. ich will die Anwendung mit einem Blickstreifen und wissen dass es meine ist.

Ja.. Lösung? Doch mal versuchen ein eigenes Bootstrap-Theme zu basteln. Es scheint ja viele Seiten dafür zu geben. Leider funktionierten nicht alle und andere waren mir zu unübersichtlich. Ich hätter gerne eine direkt Vorschau.

Aber da schon mal alles läuft, habe ich sogar schon http://www.schootoi.net. Ich wollte es bis Ende Juni fertig bekommen und wenigstens im Firefox Marketplace eingestellt haben.
Aber dann ist das Ziel jetzt eben Ende Juli. Bis dahin sollte ich hoffentlich ein eigenes Bootstrap-Theme zusammen gebastelt haben. Zeit habe ich vielleicht dafür.

JavaScript-Entwickler: Wissen?

Vor doch schon einiger Zeit bin ich über diesen Artikel http://www.heise.de/developer/artikel/Hinterfragt-Woran-erkennt-man-einen-guten-JavaScript-Entwickler-2652128.html bei Heise gestolpert. Die Fragen die dort verwendet werden, um zu beurteilen, ob jemand ein guter JavaScript-Entwickler ist, halte ich persönlich für zum Teil voll kommen nichts sagend.
Gut man prüft das Wissen über die Interna von JavaScript, aber man will ja erstmal jemanden der mit JavaScript eine Anwendung schreiben kann und nicht jemand der mir eine JavaScript-Engine schreiben. Ich kann aus meiner Erfahrung heraus sagen, so wie ich JavaScript gelernt habe, dass nur eine relevante Frage dabei ist und zwar die nach den Closures. Wenn man das erstmal verstanden hat und kann sind auch die technischen Gegebenheiten hinter den Fragen davor leicht verständlich.
Die letzte Frage ist auch kaum brauchbar. Wenn ich mit einem Canvas arbeite gibt es natürlich ganz andere Probleme und Lösungen, als wenn ich viel Berechne und in Script-Timeouts laufe. Wenn ich schlecht programmiere und unnötig Methoden immer und immer wieder in einer Schleife aufrufe, sagt es auch eher allgemein was über mich als Entwickler aus und weniger über meine Fähigkeiten mit JavaScript.

Also ich würde bei JavaScript mehr auf Closures achten und wenn mir jemand erzählt sowas bräuchte man nicht. Aber mir gleichzeitig von seiner langjährigen Erfahrungen mit JavaScript erzählt und dann aber auch beim Zuweisen einer Function zu einem Object scheitert..


object.onSomething=func();


weil es wird nur einmal bei der Zuweisung die Function aufgerufen, aber onSomething bleibt null.. dann sollte man nochmal gut überlegen, ob die Person geeignet ist. (Das war jetzt ein Beispiel das sich genau so zugetragen hat.. und er hat einige Jahre mit JavaScript gearbeitet... nur eben trotzdem keine Ahnung davon)

Eclipse Mars

Morgen kommt ja Eclipse Mars raus. Es soll besonders im JavaScript-Bereich viele Fortschritte gemacht haben. Ich werde es mir auf jeden Fall dann mal ansehen.
Bis jetzt war die Unterstützung bei Eclipse zwar nicht so toll, aber immerhin besser als ein einfacher Text-Editor und hat meistens gereicht. Verbesserungen im PDT-Bereich scheint es so nicht zu gehen.. jedenfalls war untern den ersten 5 Ergebnissen meiner Suche bei Google nicht zu finden :-)

IT wächst nicht bei Ebay

In meinem Nebenjob durfte ich auch schon einen kleinen Blick in die Welt von kleinen relativ jungen Firmen werfen. Wenn man etwas an Endkunden verkaufen will, braucht man Werbung. Eine Homepage. Eine Facebook-Seite. Hübsche Bilder der Standorte und der Mitarbeiter die einen als Berater zur Seite stehen.
Computer werden schnell und günstig bei Ebay gekauft und der Rest wird schon funktionieren. Als normaler Benutzer klingt das ja ganz ok. PC kaufen, benutzen, und sonst ist da ja nicht mehr. Aber bei Firmen sind Daten einfach auch Geld und ein Ausfall kostet Arbeitszeit (=Geld). Wenn was kaput geht oder Hilfe gebraucht wird muss man jemanden holen der versucht alles wieder in Ordnung zu bringen. Das wäre dann ich.

Hier sind einfach mal ein paar Tipps, um möglichst selten Leute wie mich vor Ort zu haben.

* Kauft Dell, Lenovo, HP, etc.. mit Service-Vertrag. Wenn etwas kaputt geht, hat man schnell und unkompliziert Ersatz. Stunden lang an einem PC rum zu schrauben kostet ab dem 2 PC mehr.

* Wer nicht unterwegs ist braucht kein Notebook. Notebooks sind teurer und schlecht zu reparieren. Der günstigste PC mit Monitor ist immer noch günstiger und schneller als ein Notebook der mittleren Preisklasse.

* Kauft einen Server um die Windows Profile darauf zu speichern. Benutzer speichern das meiste sowie so auf dem Desktop. So bekommt man Datensicherung ohne viel Aufwand.

* Kauft gültige Windows Lizenzen! Bloß weil auf einen Notebook von Ebay Windows installiert ist, heißt es dass eine gültige Lizenz dabei ist.

* Die Benutzer sind keine IT-Profis. Wenn die sich daran versuchen müssen, weil an der richtigen IT gespart wird, darf man ihnen keinen Vorwurf machen, wenn mal was in die Hose geht

* IT und Homepage-Basteln sind komplett verschiedene Welten. Die einen bauen eine Homepage und die anderen halten die Firma am Laufen!

* keinen DSL-Anschluss für Privatleute sondern einen richtigen für Firmen. Es ist den Aufpreis wert, spätestens wenn man einen eigenen Web-Sever mit einer Groupware und einen Email-Server möchte

* Datenschutz. Signaturen und Verschlüsselungen kosten.. aber ersparen einen viel Arbeit, wenn es um den Datenschutz geht. Also eigener Server mit HTTPS und sonst allem verwenden!

* Backups machen!

* Immer einen Ersatz-PC haben. Wenn einer kaput geht, einfach austauschen und neu anmelden (weil wir die Profile ja auf dem Server speichern!) und schon geht es weiter. Der Ersatz-PC muss fertig eingerichtet sein und pro Standort existieren. Den anzuschliessen geht einfach und der IT-Fachmann kann sich Zeit lassen und man hat keinen Stress mit dem Ausfall von Arbeitszeit.

Mein nächstes Projekt wird dann sein, einen möglichst günstigen Server zusammen zu basteln, wo dann Profile gespeichert werden können und niemand sagen kann, dass ein Server zu teuer wäre. Alles natürlich als VM damit der Server dann mit dem Unternehmen mit wachsen kann. Ich habe bei Turnkey-Linux schon mal wohl eine gute Grundlage gesehen. Hardware muss ich mal gucken, ob von was konkreten ausgehe oder einfach einmal erkläre wie man VMWare oder VirtualBox installiert. Aber ein kleiner Tipp was man für Hardware braucht wäre wohl nicht schlecht.

Wie groß müssen Bilder eigentlich sein?

Wenn man nicht das tollste Smartphone mit dem schnellsten Internet hat, hat man öfters das Problem, dass man ein Foto macht und es dann gerne irgendwo hin hochladen möchte. Dann dauert es ewig, bricht manchmal dann mittendrin ab und am Ende hat es viel Volumen verbraucht. Nur damit die doch einiger Massen gute Kamera des Smartphones ein belangloses Foto gemacht hat, dass die volle Auflösung nicht gebraucht hätte und am Ende auf Serverseite sowie so noch mal kaputt komprimiert wird. Es wird aber selten die Auflösung noch angepasst als eher die JPEG-Qualität runter gedreht (auf etwas mal man klassisch so bei 70% oder weniger schätzen würde).

Hoch aufgelöste Bilder wo alle Details durch die Kompression kaputt gemacht wurden. Wenn es nicht in der vollen Auflösung angezeigt wird merkt man es weniger (Super-Sampling.. auch gut um Rauschen in Bildern zu entfernen). Man könnte natürlich auch das Foto schon auf dem Client/Smartphone schon so weit verkleinern, dass es nicht unnötig Volumen und Bandbreite verbraucht. Aber auf welche Auflösung sollte man das Bild runter rechnen?

Wenn der Benutzer super Qualität mit vielen Details und guten Farben am Ende erwartet.. also im Grunde genau das was er hochgeladen hat und mit etwas Glück aus einer modernen DSLR stammt.. ja.. dann ist 6MP schon Minimum. Mit minimalen Vergrößern sollte es sogar auf 4K noch hinnehmbar aussehen. Sonst muss es leider schon 10MP sein.

Aber im normal Fall wird man eine Website/Anwendung haben, die eine Reihe kleinerer Bilder anzeigt und dann bei einem Klick darauf das Bild vergrößert anzeigt. Entweder auf Vollbild, wobei oft Ränder noch da sind, sowie Bereich für Titel, Beschreibung und Datum. In vielen Fällen auch noch Platz für Kommentare.
Kaum jemand hat eine Auflösung über 1920x1200 oder 1920x1080. Also die Breite auf max 1920 oder die Höhe auf max 1080 zu skalieren wird für normale Anwendungen, die nur zum Betrachten da sind und nicht um die Bilder nochmal runter zu laden und zu bearbeiten, vollkommen reichen.

Seiten die viele Bilder halten im Zusammenhang mit Texten (Foren und Imageboards) brauchen noch sehr viel geringere Auflösungen. Selbst Seiten wie 9gag haben bis auf wenige Ausnahmen Bilder in hohen Auflösungen. Wir reden hier nur von Bildern und nicht von GIFs.. das wäre nochmal ein Thema für sich.
Außer bei diesen sehr langgezogenen Bildern wäre eine Breite über 1000 Pixeln kaum nötig. Also 1MP reicht für die meisten Zwecke. Die Vorschaubilder sind noch bedeutend geringer aufgelöst. Und auch bei Facebook reichen Bilder mit 1000px in der Breite eigentlich immer aus, wenn man nicht detaillierte Landschaften zeigen möchte.

1000x1000 Pixel sind schon mal eine ganz andere Größe. Wir gelangen da von 2MB auf gut einige 100KB. Das macht auch beim Upload extreme Unterschiede.

Ideal wäre eine Check-Box, die man setzen kann, wenn es ein Bild mit vielen Details ist. Das Problem wären normale Benutzer, die Abends in der Cocktailbar ihr Essen im Kerzenschein fotografieren müssen und keine ruhige Hand haben und nun glauben, es wäre ein hoch detailreiches fotografisches Kunst entstanden. Wenn man genug solche Benutzer hat, würde die Checkbox immer angeklickt werden, weil kein Wissen darüber besteht, wann was von Vorteil ist und dann lieber die "bessre" Qualität gewählt wird.

Am Ende bleibt die Frage, wie kann ich Bilder vor dem Upload verkleinern? Früher wurde das doch immer auf dem Server erledigt.

Mit dem Canvas-Element auf HTML5 geht es extrem einfach. Man braucht nur das Bild am img-Element vorliegen.

Beispiel (wie man an $scope sieht ist es AngularJS-Code). $scope.longestSide gibt die max Breite hier an.

var canvas=document.createElement("canvas");
var factor=1;
if($scope.newPostPreviewImage.width>$scope.longestSide){
factor=($scope.newPostPreviewImage.width/$scope.longestSide);
}

canvas.width=$scope.newPostPreviewImage.width/factor;
canvas.height=$scope.newPostPreviewImage.height/factor;
var ctx=canvas.getContext("2d");
ctx.drawImage($scope.newPostPreviewImage,0,0,canvas.width,canvas.height);
blob=dataURItoBlob(canvas.toDataURL("image/jpeg",0.7));


Wie man hier sieht ist eines der großen Geheimnise, wie man die DataURL vom Canvas wieder in
ein Binär-Object zurück wandelt, so dass es wieder wie ein normal File-Upload gehandhabt werden kann.

Den Code haben ich nach langer Suche im Internet gefunden und er funktioniert!

function dataURItoBlob(dataURI) {
// convert base64 to raw binary data held in a string
var byteString = atob(dataURI.split(',')[1]);

// separate out the mime component
var mimeString = dataURI.split(',')[0].split(':')[1].split(';')[0];

// write the bytes of the string to an ArrayBuffer
var arrayBuffer = new ArrayBuffer(byteString.length);
var _ia = new Uint8Array(arrayBuffer);
for (var i = 0; i < byteString.length; i++) {
_ia = byteString.charCodeAt(i);
}

var dataView = new DataView(arrayBuffer);
var blob = new Blob([dataView], { type: mimeString });
return blob;
}


Damit haben wir dann alles um es hochladen zu können. Wie man etwas hochlädt erkläre ich später vielleicht nochmal, aber da gibt es sonst genug Erklärungen auf anderen Seiten, die einfach und gut verständlich sind.

Aber hier kommt nochmal auf die schnelle der Code um ein Image aus einem Input des Types "file" heraus zu bekommen. Die Methode wird über das onchange-Event des Input aufgerufen.


$scope.openFile=function(event){
var files=event.target.files;
if(files.length>0 && (files[0].type.match('image.*') || files[0].type.match('image/*'))){
console.log("load file: "+files[0].name);
$scope.newPostFile=files[0];

$scope.newPostPreviewImage=document.createElement("img");
var URL = window.URL || window.webkitURL;
var imgURL = URL.createObjectURL($scope.newPostFile);
$scope.newPostPreviewImage.src=imgURL;

URL.revokeObjectURL(imgURL);

var reader = new FileReader();
reader.onload=function(e){
$scope.newPostPreviewURL=e.target.result;
console.log("add preview image");

try{
$scope.$apply();
}
catch(e){

}
};
reader.readAsDataURL($scope.newPostFile);
}
};


Hier wird die Datei in eine Object-URL umgewandelt und einmal ein img-Element erzeugt und diese Object-URL als src gesetzt. Zusätzlich wird nochmal eine DataURL von der Bild-Datei erzeugt, um ein kleines Vorschau-Bild anzeigen zu können. Die DataURL wird, wenn sie fertig
geladen ist, bei einem bestimmten img-Element als src gesetzt. Da wird über CSS skaliert. Alle Verkleinerungsoperationen werden aber auf dem internen separat gehaltenen img-Element ausgeführt.


<img ng-src=""/>

WebWorker - Eine kurze Einführung

Eine der Stärken bei Java sind die Threads und die ExecutorServices, die die Workloads auf einen festen Pool von Threads verteilen und dann die Ergebnisse Sammeln (Future<...>). Man kann natürlich auch alles in einer großen Schleife erledigen. Bei JavaScript hat man aber das Problem, dass nicht stoppende Scripte sehr schnell gestoppt werden. Das mit Timeouts zu lösen scheitert ganz schnell wenn einzelne Workloads zu lange dauern. Aus diesem Grund wurden die WebWorker entwickelt, die es erlauben nebenläufige Vorgänge in JavaScript zu realisieren und somit auch diese Probleme mit Timeouts von Scripts zu umgehen.

WebWorker und das Hauptscript kommunizieren dabei über Nachrichten, die hin und her geschickt werden. WebWorker können dabei entweder die ganze Zeit existieren oder man kann diese auch direkt nach dem erledigen der Aufgabe wieder beenden. In den meisten Fällen ist
dieses Verhalten wohl das Beste.
Man kann z.B. auch in einem Spiel AI-Gegner mit WebWorkern realisieren. Dann muss der WebWorker natürlich nach dem Starten so lange existieren bis er von außen die Nachricht erhält sich zu beenden.

Ein echt guter Einstieg in die Welt der WebWorker ist diese Seite hier http://www.webworkercontest.net

Man schreibt einen WebWorker, der gegen einen zweiten antritt und versucht möglichst viel Fläche des Spielfeldes mit seiner Farbe zu markieren. Die Kommunikation ist sehr einfach. Der WebWorker gibt über postMessage() in einen JavaScript-Object eine Direction an das Hauptscript zurück und bekommt im nächsten Schritt das Ergebnis ob der letzte Schritt funktioniert hat. Anhang dieses Ergebnisses muss der WebWorker seinen nächsten Schritt planen. Der eigentliche WebWorker ist in der onmessage-Function gekapselt.

Also schickt das Hauptscript eine Message, onmessage des Workers reagiert und darin wird mit postMessage ein Ergebnis zurück geschickt.

Das ist die Struktur nach der WebWorker funktionieren.

Die Kommunikation hat natürlich Grenzen. Ein Element aus dem DOM an einen WebWorker zu über geben und dann dort zu ändern funktioniert (wie man wohl schon erwartet hat) nicht. Wenn man mit einem Canvas etwas machen will muss man die getImageData() Methode bemühen.

Wenn man mit einem WebWorker arbeitet hat man oft den Wunsch auch hier mit Scripten aus externen JS-Files zu arbeiten. Die klassische Variante mit den <script>-Tags funktioniert hier natürlich nicht. Dafür gibt es die importScripts-Function. Der Pfad ist relativ zur Datei des
WebWorkers anzugeben.

Beispiel:

importScripts('../lib/libwebp-0.1.3.demin.js');


Anstelle von onmessage direkt im Script kann man die Haupt-Function auch natürlich über addEventListener setzen, was sehr viel sauberer
aussieht.

Beispiel:

self.addEventListener('message', function(event) {...},false);


Es sollte sowie so beim WebWorker immer "self" verwendet werden.

Die an den WebWorker übermittelten Daten erhält man ganz klassisch über das Event.


var data=event.data;


Was in den Daten drin steht hat man ja selbst bestimmt.

Am Ende der Haupt-Function wird dann das Ergebnis zurück geschickt und wenn gewünscht der WebWorker von sich heraus auch beendet. Der WebWorker kann auch von außen beendet werden, aber es ist wohl sicherer, wenn er sich selbst schließt.

Beispiel:

self.postMessage({index:i,image:result});
self.close();


So. Nachdem wir nun wissen wie der WebWorder intern funktioniert, bleibt am Ende eigentlich nur noch die Frage, wie man nun so einen WebWorker aus dem Haupt-Script heraus startet und wie man die Ergebnisse entgegen nehmen kann. Das ist aber an sich nicht wirklich kompliziert und da alles ja auch Event-Listener und Events setzt, ist nicht schwer zu erraten wie zurück geschickt Messages verarbeitet werden können.


function func(controller){
return function(event){
controller.doSomeThing(event.data);
};
};

var worker = new Worker('./controllers/webpWorker.js');
worker.addEventListener('message', func(this), false);
worker.postMessage(post);


Das Closure der Funktion ist noch das komplexeste hier dran. Der Code hier wird in einer Methode des Controllers ausgeführt und um die Verarbeitung des Ergebnisses in einer anderen Methode des Controllers durch zu führen muss eben der Controller der Function mit einem Binding an das WebWorker-Object im Hauptscript bekannt sein. Closures sind sehr wichtig und ohne diese JavaScript zu schreiben ist extrem umständlich und depremierent. Also wenn das Konzept noch nicht kennt, sich das als erstes erst einmal ansehen!

Die in "post" übergeben Daten findet man im Event im WebWorker unter event.data wieder.

Das hier war jetzt doch relativ kurz gehalten, aber zeigt hoffentlich die Hauptstrukturen sehr gut und reicht für erste Experimente.

Permission vs FileNotFound

java.io.FileNotFoundException: /daten/tomcat/_tmp/967e9_20150407_060915.jpg (Permission denied)

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

Wenn man ein Angestellter Entwickler ist und in relativ großen Teams an interner Software arbeitet, die nur durch andere Abteilungen verwendet wird, wird man nicht wirklich über den Begriff des ROI (Return of Investment) stolpern. Wenn man aber eine kleinere Firma hat und diese mit dem was entwickelt wird, ist dieser Begriff allgegenwärtig. Man bekommt nicht einfach erst einmal viel Gehalt und dann wird geguckt ob man etwas kann oder nicht. In großen Firmen ist es auch nicht so schlimm mal weniger zu können wenn man im Team arbeitet oder einfach erst einmal angenommen wird, dass man die Stärken und Begabungen noch finden muss und man vielleicht dafür eben auch mal das Team wechseln muss.

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

Vor einiger Zeit kam bei der Arbeit eine Email herum. Irgendwer wollte gerne wissen mit welchen Zeitschriften und Homepages sich der Informatik-Bereich informiert und weiterbildet. Da wenn man den Durchschnittbetrachtet natürlich nur Heise und die c't übrig blieb, hab ich mir mal meine eigene kleine Liste gebastelt. Auch um selbst mal einen Überblickt zu bekommen, wo meine Infos und mein Wissen teilweise herkommen.

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

Marketing.. ist ja nun wirklich nicht mein Fachbereich. Dafür wende ich mich lieber an andere, die sich mit so etwas auskennen. Aber zu diesem Artikel https://webmagazin.de/e-business/argumente-fuer-werbe-und-erklaervideos-infografik-44667000 muss ich dann doch mal was schreiben, weil ich doch schon einige Zeit mit dem Internet zu tun habe und man auch viel zu diesen Thema zu lesen ist.

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

Nachdem ich mich in den letzten Tagen irgendwie mehr wieder Services und Service-Strukturen
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

Mein Komemntar zu https://jaxenter.de/sind-sie-programmierer-oder-software-entwickler-1545:

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.

Older posts:

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