wuetender-junger-mann.de

My recent effort to build a tool that takes a grammar and creates a DOM and a parser for that DSL, have become more than obsolete. I just had a look at the xtext tutorials. Xtext not only creates a (EMF)-DOM and a Parser, but it also generates fully-fledged eclipse toooling, editor with syntax highlighting, error checking, code completion, and outline view.

Speaking of JetBrains I should mention that I had a look at the online demo of their new GUI-Designer. It’s quite amazing. It brings the IntelliJ-principle to GUI-Design.

Last night we had Dmitry Jemerov of JetBrains around our office to show us their new continuous integration/ collaboration solution Team City.

It consists of an IDE-independent server, that in turn can use different machines to perform builds and to tests and static code analysis. Additionally there is a very nice Integration into the IntelliJ-IDE. Apart from that the IDE got an instant messenger (JABBER-based), which allows for cool things like sending code-pointers and navigable stack-traces to your co-workers.

It looks very promising. Version 1.0 will be out around September. The only thing that is not yet there is support for depencies among different projects, but it’s scheduled for version 1.5.

Habe gerade bei Martin Fowler von Buildix gelesen. Das ist ein knoppixbasiertes Teil mit SVN, cruisecontrol und allerlei anderen nützlichen Tools für Continuous Integration und agiles Projektmanagement.

Damit gibt es keine Ausreden mehr!

In my Opinion the only valid argument for static typing is better tool support. While refactoring capabilites of state-of-the-art Java IDEs are pretty
good, there are other possibilities to assist the developer.

One such way is shown by Prospector a tool to mine APIs for jungloids. That is calls or call chains that return an object of a desired type for an object of a given type. It is a kind of query engine over your (or better someone else’s) code base. If you start with an IFile object in eclipse you might want to get the containing IProject. Prospector will then propose call chains to get the desired return type.

The approach is detailed in a
paper
and there are also some
slides

available.

Eitan Suez has just open-sourced his JMatter framework which is an implementation of the Naked Object Paradigm explained in a Book
by Pawson and Matthews.

This Programming Model seems to be very expressive. As far as I know JMatter is the first professional implementation, that provides persistency in a database as well as a rather nice UI and a useful set of base classes.

In the documentation there’s a chapter on the desktop, which describes the author’s vision of a desktop of objects. I think the consquences of applications beeing deployed as a set of classes into an objectframework are quite amazing. It reminded me of Dan Ingalls Byte article on the Design Principles Behind Smalltalk, where he argues that there shouldn’t be an operating system, which goes beyond the object runtime. He states: “An operating system is a collection of things that don’t fit into a language. There shouldn’t be one.”

Another interesting implication is the fact that JMatter provides a dramatic productivity boost which will lead to severe problems for those teams building everything from scratch. On the other hand new applications will become feasible due to falling prices.
There’s a lucid post by John Reynold’s.

I think this thing goes well beyond the scope of ruby on rails. Though it’s somewhat more complex due to the more static nature of the java language.

Seit heute bin ich Abonent von Dr. Dobb’s Journal. Das erste Examplar habe ich gerade aus der Plastikhülle geholt. Ich weiß nicht warum ich das nicht schon viel früher gemacht habe. Die Zeitung ist legendär und wer sie kennt gehört wahrscheinlich zur guten Seite.

Nachdem ich mich letzte Woche mit eGroupWare als serverseitige Lösung meiner Informationsmanagementprobleme beschäftigt habe, ging es diese Woche an den Client.

Neben der Weboberfläche bietet eGroupWare verschiedene Integrationsmechanismen. Dabei kann man einerseits offene Standards, z.B. IMAP und LDAP nutzen, andererseits wird auch ein proprietäres XML-RPC Interface angeboten – Plugins für Outlook und Kontakt existieren, meine im Moment favorisierte Lösung ist allerdings Thunderbird.

Kurz ich kam darauf, dass ich meinen eigenen Client bauen müsste. Hybris – ich weiß…
Die Plattform war rasch definiert: Eclipse RCP + db4o + Ristretto + commons, allein mit der Implementierung gibt’s Probleme.

Als Vorarbeit habe ich mich zunächst mit IMAP beschäftigt. Dabei habe ich mit Ristretto, einer Java Mail Library gearbeitet und festgestellt, dass IMAP doch eher starr ist.

Als clientseitige Persistenzlösung habe ich mit db4o gespielt. Das ist ganz großes Kino! Mein Idee ist jetzt auch ein GroupWare-Backend zu schreiben und die Mails mit in der Datenbank zu verwalten. Die Mail-Protokolle also nur als Schnittstelle.

Wahrscheintlich geht das alles vorüber, aber die Idee eines durchgängigen OO-Systems, das ich selber erweitern kann, erscheint bestechend.

Heute stellte sich mir zum zweiten Mal innert kurzer Zeit die aufgabe Elemente einer flachen Liste nach bestimmten Kriterien zu gruppieren. Da der Code dafür eher fehleranfällig ist, hatte ich mir vorgenommen die Sache wiederverwendbar zu implementieren. Dazu griff ich zunächst zu Ruby.

Die entstandene Funktion wird so verwendet, um eine Liste von Namen in eine Map zu überführen, die für jeden Anfangsbuchstaben eine Liste von Namen enthält:

require 'pp'

names = ["Felix","Alexey","Frank","Ivan","Irina"]
grouped_names = group(names) { |element|
element[0..0]
</blockquote> <code> } pp grouped_names

Die Ausgabe sieht ganz vernünftig aus:

{"A"=>["Alexey"], "F"=>["Felix", "Frank"], "I"=>["Ivan", "Irina"]}

Und nun zur Implementierung:

def group(list, &category)

map=Hash.new
list.each{|element|

cat=category.call(element)
if (map.has_key?(cat))

grp=map[cat]

else

grp=Array.new
map[cat]=grp;

end
grp< <(element);
}
return map
end

Ich fand's so schön, dass ich beinahe weinen musste, aber nur beinahe.

Ich wurde allerdings gleich wieder wütend, als ich feststellte, dass ich bei WordPress nicht weiß, wie man code snippets einbindet...

Die letzten paar Wochen habe ich mir Domain Driven Design von Eric Evans reingezogen. Das Buch ist formal im Pattern Stil aufgemacht, aber tatsächlich werden immer kleine Entwicklungsgeschichten erzählt. Das erste Kapitel widmet sich der Ubiqitious Language. Evans argumentiert, dass Softwareentwicklung Wissensverarbeitung sei und dabei eine einheitliche Sprache des Aufgabengebiets erarbeitert werden muss. Bei einem Domain Driven Designs muss sich diese Sprache im Design/ Code wiederfinden.

Ein weiterer Teil behandelt die Bausteine des Domain Models. Dabei werden verschiedene Konzepte wie Entity, Value Object und Aggregat eingeführt, die in UML-Sprech Stereotypen für die eigentlich Domain Klassen darstellen.

Außerdem wird ausführlich auf den Prozess der Entwicklung als iterativer Erkenntnisgewinn eingegangen. Auch hier formuliert Evans bestimmte Erfahrungen als Patterns. Besonders Gefallen hat mir der Breakthrough. Ein Breakthrough ist ein Refactoring mit dem sich plötzlich ungeahnte Möglichkeiten auftun, also der inkrementelle Erweiterungsprozess an eine Grenze stößt und ein Refactoring zu einer tieferen Einsicht und einem Durchbruch führt.

Das wesentliche Verdienst des Buchs besteht für mich darin, dass viele Erfahrungen und Konzepte, die ich bisher nur erahnt habe, explizit beschrieben werden. Einige Patterns waren mir völlig unbekannt. Der Stil ist geprägt von anschaulichen Beispiele teilweise auch aus technischen Anwendungen. Verdikt: Unbedingt lesen!