Ich beschäftige mich ja seit einiger Zeit intensiver mit Web-Entwicklung - und da im besondern mit Cappuccino um damit GUIs in WebBrowsern zu bauen.

Cappuccino ist zwei Sachen - eine dünne Schicht JavaScript die einen Translator implementiert der aus Objective-J (Quasi Objective-C für JavaScript) normales JavaScript macht und eine Bibliothek an Objekten die der [Cocoa Bibliothek] von Apple aus dem Gesicht geschnitten ist.

Und Cocoa ist immer noch die schönste und knackigste Bibliothek die ich kenne - allerdings kenne ich auch noch nicht so viele.

Um so spannender fand ich es daher eines der Beispiele des Cappucino Projektes noch einmal in jQuery implementiert zu sehen (Blog dazu)

jQuery ist nämlich eine Bibliothek die die Möglichkeiten von JavaScript (Closures!) mal wirklich vollständig ausreizt und soweit ich das beurteilen kann ein Musterbeispiel von richtig gutem JavaScript Code ist.

Auf der anderen Seite ist Cappuccino - eine Sprache die von C portiert wurde, und die daher eben keine Closures einsetzt - weder in der Sprache, noch in der Bibliothek.

Und das rennen fängt gut für jQuery an - jQuery braucht für das gleiche Beispiel nur 45 Zeilen Code, während Cappuccino mit 400 Zeilen dabei ist - und enthält an manchen Stellen sogar noch mehr Bling! (Die Bilder faden schön ein statt einfach nur zu erscheinen)

Schaut man sich die Beispiele genauer an, stellt man fest, dass bei jQuery zu den 45 Zeilen Javascript noch mal 200 Zeilen CSS kommen und dass der JavaScript Code völlig ohne Leerzeilen auskommt, während bei Cappuccino besonders auf übersichtlichkeit geachtet wurde.

Korrigiert man das und vergleicht erneut, dann sieht das Ergebnis etwas anders aus: jQuery + CSS ~= 200 Zeilen vs. Cappuccino ~= 200 Zeilen.

Whoa.

Also muss der Vergleich inhaltlich stattfinden: Cappuccino isoliert den Applikationsentwickler komplett vom DOM und seinen Schwierigkeiten, während jQuery natürlich komplett damit Arbeitet - und man sich auch selber um die Komplikationen kümmern muss die man mit der Browserkompatibilität hat.

Dafür ist der Code von jQuery inhaltlich wirklich sehr schön kurz - ich finde man sieht ganz hervorragend was man erreichen kann wenn man benannte Parameter (hier durch JavaScript Objekt-Literale Vertreten) und konsequenten Einsatz von Closures kombiniert.

Das hier zum Beispiel:

$.each(data.items, function(i,item){
   img = new Image();
   img.src = item.media.m;
   img.onload = function() {
        $(this).animate({opacity: 1}, "normal");
   }
   $(img).css({opacity: 0}).appendTo("#content").wrap("<div></div>");
   if ( i == 20 ) return false;
   });

ist einfach sehr ausdrukstark. Ich freue mich schon darauf wenn Apple Snow-Leopard herausbringt und damit Closures auch in Objective-C einzug halten - weil dann wird auch Cappuccino diese Möglichkeiten endlich nutzen ohne die Kompatibilität mit Cocoa zu verlieren.

Auf der anderen Seite finde ich den Objective-J Code wie bei Cocoa auch sehr ausdrucksstark - und vielleicht etwas verbose. Dafür dokumentiert sich der Code aber auch ganz excellent.

Und da er nicht länger ist als der andere, sehe ich da überhaupt kein Problem.

Alles in allem also ein guter Grund jQuery zu lernen um die Möglichkeiten von JavaScript wirklich mal zu verstehen.

Spannend wars, gestern das Interview mit De:bug natürlich gings um die ganzen Piraten-Sachen - wie wir vermitteln dass wir es ernst meinen, warum man uns wählen sollte, etc.

Für mich spannender war danach das Gegeninterview wo wir den Chefredakteur mal ein bisschen zu dem Magazin fragen konnten. Erst mal das Übliche, sie beziehen ca. 80% ihrer Einnahmen aus Anzeigen und nur ca. 20% aus Magazinverkäufen. Auch spannend, das Magazin lebt letztlich seit seiner Gründung von einem Monat auf den nächsten - etwas das ich inzwischen bei vielen Magazinen vermute - auch wenn man das auf den ersten Blick gar nicht sieht.

Aber: Seit die "Wirtschaftskriese" losgebrochen ist hat das Anzeigenvollumen nicht wirklich zurückgegangen (!) - allerdings hat sich das Verhalten der Kunden verändert. Jetzt wird nicht mehr ein Jahr im Voraus geplant und gebucht, sondern nur noch von Monat zu Monat. Und das macht natürlich schlechte Planungsmöglichkeiten.

Auch fand ich sehr spannend aus meiner Sicht als Agiler Softwareentwickler auf die Zeitungsproduktion zu schauen - Jeden Monat ein Produkt von hoher Qualität auf den Punkt produzieren. Und das ganze mit gigantischem Kommunikationsoverhead - schließlich geht es ja beim Magazinproduzieren um nichts anderes.

Spannend. :)

Der erste überhaupt!

Insbesondere ist einer der betreuenden Professoren mein Onkel - daher hab ich den Link auch. :)

Das Konzept dass das Projekt rollend von einer Generation von Studenten an die nächsten weitergegeben wird find ich klasse. Code, Dokumentation, Bugs - alles kriegt man von den Vorgängern. Und da kommt noch mehr gutes: Kurze Iterationen 3 Wochen pro Iteration, klare review und status Meetings am ende jeder Iteration.

Soweit so gut. Einiges hat mir aber auch nicht so gut gefallen. Z.B.:

• Ein Semester nur Planung und Einarbeitung - in dieser Zeit wird für die simulierte Firma kein Wert erzeugt den sie Verkaufen können. Das haben die Studenten auch selber gemerkt. "Die erste Phase war recht lang und damit auch sehr kostenintensiv." No shit sherlock.
• Und natürlich lauter Spezialisten - keine Polivalente Teams
• Die ganze Suite der Rational Tools wird eingesetzt
• RUP als Prozess- mit all seiner "Schönheit"

Das Projekt wird als klassischer Wasserfall umgesetzt - und das Feedback der simulierten Kunden war dann auch klar: "Es gab da einige Momente im Projekt, da hätte man schon lange gesagt: 'Ich kündige den Vertrag und wechsle die Firma'".

Man könnte also sagen die Studenten sind optimal auf das Wirtschaftsleben vorbereitet.

Aber alle Kritik zur Seite: Das ist trotzdem noch lange das beste Software-Projekt das ich bisher gesehen habe.

Well, das neue Ubuntu sieht gut aus. Viele Details gefallen mir besser als beim vorherigen.

Insbesondere kann es jetzt korrekt die MacBook Pro Tastatur erkennen und die Konfiguration der Alt-Taste als Third-Level Chooser funktioniert jetzt auch etwas logischer (wenn auch immer noch recht versteckt).

Das einzige was absolut nicht gehen wollte war die Maus-Zeiger Integration. Aber Gott sei dank habe ich nach einigem hin und doch im Netz den entscheidenden Hinweis gefunden.

Man muss die xorg.conf mal wieder von hand anpassen...

Hrm.

Dafür geht es jetzt. 3D Integration krieg ich aber nach wie vor nicht zum laufen - während das mit Intrepid Ibex noch prima funktionierte.

Well, man kann halt nicht alles haben. :)

Beim Schimpfen über Javascript vergisst man immer gerne dass da doch relativ viel von Scheme drin ist.

Zum Glück gibt es Douglas Crockford - und der hat bei Google darüber gesprochen was die guten und schlechten sachen sind.

Sehenswert wenn man mit Javascript arbeitet / arbeiten muss.

p.s. Er hat auch JSLint geschrieben.

Während meinem Urlaub habe ich mir eine Menge Videos angesehen - so viel Zeit hat man ja sonst nicht. Allerdings nicht irgendwas. (OK, etwas Daily Show war auch dabei :)

Diese Videos haben mir besonders gut gefallen:

• Jive Talkin: DSL Design and Construction From a creator of many DSLs a short overview over the specific techniques and how he goes about doing them. (Test driven of course)
• Improving the usuability of your Ruby on Rails application A nice talk about website usability and very specific things that you can do to enhance it (with a great example)
• Tourbus A really nice talk about how to optimize ruby on rails applications (but really it's more general and can be used for anything). He especially talks about how you can easily get one to two orders of magnitude speed improvements on the first optimization pass of an app.
• BDD with Cucumber A talk about how Behaviour Driven Development works in practice and how it can be used to drive development - from a guy at Thoughtworks who gives very practical examples.
• La Dolce Vita Rubyista A talk about how agile development should be - shown in a series of short movies which are quite funny.
• Testing as Communication How Programmer Testing can be used to achieve better communication with your customers.
• Aristotle and the art of software development A talk about three major currents of philossophy - and how they may relate to software development and which programming language to choose.
• Using Metrics to take a look at your code Talk about possible code metrics and how to use them to discover and keep an eye on bad parts of your code.
• Effective and creative coding Talk of a psychologist about directed attention and how to recharge it to be a more effective and creative coder
• The Grand Unified Theory... ... of Programming. In this talk, Jim Weirich talks about Connescance as a guide to how to determine what is good and what isn't good programming.

Und auf diese Tools bin ich dabei noch mal gestoßen - dabei sind wirklich ein paar sachen die extra cool sind:

• Pivotal Tracker ein sehr schickes tool um den ganzen agilen Workflow zu begleiten, planen, abzuschätzen und transparent zu machen. Sehr heiß.
• the Rubyist Technical Magazine about ruby
• Watir - Overview Automatable Browser for websietes
• Integrity | The easy and fun automated continuous integration server Really nice and easy to use ruby continuous integration server
• Celerity | Easy and fast functional test automation for web applications headless Java browser with JavaScript support
• notahat's machinist at master Also a package to ease creation of fixture data
• thoughtbot's factory_girl at master Package to ease creation of fixture data for acceptance or unit tests
• autotest -rails | Ruby on Rails for Newbies Automaticly run test whenever you change a file
• ZenTest: Automated test scaffolding for Ruby Can Autorun ruby test suites whenever you change a file
• metric_fu: A Ruby Gem for Easy Metric Report Generation

Ich hab mich schon länger mit dem Gedanken herumgetragen dass es eigentlich mal einen schönen aktuellen CoreWar clienten für den Mac geben müsste.

Und, irgendwie kam es bisher nicht dazu - aus irgend einem Grund hat niemand einen geschrieben.

Well, jetzt hab ich mal einen minimalen Anfang gemacht um herauszufinden wie man so etwas überhaupt programmieren müsste.

[source:open-source/CoreWar Hier] ist das vorläufige Ergebnis.

WARNING: Work In Progress!

Das ist natürlich völlig unfertig - Es läuft genau nur ein Krieger (IMP) - und der auch nur weil er alleine ist. :-)

Aber, ich habe eine Abstraktion für die VM, ein View was das Ergebnis anzeigt, und ein paar Tests die auf der VM herumrödeln und schauen dass sie prinzipiell das richtige tut.

Kleinigkeiten die noch fehlen wären zum Beispiel ein Parser für Redcode, Einstellungen um die Applikation an die verschiedenen Regelwerke anpassen zu können und natürlich eine Implementierung aller Redcode Instruktionen...

Also ein Anfang. Und man sieht schon etwas. :)

Ach ja, hier noch was für echte Core War fans...

So.

Definitiv. Jedes der Videos aus dem das zusammengeschnitten wurde findet man auf Youtube.

Soo cool.

So, heute war der Open Space (mehr) als Hauptschwerpunkt - sonst gab es nicht so viel.

Der war eigentlich kurz eingeführt - am Anfang die Erklärung was die Regeln und Gesetze sind - und dann ging es auch schon los. Etwas untypisch war dass wir nur zwei Arbeitsphasen hatten und auch am Schluss kaum eine Auswertung stattfand.

Aber auch so war es schon sehr spannend.

Am Schluss noch eine Abschlusstechnik die ich schön Fand: Ein Talking Stick wurde in die Mitte des Kreises gelegt und wer wollte konnte ihn sich nehmen und etwas zu den Veranstaltern und Teilnehmern sagen.

Das hat ein wenig dazu geführt dass derjenige der den Stock hatte sich gerne etwas verquatscht hat - und das ist für diese Technik wohl auch verhältnismäßig typisch. Gleichzeitig gab es aber auch besinnliche Pausen zwischen den Beitragenden, so dass der Abschluss schön ruhig wurde.

So, und jetzt ruh ich mich aus.

Phew... anstrengend und interessant wars wieder. Thema heute war grob die tiefere Beschäftigung mit dem Thema "Welches Mindset hat der Großgruppen-Begleiter".

Der Triftige Unterschied ist nämlich, dass man beim Begleiten von Großgruppen ein völlig anderes Mindset benötigt als wenn man kleine Gruppen Begleitet. Und zwar deshalb, weil viele Techniken und Möglichkeiten die man vielleicht für kleine Gruppen noch benötigt für große Gruppen einfach nicht mehr funktionieren.

Zum Beispiel: Gestern Abend gab es vor dem Ende noch ein Stück Vortrag - die Moderatoren auf der Bühne und die Teilnehmer davor in Vortrags-Manier - in fünf Reihen.

Und das klappte nicht sehr gut. Die Moderatoren waren ohne Mikrofon kaum verständlich, die Schrift auf den Schaubildern nicht mehr Lesbar, wenn aus dem Publikum jemand etwas sagte hat man es nicht verstanden...

Heute Morgen dagegen war das Setting anders: Die Teilnehmer saßen in einem dreireihigen Kreis mit vielen Durchgängen, die Moderatoren hatten ein Stück des Kreises offen gelassen und dort ihre Pinwände aufgebaut.

Und der Unterschied war phänomenal - alle Probleme vom Vortrag waren damit Ausgeräumt. Mikrofone waren nicht mehr Notwendig, alle so nah dass die (etwas größer geschriebenen) Karten lesen konnten, Publikumsmeldungen konnten von allen verstanden werden, man hat auch gut gesehen wer etwas sagte... In kurz, eine Eindrucksvolle Demonstration was ein Unterschied eine etwas andere Technik macht - bzw. was passiert wenn man nicht geeignete Techniken einsetzt.

Heute der Tag startete nach einer Pause (sehr schönes Stilmittel!) und einer kurzen Einführung mit Murmelgruppen zu der Frage was wir für Probleme in der Großgruppen-Moderation schon hatten. Das Ziel dafür war solche Probleme zusammenzutragen um im nächsten Schritt in einem Fish Bowl nächer darauf einzugehen.

Murmelgruppen sind eine Methode die man sehr schön in fast beliebigen anderen Settings einsetzen kann um diese Aufzulockern. Die Idee ist dass die Teilnehmer in kleinen Gruppen, 2-3 Personen, zu einer bestimmten Frage diskutieren. Damit erreicht man neben einer Aktivierung jedes Teilnehmers zu einer Frage eine wesentlich größere Aktivierung bzw. deutlich gesunkene Hemmschwellen der Teilnehmer Fragen zu stellen. Ausserdem haben noch einmal alle Teilnehmer die Chance neue Personen kennenzulernen.

Der Fish-Bowl danach funktionierte so, dass sechs Freiwillige sich in einen kleinen Kreis in der Mitte setzten um dort stellvertretend für die große Gruppe eine Diskussion zu führen. Der Clou dabei: Ein siebter Stuhl bleibt frei und darf jederzeit von einem der Zuschauer "genommen" werden um ein Statement oder eine Frage oder Hinweis einzubringen (Das Fische-Füttern). Die Idee ist, dass die Technik einer wesentlich größeren Gruppe eine Fruchtbare Diskussion erlaubt als wenn einfach jeder versuchte Mitzudiskutieren. Die Technik hat natürlich auch ihre Begrenzungen - und eine davon haben wir heute direkt erlebt. Wenn das Thema nämlich nicht klar ist, oder die "Abgesandten" nicht direkt jemanden haben den sie vertreten, dann sind die Zuschauer aussen herum schnell unzufrieden mit dem Ergebnis - allerdings ist das Ergebnis immer noch viel besser als wenn einfach jeder drauflos diskutieren würde.

Wichtig für einen funktionierenden Fish-Bowl ist dabei eine klare Themen-Definition, bzw. ein klarer Auftrag an die "Abgeordneten" was sie Diskutieren sollen. Sehr gut funktioniert der Fish-Bowl auch zur Streit-Schlichtung, bzw. Diskussion zwischen zwei oder drei Gruppen - insbesondere bei emotionalen Themen. Vorteile hier sind dass die Stellvertreter die einzigen sind die Diskutieren, daher können die Personen aussen sich ganz auf die Argumente konzentrieren. Manche Teilnehmer kannten auch noch Variationen - eine Anmoderation um die Diskutanten besser zu fokussieren, eine Arbeitsgruppe pro Diskutant die sich auch während der Diskussion mit diesen Beraten darf, die freiwillige Aufgabe des Diskussionsplatzes wenn ein Diskutant das Gefühl hat dass er nichts mehr Beiträgt, und auch Varianten wo der siebte Stuhl belegt werden kann und dann freiwillig ein anderer Aufstehen muss bevor die Diskussion weitergehen darf.

Total klasse fand ich dabei auch eine Telnehmerin die sich auf den siebten Stuhl setzte und die Frage stellte, wie man denn damit umgehen könnte wenn sich Teilnehmer nicht an die Regeln halten sondern diese Einfach brechen. Das geniale daran: Danach blieb sie einfach sitzen und diskutierte im Fish-Bowl mit.

:-)

Eine Wundervolle Meta-Ebene - und es hat ganz schön lange gedauert bis die meisten Zuschauer dass überhaupt gemerkt haben was da los war. Großartig.

Nach dem Mittagessen war dann noch etwas Vortrag über das Mindset eines Großgruppen-Begleiters und danach eine Übung in der dass gehörte Umgesetzt werden sollte.

Das war dann wieder in Kleingruppen á 5 Teilnehmer in denen einer der Moderator / Begleiter war. Und es war spannend. Das Zurücknehmen als Moderator um die Gruppe Arbeiten zu lassen ist fast in keiner der Gruppen geglückt - ja es gab sogar richtiggehend Verärgertheit über die unklare Definition der Aufgabe, oder die zu klare Definition der Aufgabe und die Kritik dass die Moderator-Rolle mit so viel Kontrolle aufgefüllt wurde.

Sehr Spannend.

Zum Abschluss dann noch eine sehr schön energetisierende Technik. Die Teilnehmer standen sich in zwei Kreisen gegenüber und jedes Paar hatte je eine Minute Zeit um dem Gegenüber zu einer gegebenen Frage ("Was hast Du heute mitgenommen", "Was hat dich Schmunzeln lassen", ...) etwas zu erzählen. Nach Ablauf der Zeit ging jeder einen Schritt nach Rechts und man hatte den nächsten Partner für die nächste Frage.

Phew - das muss reichen.