Programmieren

I am sorry for bringing this up so late, but maybe you have already noticed: During the last weeks british TV station Channel4 aired the second season of IT Crowd. It consisted of six episodes again. My friends and I were looking forward for each single episode since it was clear very quickly that the new episodes were fulfilling all expectations. The new stories about Roy, Moss and Jen, all workers in the IT department of Reynholm Industries, are full of typical cliches that one has of geeks and are packed with masses of really good jokes. We now have watched the whole season several times, still not getting bored and spicing up our daily life with many fitting quotations, e. g. “people, what a bunch of bastards”

I recommend everyone who already loved or liked season one to also watch this one. As usual, enjoying it is not hard to achieve.

Related articles

• Hello, IT? - Me about the first season (in German)

Tja, da melde ich mich zurück aus der Blog-Eiszeit hier, und ich hoffe, hier in Zukunft wieder mehr und häufiger berichten zu können. Das Thema dieses Beitrags ist auch gleichzeitig der Hauptgrund, der mich in den letzten Monaten von einem regelmäßigen Bloggen abgehalten hat: das SEP. SEP steht für Softwareentwicklungspraktikum und jeder Informatikstudent der TU durchläuft dieses irgendwann einmal. So auch ich im vierten Semester, das jetzt zumindest vorlesungs- und praktikums-, aber noch nicht prüfungsmäßig abgeschlossen ist.

Beim SEP setzen Studenten Softwareprojekte, die von den Instituten der Informatik vergeben werden, in Teams von mehreren Studenten um.
Ich habe hierbei mit Stephan, Henning und Oli ein “Ad-Hoc-Chatsystem für mobile Netze” beim IBR (Institut für Betriebssysteme und Rechnerverbund) umgesetzt. Parallel haben dies noch drei weitere Gruppen, ebenfalls bestehend aus jeweils vier Leuten, getan.

Die Wahl auf dieses Thema fiel bei uns aus zwei Gründen: Zum einen reizte uns die Problemstellung. Ich programmiere gerne Software, die Probleme löst, für die es praktisch noch keinen verbreiteten Lösungsweg gibt, wo man also beim Programmieren Probleme lösen muss, für deren Lösung noch keine “Handlungsanweisung” existiert, wie z. B. beim mittlerweile trivialen, weil gut erforschten Sortieren bis hin zur stumpfen Programmierung einer Benutzeroberfläche. Letzteres fiel bei uns natürlich auch an, es hat aber bei weitem nicht einen Großteil der Lösung ausgemacht.
Zum anderen war dieses Projekt das einzige, bei dem eine freie Wahl der Programmiersprache möglich war. Henning und Stephan wollten ihr SEP-Projekt unbedingt in Haskell, einer funktionalen Programmiersprache, absolvieren, und auch Oli und ich hatten durch die Indoktrination der beiden immer wieder einmal die Reize dieser Programmiersprache kennen gelernt. Und letztendlich konnten wir auch beim Institut die Überzeugung wecken, dass es in Haskell zu schaffen ist, und dass wir auch wissen, wovon wir reden
Die anderen drei Gruppen haben das ganze zwei Mal in Java und einmal in C++ umgesetzt.

Die Aufgabenstellung

Detailliert bedeutete das Projekt für uns, dass wir ein gegebenes Protokoll umsetzen, also implementieren sollten, das speziell für die Verwendung in Ad-hoc-Netzen entwickelt wurde - also Netzwerken (in der Regel WLAN) ohne bestehende Infrastruktur, wie Access Points oder Server, und mit starken Fluktuationen in der Struktur. Gegeben war hierzu ein Internet-Draft, der verschiedene Grundprinzipien des Protokolls (Sicherheit, Wegefindung, etc.) und das Protokoll an sich, also die einzelnen Nachrichten spezifiziert.

Der Entwicklungsprozess

Der Entwicklungsprozess folgte dabei dem Wasserfall-Modell in all seinen Details. Jede der Phasen war mit einem Abgabetermin für Dokumente und/oder Code abgeschlossen, und die Ergebnisse wurden in einem Projekttreffen aller Gruppen präsentiert.
Dies hieß nun für uns, dass wir die ersten fünf bis sechs Wochen damit verbrachten, Anforderungen, Anwendungsfälle (sog. Use Cases) und Geschäftsprozesse herauszuarbeiten, die das Verhalten unserer Software beschreiben. Um diesen Anforderungen gerecht werden zu können, wurde dann eine Softwarearchitektur und schließlich die detaillierte Realisierung der einzelnen Komponenten spezifiziert. Nebenbei entstanden in unserer Gruppe auch schon die ersten Code-Schnipsel, meist Proof-of-Concepts, also kurze Prototypen einzelner Funktionalitäten.

Die Implementierung

Nach der Entwurfsphase ging es dann in die Implementierung. In dieser Phase werkelten wir oft bis spät in die Nacht an unserem Code, des öfteren jeder für sich an seinen Komponenten, manchmal auch bei Treffen unserer Gruppe alle zusammen. Es gab oft (auch hitzige) Diskussionen, entweder, wenn man sich im parallel laufenden Vorlesungsbetrieb gesehen hat, oder aber auch in unserem eigens gegründeten IRC-Channel, denn nicht nur sollte unsere Implementierung schön in jedem Aspekt werden (und nicht nur “irgendwie” hingefrickelt, dass es passt), sondern wir hatten uns auch die ein oder andere Bürde selbst auferlegt: Jedwede gespeicherte Daten im Programm sollten nicht redundant geführt werden, begonnen bei der internen Nachrichten-Struktur bis hin zu den verschiedenen Info-Modulen, die Informationen über Benutzer und das Netzwerk verwalten. Ein weiterer Punkt war, dass die Benutzeroberfläche einfach und (relativ) intuitiv zu benutzen sein sollte. Und so gab es einige Punkte, die wir haben wollten, weil wir sie für eine schöne Umsetzung für unabdingbar hielten.

Natürlich galt es bei der Implementierung neben den scheinbar für jedes Projekt symptomatischen Zeitproblemen auch das ein oder andere vorher nicht erwartete Problem zu umschiffen: So taten sich noch einige Spezifizierungsfehler im Protokoll auf, die teilweise durch eine Revision des Drafts behoben wurden, teilweise aber auch von uns einfach durch Einigung auf einen Standard mit den anderen Gruppen gelöst wurden.

Letztendlich war es dann aber doch geschafft und das Programm war fertig. So weit, so gut, doch nun ging es in ...

Die Testphase

In der Testphase wurde die geschriebene Software auf Herz und Nieren getestet. Das hieß, dass wir zum Teil einzelne Komponenten und zum Teil auch das Verhalten der Software ausführlichst auf Korrektheit überprüft haben. Hat man hierfür noch kleine Testprogramme schreiben können, oder kleine Netzwerkstrukturen selbst mit dem eigenen Programm aufgebaut, war der weitaus größere Brocken die Interoperabilitätstests. Bei diesen Tests wurde die fehlerfreie Zusammenarbeit unserer Software mit der der anderen Gruppen geprüft. Und hier taten sich die weitaus größeren Probleme auf: An der einen Stelle hat die eine Gruppe das Protokoll anders interpretiert, an der anderen Stelle waren bestimmte Vorgänge noch fehlerhaft, teilweise gab es Fehler, die bei zwei Instanzen des gleichen Programms nicht auftraten, wohl aber bei der Kommunikation mit einem anderen Programm.

Der Endspurt

Nachdem wir nach vielen, vielen Tests, aber bei weitem nicht allen möglichen auch diese Phase abgeschlossen hatten, bauten wir die finalen Versionen der Software zusammen, aktualisierten noch einmal die letzten Dinge in den Entwürfen und verfassten ein Benutzerhandbuch zur Software. Dann sollte unser Projekt “nur” noch abschließend präsentiert werden. Hierzu wurde noch ein DIN-A0-Poster erstellt, und ein Flyer gedruckt, und damit bewaffnet ging es dann auf den alljährlichen TU-Day, unser “Campus-Fest”, bei dem allerlei interessante Projekte und ähnliches vorgestellt werden, und abschließend zum “Tag der neuen Softwareentwickler”, einem Nachmittag, an dem alle am SEP teilnehmenden Gruppen im Mittelpunkt standen und die Ergebnisse der letzten drei Monate Arbeit präsentierten - zunächst nur einem universitätsinternen Publikum, später aber auch der interessierten Öffentlichkeit, wie z. B. Vertretern von IT-Firmen.

Noch mehr Informationen

Wer jetzt noch mehr wissen möchte oder einfach sich für das Programm interessiert, den lade ich herzlich auf unsere Projekt-Homepage ein. Dort gibt es neben sämtlichen Dokumenten, wie Entwürfen, Präsentationsmaterialien, etc. auch die finalen Versionen vorcompiliert und als Quellcode zum Download. Veröffentlicht wird der Code übrigens unter der GPL in Version 3. Es gibt dort bei Interesse auch einen Link zum Institut und von dort weiter zu den anderen Gruppen.

Und zuguterletzt gibt es auch noch Fotos vom “Tag der neuen Softwareentwickler” zu bestaunen.

At The Daily WTF there was a series of WTFs at universities a while ago telling stories of “curious perversions in information technology” at universities.

Here and today I going to tell my own WTF story from my university. It’s quite simple since it merely consists of some code snippets: We had lectures on programming the last two semesters, more precisely in Java (an incredibly awful programming language, in my opinion). And when it was the first time for you to write programs you might not have noticed how awful the demonstrated program code and style was. But when you already were able to program such as I was, then .... then you shall always keep in mind during reading the following code snippets that we shall be educated to future project leaders, lead programmers, project designers, ...:

The class BinTree implements a binary search tree. In the original code German and English names are used side by side. To make it readable for you, I translated all German variable and method names. My personal highlight is the implementation of prefixValues() which shall give the values of the tree in prefix order. encode() returns a string containing “0”s and “1”s, “00” if a node has no childs, “10” if a node has a left but no right, “01” if it has a right but no left and “11” if it has both iterating through the nodes in prefix order.

class Node {
    int value;
    BinTree leftBranch, rightBranch; 1

    Node(int x) {
        value = x;
        leftBranch = new BinTree();
        rightBranch = new BinTree();
    }
}

class BinTree {
    Node root = null; 2

    public boolean isEmpty() {
        return root == null;
    }

    public void insert(int x) {
        // ...
    }

    public String encode() {
        return encode(“”);
    }

    private String encode(String code) {
        if(isEmpty()) return code;

        String l = “1”, r = “1”;
        if(root.leftBranch.isEmpty()) l = “0”;
        if(root.rightBranch.isEmpty()) r = “0”; 3
        code = root.leftBranch.encode(code + l + r);
        code = root.rightBranch.encode(code);
        return code;
    }

    static int[] values; 4
    static int freeInValues;

    public int[] prefixValues(int n) { 5
        values = new int[n]; 6
        freeInValues = 0;
        prefixValues();
        return values;
    }

    private void prefixValues() {
        if(!isEmpty()) {
            values[freeInValues++] = root.value;
            root.leftBranch.prefixValues();
            root.rightBranch.prefixValues();
        }
    }

    // ...
}

class Test {
    public static void main(String[] arg) {
        BinTree b = new BinTree();
        String code;
        int[] values;
        b.insert(3);
        // ...
        b.insert(2);
        b.insert(5);
        code = b.encode();
        values = b.prefixValues(code.length()/2); 7
        // ...
    }
}

^{1, 2} Look how beautiful this two classes are chained together ... forever.
³ How clearly the logical structure of the program is appearing at this point, wonderful!
⁴ Eh, a static variable for values, what is it for?
^{5, 6} Ah, okay, there the prefix values are stored. But wait in a static variable? Is there only one BinTree instance supposed to be? And why does a public method destined to return the nodes of the binary tree in prefix order need the number of nodes in the tree from the calling code ....?
⁷ Sure, the code string of the tree is as twice as long as the tree has nodes -_- That’s an ... interesting ... way to get the number of nodes ....

So, all instances share the same reference to the array storing the values of the tree? You probably can imagine what happens if you use BinTree in different threads ...

Leider etwas verspätet, aber besser als nie Henning hat dieselben Algorithmen einmal in Haskell, einer funktionalen Programmiersprache, implementiert. Viel Spaß damit!

• sorting-algorithms-haskell.tar.bz2,
  3.2 KB, MD5: e1510df8459deec878ae2ec6ab403134

Ein zentrales Thema der Algorithmen und Datenstrukturen-Vorlesung im letzten Semester waren Sortier-Algorithmen. Aus Spaß an der Freude (und aus Interesse ) habe ich die beliebtesten und die bekanntesten einmal in Python auf Listen arbeitend implementiert, die da wären: QuickSort, MergeSort, HeapSort, SelectionSort, InsertionSort und CountingSort. Vielleicht hilft es dem ein oder anderen, die Algorithmen zu verstehen oder einfach nur einmal die Brillianz dahinter zu erkennen. Im Paket mit dabei ist das Script sort_test.py, das den Algorithmen jeweils eine unsortierte Liste übergibt (kann auch in diesem Skript z. B. vergrößert werden) und, wie unerwartet ;), über jeden Algorithmus die sortierte Liste wieder ausgibt. Viel Spaß damit!

• sorting-algorithms-0.1.tar.bz2,
  1.6 KB, MD5: 993478eb370a7b90f2399f61c593bf95

Update:

Die Algorithmen implementiert in Haskell.

Wer brav mein kleines Projekt WChat verfolgt, weiß es schon: Ich hab einen kleinen Linux-Daemon für WChat geschrieben, d. h. es kann jetzt auch ein WChat-Server unabhängig von der GUI gestartet werden. Für alle, die sich auch einmal daran versuchen wollen, es ist recht einfach. Hier der relevante Code mit Dämonisierung, SIG-Behandlung und Syslog-Anbindung:

Zwei Signal-Handler-Funktionen hinzugefügt, die bei SIGHUP z. B. die Config neu laden und bei SIGTERM den Daemon beenden. daemon(0, 0); forkt den Prozess als Daemon in den Hintergrund. Mit syslog(LOG_INFO, “...”); loggt man direkt in die System-Log (bei mir /var/log/messages). Ein einfaches Start-Script und die entsprechenden Config-Dateien für den wchatd können als Beispiel für dieselbigen unter Gentoo Linux dienen, alles zu finden im ebuild-Package auf der WChat-Projekt-Seite. Vielleicht traut sich ja der ein oder andere jetzt auch daran