Im zweiten Semester hatte ich ein Modul über die Maschinennahe Programmierung. Wir haben dies am Beispiel des Intel 8051 besprochen. So wurden unter anderem Themen besprochen wie CPU Takt und Zyklen, Interrupts und einige Assembler trivialitäten wie zum beispiel verschiedene Sprünge. Man musste sich mit Adressierung und dem Stack auseinander setzen und das auch beherschen. Da wir auch Praktisch Programme für den 8051 schreiben mussten, merkten wir bald die Herrausforderungen. Die Register der Accu-Maschine nicht zu überschreiben oder Code der eine bestimmte Zeit ablaufen sollte (zb für ein Frequenz Signal) zu dimensionieren. Doch trotzdem die Aufgaben geschafft zu haben, obwohl es sehr mühevoll ist, fand ich spannend. Weiter hat man uns natürlich darauf aufmerksam gemacht, dass dieser Assembler Code so nur für den 8051 gilt. Andere CPUs haben einen anderen Assembler auch andere Register, Busbreiten bzw. gar eine andere Maschinen Architektur. Daraus wurde mir klar, dass man natürlich nie den Code so auf eine andere Maschine portieren kann, wie zum Beispiel ein C Programm. Daher kommt mein Respekt Programmierung für eine bestimmte Maschine machen zu müssen. Allerdings war auch gleich klar, dass dadurch eine viel Sprezifischere Programmierung möglich ist. Insgesammt hatte mir das Modul und die Art zu Programmieren richtig spaß gemacht.

Beide Bilder zeigen die letzte Übung, die Augen eines Würfels auf einem Dot-Matrix Display anzuzeigen. Es war eine ordentliche Herrausforderung, das spaltenweise kurzzeitige Anzeigen hin zu bekommen. Erst die Spalte anzeigen, dann alle Werte und Ports umschalten und danch die nächste Spalte ausgeben bis man durch ist. Und das nach einer Frequenz die man berechnen musste und in der man alles wiederholt. Danach alles erweitern um alle Würfel Zahlen darzustellen. Es machte spaß, machte mir aber auch klar, wie viel einem Hochsprachen abnehmen.

Im Modul "Systemprogrammierung" ging es im dritten Semester um die Administration von Betriebssystemen und - da alles an Linux behandelt wurde - auch um die Verwndung von Systemcalls als Interfaces zum Kernel-Space. So wurde das Schreiben von Scripten ([ba]sh) erklärt um damit das Betriebsystem einfach zu administrieren zu können. Natürlich im Stiel: Variablen benutzen, einlesen von Werten, Schleifen, dann Prozess Verkettung und nützliche befehle für die Linux Komandozeile. Außerdem wurde gleich von beginn an Tools wie "make" erklärt und die Verwendung von Makefiles für Übungen verlangt. Diese Inhalte waren bereits so schon in der Administration meiner Privaten Systeme hilfreich.
Weiter wurde das Systemcall- System des Linux Kernel erklärt und in in eigenen Programmen genutzt. Ferner wurde auch auf Makro Programmierung in C eingeganden.
Im Modul "Echtzeit Systeme" wurde auch auf den Begriff von Echtzeit bei Software im Allgemeinen eingegangen. Viel mehr wurde aber erklärt, wie das Prozessmodell von vielen Betriebssystemen funktioniert und Scheduling Strategien erläutert. Weiter wurde auf die Interprozess Kommunikation durch Signale Eingegangen. Hier kam dann auch wieder mal der Begriff der Echtzeit zur Sprache. Zum Schluss wurde noch erklärt, was Threads sind, wie man sie in C mit pthread verwenden kann. Weiter wurde auf das Problem von Datensicherheit, Mutexe und Deadlocks eingegangen.

In den Bildern zusehen ist eine Shellscript Übung, eine Modellsimulation der Linux Prozess Verwaltung und ein Programm was Quersummen addiert mit Hilfe von pthreads.

In diesem Modul wurde sich mit der iOS Entwicklungsplattform beschäftigt. Wahlpflicht Module sind ja eher Zusatzthemen. Also ist hier die Mobile Plattform teil des Wahlplficht Modus. Leider wurde die Entwicklung auf Anderen Plattformen nicht angeboten. In dem Modul wurde immer wieder einiges zu Swift erklärt und dazu ein paar Konzepte bei der App Entwicklung für iOS. Natürlich ganz am Anfang das "Modell, View, Controller" Konzept. Dazu wurden immer wieder Apps Entwickelt. Auch der Umgang mit dem "Storyboard" bei der App Entwicklung wurde gezeigt. Als letztes wurde auf die Technik der Delegates hingewiesen und wie sie mit vielen Frameworks genutzt werden können. Daran interessant fand ich den Ansatz, weil er in richung Mobilgerät sehr interessant war. Denn ein beispiel war die Ortung per GPS. Auf einen Callback vom System zu warten, anstatt die ganze Zeit auf Kosten des Akkus die Position abzurufen, fand ich sehr weit gedacht. Am Ende konnte man schon ganz gut Apps Entwickeln.

Das ist auch wichtig gewesen. Denn zum Abschluss sollte man eine App selber mit entwickeln. Entweder etwas eigenes oder man setzte eine Vorgabe nach eigener Idee mit "MapKit" um. In den Bildern ist meine Abschluss App zu sehen. Aus den Vorgaben habe ich eine App gemacht, die wie ein "Tagebuch" für Orte auf der Karte sein soll. Wenn man an einem Ort sich etwas dazu notieren will, makiert man ihn auf der Karte und schreibt dazu ein Paar infos ins Pad. Später kann einem die App sogar benachrichtigen, wenn man dort wieder vorbei kommt. Besonders schwer war für mich den Wechsel zwischen zwei Views und den dazu gehörenden Datenaustausch hin zu bekommen. Weiter war schwer, die Ansicht der App drehbar zu bekommen, dH die Position und Größe der Elemente neu berechnen wenn das Pad gedreht wird.
BTW: Später habe ich das Projekt geforkt, um die Flugbahn des Ballons vom Stratoflights Projekt darzustellen (welches in der Raspberry Pi Section auf dieser Seite zu finden ist).

In den Vorlesungen wurde zunächst erst einmal auf die Funktionsweise des TCP/IP Stacks eingegangen. So wurde über das allgemeine Modell und die Kommunikation im Protokoll gesprochen. Weiter wurden Tools gezeigt, um Prozesse, Verbindungen, Routings oder ähnliches steuern und überwachen zu können. Außerdem wurden die Systemschnittstellen, dH Sockets erklärt. In den Praktischen Übungen wurde dann zunächst ein Programm geschrieben, dass per UDP Pakete empfangen sollte. Daraus entstand dann auch gleich ein Server Programm. Diese mussten dann miteinader kommunizieren. Darauf folgend ging es in der Vorlesung weiter mit TCP. So wurde zunächst über den Protokollablauf ansich gesprochen. In den Übungen wurde dann zunächst wieder ein Client geschrieben, der von einem Server einen Zeitstempel bekam, der die Aktuelle Zeit als Differenz zum Unix Date erhielt, Codiert in JSON. Es war schon ein bewegender Moment, als der Zeitstempel auf dem Terminal zu sehen war. Jetzt kann ich die Alten Herren der US-Amerikanischen Universitäten verstehen, als sie das erste 'A' übermittelt hatten. Hatte man das geschafft, hatte man auch gleich die ersten Kontakt mit dem Internet gemacht und über HTTP kommuniziert. Daraufhin sollte nun ein Server für TCP geschrieben werden, der den im Internet erstetzte. Dabei wurde auch gleich darauf geachtet, dass es möglich ist, mehrere Clients zu ermöglichen. Leider kammen wir durch erhebliche Verzögerung (aus Persönlichen Gründen des Dozenten) nicht mehr dazu das ganze für IPv6 zu entwickeln. Doch die entstande Leidenschaft sorgte dafür, dass ich mich nun auch Beruflich dafür interessiere Software für Netzwerk und am Linux Kernel zu entwickeln.

Im Bild sieht man den TCP Server im Terminal und einen Firefox. Ich habe diesmal nicht meinen TCP Client zur Verbindung genutzt, sondern einen Browser. Denn wenn die Kommunikation zwischen den eigenen Programmen klappt, ist das schön. Noch besser ist es aber, wenn man irgend eine Browser nehmen kann und dieser nicht einmal merkt, dass er meinen Server anfragt.

In dem Modul wurde Zunächst das leidige Problem mit scanf() und Buffern beleuchtet. So wurden verschiedenste Probleme beim umgang mit Adressen in C gezeigt, wo man Aufpassen musste. Außerdem wurde erklärt welche möglichkeiten man hat, um selbst von Compiler Seite aus etwas zu verbessern, damit "Eve" nicht details über das Programm erfahren kann bzw das Programm bei nicht normaler Veränderung der Daten "Selbstmord" begeht. Im Teil Cryptografie ging es zunächst um frühere Ansätze, wie Substitution. Als Bessere Lösung wurde "One Time Pad" vorgestellt und gleich erklärt, warum die Sicherheit begrenzt ist. Langsam kam man zu den Cryptografieverfahren, die sich vor allem aus wirtschaftlichen Interessen entwickelt haben. Also Syncron Verschlüsselungen wie DES. Es wurde erklärt, wie DES Funktioniert und warum es nicht sicher ist. Natürlich wurde auch erklärt, warum 2DES immer noch nicht sicherer ist. Also kam man auch in der Vorlesung zu AES. Auch hier wurde wieder erklärt, was AES macht. Damit kam man aber auch bald auf das Problem der Blocklänge zu sprechen, in der AES Definiert ist. Das führte dann natürlich zur Erklärung von Bock Chiffren und den drei wichtigsten Verkettungsverfahren. Abgerundet wurde das Modul mit Asyncroner Verschlüsselung. Das Bedeutet: Was ist das, wie funktioniert das, was sind die Vor- und Nachteile davon und warum macht man dann doch eher Hybrid Verschlüsselung. Außerdem wurde über Hash Funktionen und Zertifikat Ketten geredet. Wir lernten die Verfahren von Deffie Hellman und RSA kennen.


In Bild links ist eine Übung zur sicheren Programmierung in C zu sehen. Ziel war es, herraus zu bekommen, wie sich mit dem gegebenem Code durch falsche Eingabe der Start eines anderen Programms provozieren lässt. In dem Fall als "Harmloses Beispiel" xcalc. In der Mitte wird die Angreifbarkeit von Substitutions Chiffre auf Texten getestet. Durch aufstellen der Wahrscheinlichkeitstabelle für Buchstaben in deutschen Wörtern und diesem Text ließ sich der original Text wiederherstellen. Eine andere Übung gab uns einen Code vom Prof, der ein Modul für AES und Block Ciffre geschrieben hatte. Wir sollten daran Block Chiffre Moduse üben, indem wir die Highlevel API zu den CBC Modus und CTR Modus entwickelten. Im dritten Bild wurde eine Textdatei mit dem Gesamtwerk von Sherlock Holms mit AES-CBC verschlüsselt und anschließend wieder entschlüsselt. Oben ist die Original Datei zu sehen und darunter die wieder entschlüsselte Datei.

In dem Modul wurden die Theorie der Relationalen Datenbanken besprochen. Dazu gehören natürlich auch Modellierung als ERM, das Relationale Modell und Normalisierung. Normalformenlehre bis zur 3NF war ebenfalls ein schwerer Inhalt der Vorlesung. Ähnlich beliebt war die Relationale Algebra. Aber natürlich wurde sich auch mit den Anfragen an eine Datenbank und damit mit SQL beschäftigt. Vom "CREATE TABLE" über dieverse Querystatements und DML. Im zweiten Teil des Anfragen Blocks wurden dann über Mengenoperationen und Joins geredet. Doch auch andere einblicke und überlegungen wurden nicht vergessen. Zum Beispiel wurde über das Thema Anfrageoptimierung gesprochen und wie die Datenbank überhaupt damit umgeht. Also das Parsen der Anfrage und das optimiren der Anfrage innerhalb des DBMS. Auch auf das DBMS wurde ein Blick geworfen. Also den Hintergrund zu Transaktionen, also wie geht das System mit Mehreren Usern um, Timen und Sprerren von Daten und den Umgang mit Fehlern. Außerdem wurde ganz oberflächlich das Protokollieren von Änderungen und Sichern von Daten in der Datenbank angesprochen. Letztendlich wurden aber auch Konzepte zur Programmierbarkeit von Datenbanken bzw den zugriff von Programmen auf Datenbankden angesprochen. Das bedeutet das installieren und verweden von Stored Procedures. Und für Programme das verwenden von Treibern und dem Cursor Konzept.

In den Übungen wurde ein eigenes Datenanalyse Projekt mithilfe einer eigenen Datenbank gemacht. Als grundlage dazu dienten die Daten die 2006 beim AOL Research Data Leak öffentlich wurden und mehrfach gespiegelt. Jede gruppe sollte eine eigenes Thema sich ausdenken, was man aus den Suchdaten vo AOL Evaluieren könnte. Ich habe mich mit meinem Partner dazu entschieden die Marktposition von Nintendo, seinen Konsolen und Spielen und den vergleich mit anderen herrauszufinden. Dies Bot sich an, weil zu dem Zeitpunkt gerade das erscheinen von Nintendos erster Wii Konsole war. Auf der Haupseite sieht man unser Daten Modell. Erst haben wir uns interessante Fragen überlegt und dann daraus, wie unser Modell aussehen muss. Danach haben wir eine eigene Sammlung von den AOL Daten bezüglich Nintendo Probiert. Dabei stellten wir fest, dass das garnicht so einfach ist. Denn die Leute suchen doch so unterschiedlich und aus unterschiedlichen Gründen. Weiter ist es Schwer, weil die User Oft die Abkürzungen für Nintendos Konsolen verwendet haben, welche manchmal teil eines Alltagsworts sind, besonders im Englischen wie zum Beispiel die "NES" Konsole mit klein geschriebenem "nes" auch in "business" steckt. Hatten wir das in der Datenbank, mussten wir noch die Anfragen aufstellen, die die Antworten für unsere Fragen ergaben. Soweit so gut. Doch im letzten Teil ging eine Doppelarbeit los. Denn wir mussten noch die Analyse betreiben wer hat nach was gesucht. Das Vernüpfen erforderte aber erstmal weiteren Input, wie die Konsolen oder Spiele Namen. Diese mussten aber erstmal in die Datenbank gespeist werden, wärend gleichzeitig die ergebnisse dargestellt werden mussten. Dafür haben wir mehere Python Programme geschrieben und dabei Python als mächtige Datenbank Programm Sprache kennen gelernt.

Das Bild Links zeigt das Ergebnis der Marktaufteilung unter den Herstellern 2006, welches sich aus unseren Daten ergab. Die anderen Bilder zeigen den Python Code, der uns die ganzen Anfragen an die Datenbank schicken und die Ergebnisse in die Grafiken umwandeln ließ.