Dyson DC62 blinkt rot, Kundensupport reagiert prompt.

Vor gut zwei Jahren wurde ein kabellosen Staubsauger Dyson DC62 angeschaft.

Die wichtigste Eigenschaft, kompakt zu sein, erfüllt er bestens, wird er nicht benutzt verbringt er die ganze Zeit in der Ladestation an der Wand hinter einen Schrank hängend. Die Saugkraft ist wie man das erwartet und die Reinigungskraft, insbesondere wegen der Bürste ist sogar noch höher, als wie ich das von seinen Vorgängern kenne. Alleine die Wartung benötigt etwas mehr Aufwand als dass die Werbung suggeriert, der Staubbehälter muss häufiger entleert und die Bürste nachhaltiger gereinigt werden. Wer seinen Staub nicht zweimal sehen möchte ist mit einem Staubbeutel-Sauger besser bedient.

Darum soll es hier aber garnicht gehen.

Vor ein paar Wochen nun verweigerte der Sauger seinen Dienst und statt zu saugen blinkte das Gerät nur noch rot vor sich hin.

Ein Blick auf die Dyson Service Seite brachte den etwas unattrakiven Rat, den Kundendienst zu kontaktieren.

Meine Erwartungshaltung an solche Telefonate sind eng an ewige Wartezeiten mit unerträgliche Musik und lustlos unbemühten Callcenter-Mitarbeitern geknüpft.

Ergebnis bei Dyson war, das der erste Anrufversuch direkt abgewiesen wurde. Der zweite hatte etwas Warteschlange, verband mich dann aber an eine zielstrebige Mitarbeiterin, die mich gleich instruierte mit ‘dem’ Schraubendreher zwei Schrauben zu lösen. Meine Bemerkung, dass ein Hinweis den Schraubendreher bereitzuhalten, sich auf der Service Seite ganz gut machen würde parierte Sie mit Höflichkeit und Geduld.

Ein paar Handgriffe und zwei gelöste Schrauben brachten das Ergebnis, dass eine neuer Akku her müsse.

Mit der Seriennummer und meiner Beteuerung, dass ich das Gerät im Dezember 2013 (also jenseits der 24 Monate Gewährleistung) gekauft habe, wurde mir umgehend und kostenfrei ein Austausch-Akku angeboten. Das Gespräch endete mit dem dringlichen Hinweis den defekten Akku der Entsorgung zuzufügen oder alternativ mit dem Retourenschein an Dyson zurückzusenden.

Der versprochene Austausch-Akku war am nächsten Tag an der Haustür!

Die 7 Änderungen in Java 7 gegenüber Java 6

Manchmal sind Änderungen so unscheinbar, dass man kaum sagen kann wie umfangreich sie waren geschweige wann sie stattgefunden haben. Hier sind die Änderungen welche die Sprache Java mit der Version 7, wie schon auf der Seite Java Programming Language Enhancements in bestem English beschrieben, erneut in eigener Formulierung aufgeführt.

  1. Binary Literals:
    Ließen sich die Literale zu
     byte, short, int, und long

    bisher nur dezimal oder hexadezimal schreiben so ist nun auch die binäre Schreibweise möglich:
    Bisher:

    		byte dezimal = 16;
    		byte hexadezimal = 0x10;
    

    Neu:

    		byte binär = 0b0010000;
    

    Insbesondere wenn die Typen für Vergleiche auf Bit-Ebene herangezogen werden ergeben sich übersichtliche Schreibweisen.

    		byte Bit_0_Flagge = 0b0000001;
    		byte Bit_1_Flagge = 0b0000010;
    		byte Bit_2_Flagge = 0b0000100;
    
  2. Underscores in Numeric Literals:
    Muss ein von der Kreditkartenindustrie gefördertes Feature sein. In Numerischen Werten lassen sich nun Unterstriche einstreuen. Somit lassen sich vielstellige Nummern wie:

    		long kreditKartenNummer = 1234567890123456L;
    

    optisch unterteilen,

    long kredit_Karten_Nummer = 1234_5678_9012_3456L;
    

    Und es gilt:

    (kreditKartenNummer == kredit_Karten_Nummer) //true
    
  3. Strings in switch Statements:
    Bisher musste die Expression im SwitchStatment vom Typ:

    char, byte, short, int, Character,
    Byte, Short, Integer oder enum
    

    sein. Mit Java 7 kann sie darüber hinaus auch vom Typ:

    String
    

    sein.
    Somit ist dieses Konstrukt möglich:

            String what = "Foo";
            switch (what) {
                case "foo":  doFoo();
                         break;
                case "bar":  doBar();
                         break;
                default: doDefault();
                         break;
            }
    

    Bei der Auswertung der Expression wird String.equals ausgewertet. D.h. es sind zwei Dinge zu beachten:

    1. Ist die Expression null so wird eine NullPointerException geworfen.
    2. Die Auswertung der Expression is case sensitive, es wird also die Groß-und Kleinschreibung beachtet.
  4. Type Inference for Generic Instance Creation:
    Aus

    Map<String, List<String>> myMap =
        new HashMap<String, List<String>>();
    

    wird

            Map<String, List<String>> myMap = new HashMap<>();
    

    wobei das Setzen des diamond Operators “<>” in so fern wichtig ist, dass damit explizit Bezug auf die generische Variante von HashMap genommen wird. Ohne diamond Operator

            Map<String, List<String>> myMap = new HashMap();
    

    beschwert sich der Compiler, dass die Type conversion von HashMap nach Map> ungeprüft sei und ausserdem dass HashMap ein raw Type sei und diese besser mit entsprechenden Typen zu parametrisieren sei.

  5. Improved Compiler Warnings and Errors When Using Non-Reifiable Formal Parameters with Varargs Methods:
    Generics sind eingeführt worden um Typsicherheit in Java zu erhöhen. Schon der Compiler soll erkennen können ob eine Zuweisung Typenkonform ist oder nicht. Dennoch ist es nach wie vor möglich eine ClassCastException an Stellen herbeizuprogrammieren, die der Compiler für absolut unbedenklich hält:

            List l = new ArrayList<Number>(); //Hinweis auf raw type
            List<String> ls = l;              //Warnung: unchecked conversion
            l.add(0, new Integer(42));        //Hinweis auf raw type
            String s = ls.get(0);             //ClassCastException
    

    Der Umstand der in Zeile 2 herbeigeführt wird, nämlich, dass die Variable ls vom generischen Typ List auf einen nicht generischen Typ zeigt, wird Heap Pollution bezeichnet.

    Ein zunächst nichtoffensichtlicher Ort, an dem Heap Pollution gerne auftritt sind Methoden mit Typisierten Varargs:

      public static <T> void addToList (List<T> listArg,
                                           T... elements) {
        for (T x : elements) {
          listArg.add(x);
        }
      }
    

    Java 7 zeigt dort nun eine Warnung an:

    warning: [varargs] Possible heap pollution from parameterized vararg type T
    

    Details und Codebeispiele dazu:
    Improved Compiler Warnings and Errors When Using Non-Reifiable Formal Parameters with Varargs Methods

  6. The try-with-resources Statement
    Wesentlicher Punkt hier schein zu sein, dass man mit diesem Konstrukt das saubere Schließen von resources ermöglicht. Man beachte den Ausdruck in Klammern der dem try folgt:

    static String readFirstLineFromFile(String path) throws IOException {
      try (BufferedReader br = new BufferedReader(new FileReader(path))) {
        return br.readLine();
      }
    }
    

    Die Variable br im try-with-resources Statment ist vom Typ BufferedReader und implementiert java.lang.AutoCloseable. Mit Java 7 wird nun sicher gestellt dass die Resource br am Ende der Methode geschlossen wird.

  7. Catching Multiple Exception Types and Rethrowing Exceptions with Improved Type Checking:
    Releativ eingängig, nun kann man in einem try Statment 2 catch Clauses

    catch (IOException ex) {
         logger.log(ex);
         throw ex;
    catch (SQLException ex) {
         logger.log(ex);
         throw ex;
    }
    

    zu einer zusammenfassen:

    catch (IOException|SQLException ex) {
        logger.log(ex);
        throw ex;
    }
    

    Die Schärfe der CatchClause bleibt erhalten nur die Schreibweise wird kompakter.

Insgesamt hat sich die Sprache Java mit der Version nicht wesentlich gewandelt. Es ist ein wenig syntactic suggar hinzugekommen. An anderer Stelle ist die, man mag es kaum sagen, Nutzer- bzw. Programmierer-Führung verbessert worden.

Das soll uns nicht vom Programmieren abhalten,

frohes Schaffen!

Homebrew, hin und zurück in 3 Schritten

Homebrew der Software-Paktmanager für Mac OS X.

Wird Open-Source Software benötigt die von Apple nicht mitgeliefert wurde, lohnt sich ein Blick auf Homebrew.

Homebrew ist selbst Open-Source und wird auf GitHub gehostet. Die Community ist ziemlich aktiv und die bereitgestellten Pakete häufig aktueller als die von Apple beigefügten.

Homepage: http://brew.sh/

  1. Installieren:
    Auf der Homepage unter “Install Homebrew” den Text anklicken, kopieren, in das nächste Terminal einwerfen und Return drücken.

    Hier deutet sich schon an, das Homebrew aus dem Ruby Umfeld stammt. Das Installationsscript ist in Ruby geschrieben, wie auch die einzelnen Paketbeschreibungen, die “Formulae”, selbst.

  2. Benutzen:
    Die Installation eines Paketes, z.B. wget erfolgt dann durch die Eingabe von:

    $ brew install wget
    

    in einem Terminal.

  3. Wegwerfen:
    Sollte einem Homebrew nicht gefallen lässt es sich mit aktzeptablen Aufwand wieder von der Platte nehmen. Am saubersten geht das mit dem auf GitHub als Gist bereitgestellten Script:

    https://gist.github.com/mxcl/1173223

    Entweder das Script herunterladen und im Terminal ausführen:

    $ chmod 744 uninstall_homebrew.sh
    $ ./uninstall_homebrew.sh
    

    Oder alle Zeilen kopieren und in ein Terminal einfügen. Evtl. muss dem Nutzer Lösch-Zugriff auf das /usr/local/ Verzeichnis gegeben werden.

Frohes Schaffen!