Agile: Frequency Reduces Pain

Quasi alle mir bekannten agilen Methoden basieren auf einem weiteren grundlegenden Gedanken, der allerdings nur selten genannt wird, wenn Agile Softwareentwicklung erklärt wird: Frequency Reduces Pain oder anders ausgedrückt: “if it hurts, do it more often”. Integration, Tests, Schätzungen, Refactoring, alles das kann sehr unangenehm werden. Deshalb wird das alles in agilen Prozessen viel öfter gemacht — in kleineren, überschaubareren Schritten.

Integration kann man nicht vermeiden. Irgendwann muss man eben mal alles zusammenwerfen und gucken, ob es funktioniert. Je größer die Software und je später die Integration, desto schwieriger wird das Ganze. Deshalb macht man es viel öfter. Nämlich mindestens einmal täglich. Und auf einmal wird alles viel einfacher.

Schön zusammengefasst ist das außerdem in Gall’s Law:

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

Integration ist nur ein Beispiel. Das genannte Prinzip steckt in ganz vielen agilen Praktiken und ist außerdem der Grund dafür, dass agile Prozesse hochgradig iterativ sind: Wenn es schwer ist, Software fertig zu kriegen, dann kriegen wir sie eben alle zwei Wochen fertig. Wenn Schätzen schwer ist, dann schätzen wir eben alle zwei Wochen neu, aber dafür kleinere Arbeitspakete. Wenn Testen nervig ist, machen wir es zum Prinzip und schreiben Tests vor dem eigentlichen Code, sodass unser Code unweigerlich testbar wird. Wenn Refactoring fehleranfällig ist, machen wirs doch besser andauernd — immer mal wieder ein bisschen.

Softwareentwicklung ist wie Markklößchensuppe essen: Nicht alle auf einmal, sondern einer nach dem anderen.

Agile: Was ist das eigentlich?

In der letzten Zeit hab ich mich eingehend mit agiler Software-Entwicklung beschäftigt. Das hatte ich schon eine ganze Zeit lang vor, aber praktischerweise hatte ich von der Uni aus die Aufgabe mit ein paar Kommilitonen mir Scrum anzusehen und darüber zu referieren. Außerdem habe ich gerade an der Summerschool “Agile Software-Entwicklung” teilgenommen. Das hab ich dann mal zum Anlass genommen, mich etwas intensiver mit der Thematik zu beschäftigen.

Bei Agiler Softwareentwicklung gehen die Meinungen typischerweise stark auseinander. Je nachdem wem man zuhört, ist man geneigt entweder den einen oder den anderen recht zu geben. Beide Argumentationsweisen, beide Softwareentwicklungsphilosophien hören sich, für sich alleine betrachtet, vollkommen vernünftig an. Das hilft natürlich nicht sonderlich weiter, wenn man sich eine eigene Meinung bilden will und so schreibe ich das hier hauptsächlich, um mir selbst hier einigermaßen Klarheit zu verschaffen.

Ursprünglich hatte ich einen vergleichsweise langen Artikel geplant. Ich denke aber, dass mehrere kleinere Artikel eher gelesen werden als ein großer. Außerdem dauert ein großer Artikel immer so lange zu schreiben. Nachdem ich jetzt schon über zwei Monate immer mal wieder an dem Text sitze und immer noch erst etwa ein Drittel steht, habe ich mich nun entschlossen, eine Artikelserie daraus zu machen.

Die Artikelserie spiegelt meine momentanen Gedanken zu dem Thema wider. Ich kann nicht sagen, ob ich bei dieser Meinung, die ich hier mal herausarbeite, bleiben werde. Ich bin einfach selbst mal gespannt, wie ich zur Thematik stehen werde, wenn ich mit der Zeit mehr Einsicht gewinne. Nun gut. Ich hab jedenfalls einiges gelesen und mir meine Gedanken dazu gemacht. Los geht es mit einem geschichtlichen Überblick über die Thematik.
weiter lesen »

Gefangen, nicht gefunden! #19

Informatik

• Continuous Delivery und Feature Branching
• Isotopp über Performancepeaks auf Websiten
• Warum Wiederverwendung nicht immer gut ist: Package Cutomization
• Comment Only What the Code Cannot Say. Kann ich so unterschreiben. (via)
• Beauty Is in Simplicity. Ja, das stimmt wohl. Nur fehlt mir irgendwo im Text, dass “einfach” nicht “kurz” heißt. Ein bekanntes Zitat lautet: “Bitte entschuldigen Sie den langen Brief, ich hatte keine Zeit, einen kurzen zu schreiben.” Es wird irgendwie wahlweise Blaise Pascal, Karl Marx, Mark Twain, Voltaire, Goethe oder sonstwem zugeschrieben. Egal wers war: Es ist was Wahres dran.
• Eine interessante Sichtweise auf Code Reviews. Hab das bisher so noch nicht gesehen. Muss ich mir noch ne Meinung drüber bilden.
• Versionsverwaltung ist wichtig und überaus praktisch. Und die Tools unterscheiden sich ein bisschen. Hier gibts ein Buch darüber und hier ein Heise-Developer-Artikel. Beides hab ich noch nicht gelesen. Muss ich noch nachholen.
• Industrieanlagen-Steuerungen ungeschützt im Netz. Ähm… irgendwie fällt mir kein Kommentar ein, der treffend beschreiben würde, wie ich darüber denke. Aber ich fürchte, wenn ich einen finden würde, könnte man ihn als Beleidigend empfinden…

Anderes

• Mein gut gefüllter Feedreader enthält unter anderem auch xkcd. Wer das nicht kennt, sollte sich das unbedingt ansehen. Nun sind die Comics leider nicht immer so einfach zu verstehen. Und auch ich muss zugeben, dass ich sie nicht immer verstehe. Oder zumindest nicht ganz. Abhilfe schafft da http://www.explainxkcd.com/
• Fertig gelesen: Niemalsland von Neil Gaiman. Der erste Urban-Fantasy-Roman, den ich gelesen hab. Ein sehr gutes Buch, das ruhig noch etwas länger hätte sein können. Direkte Folgebände gibt es leider auch nicht. Gaiman entwirft eine traumhafte Welt unter Londons Straßen. In U-Bahnhöfen, Schächten und Kanälen. Was ich an Romanen oder allgemein an Geschichten mag, ist, wenn sie einen mitnehmen in eine andere Welt, wenn diese Welt funktioniert und einen immer neue Details und womöglich Absonderlichkeiten entdecken lässt. Das ist hier definitiv der Fall. Über Kleinigkeiten kann man immer meckern, aber das hat das Buch hier nicht verdient. Also las ich das mal bleiben. BTW: Auf YouTube gibt es Ausschnitte aus der zugehörigen Fernsehserie. Das, was ich da gesehen hab ist schlecht. Wirkt auf den ersten Blick alles dilettantisch und hölzern. Ich linke besser nicht darauf. Das Buch ist um Welten besser und hat diese Probleme nicht.
• Jetzt lese ich Lechts oder Rinks ein Sachbuch, das erklären will, wie wir Fehler machen. Das Buch ist interessant geschrieben, auch wenn ich bisher noch nichts aus dem Inhalt für meinen Vortrag auf den Delphi-Tagen verwenden konnte. Aber vielleicht kommt das noch. Mal sehen.

Gefangen, nicht gefunden! #18

Informatik und Anderes

• Böser Bug. Böser Bug. *Sehr* böser Bug! Aber sehr lehrreich. Einmal, weil man hier deutlich sieht, wie wichtig das Testen ist und wie schnell man einen fatalen Fehler übersieht. Und zum zweiten zeigt das Beispiel recht schön, warum Haftungsfragen auch bei eigentlich nicht sicherheitskritischer Software eine Rolle spielen können. Ich bin ganz froh darüber, dass ich gerade eine passende Vorlesung zu dem Thema höre. Die Rechtsprechung ist hier teilweise *sehr* merkwürdig, was Software anbelangt. (via).
• “The great thing about TCP jokes is that you always get them.” Zugegeben: Es hat ein bisschen gedauert, bis ich den verstanden hab (Das Problem bei TCP-Witzen ist ja auch, dass es ziemlich lang dauern kann, bis man anfängt, sie zu verstehen. ). Aber ich find den richtig gut. Und es gibt noch mehr von der Sorte. Die sind wohl irgendwie in Twitter entstanden. Noch ein paar gute:
  • @eigenrick: The problem with TCP jokes is that people keep retelling them slower until you get them. #protolol
  • @reconbot: WHO HAS ANY ARP JOKES? #protolol
  • @OhMeadhbh: the SYN flood attack #protolol: “knock knock. who’s there? knock knock. who’s there? knock knock. who’s there? …”
  • @yoz: order best is tell that The you thing can about jokes BitTorrent them in any. #protolol
  • @peter_tonoli: Chuck Norris has only one OSI level – Physical

  (via)

• Per Zufall bin ich auf eine sehr interessante Seite gestoßen: ioexception.de. Das ist ein Blog von ein paar Informatik-Studenten der Uni Ulm. Und da gibts so einige interessante Inhalte zu entdecken:
• Zustandsautomaten, State Pattern und Java Enums. Hinlänglich bekannt, aber nochmal schön zusammengefasst. Außerdem vielleicht ganz interessant für meine SEP-Studenten, die gerade einen Bot für ein Netzwerkkartenspiel schreiben dürfen. Und hier bietet sich eben das StatePattern und die genannte Umsetzung an. Das ist nicht die einzige Möglichkeit, Automaten in Code zu gießen. Bei Gelegenheit schreib ich da mal was dazu…
• Eine interessante Idee: git als Update-Mechanismus verwenden.
• Auch die anderen Posts lohnen sich. Einfach mal reingucken…
• Martin Fowler hat einen sehr interessanten Artikel über Flags in Methoden. Dem kann ich eigentlich kaum noch etwas hinzufügen. Außer vielleicht, dass Methoden-Flags i.d.R. Kontrollkopplungen sind, also den Kontrollfluss der Methode beeinflussen, statt ein Datum darzustellen. Und Kontrollkopplungen sind starke Kopplungen, d.h. man sollte sie vermeiden.
• Mein Vortrag auf den Delphi-Tagen ist wohl gesetzt. Zumindest verschickt Embarcadero schon Rundmails, in denen ich als Speaker genannt werde. Man darf sich also jetzt schon auf eine Stunde rund um Bugs und deren Vermeidung freuen oder sich wahlweise davor fürchten. Ich hab viel zu erzählen.
• Per Zufall bin ich hierüber gestolpert: Wie man ein guter Java-Programmierer wird. Ich fürchte, da ist was Wahres dran. Gilt natürlich auch für andere Sprachen und Bereiche. Nun, was soll ich sagen? Ich bin 23 und hab vor knapp 10 Jahren angefangen zu programmieren. Und B.Sc. bin ich auch schon. Also weiter gehts…
• Die aktuelle Liste der Top 25 Sicherheitslücken. Erschreckend, dass SQL-Injection immer noch ganz vorne ist.
• In C# kann man Interfaces auf zwei Arten implementieren. Entweder implizit oder explizit, d.h. entweder man implementiert einfach passende Methoden oder man spezifiziert genau, dass die Implementierung ausschließlich für dieses Interface gedacht ist. Das bedeutet, es ist möglich, dass eine Methode von einem bestimmten Interface aus zugänglich ist, von der eigentlichen Klassenreferenz aber nicht. Das klingt erstmal sehr merkwürdig, hat aber seine Vorteile. Es bietet nämlich die Möglichkeit, Methoden, die nur für ein bestimmtes Interface relevant sind, vor anderen Benutzern zu verbergen. Das ist dann quasi eine weitere Möglichkeit der Kapselung. Nick Hodges zeigt in einem Blog-Post, dass das auch in Delphi möglich ist. Bei Delphi kommt noch ein weiterer Punkt dazu: Wenn man in Delphi Interfaces verwendet, sollte man diese nicht mit echten Objektreferenzen mischen (außer man weiß sehr genau, was man tut). Das hängt damit zusammen, dass Interface-Referenzen im Gegensatz zu normalen Referenzzählung implementieren. Mit diesem Ansatz kann man also quasi sicher stellen, dass man die Klassenreferenz nicht benutzt (auf der anderen Seite sollte man hier eh überlegen, ob man nicht lieber ne Factory-Methode einsetzt). Die Diskussion in den Kommentaren ist übrigens auch interessant. Darüber wie und ob man dieses Feature verwenden sollte, sind die Meinungen gespalten. Auf jeden Fall, sollte man sowas gut dokumentieren.

Gefangen, nicht gefunden! #17

Informatik

• Nick Hodges altes Blog ist wieder da; http://www.nickhodges.com/post/My-Old-Blog-is-Back!.aspx. Schön. Da ist so mancher lesenswerter Eintrag dabei.
• Letztens war Barbara Liskov (ja, das ist die mit dem Liskovschen Substitutionsprinzip) bei uns an der Uni und hat einen Vortrag zum Thema The Power of Abstraction gehalten. Letztlich war der Vortrag ein bisschen Historisches zur Entwicklung der Abstraktion. Angefangen von Dijkstras “Go To Statement Considered Harmful” über abstrakte Datentypen bis zur Objektorientierung. Inhaltlich für jemanden der im 9. Semester Informatik studiert kaum etwas Neues, aber dennoch sehr interessant. Nicht zuletzt wegen Liskov selbst, die eine wirklich herausragende Informatikerin ist. 2009 erhielt sie einen Turing-Award; das ist quasi der Nobelpreis für Informatiker. Das, was sie erforscht hat, ist mittlerweile dermaßen anerkanntes Allgemeingut, dass eine Reaktion auf ihren Turing-Award der folgende Kommentar war: “What does she get this price for? Everybody knows this.” Das zeigt sehr schön dass man vor 30, 40 Jahren noch *ganz* anders programmiert hat. Noch bedeutender wird die Geschichte, wenn man erfährt, dass Liskov — ich hoffe ich krieg das noch einigermaßen zusammen — als sie sich auf ne Doktorandenstelle bewarb, erstmal auf Ablehnung traf (So à la “Wie weiblich und will Doktor in Informatik machen? Vergiss es!”). *kopfschüttel*
  Der Vortrag scheint der hier zu sein: http://www.infoq.com/presentations/liskov-power-of-abstraction Ich hab mir das Video nicht ganz angesehen, aber es scheint so ziemlich genau das zu sein, was sie uns erzählt hat. Auch die Folien sind wohl die selben. Wer also mal ein Stündchen Zeit hat…
• Ich hab mal wieder was Interessantes bei Martin Fowler gefunden: TolerantReader. Dort beschreibt er Postel’s Law (ui, wieder eine Daumenregel!) und dessen Anwendung auf Webservices. Aber auch, wenn man nix mit Webservices am Hut hat, ist der Artikel lesenswert.
• Hab gerade per Zufall eine sehr interessante Seite gefunden: http://www.uml-diagrams.org/ Dort gibt es sehr detailliert Informationen zu UML, samt Erklärungen und Beispielen. Sehr zu empfehlen!
• Ein interessantes Gedankenspiel von einer Studentengruppe, die ich betreue: Klassen nach den Teammitgliedern benennen, die sie entwickeln. Nicht, dass das von irgendeiner praktischen Relevanz wäre (war auch als Jux gedacht), jedoch zeigt das Gedankenspiel schön den Nachrichtenaspekt (und die Aufgabenverteilung) der OO: Hans.HolMirMalDieDatenAusDerDatenbank(), Fritz.BerechneDenMittelwert(). Taugt zwar nur als Gedankenspiel, ist aber trotzdem ganz lustig.
  Wobei mich das Ganze an etwas erinnert, was sogar tatsächlich Relevanz hat: Vor einiger Zeit hab ich mal folgenden Vorschlag gelesen (ich glaub es war in “The Pragmatic Programmer”; kanns grad auf die Schnelle nicht finden): Um Schnittstellen (Methoden) für Klassen zu finden, kann man die Kommunikation der Klassen im Entwicklerteam quasi nachspielen. Jeder begibt sich in die Rolle einer Klasse und dann werden verschiedene Szenarien durchgesprochen. Also sowas wie “Ich bin jetzt mal die Formularklasse. Und ich erzeuge jetzt eine Datenbankverbindung. Dazu geb ich dir host, username und password.” “Und jetzt nehm ich, die Datenbankverbindung, die übergebenen Daten und rufe damit den JDBC-Treiber auf, der mir die Verbindung aufbaut.” etc. Die Kommunikation wird dann dokumentiert und hinterher generiert man daraus eine Schnittstellenspezifikation.

Anderes

• Ich frage mich, ob es einen offiziellen Unterschied zwischen “parametrisieren” und “parametrieren” gibt. Gefühlsmäßig ist parametrisieren das Ermöglichen der Parametereingabe (beispielsweise das Auslagern in eine Methode und damit die Spezifikation der formalen Parameter) und parametrieren das Belegen von Parametern mit Werten (also die Spezifikation aktueller Parameter). Aber ist das nur ein Gefühl oder ist das wirklich so? OK, Sprache definiert sich durch Verwendung. Aber dann stellt sich die Frage, wie weit diese Unterscheidung verbreitet ist oder ob ich das allein so sehe.

Gefangen, nicht gefunden! #16

Informatik – Im Weitesten Sinne

• Martin Fowler über Zertifikate
• Nochmal Martin Fowler. Diesmal über die Umsetzung von Rollen. Fowler zeigt hier, wie man auf verschiedene Art und Weise Rollen umsetzen kann. Der Artikel ist darüber hinaus augenöffnend, was den Unterschied zwischen Analyse und Design angeht.
• Wie nutzt man eigentlich Exceptions richtig? Dazu hab ich einen interessanten Artikel gefunden. Der Artikel bezieht sich auf Java, lässt sich aber leicht auf andere Sprachen übertragen.
• Den Call for Paper für die diesjährigen Delphi-Tage hab ich schon vor einiger Zeit bemerkt. Mir schwebt auch schon etwas vor. Nur muss ich endlich mal dazu kommen, was zusammen zu schreiben und abzuschicken.
• Eigentlich hab ich die ganze Zeit schon vor, über das Kreis-Ellipse-Problem zu bloggen. Allerdings hab ich dazu deutlich mehr Material gefunden, als ich bisher Zeit hatte zu sichten. Bis ich dazu komme, etwas zu schreiben, hier schonmal in Link.
• Kurz und verständlich. Die Java Collections API.
• Von der gleichen Seite: Datumswerte in Java. Hier sieht man mal wieder, was so typisch für die Java API ist: Intuitive Interfaces wurden zuerst genutzt. Die waren aber inflexibel ausgelegt. Jetzt sind die deprecated und es gibt bessere und mächtigere Interfaces. Nur sind die eben nicht mehr so intuitiv benutzbar. Die ganzen deprecated-Interfaces müllen den Namensraum zu. Jeder würde Datumsfunktionen in der Klasse Date suchen. Nur sind das eben die alten, die man nicht mehr benutzen soll… Das ist der Nachteil von Abwärtskompatibilität bzw. einer gewissen Lesart des Open-Closed-Principles: Alte Zöpfe, die niemand abschneidet. Nicht dass ich damit sagen wollte, man sollte das unbedingt tun. Das ist wie immer eine Abwägungssage. Und es zeigt, wie schwierig Frameworkdesign ist.
• Eigentlich hatte ich ja vor, ein Tutorial über OOA und OOD zu schreiben. Sieht aber momentan so aus, als käme ich nicht dazu. Vielleicht mache ich aber auch einzelne Blogartikel draus und fasse die später doch zu einem Tutorial zusammen. Mal sehen…

Anderes

• Ich lese gerade “Der Zauberhut” von Terry Pratchett. Das Buch ist echt klasse. Terry Pratchett schreibt ja generell tolle Bücher und gerade jetzt merke ich das mal wieder. Faszinierend.

Tradable Quality Hypothesis

In der Vorlesung Projektmanagement hört man folgendes: Die Produktivität eines Softwareentwicklungsteams ist konstant. Will man mehr leisten, in kürzerer Zeit leisten, zu geringeren Kosten leisten oder in höherer Qualität leisten, leiden die jeweils anderen Aspekte. Es ist unmöglich alle diese Punkte gleichermaßen zu verbessern.

Der Zusammenhang lässt sich mit dem so genannten Teufelsquadrat nach Sneed visualisieren. Der blaue Bereich in der Mitte der Grafik ist die Produktivität des Teams. Zieht man nun an einer oder mehreren Ecken, so drückt man gleichzeitig die anderen Ecken ein. Die Fläche in der Mitte – die Produktivität – bleibt immer konstant.

Das ist sehr anschaulich und auch intuitiv verständlich. Aber ist es auch richtig? Gerade letztens habe ich bei Martin Fowler etwas Interessantes dazu gelesen. weiter lesen »

Gefangen, nicht gefunden! #14

Informatik

• Schon ewig alt und altbekannt, aber ich find den Text immer wieder klasse: Dojo
• Eigentlich wollte ich darüber ein bisschen mehr schreiben, aber aus Zeitmangel hierzu nur so viel: Fluent Interfaces sind etwas Merkwürdiges. Es ist eine vollkommen andere Art und Weise, wie man Schnittstellen aufbaut. Auch Martin Fowler hat etwas dazu. Als ich zum ersten Mal von Fluent Interfaces gelesen hatte, fand ich die zwar ganz lustig, aber mehr Spielerei als ernst zu nehmende Alternative. Mittlerweile sehe ich das ein bisschen anders. Fluent Interfaces machen zwar die Implementierung – sofern man sie denn richtig machen will – meist deutlich komplizierter, die Benutzung aber einfacher. Und es heißt ja nicht umsonst eine Schnittstelle sollte sich nur schwer falsch, aber intuitiv richtig verwenden lassen. Damit sind Fluent Interfaces insbesondere für solche Fälle geeignet, bei denen Code nur selten verändert, aber häufig genutzt wird. Bei APIs, Frameworks und ähnlichem. Natürlich kommt das mal wieder auf den konkreten Anwendungsfall an. Letztens habe ich so einen gefunden. Und zwar bei Nick Hodges: THTMLWriter. Das ist eine Klasse mit der sich auf einfache Weise HTML-Ausgaben erzeugen lassen. Und für einen solchen Zweck eignen sich Fluent Interfaces (bzw. genauer gesagt Method Chaining) hervorragend.
• Die Entwicklung von HTMLWriter geht munter voran und es lohnt sich, immer mal wieder vorbei zu schauen. So sind mittlerweile auch Interfaces dazu gekommen. Interfaces führen in Delphi immer noch ein Schattendasein. Durch die implizite Referenzzählung muss man die richtige Verwendung erstmal lernen. Leider ist das in Delphi nicht so einfach wie in Java oder C#. Dennoch könnten Interfaces wohl häufiger Verwendung finden. Wie das Beispiel hier zeigt, kann sich das wirklich lohnen.

Anderes

• xkcd: Misconceptions
• Philosophie ist etwas Tolles. Insbesondere die Erkenntnistheorie finde ich hochgradig interessant. Wenn man damit (beruflich) etwas anfangen könnte und Informatik nicht so interessant wäre, würde ich vielleicht Philosophie studieren. Unter anderem im Bereich der Logik gibt es zwischen Informatik und Philosophie sogar ein paar Überschneidungen. Interessant finde ich insbesondere die Tatsache, dass es verschiedene Logiken gibt. In manchen gelten bestimmte Regeln und in anderen gelten sie nicht. Das wirft natürlich die Frage auf, woher wir denn wissen, dass manche logische Schlussfolgerungen überhaupt gültig sind. Bis ich da aber einigermaßen durchblicke und mir eine Meinung gebildet habe, läuft noch viel Wasser den Rhein runter…

Code Smells: Wenn Code anfängt zu stinken

Jeder, der schon eine Weile programmiert, wird die Situation kennen: Man liest Code (entweder fremden oder eigenen) und es läuft einem kalt den Rücken runter, die Zehnägel stellen sich auf und man will nur noch wegsehen. Wer das noch nie erlebt hat, sollte einfach mal seine ersten Programmierversuche wieder herauskramen.

Mancher Code scheint einfach zum Himmel zu stinken. Treffenderweise nennt man so etwas “Code Smell”. Letztens habe ich bei Nick Hodges von einem Stackoverflow-Thread über solche Code Smells gelesen.

Ich dachte mir, das passt wunderbar zu der an den Delphi-Tagen angekündigten (und leider immer noch nicht wirklich begonnenen) Artikelserie zu den Prinzipien der (objektorientierten) Softwareentwicklung. Wahrscheinlich werde ich zu jedem diskutierten Prinzip – wenn möglich – ein paar Code-Smells als abschreckendes Gegenbeispiel benennen. Hier aber erstmal ein paar allgemeine Gedanken zu Code Smells:
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…