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 98 mal heruntergeladen)
Download: Exception Handling in Multi-Layered Systems (talk notes) (Größe: 3.08 MB; bisher 172 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.

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 151 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.

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 »

Gefangen, nicht gefunden! #11

Mein letzter Blogeintrag ist schon ne Weile her. Das liegt u.a. daran, dass ich ein vergleichsweise arbeitsreiches Semester hinter mir habe… und jetzt noch zwei Klausuren vor mir. Mit ein bisschen Glück gibts jetzt aber wieder etwas öfter was von mir zu lesen. In der Zwischenzeit haben sich eine Hand voll halb-fertige Artikel angesammelt. Ebenso wie einige interessante Links…

Informatik

• Mein Vortrag für die diesjährigen Delphi-Tage ist angenommen worden. Auf der “Agenda” steht was von “Was die OOP-Tutorials verschweigen”. Es geht grob gesagt darum, wie man objektorientiert denkt. Die Folien werde ich online stellen, wenn ich sie fertig habe.
• How Not To Sort By Average Rating. Ein interessanter Artikel über das richtige Sortieren von Bewertungen (via).
• Ich hab jetzt mal auf WordPress 3 aktualisiert. Ging überraschend reibungslos. So wie ich das sehe, gehen alle Plugins noch, obwohl die meisten davon nicht für die 3er-Version aktualisiert wurden. Eigentlich sollte das bei gutem Design ja normal sein. Eigentlich…
• Wer sich ein bisschen für Security interessiert, sollte sich vielleicht mal “Tatort Internet” ansehen. Bisher gibt schon 4 Folgen. Alle sind sehr interessant und kurzweilig geschrieben. Da sieht man mal wie Malware wirklich funktioniert. Wenn man mitkommen möchte, sollte man aber ein paar grundlegende Assemblerkenntnisse mitbringen.
• “software is like sewage pipes, I want it to work reliably and I don’t want to know about the details” (gefunden bei Martin Fowler). Das Bild passt auch ganz gut auf Module. Denn genau so funktioniert Kapselung (“I want it to work reliably”) und Information Hiding (“and I don’t want to know about the details”). Der Artikel ist übrigens auch ganz interessant.
• Ich finde ja Assertions sehr praktisch. Also wenn man sie richtig anwendet. Vor einiger Zeit hab ich dazu einen interessanten Artikel gelesen: Design by Contract and Unit Testing. Die Frage ist nämlich u.a. wie das mit Unit-Tests zusammenpasst. Es gibt da noch ne Menge dazu zu sagen. Da werde ich aber wohl separat mal dazu bloggen. Wenn ich hoffentlich bald mal dazu komme…
• Zehn Zentimeter: In diesem kurzen Blogpost erklärt Isotopp sehr schön, welchen Beschränkungen verteilte Systeme hinsichtlich der Performance ausgesetzt sind.

Anderes

• Nein, heute gibts nichts anderes…

Boost:UTF und die Irrwege eines Linkers

Heute hab ich einen sehr merkwürdigen Bug gefixt. Ich benutze das Unit Testing Framework (UTF) der Boost-Library. Im Allgemeinen finde ich das Framework auch ganz gut, aber heute (bzw. eigentlich schon gestern) habe ich eine Merkwürdigkeit entdeckt.
weiter lesen »