Sat Nov 18 21:15:18 +0100 2006 , Updated at
Rails Konferenz FFM
Wow! Am 3. November fand die erste Rails Konferenz in Deutschland statt. Fast 100 Besucher waren anwesend. Die Räumlichkeiten waren für diese Anzahl genau passend, die Stühle bequem und das Mittagessen lecker.
Viel wichtiger aber: Die Vortrüge waren fast alle sehr gut vorbereitet: Informativ und zum Teil auch wirklich unterhaltsam. Ich konnte einige gute Infos & Ideen mit nach Hause nehmen.
Besonders erwühnen möchte ich an dieser Stelle den Vortrag von Jens-Christian Fischer mit seinem Vortrag “Extreme Testing”. Dieser hat mir entgültig die Augen für BDD und autotest öffnete. Ein wirklich sehr gut gemachter Vortrag, die Slides dazu gibts hier.
Die Vorträge von Rany Keddo und Maik Schmidt sind mir auch dauerhaft im Gedächtnis geblieben. Beide waren auf ihre Art & Weise sehr unterhaltsam und informativ.
Der TechTalk in der Pausen war auch sehr inspirirend: Viele Leute die mit Rails an interessanten Projekten schrauben welche uns sicherlich in den nächsten Monaten überraschen werden. Es geht einiges in der deutschen Rails Szene!
Insgesamt war alles prima und ich bin bei der nächsten Veranstaltung dieser Art auf jeden Fall wieder dabei.
Dickes Lob & Dank an die Macher: Thomas Baustert, Beate Paland, Hendrik Stier, Thomas Ziegler
Tue May 30 00:38:33 +0200 2006 , Updated at
Webmontag in Stuttgart
Der Webmontag heute im Literaturhaus in Stuttgart war sehr lohnentswert: Ich hatte viele interessante Gespräche und habe dort auch einige Bekannte angetroffen. Insgesamt eine sehr angenehme Veranstaltung: Die richtige Dosis an who-is-who und smalltalk eben, gespickt mit 5 Vorträgen vor ca. 60 Leuten. Die Vorträge waren sehr unterschiedlicher Natur und ich habe einem sehr gemischtem Publikum versucht in ~15min Ruby on Rails etwas näher zu bringen.
Bin auf jeden Fall beim nächsten Webmontag wieder dabei!
UPDATE: Dank der flei�igen Leut` Henning Schürig und Simon Müller gibts auf Flickr auch einige Bilder und der nächste Webmontag ist auch schon angekündigt.
Tue May 16 22:38:14 +0200 2006 , Updated at
Code Kränzchen
Alte Traditionen sollte man aufrecht erhalten. Meine Oma und ihre Freundinnen pflegten sich einmal wöchentlich an wechselnden Orten zu treffen um bei einer gemütlichen Runde den aktuellen Tratsch aus dem Dorf einander zu erzählen.
So, nun bin ich aber überhaupt nicht an Tratsch interessiert. Du wahrscheinlich auch nicht. Uns interessiert eher alles was mit Web zu tun hat. Wie wäre es wenn man sich hin und wieder gegenseitig zeigt an was man so den lieben langen Tag dran sitzt. Irgend welche interessanten Details, wo man denkt: That´s cool stuff man! So in der Richtung: Du zeigst mir Deins; ich zeig Dir meins.
So kann man von der anderen Welt lernen. Kurz und Knapp, ohne Aufwand! So eine Art Other World Code Review oder eben ein “Code Kränzchen” (von Cafe Kränzchen).
Vielleicht könnte ja man so was in Stuttgart etablieren. Vielleicht gibt es ja noch andere die an so was interessiert wären?!
Bisher sind wir leider nur zu zweit, Tobias Günther von Puremedia und ich. Wir haben uns auch erst 2 mal getroffen. Einmal zum Thema Typo3 Internas und einmal zum Thema DSLs: Domain-Specific-Languages.
Themen und Ort werden spontan ausgemacht. Der Aufwand sollte gering bleiben. Wer Lust hat möge sich melden!
Mon May 08 17:18:04 +0200 2006 , Updated at
Continuous Integration
Continuous Integration soll bei wachsenden und zunehmend komplexer werdenden Software Projekten das Entwickler Team unterstützen. Das Problem ist, daÃ? durch das ständige Zusammenspiel mehrerer Entwickler, sich früher oder später sogenannte Integrationsfehler einschleichen können: Beim Zusammenführen von einander unabhängig entwickeltem Code entstehende Inkompatibilitäten. “Aber es funktioniert auf meiner Maschine” ist in solch einem Falle eine oft gehörte Aussage und zeigt auf, dass es selten zwei identisch konfigurierte Entwicklermaschinen gibt. Je früher man solchen Integrationsfehlern begegnet, desto schneller und einfacher können sie behoben werden.
Das folgende hier beschriebene Scenario geht von einer Traumkonstellation mit Ruby on Rails & Subversion & und dem Continuous Builder Rails Plugin aus. Desweiteren kommen darin mehrere agile Paradigmen vor: integrate early, integrate often & automate deployment & testing.
Wie kann so etwas aus Entwicklersicht aussehen:
Unser Star Coder Rob MacCool hat nach 3 Stunden intensivem coden das Mini Feature XYZ sammt Tests fertig. Jetzt updated er nochmals seine lokale Working Copy um vor dem Commit noch ein letztes mal alle Tests durchlaufen zu lassen. Liefen die Tests erfolgreich durch, kommt der ganze Bollen ins Repositority. Nach ein paar Minuten schaut er in die CI Mailingliste und erfährt dort ob alle Tests glatt durchgelaufen sind. So kann er sich jetzt relaxt seiner nächsten Tätigkeit zuwenden. Er kann sicher sein, dass sein neuer Code keine Integrationsfehler hervorgerufen hat.
Wirklich wichtig ist, dass neu erstellter Code regelmäÃ?ig, am besten mehrmals täglich commited wird. Je länger Code zurückgehalten wird, desto eher wird er Probleme verursachen. Am besten Commits in kleinen logischen Einheiten zusammen fassen und das Ganze mit sinnvollen Commit Messages kommentieren. Zudem basiert Continuous Integration komplett darauf, dass es zu jedem Stückchen Code auch Tests gibt. Denn diese Tests liefern dann das Feedback ob neu eingecheckter Code Probleme verursacht oder nicht. Ausserdem muÃ? alles was zum Projekt gehört auch in der Versionskontrolle stecken. Ein oft zitierter Spruch hierzu ist: “Code welcher nicht im SCM steckt, existiert nicht!”.
Ein Rechner mu� zum Integrations Server gekürt werden. Gut ist, wenn die einzelnen Hardware- und Software Komponenten zu denen des Produktionsservers so identisch wie möglich sind. Dies ist aber leider nur selten komplett machbar. Dieser Server leistet dann mehrere Dienste. Zum einen verwaltet er das Subversion Repositority. Zum anderen überwacht das Continuous Builder Plugin die SVN Commits und führt die Tests aus. Feedback über den Verlauf der Tests werden per eMail an die Entwickler oder auch an eine Mailingliste, über RSS oder an einen IRC Channel gesendet. Dieser Server kann auch als Preview Server dienen, indem das CI Plugin nach erfolgreichen Ablauf der Tests den Code exportiert und somit den aktuellen Stand des Projekts an einer Preview URL zu Verfügung stellt. Dieser Server könnte auch Trac hosten: Ein Webbasiertes Project Managment Utility mit Wiki und Issue Tracking System. Und ja nicht das Backup vergessen! Eine sich auch bewährte Sache ist es den Deployment Vorgang zu scripten und diesen an Subversions Commit Hook zu koppeln. Das Deployment also durch taggen oder branchen ausführen.
Diese Infrastruktur sollte man schon vor dem eigentlichem Projektbeginn aufsetzten und zur Verfügung haben. Continuous Integration sollte sich möglichst einfach und reibungslos in die tägliche Arbeit einführen lassen.
Sat Apr 22 19:28:36 +0200 2006 , Updated at
Code Reviews
Ich werde von nun ab hier in fortlaufenden Artikeln meine Eindrücke und Erfahrungen zu den derzeit viel diskutierten agilen Methoden niederschreiben. Input dafür bekomme ich durch das Studieren aktueller Literatur und dem Anwenden in der Praxis. Meine Favourits diesbezüglich sind die Buchtitel Practices of an Agile Developer und Ship IT!.
Der Fokus wird auf der Entwicklung von Wepapplikationen in kleinen Teams liegen bei denen die Teams bisher null bis wenig Erfahrung mit agilen Methoden haben doch aber im Kleinen damit beginnen wollen und einzelne Praktiken einführen möchten.
Hier im ersten Teil soll es um Code Reviews gehen:
Ein Code Review ist eine Art Korrekturlesen, eine Inspektion oder Durchsicht von Quelltexten durch einen anderen Entwickler. Ein Code Review soll der Verbesserung und Qualitätssicherung von Software dienen.
Wie kommt so ein Code Review zustande, wie kann das ablaufen?
Hans Dampf konnte nach 3 Stunden coden das Feature X im Modul Y für das er die Verantwortung übernommen hat umsetzten. Leider leider programmiert Hans alleine und nicht zu zweit im Pair Programming, so da� jetzt, bevor er seinen neuen Code eincheckt, er sich wie immer auf die Suche nach irgend einem andern Entwickler macht. Karl Knecht hat etwas Luft und so zeigt und erklärt Hans ihm emotionslos kurz und knapp was er da produziert hat. Ist Hans Lösung simpel, so lässt sich diese leicht erklären und Karl kann noch evtl. Verbesserungen vorschlagen oder auf Probleme hinweisen. Kann Hans nicht auf die Schnelle Karl erklären was da abläuft, dann ist nicht Karl zu doof dafür sondern der Code von Hans ist zu kompliziert und sollte überarbeitet werden. Vielleicht aber fallen Hans schon während er Karl den Code erklärt, Probleme und Fehler auf. Nach dem sich Hans und Karl sachlich 10-20min über den Code unterhalten haben war es das und somit ist Karl jetzt Pate für dieses Stück Quelltext. Hans bessert evtl. noch nach und checkt dann seinen Code ein, dabei vermerkt er in der Revision History das Karl den Code reviewt hat.
Code Reviews sollten mit wechselnden Reviewern für kleine Häppchen Code wie das mehrmals tägliche Zähneputzen etabliert werden. Kurz und knapp sollten sie sein. Sie sollten nicht als Last angesehen werden sondern eher als Möglichkeit seine Arbeit zu verbessern und von anderen Entwicklern zu lernen. So verteilt sich Wissen und Können. Dadurch das der Reviewer einen äu�eren Standpunkt hat, nicht so tief in der Implementierung steckt, fallen ihm Dinge auf die der Entwickler vor lauter Detailfragen nicht mehr wahr nimmt. Und auch alleine durch das Erklären, löst sich so manches Problem von selber auf. Man mu� halt darüber sprechen. Es sollte es egal sein, ob ein Senior als Reviewer für einen Junior dient oder umgekehrt. Jeder kann vom anderen lernen. Ein Reviewer übernimmt sozusagen die Patenschaft für dieses Codeteil.
Menschliche Aspekte kommen dabei auch ins Spiel: Scheut sich der Reviewer seinen Code zu zeigen, könnte dies daran liegen, das er ein schlechtes Gewissen hat seine dunklen Hacks preis zu geben. Andererseits sollte keiner für seinen Code gescholten werden.
Für besonderes wichtige Quelltexte sollten Reviews automatisiert ablaufen. Dies bedeutet, dass das Versions Contoll Managment automatisch nach Commits Change Notifications an die Verantwortlichen per eMail oder IRC versendet.
Hierbei gilt es den richtigen Drive zu finden. Es ist klar, daÃ? eine Ã?nderung im HTML Markup keinen Code Review braucht, wahrscheinlich auch nicht der eine gefixte Bug in Zeile 276. Wenn aber die Teilaufgaben etwas komplexer werden sind Reviews eine gute Sache.
Sat Apr 22 13:10:53 +0200 2006 , Updated at
Neues Buch: Ruby for Rails
Buchankündigungen zu den Themen Ruby und Rails gibt es mittlerweile viele, langsam aber sicher werden diese nun auch veröffentlicht.
Ganz neu auf meinem Screen als PDF: Ruby for Rails von David A. Black. Mein erster Eindruck war OK. Ruby als Sprache wird einem anhand der Programmierung mit Rails erklärt; man lernt Ruby und Rails praktisch gleichzeitig. Mir verschwimmen allerdings zu sehr die Zusammenhänge der einzelnen Komponenten des Frameworks. Mir fehlen auch etwas die Hinweise wie man selber mit der Dynamik und der OOP von Ruby kreativ sein kann. Einen Workshop oder eine Referenz gehören nicht zum Inhalt. Das Buch ist nicht illustriert, keine Bildchen, Skizzen, Diagramme oder ähnliches. Mir persönlich ist es mit zu viel (Füll)Text um einfache banale Dinge und Beispiele angereichert. Dies kann aber auch daran liegen, da� sich mit jedem zu diesem Thema neu erscheinenden Buch, Inhalte auch überschneiden werden.
Ich denke dieses Buch kann für Ruby und Rails Neueinsteiger eine 2in1 Alternative zum Programming Ruby und Agile Web Development with Rails sein. Wer detailierter und umfassender Informiert sein will würde ich eher die oben genannte Kombi zuzüglich der Rails Recipes plus Blogs empfehlen.
Mon Apr 17 21:53:13 +0200 2006 , Updated at
Rails Vortrag
UPDATE: Am 2. Mai präsentierte ich der NewMedia-Agentur Netzgiganten Ruby on Rails. Diese waren sehr interessiert und fragten auch sehr detailiert nach, sodaÃ? ich auf einige Fragen keine Antwort parat hatte. Für mich “Dunkle Ecken und Winkel” wie zB. eager loading oder Datenbank Adapter muÃ? ich jetzt erst mal “ausleuchten”.
UPDATE: 26. April; so wie es aussieht, konnte ich die Stuttgarter Internet Agentur FUF davon überzeugen, Rails in einem Projekt auszuprobieren. Wobei man auch dort wieder dem Thema Scaling/Performance kritisch gegenüber stand. Zweifel gab es auch bezüglich der Flexibilität beim Anbinden von Legacy Datenbanken.
UPDATE: Gestern, am 21. April, hatte ich die Möglichkeit im Hause des Stuttgarter eBusiness Dienstleisters DMC vor einem zahlreichen und interessierten Publikum über Ruby on Rails zu sprechen. Die grö�ten Bedenken gegenüber Ruby und Rails gab es bezüglich der Performance und Skalierbarkeit von high-traffic sites. Skepsis gab es auch gegenüber RoRs conventions over configurations Prinzips hinsichtlich der Flexibilität. Ansonsten hat der Vortrag wohl neugierig auf mehr gemacht.
UPDATE: Am Freitag dem 18. April sprach ich in einem kleinen persönlichen Kreis über Rails. Interessierte waren von Pure Media und inorange.org.
Nach dem ich am Freitag dem 14. April die Möglichkeit hatte bei der Firma Info Router meinen ersten Rails Vortrag zu halten, habe ich mich entschlossen diesen zu überarbeiten. Er kam zwar gut an, war aber Streckenweise zu codelastig und eintönig. Die neue Version, hier zum download.
Fri Apr 14 00:26:13 +0200 2006 , Updated at
MySQL Cert Dev I
...heute war easy! 100 Fragen in 2,5 Stunden. Es waren wenige knifflige Fragen dabei, teilweise waren sie wirklich banal und die Zeit hat locker gereicht. Ich bin auf den 2. Teil gespannt denn dieser soll, Berichten zufolge, schwerer sein.
Mein Rails Vortrag ist soweit fertig. Folien übers Testing sind jetzt auch drin. Es werden nur noch Korrekturen einflie�en.
Update: Der Rails Vortrag wurde neu überarbeitet, download hier.
Thu Apr 13 14:44:03 +0200 2006 , Updated at
Ich glaub das wird richtig cool!
Die Demoscene trift sich übers Osterwochenende in Bingen. Das wird ein bestimmt spannender Event. Ich bin auf jedenfall als Zuschauer dabei!
Thu Apr 13 00:44:50 +0200 2006 , Updated at
Heute bei mir angekommen!
Post von den pragmatischen Programmierern: Practices of an Agile Developer. Nach kurzen durchscannen scheint es mir, da� dieses Buch ebenso interessante und aufschlu�reiche Inhalte wie die in Ship IT!, Der Pragmatische Programmierer und My Job went to India zu bieten hat. Hoffentlich wird´s ein verregnetes Wochenende ;)
Sehr schön auch das Cover: Der Programmierer vor dessem innerem Augen das Engelchen und Teufelchen herumschwebt. Und Teufelchen versucht ihn davon zu überzeugen den dunkelsten Hack seines Coderdaseins nun einzubauen während Engelchen ihm immer nur zuruft: DRY, keep it DRY!
Thu Apr 13 00:24:19 +0200 2006 , Updated at
Ruby On Rails Vortrag
Den Vortrag den ich in den nächsten Tagen bei diversen Stuttgarter eCommerce Agenturen und Software Schmieden über Ruby (on Rails) halten werde ist fast fertig. Ich möchte nur noch ein paar Folien zum Unit- und Functional Testing hinzufügen. Eine Vorabversion gibts hier schon mal, für Anregungen wäre ich sehr dankbar.
Phuuu, morgen muÃ? ich nur noch die MySQL Zertifizierung gut hinter mich bringen und das Wochenende kann beginnen!
Update: Der Rails Vortrag wurde neu überarbeitet, download hier.
Tue Mar 21 00:46:18 +0100 2006 , Updated at
Lesebefehl: Rails Recipes
Als Ergänzung zum agile Webdevelopment with Rails gibt es jetzt noch das Kochbuch Rails Recipes als BetaBook vom pragmatischen Programmierer Chad Fowler.
Das Buch begleitet mich täglich, dort finde ich viele Anregungen und Lösungen zu real live problems. Auf bisher ~200 Seiten gibt es ~30 Rezepte, gegliedert in User Interface, Controller, Testing, Big Picture und E-Mail -Recipes. Jedes Rezept ist in einen Problem und Lösungs -Bereich unterteilt, die Codebeispiele sind kurz und aussagekräftig.
Dieses Buch knüpft an die Qualität vom preisgekrönten agile Webdevelopment with Rails ohne weiteres an und macht als BetaBook durchaus Sinn, da man es wohl eher partiel, als am Stück lesen wird.
