Archive for the ‘web 2.0’ Category

Stills from 3d animation

Sunday, June 7th, 2009

Taking a break from developing (after many days with 10-15 hours of Grails I realized there are some other parts to life, though) I spent this day collecting and rendering some stills of our 3d animation we did as part of the last semester.

The idea / the story

Our basic story idea was to show a student of our course, in a (of course ;-) ) boooring lecture. He’d be switching on his notebook (where my MacBook Pro became a short part) and then just dream on on his way through the web. We had focused on all the parts that make the web (in our eyes ;-) )… you’ll see them very soon – once we are permitted to upload the video onto Youtube.

Scribbles / Renders

The following pictures where all mostly modelled, animated and rendered by me – there are many other parts to the animation which I don’t want to claim property for. Despite that I was one of the guys who was always around in the other groups, helping out where questions or problems raised. It was the thing that was most fun in my studys until now. And it kept us working on it for nights and nights!

So here are some impressions of all the effort which has gone into the animation – all the iterations over creative ideas, building things from scratch, re-inventing, putting in some funny ideas… all that stuff. And in the end, I think I can honestly say I’m very proud of it – just wait for the final animation which will be out soon.

That’s it (I just discovered the cool gallery feature WordPress has ;-) ), stay tuned for the animated version (wich is all done, just waiting for some minor legal things before uploading it to Youtube)

Bewertungsplattform

Monday, May 4th, 2009

Die letzten beiden Semester arbeitete ich mit meinen Kommilitonen Jan Laermann, Norman Schemel und Lino Strümann an einem Projekt im Rahmen der Vorlesung Projektmanagement. Unser Kunde war der Studiengangsleiter Herr Mester. Sein Ziel war es, eine generische Bewertungsplattform anzulegen. Es sollten mit minimalem Aufwand Bewertungsportale zu beliebigen Themen aufgestellt werden können.

Projektplanung

Im ersten der beiden Semester kümmerten wir uns maßgeblich um die Projektplanung, dies ergab am Ende ein Pflichtenheft, das vom Kunden unterzeichnet wurde und uns im Folgenden als Basis für unsere Entwicklung diente.

Projektumsetzung

Im zweiten (diesem) Semester des Projekts ging es dann an die konkrete Implementierung der Software, sowie den geplanten Rollout. Wir hatten uns aus diversen Gründen dafür entschieden, für die Entwicklung das Grails-Framework zu benutzen.

Zur weiteren Entwicklungsumgebung gehörten bei uns folgende Komponenten:

  • ein Subversion-Repository zur Versionierung und Zusammenarbeit
  • Trac als Task-Tracking-Tool um die einzelnen Aufgaben und auch Bugs zu koordinieren
  • anfangs ein MediaWiki welches dann durch das Wiki von Trac abgelöst wurde
  • eine lokale Testumgebung (von Grails bereitgestellt) und zum Ende auch ein serverseitiger Test mit Tomcat und MySQL

Da wir aus vergangenen Projekten leider nicht sehr gute Erfahrungen mit Lösungen aus der BA-Infrastruktur gemacht hatten (dass das SVN-Repository z.B. nicht von außerhalb der BA erreichbar war, oder häufig nicht funktionierte) wählten wir meinen eigenen Server um die Tools dort zu hosten. Eine meiner Grundaufgaben war deshalb die Verwaltung dieser Entwicklungsumgebung, damit das Team verlässlich damit arbeiten konnte.

Außerdem arbeitete ich danach als Java/Groovy-Entwickler an den Backend-Funktionen mit Grails um die Logik zu implementieren.

Abgabe

Unserem Kunden war es gegen Ende des Projektes leider nicht mehr möglich die entsprechende Live-Umgebung zur Verfügung zu stellen. Deshalb konnten wir die Bewertungsplattform nicht aus unserer Test-Umgebung auf das Live-System übertragen.

Aus dem geplanten Roll-Out wurde so die Abgabe aller Entwicklungsressourcen, inkl. SVN-Repository, Trac-Backups etc. so dass z.B. ein anderer Jahrgang dieses Projekt dann inklusive einer (ursprünglich geplanten) Werbekampagne online stellen kann.

Erfahrungen

Dies war für mich ein weiteres großes Software-Projekt innerhalb unseres Studiengangs. Man sieht, dass mich meist mehr die Technik reizt, als gestalterische oder statistische Arbeiten. Da wir den Prozess der Erstellung durch das Trac ebenfalls sehr einheitlich ablaufen lassen konnten, lief in diesem Projekt wieder einiges besser planbar als in früheren Projekten (jedes Mal kommen ein paar weitere Tools und Erfahrungen hinzu bei denen man sich fragt wie man das bisher nur ohne sie geschafft hat).

Die Arbeit mit Grails war im weitesten Sinne sehr angenehm. Das Grundgerüst der Anwendung war innerhalb von ein paar Stunden erstellt und einsatzbereit. Ein paar Bereiche sind noch naja… meines Erachtens nicht unbedingt produktiv einsetzbar – z.B. Web Flows hatten bei mir auch in anderen Projekten bisher noch einige Stabilitätsprobleme. Und die Doku reicht auch von supermegatoll bis mittelprächtig. Fragen wie “wie bekomme ich den info-Loglevel für Controller oder Services?” ließen sich nur durch langwierige Recherche im Internet beantworten. Aber es gibt auch Bereiche wie die Konfiguration mittels der jeweiligen “DSLs” (z.B. für die DataSources) oder die Groovy-Builder, mit denen die Arbeit eine reine Freude sein kann, sofern die Doku sie entsprechend erläutert.

Wir hatten sehr viel Zeit zur eigenen Einteilung zur Verfügung, so konnten auch die einzelnen Entwickler ihren eigenen Rhythmus leben (meine Commits kamen z.B. meist in der Zeit von 8-20 Uhr, andere zwischen 14-2Uhr ;-) ). Das wurde auch durch die strikte Trennung von Grails ermöglicht, weshalb z.B. die einen weiterhin an den Layouts arbeiten konnte, während andere die Logik implementierten.

Ausblick

Ich werde mich mit Sicherheit weiterhin mit Grails beschäftigen. Für die schnelle Erstellung von Web-Anwendungen eignet es sich hervorragend. Integriert sich auf Wunsch auch gut in bestehende Umgebungen (eigenes Mapping für Persistenz z.B.) bietet viele sinnvolle Features – und noch mehr durch die immer weiter wachsende Zahl von Plugins.

Ein Task-Tracking-System wie Trac ist ebenfalls sehr sinnvoll, allerdings fand ich es während dieses Projekts teilweise etwas umständlich zu bedienen – und es lief (Python, Apache, Ubuntu, VPS, wer auch immer dafür verantwortlich ist…) leider lange Zeit nicht unbedingt flink.

Auf eine Versionsverwaltung kann ich selbst bei Ein-Mann-Projekten nicht mehr verzichten!

Pie-Menu mit JavaScript

Tuesday, October 21st, 2008

Nach einer Weile Ruhe kann ich nun mein neuestes “Projekt” vorstellen, das mich hauptsächlich nun während des Studiums nicht mehr loslässt: Es handelt sich dabei um eine Pie-Menu Implementierung in JavaScript und XHTML.

Gefesselt haben mich Pie Menus nun seit Längerem. Denn neben meinen Interessen für die technische Seite der aktuellen Entwicklungen interessieren mich auch neue oder ungewohnte, selten genutzte Benutzerschnittstellen.

Vorteile eines Pie-Menus sind dabei:

  • einfachere Bedienung, da nur grobe Richtungen angegeben werden müssen, anstatt auf kleine Icons etc. zu klicken
  • bessere Raumausnutzung (ringförmig) statt linearer Menüs
  • intuitive Benutzung nach kurzer Gewöhnungsphase

Die Implementierung ist momentan noch ziemlich simpel, aber schon darauf ausgelegt, mehrere solcher Menüs in einer Seite unterbringen zu können.

Die Idee: im Markup werden ul-Elemente mittels der Klasse “jspie” gekennzeichnet, für diese wird je li-Element ein Eintrag im Menü erstellt.

Es lässt sich dabei nicht nur zu URLs navigieren, sondern z.B. auch JavaScript-Code ausführen, sodass den Aktionen alle Möglichkeiten offenbleiben.

Wem “Pie Menus” nichts sagen, dem wird folgende “Illustration” vielleicht weiterhelfen:

Für eine feinere Implementierung als die momentane werde ich wohl noch einige Zeit brauchen, aber der Prototyp dafür steht bereits und kann grob verwendet werden. Eine Demo-Seite werde ich in den nächsten Tagen einrichten. Dort wird dann auch der Quellcode veröffentlicht werden.

Die Darstellung des Menüs wird im Laufe der Zeit natürlich noch optimiert werden.

EDIT:

Wenn man eine Weile in einem Projekt drinsteckt läuft man gerne Gefahr, viele Aktionen die für den Laien schleierhaft erscheinen mögen als völlig klar und “trivial” anzusehen. Um nochmal auf die Funktionsweise eines Pie-Menu zurückzukommen:

  • das Pie Menu wird vom Benutzer aktiviert (hier durch Gedrückthalten der Maus länger als 300ms)
  • innerhalb des nun dargestellen Menüs wird eine Aktion ausgewählt – meist durch Bewegen der Maus in Richtung der Aktion (hier mit gedrückter Maustaste – eine Aktion wird nur gewählt, wenn der Mauszeiger über den Rand des Kreises hinaus bewegt wird)
  • durch Loslassen der Maustaste wird die gewählte Aktion bestätigt und ausgeführt – soll keine Aktion ausgeführt werden lässt man die Maus folglich innerhalb des Kreises los

Nun noch ein (akademisch außerordentlich wertvoller) Link zum Wikipedia-Artikel: Pie Menus in der Wikipedia

Selectors API in Opera Acid3 Build

Thursday, August 14th, 2008

Kurzes Update:

Auch bei Opera bemüht man sich natürlich die neuen Web Standards zu unterstützen und so gibt es seit Ende März ein Build das eine 100/100-Completion im Acid3-Test erfüllen soll (näheres im Entwicklerblog).

In diesem Build ist auch eine native Implementierung des Selectors API eingebaut. Die mit dem von mir aufgebauten Test-Szenario Ergebnisse zwischen 16 und 32ms erzielt.

Diese Werte lassen sich leider nicht 1:1 mit den anderen ermittelten vergleichen, da sie in unterschiedlichen Test-Umgebungen (Core2Duo 1.8 statt Core2Duo 2.6 – Windows XP statt Mac OS X) entstanden sind.

Firefox 3.1a testet Selectors API

Saturday, August 9th, 2008

Laut John Resig wird in Firefox 3.1 mit der nächsten Gecko-Version ebenfalls eine native Unterstützung für das Selectors API eingebaut sein. Ich habe mir eine Nightly-Version von Firefox 3.1 (Minefield 3.1a2pre) für Mac OSX geholt und sie über meinen kleinen Test-Parcour geschickt. Die Ergebnisse sprechen für sich. Im Vergleich zur Javascript-Implementierung via Base2.DOM zeigt sich hier ein Bild ähnlich dem in Safari 3.1:

  • beim Test mit querySelectorAll fällt die Zeit von 235ms im Mittel auf 25ms
  • bei querySelector sind es nun 17ms statt vorher 151ms

Damit erreicht Firefox 3.1a zwar nicht ganz die bisherigen Spitzenwerte von Safari 3.1 (11ms/8ms) holt aber mächtig auf.

Auch bei Opera schläft man nicht und so gibt es seit Ende März ein Acid3 build von Opera das ebenfalls eine native Implementierung des Selectors API besitzt. Auch dafür werde ich die Performance testen, sobald ich dazu komme.

Gleichzeitig arbeite ich an einer neuen Version des Benchmarks um alltagstaugliche Testergebnisse zu erbringen. Die Arbeit an meinem eigenen kleinen Tool zur Nutzung des Selectors API steht momentan ein bischen hinten an.