Vorträge

Irgendwie komme ich kaum zu posten. Unter anderen wartet ein Artikel zu REST (wobei das vermutlich mehrere werden) in der Pipeline. Jetzt sind aber erstmal die Delphi-Tage dran. Und bevor sich das hier gar nicht mehr mache, kurz und bündig:

  • Die diesjährigen Delphi-Tage in Bonn haben mir wieder gut gefallen.
  • Mit Delphi hab ich mittlerweile eigentlich kaum noch etwas zu tun. Aber es war 10-jähriges Jubiläum der Delphi-Tage und ich hab Martin ein wenig vertreten dürfen. Es waren meine siebten Delphi-Tage und vielleicht meine letzten. Aber man soll ja nie nie sagen…
  • Die Begrüßung verlief ungeplanterweise etwas improvisierter als von mir angedacht. Aber ich denke, es haben sich trotzdem alle begrüßt gefühlt.
  • Mein Vortrag war insgesamt ganz gut besucht und ich bin im Großen und Ganzen auch zufrieden. Das ein oder andere hätte ich besser machen können, aber ich fands in Ordnung.
  • Ich hab vermutlich etwas zu oft Fragen ins Publikum gegeben. Ich sollte lernen, das gezielter einzusetzen.
  • Vermutlich hat man gemerkt, dass ich deutlich weniger Zeit in Folien und Vortragsvorbereitung gesteckt habe, als in den letzten Jahren. Die Folien waren sehr codelastig und an der ein oder anderen Stelle gabs kleine Fehler. Und er Vortrag lief nicht überall ganz rund: „Hab ich hierzu ne Folie? Äh ne hab ich nicht“.
  • Danke an die aufmerksamen Zuhörer, die mich auf das ein oder andere Problem hingewiesen haben. Ich soweit ich mich daran erinnern konnte, hab ich die Folien entsprechend korrigiert.
  • Ich hab das Gefühl, mein Problem mit dem „äh“ ist besser geworden. Ob dem so ist?
  • Die Beispiele kamen, nach dem, was ich so gehört habe, nicht ganz so gut rüber, wie erhofft. Ich von meiner Seite aus, war mit ihnen eigentlich sogar recht zufrieden. Trotz der kurzen Vorbereitungszeit hab ich nur an einer Stelle auf ein Foobar-Beispiel ausweichen müssen (Dafür war das auch besonders schlecht 😉 ). Woran die anderen Beispiele gekrankt haben, weiß ich noch nicht so genau.
  • Feedback ist wie immer jederzeit herzlich willkommen.

Remember remember the fifth of November… I certainly do remember the fifth of November—which was last Tuesday. I don’t remember it because of the Gunpowder Plot, certainly not because of the nursery rhyme and at least not today because of V for Vendetta. Rather I once more gave my talk on principle languages. This time as a webcast to Sydney, Australia.

This is also a premiere. This is not the first time for me to present the topic. Neither it is my first webcast or my first presentation in English. But this time I have a recording. And here it is: (mehr …)

Wie jedes Jahr war ich auch diesmal wieder auf den Delphi-Tagen und hab einen Vortrag gehalten. Auch, wenn ich eigentlich gar nicht mehr so viel mit Delphi zu tun habe, ist es jedes Jahr wieder eine tolle Veranstaltung für mich. Diesmal hab ich über Prinzipiensprachen geredet. Letztendlich war das meine Masterarbeit, aber eigentlich ist das nichts anderes als das, was mich schon seit Jahren interessiert: Daumenregeln. Welche Daumenregeln gibt es, die helfen, gutes Design von schlechtem zu unterscheiden? Wie hängt das alles zusammen?

Titel: Prinzipiensprachen — Entwurfsentscheidungen treffen und darüber reden

Abstract:
Ähnlich wie Patterns sind Softwareentwicklungsprinzipien oder -Daumenregeln eine Form der Wiederverwendung von Erfahrung. Viele dieser Prinzipien sind seit langem bekannt und weithin akzeptiert (KISS, DRY, SOLID, etc.). Aber es gibt dutzende und wahrscheinlich hunderte solcher Prinzipien und viele davon sind außerhalb bestimmter Communities nur wenig bekannt. Dieser Vortrag zeigt, wie man solche Prinzipien nutzen kann um Entwurfsentscheidungen auf nachvollziehbarer Grundlage zu treffen und wie sie helfen, über Entwürfe und Entwurfsentscheidungen zu reden. Außerdem wird principles-wiki.net vorgestellt, ein Wiki, das solche Prinzipien dokumentiert, diskutiert und vernetzt.

Zielgruppe: Alle die entweder ihre Software besser strukturieren oder Kommunikation verbessern wollen.

Download: Prinzipiensprachen (Folien) (Größe: 1.75 MB; bisher 492 mal heruntergeladen)
Download: Prinzipiensprachen (Vortragsnotizen) (Größe: 1.76 MB; bisher 524 mal heruntergeladen)

Resümee:

  • Der Vortrag war ganz gut besucht. Der Raum war aber leider recht heiß und stickig.
  • Anfangs waren nur recht wenige da. Später sind immer mehr gekommen. Das liegt wohl daran, dass einige noch in der Mittagspause waren. Vielleicht hätte ich noch etwas warten sollen.
  • Von meiner Seite aus hat eigentlich alles ganz gut geklappt. Ich hab den Vortrag auch schon bei anderer Gelegenheit mit anderem Publikum gehalten. Da waren schon einige Verbesserungen eingeflossen.
  • Im Gegensatz zum letzten Mal hatte ich jetzt einen Presenter. Die Dinger sind praktisch. Ob ich das Ding richtig verwendet hab? Ich weiß nicht. Ich war trotzdem froh, es zu haben. Auch wenn sowas mehr kostet, als es eigentlich müsste. Ein paar Tastendrücke simulieren und n roten Punkt machen, ist nu wirklich keine Kunst.
  • Ich hab wieder separate Folien und Vortragsnotizen. Und ich denke, ich fahre mit dieser Strategie ganz gut.
  • Das war sicherlich einer meiner theoretischsten Vorträge. Generell hab ich ja einen Hang zu dem, was man an der Uni Praxis nennt und in der Praxis Theorie.
  • Es kamen ein paar interessierte Fragen, aber keine Begeisterungsstürme. Was ich daraus ableiten soll, weiß ich noch nicht.
  • Beim Fragen beantworten hab ich oft das Problem, dass ich erstmal meilenweit aushole und erst ganz am Schluss wieder zur Frage zurück komme. Diesmal hab ich mir explizit vorgenommen, das umzudrehen und zuerst direkt zu antworten und ggf. Hintergrund nach zu schieben. Für den Anfang hat das, denke ich, ganz gut geklappt. Ich denke, ich bin zumindest auf dem richtigen Weg.

Feedback: Wie üblich, bitte ich wieder um Feedback. Gerne auch negatives, gerne auch Kleinkram. Stimmt meine Selbstwahrnehmung von oben? Wie war mein Vortrag? Meine Gestik? Meine Aussprache? Egal: Jegliches Feedback ist willkommen. Im schlimmsten Fall lerne ich etwas daraus…

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

… 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 874 mal heruntergeladen)
Download: Schichten und Exceptions: Vortragsnotizen (Größe: 3.05 MB; bisher 1272 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.

Wie schreibt man eigentlich Software?
– Nun, man tippt einfach den Code.
Und wie weiß man welchen Code man schreiben muss?
– Äh…

– Also, wenn man plangetrieben entwickelt, hat man ein Modell der Software, die man implementiert.
Und wie kommt man zu dem Modell?
– Man schreibt es auf, z.B. mit UML.
Und wie weiß man, was man aufschreiben muss?
– Äh…
– Also, wenn man agil entwickelt, entwickelt man i.d.R. testgetrieben, d.h. man schreibst zuerst Tests und aus den Tests kann man ersehen, welches Design man zu verwenden hat.
Und wie weiß man, wie man den Testcode schreibt?
– Man benutzt ein Unittest-Framework und testet damit die zukünftige Schnittstelle.
Und wie weiß man, wie die zu testende Schnittstelle aussehen muss?
– Äh…

OK, die Antwort auf diese Frage wird etwas länger. (mehr …)

Wie im letzten Jahr, hab ich auch dieses Mal wieder einen Vortrag auf den Delphi-Tagen gehalten. Diesmal gings ums Fehler vermeiden. Man könnte auch sagen, um konstruktive QA-Maßnahmen. Egal. Jedenfalls gings um Bugs.

Abstract

„Wenn Debugging der Vorgang ist, Fehler aus einem Programm zu entfernen, dann ist Programmierung der Vorgang, Fehler in ein Programm einzubauen.“ So liest man zuweilen im Netz und manchmal ist es nur zu wahr. Stunden verbringen wir damit, umständlich einen Fehler zu suchen, den wir zuvor noch ganz mühelos einbauen konnten. Wäre es da nicht praktischer, statt uns mit Debugging aufzuhalten, das Enbugging, das Einfügen von Fehlern gar nicht erst zu betreiben? Letztendlich sind wir ja eigentlich selbst schuld: Bugs entstehen nicht aus dem Nichts. Vielmehr erzeugen wir — meist unabsichtlich — Bedingungen, unter denen diese kleinen Krabbelviecher so prächtig gedeihen. Dieser Vortrag soll zeigen, wie Bugs entstehen und was wir dagegen tun können. Eine vollständige Betrachtung des Themas kann dabei natürlich nicht erfolgen. Stattdessen wird ein Überblick gegeben, um danach einzelne Aspekte zu vertiefen.

Folien

Wie versprochen gibts hier die Vortragsfolien: Download: Enbugging (Größe: 1.14 MB; bisher 1159 mal heruntergeladen)

Ich hab wieder eine Gratwanderung zwischen vortragsunterstützenden Folien und Infos für alle, die den Vortrag nicht gesehen haben, versucht. Ob mir das gelungen ist, darf jeder selbst beurteilen (und mir am besten auch noch ein bisschen Feedback geben).

Hinweise

  • Eigentlich wollte ich noch erwähnen, dass Tony Hoare (der übrigens auch den QuickSort erfunden hat) auch dran schuld ist, dass in Pascal die geschweiften Klammern Kommentare sind. Hoare hat Vorbedingungen und Nachbedingungen in geschweiften Klammern vor bzw. hinter Code geschrieben („Hoare-Tripel„) und damit formale Verifikation gemacht. Niklaus Wirth gefiel das Ganze so gut, dass er die geschweiften Klammern zu Kommentarzeichen machte.
  • Um die Beispiele zu verstehen, sollte man sich genau angucken, wie die Bezeichner (insbesondere die Klassen) heißen. Man sollte daraus erraten können, worum es geht. Meine Beispiele waren meist allgemein bekannte Datenstrukturen (List, Map, Set) oder standen in losem Zusammenhang mit Feedreadern, HTML-Parsern u.ä.
  • „Meine Fehlerliste“ enthält viel zu wenige Daten, um hieraus schon etwas Sinnvolles ableiten zu können. Da muss ich noch mehr sammeln. Das hab ich beim Vortrag zwar schon dazu gesagt, aber es steht so explizit nicht in den Folien.
  • Was ich auch im Vortrag erwähnt hab, aber nicht auf den Folien steht: Bidirektionale Assoziationen sind starke Kopplungen. Also wenn sich zwei Module gegenseitig kennen, anstatt dass nur ein Modul das andere kennt, aber nicht umgekehrt. Man sollte deshalb zusehen, dass man möglichst nur einseitige Beziehungen hat.
  • Der Anhang enthält noch weitere Beispiele und Hinweise auf weiterführende Themen, die nicht angesprochen werden konnten.

Errata

  • Auf Folie 60 fehlt ein not. Es müsste also heißen if not FInnerList.Contains(item) then.

Bitte um Feedback

Das Feedback, das ich bisher bekommen hab, war durchweg positiv. Das freut mich. Ich will hier aber trotzdem nochmal nach Feedback und explizit auch Kritik fragen. Nur, wenn ich weiß, was ich besser machen kann, kann ich in Zukunft etwas weniger schlimme Vorträge machen… *g*

Insbesondere würde mich folgendes interessieren:

  • Hab ich verständlich geredet? War ich vielleicht zu schnell?
  • Waren die Beispiele verständlich? Nachvollziehbar? Praxistauglich?
  • Wie versteht man die Folien, wenn man sich den Vortrag nicht angehört hat?
  • Waren Thema und Inhalt angemessen? Zu theoretisch? Zu einfach? Zu schwer? Zu trivial?
  • Kann ich sonst etwas verbessern?

„Wenn Debugging der Vorgang ist, Fehler aus einem Programm zu entfernen, dann ist Programmierung der Vorgang, Fehler in ein Programm einzubauen.“ Und ich fürchte das stimmt. Debugging ist manchmal nervig, auf jeden Fall aber zeitaufwändig. Und dabei sind wir doch eigentlich selbst schuld: Mühelos bauen wir Fehler in unseren Code ein, damit wir diese dann wieder mit viel Mühe erkennen, lokalisieren und beheben können.

Schön wäre es doch, wenn wir die Fehler gar nicht erst einbauen würden. Wir tun das nicht bewusst. Man könnte das jetzt einfach als Nachlässigkeit oder „Versehen“ abtun, aber meistens ist es mehr: Wir erzeugen Bedingungen unter denen Bugs leicht entstehen. Wir tricksen und quasi selbst aus, indem wir unsere Programme so entwerfen, dass wir fast unausweichlich Bugs machen müssen, wenn wir nicht höllisch aufpassen. Uns ist das nicht immer bewusst, aber es ist so. Einige solche Bugschleudern hab ich selbst schon fabriziert.

Um dem zu begegnen gibt es IMHO drei Dinge, die wir tun können:

  1. Verstehen wie Code funktioniert, welche Probleme und Fallstricke existieren und welche Fehler man machen kann.
  2. Verstehen welche Fehler man persönlich macht.
  3. Bedingungen erzeugen, unter denen Bugs nicht so leicht entstehen oder zumindest schneller erkannt werden.

Das ist mehr oder weniger das, was ich auf den diesjährigen Delphi-Tagen in Köln erzählen will. Einen Vorgeschmack gibts schonmal hier: Download: Enbugging-preview (Größe: 383.76 kB; bisher 661 mal heruntergeladen)

Ich hab viel zu erzählen und weiß noch nicht ganz, ob ich davon noch etwas kürzen oder verändern muss. Deshalb erstmal nur das Kapitel zur Einführung. Den Rest gibts dann als finale Version nach oder kurz vor den Delphi-Tagen. Das, was ich hier zeige, ist zwar mit Abstand das langweiligste Kapitel, aber zumindest ist ein Inhaltsverzeichnis dabei, sodass man schonmal nen Eindruck gewinnen sollte, ob es sich lohnt, mir zu zu hören.

Alles in Allem werde ich nichts bahnbrechend Neues vorstellen. Das ist teilweise Erstsemester-Stoff [1], aber ich werde versuchen, aufzuzeigen, warum das wirklich praxisrelevant ist. Relevanter als ich das im ersten Semester erkannt hab. Es wird ne Menge Beispiele geben, die auch mit Abstand die meiste Arbeit gemacht haben und hoffentlich den ein oder anderen Aha-Effekt erzeugen. Mal sehen, ob mir das gelingt. Zumindest ist das mein Ziel.

Vorab kann ich schonmal sagen, dass ich den Titel geklaut hab. Und zwar von diesem sehr lesenswerten Artikel: The Art of Enbugging von Andy Hunt und Dave Thomas.

[1] OK, wirklich nur teilweise

oder: Wie man objektorientiert denkt

Abstract

Zielgruppe: OOP-Einsteiger und -Fortgeschrittene, sowie alle, die das Gefühl haben, die OOP noch nicht ganz verstanden zu haben. Ein OOP-Tutorial sollte man aber zumindest mal gelesen haben.

Die ersten Gehversuche in der OOP fallen oft recht schwer. Und in der Tat klappt das, was dabei heraus kommt, meinst mehr schlecht als recht.
Die OOP erweitert erst einmal die Möglichkeiten, Fehler zu machen. Eine der Ursachen dafür ist, dass Objektorientierung eine andere Denkweise erfordert. Ohne diese objektorientierte Denkweise programmiert man vielleicht “prozedural mit Klassen”, nicht aber wirklich objektorientiert. Und so bleiben auch die schönen Vorteile der OOP wie Wiederverwendbarkeit und Änderbarkeit aus. Wie aber denkt man objektorientiert? Dieser Vortrag stellt einige objektorientierte Denkmuster und Prinzipien vor und zeigt, dass Objektorientierung mehr ist als Klassen und Vererbung.

Folien

Das war Thema meines Vortrags auf den diesjährigen Delphi-Tagen. Die Folien gibts wie versprochen zum Download: (mehr …)