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. :lol:). 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.