Für das Verständnis dieses Eintrags ist es wichtig, zwei Begriffe zu verstehen:

1. Tickets. Das sind Einträge in einem internen Entwicklungswerkzeug (namens Trac), in der notiert wird, was bisher noch nicht so läuft wie es soll. Das können also Fehler sein (z. B. “Login funktioniert auch ohne Angabe eines Passworts”) oder Funktionen des Systems, die noch nicht programmiert wurden (z. B. “Suchfunktion”). Ein Ticket wird “geöffnet”, wenn es neu geschrieben wird, meistens dann, wenn jemandem der Fehler/die fehlende Funktion erstmals auffällt. Ein Ticket wird “geschlossen”, wenn entweder die Ursache für die Fehlfunktion im Programmcode korrigiert wurde – oder man feststellt, dass man ein ungültiges (“Hoppla, ich hatte mich ja nur vertippt”), doppeltes (“Oh, da hat Heinz ja vorgestern schon ein Ticket zu geöffnet”) oder nicht zu korrigierendes (“Ja, das ist so, aber das ist Absicht, weil …”) Ticket vor sich hat.
2. Commits. Das sind Änderung am Programmcode. Das kann eine Korrektur eines Rechtschreibfehlers genau so sein, wie eine neue Suchfunktion, eine komplette Umstrukturierung der Seite oder gar eine Änderung, die überhaupt keinen bzw. keinen Sichtbaren Effekt hat. Es sagt nur aus, dass zu einem bestimmten Zeitpunkt ein bestimmter Entwickler einen neuen Datenstand von seinem Rechner in den allgemeinen Programmcode (Repository) übertragen hat.

Die obige Grafik (Anklicken zum Vergrößern) zeigt die Anzahl der geöffneten, geschlossenen, noch verbleibenden offenen Tickets in bestimmten Zeitspannen an. Außerdem wird die Anzahl der Commits in diesen Zeitspannen angegeben. Am Anfang unserer Entwicklung haben wir noch mit anderen Werkzeugen gearbeitet, so dass ich bis zum 14.12.2009 keine Daten über Tickets vorliegen habe. Dieser Bereich ist blau hinterlegt und wird von mir im Folgenden nicht betrachtet. Wer sich dafür interessiert, was in dieser Zeit inhaltlich passiert ist, möge den entsprechenden Blogeintrag lesen.

Interessant wird es nun bei den grün bzw. rot hinterlegten Daten. Grün sind die Zeiträume mit denen ich – rein subjektiv und emotional bewertet – äußerst zufrieden bin, rot die, mit denen ich weniger zufrieden bin. Hierzu auch nochmal die gleichen Daten als Diagramm (Anklicken zum Vergrößern):

Woche 6: Im Zeitraum vom 15.12.2009 bis 22.12.2009 wurden alle Funktionen, die wir uns für Kunstretter wünschen in unser Ticket-System eingetragen. Aus diesem Grund gab es die sehr hohe Zahl von 58 geöffneten Tickets. Außerdem wurden wichtige Grundfunktionen des Kunstretter-Systems implementiert. Zusätzlich wurden die bestehenden Systeme entscheidend erweitert. Ganze 10 Tickets konnten geschlossen werden. Die Entwicklung verlief in dieser Zeitspanne vor allem deswegen so gut, weil zu Beginn ein Entwicklertreffen stattgefunden hat, bei dem wichtige offene Fragen geklärt werden konnten. Auch die neuen Entwicklungswerkzeuge haben sich positiv ausgewirkt.

Woche 7: Im Zeitraum vom 23.12.2009 bis zum 30.12.2009 wurde vieles entwickelt, das weniger abstrakt als das vorangegangene ist: Allen voran ist Login und Logout zu nennen. Aber auch an der Stabilität des Systems und an Grundlagen für spätere Funktionen wurde hart gearbeitet. Die hohe Zahl von sowohl geöffneten als auch geschlossenen Tickets, sowie natürlich die Commit-Aktivität spricht eine deutliche Sprache.

Woche 8: Im Zeitraum vom 31.12.2009 bis zum 07.01.2010 wurden erstmals mehr Tickets geschlossen als geöffnet – auch wenn es nur vier Stück waren ein gutes Gefühl. Viele Änderungen, die sich nicht direkt in Tickets wiederspiegelten wurden ebenfalls durchgeführt. Hier eine Liste der wichtigsten Änderungen dieser Woche insgesamt:

• Passwortsicherheit [mit Ticket]
• Projekte können favorisiert werden [mit Ticket]
• Einem Projekt zugehörige Veranstaltungshinweise werden angezeigt
• Im Benutzerprofil werden eigene Projekte angezeigt und favorisierte Projekte angezeigt
• Administrationsbereich wurde stark erweitert (Veranstaltungshinweise und Projekte administrieren)
• Letzte Fehler aus dem Login wurden entfernt [mit Ticket]
• Allgemein wurde das Projekt “präsentabel” gemacht: z. B. gibt es keine toten Links mehr [mit Ticket]

Auch wenn in der 8. Woche wenig am “großen Ganzen” gearbeitet wurde, zeigt sich hier doch, dass wir “ernten” konnten, was wir in den Wochen zuvor “gesät” haben. Relativ viel konnte mit relativ wenigen Commits umgesetzt werden.

Nun folgt die rotmarkierte Phase. Ich muss dazu sagen, dass ich vorher wusste, dass im Januar wenig entwickelt werden könnte. Ich selbst hatte zu viel mit einem anderen Projekt zu tun, ansonsten gab es bei den Entwicklern Diplomprüfungen, Probleme mit unseren Entwicklungswerkzeugen, weitere Projekte, Klausuren, Krankheit, Urlaub, Stress usw. usf. was eben oft dann bei einem kleinen Team von vier Entwicklern alles zusammen hereinbricht.

Woche 9 bis 11: Völlig unspektakulär. Durch einen Commit wurden falsch angezeigte Umlaute korrigiert. Zwei Fehler in den Entwicklungswerkzeugen konnten behoben werden, die uns bis dahin beeinträchtigt hatten. Dummerweise sind uns gleich wieder neue Fehler in unseren Entwicklungswerkzeugen bewusst geworden und wurden als Ticket eröffnet. Ansonsten eher vorbereitende bzw. Testcommits. Einige Tickets konnten wir in ihrer Beschreibung verbessern bzw. neu aufteilen.

Woche 12: Ja, die läuft eigentlich noch zwei Tage, daher auch fragwürdig, dass ich sie rot markiert habe. Kann ja noch viel passieren. Die Registrierung und die Erstellung neuer Projekte wurde umgesetzt, vorbereitende Arbeit fürs Editieren von Projektseiten.

Und die Zukunft? Die wird spannend! Denn ich bin mir sicher, dass auf die “rote Phase” nun wieder eine “grüne Phase” folgt, da die oben beschriebenen Probleme nun für die meisten Entwickler Vergangenheit sein sollten. Ich werde in den nächsten “Neuigkeiten aus dem Maschinenraum” drüber berichten.

Statistik

Eine ganze Menge hat sich im letzten Monat am Kunstretter-System getan.

Es wurden 116 Änderungen (Commits) durchgeführt, die meisten von Ju und mir. Es gibt bereits 4848 Zeilen Programmcode. An 18 der 34 Tage seit meinem letzten Blogpost wurde am Programmcode gearbeitet.

Der Rohbau – Weitere wichtige Voraussetzungen für das Kunstretter-System

• Steven hat uns im letzten Monat nicht nur wichtige Entwicklungswerkzeuge zur Verfügung gestellt, mit denen wir einen noch besseren Überblick haben, sondern auch den Logger programmiert, ein Programmteil, der es ermöglicht alle möglichen Aktionen mit Uhrzeit und Datum aufzuzeichnen und somit festzuhalten, wer wann was getan hat. Da wir es ja mit einem System zu tun haben werden, dass unter anderem auch Spenden für Künstler ermöglichen soll, ist es besonders wichtig, dass wir diese Übersicht haben und so im Notfall auch feststellen können, warum z. B. das Geld eines bestimmten Spenders noch nicht überwiesen worden ist. Ebenso sicherheitsrelevant sind Fragen wie, wer veranlasst hat, einen bestimmten Nutzer zu sperren, oder wann ein Benutzer sich ein neues Passwort zuschicken lassen hat.
• Ju hat neben unzähligen Verbesserungen und Veränderungen an den bereits erwähnten Systemen unter anderem die Erzeugung und Ausgabe von Fehlermeldungen programmiert. Ist das System überlastet? Der eingegebene Benutzername schon vergeben? Alles Dinge, die man natürlich als Benutzer wissen will. Außerdem hat er sich um die Systeme gekümmert, die Eingaben und Anfragen bearbeiten und an den Server schicken, der sie verarbeitet, sowie um die, die diese Anfragen wiederum beantworten. Natürlich haben auch die schon genannten Dokumentations- und Entwicklungswerkzeuge viele Verbesserungen erfahren.
• Ich habe einen ersten Versuch gestartet, den Rohbau des Programmcodes für einzelne Kunstprojekte zu schreiben. Außerdem habe ich am UserManager programmiert – es ist nun für Administratoren möglich, manuell Benutzer anzulegen (wichtig z. B. für die Betaphase, oder wenn die reguläre Registrierung nicht funktionieren sollte), Benutzer zu löschen, sie wieder “aus dem Papierkorb” zu fischen, Benutzern gewisse Rechte zuzuweisen oder zu entziehen, sowie Eigenschaften von Benutzern einzusehen und zu verändern.

Wie geht es weiter?

Im Neuen Jahr haben wir wieder viel vor. Nachdem wir dieses Jahr erst im Dezember richtig Fahrt aufgenommen haben, legen wir im Januar umso fixer wieder los. Geplant ist, dass die wichtigsten Stützpfeiler im Hintergrund bereits am 09.01.2010 funktionieren und sich nicht mehr allzu stark verändern sollen. Login, Logout und Registrierung neuer Benutzer sollen bis dahin ebenso funktionieren, wie der erwähnte Logger.

Bis Ende Januar sollen dann richtig viele Funktionen Schlag auf Schlag folgen, aber mehr darüber erst im neuen Jahr.

Im Namen des gesamten Teams möchte ich noch allen Besuchern und Lesern unseres Blogs frohe Feiertage und ein gutes Neues Jahr wünschen und wir haben uns bereits als Neujahrsvorsatz vorgenommen, 2010 mehr über unsere Arbeit zu berichten, per Twitter und Blog.

Während in den ersten fünf Monaten sehr genau festgelegt wurde, was wir erreichen wollen, welcher Mittel wir uns dazu bedienen wollen und wer wir überhaupt sind, wurde erst in diesem Monat mit der eigentlichen Entwicklung angefangen. Einer unserer Programmierer, Ju (^jf, der einzige der noch keinen Steckbrief hier hat ) wurde zum Leiter des Entwicklungsteams ernannt und nach ausführlichen Diskussionen darüber, welche Technologien wir einsetzen werden, wie genau die bereits erwähnte Featureliste zu verstehen ist usw. wurden die ersten Zeilen Code geschrieben.

In der Kategorie “Neues aus dem Maschinenraum” möchte ich in Zukunft regelmäßig alle 14 Tage monatlich darüber berichten, wie sich der Kunstretter-Programmcode entwickelt. Solange noch nichts sichtbares da ist, kann dieser Einblick sicherlich interessant für Außenstehende sein. Ich werde versuchen so wenige technische Begriffe zu verwenden wie möglich, keine Sorge.

Zementsäcke zählen – Ein bisschen Statistik

Diesen Abschnitt kann man überspringen, wenn man sich nicht für Zahlenspielereien interessiert. In den vergangenen 14 Tagen haben zwei Personen – hauptsächlich Ju und gelegentlich (um z. B. einen Schreibfehler zu korrigieren)  auch ich – am Programmcode gearbeitet. Steven hat dafür die Werkzeuge, die fürs Entwickeln gebraucht werden, zur Verfügung gestellt. Er wird sich später auch um das Frontend kümmern, d. h. um die Teile der Software, die man auch wirklich sehen kann (vgl. das Armaturenbrett und den Motorraum, der dann das “Backend” wäre).

In diesen 14 Tagen wurde an immerhin 7 Tagen auch Programmcode auf unseren Entwicklungsserver hochgeladen, was ziemlich genau meiner Erwartung entspricht. Es gibt bereits 405 Dateien, verteilt auf 143 Ordner, mit einer Gesamtgröße von 2,7 Megabyte. Das ist allerdings nicht besonders aussagekräftig, da dazu auch eine ganze Menge an Dokumentation, internen Daten (svn), Wartungskrempel usw. usf. gehört. Wenn ich versuche wirklich nur die relevanten Daten zu zählen komme ich immerhin noch auf 40 Dateien mit einer Gesamtgröße von 312 Kilobyte. Diese Daten wurden in 35 Schritten (Commits) zusammengefügt, von denen 19 durch Ju und der Rest durch mich durchgeführt wurden (Allerdings wie gesagt: Ich nur Tippfehler, Ju das große Ganze).

Fundamente gießen – Worauf basiert das Kunstretter-System?

Von der bisherigen Arbeit sieht man als Laie noch nichts. Sehr häufig läuft Softwareentwicklung so ab, dass man erst wochen- oder monatelang “nichts” präsentieren kann und dann auf einen Schlag, als ob man einen Schalter umlegt, plötzlich “ganz viel” da ist. Das “ganz viel” kann dann natürlich noch voller kleiner Fehlerchen stecken, aber das ist eine andere Sache.

Die bisherige Arbeit konzentriert sich auf ein Fundament, eine Basis, auf die man später gut aufbauen kann. Ziel ist, dass nachdem dieses Fundament einmal gegossen ist, es möglichst selten nochmal angefasst werden muss. An folgenden Bestandteilen wurde bisher gearbeitet:

1. Zugriff auf die Datenbank. Da Kunstretter eine große Datenmenge verarbeiten muss, ist es natürlich wichtig, auf diese zugreifen zu können, d. h. Daten zu lesen, zu verändern, zu löschen. Hier ist Sicherheit ein wichtiger Aspekt: Unser System soll die Daten ändern dürfen, aber natürlich niemand Unbefugtes.
2. Übersetzung. Wenn es irgendwann mal möglich sein soll, Kunstretter auch in anderen Sprachen anzubieten, muss schon jetzt der Grundstein dafür gelegt werden. Ein Fehler, den viele Softwareprojekte machen ist, zunächst keine Übersetzung einzuplanen und wenn später eine erwünscht ist, muss monatelang Programmcode korrigiert werden, um dies zu ermöglichen.
3. Anzeige von Seiten. Klingt trivial, ist es aber nicht. Wie genau sollen die Internetseiten von unserem Maschinenraum zum Rechner des Betrachters? (Wir verwenden übrigens XSL-Transformationen)
4. Benutzer- und Sitzungsverwaltung. Wenn sich jemand einloggt/anmeldet, dann muss das System das auch erkennen – und diesen Status (“eingeloggt”) nicht plötzlich wieder vergessen. Es muss natürlich auch möglich sein, sich wieder abzumelden. Und unsere Benutzer werden eine ganze Reihe von Einstellungen und Eigenschaften haben – von der E-Mail Adresse über das Anmeldedatum über die Frage, ob sie Nachrichten von uns erhalten wollen, oder nicht,… Diese Einstellungen und Eigenschaften müssen auch irgendwo gespeichert werden (nämlich in oben erwähnter Datenbank) – Im Falle des Passworts so gut wie möglich verschlüsselt, bei den anderen Daten muss auch darauf geachtet werden, dass kein Unbefugter sie sich ansehen kann.

An diesen vier Fundamentbestandteilen wurde in den letzten Tagen hauptsächlich gearbeitet. Sie sind noch nicht fertiggestellt, aber wir liegen gut im Zeitplan.