Blog

Alfa Romeo Giulietta im Motorsport

Es hat etwas gedauert, aber jetzt ist sie fertig: Die halbwegs komplette Liste von allen Serien, wo die Alfa Romeo Giulietta (Typ 940, also die aktuelle) in Rennen eingesetzt wird oder wurde.

Wieso mache ich das? Vor allem weil ich das Auto jeden Tag selbst fahre (nicht in Rennen) und neugierig war. Aber es hat auch viel damit zu tun, dass die Giulietta schon jetzt und sicher noch mehr in der Zukunft unfairerweise als ein Tiefpunkt in der langen Geschichte Alfa Romeos angesehen wird. Das hat wenig bis gar nichts mit dem Auto an sich zu tun. Die Giulietta macht Spaß beim Fahren, sieht gut aus, ist praktisch und für Alfas äußerst zuverlässig. Das echte Problem ist, dass 2011 der Alfa 159 eingestellt wurde, weil Fiat in der selben Fabrik mehr Pandas bauen wollte. Seitdem bis zur Einführung der Giulia war die Giulietta, eine gut aussehende aber letztlich harmlose Rivalin für den VW Golf, das Topmodell einer der besten Marken der Automobilwelt. Und das ist tatsächlich ein Tiefpunkt.

Dazu kommt das Alfa Romeo eine lange Geschichte im Motorsport hat. Unter anderem gewann Alfa das erste Formel 1 Rennen überhaupt, und Enzo Ferrari hatte hier seine Karriere gestartet. Die Geschichte ist voll von bekannten und tollen Rennautos… bis 2004, als der Alfa 147 Cup endete. Seit dem gibt es keine werksunterstützten Rennprojekte von Alfa mehr. Es gibt zwar immer wieder Gerüchte, dass Alfa ein die DTM einsteigen könnte, aber es scheint gleichzeitig klar, dass Alfa daran kein Interesse hat. Statt dessen könnte Alfa in die Formel 1 einsteigen… in dem Ferrari-Motoren vom Vorjahr ein neues Logo drauf kriegen und an kleine Teams verkauft werden. Seeeeehr spannend. Aber es gibt tatsächlich immer noch Rennen mit Alfa Romeos, die spannend und lustig sind, und die größtenteils mit der Giulietta fahren. Ich habe wenigstens sieben verschiedene Projekte von verschiedenen Teams gefunden.

TCR

TCR ist eine relativ neue Rennautoklasse, entworfen um spannende Rennen bei relativ wenig Kapitaleinsatz zu ermöglichen, mit Autos die sehr dramatisch aussehen aber für viele verschiedene Teams bezahlbar bleiben. Eingesetzt wird die Serie in verschiedenen regionalen Serien, einer internationalen Serie die mehr oder weniger das Flaggschiff ist, und in verschiedenen Langstreckenrennen.

Die Spezifikationen sind direkt basierend auf dem SEAT Leon Cup, und die Autos werden größtenteils von mehr oder weniger unabhängigen Tunern entworfen. Ein entscheidender Teil des Konzepts sind gewaltige Spoiler und Motoren die auf 350 PS gebracht wurden. Derzeit sind elf verschiedene Marken mit ihren Autos vertreten, und es werden immer mehr. Auch die Alfa Romeo Giulietta gehört dazu, wobei hier die Rennversion vom italienischen Tuner Romeo Ferraris entworfen wurde (trotz des Namens hat die Firma keinen direkten Bezug zu einer von beiden Herstellern). Die Unterstützung von Alfa hat sich anscheinend auf ein herzliches „Viel Erfolg!“ beschränkt; etwas enttäuschend wenn man sieht das zum Beispiel Volkswagen den Golf GTI TCR selbst entwickelt und vertreibt. Und den SEAT Leon, und den Audi RS3 natürlich… Trotz dem hat die Giulietta TCR bewiesen, dass sie Rennen gewinnen kann.

Zuerst eingesetzt wurde sie in der 2016er Saison, vom Romeo Ferraris-Team. Dort zeigte sie noch zu wenig Leistung und enormes Verbesserungspotential. Das Team setzte ein paar Rennen aus und kam gegen Ende der Saison mit einer verbesserten aber noch nicht konkurrenzfähigen Version zurück. Im Winter wurde dann noch härter gearbeitet, und Anfang 2017 fuhr sie in der TCR Middle East, eine sehr kleine Serie in der vor allem verschiedene Europäische Teams ihre Autos testeten. Hier konnten immerhin schon ein paar zweite Plätze erzielt werden.

Jetzt ist sie in der internationalen Serie, und hat gleich das allererste Rennen der Saison gewonnen. Seit dem gab es auch weitere Siege und Podiumsplätze. Die Ergebnisse sind immer noch etwas zu durchwachsen um wirklich um die Meisterschaft mitzufahren, aber es wird definitiv besser.

Ein Hinweis zu Teamnamen: 2016 war das Team „Romeo Ferraris“. In der Middle-East Serie fuhr die Giulietta unter „Mulsanne Racing“, und jetzt läuft das ganze unter „GE-Force racing“. So weit ich das beurteilen kann scheint es im Prinzip immer das selbe Team im Kern zu sein, mit den Leuten von Romeo Ferraris in allen Schlüsselpositionen, wie z.B. Michele Cerruti, Fahrerin, Teammanagerin und eine der Personen die das Auto entwickelt haben. Darüber hinaus verkauft Romeo Ferraris die Giulietta aber auch an andere Teams. Derzeit weiß ich von zwei Verkäufen.

Zuerst hat das ungarische Team Unicorse eine rote Giulietta gekauft. Diese fuhr als Gaststarter im ungarischen Lauf der internationalen Serie mit, ohne interessante Platzierungen zu erreichen. Es gab Ankündigungen, dass das Team damit in der ETCC fahren wollte, eine andere Tourenwagen-Serie die seit einiger Zeit auch TCR-Autos erlaubt, aber das ist zumindest bis jetzt noch nicht passiert.

Zwei weitere Giuliettas gehören V-Action und fahren seit ein paar Wochen in der TCR Italy-Serie. Eine davon fuhr auch als Gaststarter im letzten Lauf der TCR Germany. Wir kommen auf die TCR Italy gleich wieder zu sprechen.

Zusammengefasst muss man aber sagen, dass die TCR-Version ziemlich sicher die Königin der Giuliettas ist, und ich kann die Serie (auch sonst) sehr empfehlen. Alle Rennen sind live und als Aufzeichnung kostenlos auf Youtube.

TCT

Jetzt wird es kompliziert. Die TCR Italy erlaubt auch Fahrzeuge einer anderen Klasse, die TCT heißt. Diese Klasse hat die selben technischen Daten wie die TCR, aber die Autos brauchen nur eine nationale statt einer internationalen Lizenz. Ich vermute, dass dies die Kosten reduziert oder reduzieren soll. TCT steht in diesem Zusammenhang nicht für Twin-Clutch-Transmission oder deutsch Doppelkupplungsgetriebe, ein Feature dass man auch in der normalen Giulietta kriegt und was das Googeln nach diesem Thema nicht erleichtert.

Das Team Etruria hat eine TCT-Giulietta entwickelt und zwei davon eingesetzt. Die allgemeinen technischen Daten sind denen von Romeo Ferraris sehr ähnlich, was bei gleichen Reglements auch zu erwarten war, aber es ist erstaunlich wie anders das fertige Auto doch aussieht. Spoiler, Kotflügel und Lufteinlässe sind völlig anders, und meines Erachtens deutlich hässlicher umgesetzt.

Diese Autos fuhren 2016 und in einigen Rennen in der 2017er-Serie. In beiden Fällen waren sie höchstens Mittelfeld gegenüber den TCR-Autos. Bis jetzt wurden sie nicht in Rennen eingesetzt, wo auch die TCR-Giulietta fuhr, und es würde mich nicht wundern wenn sie gar nicht mehr fahren - einer der Fahrer hat schon Etruria mit TCT zu V-Action mit TCR gewechselt. Daher werden wir wohl leider nie direkt sehen, welche Giulietta auf der Rennstrecke wirklich schneller ist.

Aber das ist noch nicht alles. In der TCT-Kategorie fuhr auch eine Giulietta von Gianni Giudici, ein Mensch der noch öfter auftauchen wird. Wie man auf dem Bild sieht, ist das ein ganz anderes Auto, dass deutlich näher an der normalen Straßenversion ist, abgesehen von dem großen Heckflügel. Ich habe keine Ahnung was da die Story ist, aber ich kann raten. Giudici hatte vorher auch schon Giuliettas in der VLN eingesetzt (siehe unten). Könnte es sein dass es sich um ein Auto aus diesem Projekt handelt, was durch die VLN-Spezifikation nicht mehr ins TCS-Reglement passte (siehe nicht ganz so weit unten)? Aber wo kommt dann der Heckflügel her? Der ist in der TCR tatsächlich vorgeschrieben, aber ob das so auch für die TCT zutrifft weiß ich nicht. So oder so, das Auto tauchte bei genau einem Lauf auf und zeigte sich allen anderen TCR und TCT-Autos deutlich unterlegen.

TCS

TCS ist noch ein weiteres Reglement für italienische Tourenwagen, mit einer langen und komplizierten Geschichte. Zeitweilig war TCS das einzige Reglement für die italienische Tourenwagenserie. Im relevanten Zeitraum war sie 2015 und 2016 eine zusätzliche Kategorie in der TCR Italy, und ist 2017 eine eigene Serie in der vor allem aber nicht nur Seat-Kombis fahren.

Das grundlegende Prinzip hier ist deutlich einfacher und näher an der Straßenversion. Die Autos kriegen Sicherheitsfeatures wie Überrollbügel, ein bisschen Überarbeitung an Aufhängung und Motorsteuerung, aber keine massiven Flügel, ausgestellten Radläufe oder ähnliches. Es gibt weitere Untereinteilungen nach Hubraum, wie TCS 2.0, TCS 1.8 und TCS 1.4.

Bei all diesen Serien muss man sagen, dass es deutlich mehr Ankündigungen gab als echt Autos gefahren sind, und da alle Informationen auf italienisch sind bin ich mir hier noch unsicherer ob meine Informationen stimmen als sonst. So oder so:

Dieses Jahr, 2017, ist keine Giulietta in der TCS-Serie gefahren. Leone Motorsport hatte eigentlich angekündigt, eine einzusetzen, und damit immerhin eine Doppelseite in einer italienischen Motorsportzeitung gekriegt, aber tatsächlich ist sie in keiner Ergebnisliste aufgetaucht.

Das Team hatte aber schon 2016 so etwas versucht und tauchte in zwei Läufen auf. Im Ersten endete das ganze mit einem „Not Classified“ im freien Training. Wusste nicht, dass so etwas geht. Später schaffte es das Auto immerhin in zwei Rennen am selben Wochenende (die meisten dieser Serien haben zwei kurze Rennen an einem Wochenende), kam aber in beiden Fällen nicht ans Ziel. Das, obwohl man zwischen beiden Rennen auch noch den Fahrer ausgewechselt hatte.

Davon unabhängig (glaube ich) tauchte auch hier Gianni Giudici wieder auf, bei einem einzigen Lauf 2015 in Monza. Ob das etwas mit seinen Projekten bei der VLN oder in Monza zu tun hatte weiß ich nicht, und mit einem neunten Platz bei zehn Autos im Ziel nach dem er vorher nicht ins Ziel kam war er auch nicht sonderlich erfolgreich.

Die erfolgreichsten Alfas waren tatsächlich 2016 zwei Mitos, obwohl der nun wirklich ein Auto ist dass mir relativ wenig gefällt. Ich übertreibe vielleicht, aber eine hohe Sitzposition und gefühllose Lenkung ergeben ein relativ langweiliges Fahrgefühl. Aber egal; die Rennversion, von Tecnodom, ist äußerst orange und halbwegs erfolgreich. Sie gewannen immerhin häufiger die TCS 1.4 Kategorie selbst wenn sie nicht die einzigen Autos darin waren (das heißt sie waren vor dem einen Fiat 500 in dieser Klasse), und waren teilweise besser als einzelne TCS 1.8 Autos. Sie sind aber nie in einem Rennen mit den TCS-Giuliettas gefahren (Gegenüber den TCT-Giuliettas blieben sie erwartungsgemäß weit zurück).

VLN

Ich habe Gianni Giudici schon ein paar mal erwähnt, aber diese Serie scheint sein Hauptgebiet gewesen zu sein. Die VLN ist eine Langstreckenserie mit Rennen die immer wenigstens sechs Stunden dauern. Organisiert wird sie von der Veranstaltergemeinschaft Langstrecke Nürburgring; von diesem niedlichen Namen kommt auch die Abkürzung.

Die Website der Serie ist komplett deutsch, aber liefert leider praktisch keine historischen Daten, was es recht schwer macht zu überprüfen wann und wo die Giulietta denn nun tatsächlich fuhr. Nach dem was ich dort und auf Fanseiten sah, fuhr die Giulietta zumindest ein Rennen und erreichte dort Platz drei in ihrer Kategorie… von vier. In einem anderen Lauf (denke ich) hatte das Auto einen größeren Unfall. Das Projekt ist trotzdem bemerkenswert, weil einer der Fahrer kein geringerer ist als Nicola Larini, einer der Legenden der guten alten DTM mit dem Alfa 155 V6 TI.

Das ist übrigens nicht das einzige Mal, dass Larini in Renngiuliettas fuhr. Bei der TCR-Serie gibt es eine „Balance of Performance“-Regelung, bei der jedes zugelassene Auto bei einem großen Test auf seine Leistung getestet wird, und dann Ballast dazu addiert oder abgezogen kriegt. Larini ist einer von zwei (früher der einzige) Rennfahrern, die jedes Auto fahren und damit die Performance bewerten, die Giulietta natürlich eingeschlossen.

Zu Gianni Giudici muss noch gesagt werden, dass er wirklich groß darin ist Sachen anzukündigen, die dann so nicht passieren. Unter anderem wollte er neben Larini auch Nannini, den anderen der bekanntesten DTM-Fahrer anheuern. Und es gab wohl auch Pläne, dass er eine eigene TCR-Giulietta designen und fahren wollte, was ebenfalls bis jetzt nicht passiert ist. Das soll kein Vorwurf sein, ich habe keine Ahnung was hinter den Szenen abläuft, und er ist bei weitem nicht der einzige im Feld der Unbekannten kleinen Tourenwagenserien. Aber er hat anscheinend einen guten grafischen Designer und eine gute PR-Abteilung, was dazu führt dass man in seinem Umfeld auf Google ständig Ankündigungen und Bilder von Autos findet, die so nie tatsächlich existierten.

BTCC

Nach dem ganzen Oben bin ich jetzt kein großer Fan von Vorankündigungen, aber diese ist zu oft wiederholt worden um sie zu unterschlagen. Die British Touring Car Championship ist eine Serie mit ihrem eigenen Reglement, die irgendwo zwischen den Silhoutten-Rennwagen der DTM und den mehr serienbasierten Autos der TCR angesiedelt ist. Die Karosserie kommt zwar aus der Serie, aber alles darunter kommt weg, und es werden insbesondere standardisierte Fahrwerke und Radaufhängungen verwendet. Standardisierte Motoren sind verfügbar aber nicht verpflichtend.

2018 will Handy Motorsport, die derzeit mit irgend einem Toyota fahren, eine Giulietta in der Serie einsetzen. Dank des hohen Standardisierungsgrades sollte das wohl machbar sein; das Team will dabei zumindest vorerst den Standardmotor verwenden anstatt den Motor der Giulietta zu überarbeiten. Es gibt auch schon ein Demo-Auto, wobei es sich aber nur um eine normale Seriengiulietta mit Aufklebern handelt.

Für britische Fans die Vorankündigungen mögen könnte auch die neue TCR UK interessant sein, eine Serie nach TCR-Spezifikationen die sich mehr als Einsteigerveranstaltung und Nachwuchsförderung positioniert. Zumindest hat schon ein britischer Fahrer die Giulietta TCR probegefahren.

Targa West

Noch eine Sache die auf Google auftauchte: Anscheinend ist die Giulietta in einer australischen Rally gefahren, und dabei in ihrer Klasse (Verkaufsraum-Standard, zwei angetriebene Vorderräder) ziemlich gut abgeschnitten, was endlich die Frage beantwortet: „Gibt es Alfas in Australien?“ Die einzige Quelle, die ich dafür nach ziemlich exakt keiner Suche gefunden habe, ist ein Forenpost in dem der Rennfahrer damit angibt, daher betrachte ich es vielleicht nicht als das wichtigste Ereignis in diesem Zusammenhang. Aber für die Liste zählt es auf jeden Fall.

Die Ostdeutschlanderklärer

Es gibt eine neue Art von Lieblingsartikel in der deutschen Zeitungslandschaft: Wessis machen eine Rundreise durch die neuen Bundesländer und berichten dann den anderen Wessis, wie „die da drüben“ so ticken und wieso „der Osten“ immer noch nicht im vereinten Deutschland angekommen ist. Es gibt viele dieser Artikel, und der Fokus variiert - mal sind drei Statistiken dabei, mal dürfen ein paar „echte Ossis“ ihre Meinung kundtun, aber das Grundprinzip ist immer gleich. (Der, der mich gerade aufgeregt hat ist hier zu finden - hinter einer Paywall, aber letztlich nicht wirklich Geld wert). Man schreibt über gute Straßen auf denen schlecht gelaunte Leute laufen, über sozialistische Sozialstrukturen die jetzt fehlen, und natürlich immer über die AfD, ohne die man sich ja die ganze Mühe, mal „rüber“ zu fahren, nie machen würde. Nur für eine Erkenntnis ist nie genug Platz: Das solche Artikel ein massives Teil des Problems sind.

Eines der grundlegenden Probleme des vereinten Deutschlands ist, dass die Einheit nie in den Köpfen der Westdeutschen angekommen ist, und dass man auch nie den Versuch unternommen hat. Diese Artikel sind dafür ein wunderbarer Beleg. Bis heute gilt in den deutschen Medien die Westdeutschlandsvermutung: Die Geschichte und Erfahrung der BRD ist der Standard; die ehemalige DDR ist eine Anomalie die man extra erklären muss. Wenn man zum Beispiel auf der „einstiges“-Seite von Spiegel Online die wichtigsten oder interessantesten Punkte der deutsche Nachkriegsgeschichte ansieht, dann sieht man Bundesliga, RAF, Privatfernsehen, derzeit sehr viel über Seenotretter, und natürlich den ersten Supermarkt Deutschlands in Köln. Immerhin wird da kurz erwähnt dass es so was auch in der DDR gab.

Wenn die DDR vorkommt, dann als die Ausnahmeerscheinung. Beispielsweise gibt es in der Serie über Seenotrettung genau einen Artikel der sich damit beschäftigt und klar macht dass es heldenhafte Rettungen nur im Westen gab, im Osten war natürliches alles Stasi. Denn wenn die DDR erwähnt wird, dann kann das nur im Kontext der Stasi passieren.

Bundesdeutsche Kultur ist und bleibt westdeutsche Kultur, egal woher die Kanzlerin kommt und wie viel in den Filmstudios Babelsberg produziert wird. Geschichten wie die DEFA-Winnetou-Filme oder Urlaub am Plattensee sind es nicht wert erzählt zu werden, so lange man noch nicht den ersten Versprecher im ZDF erwähnt hat. Das westdeutsche Wirtschaftswunder wird gefeiert; die ostdeutsche Wirtschaft ist stets ein großer Haufen von Ineffizienz in denen allen Arbeitern alles egal ist. Dass die DDR in vielen Bereichen im Ostblock technologisch führend war, die zweitgrößte Wirtschaftsmacht und den höchsten Lebensstandard pro Kopf hatte, wird ignoriert. Dass die meisten Leute dort hart gearbeitet hatten und Stolz auf das Erreichte waren passt nichts ins Bild oder ist vielleicht auch nicht bekannt. Und das ganze Themengebiet Treuhand sieht man anscheinend nicht als relevant, obwohl man doch angeblich verstehen will, wie es den neuen Bundesländern heute geht.

Hier wäre mal eine These: Könnte es sein, dass die Menschen in den neuen Bundesländern, die sich so abgehängt fühlen, vielleicht auch in mancher Hinsicht abgehängt sind? Dass die Ostalgie lebt und blüht, weil es immer noch keine gesamtdeutsche Geschichtsschreibung und damit kein gesamtdeutsches Identitätsgefühl gibt? Und könnte es vielleicht sein, dass man über solche Themen reden muss, nicht nur wenn die AfD in den Nachrichten ist oder am dritten Oktober? Ich persönlich denke, dass so was sinnvoller sein könnte, als der nächste Artikel mit dem Grundauftrag: „Echte deutsche (Wessis) erklären dem echten Deutschland (Westdeutschland) wie die Ossis so ticken“.

Eclipse E4: A Critique

At work, I’m developing on a large internal application based on the Eclipse Rich Client Platform, which is basically the foundations of the Eclipse IDE made available for everyone else, too. As platforms go, it’s alright, I guess, but it does have its share of weirdness. For example, why do I have to dispose colors once I’m done with them!?[^1](#) But with a healthy amount of helper functions, it’s all manageable.

[^1](#): For compatibility with 8-bit indexed displays. Since this is nowhere near a target for our app, I generally don’t dispose colors.

We’ve recently finished porting the application from Eclipse 3.7 to the 4.x line (specifically 4.5, planning to upgrade to 4.6 once it’s out). This may seem a bit late, considering that the first official release of that line, Eclipse 4.2, came out four years ago. After working with the new code, though, I’m starting to think that maybe we’re still too early. Eclipse 4, or e4 for friends, features a massive rewrite of some of the core parts of the platform. And I think that it’s unfinished and in parts rather misguided.

Unfinished Business

Editors are gone, as are views, replaced with generic parts. I could get behind that, but gone as well are editor inputs objects. So telling an editor what file to open and making that decision persistent requires custom logic - and possibly a lot of that if you relied on the flexibility editor inputs gave you. You might see the MInputPart in the documentation, but apparently that was never implemented and is now deprecated. I think the only reason it’s still in the documentation is to taunt people. Of course, even if it did work, an URI based scheme only brings you so far if you have an editor that is supposed to receive objects from many different sources.

Many classic services have no e3 equivalent. For example, the IFocusService lingers around, but it’s very unclear whether I can rely on it once we’re e4 only.

No documentation

The documentation for new e4 specific stuff is largely missing or automatically generated and not helpful at all. I dare you to find any information in the documentation of MToolItem that isn’t obvious from the method names. What’s particularly missing is overview information: What do the different parts in the application model actually mean? What’s the difference between a MPart and a MPartDescriptor, and which one do I need? What’s the lifecycle of a MPart exactly? What is the point of context activation?

The best source of information are the rather terse Vogella tutorials, but these are task-oriented, not concept-oriented. If you want to do something that no Vogella employee wanted to do yet, you’re largely on your own.

Loose coupling. Like Spaghetti

I like the idea of dependency injection in theory, but I’m not sure about the practice. And I have no idea whether that is an Eclipse thing or not, but it still irks me.

The basic idea suffers from two problems: You want all dependencies passed in externally instead of getting them from some global nebulous set of singletons and what not. That’s valid. But you also don’t want gigantic constructors with 200+ arguments for complex classes. Not that you should have classes like that anyway, but a complex editor implementation can reasonably require access to most services Eclipse provides, even if it is just passes them on to helper objects.

The solution is more or less to put all that global state in a map, then pass that map as the argument to every constructor, and allow it to create new versions of the same map internally. Only they chose a more complex version that also has a lot of syntactic sugar, to make sure it runs really slowly. Eclipse has a reputation to maintain, after all.

As a result, you still have no clear idea what part of the application needs access to what unless you search for type names, and now you also have no idea where it’s coming from. It’s not so much that it’s bad per se, but it definitely does not realize the advantages that dependency injection was meant to provide.

And while we’re here already: The way event handling is done via dependency injection is just insane.

Horribly bad ideas

I honestly don’t get the application model, and not just because there is no real documentation on it. I have no idea why it’s here at all, what problems it’s meant to solve, and how it thinks it has solved them. And most of all, I don’t get why so many Eclipse developers are so damn happy about it. “Look at this”, they go, “I change the window’s title in the application model, and the window’s title actually changes! And I can even do that… at runtime!” And then they’re surprised when I don’t applaud.

But hey, whatever, I’ve been able to write helper methods and helper classes to get around any problem in e4 yet. The real problem of the application model is that it seamlessly merges user state and declarative application code into one giant ball of mud. And then it makes that mud persistent, which is just as unpleasant as it sounds.

Because suddenly, changes in user state get the opportunity to conflict with changes to declarative application code. Will my new context menu show up if the user has moved any editors around? For that matter, will my old context menu continue to show up? Surprisingly often, the answer is no, and never for any good reason I could discern. By merging what absolutely had to stay separate, they built a giant bug-producing machine.

And they know it. The closest thing to an official recommendation is to simply disable persistent user state. Only during development, in theory, but they sure don’t provide a better way to deal with the problem once I release an update of my app. In my opinion, this wins the very highly contested price for least user-friendly thing ever done in Eclipse.

Oh, there’s a workaround, but it’s one that nobody will tell you about, and it’s the most WTFy thing I ever implemented, to the point that I still can’t quite believe that this is what it takes. But I’m doing it anyway: I wrote my own code for serializing the application model to an XML file and back, making 100% sure that I only touch the parts that the user can change (i.e. what editor is where), but not the parts that are declarative program code. It’s been a few months since I implemented this thing, and I still sometimes wake up in the night and shout “There must be something better! Some simple flag I missed somewhere!” Do drop me a line if you found it.

Handlers

Finally, command handlers. The new way of writing them is good. Having the validation logic in the handler itself as opposed to an XML file somewhere is better. Good choices all around.

Less good: Why can I have only one handler per command per part? I kind of need several different “delete” handlers for different parts of some more complex editors, thank you very much, and I have only limited interest in creating one giant monster handler that contains the delete logic for absolutely everything. Of course it’s possible to work around that; I’ve managed to work around every little thing in e4 except the application model weirdness so far. In this case, write one handler that creates an internal list of other handlers, then asks each whether it can execute and the first one to shout yes gets to do the job. But I don’t get the logic that says I have to write stuff like that.

I also don’t quite get why some handlers exist and others don’t, but that’s less of an issue.

No tool support

Why is it that so many new things are released without good tool support? Do people somehow think that’s optional? I don’t see it. For example, to port from e3 to e4, there is an awful lot of getting information out of one XML file, translating it, and putting it into a different XML file. It’s boring, tedious and straightforward. And the one and only tool I found for that is one I wrote myself (No; you can’t have it. Nothing personal, but I have no idea what hoops I’d have to jump through to get something developed internally released as Open Source here).

The tools that do exist regularly stop accepting copy and paste and have no useful search. Most of them aren’t part of the platform proper, but require a separate download. It all feels very experimental. I went back to editing the XML files by hand.

Overall

Overall, e4 is still very far from done, and that’s frustrating. But in a few places, even the core is wrong or at least questionable. And while it looks like Eclipse 4.6 will solve a few issues I’ve been having (Generics for Databindings! Hooray!), they don’t seem even interested in solving the big ones.

Agents of SHIELD retrospective

So I wrote this a while back, posted it elsewhere, then forgot about it, until I was reminded the day before yesterday that this wouldn’t be all out of place here, either. So let’s talk about a TV show that I found really disappointing once more: Agents of SHIELD.

At the start, I was really excited about it. Then I was disappointed. Then I got angry. Then it got better again, so by now my feeling is mostly “meh”. And what a big “meh” it is; I’ve been putting this off for more than a week after the final episode of season 1 aired and I still barely have the energy to get through this post.

The show certainly means well, although it really tries more to be a Joss Whedon show than a Marvel property. I guess the writers had prepared a checklist pretty much like the one I posted above and were trying their best to fast-track through it. This became very apparent later on when the characters basically outright stated “That bonding over a common enemy thing? Might as well do that now, nothing else interesting going on this episode”. And never forget that “the Bus”, their plane, is for all points and purposes the Serenity from Firefly. Similar looks, capabilities, identical internal layout including which character owns what space.

What it lacks is the depth and complexity that real Whedon shows have. For all of the characters, their motivations, strengths and flaws can be described in two sentences at most. Instead the show tries to keep our interest with layers of mystery and question after question. Lost has been getting a lot of shit for this, but there can be no doubt that Lost did it way better. The story of Coulson’s resurrection, for example, is in the end neither particularly complicated, nor does it mean much for his character both in how it happened or in how he reacts to it. It’s also kind of stupid. But in Agents of SHIELD, kind of stupid is probably the biggest compliment you can make, considering that the show is so very frequently extremely stupid.

For example, take the episode 0-8-4. How many trained Agents of SHIELD and peruvian military police does it take to stop one Land Rover filled with I guess about three or four insurgents? I don’t know, but it’s gotta be more than 6 and about 15, respectively, because they try and fail. Then there are things like where the “adorable quirky” (annoying) scientist guy gets to go out in the field with the actually competent person. Yeah, Fitz isn’t field-rated, I get it. But are you seriously telling me he’s never even seen a spy movie before?

It all works out for the heroes because the villains are just as stupid. Take the excavator thing: The bad guys didn’t need an excavator to open the secret SHIELD truck; it had normal doors (with some boxes stashed behind to throw anyone who opened the doors of track, so clearly they weren’t welded shut). They don’t use the excavator to open the secret compartment within the truck either; that job goes to a blowtorch. And they paid for the excavator in gold bars, which seems hardly reasonable. Of course the gold bars can be traced back to the main villain’s gold mine, something that a gold mine owner probably should have known. Oh, and the entire plot hinges on Malta not being a member of the UN or EU (it is, of course, a member of both organizations). This is some serious multi-level idiocy going on here.

Later episodes pick up the slack quite a lot, and at turns even make fun of themselves, for example when Skye reveals that her name (given to her at the orphanage) was Mary Sue, or my personal favorite: When Agent Hand sees all of Team Coulson’s incompetence and deduces they must have been Hydra all along.

But at that point the show was doing exactly the same thing as „Captain America: The Winter Soldier“, and boy does it not hold up. I get that a TV show with a limited budget can’t look as good as the Hollywood blockbuster, but the longer running time should allow it to have better human drama. It doesn’t. Captain America wins on all fronts here with Cap as an all-around good guy who never actually becomes boring, an interesting friendship with Black Widow, inspirational speeches that actually work on me (and I’m a long-standing cynic) and real pain over the thing with Bucky. Even Falcon with his amazing lack of screen time has more personality than most of the Agents of SHIELD group.

Also, somewhere before there, I think I’ve kind of stopped caring. I mean, the final resolution to “how and why did Coulson get resurrected?” was “Nick Fury did it because Coulson is a nice guy whom everyone likes”. Seriously. And my reaction to that was “eh, could have been worse”.

Finally, to wrap this up: The show doesn’t look that good. Don’t get me wrong, it looks perfectly okay in a late 1990s kind of way. But we live in an age where Heroes, Lost, Breaking Bad or further out of the field Gossip Girl have established strong visual identities on TV. Whether it is through the choice of color, editing, or other things, these shows have character. SHIELD is, visually, less exciting than Bones or Castle.

In total: Agents of SHIELD is really not worth the bother. The later episodes are at least not offensively stupid anymore, but there isn’t really anything else to get passionate about either. Season 2 has been announced, but I’ll probably skip it. Here’s hoping that these Netflix shows or Agent Carter do better.

DAG vs. Baum

Ich überlege, ob die Datenstruktur “Baum” nicht vielleicht einer der größeren Fehler der Informatik war. Fast alles reales, was man in einem Baum abspeichert, ist eigentlich ein DAG.

Zur Erläuterung: Ein Baum ist eine Datenstruktur bestehend aus Knoten, in denen jeder Knoten einen oder keinen Vorgänger hat (genauer ist dies ein Wald. Bei einem Baum hat genau ein Knoten keinen Vorgänger). Umgekehrt hat jeder Knoten keine bis beliebig viele Kinder, nämlich genau die, deren Vorgänger der Knoten selbst ist. Kreise sind explizit verboten.

Das bekannteste Beispiel ist das Dateisystem auf einem Computer: Jede Datei liegt in einem Ordner. Der liegt wieder in einem anderen und so weiter, bis hin zu einem der auf dem Laufwerk liegt, das wiederum den Anfang darstellt. Maillisten und einige Arten von Foren und Kommentarsystemen funktionieren ähnlich: Jeder Post ist eine Antwort auf exakt einen vorigen und wird eine Ebene tiefer angezeigt. Baumstrukturen gibt es aber schon länger als es Informatik überhaupt gibt: Das ganze Feld der Taxonomie oder auch die Sprachforschung, die alles in verschiedene Familien und Unterfamilien und so weiter unterteilt, sind genau das.

Bäume lassen sich durch Algorithmen schön und einfach behandeln, z.B. um alle Kinder zu finden. Über Pfadangaben kann ein einzelnes Element eindeutig identifiziert werden.

Es gibt nur ein Problem damit: So funktioniert die Realität nicht. Im Normalfall haben Sachen mehrere Vorgänger. Ein klassisches Beispiel: In welchen Ordner passt diese Datei? In Diskussionen möchte man manchmal auf mehrere Posts, die ähnliche Punkte machen, gleichzeitig antworten. Sprachen gehören nicht zu einer Familie, sondernd haben Einflüsse von vielen andere gleichzeitig.

Um darum herumzukommen, muss man sich für einen Vorgänger explizit entscheiden, oder das Objekt aufteilen (was bei Antworten in Online-Diskussionen gut geht, bei Dateien nur fallweise möglich ist, und zum Beispiel bei der Klassifizierung von Autotypen völlig versagt). In beiden Fällen gehen bestehende semantische Beziehungen verloren.

Die Antwort darauf heißt DAG für Directed Acyclic Graph. Die Regeln sind fast die gleichen wie für einen Baum, nur dass hier ein Knoten mehrere Vorgänger haben kann. Ein Beispiel: iTunes und ähnliche Programme erlauben es zum Beispiel, dass ein Lied in vielen Wiedergabelisten gleichzeitig ist.

DAGs repräsentieren all die Beispiele, die ich genannt habe, auf natürliche Art und Weise. Damit kann eine Datei auch in zwei Ordnern liegen. Da ein Baum ein Spezialfall eines DAGs ist, können bestehende Strukturen auch problemlos darin abgebildet werden.

In der Realität haben viele Systeme im Prinzip Hacks, um DAG-Strukturen zu erstellen. Dank Hardlinks sind Dateisysteme de-facto schon lange DAGs, es wird nur gut versteckt. Symlinks, Aliase und die Windows .LNK-Dateien stellen “Vorgänger zweiter Klasse” da, durch welche die Beziehungen expliziert neu erzeugt werden.

Heutzutage werden klassische hierarchische Strukturen massiv durch Tag-Systeme abgelöst, bei denen eine Datei, Blog-post oder so beliebig viele Tags haben kann. Diese Struktur ist einfach nur ein sehr kurzer DAG. Im Prinzip ist das auch schon ein Lösungsansatz, aber da ich keine Beziehungen zwischen Tags als solchen herstellen kann, und so ein System in manchen Fällen (z.B. Diskussionen) überhaupt nicht geht, würde ich das aber nicht als vollwertigen Ersatz betrachten.

Aus technischer Sicht ist ein DAG wesentlich schwieriger. Zum Beispiel ist ein Baum immer Planar, was heißt das man ihn ohne weiteres ohne sich kreuzende Linien darstellen kann, was bei einem DAG nicht zwingend gegeben ist. Eine Aufzählung aller Elemente ist schwieriger wenn nichts doppelt sein soll. Objekte lassen sich möglicherweise über mehrere völlig unterschiedliche Pfade finden. Das ist natürlich auch genau der Punkt, aber die Frage “bezeichnen die zwei Pfade das selbe Objekt” lässt sich nicht beantworten ohne in den DAG selbst hineinzuschauen (während sie für Bäume trivial ist).

Vor allem aber kenne ich noch keine wirklich gute UI um DAGs darzustellen und zu manipulieren. Beispielsweise ist die Alternative zur Baumstruktur in Online-Foren nicht etwa ein DAG, sondernd eine einfache Liste die nach der Zeit geordnet ist. Beziehungen müssen durch die Inhalte der Texte manuell angezeigt werden.

(All das betrifft natürlich nicht die Anwendung von Bäumen zur effizienteren Verwaltung wo der Nutzer sie nicht sieht, z.B. in Suchindizes, Heaps und anderen Fällen.)

Was meint ihr? Ich habe hier wegen zu viel Spam die Kommentare hier fürs erste abgeschaltet, aber ich bin bei Twitter unter @zcochrane erreichbar.

30 Jahre Mac

Als ich 2002 meinen ersten Mac kaufte (ein eMac mit 700 MHz G4), dachte ich, ich wäre ein absoluter Neuling in der uralten Mac-Szene. Nun bin ich in vielen Treffen von Mac-Nutzern einer der ältesten.

Im Gegensatz zu vielen Leuten, die gerade im Internet posten wie sie ihren ersten Mac sahen und sofort verliebt waren, bin ich mehr in das ganze reingeschlittert. Der erste Mac den ich bewusst sah war ein PowerMac G4 (mit Nadelstreifen) der meinem Vater gehörte. Darauf lief Mac OS 9, was zwar anders, aber in kleinster Weise interessant war. Das änderte sich mit dem zweiten Mac den meine Eltern kauften: Ein weißes iBook G3 mit Mac OS X 10.1. Zwar lief kaum Software drauf und es war nicht furchtbar schnell, aber ich fand es klasse. Ich würde gerne sagen, dass ich die Visionen und große Zukunft erkannte, aber ehrlich gesagt waren es doch vor allem die beeindruckenden Grafiken. Ein großer Teil der Entscheidung waren auch die kostenlosen Entwicklungstools, Project Builder und Interface Builder (heute alle als Xcode zusammengefasst). Zuletzt war ich angetan von iTunes und dem iPod. Beide waren wirklich sehr beeindruckend für jemanden, der sich vorher immer über Winamp und nerviges Brennen von CDs ärgerte.

Seitdem hat sich die Welt merkwürdig weiterentwickelt. Als ich anfing war die Umstellung von Mac OS 9 auf Mac OS X voll in Gang. Dann wechselte Apple zu Intel, dann wurde iOS plötzlich groß. Die ganze Gerüchteszene zu Apple verschwand mehr oder minder, wohl auch weil die meisten langlebigen Gerüchte (Apple wechselt zu Intel! Apple macht einen Nachfolger für den Newton! Apple macht ein Telefon! Apple macht eine Maus mit zweitem Button! Apple macht einen Tablet-PC!) sich letztlich erfüllten, wenn auch nicht immer auf die Art und Weise die erwartet wurde.

Für mich bedeutend: Ich habe praktisch alles, was ich über Programmieren und Softwareentwicklung weiß, auf und mit meinen verschiedenen Macs gelernt. Es ist immer noch mein größtes Hobby und nebenbei mein Job heutzutage. Ich weiß nicht ob ich ohne Macintosh wo anders gelandet wäre, aber ich weiß, dass es ohne Macs wesentlich weniger Spaß gemacht hätte.

Agents of Shield - Checklist filled

So let’s see how that checklist works out in practice then. Oh yeah, spoilers:

  • A group of people that don’t get along initially, but grow to become a family? - Yeah. Still working on that growing to be a family.
  • A scene where it looks like a tiny girl is in danger, but in reality she’s the one in control of the whole situation and the most dangerous thing all around? - Yeah. This time she’s evil. In a wider sense, the villain of the week is male but portrays that power reversal, too.
  • A “oner”, meaning a very long shot where the camera moves to a space without cutting? - Not yet.
  • An episode where information is conveyed through music? - Not yet.
  • Beloved minor characters who die? - Not yet.
  • Characters in so much pain and angst that they can barely walk? - Yeah. Charles Gunn.
  • Pop culture references? - Oh yeah. “With great power comes… a whole lot of shit that you’re not prepared to deal with.”
  • Actors from previous Joss Whedon works? - Charles Gunn, Shepherd Book, the Serenity. And a discount version of Eliza Dushku.
  • A great sense of humor? - Hell yeah. “Sorry, the corner was dark, I couldn’t resist”
  • Horrible things happening to people in love? - still too early for that