Bücher für Software Entwickler #4

CLR via C#, 4th Edition

Vermutlich das Referenzbuch für C# mit einem wirklich tiefen Blick in die praktische Anwendung aller Komponenten. Für einen Einsteiger in die Sprache vermutlich etwas zu anspruchsvoll, aber jeder mit den nötigen Grundkenntnissen kann mit diesem Werk sein Wissen vertiefen und hat bei Fragen eine vollständige Referenz zum Nachschlagen.

Artificial Intelligence for Games

Wer sich mit künstlicher Intelligenz in virtuellen Spielen beschäftigt, kommt an diesem Buch fast nicht vorbei. Es gibt dem Leser eine ausführliche Übersicht über alle Themen der künstlichen Intelligenz und erklärt diverse Lösungen für fast alle Probleme in diesem Zusammenhang. Es sollte definitiv vor den ersten Experimenten mit künstlichen Intelligenzen gelesen werden, kann aber auch später als Referenz herangezogen werden.

Bücher für Software Entwickler #3

Java EE 6 with GlassFish 3 Application Server

Eine ausführliche Einführung in die Funktionen von Java EE 6 macht dieses Buch zu einem guten Einsteigerbuch für jeden der seine Java Kenntnisse um den Enterprise Bereich erweitern will. Es erläutert alle wichtigen Themengebiete wie Entities und Facelets und gibt leicht verständliche Beispiele. Der Themen orientierte Aufbau erlaubt auch die Verwendung als Referenzbuch, wenn man sich beispielsweise speziell über Rest-Sevice noch einmal schlau machen möchte.

Der Termin: Ein Roman über Projektmanagement

Wie der Name bereits vermuten lässt, handelt es sich hierbei in der Tat um einen Roman. Dieser erzählt auf angenehme Art und Weise die Geschichte eines größeren Projekts und wie das Projektmanagement dieses erfolgreich gegen alle Widrigkeiten verwaltet. Der Leser bekommt dabei sehr direkt anhand der “Beispiele” vermittelt, worauf zu achten ist und welche Standardfehler immer wieder gemacht werden. Für jeden interessant der gewisse Management Verantwortung trägt und sei es auch nur auf Teamlevel. Ein zusätzliches Sachpunkt zum tieferen Verständnis ist aber sicher noch notwendig.

Bücher für Software Entwickler #2

Der nächste Teil der Serie, diesmal nur mit einem Buch:

Effective Java: A Programming Language Guide

Ein schönes Nachschlagewerk, dass jeder Java Entwickler zumindest einmal gelesen haben sollte. Es zeigt alle Tipps und Kniffe und Eigenheiten von Java auf leicht verständliche Art und Weise. Der Aufbau ermöglicht ein schnelles Nachschlagen von einzelnen Problemfällen. Beispielsweise wird äußerst ausführlich auf die beiden Methoden equals() und hashCode() und ihren Zusammenhang eingegangen. Sollte bei keinem Entwickler, der sich ernsthaft mit Java beschäftigt, im Regal fehlen. Im Gegensatz zu vielen anderen Büchern ist und bleibt es auch sehr lange aktuell.

Python 3 Bindings für FluidSynth

FluidSynth ist ein in C geschriebener Synthesizer basierend auf dem SoundFont 2 Format. Er ist Plattform unabhängig und besitzt eine relativ einfache Schnittstelle zum Erzeugen von Tönen. Für Python gibt es daher auch eine Reihe von Bindings. Sie erlauben einen mehr oder weniger direkten Zugriff auf die Funktionen der FluidSynth Bibliothek. Zwei bekannte Implementierungen sind pyFluidSynth von Nathan Whitehead und pyfluidsynth von MostAwesomeDude. Dabei handelt es sich um Bindings für Python 2.x. Leider scheint es bis heute aber keine Bindings für Python 3.x zu geben. Aus diesem Grund habe ich mich entschieden auf Basis der beiden erwähnten Bindings eine eigene Implementierung unter dem Namen pyfluidsynth3 zu entwickeln. Es handelt sich dabei zum größten Teil um eine einfache Portierung der beiden Bindings von Python 2 zu Python 3. Der größte Teil des Codes basiert auf der Implementierung von MostAwesomeDude, kombiniert mit Anregungen von Whiteheads Version. Zusätzlich wurden einige Features erweitert, wie eine komplette Schnittstellen Dokumentation, ein besseres Finden der Library und bessere Rückgabewerte für Funktionen. Das Projekt wurde auf GitHub in meinem Repository tea2code veröffentlicht. Es steht unter der LGPL und darf gerne von jedem verwendet werden.

Entfernt das I aus Interface

Ein wichtiger Grundsatz der Software Entwicklung ist die Programmierung gegen ein Interface. Ohne in die Tiefe zu gehen heißt das, dass man nie eine spezifische Implementation einer Klasse als Grundlage für seinen Code verwendet. An Stelle dessen verwendet man ein Interface und versteckt auf diese Weise die eigentliche Implementierung. Hintergrund ist das einfache Austauschen der Implementierung gegen eine andere Klasse. Ein zweiter Grundsatz, welcher sich aus dem obigen ableitet, ist das verstecken der Implementierung. Der Anwender in Form eines Programmierers soll sich keine Gedanken darüber machen, wie eine Klasse ihre Arbeit erfüllt, er soll nur Wissen, dass sie es tut. Oder mit anderen Worten: Er muss nur ihre Schnittstelle, sprich API, sprich ihr Interface kennen. Dieser zweite Grundsatz impliziert aber noch mehr. Er sagt nämlich auch, der Anwender einer bestehenden Klasse soll nicht wissen, wie die Klasse oder besser das Objekt diesen Grundsatz umsetzt. Das heißt den Programmierer muss es eigentlich nicht interessieren, ob er gegen ein Interface oder eine konkrete Klasse programmiert, solang er und das Objekt die öffentliche Schnittstelle einhalten. Diese zweite Implikation wird aber leider von vielen verletzt. Ich selbst habe lange Zeit zu dieser Gruppe gehört. Und zwar gibt es einen Quasi-Standard bei vielen Software Entwicklern den Namen eines Interface mit einem I zu beginnen. Man erhält dann beispielsweise ein Interface IEvent und die Implementierungen KeyBoardEvent, welche von IEvent ableitet. Ursprung für diese Konvention ist die ungarische Notation, welche lange Zeit Anwendung fand, inzwischen aber eher als verpönt gilt. Besonders bei Windows Entwicklern ist sie allerdings nach wie vor beliebt und zumindest das I für Interface Teil des offiziellen Code-Styles.  Dadurch ist die Verwendung des Präfix I auch in anderen Sprachen häufig anzutreffen. Neben dem Verletzen des zweiten Grundsatz gibt es noch weitere praktische Gründe, die gegen die Verwendung eines Präfx für Interface sprechen.

  1. Nicht alles was mit I beginnt, muss auch ein Interface sein. Ist die “Schnittstelle” ID3Info  ein Interface oder eine konkrete Klasse?
  2. Entgegen dem ersten Grundsatz und teils in (unbewusster) Favorisierung des KISS-Prinzips werden Klassen zunächst ohne Interface entworfen. Ein Nachteil von zusätzlichen Interfacen ist immer die größere Anzahl an Klassen-/Interface-Dateien und solange es nicht mehrere Implementierungen gibt, spricht auch nichts dagegen. Aber was wenn sich diese Annahme später als falsch herausstellt? Im Fall der Präfix-Konvention müsste man jetzt ein Interface erstellen und sämtliche Objekte gegen das Interface austauschen (und nicht nur die konkrete Objekt Erzeugung). Ohne Präfix wird einfach der alte Klassenname zum Namen des neuen Interface und die Implementierung erhält einen konkreten Namen, der die Art der Implementierung widerspiegelt. Das hat auch zur Folge das ein dritter Grundsatz der Software Entwicklung eingehalten wird. Und zwar besagt er, dass in einem guten Design bestehender Code nicht mehr angefasst werden muss.

Eine noch detailliertere Erklärung dieser Thematik findet sich hinter folgenden Links:

Bücher für Software Entwickler #1

Mit diesem Artikel werde ich eine neue Serie über Bücher zum Thema Software Entwicklung starten. In dieser Serie werde ich meine jeweils aktuelle Lektüre vorstellen und so eine möglichst nützliche Auswahl an guten Büchern bieten. Als Referenz/Anregung für neuen Lesestoff nutze ich momentan folgende Seiten:

Kommen wir zu den Büchern:

Code Complete – A Practical Handbook of Software Construction

Mit diesem Buch verschafft man sich meiner Meinung nach den besten Überblick über alle Gebiete der Software Entwicklung. Angefangen von Code Style,  über Design Patterns bis hin zu Architekturentscheidungen. Ein absolutes Must Read.

Head First Design Patterns

Eine schöne moderne Übersicht über die wichtigsten Design Patterns und wann und wo man sie anwendet (und wann und wo nicht). Gegenüber Design Patterns: Elements of Reusable Object-Oriented Software hat es den Vorteil einen aktuelleren Stand widerzuspiegeln und bietet mit Beispielen in Java leicht verständliche Anwendungsfälle für alle Design Patterns.  Wenn man nur eins der beiden Büchern lesen kann, würde ich dieses bevorzugen.

Design Patterns: Elements of Reusable Object-Oriented Software

Der Klassiker der Welt der Design Patterns und ihrer übersichtlichen Einordnung. Aufgrund des Alters enthält es einige Design Patterns, welche häufig nur in sehr speziellen Fällen verwendet werden sollen und teilweise fehlt mir die kritische Einsicht, welche Head First Design Patterns enthält. Das beste Beispiel ist das Singleton-Pattern. Nur all zu leicht führt man mit diesem Pattern Globale Variablen über eine Objekt-Orientierte Hintertür wieder ein. Ansonsten ist es jedoch wunderbar zu lesen, wenn auch Beispiele in Smalltalk sicher nicht jeden ansprechen werden, aber dafür gibt es auch noch Beispiele in C++.

Software Systems Architecture – Working With Stakeholders Using Viewpoints and Perspectives

Ein Buch weniger über Software Entwicklung als viel mehr über den Schritt davor: Die grundlegende Software Architektur. Es gibt einen guten Einblick über die verschiedenen Elemente (Interessengruppen, Software, Hardware, Sicherheit, Budget…), welche man beim Entwurf einer Architektur beachten muss. Der Großteil des Buches beschäftigt sich allerdings mit Werkzeugen der Software Architektur und ist entsprechend eher trocken. Ich würde es demjenigen empfehlen, der plant früher oder später auch in diesem Bereich aktiv zu werden. Entwickler können mal reinschauen um zu verstehen, womit sich der Architekt im Team überhaupt beschäftigt und wie man ihn bei seiner Arbeit und letztendlich sich selbst helfen kann, aber auch nur wenn man sonst nichts zu lesen hat.

Dive Into Python 3

Ein Buch, dass sich mit den Neuerungen von Python 3 beschäftigt und vor allem auch die Unterschiede zu Python 2 hervorhebt. Ich würde es nicht als erste Lektüre für einen Python Einsteiger empfehlen, wer jedoch bereits über dem “Hello World” Stadium hinaus ist und/oder Erfahrungen in anderen Sprachen hat, wird hier einen guten und tiefen Einblick in die Fähigkeiten von Python 3 erhalten. Mit diesem Buch wird  auch die Portierungen von Applikationen auf Basis von Python 2 zu Python 3 leicht verständlich erklärt.

The Book of Qt 4: The Art of Building Qt Applications

Ein schönes Buch in deutsch und englisch, dass einen wunderbaren Einblick in das Qt Framework in Version 4 gibt. Ich bin mir nicht sicher in wie weit es noch für Version 5 nützlich ist, aber zumindest damals war es ein fantastischer Lesestoff. So ziemlich alle Aspekte des Frameworks werden ausführlich besprochen und mit echten Beispielen erklärt.

Linker Problem #1

Beim Bauen von FluidSynth mit MinGw wurde ich mal wieder an die wichtigste Lektion beim Compilen und Linken erinnert. Immer darauf achten, dass die komplette Toolchain aus entweder 32bit oder 64bit Versionen besteht. Niemals mischen. Die Toolchain umfasst dabei unter anderem Compiler, Linker und mögliche Libraries. Vergisst man leider all zu schnell, wenn man längere Zeit nichts mehr in diese Richtung unternommen hat. Den Fehler erkennt man nicht immer sofort, da er sich häufig dadurch äußert, dass der Linker nicht die Libraries findet, obwohl sie ganz klar vorhanden sind. Während man sich dann einen Wolf nach dem vermeintlichen Fehlen des Include/Lib-Pfades absucht, ist in Wahrheit der kompilierte Code in einer anderen Version als die Libraries und somit korrekterweise inkompatibel.

Notiz an mich selbst: Bloß nicht nochmal vergessen.