Flominator's Kruschtelecke (Artikel mit Tag barcamp)

.NET Open Space Süd 2009 in Ulm - Visual Studio Team System 2010

nospam@example.com (Flominator) — Tue, 21 Jul 2009 13:19:24 +0200

Nach der Session Clean Code Developer und einem weiteren leckeren Mittagessen, folgte die letzte Session, die ich noch besuchen konnte: Christian Binder informierte darin über Neuheiten zur kommenden Version der Entwicklungsumgebung aus dem Hause Microsoft. Da wir im Unternehmen "nur" Visual Studio und kein Team System einsetzen, war es für mich stellenweise ein wenig schwer, den Ausführungen zu folgen. Hier sind die Punkte, die ich (zumindest ansatzweise) verstanden habe und die mir notierenswert erschienen:

UI-Automation-Testing (Coded UI-Test/ Test Edition)
- Elemente aus UI greifen und automatisieren
- unterstützt werden sollen Win32, WinForms, WPF und Document Object Model von Internet Explorer und Firefox
- später auch Silverlight (Community Technology Preview nach RTM von VSTS 2010)
- nutzt Accessabillty-Frameworks wie UIA von Anwendungen zur Barrierefreiheit (Screen Reader etc.)
- Controls von Drittanbietern müssen gewisse Schnittstellen implementieren, damit auch sie erfasst werden
Tools für manuelles Testen
- Anlegen eines Work-Items "Testcase", das an Requirement/UserStory hängt
- spezielle UI für Tester, die keine Entwickler sind (Manual Test Runner/Test Edition oder Test Essentials)
- Tester klickt durch und nimmt dies ggf. per Rekorder auf
- Screenshots und Videoaufzeichnung des manuellen Tests möglich
- Bugs können direkt aus dem Manual Test Runner erzeugt werden
- Integration mit Team Test Lab
- Umwandlung in einen kodierten Test (C#) möglich
Team Test Lab
- Environment (derzeit als Hyper-V evtl. später auch als virtuelle Maschine per vmWare-Schnittstelle) aus Buildprozess heraus erzeugen und Build nach dort deployen
- Verbindung mit Requirements
- kann in Verbindung mit dem Manual Test Runner verwendet werden, um Tests gegen diese Test Environments auszuführen
- Screenshot bei Verletzung eines Requirements
- ggf. Erzeugung eines neuen Bugs mit der virtuellen Umgebung im Anhang (sehr schnelle Reproduktion möglich)
Test Impact Collector
- feststellen, welche Tests überhaupt von einer Änderung betroffen sind und durchlaufen werden sollten
- Unit-Tests und manuelle Tests
Oberfläche der neuen IDE ist komplett in WPF geschrieben
- bei Microsoft intern von über 3000 Anwenden genutzt
durch Extensibility API stark auf Erweiterbarkeit ausgelegt
UML/DSL-Designer in Architect Edition (Arc Edition)
- Kommunikationslinien zwischen den einzelnen Architekturschichten können mit Code verglichen werden -> unzulässige Kommunikationen im Code finden (oder auch zwischen Namespaces)
- keine veralteten Architektur-Flipcharts mehr
- erlaubt Reverse Engineering: Methodenaufrufe -> Sequenzdiagramm
- Analyse von Codeabhängigkeiten
Profiler (Developer Edition)
- besonders hilfreich bei Threading-Problemen
- während der Entwicklung von Windows 7 genutzt, um Performace-Probleme zu lösen
- Hotpath zeigt an, wo meiste Rechenzeit liegen gelassen wird
- Testcase-Profiler kann Auswirkungen von Änderungen auf die Rechenzeit zeigen
komfortableres Reporting, daher können Entscheider sich zukünftig selbst ihre Zahlen ziehen und entlasten damit die Entwickler
langsame Anwendungen können bald nicht mehr durch neue Rechner beschleunigt werden, wenn sie Single-Threaded arbeiten und nur wenige der Multiprozessoren dadurch belastet sind
Verfolgen von Veränderungen in (Changesets) in Branches

Fazit: Es scheint ein sehr umfangreiches Entwicklungssystem zu werden, das den Entwickler und alle restlichen Beteiligten eines Softwareprojektes in großem Maße unterstützen wird. Da solche Qualität ihren Preis hat, bleibt jedoch fraglich, welche Unternehmen sich das leisten können, leisten wollen und leisten werden ...

Update: Dank geht an Christian Binder für das Feedback. Bitte schaut euch seine kurzen Videos zur Beta 1 an.

.NET Open Space Süd 2009 in Ulm - Clean Code Developer

nospam@example.com (Flominator) — Mon, 20 Jul 2009 13:11:05 +0200

Die vorletzte Session auf dem Open Space, die ich nach Testen/Getting Things Done besucht habe, drehte sich um das Programm Clean Code Developer von Ralf Westphal und Stefan Lieser. Letzterer war höchstpersönlich anwesend, um uns in die Geschichte und die Details von CCD einzuweisen:

guter Entwickler erzeugt Qualität -> hält seine Werte ein
Analogie dazu: (Guter) Arzt wäscht sich vor Operation die Hände und lässt sich das nie nie nie ausreden
Werte für Codequalität
- Korrektheit (funktional, optisch, leistungsfähig, ..)
- Evolvierbarkeit (Einbau desselben Features kostet zu jedem Zeitpunkt gleich viel)
- Produktionseffizienz
- Reflexion
Ergebnis: 40 Bausteine zum Erreichen von mehr Codequalität
Aufteilung in fünf Grade
zur Festigung wird jeder Grad mindestens 21 Tage gehalten
am Ende wird wieder von vorn begonnen, da man immer noch besser werden kann
Dokumentation des aktuellen Grades über ein Armband
Armband bringt Leute ins Gespräch und hilft, die Idee zu verbreiten
nicht alle Entwickler interessieren sich für sauberen Code
häufig ist keine Zeit zur Einarbeitung vorhanden.
Ist das Erlernen neuer Fertigkeiten zu Erhaltung der Arbeitskraft in der täglichen Arbeitszeit erhalten oder muss man dafür in der Freizeit investieren? Es hängt vom Lohn ab
These: es dauert nicht länger, Clean Code zu schreiben, als Crappy Code (zumindest langfristig gesehen)
Python und Ruby on Rails liefern bereits beim Anlegen eines neuen Projektes ein Verzeichnis für Unit-Tests, warum nicht auch Visual Studio?
Grenze zwischen PHP (unsauberes Skripting, bä bä bä) und Java (ganz toll objektorientiert mit Unit-Tests und so) ist deutlich. Bei C# sind die ganzen VB-Pfuscher durch .NET auch im Boot.
Microsoft vermarktet häufig nur Tools, die dem Benutzer mit viel Klickibunti das Leben erleichtern. Codequalität scheint ein wenig vernachlässigt zu werden.

Fazit: Bei uns im Büro erfuhr ich bereits Ende letzten Jahres von dieser Initiative. Ich hatte sie mir auch bereits auf "vielleicht/irgendwann" notiert, aber bisher noch keinen konkreten Einstiegspunkt für mich gefunden. Nun scheint es mir, dass man auch ohne den Kauf des Buches aktiv loslegen kann. Vermutlich werde ich daher in den nächsten Wochen die Seite zum roten Grad in Angriff nehmen ...

.NET Open Space Süd 2009 in Ulm - Testen/Getting Things Done

nospam@example.com (Flominator) — Fri, 17 Jul 2009 13:31:10 +0200

Testing
Die erste Session am Sonntag hatte mit "Testen" ein etwas zu umfangreiches Themengebiet. Daher ging die Diskussion nicht ganz in die Richtung, die ich mir gewünscht hätte. Trotzdem gab es ein paar erwähnenswerte Infos:

UI-Tests lohnen sich vermutlich nur für Standardarbeitsschritte, sonst zu hohes Preis-Leistungs-Verhältnis
Webtests sind meist trivial und finden keine richtigen Fehler
Visual Studio (in welcher Edition?) erlaubt Klickreihenfolge im Browser abzuspielen und als Lasttest mehrfach auszuführen
Lasttests bei ERP-Systemen heißt, einmal die Weihnachtszeit nachzuspielen
Tester stumpfen bei häufiger Wiederholung ab und sehen Fehler nicht mehr => Vorteil von UI-Tests
bestes Preis-Leistungsverhältnis haben Unit-Tests für Rechenfunktionen

Getting Things Done
Nachdem mich das klingelnde Handy aus dem Raum geholt hatte, entdeckte ich eine kleine, aber eine Diskussionssrunde zum Thema Getting Things Done. Obwohl es nicht direkt um das Buch ging, gab es auch dort ein paar Anregungen:

alle Mails nach dem Urlaub löschen -> wer etwas will, der kommt schon wieder
(wirklich) dringende Sachen sollten per Telefon geschehen, dort ist auch Rausreißen aus der aktuellen Tätigkeit legitim
Was ist schon wirklich dringend?
Abteilungsleiter veröffentlicht seinen Wochenplan, damit seine Untergebenen sehen, was er die Woche über tut
Corporate-Mikroblogging wie Yammer kann ebenfalls dabei helfen, zu sehen, was die Leute um einen herum so tun

.NET Open Space Süd 2009 in Ulm - Mocking/Interfaces

nospam@example.com (Flominator) — Thu, 16 Jul 2009 13:27:54 +0200

Nachdem zu Inversion of Control und Dependency Injection auf dem Open Space in Ulm keine Fragen mehr kamen, handelten wir spontan noch zwei andere Themen ab:

Mocking

"normale" Frameworks wie z.B. Rhino Mocks nutzen Proxy-Mechanismusmit Vererbung
Problem: statische Klassen sind nicht mockbar
Typemock erlaubt Nutzung der Profiler-API; dadurch auch Mocking statischer Objekt möglich (Date.Now trotzdem nicht)
Frameworks mit Automock-Funktionalität ermöglichen es, dynamisch zu mocken, was gerade benötigt wird
RhinoMocks nutze früher Record-Replay-Modus, heutiges Prinzip ist Arrange-Act-Assert
siehe auch: Einfacheres Mocken von Eigenschaften eines Objektes

Interfaces

Interfaces verhindern, dass man "virtual" vergisst
abstrakte Basisklassen können bereits Funktionalitäten implementieren
Methoden abstrakter Basisklassen können ggf. überschrieben werden, MÜSSEN sie aber nicht
Interfaces erfordern bei Erweiterung neue Methoden in allen von ihnen abgeleiteten Klassen
Methoden von Interfaces müssen nicht implementiert werden, wenn die Basisklassen sie bereits implementieren
Kommentare zu Methoden des Interfaces sollten per Konvetion dort im Interface geschrieben werden, nicht in der Implementierung
alternativ können mit ghostdoc Kommentare von beerbten Objekten kopiert werden

Fazit
Mein Highlight der zweiten Hälfte der Session waren das Beispiel für das neue Arrange-Act-Assert-Schema bei RhinoMocks sowie der Verweis auf ghostdoc. Dieses Tool kann ich nur wärmstens empfehlen, um automatische Dokumentationskommentare zu generieren. Meist sind sie relativ treffend, falls nicht, sind sie dann zumindest lustig.

.NET Open Space Süd 2009 in Ulm - Inversion of Control/Dependency Injection

nospam@example.com (Flominator) — Wed, 15 Jul 2009 13:34:11 +0200

Nach dem "Kampf" von Castle Monorail vs. Microsoft MVC geht es heute um Inversion of Control bzw. Dependency Injection. Hier also meine Notizen zu diesem spannenden und häufig unterschätzten Thema:

Klasse bezieht von ihr genutzte Klassen "von außen"
Nutzung von Interfaces statt konkreter Implementierung
Zuweisung des konkreten Objektes "von außen" - manuell oder per IoC-Container
Konfigurationsstrategien für den Container
- via XML - aufwändig, bäääh!
- Objekte einzeln und "von Hand" hinein packen
- relevante Objekte per Reflection aufsammeln (+ Sonderfälle explizit zuweisen)
  - StructureMap (gut strukturiert)
  - WindsorCastle (wenn man schon Monorail oder ActiveRecord nutzt)
  - Unity
  - Ninject
  - Spring
  - "von Hand" per Attribut
Constructor injection: wenn keine Default-Implementierungen vorhanden sind
Setter injection: praktisch, da nur bei Bedarf Default-Implementierungen überschrieben werden
Performance: Zeitverlust durch IoC im Vergleich zu new ist verschwindend gering im Vergleich zur Lebenszeit des Objektes
IoC hilft, Singletons zu erzeugen (die im Vergleich zum "normalen" Pattern sogar überschrieben werden können)
Idealfall: alles wird injiziert
- Attribute sind nicht injizierbar - Ausweg bietet CommonServiceLocator
Container lässt sich beim Testen auch ausmocken

.NET Open Space Süd 2009 in Ulm - Castle Monorail vs. Microsoft MVC

nospam@example.com (Flominator) — Tue, 14 Jul 2009 13:38:31 +0200

Nach den gestrigen Scrum-Notizen hier gleich der Mitschrieb zur nächsten Session vom Ulmer Open Space. Leider gab es in der Session keinen wirklichen Vergleich zwischen den beiden MVC-Frameworks, da niemand der Anwesenden gleichzeitig beide so richtig gut kannte. Trotzdem empfand ich einige Fakten aus der Session als relativ interessant:

Ziel muss immer sein, die Logik in den Views minimieren
MS MVC ermöglicht Austausch von Controllern und View-Engines
weitere Viewengines sind z.B.: NHaml (.NET-Port der bekannten Rails-Engine) und Sparkview
Webforms sind ebenfalls als Viewengine nutzbar (aber ohne Lifecycle)
Lock-In-Effekt ist größte Gefahr bei Wahl der Viewengine
gute Viewengines erlauben Nutzung typisierter Models
NVelocity-Views zeigen $Variable, wenn selbige nicht gefüllt ist
- Quelltext nach $ durchsuchen zur automatisierten Fehlersuche
ASP-View von Monorail kann IntelliSense, MS MVC auch
Microsoft MVW beherrst ASP Dynamic Data, mit dem man schnell CRUD-Formulare erzeugen kann
Deployment von MS MVC in bin oder GAC möglich
Server startet in bestimmten Fällen neu (u.a. bei Änderung zu vieler Dateien)
Dateiendung muss an ASP.NET übergeben bzw. dafür registriert werden
Seiten ohne Endung: Bilder und Javascripte explizit per StaticFileHandler bearbeiten, um die Performance zu verbessern.
Microsofts Lösung kann mit MvcContrib sinnvoll erweitert werden
Beispiel zum MVC-Framework von Microsoft, das Albert dann ausführlich in einer separaten Session vorstellte.

Fazit: Es gibt keine technischen Gründe, sich für oder gegen Castle Monorail zu entscheiden. Langfristig ist aber (leider?) davon auszugehen, dass es mehr Tools, Support und Community-Angebote für das Microsoft Framework geben wird.

.NET Open Space Süd 2009 in Ulm - Tag 1: Scrum

nospam@example.com (Flominator) — Mon, 13 Jul 2009 13:55:16 +0200

Nachdem Thomas Bandt ja schon erklärt hat, was beim .NET Open Space Süd 2009 so passiert ist, kann ich mich hier ja glücklicherweise auf das Posten meiner Notizen beschränken.

Die erste Session drehte sich um das Thema Scrum:

Einführung

keine Aussage, wie entwickelt wird - das Team soll dies selbst regeln
Vorgesetzter kann als Scrummaster problematisch sein, da er "über" den Teammitgliedern steht
Aufgaben (geforderte Features) für nächsten Sprint werden in Punkten abgeschätzt - NICHT IN STUNDEN
Länge eines Sprints: 2-4 Wochen, im Web-Bereich häufig nur eine Woche
keine Belohnungen/Sanktionen, da sonst die Qualität leidet
Regel: keine neue Karte nehmen, wenn man noch alte hat

Daily Scrum

Diskussionen abblocken und nach dem Meeting klären
prägnant erreichte Ziele von heute und geplante Ziele für nächsten Tag nennen, nicht erzählen, was denn so alles über den Tag passiert ist
Scrummaster muss Probleme heraushören (auch nicht explizit genannte)

Nutzen

sichtbaren Ergebnis für den Kunden nach jedem Sprint
starke Kommunikation im Team
Commitment auf die Aufgabe
Product owner ist Teil des Teams
- hat mehr Verantwortung
- muss während des Sprints zur Verfügung stehen
- muss klare Vorgaben geben
mehr Struktur, klare Vorgaben

Gefahren

Scrum allein enthält keine langfristige Planungskomponente
evtl. mangelnde Effizienz über Projektlaufzeit
keine Sicht auf großes übergeordnetes Ziel
Erfolg steht und fällt mit der Qualität des Backlogs
keine Basis für Angebotserstellung
- Lösungsansatz: Spezifikation im ersten Sprint erstellen

Sonstige Themen in der Session

Release spring: Phase kurz vor einem Release, in der nur noch kosmetische Änderungen durchgeführt werden und parallel relativ zuverlässig getestet werden kann
Sprint-Burn-Down-Charts zeigen an, wie gut man in der Zeit liegt:

"Kartenstatus"-Diagramm dient dem gleichen Zweck, spart aber die Malarbeit, durch Zuordnung der Karten zu einem Status:

Fazit
Schöner Rundumschlag zum Thema mit einer guten Mischung aus Theorie und Erfahrungen. Highlight war für mich der Input von Thomas Schissler, der das Konzept seines Unternehmens vorstellte: Dort werden am Anfang zwischen 30 und 60% der Projektlaufzeit für die Erstellung der Oberfläche genutzt. Erst wenn Kunde mit Oberfläche einverstanden ist, wird implementiert. Dies erscheint mir ein sehr sinnvoller Ansatz!

In einer späteren Session erfuhr ich dann auch, was passiert, wenn Scrum falsch eingesetzt wird. In diesem Fall muss SCRUM einfach rückwärts gelesen werden

Barcamp Stuttart: Corporate Twitter / Yammer

nospam@example.com (Flominator) — Sat, 16 May 2009 18:30:12 +0200

Nächstes Wochenende geht es (vermutlich) endlich zum FuCamp. Da wird es höchste Zeit, endlich das Kapitel BarCamp Stuttgart abzuschließen und zwar mit diesem Beitrag über die Session von Dennis Kallerhoff.

Dennis vertrat die These, dass die Bedeutung der Email aufgrund neuer Kommunikationsformen (Twitter, Social Networks, etc.) sinken wird. Damit schloss sich die Session nahtlos an jene von Kai Nehm in Offenburg an, ohne diese groß zu wiederholen.

Da er bereits kurz zuvor über das Thema gebloggt hatte, brauche ich auf die Beispiele zu erfolgreich twitternden Unternehmen nicht weiter einzugehen und kann mich einem Detail widmen:

Yammer
Dennis erwähnte beiläufig den Dienst Yammer. Dort kann man ein twitterartiges Netzwerk fürs Unternehmen gründen. Die Zuordnung von Mitgliedern geschieht über die E-Mail-Domain des Unternehmens. Seit einigen Wochen evaluieren wir im Büro nun Yammer. Neben den üblichen Twitter-Features gefällt mir die Möglichkeit, Dateien an die Tweets ääh Yams anzuhängen. Mit Twitterfox existiert auch ein Firefox-Addon zum Dienst, damit man die Seite nicht immer offen haben muss. Zur Krönung lassen sich, nach Verbindung der beiden Accounts, Twitter-Nachrichten über das Hashtag #yam zu Yammer transferieren.

Lustig war mich, dass ich die Notizen zur Session und damit die zu Yammer bis vor ein paar Tagen nicht mehr angesehen hatte. In der Zwischenzeit hatte ich via Synaxon zum zweiten Mal von Yammer erfahren. Gut zu wissen, dass einen die wirklich wichtigen Infos meist mehrfach erreichen

Barcamp Stuttart: Entschleunigung

nospam@example.com (Flominator) — Sat, 09 May 2009 16:27:56 +0200

Schon wieder ist eine Woche vergangen und es folgt der nächste Beitrag zum BarCamp Stuttgart. Diesmal berichte ich über Yodas Session Entschleunigung. Die Session war eine Diskussionsrunde, daher gibt es auch keine Präsentation, auf die ich verlinkten könnte. Daher gebe ich hier kurz die Kernaussagen einiger Beiträge als Denkanstoß wieder:

Grundanliegen der Session: Wege finden, um Tempo aus dem Alltag zu nehmen, um Lebensqualität zu erhöhen
„Gut Ding will Weile haben“ => Zusammenhang zwischen Zeit und Qualität
Web-2.0-Zeug hat oft Eigendynamik und frisst jede Menge Zeit: immer online sein, auf keinen Fall etwas verpassen wollen, was im Netzwerk passiert
Vertiefen ist mehr, als sich durch Wikipedia und Google herausfinden lässt. Man muss dazu Leute anhören und Bücher lesen
Langsamkeit = Lebensqualität, da Grundlage, sich etwas genauer anschauen zu können
Buchtipp: Rasender Stillstand
Entparallelisieren von Tätigkeiten; sich auf eine Sache konzentrieren
Ist Leistung = Beschleunigung?
Leistung muss man sehen können?
Bei welchen Leuten sieht man, dass sie viel leisten? Bei denen, die gestresst und hektisch sind. Leisten sie wirklich viel oder sehen sie nur so aus?
Problem wurde verstärkt, seit Leistung nicht mehr messbar ist. Woran erkennt man die Leistung, die hinter einer Grafik steckt? An der Anzahl der Pixel?
Lösungsansatz eines Teilnehmers: Die 4-Stunden-Woche
selbe Ecke: Beauftragung von Dienstleistern, die einem Arbeit abnehmen: https://getfriday.com/
anderer Ansatz: Aufgabe erledigt sich oft, wenn man sie einfach liegen lässt — Aufgaben, die aussehen wie ein Schinken: gut abgehangen und daher besser genießbar

Fazit
Für mich war es eine sehr interessante Session, die einige Denkanstöße hervorbrachte. Besonders Leute wie ich, die sich mit Produktivitätsmethoden wie Getting Things Done etc. auseinandersetzen, sollten ab und zu mal das Tempo herausnehmen und nicht nach dem nächsten Produktivitätskick suchen. Wir haben nun einmal nur dieses eine Leben und sollten uns sehr genau überlegen, was wir damit anfangen. Es kann und darf nicht nur aus Arbeit bestehen.

Auf der anderen Seite erklärte mir ein Bekannter, mit dem ich neulich darüber diskutierte, dass er froh sei, ein Workholic zu sein. Wenn sich diese Work auf „Arbeit für einen selbst“ beschränkt und man dadurch mehr Dinge in seinem Leben schafft, als andere, könne er gut damit leben.

Vermutlich ist es wie bei allem: Man darf nicht einfach nur schwarz und weiß sehen, sondern muss auf ein ausgewogenes Gleichgewicht achten.

PS
Gerne hätte ich auf die Literaturliste verlinkt, die Yoda ein paar Tage danach gebloggt hat. Der Link dorthin ist aber leider tot.

BarCamp Stuttgart: Gute Texte, Schlechte Texte

nospam@example.com (Flominator) — Fri, 01 May 2009 16:21:54 +0200

Das BarCamp Furtwangen kommt immer näher. Daher wird es für mich wirklich Zeit, zu Potte zu kommen und die letzten Sessions vom BarCamp Stuttgart zu verarbeiten. Klar ist es schon ein paar Tage her, aber dokumentiert hätte ich die Sessions trotzdem gerne.

Die heute vorgestellte Session wurde von Hans Dorsch gehalten und trug den Titel Gute Texte, Schlechte Texte. Eine rein subjektive Betrachtung. Die Präsentation zur Session gibt es bei Slideshare.

Viele der Teilnehmer (auch ich) versprachen sich beim Titel Gute Texte, Schlechte Texte eine Art Anleitung, wie man gute Texte fürs Web schreibt. Die Intention von Hans war aber eine andere: Er wollte uns mit der Session lediglich ein paar Beispiele zeigen, wie gute Texte im Web aussehen können:

Flickr

persönliche Grußformel in wechselnden Sprachen (ähnlich wie bei der Sendung mit der Maus)
nicht nüchtern, sondern umgangssprachlich ("unsere funkelnagelneue Homepage")
aktive Ansprache, eine Aufforderung, was der Besucher tun soll
keine ausführlichen Erklärungen am Anfang, sondern "Spielen Sie mit den Einstellungen"
auch FAQs von Flickr lassen gefühlte Freundlichkeit aufkommen
Fazit: So bekommt die Leute dazu, mitzumachen!

Coolspotters

Zeigt in einem Satz, um was es geht: "Coolspotters is the Google of people and products..."

MOO

Slogan "We love to print" findet sich überall wieder.
Es macht einfach Spaß, dort zu bestellen
Überall aktive Aufforderungen, was man den als nächstes tun könnte
deutschsprachiger Warenkorb (nicht selbstverständlich)
Möglichkeit, der Bestellung einen eigenen Namen zu geben UND die Erklärung, wozu man das brauchen könnte
Bestellbestätigung auf Seite: "Hurra, deine Bestellung ist eingegangen" und gleich die Warnung, dass man für Karten benutzte Flickr-Bilder nicht löschen soll
Noch besser ist die Bestätigungsmail, in der erklärt wird, wer bei MOO für was zuständig ist:
Little MOO verwaltet die Bestellung und Big MOO druckt sie aus. Nur der Kundendienst ist "aus Fleisch und Blut"
für mich: absolutes Highlight der Session
mindestens ebenso süß, wie die Einfälle von MOO: das Waschschild bei Puma

Du oder Sie?
Nach diesen Beispielen und einigen weiteren Screenshots (Folien 30-49) ging es zur Frage, ob man den Benutzer dutzen oder sietzen sollte. Auch hier gab es ein paar interessante Fakten zu lernen:

Dänen dutzen alles und jeden, bis auf die Königin
Ikea dutzt den Kunden (auch in den Geschäften) - ältere Menschen reagieren meist verwirrt.
Flickr kann sich nicht so richtig entscheiden und wechselt teilweise auf einer Seite die Anrede
Omigo redet Verbraucher per Du, Business-Kunden aber per Sie an
die Kroatin @Rozana erzählte davon, dass sie in ihren ersten Jahren in Deutschland nur "Sie" gelernt hatte. Ihre Freunde, die sie konsequenterweise dann auch mit "Sie" ansprach, dachten immer, sie sei total distanziert und könne sie nicht leiden.
These: "Du" wird zumindest beim Geldtransfer kritisch (aber, was ist mit dem Barkeeper?)
@webstyler berichtete, dass "Du" in Kundenbeziehungen eher problematisch ist: Kunde meinte mit "kannst du nicht mal"-Mentalität um kostenpflichtige Dienstleistungen herumzukommen
Idee zum Abschluss: Entscheidung über Anrede dem Kunden auf der Website überlassen. Damit erkennt er, dass es dem Anbieter wichtig ist.

Fazit
Obwohl die Session in den Augen vieler Teilnehmer total das Thema verfehlt hatte, ergab sich eine höchst spannende Diskussion. Vermutlich wären viele der Teilnehmer gar nicht zur Session gegangen, wenn sie den Titel richtig verstanden hätten, was wiederum die Qualität der Diskussion sehr abträglich gewesen wäre. Von daher war alles gut so, wie es war. Danke an Hans für die interessante Sammlung witziger Texte, für das nachträgliche Hochladen der Folien und für den Tipp mit MOO.

BarCamp Stuttgart: Getting Started With TYPO3

nospam@example.com (Flominator) — Sat, 21 Mar 2009 09:21:48 +0100

Langsam aber sicher läuft der Countdown zum BarCamp Furtwangen (FuCamp). Spätestens bis dort will ich es geschafft haben, die restlichen Sessions vom BarCamp Stuttgart dokumentiert zu haben.

Die erste Session am Sonntag drehte sich um das Content-Management-System TYPO3 und wurde von Harald Amelung gehalten, mit dem ich mich bereits während der Eröffnungsveranstaltung unterhalten hatte. Auch mit TYPO3 hatte ich bereits meine ersten Gehversuche unternommen.

Harald hatte die Session bereits während des BarCamp Bodensee gehalten und die Präsentation dazu gebloggt. Daher hier nur ein paar Dinge, die ich für erwähnenswert halte:

Getting Started

nach der Installation erscheint erst einmal eine Fehlermeldung, dass keine Seite vorhanden ist
BackendLogin /pfad/typo3
Seite anlegen, dann kommt Fehlermeldung: kein Template gefunden
gibt zwei Arten von Templates: typoscript (Template) und html-Template
Lösung in diesem Fall: Typoskript-Template anlegen
Es sind im Lieferungfang einige enthalten, aber uralt, daher Finger weg und
neues Template anlegen
standardmäßig sind schon ein paar Zeilen Typoscript dabei (quasi Hello World)
TS ist keine Programmiersprache, kennt aber Objekte (groß geschrieben), Eigenschaften und Bedingungen sowie Funktionen (Render-Anweisungen, z.B. zum Unwandeln in Großbuchstaben)
HTML-Vorlagen werden mit Markern (drei Rauten - Marker - drei Rauten) versehen
per Typoscript lassen sich den Markern Typoscript-Objekte zuweisen

Mandantenfähigkeit
TYPO3 ist grundsätzlich nicht für mehrere Installationen auf einem Server ausgelegt. Über symbolische Links lässt sich das jedoch trotzdem realisieren (siehe Folie 8 ). Auf diese Art habe ich im Rahmen meiner damals Diplomarbeit auch MediaWiki mandatenfähig gemacht (Anleitung). Das geschah mit Linux, da es ja keine Funktion zum Erzeugen symbolischer Linux unter Windows gibt ... dachte ich. Harald klärte mich aber darüber auf, dass dies mit dem Befehl mklink auch dort möglich sei (zumindest für Windows Server 2008). Damit ist man auf beiden Betriebssystemen in der Lage, mehrere TYPO3-Installationen zentral mit Updates des TYPO3-Cores zu versorgen.

Abkürzungen in der Präsentation

TCA: Table Configuration Array - Konfiguration von Datenbanktabellen
RTE: Rich Text Editor

Sonstiges

Benutzerverwaltung in Frontend und Backend sind voneinander entkoppelt
Updates: Typo3 erkennt bestehende Installation und führt einen dann durch die Updateroutine

Fazit
Die Session war, ähnlich wie die zu CakePHP, relativ technisch ausgelegt. Da ich das allerdings auch bin, war das kein Problem. Schön fand ich auch, was ich so nebenbei aufschnappen konnte: Die oben erwähnte Geschichte mit Symlinks unter Windows sowie die Aussage, dass sich TYPO3 eher für größere Websites eignet. Für kleinere Seiten empfahlen mir Harald, Ansgar und andere Teilnehmer den Einsatz schlankerer Systeme wie TYPOlight, MODx und CMS Made Simple.

BarCamp Stuttgart: cakePHP Einführung

nospam@example.com (Flominator) — Sun, 26 Oct 2008 20:41:42 +0100

Obwohl inzwischen mit München und Berlin zwei BarCamps ins Land gegangen sind, will ich noch sämtliche besuchten Sessions vom BarCamp Stuttgart dokumentieren. Die letzte Session des Samstages wurde von Simon gehalten und stellte eine Einführung in CakePHP, ein Web-Framework dar. Hiermit kann die Erstellung von Anwendungen unter PHP/MySQL vereinfacht werden.

Simon während der Session zu CakePHP (ja, es war wirklich so dunkel im Raum)

Simon zog das richtig professionell auf; er hatte sogar eine Art Skript vorbereitet, auf dem sämtliche Eingaben notiert waren. Ich verzichtete darauf, sämtliche Schritte mitzumachen und versuchte dafür, die einzelnen Schritte nachzuvollziehen. So hatte ich die Möglichkeit, einige Notizen zu machen, die ich hiermit gerne der Öffentlichkeit zur Verfügung stellen möchte:

Vorarbeiten
Simon nutzte zur Demonstration die Lite-Version des Pakets XAMPP. So spart man sich die Konfiguration des Apache-Webservers und kann gleich loslegen. Der Link zu XAMMP Lite mit CakePHP findet sich im Skript, so dass man nach dem Download eine lauffähige Installation vorfindet.

Der Ordner htdocs/cakecore stellt den Programmkern des Frameworks dar. Hieran werden keine Änderungen vorgenommen. Der zuvor bereits bestehende Ordner app enthält die Cake-Standardanwendung, auf die der Kern bisher noch verweist.

"BarCamp Stuttgart: cakePHP Einführung" vollständig lesen

BarCamp Stuttgart: Glossr

nospam@example.com (Flominator) — Sat, 11 Oct 2008 17:07:46 +0200

Oliver während der Session.

Vor lauter Frust wegen des verpassten BarCamps in München, hier gleich der nächste Beitrag aus Stuttgart. Glossr ist ein Projekt von Matthias Bauer, Thomas Schindler und Oliver Berger. Letzterer veranstaltete auch die Session.

Das Konzept ist schnell erklärt: Glossr sammelt kurze (vgl. 140 Zeichen bei Twitter) und prägnante Definitionen von Begriffen, um Leuten, die diese verwenden, eine einheitliche Diskussionsgrundlage zu geben. Ausgelöst wurde das Projekt durch eine Session von Stefan Peter Roos auf dem Leipziger BarCamp, in der dieser etwas von „emergenten Phänomenen“ erzählte und danach feststellen musste, dass ihm niemand mehr folgen konnte. Dies brachte die drei Gründer auf die Idee, Glossr ins Leben zu rufen und damit Sessions zu veranstalten.

Ziel einer Glossr-Session ist es, in der Gruppe einen Konsens hinsichtlich einer Begriffsdefinition zu finden. Vorschläge für definierenswerte Worte waren in unserem Fall Cloud Computing, Grid Computing, PageRank Sculpting und Semantik, für das wir uns dann auch entschieden. Nach einer sehr umfang- und lehrreichen Diskussion einigten wir uns wirklich auf eine Definition, die dann auch gleich eingetragen wurde. Oliver warb damit, dass jeder auf BarCamps gerne nach diesem Konzept Glossr-Sessions veranstalten darf. Es ist natürlich klar, dass es in München *nochmal schnüff* eine weitere Session zu Glossr gab.

Es stellte sich außerdem die Frage, was Glossr von Wikipedia unterscheidet. Oliver meinte dazu, dass Wikipedia-Artikel einfach zu lang seien, um kurz in einem Gespräch darin die Definition eines Begriffs nachzuschlagen. Gerne würde er jedoch auf Wikipedia-Artikel für weitere Erklärungen linken (was er natürlich auch darf). Ich wage allerdings, noch ein wenig weiter zu träumen: Sollte sich Glossr dazu bewegen lassen, seine Artikel zukünftig unter GFDL zu veröffentlichen, wäre sogar ein bidrektionaler Austausch mit der Wikipedia möglich. Davon könnte die Wikipedia in Form von prägnanteren Einleitungen profitieren, wie sie es zuletzt beim Einbänder tat.

Um zu zeigen, dass (eventuell) etwas längere Artikel zu einem Thema immer noch besser sind, als gar keine (wie zu diesem Zeitpunkt bei Glossr), hier noch die Wikipedia-Links zu Cloud Computing und Grid Computing.

BarCamp Stuttgart: Social Semantic News (Feeedo)

nospam@example.com (Flominator) — Fri, 10 Oct 2008 23:46:50 +0200

Passend zum zweiten Münchner BarCamp *seufz* fasse ich dann mal Social Semantic News zusammen, die nächste Session vom Stuttgarter BarCamp. Gehalten wurden sie von Anne und Jan, die ihre Arbeitgeber Digital Collections und mindmatters vertraten. Die beiden stellten die Idee vor, an der sie gerade arbeiteten.

Die Anne während der Session ...

Das Problem
Die Sache, um die es geht, kennt wohl fast jeder, der sich im Web 2.0 herumtreibt: Man liest einen interessanten Artikel und abonniert das Blog dazu per RSS-Feed, dann abonniert man noch ein paar Nachrichtenseiten und vielleicht noch ein paar Xing-Gruppen und schon ist das Chaos perfekt. Täglich kommen Unmengen von Nachrichten in Form von RSS-Feeds herein. Irgendwann kommt man nicht mehr mit dem Lesen hinterher und beschränkt sich auf das Scannen der Überschriften. Falls da auch nicht mehr reicht, gibt es nur noch eine Exit-Strategie, nämlich den Button Alle Nachrichten als gelesen markieren im Feedreader zu drücken. Anne und Jan bezeichnen dieses Phänomen als das Aua-Prinzip. Jeder im Raum kannte dieses Problem nur zu gut, naja, alle außer Ansgar.

"BarCamp Stuttgart: Social Semantic News (Feeedo)" vollständig lesen

BarCamp Stuttgart: Podcasting mit Kids

nospam@example.com (Flominator) — Thu, 02 Oct 2008 14:52:14 +0200

Die zweite Session des Stuttgarter BarCamps, die ich besuchte, wurde von Oliver Gassner und seinen beiden Kindern Julian und Janina angeboten. Die waren deshalb dabei, weil das Thema Podcasting mit Kids hieß. Mir ging es dabei allerdings wesentlich mehr um des Aspekt des Podcastens, da Kinder in diesem Moment noch kein Thema sind.

Oliver erzählte, wie es dazu kam, dass seine beiden Kinder die (de facto) jüngsten Podcaster Deutschlands (wenn nicht der Welt) wurden: Julian erzählte öfters ausgedachte Geschichten über seinen "Allesman"; Oliver wurde es irgendwann zu komplex zu merken bzw. zu transkribieren. Der Wunsch, die Geschichten zu konservieren, bestand aber trotzdem. So war es nicht weit, bis die beiden anfingen, auf Odeo die ersten Geschichten hochzuladen und sie in einem Blog zu veröffentlichen.

"BarCamp Stuttgart: Podcasting mit Kids" vollständig lesen