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.
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.
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.
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.
Informatik
- 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:
- 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…
Informatik
Anderes
- Boa bin ich langsam. Das hier liegt schon seit Ewigkeiten hier um. Ein Punkt oben war noch “Die Delphi-Tage sind ausverkauft” (aus verständlichen Gründen hab ich das vor dem Posten wieder gelöscht; Anachronismen sind nicht sonderlich hilfreich) und WordPress zeigt den 16. August als Erstellungsdatum…
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.
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.
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.
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.
Gefangen, nicht gefunden! | Christian | 
10. Januar 2013 11:30 | 
Kommentare (0) 
Also nicht von 
