Archiv der Kategorie: Entwicklerschmiede

Neues zu Technik, Entwicklung und Programmierung

Stud.IP-Apps

iPhone6

Ein Kommentar unter einem alten Artikel hat mich darauf gebracht, dass es vielleicht nicht verkehrt ist, auch hier im Blog einmal den aktuellen Stand von Apps für Stud.IP wiederzugeben.


Grundsätzlich

1. Das Stud.IP-Projekt, also die CoreGroup und die Entwickler/-innen der Webversion von Stud.IP, stellen nur Schnittstellen bereit, bauen aber selbst keine Apps. Für eine gute Umsetzung fehlen hierfür vor allem die personellen Ressourcen. Daher werden Apps für Stud.IP von Drittanbietern entwickelt.“Apps“ im Plural, denn es gibt nicht EINE App – Für IOS, Android und Windows Phone muss jeweils eine eigene entwickelt werden. Das ist dreifacher Aufwand.
2. Jede Hochschule muss für sich entscheiden, ob sie in den Apps vertreten sein möchte. Endanwender/-innen, welche sich eine App auf Ihr Handy laden und dann feststellen, dass die eigene Hochschule darin nicht enthalten ist, können nur eins tun: Der Hochschule und dem örtlichen Stud.IP-Support schreiben, ob sie nicht die Apps freischalten können. Der Ablauf ist hier wie folgt:

Android App “Stud.IP mobil”
Die Android App für Stud.IP wird vom ELAN e.V. entwickelt. Die App kann aus dem Google Playstore heruntergeladen werden. Sie ist Open Source-Software, d.h. eine Hochschule kann auf Basis des vorhandenen Quelltextes bei Bedarf sogar eine eigene App bauen. Die Entscheidung, ob eine Hochschule in der App auftaucht, kann nur sie selbst treffen. Falls die Hochschule in der App vertreten sein möchte, dann muss sie ein Mal die Schnittstelle in ihrem Stud.IP aktivieren und die App erlauben. Im Anschluss genügt eine Mail an den ELAN e.V., und mit dem nächsten Update ist die Hochschule zur Auswahl verfügbar. Mehr Infos zur App unter: http://mlearning.elan-ev.de/

iOS-App “Stud.IP mobile”
Die iOS-App wird von der Firma 2T Apps entwickelt und kann im App Store heruntergeladen werden. Sie ist nicht Open Source, d.h. für die kontinuierliche Weiterentwicklung möchten die Entwickler einen kleinen Obulus haben. Dieser kann entweder in Form einer Lizenzierung der App an die Hochschule oder in Form eines In-App Kaufs erfolgen. Die Entscheidung, ob eine Hochschule in der App auftaucht, trifft nur sie selbst. Falls die Hochschule in der App vertreten sein möchte, dann muss sie ein Mal die Schnittstelle in ihrem Stud.IP aktivieren und die App erlauben. Im Anschluss kann 2T Apps kontaktiert werden, die die Schnittstelle prüfen und fertig einrichten sowie die Hochschule in der App hinzufügen. Mit dem nächsten Update ist die Hochschule dann auch in der iOS App verfügbar. Mehr Infos zur App unter: http://www.studip-mobile.de

Stud.IP Mobile Skin (Windows Phone, Blackberry, alle anderen Mobilgeräte)
Stud.IP Mobile ist ein kostenfreies Plugin, dass jede Hochschule bei sich installieren kann. Ruft man dann mit einem Mobilgerät sein Stud.IP auf, bekommt man eine reduzierte, aber auf kleinen Touchdisplays einfacher zu benutzende Oberfläche. Das funktioniert auf allen Geräten im mobilen Browser.

Zukünftige App-Entwicklung
Grundsätzlich ist jeder eingeladen eine App für Stud.IP entwickeln. Die Schnittstellen sind dokumentiert und stehen zur Verfügung. Das Entwicklerforum für Fragen und zum Austausch von Erfahrungen mit der App-Entwicklung findet man unter http://develop.studip.de.

Wer den Namen “Stud.IP” in der App nutzen möchte, muss seine App vom Stud.IP e.V. zertifizieren lassen. Nur Apps, die in Punkto Datensicherheit, Datenschutz und Usability die Ansprüche von Stud.IP erfüllen, dürfen sich auch so nennen.
Mehr Infos und Kontaktdaten gibt es im Stud.IP-Portal: http://www.studip.de/apps/
Wenn sich Hochschulen gerne unverbindlich informieren möchten, können Sie mich gerne über bohnsack@data-quest.de ansprechen.

Teil 2 von Stud.IP 3

Sommerpause? Welche Sommerpause? Nur weil vorlesungsfreie Zeit ist, alle Bundesländer gleichzeitig Ferien haben und gefühlt JEDER im Urlaub ist, heißt das noch lange nicht, dass auch bei Stud.IP Sommerpause ist.

Aktuell befindet sich Version 3.1 im Betatest an der Universität Göttingen. Die 3.1 ist der zweite Teil der neuen 3er-Linie von Stud.IP. Nachdem die 3.0 riesige Veränderungen unter der Haube mitgebracht hat, ist in der 3.1 die Oberfläche komplett modernisiert worden. Bei so vielen Umbauten bleibt es nicht aus, dass sich Fehler einschleichen. Um die zu finden, veranstalten data-quest und Stud.IP e.V. gerade eine Fehlerjagd in Göttingen. Alle Studierenden und Lehrenden der Uni können Fehler melden und haben dafür die Chance ein iPad oder Amazon-Gutscheine zu gewinnen.

Bei data-quest rotiert die eine Hälfte der Belegschaft gerade darum, die 3.1 rund zu machen, die andere Hälfte rotiert um die Vorbereitung der Tagung. Täglich trudeln Pakete mit Tagungszubehör ein, letzte Abstimmungen mit Lieferanten, Caterern und Tagungscrew passieren. Die Tagung wird groß werden, mindestens genauso groß wie die rote „3“, die gestern geliefert wurde und gerade die Büroräume ziert…

Foto3

Noch nicht für die Stud.IP 2014 angemeldet? Dann schnell hier nachholen: http://www.studip.de

Stud.IP 3

130827_Studip-3_Frei klein

Mit neuen Versionsnummern vor dem Komma machen es sich die Entwicklerinnen und Entwickler nie einfach. „Wollen wir das wirklich? Sind wir schon so weit? Sollten wir nicht noch dieses Feature umsetzen, hier was entschlacken und dort noch was polieren und bis dahin die Version 2.5.1.2-b oder so nennen?“ – solche Diskussionen werden sinngemäß in der Community geführt.

Wir sind den Schritt jetzt gegangen. Wenn man nämlich mal ein Stück zurücktritt und sich ansieht, was sich seit der letzten großen Versionummer, der 2.0, alles getan hat, stellt man schnell fest, dass seitdem kaum ein Stein auf dem anderen geblieben ist. Das Design hat sich recht deutlich verändert, viele Funtionen wurden entschlackt, nicht genutzte Features entfernt, sinnvolle Erweiterungen eingeführt und ganz neue Bereiche sind entstanden. Im letzten Jahr ist dann noch ein besonders dicker Brummer umgesetzt worden: Die Anmeldeverfahren wurden komplett überarbetet. In der Summe war das jetzt letztlich so viel Veränderung, dass wir beschlossen haben, dass es nun an der Zeit ist, die 3er-Ära von Stud.IP einzuläuten.

Die neue Stud.IP Version ist die 3.0, und sie markiert in vielerlei Hinsicht einen Meilenstein in der Stud.IP-Entwicklung. Dieser Meilenstein zeigt große Entwicklungen an, ist aber nicht als Abschluss, sondern als Einstieg zu verstehen.

Durch das Zusammenwirken der Stud.IP-Hochschulen, des Stud.IP-Vereins, des ELAN e.V.s, des eCult-Verbundprojekts und der data-quest GmbH konnten große Entwicklungen umgesetzt und zwei häufig benutze Bereiche komplett neu geschrieben werden. Die Anmeldeverfahren, eine äußerst wichtige und sensible Komponente, wurden von Grund auf neu gedacht. Entstanden ist dabei ein Editor, mit dem sich Anmeldeverfahren zu Sets zusammenstellen lassen. Die Möglichkeiten gehen dabei weit über das hinaus, was Stud.IP bisher konnte (zum Beispiel Härtefallregelungen berücksichtigen), alles lässt sich leichter bedienen und ist einfacher zu erweitern.

Der andere große Bereich sind die Ankündigungen, die früher durch umständliche Bedienung an der Grenze zur Unbenutzbarkeit waren wenn verschiedene Bereiche gleichzeitig mit News versorgt werden sollten. Das Ankündigungssystem wurde ebenfalls von Grund auf neu gebaut und glänzt nun durch einfache und intuitive Bedienung.

Außerdem gibt es noch eine Vielzahl von Neuerungen, die aber an der Oberfläche erst einmal nicht unmittelabr sichtbar sind. Das haben wir uns für die nächste Version aufgehoben, die ein ganz neues Look & Feel mitbringen wird. Bei der Entwicklung der 3.0 standen die Bedarfe der Hochschulen und Einrichtungen im Vordergrund, bei der kommenden Version dreht sich dann alles um das Design und die User Experience. Die 3er-Ära von Stud.IP wird noch einige Überaschungen bieten – die 3.0 ist nur der Anfang.

Stud.IP mobile / Stud.IP App

Man kann die Überschrift im wahrsten, englischen Wortbegriff deuten: Es bewegt sich was. Endlich, möchte man sagen. Die Rede ist von Stud.IP auf mobilen Endgeräten. Sowohl als App als auch vernünftig aufbereitet für mobile Browser. Aber der Reihe nach.

Der Grund, warum es bislang keine App gibt, liegt darin, dass Stud.IP Open Source Software ist. Das ist einerseits super, weil jeder dran mitarbeiten kann und die Software frei von Lizenzkosten ist. Das ist andererseits auch schlecht, weil man es so viel schwieriger hat, Entwicklungen, die man gerne hätte, voran zu bringen. Entweder finden sich ein oder mehrere Personen oder Einrichtungen, die bereit sind die Entwicklung personell oder finanziell zu stemmen, oder es passiert – nicht viel. Das ist auch dann der Fall, wenn sich wirklich ALLE einig sind, dass man ja gerne eine App hätte – aber niemand bereit ist dafür Geld auszugeben oder daran mitzuarbeiten.

Mitarbeiten kann man an einer App und generell bei Stud.IP durchaus auch dann, wenn man nicht programmieren kann (bin ich selbst ja das beste Beispiel, ich schreibe im Zweifel Newsletter und Hilfeseiten). Man kann z.B. eine Umfrage konzipieren und auswerten, in der erfragt wird, was Studierende sich von einer App erwarten. Funktions- und Bedienkonzepte müssen erarbeitet werden. Design für Bedienoberflächen und Icons muss gemacht werden, undundund. Das alles lässt sich natürlich großartig als Haus-, Bachelor oder Seminararbeit machen. Stud.IP selbst wurde auch von Studis und Lehrenden erfunden, zur Verbesserung der Lehre. Hier gäbe es also die Möglichkeit, den ursprünglichen Stud.IP-Spirit weiterzutragen! Es ist übrigens noch nicht zu spät: Wer mitmachen will, schreibe mir bitte eine Mail an bohnsack@studip.de

So, JETZT aber zu den wirklichen Nachrichten:

1. Es gibt ein neues Plugin zur Verbesserung der Darstellung in mobilen Browsern.
Bisher war Stud.IP fummelig zu bedienen, mit viel Scrollen und Zoomen und Pinchen. Das wird durch diese Erweiterung etwas besser. Sie kann keine Wunder bewirken und wird gerade ständig verbessert, aber sie ist besser als der Normalzustand. Das PlugIn muss in Stud.IP installiert werden, und zwar von den Systemadministratoren. Das Plugin findet man auf dem Stud.IP-PlugIn-Marktplatz unter http://plugins.studip.de

2. Es gibt eine Stud.IP-App
Ernsthaft. Es gibt eine App für IOS-Geräte, die sich gerade in der Entwicklung befindet. Tobias Tiemerding, Student aus Oldenburg, hat sich hingesetzt und einfach mal angefangen zu basteln. Dann hat er Kontakt zu den Stud.IP-Entwicklern aufgenommen, und die haben ihn nicht nur mit offenen Armen empfangen, sie haben ihm auch Services gebaut, die er für seine App braucht. Aus dieser tollen Zusammenarbeit ist eine App entstanden, die schon brauchbare Dinge kann und schon echt gut aussieht. Aber nicht vergessen: Das ist noch eine Baustelle und bis sie im App-Store zu haben sein wird, kann es noch ein wenig dauern. Aber man kann sie jetzt schon ausprobieren, allerdings nicht mit einem „echten“ Stud.IP, sondern mit einem Entwicklungsserver.

Wer sich selbst einen Eindruck verschaffen und Anregungen einbringen möchte, kann sich registrieren. Ich zitiere aus den News auf www.studip.de:

Zur Distribution der Vorabversionen nutzen wir den Service von testflightapp.com. Neue Versionen der Applikation können hiermit zeitnah und einfach getestet werden. Melden Sie sich für die Verteilung auf der folgenden Webseite an: http://tflig.ht/skQoEK . Nachdem Sie sich registriert haben öffnen Sie bitte die Webseite http://testflightapp.com/login auf Ihrem Testgerät (iPhone, iPad oder iPod Touch) und geben Sie Ihre vorher festgelegten Zugangsdaten ein. Registrieren Sie im Anschluss Ihr Gerät. (Sollten Sie sich schon bei testflightapp.com registriert haben überspringen Sie bitte diesen Schritt).

3. Es gibt einen Workshop zur App-Entwicklung
Im Mai gibt es in Göttingen einen Workshop für alle, die bereit sind an Apps mit zu entwickeln. In Göttingen erklären erfahrene Designer und App-Entwickler worauf es zu achten gilt, wie sich die unterschiedlichen Plattformen unterscheiden und wie man anfängt. Mehr Infos gibt es unter http://studip.de/veranstaltungen.

Über die Portalseite unter http://studip.de/news oder unseren Twitteraccount @studip_news kann man sich auf dem Laufenden halten – beides wird signifikant öfter aktualisiert als dieses Blog. Denn bei Stud.IP bewegt sich ganz viel.

Ergebnisse CodeCamp 2009

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.

Stud.IP-Webservices Teil 2

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:

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

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.

82 Stunden Stud.IP-Entwickler-Workshop

Stud.IP-Entwicklertagung 2009 in Osnabrück

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

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

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

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

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

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.

Stud.IP-Webservices Teil 1

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:

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.

Servicerelease: Stud.IP 1.8.1

Seit dem 16.02. steht Stud.IP 1.8.1 zum Download bereit.

Die Stud.IP-Entwickler nennen die Zwischenschritte zwischen den großen Versionsveröffentlichungen „Service Releases“.
„Service“ hört sich immer ein wenig nach Dienstleistung an, nach nice-to-have – aber nicht lebensnotwendig. Stud.IP 1.8 funktioniert ja auch so.

Das ist sicher richtig, trotzdem sollten alle Betreiber unbedingt ein Update auf Stud.IP 1.8.1 durchführen. Neben rund 60 kleineren und 2 kritischen Bugs wurden auch zwei, kürzlich bekannt gewordene, Sicherheitslücken geschlossen. Diese waren nicht hoch kritisch und hatten auch nichts mit personenbezogenen Daten zu tun, trotzdem ist es wichtig, sie zeitnah zu schließen.

Eine Liste der behobenen Bugs findet sich hier, ein Changelog steht hier zur Verfügung.

Download: Stud.IP 1.8.1

Großer Dank gebührt Elmar Ludwig, der das Servicerelease zusammengestellt hat. Und das, während die Arbeiten an Stud.IP 1.9 auf vollen Touren laufen.