Gabi und Sascha
Tags - Kategorien : Alle | Berlin | Bücher | Fotografie | Java | Linkhalde | Weichware | Verfassung

Ich stolpere immer wieder über das Unix ln Kommando. Unter Unix ist es ja eigentlich immer so: von ist der erste Parameter, nach ist der Zielparameter. Einfach gesprochen: es ist eigentlich immer von-nach. Beim Link Kommando ln ist das anders. Dort wird erst das Ziel angegeben und dann der zu erzeugende Link. Der erzeugte Vektor ist dann aber genau umgekehrt, da der Link auf die ursprüngliche Datei zeigt. Ich gebe das beim ersten Versuch fast immer falsch an – womit ihr natürlich messerscharf schliesst: oft macht der Kohlmann das nicht.

Im Java 7 API wurde mit dem neuen java.nio.file Package auch die Möglichkeit geschaffen Links im Dateisystem zu erzeugen. Dort wurde es genau anders herum implementiert. Von Link nach Ziel. Für die Java Welt ist das konsistent. Im Zusammenspiel mit unixartigen Systemen nicht. Aber auch das werde ich irgendwann drin haben.

Der Prozess sieht so aus:

  1. Eine Mail mit Attachment kommt rein und wird unter Windows Outlook geöffnet
  2. Die Mail wird per drag 'n' drop in ein Netzlaufwerk kopiert und residiert dort dann als Datei mit der Endung msg.
  3. Der Mac User muss den Inhalt bearbeiten. Dazu muss er
    1. Die Mail vom msg Format in das emlx Format konvertieren (Apple Mail 2.x - 4.x).
    2. Die emlx Datei wird mittels Doppelklick geöffnet.
    3. Das Attachement kann mit Sichern wiederum gespeichert werden - Ordner: Documents, nicht der Ordner der emlx Datei.
  4. Das Word Dokument (docx) wird mittels Doppelklick auf die Datei mit OpenOffice geöffnet und kann letztendlich gelesen werden.

IT ist doch was grossartiges.

Ich habe heute die E-P2 auf den neuesten Softwarestand gebracht. Dafür das Olympus Master 2 Programm installiert. Also, liebe Firma Olympus, eine Restart des Macs nach der Installation ist ja so was von Windows, das geht gar nicht. Aber immerhin seit ihr sehr überzeugt von eurer Software. Glaubt sicherlich, dass der Kunde sie immer offen hat und damit arbeitet. Oder warum sonst gibt es keine Programm beenden Option?

Immerhin habe ich jetzt mit dem 24 Mb Update eine VF-3 Support. Mehr war leider nicht drin. Ausser bestimmt einigen stillschweigenden Fehlerkorrekturen. Schade, ich hatte mir eine 4x Lupe gewünscht. Zusätzlich zur 7x und 10x Lupe. Und eine 5 Bilder EV Belichtungsreihe sollte auch nur ein Software Update sein und keine neue Kamera (E-P3) benötigen.

Nachtrag: Nach einem Update auf Version 2.3 gibt es jetzt auch die Möglichkeit Programm beenden.

Am Wochenende musste ich dringend etwas mit SSH machen. Das ging aber nicht. Unser etwas angestaubter WLAN Router von D-Link (DSL-G664T) hat einen Firmware Bug der SSH nicht ermöglicht - und die anderen Netzwerke waren ausgeschaltet. Deswegen heute das betagte, wohl 10 Jahre alte, Gerät in den Ruhestand geschickt. Und durch ein neueres Gerät von AVM (FRITZ!Box Fon WLAN 7170) ausgetauscht. Jetzt geht auch SSH und ich muss nicht mehr die Nachbarnetzwerke nehmen. Raider heisst jetzt Twix.

Hardcore sind die Entwickler, die bei einem Fehler eine Exception schmeissen. Einfach so Exception, kein Subtype. Vollkommen scherzbefreit sind aber die, die nicht einfach eine Exception werfen, sonder einen InternalError. Der erbt von VirtualMachineError und die Dokumentation ist recht knapp und klar:

Thrown to indicate some unexpected internal error has occurred in the Java Virtual Machine.

Frei übersetzt heisst das soviel wie: keine Ahnung was passiert ist, aber hier geht gar nichts mehr. Wohlgemerkt, nicht für die Anwendung, sondern für die VM, dem Herz der Runtimeumgebung. Tritt so ein Fehler auf gilt es zu retten was zu retten ist, wenn dies noch irgendwie möglich ist. Ganz bescheuert wird es aber, wenn ich innerhalb von ein paar Minuten den Code so umgebaut habe, dass dieses Sub-System zwar nicht funktioniert, der Rest aber weiter machen kann als sei nichts geschehen.

Die 3. Humble Bundle Aktion ist vorbei. Ich hatte mir eine Lizenz gekauft, weil ich VVVVV genial finde. Bei den Bundle kannst du soviel zahlen wie du möchtest und bekommst die Lizenz. Ich liege über dem Durchschnitt. Und das bringt als Zusatz die Spiele der zweiten Aktion (Braid, Cortex Command, Machinarium, Osmos und Revenge of the Titans). Und oben drauf noch als Bonus Steel Storm und Atom Zombie Smasher.

Aus den Durchschnittspreisen der einzelnen Plattformen kann auch schön abgelesen werden wo der Schuh bei Spielen am meisten drückt. Linux ist mit durchschnittlich $12,03 deutlich vor Windows ($4,89).

Alles in allem ein guter Deal.

Habe vor ein paar Tagen $15 (~10€) für das aktuelle Humble Bundle investiert. Das besondere dabei: du kannst den Preis für die 5 Spiele selbst festlegen. Da ich schon die Demoversion von VVVVV genial fand und das Spiel dabei war habe ich mich dazu entschieden. VVVVV ist ein Old Fashion Jump 'n' Run Spiel, im Stil des C64. Es macht höllisch viel Spass; ist höllisch schwierig. Aber die Motivation immer weiter zu machen ist enorm. In dieser Hinsicht ist VVVVV genial. Ich kann das Humble Bundle schon wegen dieses Spiels nur wärmstens weiter empfehlen.

[SCREENSHOT VVVVV]

Im Screenshot geht es jetzt darum eine zweite Figur mit der Hauptfigur indirekt zu steuern. Dabei läuft die untere Figur nur, wenn die obere Figur unten steht… (nicht wundern, spielen :-) ).

Habe mir am Wochenende überlegt die ganzen Applikationen auf diesem Server auf aktuelle Versionen anzuheben. Bei der Blogsoftware wird das eine komplexere Geschichte. Dort hat sich fast alles geändert und ich muss neben dem CSS auch noch die eigenen Plugins umschreiben.

Dann habe ich mir das JSPWiki angeschaut. Was hat sich getan zwischen Version 2.0.x (aus 2006) die hier läuft und der aktuellen Version 2.8.2? Sogut wie nichts wichtiges im Markup. Deswegen wurde auch hier beschlossen: never touch a running system.

Wordpress würde für mich viel zu stressig sein :-)

Nachdem einblenden von EXIF Informationen bei mouseover fertig war, ging es an die Umsetzung der nächsten Idee.

Viele Bilder kommen bei dem blauen Hintergrund der Site nicht sonderlich gut zur Geltung. Besser würde es sein, wenn die Bilder vor einem dunklen Hintergrund zu sehen sind. Dazu hätte ich die Seite umgestalten müssen. Nicht, dass ich dazu keine Lust hätte. Das aktuelle Design ist schon ziemlich alt und ich mag es nicht mehr sonderlich. Aber auch bei eine Neugestaltung würde das Problem weiter bestehen. Denn ich würde niemals einen dunkeln Hintergrund mit heller Schrift verwenden. So etwas lässt sich nur schwer lesen.

Eine Abhilfe bietet der Lightbox Effekt. Den könnt ihr jetzt bei einigen Bildern einschalten, wenn ihr auf die Lampe rechts oben neben dem Bild klickt. Ausgeschaltet wird der Effekt wieder, wenn ihr auf den Hintergrund klickt. Klickt ihr auf das Bild, werdet ihr normalerweise auf ein Picasa Album weiter geleitet. Auch der hover Effekt für die EXIF Informationen funktioniert weiter. Die Diashows arbeiten auch mit der Lightbox Umsetzung zusammen.

Grösstes Problem bei der Umsetzung des Effekts war die Art, wie ich es haben wollte. Es gibt einige fertige Lightbox Module im Netz. Diese legen das Bild meistens zentral über den Fensterinhalt. Es ist dann losgelöst aus seiner Umgebung. Dies wollt ich nicht. Das Bild soll an Ort und Stelle bleiben, nur der Hintergrund soll abgedunkelt werden. Liesst sich trivial, war es auch… am Ende.

Zuerst habe ich die Lampe und die Funktionalitäten Trigger (Lampe) einblenden wollen. Dies soll nicht innerhalb des Markups angesiedelt sein, sondern nachträglich eingeblendet werden. Grund: der Effekt soll eventuell ausgetauscht order geändert werden. Ist er hart im Markup codiert sind Änderungen eine elendige Fleissaufgabe. Das Problem des automatischen einblenden mit JavaScript war recht schnell erledigt.

Problematischer war die Funktion zum Abdunkeln. Da habe ich gleich mehrere Fehler gemacht. Mir war klar, dass ich mit dem CSS z-index arbeiten muss. Im ersten Anlauf vollkommen in die Hose gegangen. Funktionierte hervorragend mit dem Chrome, aber schon bei Firefox und Safari hat meine z-index Implementierung nicht funktioniert. Karsten hat mir dann geholfen und mir ein Template gebaut, auf welchem die jetzige Lösung basiert. Dank dir dafür. Er knallt den Hintergrund beim Klick einfach als letztes Blockelement an <body>. Ich hatte es filigraner und komplexer gemacht, aber eben auch nicht funktionierend. In der Analyse liegt die Ursache für meine komplexe Lösung in der mangelnden Kenntnis des jQuery APIs.

Am kompliziertesten war hinterher die Anpassung der unterschiedlichsten z-index Ebenen. Das Twitter Widget war teilweise sichtbar, wenn die Bilder schon nicht mehr sichtbar waren. Und das jQuery cycle Plugin belegt mehrere z-index Ebenen. Zwischen all diese Ebenen musste dann der Lightbox Layer gelegt werden.

Probleme und offene Punkte

Problematisch ist jetzt noch Flash Plugins unter Chrome. Die sind auf dem Mac immer sichtbar. Beim Safari und beim Firefox (ab Version 3.6) sind Flash Plugins nicht sichtbar. Unter Windows und Linux habe ich das noch nicht getestet.

Offen: Karsten meinte, dass es unter dem IE nicht funktioniert. Würde mich über ein Feedback in den Kommentaren freuen.


Beispiel

[MENSCHEN SITZEN AUF EINER LANGEN UND BREITEN SITZBANK AUF BEIDEN SEITEN. IM VORDERGRUND LIESST EIN MANN ZEITUNG. UNGEFÄHR IN DER MITTE SITZT EIN PAAR, ER DEM BILD ABGEWAND, SIE SCHAUT IN DIE KAMERA. ES SCHEINT, ALS OB SIE SICH KÜSSEN.]
A kiss - Berlin - Alexanderplatz

Code

HTML


  <div>
    <div class='speexxThumbnails'>
      <div class='speexxThumbnail speexxPhoto' id='a_kiss_20110703' >
        <div>
          <a href='https://picasaweb.google.com/sascha.kohlmann/Menschliches#' title='Menschliches@Picasa'>
            <img src="https://lh3.googleusercontent.com/-xRbAv5Lyd3k/TgCQpdldVfI/AAAAAAAAQaQ/JTHtqlDsQG0/s640/street%25252020110619-12.jpg" width="640" height='480' alt='[]' title='' style='border-color: black' data-speexx-exif='{"Kamera":"OLYMPUS IMAGING CORP.","Modell":"E-P2","ISO":"160","Belichtung":"1/250 Sek.","Blende":"6.7","Brennweite":"22mm","Breite": "52.521172° N", "Länge":"13.413846° O"}'  class='speexxExifImg'  />
           </a><br />A kiss - Berlin - Alexanderplatz
         </div> 
      </div>
    </div>
  </div>

Javascript

Zur Zeit noch id basiert, bis sich der Code stabilisiert hat.


  // Lampen Icon einblenden
  $("#a_kiss_20110703").after("<div style='display: inline;text-align: right;  position:absolute; margin:0px; margin-left:0px; margin-top: 0px;' class='simpleLightbox'><img src='http://www.speexx.de/blog/images/icons/icon_lamp1_28x45.png' width='14' height='23' style='cursor: pointer;border:none;z-index:0' title='Lightbox on' /></div>");

  var lightuse = 0;	// Boolean zur Ermittlung Status Bildklicks

  $(".simpleLightBox").click(function() {
    if (lightuse == 0) {
      // fuege Underlay hinzu
      $('<div class="speexxImgLightBox"></div>')
          .css('z-index', '2')
          .css('opacity', '0')
          .css('background-color', '#000000')
          .animate({'opacity': '0.85'}, 333)
          .appendTo('body');

      // Sperre hinzufuegen Underlay (sonst Dimmereffekt)				      
      lightuse = 1;

      $('.speexxImgLightBox').click(function() {
        $(this).fadeOut(333, function() {
          $(this).remove();
          // Sperre wieder entfernen
          lightuse = 0;
        });
      });
    }
  });


Nächstes Ziel

Wenn sich Geo Koordinaten in den data-speexx-exif befinden, eine OSM Karte als Spoiler einblenden :-)

Ich habe mich heute morgen mal ein wenig mit jQuery beschäftigt – einfach um einmal zu verstehen, wie es arbeitet. Da ich mich wenig mit Webentwicklung beschäftige ist das eine andere Welt für mich. jQuery mach Spass. Es ist unwahrscheinlich einfach damit schnell einfache Verhalten hin zu bekommen. Die Dokumentation ist vorbildlich und das API logisch, sauber und durchdacht – zumindest der Teil, den ich auf die Schnelle überblicke.

Und damit ich auch einen Bezug zur Realität habe war die Aufgabenstellung: EXIF Daten als Overlay in den Bildern zu zeigen. Die EXIF Daten selbst habe ich im JSON Format in einem HTML 5 data Attribut des <img> Elements hinterlegt. So sind die EXIF Daten auch logisch nah bei den Bildinformationen hinterlegt. Als data Erweiterung habe ich -exif verwendet. a ich mich noch nicht näher mit dem data Attribut beschäftigt habe, weiss ich nicht exakt, ob dies semantisch korrekt ist.

Eine JavaScript Routine, basierend auf jQuery liesst bei einem hover() die JSON EXIF Daten aus und wandelt sie in eine Tabelle um. Die Tabelle wird logisch vor dem <img> Element abgelegt und mittels der jQuery fadeIn() Methode eingeblendet. Das funktioniert auch mit den Slideshows. Damit es bei den Slideshows keine Probleme mit der Aktualisierung gibt, wird diese jetzt bei einem hover angehalten. Ein Beispiel findet ihr hier.

Probleme und offene Punkte

  • Bei den Einzelansichten der Artikel wird die Transparenz des Overlays aus den CSS korrekt wieder gegeben. Bei der Artikelübersicht nicht.
    Falsches Verständnis über Selektoren und registrieren von Eventhandlern.
  • Die Positionierung bei Slideshowbildern unterschiedlicher horizontaler Breite ist nicht korrekt.
  • Wird data Attribut Semantik korrekt verwendet?
    In der beschreibenen Verwendung ist es semantisch und syntaktisch in Ordnung. Nur der Name exif ist sehr allgemein gehalten. Er sollte einen Prefix bekommen, um nicht eventuell mit später verwendeten Tools in Konflikt zu kommen. Hm… werde wohl speexx- davor klatschen.
    data-exif wurde in data-speexx-exif umbenannt.
  • Falscher Platz für Tabelle. Nicht erlaubt innerhalb eines inline Elements. Mögliche Lösungen sind entweder ein verschieben des <table> Elements vor das Anchor Element oder die Verwendung von inline <span> Elementen mit einer CSS display: table Formatierung. Leider wird letzteres auch vom IE 7 noch nicht unterstützt. Was wieder einmal beweisst: M$ Gerede über die Unterstützen offener Web-Standards ist heisse Luft.

Beispiel

[KÜHLERFIGUR EINES JAGUARS]
Mit dem Mauszeiger über das Bild fahren, um die EXIF sichtbar zu machen

Code

Contentformat des Attribut data-exif (Beispiel):


  data-exif='{"Kamera":"OLYMPUS IMAGING CORP.", "Modell":"E-P2", "ISO":"100", "Belichtung":"1/30 Sek.", "Blende":"8", "Brennweite":"42mm"}'

Bisheriger JavaScript Code

 
  $(function() {
      $('.speexxExifImg').hover(
        function() {
          var text = $(this).attr("data-exif");
          var json = jQuery.parseJSON(text);
          var toInsert = "<table class='speexxExifImgData'>";
          $.each(json, function(key, value) {
              toInsert += "<tr><td class='speexxExifImgKey'>";
              toInsert += key;
              toInsert += ":";
              toInsert += "</td><td class='speexxExifImgValue'>";
              toInsert += value;
              toInsert += "</td></tr>";
          });
          toInsert += "</table>";
          $(this).before(toInsert);
          $('.speexxExifImgData').fadeIn('fast', function() {});
        }, 
        function() {
          $('.speexxExifImgData').fadeOut('fast', function() {
            $(this).parent().find("table:last").remove();
          });
        }
      );
  });

[PICASA ICON] Oh, Mann, bei Picasa ist gerade echt der Wurm drin. [BRIEFKÄSTEN] Nicht nur endet fast jeder zweite (gefühlt) Request mit einem 500er, nein, jetzt hat es auch noch ein Bild von uns gefressen. Also nicht das Original – das liess sich zum Glück noch herunter laden – sondern die Vorschau. Im Picasa Web-Album wurde nur ein leerer Rahmen angezeigt. Egal welches Betriebssystem, egal welcher Browser. Ich hätte das Bild löschen und das Original neu hoch laden können. Aber dann hätte ich auch die Kommentare verloren. Ich habe mich also erst einmal im Google Forum zum Picasa Webalbum umgeschaut und eine Frage zum Verhalten gestellt. Die Antworten waren eher hilflos. Also die Dinge selbst in die Hand genommen (ich Held :-) )

Und das ist eigentlich ganz einfach. Google bietet die Möglichkeit Medien­inhalte auszutauschen ohne den gesamten Eintrag zu löschen. Simple mit einem HTTP PUT Kommando. Der URL ist einfach zusammen gebaut. cURL angeworfen und… Fehlermeldung. 500er. Storage ist nicht da. Nachgeschaut. Nichts hat sich geändert.

Als nächstes versucht das Bild mit einem anderen Bild auszutauschen. Kein 500er, die Vorschaubilder werden angezeigt. Also noch einmal das Original­bild versucht. Und wieder ist er da der 500er. Aber… oh Wunder, das Bild wurde trotzdem ausgetauscht und alles ist wieder in Ordnung.

Softwarentwickler sind Gärtner, keine Ingenieure, so schrieb Chris Aitchison vor einiger Zeit in seinem Blog. Mit einem Teil der Aussage kann ich etwas anfangen: Soft­ware­ent­wick­ler sind keine In­gen­ieure. Aber auch die Analogie zu Gärtnern halte ich für Unfug. Soft­ware­ent­wick­ler sind… Soft­ware­ent­wick­ler. Ich habe früher auch mal versucht so eine Ana­logie zu finden. Ich bin bei Handwerker gelandet. Und davon inzwischen wieder abgekommen. Alexander hat es einmal mit Köchen versucht (ich finde den Link nicht wieder). All diese Ana­logien haben ein Problem: Sie sind Unsinn.

So etwas wie Software hat es vor der Erfindung von Soft­ware nicht gegeben. Es hat nicht einmal ähnliches gegeben. Deswegen sollten wir auch nicht immer wieder versuchen Analogien zu etwas zu suchen, zu dem es keine Ana­logien gibt. So schwer es uns auch fällt, weil wir immer wieder versuchen neues in unser bekanntes Weltbild zu pressen.

So ist es auch mit dem Internet. So etwas wie das Internet hat es zuvor auch nicht gegeben. Nicht einmal etwas ähnliches wie es z.B. Kutschen und Autos sind. Deswegen muss man auch immer aufpassen, wenn Politiker über das Internet reden. Auch die müssen dieses neue in ihr existierendes Weltbild pressen – wenn sie nicht damit aufgewachsen sind. Und selbst dann, das Netz ist komplexer, als sich die meisten Menschen vorstellen können.

In Java existiert das sogenannte Konzept der checked exceptions. Jede Exception, die nicht vom Typ RuntimeException ist, muss in Methoden deklariert werden, wenn sie geworfen wird. Und sie muss explizit gefangen werden, wenn eine Methode, die die Exception deklariert, aufgerufen wurde. Alternativ kann die aufrufende Methode die Exception – oder einen generelleren Typen – fangen oder weiter werfen. Soweit so bekannt, so langweilig.

Problematisch wird es wenn Methoden Mengen solcher checked exceptions werfen oder in einem try-catch Block mehrere Methoden mit unterschiedlichen checked exception aufgerufen werden. Dann kann es zu elend langen catch Sequenzen kommen. Java 7 wird hier etwas Abhilfe schaffen. Trotzdem kann es nervig sein, sich durch die Exceptionwüsten zu arbeiten.

Der grösste Vorteil von checked exceptions ist meiner Meinung nach aber der dokumentierende Charakter. Dadurch, dass eine checked exception explizit in der Methode dokumentiert wird, weiss der Entwickler was ihn erwartet – und kann entsprechend handeln. Beispielsweise ist eine meiner Lieblingsexceptions die IOException. Sie dokumentiert, dass eine IO-Operation Probleme machen kann. Passiert dies, tritt ein Problem auf, kann ich als Entwickler oft noch versuchen zu reagieren. Ich kann beispielsweise versuchen noch einmal eine Datei anzulegen, in eine Datei oder auf einen Socket zu schreiben. Erst wenn dies ein paarmal nicht funktioniert hat, hat kann aufgegeben werden. Oder ein Subtyp der Exception besagt glasklar: hier geht nichts mehr.

Würde die IOException eine RuntimeException sein, dann muss sie nicht dokumentiert werden. Weder im Code in der Methodensignatur, noch in den Javadocs. Und genau diese Dokumentation wird dann auch ganz gerne einmal vergessen. Ist dies der Fall kann ich nur erahnen, dass ein IO Problem aufgetreten ist, um entsprechend zu reagieren oder ich muss auf Verdacht eine IOException fangen. Geholfen ist mir damit nicht viel.

Leider wird viel zu oft bei Exceptions überhaupt nicht reagiert und z.B. bei Datenbankoperationen stumpf ein Rollback durchgeführt. Das Exceptions signalisieren: versuch es noch einmal oder nimm einen alternativen Weg ist bei der Geschwindigkeit, in der heute Dinge entwickelt werden leider kaum zu vermitteln. Deswegen fehlt meistens eine entsprechende Strategie im Umgang mit Exceptions. Auf Exceptions nur mit einem totalen Abbruch zu reagieren ist ein nach-mir-die-Sintflut programmieren. Qualität kann so nicht entstehen. Ich denke, dass dies einer der Gründe ist, warum sich das Konzept der checked exceptions nicht durchgesetzt hat.

Bin normalerweise schwer zu beeindrucken, was IT Dinge angeht. Aber ein x86 Emulator in JavaScript, der einen Linux Kernel im Chrome Browser bootet, das ist schon ziemlich beeindruckend.

Demnächst dann wohl auch mit VGA Unterstützung und innerhalb von Linux einen DOS Emulator starten, um Doom zu spielen :-)

42

Der Featureumfang von Java 7 wird aufgespalten. Das ist noch nichts Neues. In Java 7 (soll Mitte 2011 erscheinen) wird es ein paar neue APIs geben, nichts weltbewegendes. Etwas Syntaxsugar aus dem Project Coin. Aus Coin interessiert mich eigentlich nur der Diamond Operator. Weniger Code ist immer gut. Das Closures verschoben werden ist nicht so wichtig. Schmerzhafter ist schon das Jigsaw auf Java 8 (Ende 2012) verschoben wird. Besonders bei grösseren Applikationen würde dies viele Bauchschmerzen vermeiden helfen - komme mir jetzt niemand mit OSGi. Aus meiner Sicht richtig blöde ist, dass JSR 308 (Annotations on Java Types) auf Java 8 verschoben wird. Das ist eine wirklich extrem sinnvolle Erweiterung um stabilere Systeme zu entwickeln. Und nur noch darum geht es bei der Weiterentwicklung von Java: stabilere Systeme entwickeln.

Wenn Java 8 Ende 2012 hoffentlich das Licht der Welt erblickt, dann wird es noch mindestens 2-4 Jahre dauern, bis es den Markt breiter durchdrungen hat. Das heisst also, die Features können erst 2015 oder 2016 in breitem Mass genutzt werden. Vielleicht auch noch später. Gründe: es wird sicherlich einige Unternehmen geben, die auf Java 7 wechseln werden. Sei es weil Java 6 im Jahr 2011 schon in die Jahre gekommen ist - erschienen 2006 - oder sie die neuen Features unbedingt brauchen. Nicht vernachlässigt werden darf auch die Java Enterprise Edition (JEE). Diese hängt der Java Standard Edition immer um 1-2 Jahre hinterher. Dann müssen auch die Application Server angepasst und breiter ausgerollt werden. Normalerweise überspringen Unternehmen einen Release. Ist dies der Fall, werden sie erst mit Java 9 die Java 8 Features anwendbar machen. Also irgendwann 2017 oder später.

Eine andere Strategie: die Unternehmen erkennen, dass Java 7 ist was es ist, nur ein kosmetischer Release. Erst mit Java 8 wird es wirklich interessant. Dann ist 2016 wieder realistisch. So oder so wird sich die nächsten 4 Jahre bei Java in der freien Wildbahn nicht viel tun. Auch so kann Planungssicherheit aussehen.

Habe heute den GIMP Clone CinePaint auf dem Mac ausprobiert (Version 0.23 und 0.24 auf Mac OS X 10.6.4). CinePaint kann angeblich TIFF 16 und OpenEXR Dateien verarbeiten. Also Bilddateien mit mehr als 8 Bit Farbtiefe pro Kanal. GIMP kann aktuell nur mit besagten 8 Bit Rastergrafikformaten umgehen, wie ich schon einmal geschrieben habe.

Leider hat es nicht so richtig geklappt. Der Mauszeiger wurde durch ein intransparentes Kreuz ersetzt. Laden einer TIFF 16 Datei hat funktioniert. Ebenso konnte eine OpenEXR Datei geladen werden. Die einfache Palette der GIMP Werkzeuge konnte eingesetzt werden. Durch den fehlerhaften Mauscursor war ein effektives Arbeiten aber nicht ganz einfach. Bei den Filtern musste CinePaint dann in beiden Versionen kapitulieren. Die Dialoge für die Filter wurden hinter dem Fenster mit der Grafik geöffnet. Nach dem sichtbar machen - verschieben des Hauptfensters - reagierten die Dialoge nicht auf Eingaben. Hierdurch wird das Programm unbedienbar.

Ich werde CinePaint weiter beobachten.

Die GWT-MATH Artefakte befinden sich im Maven-Repository unter com/google/code/gwt-math. Die groupId in der POM Datei ist allerdings com.googlecode.

Wie geht denn das?

Im Grunde bin ich mit Java als Sprache und als Plattform ganz zufrieden. Hier und da kann es Verbesserungen geben. Beispielsweise in der Abschottung von Subsystemen. Dies hätte ich gerne in Form eines Modulsystems und nicht als OSGi-System aufgepfropft. Bei Generics hätte einiges besser laufen können. Mit Java 7 wird jetzt immerhin der Diamond-Operator eingeführt. Autoboxing ist leider vollkommen verunglückt.

Womit ich inzwischen nicht mehr zufrieden bin ist das Schlüsselwort final und seine Semantik. Mit final wird eine Klasse oder Methode vor überschreiben geschützt. Ein Feld wird vor erneuter Zuweisung geschützt. Das Feld ist dementsprechend mehr eine Konstante als eine Variable. Langjährige Erfahrung hat allerdings gezeigt: überschreiben oder neu zuweisen wird überbewertet. Vererbt wird selten wirklich sinnvoll und echte Variablen gibt es auch eher selten.

Inzwischen halte ich es für eine bessere Idee statt final ein var zu verwenden. Also Verbung und neu zuweisen nicht explizit zu verbieten, sondern explizit zu erlauben. Code würde dadurch robuster werden. Einige sich immer wieder einschleichender Fehler würden beseitigt. Überkomplexe Vererbungshierarchien mehr durchdacht, bevor sie in Code gegossen werden. Einige der neuen Sprachen, die auf der JVM aufsetzten, implementieren var. Leider nicht die Hauptsprache Java. Schade, dass der Zug dafür abgefahren ist.

Lose, unausgereifte Gedanken.

Geräte werden immer kleiner und wir tragen immer mehr elektronische Gadgets mit uns herum. Das Telefon mit Touchoberfläche, MP3-Player und ein Netbook. Zu Hause ein Notebook oder ein Tablet der IPad-Klasse. Eventuell eine Kamera. Zwischen allen wollen Daten hin- und her kopiert werden. Das ist immer noch ziemlich kompliziert.

Eine Idee über die wir uns als Techniker einmal Gedanken darüber machen sollen ist, ein geräteübergreifendes Cut'n'Paste und Drag'n'Drop zu implementieren. Das kann über unterschiedliche Austauschmechanismen geschehen. Sei es ein zentraler Server unterstützt das kopieren zwischen den Gadgets oder es geschieht über Nahbereichsfunktechniken wie zum Beispiel Bluetooth/WLAN bzw. Kabel gebunden (z.B. USB). Ein nicht unwichtiges Feature dabei ist, dass die Ausrichtung der Geräte zueinander bekannt ist. Nur so lässt sich ein intuitives System für den Benutzer schaffen. So kann beispielsweise durch einfaches wegwischen mit dem Finger auf einer Touch­ober­fläche in Richtung des Empfänger­gerätes der Transfer initialisieren. Wird beispielsweise eine Datei rechts aus den Bildschirm herausgewischt und das Empfängergerät ist ebenfalls rechts vom Sender, so muss die kopierte Datei links auf dem Empfänger­gerät herein fliegen. Würde das Symbol der Datei rechts herein fliegen würde dies unglaubwürdig sein. Entsprechend darf kein Gerät die zu kopierende Datei in Empfang nehmen, wenn in die Richtung keine Gerät vorhanden ist. Diese Ortbestimmung ist sicherlich einer der kniffeligsten Punkte.

Alternativ kann ich mir auch eine einfache erste Lösung vorstellen. Das Empfängergerät wird ähnlich dem Mac OS Dock am Rand des Sendergerätes eingeblendet. Dies muss natürlich auch in laufenden Applikationen möglich sein. Auf diese Einblendung wird dann das zu zu kopierende Artefakt verschoben. Es erscheint dann auf dem Empfängergerät. Eventuell kann hier noch ein Menu geöffnet werden, um eine Empfangsapplikation heraus zu bestimmen.

Wichtig ist, dass die Protokolle plattformübergreifend sind. Geräte und Plattformen diversifizieren immer weiter. Implementiert ein Plattformhersteller eine solche Umgebung nur für seine Plattform, dann wird eine solche Insellösung Kunden nur wenig überzeugen. Allerdings habe ich wenig Hoffnung, dass der Wunsch des plattformübergreifens wirklich gleich umgesetzt wird.