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.