Nächste Woche ist es soweit: Die Stud.IP-Tagung 2009 findet am 30.09. und 01.10. statt. Ich freue mich schon sehr darauf, alle Admins, Betreiber und Dozierende aus ganz Deutschland in Göttingen begrüßen zu können. Mit jedem arbeiten wir gut zusammen, mit vielen sind im Laufe der letzten Jahre Freundschaften entstanden.

Alles rund um das Programm findet sich hier. Persönliche Eindrücke kann jeder über Twitter an unsere Stud.IP-Twitterwall nageln. Der Hashtag lautet #Studip09, die Wand findet sich unter http://bit.ly/4zAJzb oder in einer puristischen Version unter http://twitterwallr.com/studip

Wie es sich für Twitter gehört sind beide Dienste ab und zu mal down. Aber selten beide gleichzeitig.

Und, wie war´s?
Lustig, entspannt, produktiv – so würde ich es mal zusammenfassen. Die gAstwerker haben uns freundlich aufgenommen und traumhaft umsorgt. Das Essen war ausgezeichnet und reichlich und unsere seltsamen Wach-Krach-Schlafzyklen wurden nicht weiter kommentiert.

Obwohl von den 11 Personen nur vier programmieren konnten waren alle produktiv tätig. Es wurde getestet, Fehler behoben und Dokumentation verfasst. Eine Gruppe entwarf einen Fragebogen für eine Anwenderbefragung, eine andere überarbeitete Texte und Featurelisten für Infomaterialien und die in Kürze generalüberholte Portalseite. Vorwiegend in den Abend- und Nachtstunden malträtierten Gruppen von zwei bis vier Personen die mitgebrachte Spielekonsole, um entweder zu rocken, zu singen oder die Videspielfassung eines Familienquizes zu spielen.

Das Ende kam dann, wie immer, viel zu schnell – vermutlich hätten Teilnehmerinnen und Teilnehmer noch länge rmachen können. Für das nächste Jahr sollte überlegt werden ob es machbar ist das CodeCamp auf vier Tage auszudehnen.

Elf Unerschrockene haben sich in den Kasseler Bergen auf dem Hof der Gastwerke eingefunden um an Stud.IP zu arbeiten. Zwei Tage voll konzentrierter Arbeit, Rumspielen mit neuen Ideen, Bugfixing und evtl. auch ein wenig Spass.

Was genau gemacht wird können Interessierte über Twitter verfolgen, der Hashtag lautet #codecamp09.

Seit dem 04.06.2009 steht Stud.IP 1.9.0 (leicht verspätet) zum Download bereit.

Diese Version läuft mit lokalen Anpassungen in Osnabrück seit drei Monaten stabil als Produktivsystem und hat den Beta-Test damit erfolgreich überstanden.

Eine Liste der Änderungen zur Vorversion findet sich hier, ein Changelog steht hier zur Verfügung.

Download: Stud.IP 1.9.0

Stud.IP 1.10 ist bereits seit längerem in Arbeit, bisher gibt es ca. ein Dutzend StEPs in der Diskussion und knapp 40 TICs.

Mal ein Thema abseits von Stud.IP, aber eins das uns alle angeht: Die Zensur des Internets in Deutschland.
Vor ziemlich genau einem Jahr veröfentlichte die CDU/CSU- und die SPD-Fraktionen im Bundestag ein Schriftstück mit dem Titel:

Das Recht auf Meinungs- und Pressefreiheit weltweit durchsetzen und der Internetzensur entgegentreten

Es handelt sich um einen Antrag des Bundestages, nachdem die Bundesregierung sich gegenüber anderen Ländern für die Pressefreiheit und gegen Repressionen einsetzen soll. Unter Punkt 9 liest man:

(Der Deutsche Bundestag fordert die Bundesregierung deshalb auf,)
9. im Rahmen aller genannten Forderungen auch und insbesondere die Zensur im Internet zu thematisieren und dieser entgegenzutreten.

Unterzeichnet ist das Papier von Volker Kauder, Dr. Peter Ramsauer und Dr. Peter Struck, im Text werden Zensurbeispiele aus China und afrikanischen Ländern genannt.

Ein Jahr später steht der Bundestag kurz davor, die Zensur des Internets in Deutschland zu beschließen. Wie sonst sollte man die das Vorhaben der unkontrollierten Sperrung von Internetseiten, dass unter dem Deckmäntelchen des Kampfes gegen Kinderpornographie durchgeboxt wird, nennen?

Als Netznutzer darf einem das nicht egal sein.

Ich rufe daher an dieser Stelle alle Leserinnen und Leser dazu auf, die Petition gegen die Indizierung und Sperrung von Internetseiten zu unterstützen. Die Petition ist direkt auf der Seite des Bundestags zu finden und benötigt 50.000 Stimmen um eingereicht werden zu können. Zur Teilnahme ist eine Registrierung notwendig – nicht ganz Web2.0, ABER: Ich will mir später nicht vorwerfen lassen, dass ich nichts unternommen habe, als die Internetzensur begann.

Hier geht es zur Petition: https://epetitionen.bundestag.de/index.php?action=petition;sa=details;petition=3860

Und jetzt die Langfassung und Einführung ins Thema: Blogger Jens Scholz erklärt, warum es um Zensur geht und weshalb die Internetsperren Humbug sind. Der folgende Text wird mit freundlicher Genehmigung des Autors wiedergegeben. Zuerst veröffentlicht wurde er hier: http://www.jensscholz.com/2009/04/warum-es-um-zensur-geht.htm

Warum es um Zensur geht
Da reiben sich gerade so viele die Hände, daß man eigentlich ein beständiges Rauschen hören müsste. Die Idee, das Thema Kinderpornografie als Popanz vorzuschicken, um das nun geplante Internet-Zensursystem einzuführen war aber auch wirklich eine richtig gute. Hat das ja zuvor mit den Themen Terrorismus und Internet-Kriminalität nicht wirklich hingehauen, kann man hier spitzenmäßig mit dem Holzhammer wedeln und Kritiker einfachst diffamieren, indem man die eigentliche Kritik ignoriert und ihnen vorwirft, sie wollten die Verbreitung von Kinderpornografie schützen. Wie schnell schon der Vorwurf zum beruflichen und gesellschaftlichen Tod führen kann, zeigte man nur wenige Wochen zuvor ja schonmal anschaulich am Exempel Tauss (der übrigens natürlich nicht im Netz “erwischt” wurde, sondern über Handykontakte und DVDs per Post).
Aber ich schweife schon wieder – wie es durch die Wahl dieses Themas ja auch gewünscht ist – ab.
Denn das Problem, das die Kritiker haben, ist ja natürlich nicht, daß man den Zugang zu Kinderpornografie sperren will, sondern das Sperrinstrumentarium, das man dazu baut. Schaut man sich das an, merkt man schnell: Es geht nicht um Kinderpornos und wie man dagegen vorgeht. Ging es nie.
Es geht um die Installation eines generellen technischen Systems und die generelle Art und Weise, wie es betrieben wird: Es geht darum, daß eine waschechte, diesen Namen zu Recht tragende, Zensur ermöglicht wird. Auch wenn die zunächst gesperrten Websites tatsächlich nur Kinderpornografie beinhalten (was die Liste eigentlich extrem kurz halten müsste) wäre sowohl die Technik, die Verwaltung und sogar die Psychologie installiert, um sofort eine effektive Zensur betreiben zu können.

Technik
Die Provider sollen ihre Nameserver so umbauen, daß Webseiten, die das BKA aussucht und ihnen nennt, nicht erreichbar sind und dem Nutzer bei Aufruf stattdessen eine Sperrseite angezeigt wird. Gleichzeitig soll das BKA jederzeit abrufen könne, welche Nutzer auf Webseiten aus dieser Liste zugreifen wollten und stattdessen auf die Sperrseite geleitet wurden.
Ein normaler Internetnutzer, der seinen Nameserver nicht auf einen freien DNS-Server umstellt, sieht bestimmte Seiten nicht und erhält die Mitteilung, er wolle sich gerade Kinderpornografie ansehen. Ob das stimmt, weiß er nicht und nachprüfen darf er das auch nicht, da ja schon die Suche nach Kinderpornografie strafbar ist. Der Nutzer muss sich in diesem Moment weiterhin im Klaren sein, daß er gerade etwas getan hat, was das BKA als illegal ansieht und als Grund ansehen kann, gegen ihn vorzugehen.
Die allein schon technisch verursachten Risiken für jeden Internetnutzer sind immens, noch dazu, weil man damit auch noch eine perfide Beweisumkehr eingebaut hat: Sie müssen künftig ihre Unschuld beweisen, z.B. daß sie “versehentlich” die gesperrte Seite angesteuert haben. Viel Spaß beim Versuch, Richtern TinyUrls, iFrames, Rootkitangriffe, Hidden Scripting und so weiter zu erklären, wenn Sie überhaupt wissen, was das ist.
Die Lösung zunächst: Den Nameserver umstellen, um sich dieser Gefahr vollständig zu entziehen. Geht schnell und kann jeder.
Die Technik ist allerdings interessanterweise das kleinste Problem in dieser ganzen Geschichte. Es gibt Staaten, die in ihren Zensurbemühungen schon wesentlich weiter sind. Die Menschen dort können dennoch sowohl anonym als auch unzensiert das Internet benutzen. Das Internet ist von Nerds gebaut worden. Ein Staat kann da so viel fordern wie er will, er wird das Netz auf technischer Ebene never ever kontrollieren können.

Verwaltung
Hier liegen die springende Punkte, die das Ganze zum Zensurinstrument machen:
1. Die gesperrten Inhalte stehen auf einer Liste, die das BKA direkt und ohne Prüfungsinstanz erstellt und die die Provider möglichst ohne sie anzuschauen zu installieren haben. Es entscheidet kein Richter über den Inhalt, es überprüft keine unabhängige Institution über die Rechtmäßigkeit, es gibt keine Regelung, wie Adressen überhaupt wieder von der Liste gelöscht werden könnten. Die Polizei, die Verbrecher verfolgt, bestimmt, welcher Wunsch nach welcher Information ein Verbrechen ist. Vorab zu definieren, was ein Verbrechen ist und hinterher darüber zu entscheiden, ob ein Verbrechen begangen wurde ist aber nicht Aufgabe der Polizei.
2. Die Liste ist geheim. So lange diese Liste nicht in die Öffentlichkeit gerät kann alles drinstehen und nichts davon muss gerechtfertigt werden. Wer das in Frage stellt wird zum Verdächtigen. Wie Zensur in Reinform eben funktioniert.
3. Der Gesetzentwurf ist schwammig genug, daß das BKA im Prinzip alles in die Liste setzen kann. Da im Web jeder Inhalt nur einen Klick weiter vom letzten entfernt ist und das Gesetz möchte, daß auch “mittelbare” Seiten gesperrt werden können, kann somit de facto auch jede Seite gesperrt werden.
4. Das System soll die direkte Verfolgung von Zugriffen erlauben. es wird nicht nur gesperrt, sondern es kann auch nachgeschaut werden, wer sich die gesperrten Seiten ansehen will. Dies kann dann Anlass für verdeckte Überwachungen, Hausdurchsuchungen und andere existenzbedrohende Vorgänge sein.
Die Staatsanwälte dieses Landes üben ja seit einiger Zeit kräftig an der Vorverurteilungsfront, indem Sie inzwischen gerne mal Pressemitteilungen über eingeleitete Verfahren rausgeben und die Presse direkt zu möglichst spektakulär und öffentlichkeitswirksam inszenierten Verhaftungen mitnehmen (Zumwinkel, Tauss, Frau B.).

Psychologie
Womit wir schon beim gewünschten Effekt von Zensur sind: Die Einführung der Schere im Kopf. Die wirksame Selbstzensur, weil man nicht weiß, was eventuell passiert, wenn man zu laut und deutlich Kritik äußert. Die Geheimhaltung der Sperrliste und ihre völlige Unverbindlichkeit durch das Fehlen jeglicher Kontolle ist ein bewußt eingesetzes Instrument, um Verunsicherung zu erzeugen.
Ein anderes ist die Verknüpfung mit dem Thema Kinderpornografie, womit wir wieder am Beginn dieses Artikels wären. Man weiß ja inzwischen, daß auch nur der leiseste Ruch, man könnte eventuell irgendwas mit Kindesmissbrauch und Pädophilen zu tun haben, die Existenz vernichten kann, selbst wenn hinterher rauskommt, daß tatsächlich nichts an den Vorwürfen dran war. Wie nahezu generell nichts rauskommt. Das ist ein so extrem starkes und wirksames Druckmittel, was natürlich beispielsweise ein Herr Gorny sofort erkennt, weil sein Versuch, diese Schere im Kopf einzuführen (durch den Versuch, Filesharing als schreckliches Verbrechen zu diskriminieren), wirkungslos blieb und er sich nun an den besser funktionierenden Trigger dranhängt (indem er Urheberrechtsverletzung mit Kindesmissbrauch gleichsetzt).
Die Justizministerin gibt dann noch Tipps in die richtigen Richtungen, die natürlich prompt reagieren. Überhaupt, das mal ganz nebenbei, finde ich es immer wieder seltsam, daß Frau Zypries immer wieder als Warnerin vermittelt wird. Dabei war – so sagt sie zumindest – sie es, die den Gesetzentwurf gegenüber dem Vorabvertrag von Frau von der Leyen verschärfen ließ und dieser nun schon den Zugriff auf Stopp-Seiten verfolgen lassen will.

Um die Frage zu beantworten, warum und wann es in einer Gesellschaft überhaupt dazu kommen kann, daß ein Teil davon meint, einen solchen Eingriff vornehmen zu müssen und der andere Teil (zu dem ich u.a. mich zähle) darin ein so massives Unrecht sieht, das es zu bekämpfen gilt, kann man sich bitte den Artikel “Kampf der Kulturen” drüben bei netzpolitik.org durchlesen.

Im letzten Artikel wurde die Infrastruktur hinter den Stud.IP-Webservices vorgestellt und auf den PHPXML-RPC-Debugger hingewiesen. Heute werden wir einen einfachen  echo-Webservice schreiben, der einen zugesendeten Text einfach wieder zurück schickt. Natürlich braucht man dafür eine eigene Stud.IP-Installation zum ausprobieren. Wie man Stud.IP installiert, steht in der Installationsanleitung. Wichtig für funktionierende Webservices: Es müssen zwei Konfigurationsvariablen in der Datei config/config_local.inc.php angepasst werden:

• $WEBSERVICES_ENABLE legt fest, ob die Stud.IP-Webservices überhaupt aktiv sind. Notwendigerweise muss dieser auf TRUE gestellt werden, damit man mit den Stud.IP-Webservices experimentieren kann.
• $STUDIP_API_KEY stellt eine Art Passwort dar, mit dem in manchen Webservices geprüft wird, dass der Request authorisiert ist. Füllen Sie diese Konfigurationseinstellung mit einem langen String. Lassen Sie sich zum Beispiel einen generieren.

Ihr Stud.IP-System sollte jetzt Webservice-Requests bearbeiten. Überprüfen Sie die Endpoints:

• SOAP: http://{URL zu Ihrem Stud.IP-System}/soap.php (Beispiel: Entwicklungsserver)
• XML-RPC: http://{URL zu Ihrem Stud.IP-System}/xmlrpc.php (Beispiel: Entwicklungsserver)
• JSON-RPC: http://{URL zu Ihrem Stud.IP-System}/jsonrpc.php (Beispiel: Entwicklungsserver)

Für den SOAP- und XML-RPC-Endpoint sollten Sie die Dokumentation der zur Verfügung stehenden Methoden vorfinden.

Dokumentation der XML-RPC-API von Stud.IP

Nachdem nun alle Puzzleteile an ihrem Platz sind, kann es mit der echo-Methode losgehen. Den entsprechenden Quellcode habe ich in einem entsprechenden Stud.IP-Branch bei github.com (commit 8cd17b) abgelegt.

Eine Funktion, die ihr Argument einfach zurückgibt, sieht in PHP so aus:

function echo($string) {
  return $string;
}

Eigentlich sind wir damit schon fast fertig, damit daraus aber ein Webservice wird, müssen noch ein paar Formalitäten abgewickelt werden.

Zunächst möchte man diese Funktion sicher nicht im globalen Namensraum liegen haben. Da allerdings erst mit PHP 5.3 tatsächliche Namensräume vorhanden sind, behelfen wir uns mit einer Klasse, in der wir die Funktion als Methode einbetten:

class ExampleService {
  function echo($string) {
    return $string;
  }
}

Diese Klasse legen wir in einer neuen Datei lib/webservices/services/example_webservice.php ab.

Außerdem fallen weitere Konventionen an, denen genüge getan werden muss. Zum einen müssen die Endpoints von unserem Webservice erfahren. Dazu öffnet man die Dateien

• public/jsonrpc.php
• public/soap.php
• public/xmlrpc.php

und fügt dort jeweils in ca. Zeile 38 ein:

require_once 'lib/webservices/services/example_webservice.php';

Außerdem muss der Name unserer neuen Klasse in die Argumentliste bei der Instanzierung der Server-Objekte aufgenommen werden. Für beispielsweise die Datei soap.php fügen wir deshalb den String “ExampleService” so in Zeile 45 an:

$delegate =& new Studip_Ws_SoapDispatcher('UserService', 'SessionService',
  'SeminarService', 'ContentmoduleService', 'LectureTreeService',
  'InstituteService', 'ExampleService');

Für XML-RPC und JSON-RPC tut man das genauso.

Als nächstes Zugeständnis müssen Funktionen, die über einen Webservice zugänglich gemacht werden sollen, umbenannt und angemeldet werden. Die Umbenennung ist nicht schwer: Solche Funktionen müssen einfach auf “_action” enden. (Würde man das nicht tun, dürfte man z.B. niemals eine Funktion “list” haben, da dies in PHP ein reserviertes Wort ist.)

Die Anmeldung einer Funktion geschieht im Konstruktor der Klasse. Dort muss der Name (ohne das “_action”) und die Signatur genannt werden. Über die Signatur sprechen wir in einem zukünftigen Artikel, so dass hier nur der fertige Code gezeigt wird:

class ExampleService extends Studip_Ws_Service {

  function __construct() {
    $this->add_api_method('echo',
                          array('string'),
                          'string',
                          'example echo service');
  }

  function echo_action($string) {
    return $string;
  }
}

Die Argumente der Anmeldung (#add_api_method) im Konstruktor lassen sich so entschlüsseln:

• Der Name der Funktion lautet “echo” (ohne “_action”!).
• Der nächste Parameter enthält die Typen der Funktionsargumente als Liste. Wir verlangen einen Parameter, der ein String sein soll, so dass die Typliste so aussieht: “array(’string’)”.
• Der dritte Parameter gibt den Typ des Rückgabewertes an. Hier ist das wie beabsichtigt ein String.
• Der letzte Parameter enthält eine kurze textuelle Beschreibung der Funktion.

Und damit sind wir schon fertig. Rufen Sie einen Endpunkt auf (z.B. für XML-RPC). Dort taucht nun in der Liste unsere echo-Methode auf. Probieren Sie sie z.B. im Debugger aus. Wie zu erwarten war, funktioniert alles einwandfrei

PHP-Funktionen über die studip-ws-Bibliothek ist also ganz einfach. Wenn man von den beschriebenen, minimalen Anforderungen absieht, ist dies nicht schwieriger, als eine Funktion in PHP zu schreiben, ohne jemals XML oder SOAP gesehen zu haben.

Im nächsten Teil geht es dann um die Signaturen der Funktionen. Bis dahin viel Spaß mit ihrem neuen echo-Service.

Stud.IP-Entwicklertagung 2009 in Osnabrück

Der diesjährige Stud.IP-Entwickler-Workshop im Zentrum virtUOS der Uni Osnabrück ist vorbei. Vier aufregende Tage voller spannender Vorträge, intensiver Diskussionen und hochmotivierter Weiterentwicklungen. Inhaltliche Resumés folgen noch; hier zunächst nur einige Impressionen der letzten vier Tage.

Donnerstag, 26.3., 8.00 Uhr

Carola und Ansgar sind schon fleißig, schleppen Kisten und Kabel in den Senatssitzungssaal. Dank ihrer perfekten Vorbereitung in den letzten 14 Tagen kann ich nur danebenstehen, und, wenn Not am Mann ist, mit zupacken. Schließlich steht alles bereit, Kaffee ist gekocht und die Gäste können eintrudeln. Kaffee, Saft und Kekse werden vom Stud.IP e.V. gesponsert, so dass der übliche Hut, der bei solchen Gelegenheiten kreist, um die Unkosten zu decken, in der Ecke liegen bleiben kann. An dieser Stelle ein Dank an alle Vereinsmitglieder, insbesondere die (derzeit drei) Mitgliedshochschulen, die mit ihren Beiträgen unter anderem Entwicklerworkshops ermöglichen und motivierender gestalten helfen!

Donnerstag, 26.3., 11.00 Uhr

Konzentriertes Zuhören bei den Vorträgen

Es geht los. Knapp dreißig Teilnehmer lauschen hochkonzentiert den Vorträgen und sind jederzeit bereit, bis ins Detail nachzufragen. Ein halbes Dutzend Nachzügler lässt die Teilnehmerzahl bis zum Mittag auf stolze 35 ansteigen. Beinah jeder Vortrag, jeder Einzelworkshop ist zu kurz. Bei Stud.IP-Entwicklervorträgen gibt es keine Hochglanz-Präsentationen, dafür werden aktuellste Entwicklungen vorgestellt. Manchmal sind sie bereits im Einsatz vor Ort, manchmal halbfertig, manchmal nur Ideen. Jeder Vortragende kann sich sicher sein: Das Publikum ist hochkompetent, begeisterungsfähig und kritisch. Präsentationsmängel werden leichter verziehen als halbgare Ideen. Deshalb sind Entwicklerworkshops Spezialistentagungen. Wer ganz neu dazustößt braucht eine Weile, um sich zu ortientieren. Aber er kann sich sicher sein: Es findet sich spätestens in der Pause zu jeder Frage jemand, der sie geduldig beantwortet.

Donnerstag, 26.3., 15 Uhr

Diskussion im virtUOS-Studio

Das »Schnitzel Florida« aus der Mensa ist verdaut, es herrscht angeregte Diskussionsatmosphäre. Für die Einzelworkshops wird das Plenum geteilt und je eine Gruppe verzieht sich ins angrenzende virtUOS-Filmstudio.  Manch einer wollte vor lauter spannender Videotechnik ringsum erstmal hinter die Kulissen kriechen, musste damit aber bis zum Abend warten. Während nach 6 Stunden intensiven Arbeitens die Core-Group noch eine zweistündige Sitzung zu absolvieren hatte, konnten sich die anderen in der Uni Osnabrück herumführen lassen und Aktuelles wie Historisches über virtUOS und Schloss erfahren.

Donnerstag, 26.3., 22 Uhr

Noch gut 20 Entwickler und andere Stud.IP-Interessierte sitzen im Unikeller bei Speis und Trank und können kaum von den angefangenen Diskussionen des Tages lassen. Neue Ideen werden zusammengesponnen, Erfahrungen ausgetauscht, aber auch ganz “normale” Kneipengespräche füllen die gemütlichen Gewölbe. Für die Einen ist es willkommenes Wiedersehen, andere lernen zum ersten Mal die Gesichter und Menschen hinter den tagtäglichen Forumsdiskussionen des Developerservers kennen. Irgendwann weit nach Mitternacht ruft das Hotelbett, denn morgen steht ein weiterer Workshoptag an.

Freitag, 27.3., 9 Uhr

Große Runde am Freitagmorgen

Dass alle pünktlich um 9 auf ihren Plätzen sitzen und meiner kritischen Betrachtung der formalen Regeln beim Entwickeln und Neue-Features-Einbringen lauschen, werte ich als höchst erfreuliches Zeichen. Das persönliche Engagement der Entwickler wird selbst bei vermeintlich trockenen Themen spürbar. Hier geht es darum, wie wir alle gemeinsam weiterarbeiten und wie und ob die selbstauferlegten Regeln nicht Kreativitätshemmnis, sondern verlässliche Orientierung sein können. Weiter geht es mit einer kurzweiligen Runde, in der im 5-Minuten-Takt kleine Plugins und lokale Erweiterungen vorgestellt werden.  “Verständnisfragen sofort, Diskussion in der Pause!” muss ich die Teilnehmer ermahnen und der Zeitplan rutscht trotzdem nach hinten.

Freitag, 27.3., 14.00 Uhr

Letzter offizieller Programmpunkt: André gibt eine launige Einführung in die Stud.IP-Entwicklung. Was ist zu beachten, wo lauern Altlasten, die man verstehen aber nicht mehr weiterverwenden sollte, wie orientiere ich mich im Dschungel aus Dateien, Funktionen und Klassen? Manch Neuling wünschte sich diese Runde für den Anfang der Tagung, aber auch alte Hasen sind sich einig: Einen solchen Überblick, zumal gewürzt mit Anekdoten und persönlichen Statements können wir häufiger (v)ertragen. Jeder, selbst wenn er wie ich in den vergangenen 5 Jahren vermutlich jede Stud.IP-Ecke schonmal gesehen hat, kann noch etwas mitnehmen und an der einen oder anderen Stelle einen zusätzlichen Motivationsschub für das anschließende Entwicklerwochenende bekommen.

Freitag, 27.3., 16.00 Uhr

Entwickler-Wochenende

Der offizielle Teil ist beendet, viele Teilnehmer müssen leider schon abreisen. Aber insgesamt ein gutes Dutzend Entwickler und anderweitig an der Stud.IP-Zukunft Interessierte können und wollen noch bleiben. Nach dem erfolgreichen ersten Stud.IP-Code-Camp auf dem Veganer-Hof in Laer im vergangenen August haben die Osnabrücker Entwickler zu einem rein freiwilligen und privaten Entwickler-Wochenende geladen. Wir ziehen mit unseren Notebooks in die Besprechungsräume des virtUOS um und sofort ist wieder diese knisternde Arbeitsatmosphäre aus Laer da: “Zeig mal, was du gebaut hast…”, “Guck dir mal diese Idee an…”, “Hast du Lust, mit mir zusammen endlich mal dieses Ärgernis anzugehen…”. Satzfetzen wie diese begleiten die Platzsuche und bald wird es seltsam still. Tastaturen klappern, technische Details werden halblaut ausgetauscht und alle haben etwas gefunden, an dem sie hochkonzentriert arbeiten. Zwischendurch immer wieder etwas für alle: Was zum Vorzeigen, zum Lachen, zum Rätseln, zum Beurteilen. Dass nach 23 Uhr kein Bringdienst mehr liefert, wäre uns beinah zum Verhängnis geworden, denn kaum jemand hat noch auf die Uhr geschaut. Die meisten gehen erst nach 3 ins Hotel oder ihre Wohnung zurück, noch die Worte murmelnd: Bis gleich!

Samstag, 28.3.2009, 10.00 Uhr

Aus Kaffee wird Code

Der Start um kurz vor 10 ist noch etwas schleppend aber bald brummt und summt das Changelog im SVN wieder vor lauter Aktivität. Wie schon im letzten Jahr halten sich Aufräumen, Dokumentation verbessern und Neues-Bauen ungefähr die Waage. Draußen regnet es fast den ganzen Tag, so dass kaum jemand in Versuchung geführt wird, aus dem virtUOS zu fliehen. So geht es produktiv voran und wieder verfliegt die Zeit fast unbemerkt. “Warum ist es plötzlich so dunkel draußen?” hört man den einen oder anderen verwundert sagen.

Samstag, 27.3., 23.00 Uhr

Die Singstar-Fraktion ist wieder aktiv. Wie auch schon gestern abend wird nebenan Lied für Lied geschmettert, nur die Sänger wechseln. Nach Lust und Laune klinkt sich der eine oder andere aus, um kurz abzuschalten. Im letzten August hatten Guitar-Hero-Sessions für Laune gesorgt, für das nächste Mal ist Rock-Band schon drohend angekündigt. Bezeichnend aber für die Code-Camp-Atmosphäre: Alles findet nebeneinander statt. Jemand starrt hochkonzentiert auch den Laptop-Bildschirm, um im Editor schließlich ein Komma einzufügen und einen neuen Datenbankdump einzuspielen, während kaum einen Meter entfernt die schlimmsten Hits der 90er nachgegröhlt werden.  So geht das – dank Zeitumstellung – bis kurz vor 4. Für alle Verbliebenen präsentiert die Stud.IP-Verschönerungsgruppe noch ihr neu entwickeltes Gewand für Stud.IP, das auf große Zustimmung stößt, für alle Nichtanwesenden aber noch bis zum Herbst verschlossen bleiben wird.

Sonntag, 28.3., 10 Uhr

Die Ostniedersachsen fahren direkt nach dem Frühstück heim, so dass nur noch Osnabrücker für den letzten Tag bleiben. Dank Regens und schlechter Busverbindungen bin ich der erste, der um 10 Uhr anfängt, die Reste zusammenzufegen, Flaschen einzusammeln und Pizzakartons zu falten. Dankenswerterweise konnte der Verein auch zum Entwicklerwochenende beitragen und Verpflegung sponsern. Merci nochmal an alle Mitglieder! Den Rest des Sonntags haben Till und ich dann damit zugebracht, den Homepagebaukasten als drigend notwendige Renovierung der persönlichen Homepages in Stud.IP nochmal ein entscheidendes Stück voranzubringen. Gesungen wurde aber nicht mehr.

Sonntag, 28.3., 18 Uhr

So. Schluss. 82 Stunden Stud.IP-Entwickler-Workshop liegen hinter uns. Die Schlafpausen waren kurz, die Konzentration hoch, die erzielten Ergebnisse liegen über den Erwartungen. Die vier Tage haben mir wieder einmal gezeigt, dass die Stud.IP-Entwickler-Gemeinde besonders aktiv, aber auch besonders kommunkativ und herzlich ist. Auf der Haben-Seite stehen jetzt mehrere Dutzend behobener Bugs der Kategorie “Nicht kritisch (denn die werden immer sofort behoben), aber nervig”, eine Menge neuer Dokumentation, entscheidende Fortschritte bei wichtigen Umbauvorhaben und viele frische Impuls und Ideen, von denen wir die nächsten Monate zehren werden.

Persönlich möchte ich mich bei allen so engagiert Beteiligten bedanken. Vor allem bei Carola und Ansgar für die Organisation, beim Verein und data-quest für die finanzielle Unterstützung. Auch bei den Arbeitgebern der  Entwickler dafür, dass es für sie so selbstverständlich ist, Reisekosten und zwei volle Arbeitstage für den Workshop in die Zukunft von Stud.IP zu investieren. Und vor allem bei denen, die wieder mal Ihre Freizeit genutzt haben, um ein Projekt, das Ihnen persönlich am Herzen liegt, voranzubringen.

Die Ergebnisse und Erfolge dieser vier Tage finden Sie, lieber Leser, wie gewohnt demnächst in Ihrer Stud.IP-Installation.

Zwei Tage Entwicklertagung in Osnabrück, danach zwei Tage (freiwilliges) Entwicklerwochenende – es tut sich mächtig was.

Zur Tagung, die vom VirtUOS organisiert und vom Stud.IP e.V. unterstützt wurde, waren rund 25 Entwickler aus ganz Deutschland angereist. Viele interessante Themen standen auf dem Programm – von der Gründung des Arbeitskreises “Barrierefreies Stud.IP” über neue Workshops zu Suchfunktionen, Codeüberholungen und GUI-Verbesserungen bis hin zum “Stud.IP Kochkurs: Grundlagen der Stud.IP Entwicklung, mit einer gesunden Mischung aus frischen Zutaten und Resteverwertung” war alles dabei.

Zwischendurch tagte auch die CoreGroup und diskutierte einen Abend über neue Verfahren und die weitere Entwicklung.

Wer nach der Tagung die neuen Ideen gleich umsetzen wollte, wurde im Tatendrang nicht gebremst. Von Freitag Nachmittag bis Sonntag Nacht sitzen die Entwickler zusammen. So ein “CodeCamp” wurde im letzten Sommer zum ersten Mal durchgeführt und erwies sich als sehr produktiv. Während die Entwickler normalerweise nur über Foren kommunizieren und recht isoliert dem Tagesgeschäft nachgehen, ist auf einem Programmiertreffen Zeit sich auszutauschen, voneinander zu lernen, lange geschobene Dinge endlich zu erledigen, mit neuen Ideen zu spielen, gegenseitig die Kreativität anzustacheln und auch mal neue Dinge ganz ohne Produktivitätszwang auszuprobieren.

Da bei solchen Treffen ein Wochenende der, ohnehin knappen, Freizeit dem Projekt Stud.IP geopfert und auch gerne die Nächte durchprogrammiert wird, ist das natürlich auch anstrengend – aber der Motivationsschub durch die direkte Zusammenarbeit und die Ergebnisse sind es Wert.

Betreiber und Nutzende profitieren von diesem persönlichen, unbezahlten Einsatz natürlich auch. Die Tagung hat viele Entwicklungen angestoßen, die sich zukünftig positiv auswirken werden. Das Programmierwochenende führt, wie es bisher aussieht (ist ja alles noch in vollem Gange) zu einem 1.8.2 Release und einem sehr coolen, neuen und einfach zu handhabenden Design für die Version nach Stud.IP 1.9.

Im Stud.IP-Entwicklerforum wurde nachgefragt, wie man eine weitere Methode zur Verfügung stellen könne. In den kommenden Tagen werde ich versuchen, die wichtigsten Sachen zu diesem Themengebiet vorzustellen.

Grundsätzlich wird für die (RPC-basierten) Webservices in Stud.IP die Bibliothek studip-ws verwendet, die sich in einer üblichen Stud.IP-Installation im Verzeichnis /vendor/studip_ws/ befindet. Grundsätzlich ist diese Bibliothek die Abstraktion zweier anderer:

• PHPXML-RPC für den Zugriff auf die Webservices über XML-RPC
• NuSOAP für den Zugriff auf die Webservices über SOAP

Die Motivation für eine weitere Abstraktion über diesen schon nicht unbedingt simplen Protokollen bestand darin, bei der Implementation von Webservices möglichst wenig mit den teilweise ungewöhnlichen Details dieser Protokolle zu tun zu haben. Stattdessen war die Idealvorstellung, Methoden in Klassen in »normalem« PHP zu implementieren. Solange man sich in einer gewissen Untermenge von PHP bewegt, funktioniert das alles sehr gut.

Leider ist es für die Verwendung von SOAP unerlässlich, Signaturen für die zur Verfügung gestellten Methoden zu definieren. Aus dieser Einschränkung resultieren ein paar Eigenheiten, die unter anderem in den kommenden Artikeln vorgestellt werden sollen.

Um ein bisschen praktischen Nutzwert in diesem Artikel zu geben, soll der in der PHPXML-RPC-Bibliothek enthaltene Debugger vorgestellt werden. Wer den Debugger nicht selbst installieren möchte, kann mit genügend Vertrauen die öffentliche Demo-Version ausprobiert werden.

Trägt man dort in das Textfeld »Address« den Wert »phpxmlrpc.sourceforge.net« und in das Textfeld »Path« den Wert »/server.php«, werden einem nach Klick auf den Knopf »Execute« alle Methoden des eingetragenen XML-RPC-Servers aufgelistet. Von dort ausgehend können die Signaturen der Methoden untersucht werden oder auch tatsächliche RPCs ausgeführt werden.

Viel Spaß damit und bis zum nächsten Artikel, bei dem in einem (aktuellen) Stud.IP  eine weitere Methode hinzugefügt wird.

Der alljährlich stattfindende Entwicklerworkshop bringt die aktiven Stud.IP-Entwickler, Neueinsteiger und alle anderen an den eher technischen Aspekten der Stud.IP-Entwicklung Interessierten zusammen. In diesem Jahr findet der Workshop von Donnerstag, 26. März 2009 bis Freitag, 27. März 2009 an der Universität Osnabrück statt. Wer Lust auf mehr hat, kann ein Verlängerungswochenende bis Sonntag, 29. März 2009 anhängen.

Programm

Folgende Themen werden im Mittelpunkt des Workshops stehen:

• Gründung eines Arbeitskreises „Barrierefreies Stud.IP“
• Einstieg in die Stud.IP-Entwicklung: Workshop für Neueinsteiger und Verbesserung der Dokumentation
• Weiterführung des GUI-Redesigns
• Vorstellung lokaler Entwicklungen und Plugins und Diskussion über ihre Eignung für andere Standorte

Das genaue Programm wird am 10. März veröffentlicht, bis dahin ist der aktuelle Stand im Wiki der Veranstaltung „Stud.IP-Entwicklertagung 2009“ auf dem Developer-Server einsehbar. Weitere Vorschläge für Beiträge sind herzlich willkommen und können dort direkt eingetragen werden.

Anmeldung

Die Teilnahme am Workshop ist kostenlos. Wir bitten allerdings um Anmeldung bis zum 25. März 2009, damit wir Räume, Kaffeeversorgung etc. planen können.
Um sich anzumelden:

• Tragen Sie sich entweder einfach in die Veranstaltung “Stud.IP-Entwicklertagung 2009“ auf dem Developer-Server (http://develop.studip.de) ein. Dort finden Sie auch alle aktuellen Informationen zum Workshop und dort können Sie sich noch in die Planung einbringen.
• Oder schicken Sie eine E-Mail an kursmanager@uni-osnabrueck.de.

Verlängerungswochenende

Besonders Engagierte und Interessierte haben die Möglichkeit, zwei zusätzliche Tage Stud.IP-Entwicklung anzuhängen. Ganz freiwillig (und nicht als Teil des offiziellen Programms) laden die Osnabrücker Stud.IP-Entwickler zu einem Entwicklerwochenende im Anschluss an den Workshop ein. Unterkünfte können privat gestellt werden, gearbeitet wird im Zentrum virtUOS, Verpflegung und Freizeitprogramm gemeinschaftlich vor Ort organisiert. Auf dem Programm steht das, was die Teilnehmer mitbringen: Spannende neue Features umsetzen, Dokumentation vervollständigen, Bugs fixen, Diskutieren bis zum Morgengrauen oder einfach gegenseitiges Über-Die-Schulter-Schauen. Wer Lust hat, am Entwicklerwochenende teilzunehmen (das Dutzend werden wir sicherlich vollbekommen), melde sich bitte im Forum der Veranstaltung “Stud.IP-Entwicklertagung 2009“ auf dem Developer-Server.

Weitere Informationen

Informationen zu Anreise, Unterkunft und Ansprechpartnern finden Sie auf den Seiten des Zentrum virtUOS unter: http://www.virtuos.uni-osnabrueck.de/VirtUOS/StudIPDev09