Die Lügen des Locke Lamora

Der geheime Frieden ist in Gefahr. Denn Locke Lamora, Gentleman-Ganove und Priester des namenlosen dreizehnten Gottes, hält sich nicht daran. Mit seiner Bande bestiehlt er die reichen Adligen, obwohl der geheime Frieden diesen eigentlich zusichert, niemals bestohlen zu werden. Locke ist ungestüm, verwegen und ein Meister seines Fachs. Nichts kann ihn aufhalten, so scheint es — bis der Graue König auftritt und ihn eines anderen belehrt.

Die Stadt, in der sich das alles zuträgt, ist Camorr, deren Name nicht von ungefähr an die Camorra erinnert. Neben dem greisen Herzog Nicovante herrscht dort Vencarlo Barsavi, der Capa von Camorr, Herr über die “Richtigen Leute”, die Mafia der Lagunenstadt.

Die Lügen des Locke Lamora ist ein Buch, das durchaus Spaß macht, zu lesen. Camorr versprüht den Charme eines mafiösen Renaissance-Venedig und die Geschichte um Locke und seine Bande ist interessant erzählt. Aber ganz ohne Vorbehalte kann ich das Buch dennoch nicht empfehlen. Schwebt im ersten Teil des Buches nur ein Hauch von Magie in der Luft, so tritt irgendwann ein übermächtiger Soldmagier auf. Nun hat Magie in Fantasy-Geschichten oft das Problem, dass sie zu mächtig ist und damit den Plot unrealistisch macht. Steht der Magier auf Seiten der Protagonisten, haben diese es entweder zu leicht und der Plot wird langweilig oder der Zauberer muss sich nicht nachvollziehbarer Weise oft mit seiner Macht zurück halten, was ihn unrealistisch werden lässt. Steht der Magier aber auf Seiten der Gegenspieler, werden deren Pläne entweder ziemlich simpel oder unrealistisch, weil es keinen Grund für komplizierte Herangehensweisen gibt. Deshalb muss Magie irgendwie eingeschränkt werden, damit eine Geschichte funktioniert. Unkontrollierte Magie macht also entweder den Plot langweilig oder unglaubwürdig. Hier ist leider das letztere der Fall. Die Soldmagier wirken unglaubwürdig, weil sie viel zu mächtig sind. Warum sollten Zauberer, die sich unverwundbar machen, Gedanken manipulieren und durch Wände gehen können, ihre Dienste für Geld anbieten? Und warum nutzt man nicht die Dienste eines solchen Magiers voll aus, wenn man es könnte, und verfolgt stattdessen einen komplizierten und fehleranfälligen Plan?

Auch Locke, die Hauptfigur, ist nicht immer so, wie er sein könnte. Er wird eingeführt als übereifriger kleiner Bengel, der es liebt zu stehlen und langsam lernt, wie wichtig Planung und Voraussicht ist. Diese Voraussicht scheint er mit der Zeit aber wieder zu verlieren. Insbesondere gegen Ende des Buches handelt er wieder alles andere als vorausschauend. Gründe für diese Rückwärtsentwicklung werden nicht genannt und ich bin mir auch nicht sicher, ob sie gewollt oder einfach nur dem Plot geschuldet ist. Schade, denn eigentlich sind Locke und seine Bande wirklich interessante Charaktere.

Trotz dieser Mankos hat Scott Lynch dennoch ein ganz gutes Buch geschrieben, das sich unterhaltsam liest. Rückblenden in Lockes Kindheit unterbrechen regelmäßig die Handlung, beleuchten die Hintergründe und bauen einen zweiten Handlungsstrang auf. Das ist ganz gut gemacht, wenngleich ich an der ein oder anderen Stelle das Gefühl hatte, dass es besser ginge. Camorr ist als Handlungsort gut durchdacht und interessant. Die Komplexität der Handlung wirkt zwar manchmal etwas gekünstelt und ist den Protagonisten irgendwie nicht völlig bewusst, aber zur Unterhaltung taugt sie allemal.

Insgesamt ist “Die Lügen des Locke Lamora” also nicht überragend, aber dennoch ganz gut. Die Folgebände werde ich mir wohl dennoch nicht kaufen und lieber etwas anderes lesen.

Gefangen, nicht gefunden! #25

Informatik

• Ich hatte mich ja schonmal zu Robustheitsdiagrammen geäußert. Ich hab die bisher immer noch nicht ausprobiert, aber mir ist gerade klar geworden, warum ich skeptisch bin. Falsch angewendet scheinen sie zu einem Anemic Domain Model zu verleiten. Insbesondere dürfen Entity-Objekte ja eigentlich nicht miteinander kommunizieren. In einem richtigen Domänenmodell müsste dies aber sein.
• The Clean Code Talks – Don’t Look For Things!: Interessante Einführung in Dependency Injection. Nur bei einer Sache bin ich anderer Meinung: Das Prüfen auf Null-Werte. Ich mache das häufig und setze zumindest ne Assertion rein. An Schichtengrenzen auch Exceptions. Ich möchte nicht, dass Fehler zu weit propagiert werden, bevor sie sich manifestieren. Das erschwert das Debugging unnötigerweise. Und trotz Unit-Tests sagt Murphy’s Law, dass irgendwann solche Fehler auftreten werden. Auch kann ich die genannten Vorteile nicht ganz nachvollziehen. Ja, man kann in Tests durch Übergabe von null klar machen, dass der Parameter für den Test nicht gebraucht wird. Aber will ich das? Eigentlich interessiert mich das im Test gar nicht. Das ist Implementierungsdetail, um das sich der Test eigentlich nicht kümmert. Zudem könnten dann Tests auf einmal schiefgehen, nur, weil intern nun irgendwann doch auf nen Parameter zugegriffen wird. Es spart auch keine Arbeit, weil ich für irgend einen Test immer einen Dummy schreiben muss. Darum kommt man nicht drum herum. Und durch Nutzung von Fixtures, muss man auch die Initialisierung der Dummies nicht replizieren. Ich werde also weiterhin auf null prüfen. [1]

Anderes — Heute: Filme

• Habe mir letztens den Hobbit im Kino angesehen. Kurzmeinung dazu: Nicht ganz so gut wie Herr der Ringe, aber durchaus sehenswert. Am Anfang kommt die Handlung nicht so recht in die Gänge. Es wird versucht das mit humoristischen Szenen etwas auszugleichen, was aber nur teilweise gelingt. Später wird es dann deutlich besser. Vielleicht hätte man den Radagast-Seitenplot etwas stärker ausführen sollen. Das hätte der ansonsten recht linearen Handlung etwas mehr Tiefe gegeben und böte mehr Möglichkeiten, mit Spannung zu spielen. Trotzdem ist es toll, mal wieder Mittelerde zu sehen. Ich denke der wahre Held in Tolkiens bzw. Jacksons Geschichten ist diese sagenhafte, mittlerweile schon prototypische Fantasywelt. Somit ist der Hobbit ist der Hobbit, trotz gewisser Schwächen, wohl ein Muss für jeden HdR-Fan.
• Den Hobbit habe ich in 3D gesehen. Hatte aber (mal wieder) nicht den Eindruck, dass das ein großer Gewinn gegenüber 2D gewesen wäre. Es gibt zu wenige Szenen, in denen das gut funktioniert. Eine davon ist in der Höhle, der die Zwergen-Bande übernachtet.
• Eine Neuerung im Hobbit soll ja HFR sein. Aufgrund der Kritik an dem Verfahren bzw. der momentanen Probleme damit, hab ich mir das zusätzliche Geld, das das gekostet hätte, gespart. Ich hatte letzte Woche noch ganz interessante Links dazu. Finde das momentan aber nicht mehr. Kurz gesagt war mein Resümee: HFR wrd sich mit der Zeit langsam durchsetzen. Aber man muss sich erstmal dran gewöhnen. Außerdem müssen wohl Filmemacher bei Maske und Set noch stärker darauf achten, dass man jetzt mehr sieht. Angeblich wirkt der Hobbit deshalb in HFR momentan eher wie eine Fernsehdokumentation oder ein Computerspiel. Selbst kann ich das aber nicht beurteilen.
• Bei der ganzen Tolkien-Film-Sache hab ich entdeckt, dass es auch zwei recht gute Fan-Filme gibt: The Hunt for Gollum und Born of Hope. Für No/Low-Budget-Filme sind die ziemlich gut geraten. Insbesondere was Kostüme/Maske angeht. Auch Musik und Kameraarbeit ist für so etwas schon ziemlich gut. The Hunt for Gollum hat ne ziemlich einfache Handlung, aber Gandalf ist richtig gut gelungen. Born of Hope ist in mancher Hinsicht noch etwas besser und aufwendiger gemacht, krankt aber leider an einem ziemlich schlechten Drehbuch. Fanfilme halt. Im Gegensatz zu anderen dieser Art aber nicht nur für die Filmemacher selbst interessant.

[1] Eigentlich hätte ich das gerne zu nem eigenen Blog-Post gemacht. Dann wäre das auch verständlich, ohne, dass man sich das Video anguckt. Leider fehlt mir hierfür momentan die Zeit. Aber das Video ist eh sehenswert.

Exception Handling in Multi-Layered Systems

This is the first blog post here which is completely in English. And of course there is a reason for that. I currently don’t plan to do this regularly (maybe I should? I don’t know.). Anyway, here is the reason: Next week I’ll give a talk for the Australian Delphi User Group in Sydney. The talk will be a webcast, which means, I’ll stay here in Germany while the audience will be sitting on the other side of the globe. ADUG members who cannot be in Sydney can also attend using the web streaming system.

What am I talking about? If you are reading my blog, you should recognise the topic:

Title: Exception Handling in Multi-Layered Systems
Abstract (or maybe I should rather say “teaser” or something):
How do you structure software properly? Why should we think about the structure of a software? And how? How to handle exceptional cases? Is the Exception language feature always the best way? This talk has roughly two parts. In the first part we will have a look at architecture, layers and tiers. The second part deals with exceptions and how to use them properly. In the end we will see what the one has to do with the other.

Errata:

• There is a typo on slide 17: it should read “defines” instead of “defined”.
• Slide 22 is not translated (sorry for that). The note there means “Weak layering: Layer 3 may directly access Layer 1.”

This is basically the same talk I gave at the Delphi-Tage this year in Heidelberg. After my presentation in Heidelberg, Mathias Burbach, the president of the ADUG, approached me and asked if I could also give this talk in English. And so I do. The contents will be basically the same, although there are some minor changes.

Again there are slides and more elaborate talk notes:

Download: Exception Handling in Multi-Layered Systems (Slides) (Größe: 3.08 MB; bisher 97 mal heruntergeladen)
Download: Exception Handling in Multi-Layered Systems (talk notes) (Größe: 3.08 MB; bisher 171 mal heruntergeladen)

I haven’t had the time to translate everything, so the German talk notes are still more detailed (roughly eight pages more).

While translating, I also realised that by now I’m already more used to American English than the British one. In school I mainly learned the British version but in university I almost exclusively hear, talk, read and write AE. Wikipedia says Australian English is pretty much like BE, so I’ll try to get used to that variant again. Let’s see how good that works.

As always I’m highly interested in feedback of any kind. Tell me what you like but especially also what you didn’t like. I can only get better when I know where to improve. Don’t hesitate to mention even spelling mistakes or the like. I’m happy to hear about everything I can do better.

Update (24th November): Maybe I should share my impressions of the talk. I like giving talks and giving this one in English via a web stream was a quite interesting experience. The English talks I gave until now where about half an hour, so this one lasting 55 minutes (+discussion) was quite a bit longer. Nevertheless it proved to be not much of a difference. As far as I remember I haven’t been looking for words, etc. So I’m quite satisfied with the language although German is still a bit more comfortable for me.

Due to some technical problems, I had to interrupt my talk to wait for a part of the audience rejoining. This made me hurry up a bit to keep the time frame. I tried to do this in those parts of the talk the audience most likely was already familiar with. But I’m afraid I was a bit fast anyway.

Web streaming the talk in my eyes had two effects: a positive one and a negative one. The negative one is that I could not see the audience and thus could not react to whether they looked bored or confused or rejecting or whatever. Normally a good presenter should keep an eye on how the audience reacts. Here I didn’t have the opportunity to do so. The second effect I believe to have encountered was that not seeing the audience made me avoid saying “erm“. Normally I use this “erm” a lot (and I try to stop that). During the talk I found myself rather making an actual pause or speaking slower instead. This is good. My guess is that not seeing the audience makes me less feel the need to make this sound as it normally just works as a signal which says “Don’t interrupt me, I haven’t finished talking yet.” But maybe I also just have a wrong impression. I didn’t concentrate on this aspect as language was more important.

At the end there was the opportunity for discussion but there was only one question. Unfortunately in my eyes I didn’t answer this question well. It was actually pretty bad. So after the break I tried to give a better answer.

Like so often, feedback is scarce. It’s a pity. I’d love to hear some comments on my presentation style, my English, the topic, etc. Even negative comments. The above is just my impression and maybe it’s wrong. Most likely there are also aspects I don’t realise, so feedback is always good if you want to improve.

Gefangen, nicht gefunden! #24

Informatik

• Letztens hab ich einen lustigen Kommentar in meinen Code gesetzt:
  /* This is a time travel correction routine.
Beware that grammar of time travel is complicated! */
  Und ich habs tatsächlich geschafft, das noch halbwegs ernst zu meinen…

Anderes

• Das Wahlsystem ist verrückt. Nicht unsers. Äh… doch. Unseres auch. Aber über Überhangmandate und das Feilschen um ein verfassungsgemäßes Wahlrecht wollte ich gar nicht schreiben. Das ist traurig genug. Ich meine das US-Wahlrecht. Wie bei jedem Algorithmus sind auch hier die Grenzfälle interessant. Und bei denen hat man sich teilweise ganz lustige Strategien überlegt, die, sofern angewendet, noch lustigere Konsequenzen haben können. Hier gibts Informationen dazu. Lesenswert. Noch besser ist übrigens das eingebettete Video. Wer mal wirklich lachen will, sollte sich das unbedingt angucken. (via — ebenfalls lesenswert: what-if dazu)
• Interessante Software: Language Tool
• Ich war mal wieder auf einer Firmenkontaktmesse bzw. konkreter: Dem Informatik-Praxistag des FIT. Kurzfazit: Schön, dass man Firmenpräsentationen mit Fachvorträgen verbunden hat. Die Vorträge waren mitunter sehr interessant, nur leider etwas kurz. Die Resonanz unter den Studenten war geringer, als ich erwartet hätte. Es war eigentlich sehr lohnenswert, aber die Firmenvertreter haben sich wahrscheinlich zum Teil gelangweilt. Andererseits hatte man problemlos die Möglichkeit, jemanden ne halbe Stunde lang auszufragen. Warteschlangen gabs nicht.

Gefangen, nicht gefunden! #23

Leider bin ich in letzter Zeit kaum zum Posten hier gekommen. Deshalb hier zumindest ein bisschen was in verkürzter Form.

Informatik

• Ein Post über Security liegt hier halbfertig rum. Mal sehen, wann ich endlich dazu komme, ihn hier zu posten.
• Interessanter Gedanke: SoftwareDevelopmentAttitude. Hab den Artikel schon vor einiger Zeit gelesen und der Link ist hier entweder schon aufgetaucht oder er folgt noch in meiner leider nur langsam fortgeführten Artikelserie zur agilen Softwareentwicklung. Kurzkommentar: Ich würde hier noch eine weitere Unterscheidung betrachten: Ein Sprachfeature, ein Prozess oder was auch immer kann nicht nur “enabling” oder “directing” sein. Die Frage ist doch eher: Was wird mir ermöglicht oder vor was werde ich geschützt? Niemand wird behaupten, auf Anhieb fehlerfreien Code zu produzieren. Als Entwickler machen wir Fehler. Punkt. Und wenn etwas solche Leichtsinnsfehler, verhindert oder erschwert, ist das erstmal gut. Das ist directing. Es gibt aber auch die andere Kategorie Fehler, die einem guten Entwickler praktisch nicht mehr passieren. Auch für solche Fehler mag es Techniken/Tools/Methoden geben, die sie verhindern und in gewissen Situationen sind sie vielleicht auch sinnvoll. In anderen aber nicht. Konkret würde ich sagen: Je erfahrener ein Entwickler ist, desto mehr kann man das “enabling” dem “directing” vorziehen. Leichtsinnsfehler wird man aber immer machen und es ist gut, wenn man etwas hat, um dem zu begegnen. Was ich mich nun frage: In welches Lager zähle ich? Ich mag Exceptions. Ich mag OO. Ich bin statisch typisierte Sprachen gewohnt, sehe aber auch den Nutzen von dynamisch typisierten (demgegenüber bin ich aber klar für stark typisierte Sprachen und gegen schwach typisierte). Und ich sehe sowohl die Vorteile von plangetriebenen als auch von agilen Prozessen. Ist zumindest mal interessant, darüber nachzudenken…
• Wenn ich grad mal wieder dabei bin Martin Fowler zu verlinken, hier noch ein Link: ContextualValidation
• In der Uni haben wir SDL gelernt um Protokolle zu spezifizieren. Das ist ja ganz lustig und es ist schön, dass man aus den Diagrammen vollautomatisch Code generieren kann. Aber im Detail ist es nicht sonderlich gut gelöst. Die Strukturdiagramme sind ganz in Ordnung. Wobei hier ganz klar eine Möglichkeit fehlt, Signale über ein einfaches Symbol in mehrere Kanäle zu replizieren. Prozessdiagramme sind für einfaches Zeug in Ordnung, ab einer gewissen Komplexität IMHO aber unübersichtlicher und vor allem schwergewichtiger als Code. UML-Zustandsdiagramme demgegenüber zeigen eigentlich schön, wie zwischen den Zuständen gewechselt wird. Bei SDL hat man diesen Vorteil nicht. Und so sehe ich keinen sonderlichen Vorteil darin, dass die Prozessdiagramme, nun, Diagramme — also graphisch — sind. Eine Mischung aus UML-Zustandsdiagramm und Code wäre IMHO benutzbarer gewesen. Schade.

Anderes — heute: (hauptsächlich) Filme

• Es gibt mal wieder einen — mal wieder sehenswerten — Blender-Film: Tears of Steel
• Guter Film: Das Bourne Vermächtnis — Die Verfolgungsjagd am Ende ist etwas langatmig. Und man sollte die anderen Teile der Reihe gesehen haben (in doppeltem Sinne). Ansonsten ganz gute Unterhaltung.
• Total Recall war übrigens auch nicht schlecht. Insbesondere das Szenenbild ist wirklich sehr gut. Aus der Story hätte man aber etwas mehr machen können. Viel zu gradlinig für einen Film, bei dem es um manipulierte Erinnerungen geht. Das Original aus dem Jahr 1090 hab ich bisher nicht gesehen.
• Doctor Who ist toll. Zumindest das, was ich bisher gesehen hab (11. Doktor, ab Mitte 6. Staffel).
• Die Ig-Nodelpreise wurden mal wieder verliehen.

Fehlerbehandlung in mehrschichtigen Systemen

… oder kurz: Schichten und Exceptions

Die Delphi-Tage 2012 sind zu Ende. Wie üblich hab ich nen Vortrag gehalten. Diesmal gings um Schichten, um Exceptions und was das eine mit dem anderen zu tun hat.

Abstract:
Wie strukturiert man eigentlich Software? Braucht Software überhaupt eine Struktur? Und, wenn ja, wie kann die aussehen? Und wie behandelt man eigentlich Fehler und Ausnahmesituationen? Sind Exceptions hier das Maß aller Dinge? Wie setzt man sie richtig ein? Und was hat das Ganze mit Schichten zu tun? Dieser Vortrag gliedert sich in zwei Teile. Im ersten Teil wird gezeigt, wie man Software in Schichten strukturieren kann und welche Vorteile das hat. Außerdem werden ein paar Buzzwords wie “Architektur”, “Layers” und “n-Tier” geklärt. Der zweite Teil befasst sich mit Exceptions, wie man diese richtig einsetzt und was das Ganze mit Schichten zu tun hat.

Resümee:
Ich halte gerne Vorträge und noch lieber halte ich sie, wenn interessiertes Publikum vorhanden ist. Und das war es. Und es hat Spaß gemacht. Der Raum war voll und das obwohl die parallel stattfindenden Vorträge sich eigentlich auch sehr interessant angehört haben. Was mich besonders gefreut hat, war, dass es viele gute Fragen gab. Es ist immer schön zu sehen, wenn man mit dem Thema etwas getroffen hat, das nicht nur einen selbst interessiert.

Von meiner Seite aus muss ich sagen, dass eigentlich alles ziemlich gut geklappt hat. An Details kann man natürlich immer feilen. Deshalb mal wieder die Bitte um Feedback. Diverse positive Rückmeldungen hab ich schon bekommen (was mich sehr gefreut hat). Da ich mich aber nur verbessern kann, wenn ich weiß, was nicht so gut war, bitte ich auch und insbesondere um negatives Feedback. Was war nicht den Erwartungen entsprechend, was war verbesserungswürdig, unnötig oder unverständlich? Was hat gefehlt?

Folien und Vortragsnotizen:
Ich habe diesmal getrennte Folien und Vortragsnotizen. Auf den Folien steht nicht sonderlich viel drauf, was sie für den Vortrag passender gemacht hat (denke ich zumindest). Dafür gibts zusätzliche Vortragsnotizen. Diese sind demgegenüber ausführlicher und enthalten teilweise sogar ganze Textabsätze. Das ist jetzt nicht so detailliert und ausgefeilt wie ein Tutorial, aber es sollte ausreichen, um auch verständlich zu sein, ohne dass man den Vortrag gehört hat. Feedback hierzu ist natürlich auch willkommen. Also hier die Downloads:
Download: Schichten und Exceptions: Folien (Größe: 2.99 MB; bisher 150 mal heruntergeladen)
Download: Schichten und Exceptions: Vortragsnotizen (Größe: 3.05 MB; bisher 168 mal heruntergeladen)

Hinweise:

• Danke für den Hinweis, dass in den Folien ein “Create” gefehlt hat. Ist jetzt korrigiert.
• Nach dem Vortrag würde ich noch auf EurekaLog als Alternative zu madExcept hingewiesen. Der Hinweis findet sich nun auch in den Vortragsnotizen.
• Ebenfalls vielen Dank für den Hinweis, dass man die UML-Packages, die erstmal ja nur eine logische Gruppierung darstellen, mit Delphi-Packages umsetzen kann. Der eigentlich passende Mechanismus wären IMHO wohl Namespaces, die es in Delphi in der Form nicht gibt. Und wenn man sich .NET und Java ansieht, wird man feststellen, dass es dort beides gibt: Namespaces/Java-Packages und Assemblies/jar-Dateien. Beides, logische und physische Gruppierung, ist orthogonal, d.h. vollkommen unabhängig voneinander. So kann eine Assembly mehrere Namespaces enthalten und umgekehrt. Dabei ist die physische Gruppierung die eindeutig schwergewichtigere. Trotzdem halte ich das für einen wertvollen Hinweis. Man sollte sich durchaus überlegen, ob Delphi-Packages nicht doch in Frage kommen, um einzelne Schichten/Packages voneinander zu entkoppeln. Ist wohl eindeutig eine Überlegung wert.
• Die Graphik mit dem schlecht wartbaren Subsystem wurde mit einer Software des Fraunhofer IESE erstellt. Links dazu sind in den Vortragsnotizen.
• Zwei “Problembereiche” von Exceptions wurden noch angesprochen: DLLs und Threads. Ich hab nochmal nachgeguckt, aber leider hab ich keine Links dazu parat. Und ein Patentrezept hab ich leider auch nicht. Von daher kann ich wohl nur wiederholen, was ich schon als Antwort gegeben hatte: Exceptions an DLL- und Threadgrenzen vermeiden (noch mehr als sonst) und ggf. auf die anderen Fehlerbehandlungsmechanismen ausweichen (Fehlercodes, OnError-Events, etc.). Man könnte sich auch andere Ausweichstrategien überlegen. Beispielsweise Records mit den Fehlermeldungen zurückgeben, Window-Messages verschicken, etc. Auch kann man sich um ne DLL auf der Aufruferseite wieder einen Wrapper schreiben, der Fehlercodes, die als Ausweichstrategie verwendet wurden, wieder in Exceptions umschreibt. Leider gibt es wohl keine perfekte Lösung. Was im konkreten Fall nun vorzuziehen ist, hängt dabei wohl auch stark von den jeweiligen Rahmenbedingungen und Anforderungen ab.
• Testgetriebene Entwicklung/Test-First-Ansätze wurden erwähnt. Genau genommen unterscheide ich zwischen den beiden Begriffen (was nicht alle tun). Vielleicht mach ich dazu mal nen separaten Blog-Post darüber. Vereinfacht gesagt geht es darum, den Test-Code zuerst zu schreiben. Und das hat dann Auswirkungen auf das Design. Eigentlich geht es noch um viel mehr. Weil ich das aber hier nicht alles erwähnen kann, verweise ich lieber auf Wikipedia, die einschlägigen Blogs und diverse Bücher zum Thema.
• Zu Assertions hab ich letztes Jahr schon ein bisschen was gesagt. Außerdem kann ich auf das auch anderweitig unbedingt zu empfehlende Buch “The Pragmatic Programmer” verweisen. Da gibts auch ein kleines bisschen etwas dazu. Im übrigen sind Andrew Hunt und David Thomas auch meiner Meinung, dass man Assertions nicht unbedingt deaktivieren muss.
• Design by Contract wurde auch kurz erwähnt. Hier ein passender Link dazu.
• Ich hoffe, ich hab hier nichts vergessen. Vielen Dank jedenfalls auch für die anderen Kommentare.

Nachtrag:
Eine Möglichkeit zur Verbesserung ist mir gerade selbst noch eingefallen: Mit einem Laserpointer würde sich wohl deutlich besser auf die Leinwand zeigen können als mit der Hand. Ich glaub, ich sollte mir für nächstes Jahr so ein Ding zulegen. Ansonsten würde ich gerne wissen, ob ich verständlich war. Sowohl inhaltlich alsauch sprachlich. War ich zu schnell, zu langsam, zu laut, zu leise? Wie war meine Körperhaltung und keine Ahnung was… Ich bitte auch um Kritik an Kleinkram.

Gefangen, nicht gefunden! #22

Informatik

• Wie man einen Graph plottet
• Nächstes Frühjahr werd ich mit dem Studium fertig und stürz mich ins Berufsleben. Ich hoff dann mal, dass ich dann nicht sowas erleben muss: Joy of Programming: SNAFU — Situation Normal, All Fouled Up!. Bei Firmenkontaktmessen, Exkursionen und Co. ist es ja ganz sinnvoll, die Leute dort auszufragen, um nen Eindruck zu kriegen. Vielleicht sollte ich meinen Fragenkatalog erweitern, um solche Fälle zu erkennen. Hm…
• Letztens hat jemand behauptet, dass Joel Spolsky ja so konservativ wäre. Mal davon abgesehen, dass ich Leute kenne, die noch viel konservativer sind, wusste ich erstmal nicht so ganz, woran man das festmachen sollte. Und ich hab mich gefragt, ob ich auch so “konservativ” bin. Zumal ich seine Ansichten über Management gar nicht so konservativ finde. Letztens hab ich aber seinen Artikel How Microsoft Lost the API War gelesen. Und da seh ich manches denn doch etwas anders. Nicht in der Kernthese des Artikels: Dass es MS mittlerweile schwerer hat, weil SaaS und die Cloud immer wichtiger werden und iOS und Android auch Windows bedrohen, zeigt eigentlich, dass Spolsky schon vor 8 Jahren nicht ganz unrecht hatte mit der Entwicklung. Über weite Strecken erzählt er aber — durchaus lesenswert — von zwei Lagern bei MS. Die einen, die Rückwärtskompatibilität über alles stellen und die anderen, die gerne mal was Neues machen. Und er beklagt, dass letztere “gewonnen” haben. Seine Argumente sind nicht ganz falsch. Aber er unterschlägt, dass es auch immer wieder neue Produkte gibt und manchmal nur ein Bruch in der API wirklich Fortschritte bringt. Es ist kein Schwarz oder Weiß. Es ist immer eine Abwägungssache.
• Wenn wir schon dabei sind: Noch ein interessanter Text von Joel Spolsky: Getting Things Done When You’re Only a Grunt
• Wie schon erzählt, mache ich mir momentan so ein bisschen Gedanken darüber, wo ich nach meinem Studium hin will. Dass ich in die Softwareentwicklung will, steht fest. Dabei stellt sich für mich aber u.a. auch die Frage, ob ich lieber Standardsoftware oder Individualsoftware entwickeln will. Beides hat wohl seine Vor- und Nachteile. Außerdem frage ich mich, ob ich lieber plangetrieben oder lieber agil Software entwickeln will. Auch das hat seine Vor- und Nachteile und ich kann mir beides vorstellen. Bei den ganzen Überlegungen merke ich aber mal wieder: Der eigentliche Unterschied liegt in der Denkweise. Man kann auch einen klassischen Ansatz mit Scrum verbinden. Ob das Ergebnis dann “agil” ist, ist ne andere Frage, aber das heißt nicht, dass das Ergebnis schlecht wäre. Die Idee finde ich jedenfalls ganz interessant.
• Über Technical Debt bzw. techische Schulden hab ich ja schon des öfteren erwähnt. Ich finde das ist eine sehr hilfreiche Metapher. Eine detailliertere Taxonomie beschreibt Steve McConnell. Lesenswert. Und noch ein Artikel zu dem Thema: Understanding technical debt
• Wenn wir grad beim unsortierten Auflisten von Artikeln sind, die ich gelesen hab: Hier ist noch einer: Death by UML Fever. Ich mag die UML. Eigentlich. Man kann sie aber sehr unterschiedlich einsetzen. Der Artikel behandelt problematische Anwendungen der UML.
• Irgendjemand hier, der wissen will, wie und warum man Entwickler wird? Und wie man ein besserer wird? Vermutlich wissen das die meisten von euch schon. Egal. Hier ist trotzdem ein interessantes Video, das das veranschaulicht: So You Want to Be a Developer Part 1 und Part 2
• Wie ein paar Praktikanten innerhalb von 12 Wochen eine marktreife Software schreiben: Aardvark’d: 12 Weeks with Geeks

Anderes

• Ich war noch nie ein großer Comic-Leser. Was ich aber ganz gerne lese, sind Web-Comics wie xkcd. Randall Munroe, der Autor von xkcd, hat aber noch ein paar andere Projekte, die mitunter auch ganz interessant sind. Das neueste ist “what-if“. Dort gibt er physikalische Antworten auf hypothetische Fragen. Beispielsweise, was passieren würde, wenn man einen Baseball auf 90% der Lichtgeschwindigkeit beschleunigen könnte. Das Ergebnis liest ich überraschend und unterhaltsam.
• Momentan läuft ja The Amazing Spider-Man in den Kinos. Kurzreview hierzu: Ich war ganz gut unterhalten, aber viel mehr auch nicht. Die Story verschenkt einige Potenziale und ist ziemlich vorhersehbar linear. Schade. Außerdem dachte ich, dass 3D bei den Wolkenkratzer-Szenen beeindrucken sein müsste. Weit gefehlt: Durch die Bewegungsunschärfe verschwimmt der Hintergrund und der Effet verschwindet.

Linux für Computer-Anfänger

… endlich mal wieder ein Linux-Artikel …

Meine Mutter lernt gerade Computer. Vieles von dem, was für mich selbstverständlich ist, muss sie erst lernen. Und manches fällt ihr schwer. Scrollbalken z.B. Oder generell die Maus. Oder, dass es mehrere Fenster gibt.

Ich habe ihr jetzt einen eigenen Rechner eingerichtet. Einen, der möglichst einfach zu bedienen ist. Und damit so ein Rechner wirklich einfach zu bedienen ist, muss man ne ganze Menge beachten:

• Scrollbalken sind schwer. Man muss mit der Maus den Balken an der richtigen Stelle treffen und das Ding richtig bedienen. Alternativ kann man zwar auch Pfeiltasten oder Scrollrad verwenden. Dazu muss die Box oft aber den Fokus haben. Und Fokus ist ein kompliziertes Konzept.
• Doppelklicks sind schwer. Man muss schnell genug sein. Und die Maus darf dabei nicht wackeln.
• Alles, was irgendwie anders ist, als sonst, ist verwirrend und beängstigend.
• All die vielen Knöpfe verwirren.
• Man muss Updates machen, damit das System aktuell bleibt und sich keine allzu großen Sicherheitslücken auftun. Und das wird noch komplizierter, wenn das bei jedem Programm anders funktioniert.
• Virenscanner, Firewall und was weiß ich nicht alles drücken sich manchmal einfach so in den Vordergrund. Das ist verwirrend.
• Ordnerhierarchien sind kompliziert.
• …

Ein Anfänger-Rechner muss *wirklich* einfach sein. Also hab ich Linux drauf gemacht. Meine Mutter verwendet eh nur Browser, Mailclient und Textverarbeitung. Da gibt es keinen Grund, warum man Windows verwenden müsste. Und so hab ich die Möglichkeit, alles so einzurichten, dass alles möglichst einfach ist… weiter lesen »

Seid stolz auf eure Fehler

Ja wirklich. Aber ich fürchte, das muss ich erklären.

Wir lernen meines Erachtens hauptsächlich aus Fehlern. Entweder aus eigenen oder aus denen von anderen. Deshalb sage ich meinen Studenten immer, sie sollen keine Angst haben, auch mal was Falsches zu sagen. Im Gegenteil: Wenn man eine falsche Antwort gibt, wird man sich viel leichter merken, was die richtige ist. Wenn man nur richtig geraten hat, hat man Pech, weil man sich dann schlechter daran erinnern wird, als wenn man die falsche Antwort gegeben hätte.

Fehler machen ist also gut. Weil man daraus lernt. Wenn man daraus lernt. Meistens ist das eher der komplizierte Schritt. Das ist etwas, das ich auch immer versuche, meinen Studenten bei zu bringen. Und heute bin ich mal an der Reihe, auf meinen eigenen Ratschlag zu hören. Ich habe einen Fehler gemacht. Die Seminararbeit, die ich geschrieben habe, ist nicht so gut angekommen. Sie war wohl u.a. nicht so gut verständlich. Und ich hab ein bisschen gebraucht, bis ich verstanden habe, warum. weiter lesen »

Von Eiswaffeln und Tests

Tests scheint irgendwie niemand gerne zu machen. Warum auch immer. Das sehe ich gerade jetzt wieder. Ich betreue ja wieder mal das Softwareentwicklungsprojekt und da soll im Team eine Software entwickelt werden. Und selbstverständlich muss man die auch testen (das schreiben wir sogar vor). Hier aber mal eine kurze Statistik, wie das aussieht:

• Innerhalb von ca. 2 Wochen haben von den 17 Gruppen gerade mal 5 überhaupt angefangen, Tests zu schreiben.
• Davon benutzen gerade mal zwei Stubs.
• Dafür hat eine Gruppe ganz offensichtlich schon Probleme, das Prinzip von JUnit zu verstehen
• Und eine hat bisher nur ein paar Fingerübungen gemacht.

Wir kannten solche Probleme schon aus den letzten Jahren. Also hatten wir extra eine Saalübung zum Thema Testen gemacht. Wir hatten erklärt warum man testet, wie man das tut, wie und warum man Stubs verwendet und warum Test-First eine sinnvolle Strategie ist. Geholfen hat es offensichtlich wenig.

Dabei könnten Unit-Tests helfen, Zeit zu sparen, weil man Bugs früher bemerkt. Ja genau: Richtig eingesetzt würden die Tests eigentlich Zeit sparen. Eigentlich…

Ich will jetzt aber wenigstens noch ein bisschen was zu Tests sagen. Nicht weil ich große Hoffnung hätte, dass das auf wundersame Weise 17-x SEP-Gruppen bekehrt (die meisten werden das hier wohl eh nicht lesen). Aber ich hab ein paar interessante Links, die vielleicht wenigstens *irgendwem* helfen könnten… weiter lesen »