Und klar könnten wir uns das zur Gewohnheit machen neue Mitarbeiter vorzustellen – da hier nur kleine und große Persönlichkeiten arbeiten, würde dies sicher niemand langweilen…(; Bei Sven gibt es jedoch einen besonderen Blog-Grund: Pentabarf.
Aus den Tiefen der (u.a. Dresdner) Coderszene enstand vor einiger Zeit diese geniale Software mit dem strangen Namen. Siehe: Diskordianismus?, aha! …recherchiert, und wieder was gelernt. Vor allem dass diese Jungs wohl nicht nur coden können, sondern auch humoristisch/intellektuell punkten. Um den Sinn und Unsinn des Ausdruckes “Pentabarf” zu verstehen, braucht man nämlich genau das – bin beeindruckt (:

Den ersten kleinen Auftrag hat Sven gleich mitgebracht – das Setup und Hosting von Pentabarf für den tazkongress nächstes Jahr. Da freuen sich die verkappten Revoluzzer bei Tschitschereengreen. Mit dem Spruch “links blinken, rechts abbiegen” möchte ich mich von jeglichen politischen Statements (durch Verwirrung) distanzieren und damit zum Ausdruck bringen, dass Pentabarf mindestens genauso gut für klassisch-konservative Kongresse taugt. Bei Interesse, Fragen, Beratungsbedarf einfach kontaktieren.

Achso, ganz vergessen.. ein kurze Briefing zu Pentabarf in Stichwörtern:
Open-Source Konferenzplanungssoftware:
» Submission System: Redner können ihr Vorträge einreichen
» Zeit- und Raumplanung
» Inhaltliche Abstimmung (kollaberatives Arbeiten an Dokumenten)
» x-beliebige Exportfunktionen
» eigenes Bewertungssystem
» Account-Management
» etc. pp
Mehr dazu auf pentabarf.org, u.a. auch Referenzen.

Und für die technisch Interessiert- und Versierten: It’s Ruby (:

» maximale Zeilenbreite: 80

» maximale Anzahl Zeilen: zwischen 120 und 2000

» CodeInhalte: saubere Trennung nach MVC bzw. Pattern, nur gültigen Code

» Kommentare: Feste Syntax, Block Komments, 1-6x Umfang des kommentierten Quelltextes

» Struktur: optisch durch Kommentare kennzeichnen

» Dateikopf: Inhalt, Datum, Ersteller/Brarbeiter

» Funktionskopf: Inhalt, Parameter inkl. Beschreibung, Documentor Standards nutzen, Rückgabewerte dokumentieren

» Intendation: maximal 5 Schritte

» Klammern: korrekt intendiert, keine eigene Zeile vs. eigene Zeile

» Leerzeilen: kennzeichnen zusammengehörige Strukturen, einheitliche Verwendung!

» Methodenlänge: <40 bis < 80 Zeilen

» Naming Conventions inkl. Kommentare: einheitlich, nach Projektstandard

» Charset: UTF8

» Tabs/Spaces: Spaces bevorzugt, aber immer einheitlich

» Definition, Deklaration: getrennt, einzeilig wenn identisch

» Code Strukturen (optisch erkennbare Muster): zusammenfassen, wenn identisch oder gleichartig formatieren

Spannende Diskussionen gab es bei zwei Punkten: zum einen stand die Hypothese im Raum, dass wenn immer man innerhalb einer Funktion eine Leerzeile einfügen will, man lieber direkt eine neue Funktion für den folgenden Code schreiben sollte. Darüber hinaus kam das alte Thema Spaces vs. Tabs auf.

Im Zuge des Workshops habe ich ein paar Fragen an die Anwesenden gestellt und war überrascht, dass über 80% der Anwesenden schon umfangreiche Programmiererfahrungen, z.T. auch in grösseren Teams, hatten und dass ca. 50% aller Studenten in ihrem Arbeitsumfeld direkte Coding Guidelines definiert haben. Mein Eindruck nach den verschiedensten Diskussionen mit den Studenten hinterlässt dabei den Eindruck, dass die Mehrzahl der Anwesenden in der Summe einen überdurchschnittlich guten Code schreiben dürfte. Was entweder an der Auswahl der Teilnehmenden oder der Ausbildung der HTW Dresden liegt. Hier darf man spekulieren .

Weiterführende Links zum Thema Code Design liefer ich morgen in einem extra Artikel kurz nach.

Insgesamt war der Workshop optimierungsfähig. Die einzelnen Gruppen mit Vorschlägen zum Thema Code Design hatten zu viel Redezeit, so dass sich sicherleich diverse Anwesende schnell langweilten. Andererseite war die Beteiligung deutlich über meinen Erwartungen, so dass die Gruppengrösse tiefere Diskussionen (ich wäre gern auf bestimmte Details näher eingegangen) verhindert. Fazit: Es bringt nichts, wenn die Hälfte der Leute sich nach 1,5 Stunden langweilt und man dennoch zu flach auf der Oberfläche der Themen kratzt. Hier werde ich mir also zur nächsten Veranstaltung etwas einfallen lassen.

Chris Kaula brachte der interessierten Runde anhand eines Mini-Blogs die Vorzüge von Django nahe. Wir konnten live verfolgen wie Chris den Blog in kürzester Zeit aufsetzte – fetzt! (:

Zu Gast waren neben 3 Teammitgliedern vier Studierende der TU Dresden. Das Feedback war rundum gut: Wissen teilen, guter Vortrag, Django-Interesse geweckt, gerne wieder –> Ziel erreicht! Und nebenbei wurden noch unsere schönen Räumlichkeiten bestaunt – da freut man sich doch.
Dank an der Stelle an Seto fürs Beamer-Ausleihen!

Die Folien finden sich hier zum Download: 11-2009 Allgmeine Praesentation TTS HTW – Neue Werkzeuge.pdf

Das Fazit: die Präsentation kam sehr gut an. Habe ein nettes Kompliment von einer anwesenden Professorin zum Vortrag erhalten . Darüber hinaus geb es ne Menge Fragen und ich musste nach 50% Inhalten und 75% Zeit den Turbo einschalten. Alles in allem hoffe ich, dass es die Erwartungen erfüllt hat und einen Einblick in aktuelle Trends und die Arbeitsweise von Tschitschereengreen vermittelt hat.

Die vielfältigen Fragen waren sehr spannend und wären es sicher wert tiefere Diskussionen hierzu zu führen. Hier ein paar Beispiele:
* In der sich so schnell verändernden Welt der Webtechnologien: welche Rolle wird Java hier zukünftig spielen? Vor allem jetzt wo Google, das im den Web Toolkits verwendet, wird es da einen neuen Aufschwung geben?
* Was bedeutet diese schnelle Veränderung für die Lehre? Was ist wenn, die heute vermittelte Inhalte in 3-4 Jahren, wenn die Studenten fertig sind, nicht mehr relevant sind? (Grossartige Frage eines Professors/Professorin)
* Wie passen die aktuellen Web-Sprachen mit Java-Enterprise-Applikationen zusammen?
* Was passiert, wenn in Ihrem Unternehmen ein Entwickler ausfällt?
* etc… spannend, spannend die Themen

Zum Abschluss habe ich noch wie versprochen, zwei Veranstaltungen vorgestellt, welche wir weiterführend umsetzen könnten. Das Interesse war vor allem für das Seminar: Code Esthetics am grössten. Die erste Veranstaltung wird daher am 3.12.2009 um 17.00 stattfinden und je nach Bedarf aller 2 Wochen wiederholt.

Ich kenne das aus der eigenen Erfahrung. Vor allem, wenn man an sein Ziel kommen will, der Bug eigentlich nur nervt, dann ist man sehr oft dabei “intuitive Abkürzungen” zu nehmen. Das das sehr gefährlich ist und nur teilweise zum Erfolg führt, hat mich die eigene Coding-Praxis gelehrt. Denn so gut wie meine Fehleranalyse, war dann auch mein Code. Sprich, wenn die Probleme nur intuitiv bekannt sind, dann kann der erarbeitete Bugfix ebenfalls nur intuitiv richtig sein. Dass damit bereits die Grundlage für den nächsten Bug/-fix gelegt ist, erschliesst sich sicherlich jeden.

Bei der Arbeit als Projektmanager habe ich dabei zwei Szenarien erlebt: a) den Entwickler, der mit einer Software arbeitet (Open Source, Closed Source) welche Ihm nur zu einem bestimmten Prozentsatz bekannt ist. Zusätzlich erschwert wird das Thema, wenn die Sprache/Entwicklungsumgebung nicht 100%ige Nachvollziehbarkeit aller vom Code ausgeführten Aktionen sicherstellt. Hier habe ich Intuition von Entwicklern sehr zu schätzen gelernt. Wo bei es hier gigantische Unterschiede gibt, grundsätzlich gilt, wie im Wikipedia-Artikel nachlesbar: je mehr Arbeitserfahrung , desto besser die auf Intuition basierenden Ergebnisse.

b) Das zweite Szenario, ist z.B. die Arbeit mit Werkzeugen wie Python o.ä. Hier ist gewährleistet, dass jeder einzelne Schritt des Codes nachvollzogen und geprüft werden kann. Hier ist es immer besser, sich ausschliesslich rational dem Problem zu nähern und dieses Schritt für Schritt einzugrenzen. In der Regel ist man schneller, als mit Anzahl x intuitiven Versuchen den Fehler zu identifizieren.

Ein weiteres Problem ist mir vor allem bei der Arbeit mit Scriptsprachen aufgefallen. Die vermeintliche unmittelbare Überprüfbarkeit des Ergebnisses verleitet (bin of genug selbst Opfer gewurden) sich auf ein Try-and-Error-Coding zu verlassen. Wenn diese zusätzlich auf durch Intuition basierden Bugfixes verlässt, ist die Gefahr gross, das der Fehler nur oberflächlich behoben, aber nicht entgültig entfernt wird.

Grundsätzlich bin ich daher ein grosser Freund von Entwicklungssystemen (Sprache, IDE, Tools) welche grosse Transparenz bei der Softwareentwicklung sicherstellen. PHP (hier vor allem das Zend Studio) liefert hier eine recht gute Grundlage. Python ist allerdings hier deutlich besser, da die Sprache an sich besser lesbar und inhaltlich stringenter aufgebaut ist.

Python bietet darüber hinaus deutlich mehr Tools zur Nachvollziehbarkeit des Codes, als PHP. Das kann aber aus meiner Sicht auch ein Nachteil sein. Denn die Arbeitsweise des Softwareentwicklers (v.a. das rationale Analysieren vs. der bewusste Einsatz intuitiver Fähigkeiten) sind sicherlich deutlich entscheidender für das schnelle Finden der korrekten Fehlerursache. Die Tools können das nur unterstützen.