Drucken unter Ubuntu mit Turbo-Print
Mit dem Wechsel auf Ubuntu 9.10 sind einige Standard-Pakete weggefallen oder umbenannt worden, die der Canon-Druckertreiber für den Canon MP-620 benötigt. Zumindest direkt nach der Freigabe von 9.10 war von Canon auch noch kein Update des Druckertreibers verfügbar.
Da bin ich auf Turbo-Print gestoßen. Turbo-Print unterstützt alle mögliche Drucker (darunter auch den Canon MP-620) und ist im Gegensatz zu den Canon-Ubuntu-Treibern auch ganz einfach zu installieren.
Einziger Wehrmutstropfen ist, dass Turbo-Print kommerziell ist – knapp 30 EUR ist jetzt aber auch nicht so viel Geld.
Und mit Turbo-Print klappt’s jetzt auch wieder mit dem Drucken.
4 comments Januar 31, 2010
Wieviel Schutz brauchen Entwickler?
Vor ein paar Tagen habe ich mit einem Web-Entwickler gesprochen, den ich sehr schätze – über Java-Script. Wir waren uns schnell einig, dass Java-Script stark unterschätzt wird.
Und dann habe ich ihn etwas ausgefragt, um mich selbst weiterzubilden. Mir ist z.B. notorisch unklar, ob es einen einheitlichen Stand der Kunst zur Definition von Klassen in Java-Script gibt. Und in dieser Diskussion sind wir auch auf private Felder und Methoden in Klassen gekommen. In Java-Script kann man beides machen, es sieht aber nicht so übersichtlich aus.
Daher macht mein Gesprächspartner das gar nicht und markiert Privates einfach mit einem führenden Unterstrich. Und das funktioniert nach seinen Aussagen auch sehr gut. Und zusätzlich muss man sich beim Unittesten nicht damit rumärgern, dass man an irgendwas nicht drankommt.
Und tatsächlich: Wenn ich an 12 Jahre Java-Entwicklung zurückdenke, habe ich kaum von privaten Methoden profitiert. Aber behindert haben sie mich ständig.
Ähnlich verhält es sich mit Konstanten. Klar muss man wissen, was konstant ist. Aber dafür reicht eine Namenskonvention. Hat mich jemals der Compiler darauf hingewiesen, dass ich versuche, eine Konstante zu ändern? Nicht, dass ich mich erinnern könnte.
1 comment Januar 26, 2010
Buchtipp “Clean Code”
Das Buch “Clean Code” von Robert Martin stand schon eine Weile in meinem Bücherregal. Ich habe es solange aufgeschobene, weil ich für mich wenig Neues erwartete. Jetzt bin ich dann endlich dazu gekommen, das Buch zu lesen. Ich hatte vor, es zu überfliegen, weil der Inhalt für mich mit 10 Jahren agiler Programmiererfahrung nicht wirklich neu sein kann.
Wirklich neu war der Inhalt auch nicht, aber aus dem Überfliegen ist auch nichts geworden. Zum einen ist das Buch so kurzweilig geschrieben, dass das Lesen Spaß macht. Zum anderen waren doch einige Abschnitte drin, die mich überrascht und zum Nachdenken angeregt haben.
Die grundsätzliche Argumentation des Buches ist, dass man sich auch um die Kleinigkeiten kümmern muss. Das ist erstmal konträr zu dem, was ich im Studium gelernt habe. Dort war eine Hauptmotivation für Module, dass man in denen das Chaos einsperren kann. Demnach müsste man die Makrostruktur sauber halten und muss sich um die Interna der Module nicht so sehr kümmern. Klang logisch. Aber sowas habe ich in 18 jahren kommerzieller Softwareentwicklung nicht erlebt. Entweder war das System auf jeder Ebene gut strukturiert oder auf jeder Ebene vergurkt. Ich denke, das hängt mit der Einstellung der Entwickler zusammen. Entweder sie interessieren sich für Qualität. Dann tun sie das auf jeder Ebene. Oder sie interessieren sich nicht für Qualität. Dann kümmern sie sich auch nicht um eine vernünftige Makro-Struktur. Robert Martin hat also Recht: Wir müssen uns um sauberen Code auch auf Mikro-Ebene kümmern.
Nur ein Beispiel für die Überraschungen, die das Buch für mich bereit hielt Robert Martin vertritt die Ansicht, dass eine Methode mit einem Parameter schon komplex ist und wenn möglich vermieden werden sollte. Mit 2 oder 3 Parametern wird es demnach noch viel schlimmer. Zuerst habe ich gedacht “naja…”. Aber seine Argumente sind gut und er hat Recht. Viele Parameter sind in sich komplex und deuten häufig darauf hin, dass wir zusätzliche Klassen benötigen oder Methoden in andere Klassen verschoben werden sollten.
Fazit: Aus meiner Sicht ist “Clean Code” ein Must-Have für jeden professionellen Softwareentwickler – egal ob agil oder nicht. Auch alte Hasen werden Nutzen daraus ziehen können.
Add comment Januar 26, 2010
Flow, Pair Programming, Teams und das Unerwartete
Ich bin jetzt endlich dazu gekommen, einen Artikel zu lesen, der schon eine Weile bei mir rumlag: “Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience” (PDF).
Auch wenn der Artikel nicht mehr ganz frisch ist, ist er dennoch sehr erfrischend. Er untersucht die Auswirkungen verschiedener Team-Organisationsformen in agilen Projekten. Zuerst belegt er die Annahme, dass Teams, die sich selbst Tasks nehmen, die effektivste Form der Arbeitsorganisation ist. Gefolgt von Teams, denen die Aufgaben zugewiesen werden, gefolgt von Individuen, die sich die Arbeit selbst nehmen, gefolgt von Individuen, die Arbeit zugewiesen bekommen. Damit ist die klassische Form der Arbeitszuweisung am wenigsten effektiv. Interessanterweise geht FDD mit seinem Class-Ownership-Konzept aber auch in diese (ineffektive) Richtung.
Richtig interessant wird der Artikel aber bei der Frage des Pair-Programming. Die Autoren haben bei sich festgestellt, dass die Enwicklung dann mit Abstand am Effektivsten war, wenn alle 90 (!) Minuten die Pair-Partner getauscht wurden. Bei wachsender Teamgröße (11 Personen) war 120 Minuten die ideale Zeitspanne, bis die Paare wieder wechseln sollten.
Das ist wirklich erstaunlich. Normalerweise geht man davon aus, dass man für hochproduktives Arbeiten im Flow arbeiten muss. Der Flow-Zustand hat aber auch Nachteile: Man braucht lange, um in den Flow-Zustand zu gelangen und wenn man drin ist, ist der Zustand fragil. Durch Unterbrechungen kann er schnell zerstört werden. Nun sagen die Ergebnisse des Papers, dass man auch ohne Flow-Zustand extrem produktiv sein kann – schließlich institutionalisiert das extrem häufige Wechseln des Pair-Partners ja gerade die Unterbrechungen. Dadurch geht man immer wieder mit einer neuen Perspektive an die Aufgabe heran (“Beginners Mind”) und kommt so auf die besten Ideen. Und das ist offenbar sehr produktiv.
Und an dieser Stelle finde ich den Artikel auf einer Meta-Ebene sehr interessant: Die Autoren haben ein “Naturgesetz” in Frage gestellt – nämlich dass hochproduktives Arbeiten nur im Flow möglich ist. Und so konnten sie etwas wirklich Neues entdecken. Respekt!
4 comments Januar 18, 2010
Festpreise, Aufwandsprojekte und dann?
Vor kurzem habe ich hier zu Festpreisen und Aufwandsprojekten geschrieben. Und ich hatte versprochen noch etwas mehr dazu zu schreiben.
Das große Problem an beiden Vertragsformen ist ihre Kostenorientierung. Die Kosten stehen im Vordergrund und damit gehen auch immer alle Diskussionen in Richtung Kostenreduktion.
Ich möchte keine Kostenstelle sein! Ich will Geschäftswert schaffen.
Wie wäre es also zur Abwechslung mal mit wertorientierten Vertragsformen? Warum lassen wir uns als Softwareentwickler nicht prozentual an den Werten beteiligen, die unsere Software für den Auftraggeber schafft?
Dann haben Auftragnehmer und Auftraggeber dasselbe Ziel. Und wenn der Auftragnehmer durch Scrum ganz furchtbar produktiv wird, profitiert er auch davon.
Neu ist die Idee übrigens nicht. Kent Beck hat schon in der zweiten Auflage des XP-Buchs “Pay per Use” gefordert; ein mögliches Vertragsmodell, aber nicht das einzige.
2 comments Januar 15, 2010
Lernen im 4. Quartal 2009
Damit habe ich mich im 4. Quartal 2009 beschäftigt und das habe ich dabei gelernt:
- Ich habe mir Cruise-Control Ruby angesehen und damit die Testausführung in einem Rails-Projekt automatisiert. Ich bin nicht überzeugt von dem Tool. Zu umständlich für das bisschen, was es leistet.
- Hudson kann mehr und ist auch nicht komplizierter.
- Ich habe weiter Rails programmiert und insbesondere mein Verständnis der DB-Migration verbessert.
- In diesem Zusammenhang habe ich mit auch jQuery und jQuery-UI angesehen und bin davon ganz angetan.
- Ich habe mehrere Präsentationen mit Prezi erstellt und gehalten. Das war lustig. Meiner Erfahrungen dazu hatte ich bereits in einem anderen Blog-Eintrag beschrieben.
- Im Rahmen einer Artikelvorbereitung habe ich mich näher mit BDD beschäftigt und etwas mit easyB programmiert. Ich finde easyB echt nett, um Tests äh Spezifikationen für Groovy-Code zu schreiben.
- Für ein Projekt habe ich Python-Skripte programmiert. Das war lustig. Nette Sprache.
- Ich habe bei einem Kunden mehr Kanban in der Praxis erlebt und dabei ein paar interessante Einsichten gewonnen. Mehr dazu auf der OOP und in späteren Blog-Einträgen.
- Ich habe gelernt, dass man in einer Linux-Shell Strg+R drücken kann, um in der Shell-History zu suchen. Das ist echt nützlich.
- Ich habe das Buch “Sexy Webdesign” gelesen. Meine Einschätzung dazu hatte ich bereits in einem anderen Blog-Eintrag beschrieben.
- Durch das Buch bin ich auf die Layouthilfe 960.gs gestoßen. Das sieht auch echt nützlich aus.
- Ich habe etwas mit der A3-Analysetechnik aus dem Toyota-Production-System experimentiert und dabei festgestellt, dass das gar nicht so einfach ist. Aber hilfreich war es dann doch.
- Ich habe in einem Java-Projekt etwas Jersey programmiert, um ein REST-API zu erstellen. Schön einfach. Ist man von Java ja gar nicht gewohnt
- Für die XP-Days Germany musste ich mehrere Code-Katas vorbereiten. Dabei habe ich gemerkt, wie überraschend viel man lernen kann, wenn man mehrfach hintereinander dasselbe Beispiel programmiert. Diese Erfahrung habe ich in einem anderen Blog-Eintrag beschrieben.
- Ich habe das Buch X-Teams gelesen. Meine Einschätzung habe ich hier beschrieben.
- Nachdem ich mir von meinem Bruder im 3. Quartal die richtige Brustschwimm-Technik habe zeigen lassen, habe ich das Brustschwimmen geübt und kann das jetzt einigermaßen (letzter Wert: 1.000 Meter am Stück). Das war am Anfang wirklich ein komisches Gefühl: Ich paddel unbeholfen zwischen den ganzen Halbprofi-Schwimmern rum und mache mich dabei mehr oder weniger lächerlich. Das hat mir ein Gefühl dafür vermittelt, wie schwer es mitunter für Schulungsteilnehmer sein muss. Man macht in einem Bereich mehr oder weniger öffentlich, dass man in diesem Bereich von Tuten und Blasen keine Ahnung hat. Das kann schon eine ganz schöbe Überwindung bedeuten.
Add comment Januar 14, 2010
Code Kata Bunkai: Prime Factors
Bernd Schiffer has published a screencast of the Prime Factors Code Kata that we prepared.
When a programmer new to TDD watches such a code kata he has the same problem that an unexperiences karate student has when he watches a karate kata. He can see what’s happening but he has no idea why.
In karate there is a second kata flavour: Bunkai:
Bunkai literally meaning “analysis” or “disassembly”, is a term used in Japanese martial arts referring to the application of fighting techniques extracted from the moves of a “form” (kata) (see Wikipedia).
When watching a kata bunkai it becomes pretty obvious why the moves of the kata are done.
The same should be possible with code katas. Therefore we tried to transfer the bunkai concept to code katas. For now that simply means that the non obvious parts of the code kata are explained. I published the result for the prime factors code kata on YouTube.
I have to confess that I simply cut Bernds video. I think the real code kata bunkai should include the explanation in the kata – like it is in karate. We will work on that.
11 comments Januar 7, 2010
Festpreise und schneller durch Scrum
Boris Gloger hat zwei Blogeinträge zu Festpreisen und Scrum geschrieben (hier und da) und dabei interessante Thesen vertreten. Die Abrechnung
nach Time&Material könne problematisch sein, wenn man nach Scrum arbeitet. Sein Argument ist, dass der Anbieter dann einfach Tagessätze abrechnet und keine große Motivation hat, effektiver zu arbeiten. Aber genau dafür sei Scrum da: effektiver Arbeiten. Ich finde das Argument soweit nachvollziehbar.
Eine Alternative dazu könne ein Festpreis sein – das vertritt auch Jeff Sutherland mit seinem “Money for Nothing, Change for Free”. Wer Scrum richtig macht, sei deutlich effizienter als ein klassischer Anbieter und könne daher mit Festpreisen sehr hohe Margen erreichen. Auch das finde ich erstmal nachvollziehbar.
Aber:
Wir haben uns vor ein paar Jahren um ein Multi-Millionen-Euro-Projekt beworben. Nach einigen Auswahlrunden waren noch wir übrig und ein anderer Anbieter. Der andere Anbieter geht klassisch vor und ist viel größer als wir. Wir haben die Entwicklung zu einem Bruchteil des Preises angeboten, die der andere Anbieter angeboten hat. Ich glaube, unsere Aufwandsschätzung hätte gepasst. Wir wären also tatsächlich deutlich effektiver gewesen als der Anbieter. Scrum sei Dank.
Und jetzt passierte etwas sehr Merkwürdiges. Der Auftraggeber meldete sich bei uns und meinte, unser Angebot sei zu billig und damit
unglaubwürdig. Uns wurde empfohlen, Aufwände für Projektleitung, Testen, Dokumentation etc. extra auszuweisen und damit den Aufwand in “glaubwürdige” Regionen zu bringen. Also haben wir das gemacht. Letztlich waren wir damit immer noch erkennbar günstiger als der andere Anbieter, aber nicht mehr so dramatisch. Und wir haben unsere Margen erhöht.
Damit war der Auftraggeber zufrieden und hat sich für den anderen Anbieter entschieden. Die Argumentation des Vorstandes ging dann wahrscheinlich so: “OK, A ist etwas günstiger, aber B ist größer. Da sind wir auf der sicheren Seite. Also nehmen wir die Mehrkosten in Kauf.”
Dass wir soviel effektiver waren als die Konkurrenz hat uns also gar nichts genützt.
Ich glaube, es gibt jenseits von Time&Material und Festpreis andere Vertragsmodelle, die besser zu Scrum passen (und natürlich kann man prinzipiell Time&Material und Festpreise mit Scrum machen). Ich werde dazu später noch etwas schreiben.
4 comments Januar 6, 2010
Katacast: Screencast zu Code-Kata – Primfaktorzerlegung
Ich habe zusammen mit Bernd Schiffer in mehreren Iterationen an der Code-Kata zur Primfaktorzerlegung gearbeitet. Jetzt hat Bernd den dazugehörigen Screencast veröffentlicht. Die Kata selbst führt Bernd vor.
Add comment Dezember 26, 2009
Scrum bei Startups
In meinen Scrum-Kursen begegne ich immer häufiger Leuten, die direkt oder indirekt davon betroffen sind, dass Venture-Capital-Geber (VCs) wünschen, dass IT-Startups Scrum einsetzen. Bei einigen Geldgebern gibt es wohl gar keine Kohle mehr für IT-Startups, wenn sie nicht Scrum machen.
Das ist auf jeden Fall ein starkes Signal. Der Job der VCs besteht darin, die erfolgversprechenden Startups von denen zu unterscheiden, die keine Chance auf Erfolg haben. Und wenn die VCs jetzt immer stärker in Richtung Scrum drängen, dann bedeutet das wohl, dass sie Scrum als Erfolgsfaktor für Startups ausgemacht haben.
Das bedeutet natürlich noch lange nicht, dass die VCs wirklich verstanden haben, was Scrum ist. Aber das spielt in ihrer Position auch höchstens eine untergeordnete Rolle. Oder doch? Brauchen wir “Scrum für VCs”-Kurse?
Ob es viel bringt, die Startups zu Scrum zu zwingen kann man natürlich in Frage stellen. Wenn die Startups das nicht von sich aus wollen, werden sie Scrum wahrscheinlich auch nicht richtig hinkriegen. Sie werden Scrum bei Bedarf mit mehr oder weniger großem schauspielerischem Talent aufführen: Scrum-Schauspieler. Aber dadurch erreichen sie die erhofften Effekte nicht.
Es gibt allerdings auch Startups, die Scrum bisher einfach nicht oder nicht richtig kennen. Und da kann ein Schubs in Richtung Scrum durchaus hilfreich sein.
2 comments Dezember 16, 2009
