Tag Archives: Literatur

Probleme in OpenSource-Gemeinschaften

Ich lese zur Zeit das Buch »Producing Open Source Software« von Karl Fogel. Er beschreibt aus Insidersicht was für Probleme in OpenSource-Projekten so auftreten und wie man diese von vornherein vermeiden oder später lösen könnte. Ich finde dieses Buch sehr interessant in Bezug auf die Projekte, wo ich persönlich beteiligt bin oder die ich intensiv verfolge (eisfair, IMPULS, climm). Viele Probleme sind da weniger technischer denn sozialer Natur und es gibt interessante Parallelen zwischen all diesen Projekten und den im Buch als Beispiel herangezogenen. Vom Glanz so erfolgreicher Projekte wie Subversion lässt man sich da nur allzu leicht blenden. Es ist vielmehr so, dass die allermeisten Projekte besser laufen könnten. Das ist mir am Wochenende beim Release von Eisfair 1.5.0 aufgefallen und gerade heute noch an anderer Stelle deutlich geworden, als Oliver von F!XMBR über seinen persönlichen Frust mit FreeBSD berichtet hat.

Ich will in Bezug auf Eisfair an dieser Stelle nicht ins Detail gehen, aber ich werde das für die Vorschläge, die ich diese Woche im Eisfair-Team machen will, berücksichtigen…

Humor in Fachbüchern

Beim Studium von Fachbüchern freue ich mich immer, wenn der Autor auch ein wenig Humor beweist um den trockenen Stoff ein wenig aufzulockern. Bei meinem neuen Buch heißt es beispielsweise:

For instance, the following two identifiers are equivalent:
KoЯn
@KoЯn

Warum nicht auch mal den Namen bekannter Metal-Bands als Bezeichner benutzen? Ebenfalls schmunzeln musste ich bei dem beinahe törichten Versuch, die Lichtgeschwindigkeit ändern zu wollen:

A constant declaration is like a variable declaration, except that the variable cannot be changed after it has been declared:

const double speedOfLight = 2.99792458E08;
speedOfLight+=10; // error

Weiter hinten wird dann als Beispiel eine Klasse Astronaut benutzt. Die Instanz davon wird »forestGump« genannt, was in Kombination mit der Methode »Jump« durchaus witzig aussieht: forestGump.Jump(); *g*

C# für Ingenieure

In meinem Studium geht es auf die Zielgerade. Im Rahmen dessen beschäftige ich mich zur Zeit mit dem Microsoft Robotics Studio. Auf den ersten Blick eine interessante Sache: eine leistungsfähige Physik-Engine dabei, die sogar mit den PhysX Beschleuniger-Karten von AGEIA arbeiten kann, eine ansprechende 3D-Visualisierung aus der Spielewelt der Xbox (XNA Framework) und als Backend ein modulares System aus Services, die alle über HTTP kommunizieren – also wenn ich das richtig verstanden habe. ;-)

Die Geschichte fußt natürlich auf .NET und in den Tutorials wird man immer wieder mit der Nase drauf gestoßen, dass man doch bitte Visual Studio und C# benutzen solle. »Kann ja nicht so schwer sein«, hab ich mir gedacht und mir erstmal das einzig noch verfügbare Buch über C# aus unserer Bibliothek geholt. Die gut 230 Seiten hab ich in ein paar Stunden durchgearbeitet und bin um einige Erkenntnisse reicher:

  • Fußnoten können den Lesefluss erheblich stören.
  • Ich ärgere mich über Fußnoten, in denen Begriffe wie »Microsoft«, »Informatik« oder »Editor« erläutert werden. Ingenieure sind doch nicht dumm.
  • C# sieht C/C++ und Java sehr ähnlich.
  • Der Unterschied zwischen dynamischer Polymorphie und Interfaces ist esoterischer Natur, aber, da Java und C# keine Mehrfachvererbung unterstützen, sinnvoll.
  • Es gibt Software die besser geeignet ist, ein Buch zu schreiben als MS Word.

Die wichtigste Erkenntnis jedoch: wenn man die Grundkonzepte der Programmierung, also elementare Datentypen, Kontrollstrukturen, Algorithmen und auch OOP verstanden hat, ist die Syntax einer Sprache nur noch Nebensache und in wenigen Stunden drin. Der Umkehrschluss: um Programmieren zu lernen, kann man eigentlich eine beliebige höhere Sprache benutzen, die es ermöglicht die genannten Konzepte umzusetzen. Ob das jetzt wie in diesem Fall C# ist oder Java, Perl, PHP, Delphi, C++ usw. – eigentlich egal. Ich hab das an verschiedener Stelle schon behauptet und das heute sozusagen im Selbstversuch untermauert. *gg*