Seit vielen Monaten - recht genau seit Beginn von Umbauarbeiten zur Vorbereitung von Stuttgart 21 - klemmt und
hakt es im gesamten S-Bahn-Netz in Stuttgart. Waren früher Zugausfälle die extreme Ausnahme, vergeht derzeit keine
Woche, ohne daß Pendler stundenlang unterwegs sind, bis sie an ihrer Arbeitsstelle oder wieder zuhause angekommen
sind. Die Website S-Bahn-Chaos in Stuttgart dokumentiert diese Fälle und
und erklärt Hintergründe.
Morgen, am 21. September, tut der Verkehrs- und Tarifverbund Stuttgart (VVS), Träger des S-Bahnverkehrs in der Region, nun endlich etwas dagegen.
Wie? Na, das liegt doch auf der Hand: Indem er Werbung für die BILD und damit indirekt für die schwarz-gelbe Regierung macht.
Ausgerechnet am Samstag vor der Wahl gilt nämlich die aktuelle Ausgabe der
BILD Stuttgart
als VVS-Ticket.
Nun ist es eine Sache, sich mit der BILD für PR-Zwecke gemein zu machen. Wenn man wie der VVS erst einmal seine Kundschaft durch miserabelsten Service so richtig vergrätzt hat, kommt man offenbar auf verzweifelte Ideen.
Das aber auch noch am Wahlwochenende zu tun, das hat mehr als nur ein Geschmäckle. Die BILD wird
am Samstag vor der Wahl alles daran setzen, Leser im Sinne der Blattdoktrin zu
beeinflussen. Nicht von ungefähr sollen am gleichen Samstag auch noch 41 Millionen Exemplare
einer BILD-Sonderausgabe verteilt werden - die
Nachdenkseiten berichten.
Wer verfolgt hat, wie
intim der BILD-Chefredakteur insbesondere mit "Spitzenkräften" der FDP umgeht
und wie auch sonst die Berichterstattung dieses Blattes ausfällt, kann
sich die Richtung dieser Beeinflussung leicht ausrechnen.
Und ausgerechnet am Samstag vor der Wahl verhilft der VVS der BILD zu einer hohen Auflage und hilft
ihr damit, die politische Agenda des Springer-Konzerns zu befördern.
Als VVS-Kunde, der für seine Jahreskarte gutes Geld hingelegt hat, bleibt mir da die Spucke weg.
Ich erwarte vom VVS, daß er alle seine Kräfte bündelt und dafür sorgt, daß die S-Bahnen endlich wieder
pünktlich fahren. Darin möchte ich das Geld für meine Jahreskarte investiert sehen - und auf gar
keinen Fall in BILD-Auflage und Wahlmanipulation.
Seit einigen Jahren schon nennen sie mich einen Softwarearchitekten. Kaum stand
die Bezeichnung auf der Visitenkarte, ging das los mit dem schlechten Gewissen.
So ein Architekt sollte doch den ganzen Tag blitzgescheite Architekturdokumente
schreiben, denkt man. Er sollte mit Mustern nur so um sich werfen, bis die
Codegeneratoren zu glühen beginnen und den Kollegen der Kopf kreiselt. Und
er sollte alle Bürowände und alle U-Bahn-Unterführungen auf dem Weg zur Arbeit mit
UML-Diagrammen zukleistern, bis Greenpeace Kästchen und Pfeile zu bedrohten Arten
erklärt.
Nichts davon habe ich getan - und habe mich manches Mal im Stillen deswegen einen
Hochstapler geziehen.
Nun stosse ich
gestern, bei der Recherche
in Sachen "Agilität versus Architekt", auf einige Stimmen, die finden, daß Architekten
klassischer Art in Scrum-Teams ohnehin kaum noch gebraucht werden.
Und heute folgt auf dem Fuß eine Studie ("UML in Practice"), die
nahelegt, daß
UML in der Praxis doch eher spärlich angewendet wird - und wenn, dann fast nur für
Klassen-,
Sequenz-
und
Aktivitätsdiagramme.
Nun, ich nehme mir dennoch vor, zumindest diese Diagrammtypen immer einmal wieder zur
Illustration zu verwenden. Denn mindestens ab und an finde ich UML natürlich überaus
nützlich - für die interne Kommunikation, oder auch um Chefetage und Kundschaft zu beeindrucken.
Bei dieser Gelegenheit entdeckt:
PlantUML. Das könnte helfen,
UML-Diagramme ordentlich zu versionieren, also gemeinsam mit dem Quellcode zu pflegen.
Gerade komme ich von einem Vortrag zurück, den JUGS
und andrena
gemeinsam organisiert haben: "Agilität und Softwarearchitektur - Freunde oder Feinde".
Im allgemeinen meide ich Diskussionen über agile Softwareentwicklung - zu oft
verliert man sich dabei in Allgemeinplätzen oder tauscht
längst bekannte Standpunkte zum zweiundvierzigsten Male aus. Bei diesem Vortrag habe
ich eine Ausnahme gemacht, weil ich mir Hilfe erhoffte, um meine Position als Softwarearchitekt
in einem neuen Scrum-Team zu bestimmen.
Braucht ein Scrum-Team überhaupt einen ausgewiesenen Architekten? Wenn ja, von welchen
schlechten Angewohnheiten sollte er ablassen? Welche Aufgaben sollte der Architekt im Team übernehmen?
Und wie entsteht dieses wolkige Etwas namens
Architektur, wenn man immer nur die nächsten ein oder zwei Monate detailliert plant?
Der Vortrag von Johannes Stammel lieferte dazu Hinweise. Leider driftete die folgende
Diskussion wie befürchtet ab - zum Beispiel ging es um die Frage, wie man einem Kunden ein agiles
Projekt "verkauft". Das ist in der Tat ein veritables Problem, hat aber mit der Architektenrolle
eher wenig zu tun.
Aber der Vortrag inspirierte mich auch, weitere Quellen zu bemühen:
Erst jüngst hatte ich außerdem den Artikel
Der agile Architekt
von
Nils Arndt gelesen, dessen Schlussfolgerungen für die Architektenrolle
mir durchaus sympathisch waren:
- So wie es in einem Scrum-Team einen Spezialisten fürs UI geben kann, so
darf es auch jemanden geben, der sich mit Vorliebe oder besonderer Begabung
mit Architekturthemen beschäftigt.
- Der Architekt trägt durch Schulungen, Entwurfsbesprechungen, aktive Mitarbeit und Dokumentation
Architekturwissen ins Team.
Denn: "Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams."
(Womit dann auch das Team für die Architektur verantwortlich ist und nicht nur der
Architekt.)
- Die Architektur wird von Sprint zu Sprint gemeinsam weiterentwickelt.
Entscheidungen werden im "letzten Moment" gefällt - also dann, wenn man die Anforderungen
gut kennt und man sich etwas vergeben würde, wenn man keine Entscheidung fällt.
- Abstraktionswut hat in agilen Projekten keinen Platz.
- Der Architekt faßt selbst in der Entwicklung mit an.
- Architekturdokumentation gibt es weiterhin, fällt aber schmaler aus als bei anderen Ansätzen.
(Nils Arndt schlägt arc42 als Schablone
für die Architekturdokumentation vor, was ich aber noch mit Skepsis sehe.)
- Der Architekt ist Kommunikator - er vermittelt zwischen Entwicklern, product owner, Management.
- Bei divergierenden Auffassungen im Team ist es Aufgabe des Architekten, eine
Entscheidung herbeizuführen.
Mal sehen, was mein Team dazu sagen wird...
PS: Ein Kollege verwies mich als Kommentar gleich auf Martin Fowlers
Who Needs An Architect?.
Irgendwann wurde das Tethering über mein altes Telefon nervig, und so legte ich mir endlich
einen UMTS-Stick zu, damit mein Macbook Pro auch unterwegs mit dieser Modeerscheinung namens "Internet"
Kontakt aufnehmen kann. Dummerweise macht der Stick Zicken.
Erworben habe ich den UMTS-Stick via
Pro7 (jaja, ich weiß...),
technisch handelt es sich dabei um ein
Huawei E173s-1,
der sich seine Daten aus dem Vodafone-Netz holt.
Witzigerweise tat der Stick am Macbook beim ersten Test ganz wie gewünscht: Einstecken, mitgelieferte
Software starten, PIN eingeben, mit Netz verbinden. Ein paar Tage später aber war Schicht im USB-Schacht:
Offenbar wird der Stick am USB-Port nicht mehr erkannt. Erkennbar ist das daran, daß die zugehörige Software ihre Hardware nicht findet:
Ach ja, auf dem Macbook Pro läuft OS X 10.8 (Mountain Lion).
Diskussionen zufolge, die ich an diversen Stellen gefunden habe, scheine ich mit dem Symptom nicht
alleine zu sein, aber eine befriedigende Erklärung oder Lösung habe ich bisher nicht finden
können - aber immerhin einen (recht ungelenken) Notbehelf.
Was ich bisher versucht habe:
- Alle verfügbaren USB-Ports am Macbook ausprobiert (kein Erfolg)
- UMTS-Stick an einem Netbook ausprobiert (dort tut alles wie gewünscht)
- Treiber/Gerätesoftware aktualisiert (kein Erfolg)
Auf dem Netbook liefert
sudo lsusb -v übrigens die folgenden Angaben zur Hardware:
Bus 001 Device 008: ID 12d1:14c9 Huawei Technologies Co., Ltd. K3770 3G Modem
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x12d1 Huawei Technologies Co., Ltd.
idProduct 0x14c9 K3770 3G Modem
bcdDevice 1.02
iManufacturer 3 HUAWEI
iProduct 2 Vodafone Mobile Broadband (Huawei)
Was schließlich weitergeholfen hat: Über einen USB2-Hub angeschlossen, funktioniert der UMTS-Stick
auch am Macbook wieder! Diesen Rat findet man auch an diversen Stellen im Netz, wo aber auch andere
Lösungsansätze verhandelt werden, die ich noch nicht alle durchprobiert habe. Eine Auswahl von Fundstellen:
Nach wie vor verstehe ich überhaupt nicht, warum der Stick anfangs gut funktionierte und erst nach
ein paar Tagen die Probleme auftraten, die ja offenbar mit dem Betrieb an einem USB3-Port zusammenhängen.
Übrigens,
diese Diskussion läßt vermuten, daß das
Problem nicht nur unter OS X auftritt, sondern auch unter Ubuntu auf einem Rechner
mit USB3-Ports.
PS: Ein Teil des Durcheinanders stammt vielleicht auch daher, daß auf meinem Rechner inzwischen
zwei Softwarepakete installiert sind, die zumindest theoretisch beide den UMTS-Stick betreiben
können -
"Mobile Partner" (mit dem UMTS-Stick ausgeliefert) und
Vodafone Mobile Broadband.
x86 oddities is
quite an amusing collection of x86 opcodes and behaviors which aren't commonly known.
The same site also has video tutorials on the portable executable (PE) format, and neat opcode
tables for x86, Java bytecode and .NET IL. Very useful!
And while we're discussing Java bytecode and .NET IL: I have always found
IKVM most fascinating - this lets you run your Java
code in a .NET CLR. Roughly, it works by loading Java class files and translating them on the fly
to .NET IL code. (I think there is also a "static" translation mode, though.)
Using IKVM, people succeeded in running fairly involved stuff like Eclipse and
Groovy
in the CLR...
In a similar vein,
jni4net tries to create a bridge between
.NET and Java. Fascinating stuff as well.
Previous month: Click
here.
to top
Blog