Praktikumsbericht - Freie Universität Berlin

Freie Universität Berlin, Fachbereich Mathematik und Informatik
Institut für Informatik, Studiengang Informatik
Praktikumsbericht
von
Arne Müller
4216060
[email protected]
16. Dezember 2008
Secrypt Gmbh, Bessemerstraÿe 82, 12103 Berlin
vom 4.8.2008 bis 26.9.2008
Betreuer: Matthias Schlede, [email protected]
1
Arne Müller
Praktikumsbericht
16. Dezember 2008
Inhaltsverzeichnis
1 Praktikumsstelle
3
2 Aufgaben und Tätigkeiten
4
2.1
2.2
2.3
Tätigkeitsumfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aufgabe und Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tätigkeiten und Arbeitsergebnisse . . . . . . . . . . . . . . . . . . . . .
3 Einsichten und Fazit
3.1
3.2
3.3
3.4
3.5
Technik . . . . . . . . .
Methodik . . . . . . . .
Sonstiges . . . . . . . .
Fazit . . . . . . . . . . .
Anmerkung zum Schluss
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
(nachträglich) .
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
8
. 8
. 9
. 9
. 10
. 11
Arne Müller
Praktikumsbericht
16. Dezember 2008
1 Praktikumsstelle
Am schwarzen Brett im Informatik-Gebäude hing ein Aushang von der Secrypt-Gmbh,
die nach Studentische Hilfskräfte aber auch Praktikanten in der Software-Entwicklung
suchte. Also bewarb ich mich bei der Firma.
Secrypt ist einer kleine Firma im Bereich elektornischer Signaturen. Sie produzieren
Software mit der Dokumente unterschiedlichster Formate und eingescannte PapierDokumente signiert werden können. Obwohl die Firma aus ungefähr 10 Mitarbeitern
besteht, haben sie groÿe Kunden wie z.B. Siemens und kooperieren mit D-Trust, einer
Tochterrma der Bundesdruckerei.
Die Firma hat 4 Hauptprodukte: DigiSeal Reader, eine kostenfreie Software um Signaturen zu verizieren. DigiSeal Oce, um Dokumente zu Signieren und Verschlüsseln. DigiSeal Server, um über Dateischnittstellen Dokumente in Stapelverarbeitung
zu signieren bzw. zu verizieren. DigiSeal 2DBarcode, einem 2D-Barcode in dem beliebige Dateien gespeichert werden können, z.b. um ein eingescanntes Dokument und
dessen Signatur darin zu speichern. Der Barcode ist auf Grund ranierter Komprimierungsmethoden in der Regel 1/10tel des eingescannten Dokuments groÿ, enthält aber
auch reduntante Informationen für Fehlerkorrekturen.
Ich habe hauptsächlich mit dem DigiSeal Server gearbeitet.
Abbildung 1: ozielles Organigramm der Firma aus deren QM-Dokumentation
Meine Gruppe bestand aus 4 Softwareentwicklern die direkt mit einem der Geschäftsführer, Herrn Schlede, zusammenarbeiten. Mein Betreuer, Herr Schlede, ist Geschäftsführer und Softwareentwickler.
Leider habe ich keine Bezahlung bekommen. Mir war das allerdings auch nicht so
wichtig, mir waren interessante Aufgaben wichtiger, somit habe ich mich vielleicht bei
meinem Vorstellungsgespräch diesbezüglich auch etwas ungeschickt angestellt.
3
Arne Müller
Praktikumsbericht
16. Dezember 2008
Ich habe 8 Wochen lang Praktikum gemacht, weil ich mir das Praktikum später
eventuell auch vom Mathematikfachbereich anerkennen lassen möchte. Mit meinen
Arbeitszeiten war ich sehr exibel, aber in der Regel war ich von 10.00 Uhr bis 18.00
Uhr in der Firma.
2 Aufgaben und Tätigkeiten
2.1 Tätigkeitsumfeld
Ich war in der Softwareentwicklung tätig. Dort habe ich an einem Subprojekt gearbeitet um XML-Signaturen zu verizieren und später auch zu signieren. Es wird von
den Hauptprodukte DigiSeal Server, DigiSeal Oce und DigiSeal Reader der Firma
benutzt. Das Signieren und Verizieren von XML-Signaturen (siehe [5]) war, als ich
das Projekt begonnen habe, schon eingeschränkt möglich. Allerdings wurde auch die
Implementierung von XPath- und XPointer-Ausdrücken (siehe [1], [4], [3]) benötigt,
welche ich dann gröÿtenteils eigenständig geschrieben habe. Die Implementierung der
neuen Features erforderte allerdings auch etwas Umdenken bei Schnittstellen, die nicht
direkt etwas mit den XPath- und XPointer-Ausdrücken zu tun hatten. Somit musste
ich mich dann mit den anderen Entwicklern absprechen, da die Änderungen teilweise
nicht kompatibel mit den angedachten Workows war.
2.2 Aufgabe und Ziele
Ich sollte XPath- und XPointer-Unterstützung für die Implmenentierung der Secrypt
zur XML-Verikation implementieren. Ich weiÿ nicht, wie lange eingeplant wurde,
dass ich dafür brauchen würde. Am Anfang rechnete ich und ich vermute auch die Firma mit ca. 2 Wochen, da schon groÿe Teile existierten. Da die existierende Struktur
aber teilweise unbrauchbar war und auch die Verwendung von XPath- und XPointerAusdrücken von den anderen Softwareentwicklern falsch verstanden war, brauchte ich
dann doch länger, sodass ich danach hauptsächlich den DigiSeal Server und die zugehörige API testete und nur noch dazu kam ein paar Kleinigkeiten und Erweiterungen
für den XML-Signatur und XML-Verikations Code zu entwickeln.
Während des Praktikums wollte ich ein genaueres Verständnis von Signatur und
Verschlüsselungsmechanismen bekommen, also z.B. mit welchen Problemen man sich
dabei herumschlagen muss. Auch wollte ich einen Überblick bekommen um selber Einschätzen zu können, wie sicher kryptographische Methoden heutzutage sind und wie
mit diesem doch sehr sensitiven Gebiet innerhalb der Firma umgegangen wird. Auÿerdem wollte ich herausnden, wie es ist in der Privatwirtschaft zu arbeiten um später
eine gute Entscheidung zwischen Universitätskarriere und Privatwirtschaft treen zu
können.
4
Arne Müller
Praktikumsbericht
16. Dezember 2008
2.3 Tätigkeiten und Arbeitsergebnisse
Das Hauptgebiet in dem die Firma aktiv ist, ist die Verikation und Signierung von
Dokumenten. Da aber die Art der Domukmentsignierung von den Dateitypen abhängt,
können a priori nicht alle Signaturtypen unterstützt und geschrieben werden. So konnten, als ich mein Praktikum begonnen habe, XML-Dateien nur sehr eingeschränkt mit
Signaturen versehen werden bzw. in XML-Dateien enthaltene Signaturen veriziert
werden.
Allerdings ist XML ein sehr weit verbreitetes Format, sodass es auch schon eine
OpenSource-Implementierung (siehe [6]) für XML-Signaturen gab, die auch von der
Firma benutzt wurde. Die Benutzung der OpenSource-Bibliothek wurde durch einen
Wrapper verdeckt.
Somit war meine erste Aufgabe diesen Wrapper anzupassen, sodass auch möglichst
alle signierten XML-Dateien veriziert werden konnten. Dies war unter anderem für
Mehrfach-Signaturen wichtig, da dies vorher mit der eingeschränkten Verikationsimplementierung nicht möglich war. Die Firma hatte ein eigenes Debug- und Fehlermanagementsystem entwicklet. Dieses war nicht intuitiv zu verstehen, da davon zwei
Versionen ineinander vermischt benutzt wurden und die Funktionen und Makros in
bestimmter Art und Weise genutzt werden sollten. Da mein Code später mit dem
der Firma interagieren sollte, musste ich dieses Log-System auch in meinem Code
benutzen.
Das Programmieren stellte für mich kein besonderes Problem dar, da ich schon in C,
C++ programmiert hatte und mich somit teilweise mit einigen der hässlichen Tricks
auskannte. Ich bin allerdings noch viel mehr davon begegnet.
Der schwierigste Teil dieser Aufgabe war es allerdings die XML-Spezikationen zu verstehen um herauszunden, ob der Wrapper das macht, was man nach Spezikation
erwarten sollte oder nicht. Dies war gar nicht so einfach und ich musste mehrfach
meinen Code umschreiben, da die Methoden von anderen Entwicklern nicht zu dem
Verarbeitungsuss, den die Spezikation vorschlug, passten. Diese Methoden habe ich
dann konsequenter Weise auch angepasst. Auch musste ich teilweise ein paar algorithmische Probleme lösen, die die benutzen Bibliotheken in der Form noch nicht implementierten, bzw. nicht sonderlich performant.
Z.B. gibt es XPath-Transformationen, die aus einer Liste von XPath-Ausdrücken bestehen (siehe [4]). Jeder dieser Ausdrücke beschreibt eine Menge von Wurzel-Knoten
von Teilbäumen des Dokumentes. Nun können diese einzlenen Ergebnisse aus der
Evaluierung der XPath-Ausdrücke in Form von Mengenoperationen miteinander vereinigt, geschnitten und subtrahiert werden. Da häug gröÿere Teilbäume beschrieben
werden, war es meiner Ansicht nach nicht sehr performant diese aufzulösen und auf den
Knoten in den Bäumen direkt zu arbeiten. Deswegen implementierte ich Methoden,
die Schnitt, Vereinigung und Subtraktion auf den Teilbäumen direkt ausführten. Im
Endeekt bestand die Grundidee für jede der 3 Operationen darin, für jeden Knoten
des einen NodeSets bis zu einem Elternknoten des anderen NodeSets oder Wurzel-
5
Arne Müller
Praktikumsbericht
16. Dezember 2008
knotens den Baum zu traversieren und abhängig von dem Typ der Transformation
den Ausgangsknoten in eine neue Liste einzufügen oder zu löschen. Ein bischen hinderlich war, dass es in C++ keine vernünftige HashSet Implementierung gibt und ich
somit die HashTable Implementierung der Firma nutzte, die zwar auch ihre Vorteile
besaÿ, aber z.B. sich nicht selber vergröÿern konnte. Durch diese Verbesserungen und
einige simple Änderungen in dem Signatur-Code, der diese Transformationen aufrief
(es wurde z.B. vorher eine verkettete Liste über Index-Zugri traversiert!) konnte ich
meinen Code so performant machen, dass die Stellen, die langsam waren, komplett in
der libxml2 [6] lagen.
An mehreren Stellen war die Spezikation etwas ungenau und ich konnte das gewollte
Verhalten nur aus den Beispieldateien und einer Referenzimplementierung in Java
ablesen. Dies war sehr unzufriedenstellend. Am Anfang betraf das wenigstens nur Teile,
die ich selber schreiben musste, wo ich also viel Kontrolle über das Verhalten hatte.
Zum Schluss hatte ich aber auch einen Fall, wo die Implementierung der benutzen
OpenSource nicht der Referenzimplementierung von Sun in Java entsprach und bei
mir somit die Verikation fehlschlug. Darauf hin habe ich die entsprechende Datei in
der Bibliothek editiert (glücklicherweise war sie OpenSource) und einen Bugreport bei
dem OpenSource Projekt eingesendet. Allerdings lag der Bug in einem Teil, der durch
meinen Fix eventuell vorher mit dem Bug signierte Dateien nicht mehr verizierbar
macht. Somit warte ich gespannt auf die Reaktionen auf meinen Bugreport. Es stellte
sich heraus, dass der Bug doch keiner war und ich lediglich etwas falsch verstanden
hatte.
Dies führte unter anderem dazu, dass ich die Aufgabe in manchen Punkten anders
eingeschätzt hatte und somit teilweise nachher Änderungen durchführen musste, die
zwar durchhaus möglich waren, aber da nicht antizipiert die Struktur verschlechterteten
und somit das Programm Fehleranfälliger machten.
Auch musste an manchen Stellen das Vehalten von einem Code so angepasst werden,
damit er mit älteren Versionen konform ist, die aufgrund von Implementierungsfehlern
teilweise falsch signiert oder veriziert haben. Es war garnicht immer so einfach diese
Probleme zu umgehen, ohne selber weitergehend dieselben Fehler zu behalten. Erstaunlicherweise wurden mehr oder weniger zufriedenstellende Lösungen gefunden.
Ich war mit meiner ersten Aufgabe im Grunde nach 4 Wochen fertig. Danach bearbeitet mein Programmcode zuverlässig die Beispieldateien und er sollte in das dort
existierende Framework integriert werden. Ich hatte ihn vorher nämlich nur mit TestMethoden getestet, um nicht die ganze API des Produkts benutzen zu müssen. Diese
Test-Methoden unterschieden sich dann teilweise von dem gesamten API, welches
dazu ausgelegt war auf mehreren Prozessoren getrennt laufen zu können und somit
Beschränkungen auferlegte, die mir anfangs nicht klar waren. Für die Anpassung war
ich dann selber nicht mehr verantwortlich, sondern einer der anderen Softwareentwickler hat dies gemacht. Allerdings schien er auch nicht soviel Überblick über den Code
zu haben, sodass es eine Weile inklusive mehrere Abstürze des Programmes gedauert
hat, bis die Einbettung erfolgt war. Diesen Teil fand ich überhaupt nicht schön, da
meiner Meinung nach der Code einfach geändert wurde, ohne zu gucken, ob es in
6
Arne Müller
Praktikumsbericht
16. Dezember 2008
bestimmten Bereichen sinnvoll ist, bzw. andere Schnittstellen kaputt macht. Das alles
wurde lediglich per Hand durch Testfälle über das Gesamtsystem abgestet. Ich fand
es erschreckend, wie sich auf solche Testfälle verlassen wurde, ohne geziehltes UnitTesting. Und nach jeder Änderung musste dann quasi nochmal alles getestet werden.
Es wurde danach sehr intensiv auf dieser obersten Ebene getestet, weil ein neues Release veröentlicht werden sollte.
Erstaunlicherweise lag nur einer der vielen später XML-bezüglich aufgetauchten Fehler
in dem Teil des Programmcodes, den ich geschrieben hatte, und dies war ein vergessenes
return-statement, was manchmal zu komischen Fehlern führte und somit schwer zu
nden war.
Theoretisch wären ja kleine Bugs nicht so schlimm, solange die essentiellen Teile wirklich gut durchgetestet sind und man sich sicher sein kann, dass keine komischen Eekte
auftauchen (weil man weiÿ, dass bestimmte Teile nichts miteinander zu tun haben).
Diese Unabhängigkeit der Komponenten scheint aber nicht der Fall gewesen zu sein,
was ich hochgradig fahrlässig für Verschlüsselungs und Signatur-Technik nde. Im
Nachhinein habe ich das Gefühl, dass einfach vieles mehrfach implementiert war und
dadurch kleine Änderungen viele Nebeneekte auf sich zogen.
Dieses Testen dauerte bis zum Ende meines Praktikums, wo dann an meinem letzten Tag das Release fertig gestellt wurde. Auch ich wurde in das Testen eingebunden
und so sollte ich, da sich in meinem Teil aber keine Fehler mehr fanden, sondern nur
noch in der Einbindung von meinem Code, meine Funktionen direkt mit dem DigiSeal
Server und deren API, welches Kunden angeboten wird, testen. Diese Arbeit war
relativ langweilig, nicht sehr zielgerichtet und irgendwann auch keine Bugs mehr für
mich aundbar, sodass ich die Entwicklung von weiteren XML-Funktionen angestoÿen
habe. So schrieb ich einen Wrapper für die zur libxml2 passsenden Bibliothek libxslt
[6], um auch XSL Transformationen (siehe [2]) zu ermöglichen. Aufgrund meines modularen Konzeptes des ersten Teils, war dies sehr leicht zu integrieren. Da ein anderer
Praktikant parallel damit beauftragt war ein Online-Update-System zu entwickeln, bei
dem die Update-Informationen mit einer XML-Datei übertragen werden, sollte diese
XML-Datei auch mit meinem Signatur-Code signiert werden. Allerdings genügte es
nicht, diese XML-Dateien gewöhnlich mit einer enveloped-Signatur zu versehen, wie
sie bis dahin nur unterstützt wurde. Sondern es sollten bestimmte Elemente nicht signiert werden. Also mussten für den Signatur-Prozess die benutzten Transformationen
exibel kongurierbar sein und somit implementierte ich dieses Feature ebenfalls. Es
können nun also alle möglichen vorstellbaren XML-Signaturen erzeugt werden. Die
Verikation derselben hatte ich ja in meinem ersten Teil schon erledigt.
Dabei bemerkte ich eine Sicherheitslücke, die erstmal überhaupt nicht ernst genommen wurde und in die ich einige Arbeit investieren musste um diese zu verdeutlichen.
Durch die Transformationen die in einer XML-Signatur vorgenommen werden, muss
der Signaturgegenstand (das sind die Daten, die signiert wurden) nicht gleich dem
Dokument ohne Signatur sein. Somit kann z.B. ein XML-Dokument eine gültige Signatur besitzen, die aber keine XML-Elemente (also quasi ein leeres Dokument) sig-
7
Arne Müller
Praktikumsbericht
16. Dezember 2008
niert. Diese Problematik wurde aber vorher wissentlich in Kauf genommen, da man
nicht mehrere Signaturgegenstände haben wollte, die evtl. sogar keine wohlgeformten
XML-Dokumente sind. Besonders kritisch wurde dies für das Online-Update, da dort
automatisch das XML-Dokument geprüft werden sollte und natürlich die wichtigen
Elemente des Dokumentes auch signiert sein sollten. Also baute ich zunächst aus existierenden signierten XML-Dokumenten, um die Lücke zu demonstrieren, eine Datei,
die bei dem Online-Update als Ok durchgegangen wäre, aber garnicht die wichtigen
Elemente signiert hätte. Darauf hin implementierte ich in meiner letzten Woche noch
zwei Klassen, um die Signaturgegenstände zu verwalten und um zu prüfen, welche
Knoten signiert wurden und welche nicht. Dem anderen Praktikanten erklärte ich dann
diese neuen Funktionalitäten und dabei stellte sich heraus, dass er sehr inezient sein
Programm entwickelte. So erklärte ich ihm, dass es nicht sinnvoll ist, vorläugen Testcode in die zu entwicklenden Methoden hineinzutun, da ja später diese Daten auch
von Auÿerhalb kommen würden um man sie also folglich analog über Testfunktionen
setzen könne.
Als Ergebnis denke ich, dass ich mich nun sehr gut mit Signaturen in XML-Dokumenten auskenne, da ich fast alle dafür Spezikationen gelesen und implementiert
habe (auch wenn ich entsprechende Funktionen an eine Bibliothek weitergeleitet habe,
aber dort musste ich dennoch verstehen, was die benutzen Funktionen machen). Auch
weiÿ ich nun, dass das Testen von Code extremst langweilig un nervtötend sein kann
und man deshalb eigentlich komplizierten nicht so Performance kritischen Code nicht
in C++ schreiben sollte, da man nur Scherereien mit Memory Leaks bekommt.
3 Einsichten und Fazit
3.1 Technik
Ich habe hauptsächlich unter Windows mit Visual Studio in C++ gearbeitet. Im allgemeinen ist C++ im Vergleich zu Java eine relativ eklige Sprache, da man z.B. auf
Memory-Leaks aufpassen muss. Erstaunlich und schön fande ich die Überwachung von
nicht initialisierten Variablen und unerlaubten Speicherzugrien im Debug-Modus.
Auch der Debugger war sehr brauchbar. Mit gewissen Tricks konnten auch MemoryLeaks aufgespürt werden (z.B. durch neu-Denition des new Operators). Allerdings
kann ich dies nicht mit anderen IDE's vergleichen, da ich bisher nur Java in eclipse
programmiert habe und man in Java ganz anders Programmiert.
Ich habe zwar in C++ programmiert, allerdings war die benutzte OpenSource-Bibliothek (libxml2) in C programmiert. C ist zwar an sich nicht objektorientiert, allerdings
wird trotzdem versucht pseudo-objektorientiert zu programmieren, indem man die
Reihenfolge von Feldern im Struct so sortiert, dass sie in mehreren Structs gleich sind,
sodass man auch unter Verwendung des falschen Pointer-Typs auf die richtigen Felder
zugreifen kann. Das ist einfach häÿlich und kann auch böse Fehler produzieren, sodass
ich nicht freiwillig wieder in C oder C++ programmieren würde, wenn es nicht wirklich
8
Arne Müller
Praktikumsbericht
16. Dezember 2008
performancekritisch ist.
3.2 Methodik
Wenn man ein neues Feature implementieren soll, erst genau die Spezikation lesen
und dann auf die Schnittstellen achten, die andere Programmierer vor einem schon
geschrieben haben, da diese eventuell die Spezikation missachten oder nur eingeschränkt
implementieren und man dadurch für die Wahl der Datenstrukturen verwirrt wird.
Wenn ich etwas Wesentliches an Methodik gelernt habe, so ist es das Lesen von Spezikationen und RFC's und deren Implementierung. Man überliest so leicht kleine Feinheiten, weil das soviel Text ist und man keine Lust hat sich durch teilweise doch viel
unnötige Informationen durchzuwühlen, weil man Teile auch an andere Bibliotheken
weitergibt und sich nicht dafür zuständig fühlt.
Selbst wenn man versucht bugfrei zu programmieren, schat man dies nicht, da andere
die Spezikationen anders verstehen können als man selbst oder man was überlesen hat.
Nach meiner Programmiererfahrungen gibt es nur 2 wesentliche Fehlerquellen, wenn
man ordentlich und durchdacht programmiert: Speicher-Verwaltung, weil beim Programmentwurf das erstmal unwichtig erscheint und man überall davon kleine hässliche
Pointerfehler einbauen kann, und die Umsetzung menschengeschriebener Dokumente,
wie Spezikationen. Da kann man einfach nicht mit mathematischen Schlussfolgerungen sich die Korrektheit verdeutlichen. Einer der Softwareentwickler beweist sogar
Teile seines Programmcodes, aber auch der war nicht bugfrei.
In einer Firma wird anscheinend wegen Zeitdruck oder ähnlichem teilweise sehr schlampig programmiert. Dagegen kann der eigene bugfreie Code auch nicht viel helfen.
Mit einer besseren Einführung in die API für die Produkte hätte ich eventuell Einbindungsprobleme reduzieren können.
3.3 Sonstiges
Die Firma hatte ein Qualitätsmanagementsystem, vorher hatte ich nicht gewusst, dass
es sowas für die Struktur von Firmen gibt, bzw. geben muss, damit eine Firma Aufträge
aus der öentlichen Hand annhemen kann. Interessant fand ich, dass dort alle Prozesse
bürokratisch festgelegt sind. Allerdings musste ich anhand von dem Projekt an dem
ich arbeitet, feststellen, dass dieses Qualitätsmanagement mehr oder weniger ignoriert
wurde, da das ja ein internes Projekt ist und somit nicht so wichtig. Somit fehlten
ozielle Testzyklen, auch wenn ich natürlich selber Tests auf den unterschiedlichen
Ebenen selber ausgeführt habe.
Ein vernünftiges Versionssystem ist auÿerdem anscheinend nicht so wichtig, wie ich
mir das vorher dachte. Ich war total überrascht, dass anstelle eines CVS oder SVN
Repositories, ein selbst geschriebenes Shellskript benutzt wurde, welches über komplizierte Datei-Listen die Dateien abgleichte. Auÿerdem wurde auch immer nur die
aktuellste Version neben ein paar Branches und täglichen Sicherheitskopien auf dem
9
Arne Müller
Praktikumsbericht
16. Dezember 2008
Abgleich-Server gespeichert.
Im Ganzen funktionierte die Softwareentwicklungsgruppe meiner Meinung nach sehr
gut, was vermutlich teilweise durch die ache Struktur begründet war. Teilweise gab
es aber auch Stress, wenn kurz vor dem Release noch Bugs von der Testabteilung
gefunden wurden. Es wurde aber dann keiner für den Fehler als schuldig befunden,
sondern man hat sich lediglich darüber geärgert, dass nun wieder alles neu compiliert
werden musste, was pro Produkt immer ca. eine Stunde dauerte.
Ich hätte vermutlich in den zweiten 4 Wochen nach dem XML-Projekt auch noch etwas
neues anfangen können und vermutlich auch die Zeit gehabt das gut fertigzustellen,
allerdings wussten die in der Firma keine gute Aufgabe und es musste das Release fertig
gestellt werden. Vermutlich hätte ich vehementer nach einer neuen, anspruchsvolleren
Aufgabe fragen sollen, dann hätte ich micht in der zweiten Hälfte nicht so gelangweilt.
Interessant fand ich die alltägliche Diskussion wegen Essen. Die Firma hat keine Kantine in der gegessen werden kann, es kommt lediglich ab und zu ein Sandwich-Mann
und man kann sich von gegenüber der Firma im Supermarkt oder bei nem Imbiss
was kaufen. Da das aber nicht viel Vielfalt bietet, kam mehrmals die Diskussion auf,
wer und wohin losfährt um Essen zu kaufen. Da ziehe ich doch dann auf Dauer die
FU-Mensa vor ;-)
3.4 Fazit
Wärend meiner Studiums hätte ich nie gelernt, wie es ist in einer Firma zu arbeiten.
Auch wenn secrypt selbst noch sehr klein ist, kann ich mir glaube ich relativ gut
vorstellen, wie es ist in einer Firma zu arbeiten. Auch weiÿ ich jetzt, dass extensives
unkontrolliertes Testen nervtötend ist, nur weil keine fehlerhaften Produkte ausgeliefert
werden sollen, auch wenn die Fehler nur kleinerer Natur sind. Begründet vermutlich
durch schlampige Programmierung.
Zudem bin ich selber eher der Theoretiker. Deshalb hungert es mich aktuell nach immer mehr und aktuellerem Wissen. Im Studium ist man meiner Meinung viel näher
an aktueller Forschung dran als in einer Firma. Da in einer Firma durch künstliche
Verknappung des Informationsusses, wegen der Angst vor Konkurrenten, Innovation
nicht so schnell voranschreiten kann. So habe ich zum Beispiel erfahren, dass XMLSignaturen angeblich erst seit wenigen Monaten wirklich in der Industrie benutzt werden. Dies fand ich sehr erstaunlich, da ich selbst im Frühling dieses Jahres damit herum
gespielt habe und dies eigentlich als eine sehr natürliche Idee empfand.
Insgesamt hat mir das Praktikum viel Spaÿ gemacht und ich denke, dass es einigermaÿen interessante Probleme auch in der Wirtschaft gibt und die Atmosphäre häug sehr locker war. Dennoch denke ich, dass ich vorziehen würde noch tiefer in die
Forschung einzudringen, da die Implementierung von RFC's zwar teilweise algorithmisch anspruchsvoll, aber nicht unbedingt kreativ ist.
10
Arne Müller
Praktikumsbericht
16. Dezember 2008
3.5 Anmerkung zum Schluss (nachträglich)
Ich habe über eine Woche vor Ende meines Praktikums angesprochen, dass ich eine
Praktikumsbescheinigung benötige und auch gerne ein Zeugnis haben möchte. Jetzt
ist mein Praktikum schon 5 Wochen vorbei und ich habe mehrmals bei der Praktikumsstelle angerufen und habe immer noch nicht die Praktikumsbescheinigung erhalten. Darüber bin ich sehr frustiert. Ich wurde Woche für Woche vertröstet, dass
die die Praktikumsbescheinigung bald ausstellen würden, so dass ich bis jetzt gewartet
habe meinen Praktikumsbericht abzugeben, um dies mit der Praktikumsbescheinigung
zusammen machen zu können 1 . Von diesem Gesichtspunkt ist von Secrypt als Praktikumsstelle abzuraten.
Literatur
[1] W3C. Xml path language (xpath) version 1.0. http://www.w3.org/TR/xpath,
1999. [Online; Stand 4. Dezember 2008].
[2] W3C. Xsl transformations (xslt) version 1.0. http://www.w3.org/TR/xslt, 1999.
[Online; Stand 4. Dezember 2008].
[3] W3C. Xml pointer language (xpointer). http://www.w3.org/TR/xptr, 2002. [Online; Stand 4. Dezember 2008].
[4] W3C. Xml path language (xpath) 2.0. http://www.w3.org/TR/xpath20/, 2007.
[Online; Stand 4. Dezember 2008].
[5] W3C. Xml signature syntax and processing (second edition). http://www.w3.
org/TR/xmldsig-core/, 2008. [Online; Stand 4. Dezember 2008].
[6] xmlsoft. The xml c parser and toolkit of gnome. http://xmlsoft.org/. [Online;
Stand 4. Dezember 2008].
1 Nach 2 Monaten habe ich nun mein Praktikumszeugnis erhalten, dabei auch ein Exemplar mit
elektronischer Signatur
11