Dieser Blog flattr-t

In eigener Sache: Dieser Blog versucht sich an Flattr.

Flattr ist ein Micropayment-Dienst auf freiwilliger Basis. Das funktioniert so: Beliebige Inhalte wie Blogposts, Bilder, Videos usw. können mit Buttons von Flattr versehen werden. Das ist so ein Button:

So einer klebt auch an diesem Blogpost. Klickt der Blog-Besucher auf den unteren Teil des Buttons (da, wo "Flattr" drauf steht), dann bewertet er diesen Blogpost, er flattr-t ihn. Die Zahl im oberen Teil des Buttons erhöht sich dann. Sie zeigt an, wie viele Besucher den Blogpost ge-flattr-t haben. Ein Klick auf die  Zahl bringt den Besucher auf eine Flattr-Seite mit Statistiken.

Was genau heißt es jetzt, etwas zu flattr-n? Hier kommt das Micropayment ins Spiel: Wer flattr-t, verteilt Geld. Vom Flattr-nden zum Ge-flattr-ten. Das funktioniert nach einem ausgeklügelten System: Wer sich bei Flattr anmeldet, muss zunächst sein Konto füllen, mindestens EUR 2 im Monat. Danach darf er auf Flattr-Buttons klicken. Seine Klicks werden von Flattr gezählt. Am Ende des Monats werden alle seine Klicks aufsummiert. Sein Monatsbudget wird durch die Summe all seiner Klicks in diesem Monat geteilt. Dieser Betrag wird dann an jeden von ihm Ge-flattr-ten ausgezahlt bzw. dessen Konto gut geschrieben.

Was? "Nicht einfach", sagst Du? Okay, hier ein Beispiel: Du hast auf Deinem Flattr-Konto ein Monatsbudget von 2 EUR angegeben. Im Laufe des Monats flattr-st Du 100 Blogpost, Videos usw. Am Ende des Monats ist damit so ein Klick 2 EUR / 100 Klicks = 0,02 EUR pro Klick wert. Wenn Du in diesem Monat auf diesen meinen Blogpost den Flattr-Button geklickt hast, dann bekomme ich auf mein Konto von Dir für diesen Monat genau 0,02 EUR gut geschrieben. Hättest Du nur einen einzigen Beitrag ge-flattr-t - diesen vielleicht? :) - im Monat, dann würde der Ge-flattr-te von Dir die vollen 2 EUR bekommen. Flattr verdient dabei, behält von jeder Konto-Gutschrift 10 % ein.

Lohnt sich Flattr-n? Wohl eher nur für die großen Blogs. netzpolitik.org hat eine Bilanz für Juni veröffentlicht, und da sah's wohl ganz nett aus. Aber nichts umwerfendes. Auf jeden Fall nicht mein Motiv, Flattr auf diesem Blog einzusetzen. Meine kühnsten Träume werden wahr, wenn ich etwas das raus bekomme, was ich rein gesteckt habe.

Warum Du flattr-n solltest? Um Danke zu sagen oder um jemanden zu belohnen für Inhalte, die Du gut findest. Das Ding ist freiwillig, keiner zwingt Dich. Alternativ twitter drüber. Oder erzähl's Deinen Freunden. Flattr ist für mich auch nur eine weitere Art, das gute Wort zu verteilen. Mir geht's um Feedback, und Flattr ist ein aktueller Feedback-Mechanismus.

Noch ein Grund zu Flattr-n: Um zu geben, wenn Du nimmst. Du musst Dich bei Flattr anmelden, um ge-flattr-t zu werden oder selbst zu flattr-n. Wenn Du also empfangen möchtest, dann bist Du automatisch in der Lage, selbst zu geben. Und das freiwillig: Wer's mag, der zahlt, wer's nicht mag, der zahlt nicht. Meine Traum-GEZ. Und wenn das bedeuten würde, das die Online-Werbung zurück geschraubt würde... ja, okay, man wird ja noch mal träumen dürfen.

Mein Grund zu Flattr-n: Ich wollt's gerne mal ausprobieren. Die Flattr-Buttons tauchen immer öfter vor meiner Surf-Nase auf. Und da wollte ich endlich mal drauf klicken. Und wenn ich mich dafür schon angemeldet habe, dann kann ich auch gleich selbst die Buttons auf meine Posts kleben.

Die schlechte Nachricht: Wer sich selbst bei Flattr anmelden möchte, kann das momentan nur mit einem Invite-Code. Dafür bin ich @flattrme gefolgt. Die wollen dann dort, dass Du "Bitte, bitte" machst, aber wenn man über diesen Schatten springt, bekommt man flugs seinen Invite-Code und kann los legen.

Das Einbinden der Buttons in den Blog ist dann weniger spaßig. Automatisch geht das nur halb. Ich habe mit Hilfe von Nicolas Gramlichs Flattr Button Plugin für Blogspot (übrigens mein erster ge-flattr-ter Inhalt!) die Buttons auf die Blogpost bekommen. Das geht automatisiert. Trotzdem muss man jeden einzelnen Beitrag auf Flattr posten, sonst ist der Inhalt für Flattr inaktiv und dann sieht der Button so aus:

Ich habe wenig Lust, jeden einzelnen Post dieses Blogs zu aktivieren, ergo bleiben alte Posts wie dieser vorerst inaktiv.

Fazit: Spannende Sache. Glaube, dass Flattr und ähnliche Konzepte in Zukunft durch starten werden. Schaue mir das mal aktiv von hier aus an.

Running only one of JUnit's Tests

Green Bar with only one of JUnit's Tests

I managed to run all of JUnit's tests. And I failed for some time to run only one test. Here's why and how I finally succeeded.

One test I kept a close eye on: org.junit.tests.running.classes.ParameterizedTestTest. I opened it in Eclipse and tried to run it. A window occured and asked me to select a test:

What was that? I never saw such a window before. Was it something new in Eclipse 3.5.1? I looked around and looked also into the outline of that test class:

After a closer look I thought I knew what that test selection window was all about: One was able to pick a specific test method in one test class. All of the test method names in the test selection window were also in the outline view of that class. Yes, that would make sense. And that would be actually a great thing, since it was never possibile to do that in previous Eclipse versions and that would be a very useful feature for many reasons.

Okay, new feature, cool. But how could I run one test class with all test methods together? Like I was used to do in all the previous Eclipse versions before? I asked other Eclipse users in my current project, but nobody had a clue. I asked on Twitter, and got some doubtful suggestions like "I think there is something seriously broken in your eclipse installation."

After the fifth person or so I begged for help I realized what was going on. Do you see it? It's in the pictures I showed you in this post before. What I saw after a while was this line:

What a bad UI design, I thought. Why on earth would they put an entry for the whole test class in the middle of all the other test methods? Shouldn't it at least be marked in some way? Wrong assumption, again. Those items were all test classes! Oh my, now that I look at the test selection window I see all those green icons with the C in it...

Anyhow, why are there so many static test classes (yes, that's what they are, static, and the outline view told me with a little red 'S') in one single file? Because those are the input parameters for the tests. The test class contains all the tests for JUnit's Parameterized Test feature, which is a way to deal with one test method called several times with different parameters. It's more than having a for-loop going through a bunch of parameter sets, because with JUnit's Parameterized Test feature every parameter set is treated like a separate test method. With three parameter sets you'd end up with three tests, and if one test would fail, the others won't stop running like they would do in a for-loop.

For that feature you have to provide a annotated method which should return the parameters, you have to provide a constructor and instance variables for the parameters, and you have to reference the parameters in the instance variables from within the test method. That's a lot of stuff which could be broken easily. Each static test class supports a test method for the feature. Eclipse cannot distinguish between a test class as a test class and a test class as a test input parameter, and so it showed every test class in a test selection window.

Well, maybe I shouldn't program late at night, but that was really a hard one to figure out.

Running all of JUnit's Tests

Green Bar with JUnit

After Getting JUnit from Git on a Mac I wanted to run all of JUnit's tests. Here's what happened.

First I opened the whole JUnit project in TextMate. TextMate is my editor of choice when I work with Groovy/Grails and Ruby/Rails. I do whole projects with it. For those kind of languages and frameworks Textmate is suiteable, but since JUnit is a Java project, TextMate's seems to be not enough.

I tried to run all the tests within JUnit with TextMate. There are some AllTests classes, but you can't run them from within TextMate easily, because you would have to deal with the classpath on your own. There's an Ant build file, but unfortunately without a test task. Tests seems to be only executed during a build, but I don't want to build JUnit everytime when I actually want to run all the tests.

In the build file I saw a reference to org.junit.tests.AllTests. Again, it'd be a mess to build the classpath everytime I wanted to execute the AllTests class within TextMate. I switched to Eclipse after I upgraded to Eclipse 3.5.1.

There were already project files for Eclipse in the JUnit project, so I was able to be up with JUnit in Eclipse with a simple import. I executed org.junit.tests.AllTests with Alt+CMD+X T and I saw a green bar with 481 tests. Yay!

Only the execution time wasn't that good. It took me ~23 seconds to execute all the tests, which is quite more than my expected less than 10 seconds.

At least I could run all of JUnit's tests now.

Getting JUnit from Git on a Mac

Logo of Git distributed revision control system by Wikipedia

I want to dig deeper into JUnit for some reasons. Therefore I want to see the latest version in the repository. JUnit uses Git. I use a Mac and never used Git before. Here's what I've done to get JUnit from Git on a Mac.

I installed Git for OS X. It's a dmg file and quite simple to install.

After that I had to add Git's bin path to PATH to use Git in the terminal. I added this to ~/.bash_profile.

export GIT_HOME=/usr/local/git
export PATH=$PATH:$GIT_HOME/bin

Worked now for me: I entered git in the terminal and saw a list of commands.

Now what? I read parts of the official Git tutorial online and in the terminal with git help tutorial. I entered my user.name and my email.adress as a key with git config --global key value where value is my name or email adress, because I should do that "before doing any operation".

I continued reading at paragraph "Using git for collaboration". There's what I was looking for:

Suppose that Alice [aka Kent] has started a new project with a git repository in /home/alice/project [aka git://github.com/KentBeck/junit.git as listed on github.com], and that Bob [aka me], who has a home directory on the same machine [aka ~/projects/junit], wants to contribute.

In the terminal I entered

git clone git://github.com/KentBeck/junit.git ~/projects/junit

Now Git downloaded JUnit. Finally JUnit was downloaded on my computer. The tutorial states that if Kent would commit changes I could be again up to date with a simple git pull.

So far so good to be able to have a look around in JUnit.

[Update: If you want to run Git within TextMate, than you can. TextMate can deal with Git from the start, but you have to set TM_GIT as a shell variable, e.g. to /usr/local/git/bin/git or wherever you've installed Git.]

stilversprechend.de

Nach werkannwann.de (ich berichtete) gibt es ein weiteres hilfreiches Tool als Webapplikation aus dem Hause it-agiles: stilversprechend.de analysiert den Stil eines Textes und gibt hilfreiche, mindestens aber interessante Informationen über ihn aus.

Die User-Story ist ziemlich einfach: Schreiber schreibt Text. Schreiber möchte Feedback, ob der Text so okay ist oder er ihn noch verbessern kann. Schreiber hat niemanden, der ihm Feedback gibt. Schreiber ist frustriert, weil er kein Feedback bekommt. Schreiber surft zu stilversprechend.de und gibt den Text ein per Copy 'n Paste. Stilversprechend.de gibt Schreiber Informationen über den Stil des Textes. Schreiber passt Text an, damit dieser lesbarer und stilvoller wird. Schreiber ist glücklich, weil er Feeback bekam.

Surft man zu stilversprechend.de, so erscheint ein Formular mit zwei Eingabefeldern und drei Buttons. In das große Formular kann man Text eingeben, und wenn man dann auf "Text prüfen" klickt, wird der Text geprüft und das Ergebnis ausgegeben. Alternativ kann man auch eine URL angeben und dann wahlweise per Häkchenbox den Text einlesen oder gleich überprüfen lassen.

Das Ergebnis ist schon ziemlich umfangreich: Anzahl der Zeichen, Wörter, Silben und Sätze wird ausgegeben. Es wird der Flesch-Wert berechnet, mit dem man erkennen kann, ob man seine Artikel eher dem Axel-Springer-Verlag (Bildzeitung; Fleschwert 61-70) oder dem Julius-Springer-Verlag (wissenschaftliche Titel; Fleschwert 20-30) anbieten sollte. Werte für den Durschnitt von Wörtern pro Satz, Silben pro Wort, Kommas pro Satz und die Passivrate werden ermittelt. Das sind schon ganz nützliche Angaben, wie ich finde. Darüber hinaus wird der analysierte Text noch mit zusätzlichen Angaben versehen: Nominalstile, Füllwörter, lange Sätze und Wörter, Floskeln, Wortdoppelungen und Satzanfänge mit "Es", Passivsätze und Anglizismen werden hervorgehoben dargestellt.

Eine (sehr gut und lustig geschriebene) Kritik an dieser Art der Stilüberprüfung weist darauf hin, dass man in seiner künstlerischen Freiheit durch Metriken wie den Fleschwert zu stark eingeschränkt wird, wenn man dieser Metrik quasi blind Folge leistet. Die Hintergründe zu verstehen lohnt sich daher. Und wie bei jeder Metrik steckt auch hier eine Implikation dahinter, keine Äquivalenz: Gute Texte haben gute Kennzahlen, aber nur, weil die Kennzahl gut ist, muss der Text es noch lange nicht sein. Allerdings: Schlechte Kennzahlen deuten auch auf schlechte Texte hin. Aber wir kennen soetwas ja zur Genüge bei der Testabdeckung...

Guter Stil ist übrigens relativ: Ich habe mich mit Kollegen darüber unterhalten, und die Meinungen gehen weit auseinander. Während ich persönlich der Ansicht bin, dass selbst die Präsentation eines Produktes im Comicstil (Fleschwert über 70) überaus gut ankommen, wird auch gerne die Ansicht vertreten, dass der Stil gehoben sein müsse, damit der Text überhaupt vorzeigbar ist (Fleschwert 20-30; geht in Richtung der Soziolekte, Stichwort: restringierter und elaborierter Code). Ach ja, da waren doch damals diese stressigen Diskussionen mit meinem Prof, ich solle doch meine Sätze nicht so einfach halten, dass sei ja nicht wissenschaftlich... :-(

Natürlich bleibt es dem Schreiber vorbehalten, Änderungen aufgrund der Angaben von stilversprechend.de durchzuführen. stilversprechend.de bietet einen Spiegel für den Verfasser und trägt nicht selbst das Make-Up auf oder drückt einen Pickel aus. Wer auf z.B. Wolf Schneider und seine Stilkunde steht, der mag seine helle Freude an dem Tool haben. Ich selbst untersuche jeden meiner Blogeinträge vor dem Veröffentlichen mit stilversprechend.de. So siehen die Kennzahlen für diesen Post aus:

Screenshot der Kennzahlen von stilversprechend.de für diesen Post. Naja, ist nicht ganz ein Comic geworden :-)

Mein Featurewunsch an stilversprechend.de: Ein Widget für meinen Blog wäre toll, mit dem ich die Metriken direkt abfragen kann. Dann könnte ich in den Footer schreiben: Dieser Post besteht aus v Sätzen, w Wörtern, x Silben, y Zeichen und hat einen Fleschwert von z.


Glückwunsch an meine Kollegen von it-agile für dieses aus meiner Sicht feine und sehr nützliche Tool! Und hoffentlich lest ihr auch meinen Featurewunsch hier und priorisiert den hübsch weit oben in Eurem ProductBacklog, damit ich bald in Eurem Blog von stilversprechend.de nachlesen kann, wie ich das Widget einbauen kann.

Neue Teilnehmereingabe für werkannwann.de

Vor ein paar Wochen haben wir werkannwann.de einer beschränkten Öffentlichkeit zugänglich gemacht - und sehr viel Feedback zurückbekommen! Da haben sich alle bei it-agile, die an diesem Projekt beteiligt sind, sehr drüber gefreut. An dieser Stelle vielen Dank für die tolle Resonanz!

werkannwann.de wird agil, u.a. also iterativ entwickelt. Bugs zu fixen hat immer Vorrang vor neuen Features, und so wird am Anfang einer Iteration das System von Bugs befreit. Es ist nur... da waren keine richtigen Bugs zu fixen. Dank sehr ausführlichem Feedback haben wir zig Rechtschreibfehler, grammatikalische Fauxpas und verrutschte Grafiken und Layoutbereiche korrigiert, aber so Bugs im Sinne von "Das System verhält sich nicht so, wie es sich verhalten sollte!" gab es keine.

Gut, es gibt ja immer diese Diskussionen, ob das nun tatsächlich ein Bug ist oder ein Feature, dass noch nicht umgesetzt wurde. Wenn das Bemängelte nämlich ein Feature ist, dass noch nicht umgesetzt wurde, dann kann es ja noch nicht funktionieren, korrekt? Und daher ist das dann kein Bug. So sieht die Welt durch die rosarote Entwicklerbrille aus.

Diese Frage, ob Bug oder Feature, ist meist nicht nur eine Frage der Ehre für die Entwickler ("Ich habe da keine Bugs eingebaut, lieber Auftraggeber, Du hast die Features nicht richtig oder gar nicht beschrieben!"), sondern letztlich eine Frage des Geldes: Wenn es ein Bug ist, zahlt das Fixen der Auftragnehmer, während Features natürlich vom Auftraggeber bezahlt werden. Oft streitet man sich da um Selbstverständlichkeitsanforderungen. Kunde: "Das ist doch selbstverständlich, dass sich die Anwendung so und so verhalten muss! Alles andere ist doch Blödsinn!" Entwickler: "Aber das haben Sie nirgendwo angefordert, richtig? Woher soll ich denn wissen, wie sich das System genau verhalten soll, wenn Sie mir das nicht sagen? Es gibt [große Zahl] mögliche Lösungen für das Problem, und Ihre Lösung ist nur eine davon und somit gar nicht selbstverständlich!" Es sollen schon Kriege ausgelöst worden Firmen untergegangen sein, weil sich Entwickler und Kunden nicht auf Bug oder Feature einigen konnten...

Naja, in der Produktentwicklung, also auch bei werkannwann.de, ist es wirklich fast nur eine Frage der Ehre, vielleicht noch eine Frage des Geldes beim Budget von Entwicklung (Auftragnehmer) und Produktmanagement (Auftraggeber). Aber den Benutzer, der seine Termine abstimmen will, den interessiert das nicht, der will, dass es ordentlich läuft.

So eine Bug-oder-Feature-Sache war die Eingabe der E-Mail-Adressen des Organisators und der Teilnehmer. Bislang hatten wir jegliche Eingabe bei den E-Mails akzeptiert, also auch z.B. "blubb". "blubb" ist aber keine E-Mail-Adresse, und dann knallt es beim Versenden. Wir sind in der Alpha-Version erstmal davon ausgegangen, dass wir uns die Mühe sparen können, diese Eingabe zu validieren, um mehr Entwicklungskapazitäten für drängendere Features zu haben. Falsche Annahme, wie uns einige Benutzer meldeten. Wir haben verstanden, und es können jetzt nur noch syntaktisch korrekte E-Mail-Adressen eingegeben werden.

Überhaupt haben wir die Teilnehmereingabe selbst überarbeitet: Früher sah die Eingabe so aus:
Diese Grafik ist manipuliert, also zusammengeschnitten, denn tatsächlich waren 15 Teilnahmefelder (intern haben wir die "Rippen" genannt) auf der Seite, nicht nur die neun in der Grafik. 15 Rippen waren doof, wenn man nur ein oder zwei Teilnehmer eingeben wollte, denn die Seite war unübersichtlich und hat sogar Probanden in Usability-Tests erschreckt ("Huaa, was geht denn jetzt ab? Die muss ich alle ausfüllen?"). Andererseits wollten Benutzer mehr als 15 Teilnehmer abstimmen lassen, und das ging bis dato auch nicht.

Jetzt sieht die Seite so aus:
Da ist jetzt nur noch eine Rippe zu sehen, dafür aber ein Plus-Zeichen daneben. Klickt man auf das Pluszeichen, dann wird eine weitere Rippe hinzugefügt. Für Power-User hilfreich: Es erscheint auch eine weitere Rippe, wenn man im letzten E-Mail-Feld eines Teilnehmers den Tabulator bedient. Dann springt man gleich weiter zum Namens-Feld der neuen Rippe. So kann man hintereinander die Teilnehmer nur so "wegtippen".

Na, ist das was? Das ist was!

Wer's ausprobieren mag: werkannwann.de ist weiterhin im Alpha-Stadium, was bedeutet, dass ohne Anmeldung keine Abstimmung angelegt werden kann (das Abstimmen selbst geht übrigens ohne Login). Interessierte bekommen die Zugangsdaten zu werkannwann.de, wenn sie kurz anfragen unter info@werkannwann.de.

werkannwann.de

Endlich ist es soweit! Voller Stolz darf ich eine Grails-Anwendung verkünden, an der ich maßgeblich mitarbeiten durfte und die jetzt auch tatsächlich online gegangen ist: werkannwann.de.

werkannwann.de ist eine Webanwendung zur Online-Abstimmung von Terminen. Ich erklär's an einem Beispiel: In meiner Firma sind wir zum Arbeiten über die ganze Bundesrepublik verstreut. Damit wir uns auch trotz der Verteilung noch in Zukunft alle liebhaben, sehen wir uns öfter mal im Jahr alle zusammen, um uns abzusprechen. Aber es ist nie so einfach gewesen, dieses Treffen zu koordinieren. Ziel ist es, einen Termin mit allen abzustimmen, an dem die meisten teilnehmen können.

Henning, mein Chef, mailte dazu früher uns alle an: "He, wir müssen uns mal wieder alle zusammensetzen und Klönschnack halten. Wann habt Ihr Zeit? Ich schlage vor: ...", und dann folgten ein bis zwei Dutzend Datumsangaben. Und dann kamen die Antworten: "Ich kann dann und dann, aber da und da nicht, und da und da nicht so gerne." - "Mir passt's immer, außer [Liste von Datumsangaben]." - "Vielleicht könnte ich es da und da einrichten, aber sicher bin ich mir noch nicht. Da kann ich überhaupt nicht und hier bin ich mit meiner Familie im Urlaub, wo wir [lange Geschichte, die nett ist, aber irrelevant für die Terminabsprache]."

Jetzt hatte Henning viel Arbeit: Er musste aus den Antwort-E-Mails quasi alle Angaben herausfiltern, wann seine Mitarbeiter konnte, wann sie nicht konnte, und wann sie konnten, aber nur mit Bauchschmerzen. Das war viel Arbeit, langweilig und stupide. Und genau das übernimmt jetzt werkannwann.de!

Wenn Henning mit uns Mitarbeitern jetzt einen Termin abstimmen möchte, dann ruft er http://www.werkannwann.de auf:


Dort legt er dann eine neue Abstimmung an, gibt den Titel und eine Beschreibung ein und macht Datumsangaben, die seiner Meinung nach passen könnten. Er möchte das nächste Meeting irgendwann im Mai stattfinden lassen, Montags oder Freitags (aber nicht am 2. Mai, da sind vielleicht noch nicht alle wieder nüchtern haben einige vielleicht einen Brückentag geplant):


Auf der zweiten Seite gibt er noch die Namen und E-Mail-Adressen von sich und allen potentiellen Teilnehmern ein (ich hab die Darstellung mal etwas fürs Beispiel gekürzt; und die E-Mail-Adressen sind auch alles dieselbe, nämlich meine, sonst mache ich die ganze Firma kirre mit so einer Beispiel-Abstimmung). Er kreuzt an, dass auch er selbst an der Abstimmung teilnehmen möchte. Er nimmt noch schnell die AGB zur Kenntnis - und schon ist die Abstimmung angelegt:


Jetzt bekommt Henning eine E-Mail mit zwei Links: Mit dem ersten bestätigt er seine E-Mail-Adresse und veranlasst das Verschicken der Einladungs-E-Mails an die Teilnehmer. Mit dem zweiten kann er sich das Ergebnis anschauen. Dazu aber später mehr.

Jetzt bekommen die Teilnehmer also Einladungen via E-Mail. Dort ist ein Link drin enthalten, mit dem sie zur Abstimmung auf werkannwann.de gelangen. Dort wählen sie zwischen drei Optionen: ich kann (grün), ich könnte es möglich machen (gelb) oder ich kann nicht (rot). Ich lasse hier mal gerade meinen Kollegen Martin abstimmen:


Sobald der Teilnehmer gewählt hat, bekommt er eine anonymisierte Übersicht präsentiert, das bisherige Zwischenergebnis sozusagen (Martin war hier der erste, der abgestimmt hat):


Wenn dann irgendwann alle Teilnehmer abgestimmt haben, dann klickt Henning, der die Abstimmung gestartet hatte, sich über seinen zweiten Link auf eine andere Übersicht, in der er auch noch sieht, wer wie abgestimmt hat. Das ist hier wichtig, damit er evtl. nochmal nachfragen kann, falls nur ein einziger an einem bestimmten Termin nicht kann, alle anderen aber doch. In der Übersicht sieht Henning auch sofort, an welchem Termin die meisten können.


Schließlich kann Henning einen Gewinnertermin festlegen. Dann kann er alle Teilnehmer darüber informieren, welcher Termin das Rennen gemacht hat. Ihm wird da schon ein Text vorgeschlagen, den er nach seinen Wünschen abändern kann.


Wenn er den Text jetzt abschickt, dann bekommt jeder Teilnehmer Hennings Nachricht, und die Abstimmung ist beendet.

werkannwann.de ist nun erstmal in einer geschlossenen Alphaversion online. Das machen wir, um zu schauen, ob die Anwendung überhaupt "echte" User verträgt, und um nicht gleich alle zu enttäuschen, falls sie das noch nicht tut oder sich nicht so galant verhält (das böse Stacktrace-Monster, ihr wisst schon).

Abstimmungen anlegen darf also nur der, der die geheime Login-Passwort-Kombination kennt. Die verrate ich allerdings jedem, der's wissen möchte: eine E-Mail an info@werkannwann.de reicht da völlig. Wenn Ihr dann werkannwann.de ausprobiert, dann wäre Feedback natürlich echt super! Aber auch so freuen wir uns über jeden Besucher :-)

P.S.: An alle, die nerven, wann das Grails-Buch endlich kommt: Es kommt, wann es kommt. Wir sind noch dabei, aber werkannwann.de hat erstmal Vorrang. Alle dort gesammelten Erfahrungen fließen schließlich auch wieder ins Buch ein. Das Buch ist für Praktiker gedacht, ergo brauchen wir Praxis. Und mal ehrlich: So eine Webanwendung zu bauen ist doch viel spannender als darüber zu schreiben, oder? Also nicht verzagen, das Buch kommt!