qlist -I xorg-drivers

Emerge the the drivers on the list.

e.g.:

emerge -v1 x11-drivers/xf86-input-evdev x11-drivers/nvidia-drivers

1h 21m 49s

compared to compiling it directly on my Gentoo box:

38m 18s

So I decided to switch from the VM directly to my Gentoo box with a kde-devel user. I used in both cases

./kdesvn-build qt-copy

as described in the document  “Getting Started/Build/kdesvn-build” with a clean kde-src directory.

N900 <-> USB/WLAN <-> Laptop/Kontact

Yesterday I ask for a solution to synchronize (at freenode#kontact). The answers are more or less: Setting up a Groupware-Solution (e.g. Horde) – sync the phone with this server – sync Kontact with the server.

But I think there must be easier solution for “normal” users without setting up such a server. And now I have a new long-term pet project.

I found a few tools that I could possibly use (The list is not exhaustive.):

• SyncEvolution (N900/Maemo side)
• the build-in synchronization – ? (N900)
• Akonadi SyncML Agent (Kontact side)

But at first I have to bootstrap my C++, Qt and KDE-programming knowledge. My plan is to help kde-pim a little bit to become familiar with the whole environment. At the moment I’m setting up a KDE development environment. It runs in a VM. If I have more experience, I will run it directly on my gentoo os.

So, qt-copy is compiling…

Btw. I finished the go-lang tutorial. I like the language. But at the moment I have no project to use it.

The installation was completed thanks to a good description in 15 minutes. One problem I had when compiling. You have the locale set to “en_US” during the compilation:

$ cd $GOROOT/src
$ LANG=en_US ./all.bash

5 minutes later, the “hello world” ran.

In the directory $GOROOT/misc/kate,  a file go.xml can be found for the syntax highlighting in kate. This file must be copied into the directory ~/.kde4/share/apps/katepart/syntax/.

Am Beispiel von CityBike möchte ich erklären, dass die Implementierung der Unit-Test’s jetzt ganz einfach geht. Wir haben also die leere Implementierung der Klasse:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class CityBike implements WithBasket {
 
    private Basket basket;
 
    public CityBike(Basket basket) {
    }
 
    public void addElement (Element e) {
    }
 
    public Basket getBasket () {
        return null;
    }
}

Alle Implementierungen sind leer, da wir ja im Sinne von Test-Driven Development (TDD) zuerst unsere Tests schreiben und erst danach die Implementierung. Hier also die JUnit4-Testklasse:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

import org.junit.Before;
import org.junit.Test;
import static org.junit.Assert.*;
import static org.mockito.Mockito.*;
 
public class CityBikeTest {
 
    private Basket basket;
    private CityBike cityBike;
 
    @Before
    public void setUp() {
        basket = mock(Basket.class);
        cityBike = new CityBike(basket);
    }
 
    @Test(expected=IllegalArgumentException.class)
    public void shouldNotCreateWithNullAsBasket() {
        new CityBike(null);
    }
 
    @Test
    public void shouldDelegateAddElementToBasket() {
        Element e1 = mock(Element.class);
        //
        cityBike.addElement(e1);
        //
        verify(basket).add(e1);
    }
 
    @Test
    public void shouldReturnBasket() {
        assertEquals(basket, cityBike.getBasket());
    }
}

Alle 3 Tests melden einen Fehler. Also ändern wir die Implementierung so, dass die Tests funktionieren:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public class CityBike implements WithBasket {
 
    private Basket basket;
 
    public CityBike(Basket basket) {
        if (null == basket){
            throw new IllegalArgumentException("null as basket not allowed");
        }
        this.basket = basket;
    }
 
    public void addElement (Element e) {
        this.basket.add(e);
    }
 
    public Basket getBasket () {
        return this.basket;
    }
}

Alle Tests funktionieren. (Die Implementierung und Tests für SimpleBasket und SimpleElement lasse ich hier im Text mal weg, damit es nicht zu unübersichtlich wird.) Damit haben wir als Programmierer von CityBike mal alles gemacht

Jetzt kommt ein zweiter Programmierer und möchte unsere Klassen benutzen. Es wird eine Person implementiert, die mit dem Fahrrad fahren soll. Allerdings muss dieser Fahrer seine Umhängetasche in den Korb (Basket) legen, bevor er losfahren darf. Natürlich sollte auch der zweite Programmierer seine Klassen “Fahrer” und “Tasche” testen. Hier die fertigen Implementierungen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

public class Fahrer {
 
    private Tasche tasche;
 
    private CityBike cityBike;
 
    public Fahrer(Tasche tasche, CityBike cityBike) {
        if (null == tasche){
            throw new IllegalArgumentException("null as tasche not allowed");
        }
        this.tasche = tasche;
 
        if (null == cityBike){
            throw new IllegalArgumentException("null as cityBike not allowed");
        }
        this.cityBike = cityBike;
    }
 
    void losfahren(){
        this.cityBike.addElement(tasche);
 
        // aufsteigen
        // nach rechts und links schauen
        // anfangen in die Pedalen zu treten
    }
}
 
public class Tasche implements Element {
 
    public int getWeight() {
        return 12;
    }
}
 
import org.junit.Before;
import org.junit.Test;
import static org.mockito.Mockito.*;
 
public class FahrerTest {
 
    private Tasche tasche;
 
    private CityBike cityBike;
 
    private Fahrer fahrer;
 
    @Before
    public void setUp() {
        this.tasche = mock(Tasche.class);
        this.cityBike = mock(CityBike.class);
 
        this.fahrer = new Fahrer(tasche, cityBike);
    }
 
    @Test
    public void shouldAddTascheInKorb() {
        //
        fahrer.losfahren();
        //
        verify(cityBike).addElement(tasche);
    }
}

Was passiert, wenn wir die Methode addElement(Element e) aus WithBasket und CityBike rausnehmen. Jeder der dann WithBasket, CityBike oder andere Subklassen von WithBasket benutzt muss dann den Wege über getBasket().add(Element e) gehen. Die Methode losfahren in Fahrer sieht dann so aus:

1
2
3
4
5
6
7

    void losfahren(){
        this.cityBike.getBasket().add(tasche);
 
        // aufsteigen
        // nach rechts und links schauen
        // anfangen in die Pedalen zu treten
    }

Aber nicht nur das wir jetzt in X Klassen dieses getBasket().add(tasche) stehen haben. Wir machen den Benutzern unserer Klasse auch noch das Testen schwieriger:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

import org.junit.Before;
 
import org.junit.Test;
 
import static org.mockito.Mockito.*;
 
public class FahrerTest {
 
    private Tasche tasche;
 
    private CityBike cityBike;
 
    private Basket basket;
 
    private Fahrer fahrer;
 
    @Before
 
    public void setUp() {
 
        this.tasche = mock(Tasche.class);
 
        this.cityBike = mock(CityBike.class);
 
        this.basket = mock(Basket.class);
 
        this.fahrer = new Fahrer(tasche, cityBike);
 
    }
 
    @Test
 
    public void shouldAddTascheInKorb() {
 
        when(cityBike.getBasket()).thenReturn(basket);
 
        //
 
        fahrer.losfahren();
 
        //
 
        verify(basket).add(tasche);
 
    }
 
}

Wir haben eine zusätzliche Membervariable basket im Test und der Test muss noch Vorbereiten das auf cityBike auch wirklich ein Basket geliefert wird. Und hier haben wir nur eine Verschachtelungstiefe. Man denke sich mal aus wie es aussieht wenn wir folgende Situation haben: A.getB().getC().getD().add(E e). Und jetzt stelle sich der Leser noch vor, dass das ganze Konsequent in der ganzen Applikation so gemacht wird. Irgendwann sind die Tests so aufwendig und kompliziert, dass kein Entwickler mehr Tests schreibt, weil einfach keine Zeit ist. Wenn dagegen immer das Law of Demeter eingehalten wird, dann sind die Tests kurz und einfach.

Schlusswort:

Ich habe hier Mockito verwendet um die Mock-Objekte zu schreiben. Eine wirkliche Empfehlung von meiner Seite. Diese Bibo ist der Hammer. Wirklich schnell zu lernen und eine wunderschöne API. Gratulation an die Entwickler zu diesem tollen Stück Software.

Schönes Wochenende!

Als heute  morgen alle noch bei Kaffee in unserem Pausenraum sassen, habe ich ein speziellen Teil unseres Domain Modells an die dort hängende Tafel gemalt. Ich wollte allen mitteilen, auf welch schönes Design wir gestern für einen Teil unseres Domain Modells gekommen waren. Insbesondere wollte ich auch aufzeigen, wie elegant eine Lösung werden kann, wenn man sich an das Gesetzt von Demeter hält. Dabei haben Jan und ich nicht mal an das Gesetz gedacht, als wir die Schnittstellen definiert haben. Es ist sozusagen “einfach entstanden”.

Hier ein leicht abgeändertes Beispiel:

Wir haben also ein Interface welches aussagt, dass ein Typ welches dieses Interface implementiert eine Has-A-Beziehung zu Basket hat. Ein WithBasket-Object hat also immer einen Basket. Ausserdem kann ein Basket eine Menge (0 bis n ) Elemente beinhalten. Nun machen wir mal zwei Methoden hinzu:

Die Diskussion entbrannte nun an der Methode addElement(Element e) in WithBasket. Eine Implementierung von WithBasket muss also diesen Aufruf an Basket delegieren. Und dieser Punkt war einigen Kollegen nicht geheuer bzw. wurde abgelehnt, u.a. mit der Begründung, dass ja der Typ WithBasket nicht für die Verwaltung von Elementen zuständig ist. Besser sei auf WithBasket eine Methode “public Basket getBasket()” zu implementieren, void addElement(Element e) wegzunehmen und der Benutzer von WithBasket kann dann auf dem Basket die gewünschten Operationen ausführen. In einem Client von WithBasket würde also folgender Code stehen:

myObjectWithBasket.getBasket().add(myElement);

Dies bricht das Gesetz von Demeter.

Nun habe ich in der Mittagspause nachgedacht und nach Beispielen aus dem realen Leben gesucht. Als Erstes ist mir ein Theaterbesuch in der ehemaligen DDR eingefallen. Dort habe ich mal Folgendes erlebt:

Vor der Garderobe des Theaters stand eine Angestellte des Theaters die offensichtlich für die Garderobe zuständig war. Als wir nun unsere Jacken abgeben wollten, zeigte sie mit dem Finger auf die Kleiderhaken und wir mussten nach hinten gehen und unsere Sachen selber aufhängen.

Es ist richtig, dass es nicht die Verantwortlichkeit der Garderobenfrau war, unsere Kleider die ganze Vorstellung lang zu halten. Trotzdem empfindet man dies doch als komisch. Ich bin jedes mal dankbar, wenn mir die Jacke abgenommen und an die Kleiderhaken gehängt wird. Dieses Muster findet man sehr oft vor. Ein weiteres Beispiel die die Essenbestellung im Restaurant. (Gast -> Bedienung -> Koch).

Ein weiters Beispiel ist die Rezeption im Technopark Zürich. Die Rezeption hat auch einen Kopierer und wenn man möchte, kann man dort auch Sachen kopieren lassen. Man gibt ein Blatt ab, die Frau an der Rezeption nimmt das Blatt, legt es auf den Kopierer und drückt den grünen Knopf. Es ist so viel angenehmer, als erst selbst hinter die Rezeption an den Kopierer gehen zu müssen. Was passiert aber, wenn ich den Kopierer viel besser bedienen kann, als die Frau an der Rezeption? Ich kenne das Teil und weiss, wie man die Graustufen einstellt und wie man verkleinert. In solch einem Fall wäre es eventuell doch nötig an den Kopierer heranzukommen.

Um wieder zum Basket-Beispiel zurückzukommen. Was macht man, wenn man nun Basket in einem GUI darstellen möchte und nur WithBasket hat?

Für die Darstellung von Basket breche ich nun die Kapselung. Nicht unbedingt 100% Law of Demeter aber pragmatisch. Oder?

Trotzdem stelle ich die wichtigen Operationen von Basket am WithBasket zur Verfügung, damit im Domain-Model immer über dieses gegangen werden kann. Und wenn ich getBasket weglassen kann, dann mache ich es auch. Schlussendlich entscheidet der fachliche Kontext in solch einem Fall.

Wie einfach die Unit-Tests dann auf einmal zu schreiben sind, kommt vielleicht ein anderes Mal. Heute bin ich zu müde…

Gute Nacht

Engstligenalp mit Wildstrubel

Oben sind wir dann auf dem Ärtelegrad Richtung Tschingellochtighorn gegangen.

Tschingellochtighorn

Das steilere Stück bis zum Engstligengrat bin ich dann noch allein hochgestiegen. Ich konnte dann die Stelle sehen, wo ich vor einem Jahr die Rote Chumme hochgekommen bin.

Engstligengrat mit Blick auf Rote Totz

Was für ein schöner Tag

______
Update 2009-10-16:

Hier noch die Engstligenalp – Tschingellochtighorn Wegmarkierung für Google Earth.