OK, die Antwort auf diese Frage wird etwas länger.

In diesem Semester betreue ich mal wieder das Softwareentwicklungsprojekt bzw. Modellierungspraktikum. Dieses Jahr bieten wir erstmals Saalübungen an und in einer solchen hab ich versucht, genau die oben stark vereinfacht hergeleitete Frage etwas aufzuklären.

Letztendlich liegt hier das, was Softwareentwicklung manchmal zu einer Art “Kunst” werden lässt. Ein scheinbar undefiniertes Wissen, das einfach aus “Erfahrung” zu kommen scheint. Aber ganz so undefiniert ist dieses Wissen gar nicht. Viel davon lässt sich in einfachen Prinzipien, Heuristiken oder “Daumenregeln” zusammenfassen, was ein gewisses Maß an Wissenstransfer ermöglicht. Ich habe darüber schon das ein- oder andere Mal geschrieben. Leider wird so etwas nur selten wirklich gelehrt, auch, wenn es machbar wäre. Man kann damit problemlos ganze Vorlesungen füllen. Ich hab versucht, das in eine 90-minütige “Saalübung” zu quetschen. Und vielleicht war es sogar ein bisschen hilfreich.

Ich habe diesmal neben den eigentlichen Folien ein separates Handout gemacht. Das hat den Vorteil, dass die Folien nicht selbsterklärend sein müssen und deshalb knapper und übersichtlicher sein können. Auf der anderen Seite kann das Handout ausführlicher und beschreibender sein. Das Handout ist damit zwar noch kein ausführliches Tutorial, aber zumindest mal ne kurze Einführung in die Problematik und sollte auch verständlich sein, wenn man meinen Vortrag nicht gehört hat.

Das ist das erste Mal, dass ich das so gemacht habe. Feedback ist also herzlich willkommen. insbesondere weil ich mir überlege, ob ich das für meinen Vortrag auf den nächsten Delphi-Tagen auch so machen soll.

Hier ist also das Handout: Download: Wie man Software entwirft -- Handout (Größe: 4.13 MB; bisher 16 mal heruntergeladen)
Hier die Folien: Download: Wie man Software entwirft -- Folien (Größe: 4.05 MB; bisher 11 mal heruntergeladen)
Und hier der Source: Download: Wie man Software entwirft -- Source (Größe: 3.9 MB; bisher 9 mal heruntergeladen)

Hier meine Seminararbeit:
Download: Continuous Integration: Aspects in Automation and Configuration Management (Größe: 355.51 kB; bisher 33 mal heruntergeladen)

Und hier die zugehörige Präsentation:
Download: Continuous Integration (Präsentation) (Größe: 1.4 MB; bisher 31 mal heruntergeladen)

Wer sich für CI interessiertn sollte aber vielleicht eher den einschlägigen Artikel von Martin Fowler und/oder das Buch von Paul Duvall lesen.

OK, Spaß beiseite. Ob die Ente aus Gummi ist oder ausgestopft, spielt keine Rolle. Hauptsache sie ist tot. Wobei eine lebende Ente vielleicht auch…

Nein, ich hab keine Rauschmittel zu mir genommen. Ich will damit tatsächlich etwas Ernsthaftes sagen: Manchmal ist es hilfreich, ein Problem einfach nur mal detailliert zu erklären; und auf einmal löst es sich wie von selbst.

Mir ist das des öfteren schon selbst passiert. Ich stand vor irgend nem Problem und mir wollte die Lösung partout nicht einfallen. Also hab ich mich entschlossen, die Frage anderen zu stellen und auf ne hilfreiche Antwort zu hoffen. Sowas tue ich gerne auch in Webforen. Und in solchen Webforen muss man sein Problem genau erläutern:

– Was ist der Kontext?
– Was ist das Problem?
– Was hab ich gemacht?
– Was hätte passieren sollen?
– Was ist stattdessen passiert?

Dazu noch ein paar schöne Zeilen Code oder ein Beispiel und dann weiß jeder was mein Problem ist. So werden die anderen User in die Lage versetzt, hilfreich zu antworten. Und manchmal versetzt man sich so auch selbst in die Lage, das Problem zu lösen. In so einem Fall ist es gar nicht mehr nötig, die Frage auch wirklich zu posten. Man hätte die Frage genauso gut ner ausgestopften Ente stellen können.

Oftmals sitze ich auch auf der anderen Seite. Ich lese Fragen und beantworte sie. Manchmal lese ich Fragen, bei denen sich der Fragensteller augenscheinlich keine große Mühe bei der Formulierung gegeben hat. Das ist nicht nur unhöflich (jemand erwartet eine kostenlose Antwort, die mitunter Mühe kostet, will sich aber selbst keine Mühe machen), sondern erschwert auch die Hilfe. Und auch das Quietscheentchen wird einem nicht weiter helfen, wenn man es nicht erst nimmt und das Problem nicht genau erläutert.

Dazu fällt mir noch ein Erlebnis aus meiner Schulzeit ein: Im Physikunterricht hatten wir den Druck in Flüssigkeiten durchgenommen. Ich hatte mir schon einige Zeit vorher vorgenommen, bei Gelegenheit ne Frage zu stellen: Druck hat man ja früher in “Millimeter-Quecksilbersäule” gemessen. Warum geht das? Müsste das nicht von der Bauart des Barometers abhängen?

Ich stellte also meine Frage. Der Lehrer wiederholte die Frage und auf einmal schoss mir die Antwort durch den Kopf. Ich konnte die Frage ja mit meinem eigenen Physikwissen beantworten! Des Rätsels Lösung ist das Hydrostatische Paradoxon, das wir schon kennen gelernt hatten. Ich hatte die Frage gestellt ohne selbst nochmal darüber nachzudenken. Kaum hatte ich die Frage gehört, war die Antwort sonnenklar. Hätte ich die Frage vorher ner Gummiente erzählt, wär mir ne kleine Peinlichkeit erspart geblieben.

Zu den Quietscheentchen:

• Wikipedia: Rubber duck debugging
• Coding Horror: Rubber Duck Problem Solving

(via)

Aaaalso, liebes Entchen, ich hab da mal ne Frage…

Ich hab ja schon mal sein Blog verlinkt, aber jetzt will ich doch noch mal etwas mehr dazu schreiben.

Joel Spolsky ist Software-Entwickler, ehemaliger Teig-Schieber in einer Großbäckerei, hat mal bei Microsoft gearbeitet und ist Mitgründer von StackOverfow. Und er kann wirklich interessantes Zeug schreiben. Wenn ich sein Blog lese, merke ich, wie langweilig und trocken meine Blog-Posts manchmal doch sind. Allein schon durch seinen Schreibstil kann ich einiges lernen, denke ich.

Aber was kann man da nun eigentlich lesen? Viel. Hier mal ein Ausschnitt dessen, was ich in letzter Zeit von ihm gelesen hab:

• Etwas, worüber ich bisher zu wenig gelesen hab, ist UI Design. Wie erstellt man eine wirklich benutzbare Schnittstelle? Eine die effizient ist, leicht zu lernen und Spaß macht zu benutzen. Ein bisschen was Grundlegendes kriegt man in der Uni beigebracht, aber da fehlt meiner Meinung nach noch einiges. Spolsky hat dazu was geschrieben und bisher hab ich auch nur einen Teil davon gelesen. Das, was ich bisher gelesen hab, ist jedenfalls empfehlenswert. Die Artikelserie beginnt mit “Controlling Your Environment Makes You Happy“.
• Über Unicode und Co. hatte ich ja auch schonmal was geschrieben. Und Spolsky tut das auch: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) Sein Artikel ist inhaltlich etwas oberflächlicher als meiner. Es macht aber trotzdem Spaß ihn zu lesen. Wahrscheinlich mehr als meinen.
• Ich hab nicht vor, irgendwann mal ein “Manager” zu werden. Ich will lieber kreativ bleiben und Software entwickeln. Ob als “Programmierer”, “Architekt” oder “Mach-alles-Selber-Entwickler”, ob agil oder plangetrieben — das ist ne andere Frage. Ich hab auch so schöne Entwicklungsmöglichkeiten (Ich mag das Wort “Karriere” nicht. Ich entwickele nicht nur Software, ich entwickele mich; Das ist IMHO die schönere Sichtweise.) Was ich damit sagen will: Ich hab nicht vor, der Technik den Rücken zuzukehren und Manager-Kram interessiert mich nicht sonderlich. Spolsky schafft es aber trotzdem, über solche Themen so zu schreiben, dass auch ich sie interessant finde. Beispiel: The Development Abstraction Layer.
• Wie man ein Büro auch planen kann: Bionic Office
• Kann sich irgendjemand vorstellen, warum man sich ernsthaft(!) seinen eigenen C-Compiler schreiben sollte? Kann sich irgendjemand vorstellen, dass das Excel-Team bei Microsoft einen eigenen C-Compiler hatte? Kann sich irgendjemand vorstellen, warum das *keine* absolut bescheuerte Idee ist? Joel Spolsy kann es: In Defense of Not-Invented-Here Syndrome

Ich hab noch ein paar Texte, die ich empfehlen möchte. Aber dazu gibts wohl separate Blog-Posts von mir, weil Spolsky so viel darin sagt oder mich so zum Nachdenken anregt, dass ich da noch mehr drüber erzählen will.

Eine rühmliche Ausnahme, die wahrscheinlich schon jeder außer mir kennt, aber über die ich trotzdem mal was schreiben will, ist Star Wreck. Wie unschwer am Titel zu erkennen ist, handelt es sich um eine Star-Trek-Parodie. Genau genommen um mehrere.

Angefangen hat alles nämlich schon 1992 mit einem Fanfilm einer Fan-Animation, ohne wirkliche Handlung und ohne alles, was irgendwie erwähnenswert wäre. Die folgenden Filme hatten zumindest mal pixelige Animationen, die Personen zeigen. Die letzten haben dann aber wirklich menschliche Schauspieler, eine Handlung, Spezialeffekte etc. Insbesondere “Star Wreck: In the Pirkinning” ist wirklich aufwändig gemacht und hat wohl auch einiges an Geld gekostet. Die schauspielerische Leistung ist akzeptabel (was bei Fanfilmen ne große Ausnahme ist), Sound und Effekte wirklich gut und die Story ist auch OK.

Man darf natürlich nicht zu viel erwarten, aber insbesondere, wenn man die ersten “Filme” gesehen hat (sind ja meist recht kurz), sieht man wie enorm sich die Qualität verbessert hat. Ich könnte jetzt auch bei “In the Pirkinning” anfangen rumzunörgeln, könnte beklagen, dass der Plot vorhersehbar ist, etc. Aber dennoch: Mir hat der Film gefallen und ich finde ihn sehenswert.

Die Filme stehen unter einer Creative-Commons-Lizenz und können hier runtergeladen werden: http://lame.lut.fi/starwreck/
Die offizielle Seite ist diese hier: http://www.starwreck.com/

Die Filme sind auf Finnisch gedreht und haben englische Untertitel. Für “In the Pirkinning” gibts auch deutsche. Dabei ist mir aufgefallen, wie viel schöner es eigentlich ist, wenn man die Sprache versteht, die da gesprochen wird. Untertitel sind zwar schön und gut, aber man ist immer aufs Lesen fokussiert und kann nur mit nem halben Auge sehen, was passiert. Englisch würde ich ja noch verstehen, aber Finnisch kann ich leider nicht.

Wir können uns hier in Deutschland also noch glücklich schätzen, dass bei uns die Filme i.d.R. synchronisiert werden. In anderen Ländern ist das oft ja nicht der Fall. Da gibts nur Untertitel. Ich glaube, ich bin also froh, dass ich, wenn ich im Kino sitze, keine Untertitel lesen muss…

Nochmal kurz zurück zu Star Wreck: Die Macher haben mittlerweile einen weiteren Film gemacht. Iron Sky ist wohl schon recht bekannt, wurde auf der Berlinale gezeigt und läuft ab April im Kino. Ich glaube, den guck ich mir an.

• … warum unproduktives Arbeiten manchmal gut ist.
• … warum schlechter Code manchmal gut ist.
• … was Astronauten und Klebeband nicht gemeinsam haben.

Warum unproduktives Arbeiten manchmal gut ist

Code muss wartbar sein. Wenn ein Stück Code nicht wartbar ist, ist die Wahrscheinlichkeit hoch, dass mir das später Probleme bereiten wird. Fast alles, was man so schreibt, muss man später nochmal anfassen, es ändern, erweitern und vielleicht auch wiederverwenden. Und da mir noch niemand über den Weg gelaufen ist, der behaupten konnte, bug-freien Code zu schreiben (selbst Knuth soll ja Fehler gemacht haben), ist jedes Stück Code ein potentieller Kandidat für “Wartungsarbeiten”. Deshalb interessiere ich mich dafür, wie man Code wartbar machen kann. Wenn man wartbaren Code schreiben kann, kann man sich nervige Nacharbeiten ersparen — nicht alle, aber doch einige.

Mir macht es Spaß, Code anzugucken und mich zu fragen, ob man das hätte besser machen können. Entsprechende Diskussionen findet man zu Hauf im Forum. Gerade letztens wieder: eine Diskussion über 7 Tage und 27 Beiträge, die letztendlich nur zu kleinen Verbesserungen geführt hat. Man kann auch 48-Forenbeiträge darauf verwenden, einen Lottozahlen-Code zu diskutieren. Ich hab auch keine Probleme damit, eine Viertelstunde über eine Zeile Code zu grübeln und zu überlegen, wie man diese am lesbarsten gestaltet.

Das ist *extrem* unproduktiv. In einem realen Kontext, bei dem es wirklich darum geht, in vorgegebener Zeit eine Software zu schreiben, wäre so etwas absolut unwirtschaftlich. Code, den ich unter realen Bedingungen erstellte, ist also längst nicht so bis aufs Kleinste herausgeputzt, wie man das bei meiner Leidenschaft für Codeästhetik vermuten mag. Wenn es “ernst wird”, hab ich schlicht und einfach keine Zeit, ne Viertelstunde über eine Zeile Code nachzudenken, um dadurch ein halbes Jahr später bei irgendwelchen Wartungsarbeiten zwei Sekunden zu sparen. Denn mal ehrlich: So viel schlechter lesbar war die alternative Schreibweise der Zeile nun auch wieder nicht. Lesbarkeit ist zwar wichtig, übertriebener Fokus auf Lesbarkeit ist aber unwirtschaftlich.

Wenn ich aber die Chance dazu habe, bin ich auch gerne unwirtschaftlich. Das kann ich im Studium machen (wobei da auch nur begrenzt) oder im Forum. Und bei dem, was ich so für mich aus Spaß an der Freude schreibe. Dabei ist das nicht nur Spinnerei: Ich lerne daraus. Und ich merke immer wieder, dass ich immer noch mehr dazu lernen kann. Und das hilft dann auch in den realen Kontexten, bei denen man keine Zeit hat, ewig über eine einzige Zeile zu philosophieren.

Wer also lernen will, lesbaren und wartbaren Code zu schreiben, dem kann ich also nur raten, unproduktiv zu sein.

Warum schlechter Code manchmal gut ist

Wenn man also wirklich Software schreibt — im Beruf oder auch nur für die Uni — ist man manchmal gezwungen, schlechten Code zu schreiben. Wenn die Uhr tickt, programmiert es sich anders als, wenn man das nur aus Spaß an der Freude macht. Und manchmal wird man da ein gewisses ungutes Gefühl nicht los. Der Code scheint irgendwie “unvollkommen” zu sein. Ich denke, das Gefühl bewahrt einen davor, schlimme Fehler zu begehen, von daher ist es gut, das es da ist. Aber das ist nur die eine Seite…

Joel Spolsky beschreibt in Things You Should Never Do, Part I genau so eine Situation. Man sagt ja oft, dass man, wenn man etwas fertig gestellt hat, am besten nochmal alles wegwirft und neu anfängt, weil man dann weiß, wie es richtig geht und die ganzen blöden Fehler nicht mehr macht. Ich hab das bisweilen auch schon behauptet. Spolsky zeigt auf, dass gerade das ein blöder Fehler wäre. Dabei gibt er folgendes Beispiel:

[Y]ou can ask almost any programmer today about the code they are working on. “It’s a big hairy mess,” they will tell you. “I’d like nothing better than to throw it out and start over.”

Why is it a mess?

“Well,” they say, “look at this function. It is two pages long! None of this stuff belongs in there! I don’t know what half of these API calls are for.”

[...]

Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

Ich fand das wirklich… erhellend. Natürlich ist das nicht immer so. Manchmal ist Code wirklich… verbesserungswürdig. Aber im Grunde genommen hat Spolsky wohl recht. Echter Code in echter Software, die wirklich benutzt wird, ist manchmal doch etwas anders, als die schönen kleinen Lehrbeispiele aus der Uni. Solche “Bugfixes” gibt es überall. Und so hab ich das bisher noch gar nicht gesehen. Ich kann Spolskys Text (nicht nur diesen, sondern auch diverse andere von ihm) also nur wärmstens empfehlen. Es ist gut, manchmal die Dinge auch aus einem anderen Blickwinkel zu sehen.

Auf der anderen Seite wäre es natürlich gut, wenn die Bugfixes den Code nicht unnötig unleserlich machen würden. Mit ein paar Kommentaren im Code und am besten noch einem automatisierten Test pro gefixtem Bug, könnte man wohl die Lesbarkeit entsprechend verbessern und das Vertrauen der Entwickler in die Qualität des Codes erhöhen. Wenn man direkt sieht, warum die ganzen API-Calls nun notwendig sind, tut man sich mit späteren weiteren Bugfixes leichter, man macht weniger kaputt und hat ne bessere Meinung vom Code (und ist damit wohl auch motivierter bei der Arbeit).

Aber Spolsky will noch auf etwas anderes hinaus:

Manchmal wurde es tatsächlich gemacht: Alles weggeworfen und neu angefangen. Und oft ist das nicht gut gegangen. Der verlinkte Artikel nennt mehrere Beispiele. Man verliert viel, wenn man wirklich alles wegwirft. Und man braucht sehr viel Zeit, das alles wieder aufzuholen. Zeit, die in einem marktwirtschaftlichen Umfeld tödlich sein kann. Auch das hab ich bisher noch nicht so bedacht. Zumindest nicht so genau wie Spolsky.

Vielleicht gibt es manchmal wirklich keinen besseren Weg als alles neu zu machen, aber das besagte ungute Gefühl sollte uns eigentlich davor bewahren, dass es so weit kommt. Viel besser ist es, wenn man klein anfängt und langsam besser wird. “Klein” kann dabei heißen, nur 50% der angedachten Funktionalität zu haben und das auch noch bei inkonsistenten Interfaces und verbesserungswürdiger Architektur. Und durch Refactoring und stetige Verbesserung kommt man dann irgendwann da hin, wo man hin will.

Auf die Spitze getrieben nennt sich dieses Prinzip worse is better.

• Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
• Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct.
• Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
• Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

Irgendetwas in mir sträubt sich gegen diese Denkweise, aber man kann ihr einen gewissen Erfolg nicht absprechen. Ich finde gerade gut durchdachte Schnittstellen wichtig, weil sie helfen, Fehler zu vermeiden. Gerade was Reihenfolge von Parametern, Bezeichner und generelle Funktionsweise betrifft. Wenn ich mir aber ansehe, wie viele schlechte oder zumindest verbesserungswürdige APIs es gibt, scheinen die doch einigen Erfolg zu haben. Ich bin aber trotzdem noch nicht davon überzeugt, dass “worse is better” als generelles Prinzip eine gute Idee ist. Aber zumindest erinnert es mich daran, dass schlechter manchmal doch besser sein kann.

Was Astronauten und Klebeband nicht gemeinsam haben

Das bringt mich zu zwei weiteren Artikeln, die ich bei joelonsoftware gelesen habe:

• Don’t Let Architecture Astronauts Scare You
• The Duct Tape Programmer

Ich mag Architektur, Patterns, Objektorientierung und was man damit alles schönes tun kann. Leider habe ich deshalb auch manchmal die Tendenz zum Overengineering. Manchmal mache ich etwas unnötig kompliziert, weil es aus theoretischen Überlegungen heraus besser ist. Manchmal sind diese theoretischen Überlegungen in der Praxis aber weniger relevant. Spolsky nennt Leute, die solche Probleme haben “Architecture Astronauts”.

Ich weiß, dass ich das Problem hab und ich arbeite daran. Es hat sich auch schon deutlich gebessert, aber ganz zufrieden bin ich trotzdem noch nicht. Einfachheit ist wichtig. Wenn der Code einfach ist, lässt er sich auch leicht lesen und leicht ändern. Einfacher Code ist weniger anfällig für Bugs. Kraft meiner Arroganz hab ich mich sogar schon erdreistet, darüber Vorträge zu halten. Etwas verstanden zu haben (und demnach Vorträge drüber halten zu können) und etwas wirklich verinnerlicht zu haben sind aber zwei verschiedene Dinge. Ich kann also noch einiges dazu lernen und deshalb sollte ich mir den Satz von Tony Hoare, den ich so gerne zitiere, auch des öfteren mal vor Augen halten:

Tony Hoare
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature.

Die zweite Gruppe von Entwicklern, die Spolsky benennt (im Gegensatz zu ersteren aber lobt), sind die “Duct Tape Programmers”. Das sind die, die sich nicht um Objektorientierung, Vererbung, Architektur, Unittests und ähnliches stören, sondern lieber mit einfachen Mitteln (eben mit “Klebeband” wie Integers und Pointer) erstaunliche Dinge leisten können. Das Resultat mag nicht schön sein, aber es funktioniert und nach ein paar Iterationen wird der Code auch besser.

In einer Weise sind die “Duct Tape Programmers” also das genaue Gegenteil der “Architecture Astronauts”. Sie machen lieber alles zu Fuß und kümmern sich nicht um Frameworks, Architektur und Sauberkeit, sind dafür aber schnell und effektiv. Man könnte fast meinen, sie hätten im Sinne von Tony Hoare die Einfachheit zu ihrem Grundsatz erhoben, aber das stimmt auch nicht so ganz. Sie sind eher Anhänger von “worse is better”. Aber auch das stimmt nicht ganz. Spolsky schreibt dazu:

Joel Spolsky
They have to be good enough programmers to ship code, and we’ll forgive them if they never write a unit test, or if they xor the “next” and “prev” pointers of their linked list into a single DWORD to save 32 bits, because they’re pretty enough, and smart enough, to pull it off.

In meinen Augen haben “Duct Tape Programmers” das Problem, dass sie die Komplexität von der Architektur in den Code verlagern, anstatt sie zu reduzieren. Und ich weiß nicht, ob ich das generell für eine gute Idee halten soll. Ich will also eher nicht lernen, mit Klebeband zu programmieren. Viel eher will ich lernen, einfachen, geradezu langweiligen Code zu schreiben. Langweiliger Code ist leicht zu verstehen und man kann sich dann besser auf die Stellen konzentrieren, die nicht langweilig sein können, weil sie echte Komplexität enthalten, die sich nicht einfach reduzieren lässt. Lieber den Code klar und sauber schreiben und dafür die ganzen tollen Features [1], mit denen man eigentlich so schön hätte angeben können, nur dann nutzen, wenn sie wirklich nötig sind. Das ist nicht leicht, aber das ist es, was ich lernen will.

[1] mögen es nun Architektur-Tricks, Patterns oder Pointerspielereien sein

• Wer ein paar kryptographische Grundlagen leicht verständlich und ohne viel Mathe erklärt kriegen möchte, kann sich mal bei Isotopp vorbeigucken. Wer die einschlägigen Vorlesungen gehört hat, wird da zwar nicht viel Neues erfahren, für den Rest sollte es aber sehr lesenswert sein.
• Alle Welt beklagt sich über Bananensoftware — und nicht ganz zu unrecht. Meist geht es dabei um ungewollt schlechte Qualität. Man kann sowas aber auch absichtlich machen: Testing in Production. Ich denke aber, man sollte mit sowas sehr vorsichtig umgehen.
• Ein interessantes Testkonzept für verteilte Systeme: Chaos Monkey — ein Prozess, der willkürlich irgendwelche Systemkomponenten killt.
• Drei Buchstaben, die (aus firmenpolitischen Gründen) in der Delphi-Welt unbeliebt sind, (aus welchen Gründen auch immer) in der Uni kaum vorkommen, aber dennoch praxisrelevant sind: ALM. Heise Developer hat interessante Artikel dazu. So kriegt man zumindest mal nen groben Überblick:
  • ALM-Prognosen #1: Open-Source-Tools gewinnen weiterhin Marktanteile
  • ALM-Prognosen #2: ALM aus einer Hand stirbt aus
• Darüber wollte ich eigentlich nen ganzen Blogpost verfassen. Da ich aber momentan mit Prüfungsvorbereitungen beschäftigt bin, komme ich nicht so schnell dazu, wie ich das gerne wollte. Deshalb hier erstmal nur der Link: TIMTOWTDI
• Und weil wir grad dabei sind: Noch ein Artikel von Heise Developer: Studie: Nachholbedarf bei Software-Qualitätssicherung. Titel und Artikel sagen zwar kaum was anderes, als das, was man eh schon weiß, aber insbesondere die Diskussionen in den Kommentaren sind lesenswert, um einen Eindruck von der Situation und den unterschiedlichen Meinungen Thema zu kriegen.
• Warum User keine Dialoge lesen. Und schon gar keine Handbücher. Sehr lesenswerter Artikel über Usability.

Anderes

• Irgendwie denk ich da nie dran, was unter “Anderes” zu bloggen. Die Fachthemen kommen meist aus meinem RSS-Reader oder offenen Tabs im Browser. Das lässt sich leicht rekonstruieren. Mal sehen, ob ich es schaffe, hier öfter auch mal über anderes zu reden…

Höhere Mathematik für programmierende Nicht-Akademiker — Heute: Restklassenringe

Grundlagen: Algebraische Strukturen

In der Mathematik basiert alles auf Mengen (Mengenlehre, Schnittmenge, Teilmenge, Vereinigungsmenge und so). Mit den Elementen einer Menge kann man rechnen, d.h. es gibt verschiedene Operationen, die auf der Menge definiert sind.

Aus der Schule kennen wir die Menge der Reellen Zahlen: . Aus der Menge der Reellen Zahlen machen wir eine algebraische Struktur, indem wir ihr Operationen spendieren:

Wendet man eine der Operationen auf ein Element der Menge an, erhält man als Ergebnis wieder ein Element der Menge. und (5 und 6 sind wieder reelle Zahlen). Das nennt man Abgeschlossenheit.

Es gibt verschiedene Arten von algebraischen Strukturen für die jeweils andere Anforderungen gelten. So gibt es beispielsweise Gruppen, Ringe und Körper. Die Unterschiede sind hier erstmal nicht weiter wichtig.

Beispiel

Man kann nicht nur mit den Reellen Zahlen rechnen, sondern beispielsweise auch mit Natürlichen Zahlen (). Das haben wir in der Grundschule gelernt. Wir haben da erfahren, dass “nicht geht”. Später haben wir negative Zahlen kennen gelernt und auf einmal ging das doch. Trotzdem haben uns unsere Lehrer in der Grundschule nicht angelogen. geht wirklich nicht — in der Halbgruppe .

In der Programmierung begegnen uns ständig solche algebraischen Strukturen. ist z.B. auch eine Halbgruppe. Wir können Strings konkatenieren und erhalten wieder Strings (String ist abgeschlossen bezüglich der Operation ) und ist assoziativ: ('a' + 'b') + 'c' = 'a' + ('b' + 'c'). Diese zwei Eigenschaften brauchen wir um Halbgruppe nennen zu können. Außerdem haben wir noch den Leerstring als neutrales Element. 'a' + '' = 'a'. Wir dürfen deshalb sogar einen “Monoid” nennen.

Inverse Elemente

Die Operationen und haben wir oben nicht etwa vergessen. Sie ergeben sich quasi automatisch aus und . ist nämlich nichts anderes als , wobei das inverse Element (bezüglich der Addition) von ist. Das inverse Element bezüglich der Multiplikation wäre , d.h. . Ein Element verknüpft mit seinem inversen ergibt immer das neurale Element (bezüglich der Operation). (additiv inverses) (multiplikativ inverses).

Restklassenringe

Ein Restklassenring ist eine algebraische Struktur, bei der die Menge Restklassen sind. Eine Restklasse ist z.B. . hat genau Elemente, nämlich die Zahlen 0 bis 23. Definiert man noch Addition und Multiplikation, erhält man einen Restklassenring: .

In einem Restklassenring rechnet es sich in etwa so, wie mit Uhrzeiten. Nach 23 Uhr kommt wieder 0 Uhr:

20 (Uhr) + 7 (Stunden) = 27 (Uhr) = 3 (Uhr)

oder mathematisch geschrieben:

Die Modulooperation gibt also an, in welchem Restklassenring du dich befindest. Hier in . Alle “Zahlen” die den selben Rest beim Teilen durch 24 aufweisen sind in der selben Restklasse und damit “gleich”. Also:

Um entsprechend einfacher rechnen zu können, benutzt du die Modulo-Operation und erhältst immer eine Zahl zwischen 0 und 23:

Genau so ist es mit den negativen Zahlen:

0 (Uhr) – 1 (Stunde) = -1 (Uhr) = 23 Uhr

oder mathematisch:

Achtung

Die Modulo-Operation ist nicht in jeder Programmiersprache gleich definiert. Manchmal entspricht sie der oben verwendeten mathematischen Definition, manchmal ist es anders. Will man in Restklassenringen rechnen, muss man das für negative Zahlen bedenken und ggf. Korrekturen vornehmen. http://en.wikipedia.org/wiki/Modulo_operation#Common_pitfalls

Ausblick

Alle Restklassenringe mit einer Primzahl , sind nicht nur Ringe, sondern Körper, d.h. jedes Element hat ein multiplikatives inverses Element. Das ist in der Kryptographie wichtig und wird u.a. bei RSA verwendet.

Hier erstmal zwei Links, die vielleicht ganz interessant sind:

• http://www.tecchannel.de/pc_mobile/notebook/432097/akkus_notebook_lebensdauer_kapazitaet_ladezyklen_lithium_ionen_laufzeit/
• http://de.wikipedia.org/wiki/Lithium-Ionen-Akkumulator#Hinweise_zum_Umgang_mit_Li-Ionen-Akkus

Folgendes meine ich, herausgefunden zu haben:

• Die Ladeelektronik moderner Akkus verhindert das Überladen. Das ist auch sehr wichtig.
• Ebenso verhindert die (Ent-)Ladeelektronik das Tiefentladen. Das heißt, dass der Verbraucher sich lieber vorher abschaltet bzw. die Akkuelektronik die Leistungsabnahme verweigert, bevor der Akku wegen Tiefentladung kaputt geht. Man kann da also fast nichts falsch machen.
• Dieses “fast” bezieht sich auf die Lagerung. Ein Lithium-Akku hat eine Selbstentladungsrate von etwa 1-2% pro Monat. Ein fast leerer Akku kann sich also trotz der intelligentesten Elektronik bei langer Lagerung langsam weiter entladen (d.h. Tiefentladen werden) und damit Schaden nehmen.
• Längere Zeit mit voller Spannung tut dem Akku wohl auch nicht gut (aufgrund irgendwelcher chemischer Degenerierungs-Prozesse, die durch die hohe Spannung begünstigt werden oder so).
• Ähnliche oder andere lebensdauerverringernde Prozesse gibt es wohl auch irgendwie bei niedrigem Akkustand.
• Man lagert einen Lithium-Akku also am besten in etwa halb-vollem Zustand. Ob “halb-voll” 40%, 50%, 60% oder 75% heißt, ist wohl strittig. Ich hab auch schon die Empfehlung gelesen, den Akku leer zu lagern. Diese Empfehlung kann ich aber nicht logisch nachvollziehen.
• Ein weiterer limitierender Faktor ist die Zahl der Ladezyklen. Akkus verkraften nur eine endliche Zahl an Ladezyklen und gehen danach langsam kaputt. Das sind bei Lithium-Akkus so irgendwas zwischen 300 und 800 Zyklen.
• Daraus ergibt sich, dass man je nach Nutzung an nem Akku hoffentlich mindestens ein Jahr Spaß haben sollte und Lebensdauern von mehr als eins-zwei Jahrzehnten utopisch sind.
• Darüber, inwieweit sich halbe Ladezyklen anteilig anrechnen lassen, herrscht wohl irgendwie Uneinigkeit. Auch ist mir nicht ganz klar, ab welchem Ladezustand die unvorteilhaften Prozesse nun wirklich eine Rolle spielen. Ob man jetzt also besser regelmäßig von 50% auf 100%, von 10% auf 100%, von 50% auf 90% oder anders laden soll, ist mir immer noch unklar.
• Mini-Ladezyklen, wie sie z.B. auftreten können, wenn man ein Notebook ständig am Netz betreibt ohne den Akku zu entfernen, sind wohl eher weniger gut.
• Ein weiterer wichtiger Punkt ist die Temperatur. Die ideale Betriebstemperatur liegt wohl zwischen 20 und 40°C. Das ist für Handys ziemlich problemlos, bei Notebooks aber nur selten erreichbar. Auch das ist wohl der Gesundheit der Akkus abträglich. Und natürlich sollte man Akkus (Handys…) nicht nachts im kalten Auto lassen (oder im Sommer im heißen Auto).
• Über Lagertemperatur liest man unterschiedliches. Von Kühlschrank bis Zimmertemperatur.
• Lithium-Akku ist nicht gleich Lithium-Akku. Es können unterschiedliche Materialien verwendet werden und diese können auch noch in unterschiedlicher Qualität verarbeitet sein und von unterschiedlicher Reinheit sind. Und das hat wohl einen bedeutenden Effekt auf die Lebensdauer. Und man sieht das den Akkus nicht an.
• Lithium-Polymer-Akkus haben eine höhere Energiedichte (sind also bei gleicher Kapazität kompakter und eignen sich deshalb besonders für Mobilgeräte. Allerdings verkraften sie etwas weniger Ladezyklen als “normale” Lithium-Ion-Akkus.
• Zudem ist die Leistungsabnahme des Gerätes bzw. die Dimensionierung des verwendeten Akkus entscheidend für die Akkulebensdauer. Unterdimensionierte Akkus altern auch schneller.
• Alles in Allem ist eine gewisse Alterung also gar nicht zu vermeiden. Da Akkus vor dem Kauf u.U. ja auch noch ne Zeit lang gelagert werden und der Alterungsprozess da natürlich auch schon läuft, muss man hoffen, dass man keine allzu alten Akkus kauft. Das Herstellungsdatum steht da nur sehr selten drauf.
• Aufgrund der generellen Alterung macht es also wohl auch wenig Sinn, gleich ein Ersatzakku mit dem Gerät mitzukaufen. Außer vielleicht man benutzt beide Akkus alternierend.

Mein Fazit:

• Ich werde Akkus in halb-vollem Zustand bei Zimmertemperatur lagern und alle zwei, drei Monate den Akku ggf. wieder auf halb-voll bringen.
• Als Kompromisslösung versuche ich Akkus von 25 auf 100% zu laden.
• Bei längerem Netzbetrieb werde ich den Akku entfernen und wie oben beschrieben “lagern”.
• Ich gehe mal davon aus, dass unter realen Bedingungen ein häufig genutzter Akku auch bei guter Pflege nicht viel länger als 3-4 Jahre hält.

So richtig sicher bin ich mir aber irgendwie immer noch nicht, ob das das Richtige ist. Ich könnte natürlich beim jeweiligen Hersteller nachfragen. Ob ich da aber jemanden kriege, der a) Ahnung hat (und nicht nur einen 08-15-geschulten Support-Mitarbeiter) und mir b) auch die ungeschönte Wahrheit erzählen will, ist fraglich. Bis auf weiteres werde ich also wohl meinem gepflegten Halbwissen vertrauen müssen…

“Wie ich sehe, sind Sie mit den Mordfällen Pavlos und Singh befasst. Um Ihnen unnötigen Aufwand zu ersparen, sage ich Ihnen: Ich habe beide getötet. Warum, werden Sie bald erfahren. Allerdings haben Sie ein Problem. Sie können mich nicht verhaften. Sie können mich nicht aufhalten. Denn ich bin tot.”

Vor einiger Zeit habe ich Neuromancer von William Gibson gelesen. Ein bekanntes, viel gelobtes Buch. Und um ehrlich zu sein, war ich enttäuscht. Mal davon abgesehen, dass es manchmal unnötig schwer zu verstehen ist und wirr erscheint (insbesondere am Anfang; wird später besser; so richtig in Fahrt kommt die Geschichte aber nie), ist dort alles, was Technik betrifft… merkwürdig bzw. unrealistisch. Gut, das Buch stammt aus den 80er Jahren, aber dennoch: Mir hat das Buch nicht sonderlich gefallen udn so hab ich die beiden Folgebände gar nicht erst gelesen.

Ganz anders ist es mit dem, was ich jetzt gelsen habe: Daemon und Darknet von Daniel Suarez. Suarez ist Softwareentwickler und das merkt man. Technisch gesehen hat das, was er schreibt, im Großen und Ganzen Hand und Fuß. Und für einen Informatik-Studenten ist es ausgesprochen angenehm, wenn man einen Roman liest, in dem Begriffe wie “IP-Adresse”, “Formatstring-Hack” und “Quellcode” in einem technisch nachvollziehbaren Zusammenhang stehen. Man kann die Bücher auch lesen ohne diese Begriffe zu verstenen. Wenn man sie aber kennt und sieht, dass sie richtig verwendet werden, ist der Roman nochmal so gut. Auch die deutsche Übersetzung macht das nicht kaputt (im Gegensatz zu Fachliteratur lese ich Romane lieber in der deutschen Übersetzung). Es gibt zwar ein paar Stellen, bei denen ich vermute, dass die Übersetzung etwas Merkwürdiges gemacht hat. Das ist eindeutig im Rahmen und tut dem Lesegenuss keinen Abbruch.

Nun, worum gehts? Matthew Sobol ist Chef einer großen Computerspielefirma. Und er ist totsterbenskrank. Er leidet an einer Krankheit, an der er langsam aber sicher stirbt. Kurz nachdem aber die Meldung über seinen Tod durch die Medien geht, geschehen merkwürdige Dinge. Der Daemon, eine verteilte KI, die Sobol auf Basis seiner Computerspiele entwickelt hat, erwacht zum Leben und verfolgt düstere Pläne. Der Daemon wirbt Leute an, begeht Morde und infiltriert Firmennetze. Der Daemon übernimmt die Welt. Und gewisse Leute versuchen das zu verhindern.

Das hört sich ziemlich nach schwarz/weiß-Malerei mit vorhersehbarem Plot an, aber genau das ist es nicht. überhaupt nicht. Diverse Plot Points erzeugen nicht nur Spannung, sondern weichen auch die zu Anfang scheinbar noch herrschende schwarz/weiß- bzw. gut/böse-Trennung auf.

Wie von einem Thriller kaum anders zu erwarten, gehen massenweise Autos kaputt und an Toten mangelt es auch nicht. Und wie von Science-Fiction zu erwarten gibt es immer mal wieder (oder andauernd) Technik die so (noch) nicht existiert. Aber Daemon ist mehr als nur ein Thriller mit starkem Technikanteil. Manche Teile lesen sich wie ein Computerspiel, andere sind in hohem Maße gesellschaftskritisch. Es ist ein intelligenter Roman, der nachdenklich stimmt. Gerade auch, weil er sehr real wirkt. Viel tennt uns nicht von der Welt des Romans — sowohl gesellschaftlich als auch technologisch.

Ich könnte jetzt noch in den Krümeln suchen. Ich könnte erklären, was technisch so nicht funktioniert (z.B. das Portieren einer Computerspiel-Auto-KI auf ein richtiges Auto) und warum die Features des Daemon übertrieben gut sind und kaum Bugs zu haben scheint. Oder ich könnte mich fragen, warum sich ein hochgradig verteiltes System zumindest an einer Stelle (kurz vor Schluss) wie ein zentralisiertes zu verhalten scheint. Ich könnte auch aufzählen, welche Kleinigkeiten man meiner Meinung nach an der Geschichte verbessern könnte. Das würde dem Roman aber nicht gerecht. Im Vergleich zu dem, was andere Romanschreiber fabrizieren, ist das lächerlicher Kleinkram. “Daemon” ist ein guter Roman. Die Geschichte erschafft im wahrsten Sinne des Wortes eine eigene Welt; sie ist spannend, gut erzählt und regt sogar zum Nachdenken an.

Kurz: Ein intelligenter Roman, der mir viel Spaß gemacht hat.