Man liest es überall, eine neue Eclipse Version wurde vor kurzem veröffentlicht! Die letzten Jahre immer ein Grund zur Freude, endlich kann man die diversen RCs wegschmeissen und Final installieren. Nur dieses Jahr hat mich das ganze eher kalt gelassen. Nicht weil ich Eclipse nicht benutze, als CDT-User (und ehemaliger Contributor) läuft es jeden Arbeitstag. Ist Eclipse Galileo also kein Grund zur Freude?

Wenn ich mir die sogenannte Top 10 Feature List so anschaue, dann haut es mich nicht aus den Socken.

Nummer 1 ist also die neue bereits vorhandene Update- und Installations-Komponente P2. Ganz ehrlich, wenn das Number 1 Feature das neue Updatesystem sein soll, das ist doch ein Scherz?

OSGi Declarative Services, Improved target platform management, Eclipse Modeling Project refinements, etc. interessieren mich eigentlich auch nicht weiter. Allerdings dann, auf Platz 6, Install into Self! Als (zukünftig bald wieder) Plugin-Entwickler ist das ein Segen, nicht jedes Mal eine neue Eclipse-Instanz starten zu müssen, sondern ein Plugin einfach in die aktuelle Umgebung zu deployen. Das ist für mich ein Killer-Feature, wird aber alle Nicht-Plugin-Entwickler kalt lassen.

Also doch kein Grund zu Klagen? Eclipse Galileo scheint für diverse Anwendungsbereiche neue und interessante Features zu beinhalten, und dieses breite Spektrum zeigt doch auch sehr schön, wie weit und breit Eclipse inzwischen verbreitet ist und was für ein Erfolg es als Plattform hat.

CDT

Auch das CDT hat natürlich einige Neuerungen erfahren, allerdings muss man sich bewusst sein, dass die Version von 5 nach 6 nicht etwa wegen der vielen neuen Features geändert wurde, sondern wegen inkompatibler APIs. Nichtsdestotrotz, Neues hat Einzug gehalten.

Nett ist sicherlich, dass nun auch Operatoren wie andere Funktionen behandelt werden was den Indexer anbelangt. Konkret bedeutet das, dass ein Go To Declaration auf einem Operatoren mich zu seiner Deklaration führt. Das ist sogar relativ oft nützlich, denn die Streaming-Operatoren sind häufig überladen.

Von der Refactoring-Front gibt es (leider) nicht sehr viel zu berichten. Ein Extract Local Variable wurde eingeführt, und es scheint in vielen Situationen zu funktionieren, wie meine Tests bisher ergeben haben. Aus besonders geheimen Quellen weiss ich, dass ein Change Method Signature Refactoring in Arbeit ist, wenn alles klappt werden wir das im nächsten Jahr zu sehen bekommen, wenn es heisst, Helios!

Fragt mich nicht, wie ich auf die Idee gekommen bin.

montage +frame +shadow +label -geometry 16x16+0+0 /var/tmp/kdecache-`whoami`/favicons/*.png ~/montage.png

(Klicken um zu vergrössern.)

ImageMagick ist einfach genial!

Weiss jemand, wo Firefox die Favicons ablegt?

Die Osterferien sind vorbei und es gibt einige Feeds zum durchlesen. Cocaman will wissen, wo ich (und die anderen Planet-HSRler) in der Programmer Competency Matrix stehen.

Computer Science

Data structures, algorithms und systems programming sollten nicht so ein Problem darstellen. Am ehesten vielleicht noch die Algorithmen, da gehts mit dem Master wohl langsam zum Log-Level.

Software Engineering

Hier sollte log(n) wohl drinliegen. Naja, ich hab Bzr/Mercurial/Darcs nicht ausprobiert, Git hat mich begeistert und fertig. Automated UI Tests sind eine andere Sache, ich weiss zumindest, wo die Probleme liegen und warum es sehr aufwändig ist (SWT alleine ist schon mühsam, dann aber noch Eclipse Plugins..).

Programming

“complex systems with multiple product lines”.. Systeme mit mehreren Produktlinien? Sorry, damit kann ich nicht dienen. Aber ich hab alle Productline Engineering Episoden von SE-Radio gehört. Thema Kommentare: Summary für ein File? Wenn ein File ein Summary braucht, dann ist es zu gross. Ansonsten bin ich wohl überall schon auf dem n-Level. Muss ich jetzt wirklich ein Framework schreiben? Andererseits, Template-Methods hab ich schon geschrieben, also hab ich den Punkt doch schon erfüllt

Experience

Wenn mir jemand sagt, wo ich professional experience in Functional- und Logic Programming erhalte, bitte melden. Lazy evaluation, Currying, Continuations, damit sollte ich dienen können. Auch wenn mir Continuations schon ab und zu noch Kopfzerbrechen bereiten (zumindest in nicht-Lisp).

Knowledge

“Has actually written tools and scripts, added bonus if they’ve been published.” Check! “Maintains a blog in which personal insights and thoughts on programming are shared” Check!

Im Schnitt (Experience ausgenommen) bin ich wohl auf Level n und gut unterwegs in Richtung log(n).

Also, ich denke keine schlecht Liste, eine gute Orientierung wenn man nicht mehr weiss was man noch lernen könnte und eine gute Ermahnung wenn man glaubt, man könne schon alles.

In letzter Zeit hat es gerade einen Haufen guter Videos von grossen Namen auf InfoQ gegeben:

The Evolution of Lisp by Guy Steele and Richard Gabriel.

Don Syme Answering Questions on F#, C#, Haskell and Scala.

Erik Meijer on LINQ.

Taming Effects with Functional Programming by Simon Peyton-Jones.

Wer noch nicht genug hat findet vielleicht in meinem Post über die MountainWest RubyConf 2009 Videos noch was.

Ich bin wieder ziemlich im Rückstand mit Bloggen. Nun aber endlich ein Review für ein wirklich grossartiges Buch: Pragmatic Thinking and Learning – Refactor Your Wetware.

Das Buch startet mit einem Modell, welches den Wandel vom Neuling zum Experten beschreibt, dem Dreyfus Model, sowie Erläuterungen, wie man denn auf einem gewissen Gebiet Erfahrung erlangt. Der folgende weitaus spannendere Teil handelt von unserem Gehirn, wie die beiden Teile des Hirns (L- und R-Mode) zusammenarbeiten und wie das natürlich auch ausgenützt werden kann. Immer wieder unterbrochen von kleinen Uebungen erfährt man so einiges, beispielsweise wieso man manchmal einfach nicht auf den Namen eines Filmes kommt und plötzlich: ein paar Tage fällt er einem aus heiterem Himmel ein. Nun, das ist gar nicht so aus heiterem Himmel; ein Teil unseres Gehirns arbeitet nämlich im Hintergrund genau an solchen Fragen weiter. Unser Hirn vergisst nämlich fast nichts, es hat nur nicht direkte Zugänge zu allen Informationen, nicht mehr so ganz frische müssen in einer Art Full Table Scan gesucht werden.

Bereits überzeugt vom Buch? Achtung, es wird noch besser! Im hinteren Teil werden einige Lernmethoden vorgestellt, wie die SQ3R Lesemethode. Ueberrascht hat mich auch, dass die Technik der Mindmaps in den USA anscheinend kaum verbreitet ist.

Das Buch streift eine Vielzahl an Themen, von Atemtechniken bis zu Wikis, und ist im typischen Stil der Pragmatic Programmer geschrieben – kein Wunder, ist es ja auch von Grossmeister Andy Hunt. Im Moment habe ich noch 7 Post-Its im Buch stecken, die Stellen kennzeichnen, bei denen ich noch weiterforschen muss. Das geschieht selten bei einem Buch, es muss also gut sein.

Fazit: Eine Perle im sonst immer mehr entäuschenden Angebot der Pragmatic Programmer.

Ein wunderbares Zitat von Slava Pestov über Sun’s Probleme mit Java 7:

“Shrinking resources” indeed. During the dot-dom era, Sun pumped massive resources into Java, hiring an army of mediocre programmers to crank out feature after feature, half-assed API after half-assed API. Now all those bad design decisions, complete disregard for maintainability, and backwards compatibility is really weighing them down, and they’re having trouble moving forward. [..]

It’s 2009 and only now they’re adding APIs to work with symbolic links, and move and copy files? And no closures? What a joke.

Absolute Zustimmung.

Ueber ein interessantes Beispiel an eine ziemlich unerwartete Anforderungen an eine Software bin ich heute gestolpert. Aber zuerst eine Frage: Soll ein SCM / VCS (wie auch immer) es erlauben, Code zu löschen? Und zwar auch aus der History, nicht ab einer bestimmten Revision. Ich denke, dafür ein einstimmiges «Nein» zu erhalten. «Blödsinn, muss man nicht können, ja soll man nicht mal können». Tja, anscheinend besteht dafür doch Bedarf, wie ich eben in diesem Eclipse Bug-Report gesehen habe:

We [the Eclipse Foundation, or parts of it, not sure] have a serious IP concern with DVCS’s in general. There have been several times in the past where our IP team has uncovered code in our repositories which had to be deleted. [..] How do you really really delete code across all instances in a DVCS?

Tja, unerwartet, aber doch irgendwie einleuchtend. Wir sehen, auch auf den ersten Blick unsinnige Anforderungen können eine Berechtigung haben. Was lernen wir daraus? Wir Software-Entwickler haben einen harten Job

(Ach ja, und natürlich geht das mit Git sehr wohl, allerdings ist es doch relativ hässlich. Naja, sollte es vielleicht auch sein.)

ist, dass man, wenn man einen Test mal hat, keine Lust mehr hat den Code dazu zu schreiben. Geht das auch anderen so?

Die ganze Einstellung zum Programmieren ändert sich. Wenn man direkt mit der Implementierung anfängt, dann kann man wie ein kleiner glücklicher Cowboy einfach mal draufslos hacken und experimentieren; bis mans zum laufen bringt. Wenn man die Tests schon hat, dann ist man eingeengt, es gibt nur noch ein Rot oder Grün – Tot oder Leben. Man weiss immer gleich, obs falsch oder richtig ist, das ganze Abenteuer ist zur Sau. Test First Development vermiest einem den ganzen Spass am Programmieren, wie Velofahren mit Stützrädern und Helm …

Seit einem Jahr kriege ich alle zwei Monate das Java-Spektrum (ich hatte da mal so einen Wettbewerb gewonnen) und lese es daher auch regelmässiger als früher, wo es einfach im Institut rumlag. Das Java-Spektrum hat für mich ein Highlight, und zwar das absolut beste Editorial aller Magazine die ich lese. Traurigerweise ist es häufig auch der einzige Beitrag, den ich ganz lese. Das liegt wohl nicht an der Qualität der Artikel, die Java-Welt interessiert mich einfach nicht wirklich (zuviel Business und Web Zeugs), und Heinz Kabutzs Beiträge lese ich schon in seinem Newsletter.

Ok, zurück zum Editorial, geschrieben von Michael Stal. Warum ist es so gut? Ein paar Auszüge aus der aktuellen Ausgabe:

[..] sah [ein Java-Programmierer, der in den Himmel gekommen ist] plötzlich einen .NET-Entwickler an sich vorüberziehen, und sofort erwachte in ihm die alte Wut [..] und er schrie den Engel an: «Ja, seid ihr auch hier oben, ihr verdammten Brüder?! Schau, dass du Boden gewinnst, sonst setzt es was!» Für alle Fälle gab er ihm ein paar kräftige Hiebe mit dem Netbook.

Der Engel bekam dann den Auftrag, den Brief mit den Lösungen für alle SOA und JEE-Probleme and die Botschafter des JCP auszuliefern, wurde dann aber unterwegs aufgehalten und konnte ihn leider nie überbringen..

Ausserdem scheint Stal ein grosser Fan des Hitchhikers Guide zu sein, wenn Zahlen vorkommen, dann garantiert immer auch eine 42.

So, das wollte ich einfach mal gesagt haben. Noch andere Java-Spektrum-Leser da draussen?

Gelesen habe ich das Buch bereits im Mai, aber bis jetzt gezögert, darüber zu schreiben. Nicht weil es schlecht wäre, das nicht. Nun, das Buch kommt im typischen Gewand der No-Fluff-Just-Stuff-Serie, pro Kapitel schreibt ein Autor über ein Thema. Die Gemeinsamkeit der Autoren ist, dass sie alle bei Thoughtworks arbeiten, einer der laut Eigenaussage “most influential software companies” der Welt. Andere beschreiben das typische Verhalten Thoughtworks als “[..] you have a group of former C# and Java guys running around writing shitty Ruby code and training on the client’s dime for huge fees”.

Der Inhalt hört sich ganz gut an und ist es im Grossen und Ganzen eigentlich auch:

• Solving the Business Software “Last Mile”
• One Lair and Twenty Ruby DSLs
• The Lush Landscape of Languages
• Polyglot Programming
• Object Calisthenics
• What Is an Iteration Manager Anyway?
• Project Vital Signs
• Consumer-Driven Contracts: A Service Evolution Pattern
• Domain Annotations
• Refactoring Ant Build Files
• Single-Click Software Release
• Agile vs. Waterfall Testing for Enterprise Web Apps
• Pragmatic Performance Testing

Besonders interessant war das Kapitel Object Calisthenics, in dem ein paar fundamentale Regelnd festgelegt werden, die zu besserem OO-Design führen sollten, wenn man sich nur daran hält. Dazu gehört:

• Only one level of indentation per method.
• Don’t use the else keyword.
• Wrap all primitives and strings
• Use only one dot per line (Hey, erinnert mich an Demeter’s Law).
• …
• Don’t use and getters/setters/properties

Wer wissen will, was all die Regeln genau sollen, muss sich das Buch wohl kaufen oder mal bei mir ausleihen. Aber eigentlich sollte man auch von selbst darauf kommen.

Nun, wer die No-Fluff-Just-Stuff-Bücher gerne gelesen hat, wird sich auch über dieses hier freuen.