Archiv der Kategorie: Entwicklerschmiede

Neues zu Technik, Entwicklung und Programmierung

CodeCamp ’08: Tote BIESTer. Viele tote BIESTer. Sehr viele tote BIESTer.

Obwohl das CodeCamp auf einem Veganerhof gastieren durfte, gibt es jede Menge erlegten Getiers – nein, nicht zu beklagen, sondern – zu bejubeln. Viele dutzend erledigte Bugs, im Stud.IP-Jargon BIESTs genannt, säumen den Weg der furchtlosen Camper.

So ganz vollkommen makellos und fehlerfrei ist Software ja nie und im Laufe der Jahre versammeln sich in staubigen Ecken größere Mengen scheintoter Käfer, die nur darauf warten, im richtigen Moment zuzuschlagen. Vor einigen Monaten wurden die nie endenden Versuche, die BIESTer zu bändigen, aus dem in grauer Vorzeit selbstgestrickten Stud.IP-Wiki-Formularverhau in ein viel mächtigeres trac verlegt. Was noch ausstand: Mal kräftig durchfegen und in alle Ecken gucken.

Jedes einzelne BIEST, das aus den vergangenen Jahren übriggeblieben ist und das irgendwann mal jemand gemeldet hat, ist jetzt sorgfältig untersucht worden. Die meisten bewegten sich irgendwo zwischen: „Auf der Semesterferienverwaltungsseite fehlt ein Punkt“, „Manchmal funktioniert bei mir irgendwas nicht ganz richtig“ und „Ich habe eine Ausnahmesituation gefunden, in der die selten verwendete Funktion xy nicht das richtige Ergebnis liefert.“ Viele angestaubte Käfer konnten gleich aussortiert werden, weil die Verbesserungen der letzten Versionen ihnen jeden Nährboden entzogen haben. Andere ließen sich beim besten Willen nicht aus ihrem Versteck hervorlocken und wurden deshalb abgeschrieben.

Jetzt können wir nicht ganz ohne Stolz verkünden: Der Bug-Zoo ist gut aufgeräumt. Ein paar BIESTern bleibt noch der Garaus zu machen, aber wir wissen jetzt genau, wo sie wohnen. Die Verschnaufpause wird allerdings nur kurz sein. Beim genauen Hinschauen haben wir schon ein paar ganz neue Arten frisch mutierter Krabbelviecher gefunden.

CodeCamp 08 – Die Örtlichkeit

Auf dem Veganischen Larifari-Hof in Laer, in der Nähe von Münster, haben sich mittlerweile 14 tapfere Recken eingefunden, die fleißig daran arbeiten unser Stud.IP schöner, besser und sicherer werden zu lassen.
Das Essen ist lecker, die Gastgeber äußerst freundlich. Die noch von gestern stammenden Eindrücke unserer Räumlichkeiten sollen euch natürlich nicht vorenthalten bleiben.





CodeCamp ’08: Es geht los!

Wir sind da! Alle Kabel sind gelegt, Björn meldet vollen WLAN-Empfang, Nina und Tobias sind auch schon drin. Fotos gibt’s später, weil mein Handy sowas nicht kann und die Menschen mit den Kameras noch unterwegs sind. Schiefgehen kann aber nicht mehr viel. Es sieht gemütlich aus, es sieht nach Arbeit aus und es sieht nach spannenden kreativen Tagen aus. Mehr live aus dem CodeCamp später an dieser Stelle. Bleiben Sie dran!

Stud.IP CodeCamp 2008

Die meisten Entwickler haben jeden Tag mit Stud.IP zu tun. Und entwickeln das, was entweder gerade im Tagesgeschäft ihrer Hochschule benötigt wird oder ein Kunde beauftragt hat. Zeit, eigene Ideen und Projekte in Stud.IP unterzubringen bleibt da meist nur nach Arbeitsende – und da möchte man auch gerne mal was anderes tun als für Stud.IP da zu sein. Aber die ganzen schönen Ideen und Verbesserungen für immer in der Schublade belassen?

„Man müsste mal einen Programmiermarathon veranstalten“
„Oder eine Programmierparty“
„Oder wir mieten uns für einen Woche ein Ferienhaus in Dänemark und programmieren dort alle gemeinsam!“

Das sind Ideen, mit denen am Rande der Stud.IP-Tagung, der Entwicklerkonferenz oder auf dem Developerserver schon seit langem gespielt wird. Allein daran, dass sie immer wieder diskutiert werden ist zu sehen, dass ein Bedürfnis nach einem Programmier- und Funevent da ist. Bislang ohne konkrete Umsetzung.

Bislang.
Denn vor ca. einem halben Jahr fing Tobias Thelen an, Nägel mit Köpfen zu machen. Herausgekommen ist dabei das

Stud.IP CodeCamp 2008

Vom 22.-24.08.2008 treffen sich Stud.IP-Programmierer (und gerne auch solche die es werden wollen) auf dem Veganerhof „Laerifari“ in Laer bei Münster, um abseits der Zwänge des Alltags gemeinsam zu entwickeln, gemeinsam Ideen auszuprobieren, weiterzuentwickeln, zu verwerfen oder in vorher ungeahnte Richtungen laufen zu lassen. Ein paar Tage voller Kreativität und Entfaltungsmöglichkeiten.

Gesponsert wird das Ganze zum Teil vom Stud.IP e.V.

Wer dabei sein möchte, kann sich einfach auf dem Developerserver in die Veranstaltung „CodeCamp“ eintragen. Der Unkostenbeitrag für Unterbringung und Verpflegung wird ca. 30 Euro betragen, Ermäßigungen sind sicherlich auch möglich – bitte einfach im Forum nachfragen.

Lift me up!

Es gibt Dinge, die sind irgendwie peinlich und hat man sie endlich abgestellt, weiß man so recht gar nicht, ob man freudestrahlend jubeln darf. Mit sechs noch am Daumen zu lutschen gehört dazu. Oder mit knapp dreißig noch die Wäsche von Mama gewaschen zu bekommen.

Stud.IP ist jetzt 8. Daumenlutschen war noch nie ein Problem und Wäschewaschen wird Stud.IP trotz aller Funktionsvielfalt wohl niemals können. Trotzdem gibt es aber ein paar Eigenarten, die abgestellt gehören, so praktisch oder aus der Historie heraus verständlich und erklärbar sie auch gewesen sein mögen.

Ein Beispiel, das fast jeder Stud.IP-Nutzer schonmal leidvoll erleben musste: In vielen Fällen ist es nicht möglich, mit mehreren Browserfenstern oder Browser-Tabs parallel im System unterwegs zu sein. Entweder kommt dann eine Fehlermeldung »Sie haben kein Objekt gewählt« oder der Forenbeitrag landet gar in der falschen Veranstaltung.

Die Entwickler sind sich schon länger einig: Stud.IP muss auch mit mehreren Tabs einwandfrei funktionieren. Das Problem allerdings: Die dazu nötigen Änderungen ziehen sich quer durchs System und sind nicht mal eben in einem Rutsch zu erledigen. Das liegt an einem recht alten Konzept, der »gewählten Veranstaltung«. Die wird in den so genannten Session-Daten gespeichert und die gibt es pro angemeldetem Benutzer nur einmal. Die Lösung also: Fast alle Stellen, an denen Stud.IP-interne Links generiert werden, so umbauen, dass alle notwendigen Informationen direkt mitgegeben werden. Technisch nicht sonderlich aufwendig. Aber nicht mal eben nebenher zu erledigen.

Das bisherige Entwicklungsmodell verpackt alle Änderungsvorschläge in »StEPs«, das sind die »Stud.IP Enhancement Proposals«, über die diskutiert und abgestimmt wird und die bis zum nächsten Release in spätestens sechs Monaten entweder ganz oder gar nicht umgesetzt werden müssen. Aufwendige Umbauten quer durch das System sind damit kaum umzusetzen, weil die Entwicklerkapazitäten, um mehrere Versionen parallel zu pflegen, schlicht und einfach fehlen.

Jetzt tritt neben die »StEPs« ein neues Modell, die »Lifters«, das steht für »Laufende, inkrementelle Technikrenovierung für Stud.IP«. (Zugegeben, die Abkürzung ist deutlich eingängiger als die Langform.) Lifters müssen nicht bis zum nächsten Release fertig sein, sondern ermöglichen sozusagen den Umbau im laufenden Betrieb. Deshalb gilt für Lifters: Alter Code muss lauffähig bleiben, zumindest bis alle anzupassenden Stellen im System erledigt sind.

Erste Lifters sind schon formuliert und angenommen. Ganz oben auf der Liste steht, kaum verwunderlich: »Unterstützung von Tabbed Browsing«. Die Entwickler waren schon fleißig und auf dem Developer-Server kann bereits mit mehreren Tabs gearbeitet werden. In der Arbeitsansicht von Veranstaltungen funktioniert schon fast alles, der Administrationsbereich steht aber noch zur Umsetzung an.

Irgendwann ist dann alles fertig, die Entwickler vergewissern sich noch einmal, dass nicht vergessen wurde und mit dem folgenden Release kann dann verkündet werden: »Stud.IP geliftet! Daumenlutschen Tab-Verbot endgültig abgestellt.«

Alles neu macht der Mai

Ein neuer Monat, ein frisches Stud.IP-Release. Und das neue Stud.IP 1.7 bringt nun endlich auch die Möglichkeit mit, Stud.IP als einen Dienst in einer Shibboleth-Föderation zu betreiben. Tolles Wort… klingt irgendwie nach einer Mischung aus Altem Testament und Raumschiff Enterprise. Also sehr spannend. Aber was ist das nun eigentlich?

Vielleicht sollte ich als erstes ein paar allgemeine Wort zu Shibboleth verlieren. Wie man bei Wikipedia nachlesen kann, ist Shibboleth ein „vom Internet2/MACE entwickeltes Verfahren zur verteilten Authentifizierung und Autorisierung für Web-Anwendungen und Web-Services.“ Das klingt zwar alles ganz toll, aber was heißt das nun in der Praxis und was habe ich als normaler Student davon?

Im Prinzip kann man Shibboleth so auffassen, daß aus der Menge der an allen beteiligten Standorten bekannten Nutzer ein großer „Nutzerpool“ gebildet wird, der dann über Shibboleth Zugriff auf verschiedene Dienste – wie statische Web-Seiten, Wikis, Foren usw. – erhalten kann. Jeder Nutzer (egal von wo) kann sich dabei an jedem Dienst (egal wo dieser liegt) mit seiner gewohnten Kennung anmelden. Ich könnte also zum Beispiel mit meiner Osnabrücker Nutzerkennung und meinem vertrauten Paßwort einen Dienst der Uni Oldenburg nutzen. Oder ein Clausthaler Student einen Dienst der TU Braunschweig. Nun gibt es aber dummerweise zur Zeit weder in Oldenburg noch in Braunschweig einen Dienst, der eine Anmeldung über Shibboleth erlauben würde, was der ganzen Sache etwas den Reiz nimmt… Aber das wird bestimmt noch, mindestens Osnabrück hat da jedenfalls noch einige spannende Dinge vor.

Um da etwas abzuhelfen und zu zeigen, wie gut das ganze funktionieren kann, steht daher ab sofort für interessierte Nutzerinnen und Nutzer aus dem Kreis der Niedersächsischen Shibboleth-Initiative (Nds-AAI) als erstes Testsystem die Stud.IP-Installation des Entwickler- und Anwenderforums zur Verfügung. Neben der Möglichkeit zur freien Registrierung kann man sich jetzt also auch über Shibboleth direkt mit der Nutzerkennung und dem Paßwort der eigenen Hochschule dort anmelden. Nun ja, jedenfalls dann, wenn die eigene Hochschule auch bereits ihren Shibboleth Identity-Provider soweit eingerichtet hat, daß dort überhaupt Nutzer bekannt sind… Derzeit scheint das leider nur in Osnabrück der Fall zu sein, aber das wird sicher auch bei den anderen Standorten nicht mehr lange auf sich warten lassen.

Stud.IP 1.7: Getreide und Blitze

Während auf dem Developerserver schon wieder heiße Diskussionen um Features zukünftiger Versionen, eine Renovierung des PlugIn-Marktplatzes und Langzeit-Modernisierungsprojekte toben, hat eine neue Version von Stud.IP die Welt erblickt.

Hat mal wieder, ach, Schweiß und Mühe gekostet, sich aber auch gelohnt.
Meine persönlichen Highlights der 1.7:

Shibboleth
Stud.IP ist jetzt „Shibboleth Ready“. Damit kann man Nutzer einer Installation in einer anderen zulassen und somit z.B. Hochschulübergreifende Lehre anbieten. Vernetzte Stud.IPs – das wünschen sich viele Betreiber und Dozierende schon lange.

Flash-Videos
Die Möglichkeit Flash-Videos einzubinden ist ein Nebenprodukt des Campusmedien-PlugIns. Mit dem PlugIn lassen sich Flash-Filme des Institus für Wissenschaftlichen Film direkt in einer Stud.IP-Veranstaltung recherchieren und verfügbar machen. Das Angebot an Flash-Filmen im Campusmedien-Katalog wird gerade ausgebaut, was aber jetzt schon funktioniert: Flash Filme einfach im Dateibereich von Stud.IP hochladen und gleich angucken oder ein Netzvideo an einer beliebigen Stelle (Z.B. Forum, eigene Homepage) einbinden. Funktioniert genauso einfach wie das Einbinden von Bildern.

Unter der Haube
Stud.IP 1.7 bringt diesmal nicht nur, aber auch Veränderungen unter der Haube mit. Zu den in-Deep Veränderungen gehören z.B. PDO als neue Methode des Datenbankzugriffs und ein Refactoring der PlugIn-Schnittstelle. Alles wichtig, für Nicht-Programmierer wie mich aber eher unspannend.

Weitere coole Dinge
An der Oberfläche gibt es neue Dinge, die das Leben leichter oder zumindes schöner machen:
– Die überarbeitete Personen- und Veranstaltungssuche vervollständigt automatisch Suchbegrife schon während der Eingabe
– Kleinansichten von Nutzerbildern gibt es an verschiedenen Stellen im System
– Anmeldeverfahren zu Lehrveranstaltungen wurden überarbeitet
– Wikiseiten können Inhaltsverzeichnisse anzeigen
– Bei freien Stud.IPs (d.h. nicht mit einem LDAP oder einem anderen zentralen Verzeichnisdienst) kann die Neuregistrierung auf bestimmte Mailadressen eingeschränkt werden (es können sich dann z.B. nur Personen mit einer XYZ@stud.uni-dingsbums.de-Adresse anmelden), ausserdem gibt es eine Selbstbedienungsfunktion zur Anforderung neuer Passwörter

Stud.IP 1.7 ist schon seit März an der Universität Göttingen im Einsatz und arbeitet dort unter Solaris – fehlerfrei und äußerst performant.

Fazit: eine schöne, runde Version, die nicht nur unter der Oberfläche neue Wege geht. Durch die neuen Funktionen bekommt man auch als Nutzer/-in mal wieder was von den Mühen und der vielen Arbeit mit, die die Entwickler jeden Tag in das Projekt Stud.IP stecken.

Ach ja: wer jetzt noch herausfindet woher der komische Titel dieses Posts kommt, darf sich Stud.IP 1.7 kostenlos bei Sourceforge herunterladen 😉