Agenda arktur-5
Ursprünglicher Text: Erwin Flohr, 21nov06/05feb07
Vorläufige Agenda zur Arktur-5-Entwicklung
.
In den vergangenen Monaten ist die logistische Vorbereitung wesentlich vorangekommen. Es steht inzwischen eine zentrale Subversion-Entwicklungsdatenbank zur Verfügung. Sie läuft auf dem Arktur-Teamserver. Dieser stellt noch einige weitere Dienste bereit. Die jüngste Situation bei PC-Virtualisierungstechniken ermöglichte uns den Aufbau einer hoch portablen Entwicklungsumgebung (ADE). Sie dezentralisiert die Arbeit und vereinfacht den Einstieg für neue Entwickler durch vorbereitete Verfahren.
Es ist also an der Zeit, sich über den Arktur-5 Projektstart Gedanken zu machen und zu überlegen was eigentlich zu tun ist und in welcher Reihenfolge es zu tun ist, bis zu dem Moment, wo erste Testmuster vom neu geschaffenen Arktur fertig sind. Die folgenden Dinge (deren Verwirklichung übrigens teilweise schon recht weit gebracht wurde) sollten genannt werden:
1) formale Bereitstellung gemeinsamer Dienste auf dem Team-Server,
2) initialer Entwurf einer Entwicklungsumgebung,
3) beginnende Dokumentation des Teamservers und des ADE+ABS,
4) beginnende Registrierung von Entwickler(innen),
5) beginnende Gestaltung von Arbeitskonventionen und Richtlinien,
6) Ausbau der Entwicklungsumgebung mit einem untergeschobenen OS-layer,
7) initialer Entwurf der Arktur-unspezifischen Schulserver-Systembasis,
8) Spezifizierung der Arktur-Interna,
- a) Modellbeschreibung funktional unabhängiger Arktur-Teilbereiche,
- b) Deklaration der Arktur-internen system layer,
- c) Definition der Arktur-internen Schnittstellen.
- d) Deklaration der Arktur-internen Funktionsbibliotheken,
- e) Modellierung von Arktur-Basisfunktion versus Arktur-Modulen,
- f) beginnende Definition von internen Bibliotheken und Modulen,
9) beginnende Absprache von Arbeitsbereichen, bzw. Zuständigkeiten,
10) beginnender übergreifender Entwicklungstest.
Zwischenbemerkungen
Ich habe versucht, die von mir als sinnvoll erachteten Schritte gleich in eine brauchbare Reihenfolge zu bringen. Viele der Dinge müssten vom Zeitpunkt ihrer ersten Anwendung an stetig fortgesetzt werden, weshalb in der Aufzählung oben häufig die Formulierung 'beginnend' zu lesen ist. Der Punkt (8) ist eine Besonderheit. Er berührt viele Aufgaben, die sich gegenseitig bedingen. Sie müssten eigentlich gleichzeitig begonnen werden, können andererseits wegen der Abhängigkeiten nur in Folge bearbeitet werden. So würde daraus in der Praxis wohl ein Hin- und Herpendeln zwischen all den Schritten (a) bis (f).
Die eigentliche Arktur-Entwicklung, also die Gestaltung von Features und Oberflächen, habe ich mit Bedacht nicht in die Liste aufgenommen. Ich sehe es zunächst nicht als notwendig an, den einzelnen Teil-Entwicklern bzw. -Gruppen da grundlegende Empfehlungen zu machen. Gleiches gilt zum überwiegend für die Definition von Arktur-Modulen. Nur Weniges ist so zentral und unverzichtbar, dass alle Entwicklungsbereiche so betroffen wären, dass also eine gemeinsame Festlegung versucht werden müsste.
In späteren Vorschlagspapieren wäre ich bereit, zu den genannten Schritten grundlegende Entwürfe bereitzustellen, die eine Umsetzung erleichtern. Ich möchte allerdings nur so weit gehen, wie es nötig ist, um ein einfaches Bild von der Aufgabenstellung (für Laien) zu vermitteln. Auch möchte ich damit Kritiker fernhalten, die glauben, dass eine komplette Durchgestaltung nur in einem normativen Ansatz durch 'Fachleute' möglich sei. Ich halte so etwas für falsch. Es ist lediglich eine Frage der sorgsamen Zerlegung in kleinste Teilforderungen; es ist also ein vorwiegend organisatorisches Problem, keines von ungenügender Genialität oder Erfahrung! Die Zeiten, wo ein einzelner Fachmann jede komplexe Materie allein durchdenken und beherrschen konnte, sind spätestens mit Leibniz verstorben.
Erläuterung der einzelnen Punkte der Agenda
1) Beim Teamserver wurde bereits viel gute Arbeit geleistet. Das maschinelle Grundgerüst, welches die Service-Bereiche aufnehmen soll steht. Trotzdem fehlt noch so einiges. In der Subversion-Datenbank befindet sich schon ein initialer Entwurf der Arktur-Basis. Die SVN-Verwaltung dagegen muss noch konfiguriert werden. Auch andere Dienste sind noch nicht erreichbar. Eine grundlegende Nutzerverwaltung fehlt bisher. Wir werden das zunächst für jedes Autorisierungssystem getrennt von Hand machen müssen. Die für den user-Zugang nötige Firewall ist nur im Ansatz vorhanden, bei Grundeinstellung 'verboten'. Hilfreiche, vereinfachende user tools oder eine Bedienoberfläche für das handling der virtuellen Maschinen, sie sind leider noch nicht geschrieben.
Genauere Angaben, also eine erste Beschreibung, wird es hoffentlich demnächst von den Teamserver-Admins geben. Weil dies der erste Punkt meiner Agenda ist: Es ist Eile geboten, die services in Bereitschaft zu bekommen. Falls also jemand in der Lage ist, auf die Schnelle eine Firewall plus VPN-Zugang zu konstruieren, oder diverse Server-Dienste zu installieren und für die Nutzung vorzubereiten, so wäre es super, wenn er/sie sich zur näheren Besprechung bei den Betreuern des Arktur-Teamservers meldet.
2) Die erste Version der Entwicklungsumgebung, des Arktur-Development-Environment (ADE) ist bereits da. Diese hat die Aufgabe, eine parallele Entwicklung durch ungleichzeitig und verteilt arbeitende Entwicklerinnen zu ermöglichen. Natürlich soll sie auch die repetitiven Arbeitsgänge erleichtern, sie soll die Arbeit strukturieren und informative Hilfe bieten. Vor allem soll sie den Einstieg in die Entwicklungsarbeit für *jeden* Menschen zuverlässig möglich machen! Wer glaubt, in seinem kleinen Projektbereich das know how zu besitzen, sich jedoch nicht als fähig sieht, das gemeinsame Arktur-Projekt als Ganzes zu durchschauen, die oder der soll durch bereitgestellte Automatismen die Möglichkeit erhalten, sich auf die Kernaufgabe zu konzentrieren. Alles Andere wird soweit wie möglich transparent beziehungsweise es bliebe ausgeblendet.
Die ADE ist derzeit noch nicht so vollständig, dass sich damit gut arbeiten ließe. Sie zeigt aber, dass es machbar ist wie angepeilt. Das "wie" ist natürlich schon in Teilen erkennbar. Wer's ansehen möchte, wird ein VM-disk-image erhalten.
Ein eigenständiger Teil, mit der ADE eng verbunden, ist das Arktur-Build-System (ABS). Es sitzt auf dem ADE als Materiallager mit integrierten image-Generator und mit diversen zugehörigen make-Skripten. Das ABS (ent-)hält ein lokales Abbild unserer Entwicklungsdatenbank. Veränderungen an dieser lokalen Kopie würden jeweils in ein anschließend teilautomatisiert erstellbares CD-Test-image eingehen. Da das ABS mit der SVN-Entwicklungsdatenbank kommunizieren kann (und soll), ist es leicht möglich, alle eigenen Entwicklungsschritte für die Gemeinschaft verfügbar zu machen. Eine genauere Beschreibung muss Inhalt eines getrennten Textes sein.
3) Die Dokumentation der Logistik sollte idealer Weise permanent neben der Aufbauarbeit mit verfasst werden. Spätestens jetzt, im dritten Schritt, ist es aber meines Erachtens nötig, einen Rückblick zu machen und Lücken in der user-Doku zu schließen.
Bevor die nicht analog zum System bereitsteht, ist es problematisch die weiteren Schritte anzugehen. Es werden weitere Entwickler dazu kommen. Wichtige Absicht ist es doch, diesen zu helfen, anstatt ihnen das Leben zu erschweren, indem sie vor ein Häufchen Chaos gesetzt und gezwungen würden, selbiges per 'try and error' zu durchleuchten. Etwas parolenhaft formuliert: Wir wollen weitere Helfer, wir sind darauf angewiesen, dass sie ihre Begeisterung behalten, wir müssen ihnen das Leben leicht machen.
Gebraucht würde eine Handlungsanleitung für die Entwicklerin, aber genauso eine Dokumentation des rein technischen Aufbaus. Letzterer muss immer wieder erweitert und gewiss auch verbessert werden. Niemandem nützt es, wenn das nur *der* Entwickler kann, als einziger. Gewiss wäre es in dem Fall besser, gleich nochmal vorne anzufangen! Die früheren Teilarbeiten immer zu wiederholen, wenn der *eine* Entwickler gegangen ist, bringt uns nicht gut voran. Besser ist es, für ausreichend Transparenz und Eindeutigkeit zu sorgen, um etwas zu schaffen, was von allen eingearbeiteten Team-Mitgliedern gepflegt werden kann. Ich betone dies, weil's allzu gerne vergessen wird. Kryptische Ergüsse von Kreativität haben leider immer nur ein unverhofftes Ziel, und zwar den Mülleimer der Geschichte.
4) Nun könnten die Entwicklerinnen am Team-Server registriert werden. Alle erhalten einen gleichberechtigten und nach Möglichkeit vollständigen Zugang zu den Entwicklungstools, und sie tragen damit eine grosse Verantwortung. Wer sich auch um die Pflege einzelner Serverbereiche kümmern will, würde eine ergänzende administrative Zulassung für diese erhalten. Grundsätzlich ist die Akkreditierung an eine reale Mitarbeit bei der Arkturentwicklung gebunden. Wer nicht gleich bereit oder fachlich oder zeitlich in der Lage ist, eine Arbeit im Team aufzunehmen, für die/den könnte möglicherweise eine einfachere, rein leseberechtigte Zulassung erfolgen. Die konkreten Bedingungen für eine Teilnahme müssten noch geklärt werden. Erstmal lasst uns bitte unkompliziert anfangen.
5) Schon während der ersten Arbeitsbemühungen im Team wird sich herausstellen, dass es nicht gut ohne Richtlinien geht. Teils wird es gar nicht ohne gehen. Aufbauend auf den laufenden Erfahrungen, können die Team-Mitglieder nach und nach Konventionen etablieren und guidelines spezifizieren. Ich vermute, dass deren Praktikabilität immer wieder neu überdacht werden müsste. Also nur keine Angst, vorläufigen Regelungen zuzustimmen!
6) Das wichtigste Arktur-5-Entwicklungsobjekt ist für diesen Zeitpunkt noch die ADE. Sie benötigt einen auf die Entwicklungsbedürfnisse bestens abgestimmten Unterbau, das integrierte Linux-Betriebssystem (auf Basis von Debian-Etch). Sie soll schnell auf eine separate Platte installiert werden können. Alternativ soll sie nach downloading eines präformierten VM-disk-image sofort in einer virtuellen Maschine gestartet werden können.
Durch die Systemvirtualisierung wird es möglich, die ADE auf einem beliebigen Rechner zu nutzen, ohne an dessen bestehende OS-Einrichtung schwierige Bedingungen zu stellen. Es wird nur freier Speicherplatz gebraucht. Sehr interessant ist zudem der Aspekt der Gleichartigkeit aller ADEs. Der einheitliche Unterbau macht es möglich, dass Entwicklungsarbeiten portiert werden können. Es bliebe so erreichbar, dass sich die einzelnen Teilarbeiten einer Gruppe später auch wirklich ergänzen, denn alle können für eine exakt übereinstimmende Entwicklungsumgebung sorgen.
7) Eine vergleichsweise einfache Sache scheint's, die ADE um eine Arktur-Basis-Zusammenstellung zu ergänzen. Hiermit sind die Pakete und Routinen gemeint, welche die Arktur-unspezifische Grundinstallation des (Linux-) OS ausmachen.
Stehen diese Dinge bereit, so kann erstmals ein Arktur installiert werden! (Entweder neuerlich in einer VM, oder als 'chroot'-Zweig der laufenden ADE.) Der kann dann im Probebetrieb angeschaut werden, kann duch die Entwicklungsarbeit in kleinsten Schritten verändert und jeweils sofort getestet werden.
Alle Arbeiten Einzelner können über die Teamserver-Dienste quasi auf Knopfdruck zentral gesichert und von dort wieder verbreitet werden. So erhalten die aktiven Entwickler ständig eine Aktualisierung ihrer Umgebung. Sie sind auf dem Laufenden über die Fortschritte der anderen. Falls mal eine Aktualisierung Konflikte (Fehler) mit anderen Arbeiten produzieren sollte, so können diese anhand des permanenten Abgleiches frühzeitig erkannt werden.
8) Die Beschreibung einer Spezifikation ist selbst schon eine Grobspezifikation der selben Sache. Da das noch nicht erfolgen soll beziehungsweise noch nicht erfolgen kann, wird von mir jetzt nichts weiter dazu erklärt. Diese Arbeit wartet noch auf die konkret zuständigen Teilgruppen und auf ihren teamübergreifenden Austausch.
9) Erst jetzt ist an die eigentliche Entwicklung, also an die Erstellung der Arktur-Spezifika zu denken. Die Entwicklerinnen und Entwickler können sich, jede(r) nach Lust, Laune, Fähigkeit und Erfordernis, einen ihnen genehmen Teil vorknöpfen. Wir müssen natürlich darauf achten, dass für alles Wichtige früher oder später mindestens eine zuständige Person da ist! Am Anfang ist es aber weniger von Bedeutung. Es gilt zunächst Erfahrungen und Fähigkeiten zu sammeln und die einfachen Dinge anzupacken, die wir uns (schon) zutrauen. Erst danach machen wir, was danach noch gebraucht wird. Klingt doch wirklich einfach, oder?
10) Der vorerst letzte Schritt ist die immer wieder nötige Prüfung der zwischenzeitlichen Arktur-Entwicklungsstände in einem mehr oder weniger kompletten Umfeld. Dazu wird die IDE das ABS enthalten, welches 'auf Knopfdruck' ein ISO-image erstellt. Auf CD gebrannt, ist es damit möglich, einen Rechner oder eine VM einzurichten. Nun ein kleines Netzwerk dazu zu bauen, darin so zu testen, als würde ein normaler Admin in einer realistischen Schulumgebung die ersten Schritte zur Nutzung angehen, das wäre die abschließende Aufgabe in diesem Zyklus.
Schluss
Das war's soweit. Der Ablauf wird nicht nach einem statischen Plan erfolgen können. Entsprechend hoffe ich, dass sich auch andere Gedanken über das eigene und das gemeinsame Vorgehen machen werden. Es werden noch viele Entscheidungen und Absprachen nötig sein. Das wird um so besser klappen, je autonomer die Teilverantwortlichen für ihren Bereich handeln können.
