...someplace, where there isn't any trouble? Do you suppose there is such a place, Toto?

In eigener Sache: "We had to let them go..."

Die letzten Wochen waren weder Fisch noch Fleisch. Zwischen Baum und Borke. Nicht hüh und nicht hott. Between the devil and the deep blue sea. Neither fish, nor flesh, nor good red herring. Neither here nor there. Zwischen Triebwerk und Toilettentür. Oder was es sonst noch so an mehr oder weniger brauchbaren Metaphern gibt.

Der Grund ist der, dass ich - sagen wir es mal so - in der zweiten Maiwoche ganz bewusst etwas an meiner Erwerbsbiographie geändert habe. Ich habe bei meinem soon-to-be-ex-Arbeitgeber gekündigt und werde ab 1.7.2012 unter neuer Flagge segeln, und zwar bei einer Firma in Leinfelden (gerne gebe ich genauere Informationen über meinen neuen Arbeitgeber nach einer persönlichen Mail). Und zum Zeitpunkt meiner Kündigung war eine grössere Menge Resturlaub aufgelaufen, so dass ich seither viele Wochen Zeit zum Nachdenken, fürs Freibad und sonst alles mögliche hatte und mich auch auf meine neue Stelle fachlich ein wenig vorbereiten konnte. Also sowas wie grosse Ferien und sowas wie nicht mehr so richtig für den alten Arbeitgeber und noch nicht so richtig für den neuen Arbeitgeber. Daher das Füllhorn an passenden und unpassenden Metaphern am Anfang.

Damit wären dann gut 10 Jahre bei demselben Arbeitgeber, zuerst als NetSupport GmbH, dann umbenannt in enteo GmbH und schliesslich nach der Akquisition durch gleichnamige Firma als FrontRange Solutions Deutschland GmbH, für mich Geschichte. Zeit also für eine kleine Abrechnung :-) ...

Keine Angst, so unprofessionell bin ich dann doch nicht. Denn was in der Erinnerung bleibt, sind sowieso immer nur die positiven Dinge, und selbst mir als ausgemachtem Zyniker wird's jetzt, vor meiner letzten Arbeitswoche mit zwei letzten harten Arbeitstagen, schon beinah a bissal schwer um's Herz, wenn ich an die letzten 10 Jahre zurückdenke. Und schliesslich hat ja auch schon Oscar Wilde (jedenfalls schreibt man ihm diesen Spruch zu) gesagt:

"Scratch a cynic?s surface and you'll find a disappointed romantic."

 

Vieles wird mir fehlen. Nicht das heimelige Surren der zuletzt 8 Maschinen an meinem Arbeitsplatz. Nicht das Privileg, direkt neben der Firma zu wohnen und an heissen Sommertagen zwischendurch schnell mal eine eiskalte Dusche daheim nehmen zu können. Nicht der beispiellos lässige und meiner Meinung nach vorbildliche Umgang mit Home Office und Vertrauensarbeitszeit. Nicht der wöchentliche Massageservice und auch nicht die früher kostenlosen "Süssies", das kostenlose Obst und die kostenlosen Getränke.

Was ich vermissen werde, sind die Menschen. "Uhhh, Stefan spricht über "Menschen", das menschelt ja schon richtig, das ist gar nicht seine Art", höre ich da den Kai jetzt sagen. Aber es ist wirklich so: Das grossartige Team, das wir einmal waren und zu dem wir uns über Jahre entwickelt haben, war beileibe nichts Alltägliches, darüber sollte sich jeder, vor allem aber die Jüngeren im Team, im Klaren sein. 10 Jahre in derselben Firma und man kann niemanden während dieser Zeit und auch im Nachhinein als ausgemachtes Arschloch identifizieren, das spricht nicht nur für eine kluge Einstellungspolitik sondern ganz besonders für die beteiligten Individuen ("Individuen" ... ist das jetzt besser, Kai?).

Was ich sicher auch vermissen werde:

  • Die (Sub-)Kultur der durchgängig persönlichen Anrede mit dem Kürzel ("Hey SKU!", "Hi, AFU, schon gelesen...", "Mahlzeit FZO, Du alte Schabracke..."). Wobei eindeutig diejenigen im Nachteil waren, deren Kürzel  - ganz sperrig - nur dreisilbig auszusprechen war, wie etwa bei Kai (KIH - also "Kah - Ih - Ha"). Dagegen ich mit meinem geschmeidigen Einsilber ("SKU") war da natürlich an der Spitze der Nahrungskette. Ein Sonderfall war da zweifellos der SGL, zwar Dreisilber ("Es - Geh - Ell"), aber eben auch Geschäftsführer. Aber zur Not konnte man sein Kürzel ja auch ganz elegant schwäbifiziert und mit gewollt abfälliger Konnotation zweisilbig aussprechen ("Seg-gel").
  • Die grossartigen Releaseparties. Can you say "Long Island Ice Tea", FZO?
  • Mein Büro, Mission Control, Namensgeber dieses Blogs. Und alle seine Bewohner, besonders die Säugetiere darunter, namentlich Kai. Wir beide waren die einzigen in der Firma, die niemals in andere Räumlichkeiten reloziert oder sonstwie auseinanderdividiert wurden.
  • Das Suppenschlürfen mit MLO und das gelegentliche Kakaoschlürfen mit MNE
  • Jeder fachliche Diskurs mit OTE. Ein besserer Teamlead als Oliver Tengler ist für mich nur schwer vorstellbar.
  • Die Zusammenarbeit mit dem grossartigen Testteam, das wir einmal hatten. Etwas besseres kann einem Entwickler nicht passieren, als mit so kompetenten und motivierten Leuten zu arbeiten.
  • Die perfekte Organisation des Teams durch AFU. Es gibt keinen besseren Projektleiter und Program Manager auf diesem Planeten als Andreas Fuchs.

Ich bin dankbar dafür, dass ich viel lernen durfte in diesen 10 Jahren und natürlich dafür, dass ich vielleicht dem einen oder anderen auch so einiges beibringen durfte während dieser Zeit. Aber bevor dieses Narrativ nun vollends zum sentimentalen Rührstück verkommt, lohnt sich vielleicht ein Blick nach vorne.

Moving on to greener pastures

 

Der erste, der während meiner Anstellungszeit die Firma verlassen hatte, und das schon 2003, war IBI, dem ich seither in einer Art Hassliebe zugetan bin. Er kommentierte seinen Abgang damals mit den Worten:

"Etwas Besseres als den Tod findest Du überall".

 

Das haben die drei Bremer Stadtmusikanten ihrem vierten Mitstreiter, dem Hahn gesagt, der im Kochtopf landen sollte. Dieses Motto will ich mir aber keinesfalls zueigen machen, und es gibt auch keinen Grund dazu. Denn bei meinem neuen Arbeitgeber hat man mich eingestellt, obwohl ich erst mal in einem Team landen soll, das sich mit managed code und dem IIS und Datenbanken beschäftigt, also mit Themen, die bisher von mir grosszügig gemieden wurden. Das ist ein Vertrauensvorschuss, den ich erst einmal zurückzahlen muss, denn die Lernkurve für mich wird nicht nur vorhanden, sondern vor allem erst mal steil sein. Und man hat mich wegen meines Faibles für Security-Themen eingestellt, womit ich in meinem bisherigen Berufsleben eigentlich immer eher als lästiger Fragesteller und Nestbeschmutzer, und bestenfalls - unter Absingen schmutziger Lieder - als willfähriger Erfüllungsgehilfe für die dirty little secrets aufgefallen bin. In dem Team, in dem ich arbeiten werde, geht es um Lösungen für die unzweifelhaft wichtigste Herausforderung, die unsere Gesellschaft hat, und das ist die Energiewende. Also ein Thema, das für mich als Bürger von höchster Wichtigkeit ist, für mich als Ingenieur aber die Chance bietet, an Dingen mitzuarbeiten, die dieser Gesellschaft unmittelbar nützen. Gibt es was schöneres? Wünscht mir Glück und drückt mir bitte die Daumen, dass das auch klappt.

Quote of the day

"Stefan, Du bist mir heute viel zu entspannt und braungebrannt!"

Oliver Tengler, heute, an meinem drittletzten Arbeitstag bei FRS, zu mir.

Ain't that cute!?!

Wenn es überhaupt eine Bigband-Nummer gibt, die mit einem Schlagzeugsolo mit Besen assoziiert ist, dann ist das "Cute" vom Count Basie Orchestra. Ebenso, wenn es überhaupt eine Bigband-Nummer gibt, die mit einem Flötensolo assoziiert ist, dann ist das wieder "Cute" von der Basie Band. Und weil ich grade Flöte übe wie ein Bekloppter, denn irgendwie muss sich ja mein Unterricht bei der grossartigen Els Jordaens lohnen, habe ich jetzt mal das Flötensolo von Frank Wess rausgeschrieben. Ausserdem ist die Nummer wirklich so schön, dass mir mal so richtig das Herz aufgeht, wann immer ich das höre, denn wer "Cute" nicht mag, frisst auch kleine Kinder.

Wenn man der Wikipedia Glauben schenken mag, dann ist Frank Wess als hochbetagter Mensch mit über Neunzig heute noch unter den Lebenden. Wahrscheinlich ist er einer der letzten in dieser grossartigen Basie-Band der ausgehenden Fünfziger, in der Fixsterne spielten wie Joe Newman, Thad Jones, Snooky Young, Marshall Royal, Billy Mitchell, Eddie "Lockjaw" Davis und Sonny Payne. Es gab nie wieder eine bessere Bigband als diese.

Leider konnte ich nirgendwo auf YouTube diese Aufnahme finden, drum bleibt hier mal ein Link auf YouTube aus. Without any further ado, here is "Cute" (ein Klick auf das Thumbnail öffnet die Transkription als pdf-Datei):

Cute Solo Transcription

Happy transcribing, you know, I am!

Symbole im Debugger gezielt nicht laden

In diesem Blogpost beschreibe ich jetzt mal, wie man für den Debugger von Visual Studio verhindern kann, dass bestimmte Symbole geladen werden. Mein Problem ist, dass ich immer wieder vergesse, wie der Registry Key heisst, den man da anlegen/bearbeiten muss, und welche DLLs ich da am Besten eintrage, und dieses Problem wiederholt sich bei mir bei jeder Entwicklungsbox, die ich aufsetze, insofern bin ich mit diesem Blogpost mein eigenes und bestes Zielpublikum.

Das Problem

Wenn man einen Pfad zum Laden von Symbolen gesetzt hat, dann ist das normalerweise eine schöne Sache. Der Debugger versucht, von jeder DLL im Prozessraum des Debuggees die Symbole zu laden, und man erhält zumindest schöne Callstacks beim Debuggen. Bei einem Symbol Store für die eigenen Binaries sieht man auch lokale Variablen und ihre Werte sowie den dazugehörigen Code, notfalls automatisch ausgecheckt aus dem Versionskontrollsystem (wie man sich sowas aufbaut, habe ich vor langer Zeit hier beschrieben). Damit ist die Welt schön, denn beispielsweise von den DLLs des Betriebssystems bekommt man die Symbole automatisiert von Microsofts Symbol Server runtergeladen.

Blöd wird das Ganze aber, wenn im Prozessraum eine DLL auftaucht, für die man partout keine Symbole bekommt, denn der zum Scheitern verurteilte Versuch, für solche DLLs die Symbole zu finden und zu laden, braucht sehr viel Zeit, und das Leben ist bekanntlich ja schon kurz genug. Und beim Debuggen warten zu müssen ist eine PITA. Historisch zählten dazu schon ab und zu mal DLLs von Microsoft, aber notorisch bekannt dafür sind eigentlich die Hersteller von Grafikkarten, die es fertig bringen, in jeden Prozessraum ihre verschissenen DLLs zu injizieren, oder aber irgendwelche third-party Shell-Extensions. Da ich zuhause bekannterweise einen Subversion-Server einsetze und auf meinen Entwicklungsboxen daher das wunderbare Tortoise-SVN zum Einsatz kommt, ist Tortoise-SVN ein wunderbares Beispiel für dieses Problem. Am Besten manifestiert sich das Problem, wenn man beim Debuggen eine File-Open Box öffnet. Dann wird alles an Shell-Extensions geladen, was nicht bei drei auf den Bäumen ist, unter anderem auch Tortoise-SVN. Auf meiner guten alten SAAVIK, einer x64-Box von 2005, dauert das dann 22s im Debugger, bis die File-Open Box dargestellt und bedienbar ist. Der Debugger schaut für jede zu ladenden DLL in das Binary rein und versucht, das Symbol, also die pdb-Datei, zu ermitteln und dann zu laden. Wenn er sie nicht über einen absoluten Pfad findet, klappert er der Reihe nach die konfigurierten Symbol Stores ab und das dauert dann üblicherweise jedesmal ein paar Sekunden, bis er bei der Nachfrage beim Microsoft Symbol Store (oder dem eigenen Symbol Store) die Antwort bekommt: "Nein die Datei TortoiseSVN.pdb ist nicht von uns".

Die Lösung

Die Lösung besteht darin, diejenigen DLLs zu identifizieren, für die man ohnehin keine Symbole bekommt, und die dann von vornherein vom Laden auszuschliessen. Wenn Symbole lokal gefunden werden, dann sieht man sowas im Debugger-Output:

'abcd.exe': Loaded 'C:\foobar\bin\Debug\xyz.dll', Symbols loaded.

oder aber, wenn die Symbole  beispielsweise vom MS Symbol Store kommen (und daher die Debuginformationen 'stripped' sind, also nur Funktionsnamen beinhalten):

'abcd.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll', Symbols loaded (source information stripped).

Wenn aber die Symbole nicht gefunden werden, dann sieht das lediglich so aus (also ohne irgendwas mit "Symbols loaded"):

'abcd.exe': Loaded 'C:\Program Files (x86)\TortoiseSVN\bin\TortoiseSVN.dll'

Es gilt also, diese DLLs im Debugger-Output zu identifizieren und deren Symboldateien zu ermitteln. In der Regel heissen die Symboldateien so wie die DLLs, nur mit der Extension .pdb. Um aber auf Nummer Sicher zu gehen, schaut man sich jede DLL in einem Hexeditor an und sucht nach dem String ".pdb". Üblicherweise erhält man nur einen Treffer und das ist dann der Name der Symboldatei, nach der der Debugger sucht. Hat man den Namen der Datei, dann legt man den Key HKEY_CURRENT_USER\Software\Microsoft\Symbol Server\Exclusions an (sofern der noch nicht existiert) und ergänzt dort einen REG_SZ-Value mit dem Namen der Symboldatei. Bei mir schaut das dann beispielsweise so aus:

[HKEY_CURRENT_USER\Software\Microsoft\Symbol Server\Exclusions]
"TortoiseOverlays.pdb"=""
"TortoiseStub.pdb"=""
"TortoiseSVN.pdb"=""
"libapr_tsvn.pdb"=""
"libaprutil_tsvn.pdb"=""
"intl3_tsvn.pdb"=""
"slc.pdb"=""
"WMVCORE.pdb"=""
"SPYHK55.pdb"=""
"TortoiseShell.pdb"=""
"libsvn_tsvn32.pdb"=""
"intl3_tsvn32.pdb"=""
"libsasl.pdb"=""


Wenn man damit dann fertig ist, beendet man Visual Studio und startet es neu, und ab jetzt werden die angegebenen Symbole ignoriert und man kann pfeilschnell debuggen. Auf SAAVIK dauert damit das Öffnen einer File-Open Box dann unter 5s.

Als Referenz ist ein Regfile mit meinen Einstellungen von oben hier zu finden. Einfach die Datei in die lokale Registry reinmergen und dann Rock'n Roll. Debuggt man dann unter einem anderen User muss man das dann für diesen User auch nochmal tun.

Happy debugging and symbol loading, you know, I am.

 

Update (03/14/2013): Registry-Skript und dessen Listing angepasst für die aktuelle Version des Tortoise-SVN-Clients

PREfast und third-party-code

Wenn man Third-Party-Code einsetzt, hat man sehr oft nicht den Luxus, an dem so lange rumschrauben zu können, bis er sauber durch PREfast durchläuft. Ein neues Release dieses Third-Party-Codes, und die Arbeit fängt wieder von vorne an. SQLite ist so ein Fall. Ich benutze in einer Reihe von Projekten die SQLite Amalgamation, das ist ein einziges riesiges C-File namens sqlite3.c mit dem kompletten Code von SQLite drinne. Damit ich Projekte, die sqlite3.c benutzen, auch mit PREfast übersetzen kann und dabei nicht von den Gazillionen von PREfast-Warnungen aus der sqlite3.c, an denen ich eh nichts ändern kann/sollte, erschlagen werde, injiziere ich beim Übersetzen von sqlite3.c ein Headerfile von mir. Das Injizieren von Headerfiles ist ein ziemlich fieses mächtiges Feature von Visual C, das seit Urzeiten in diesem Produkt drinne ist, das aber auffällig wenige Leute kennen. Das ganze geht mit dem Compilerschalter /FI, mit dem man den Namen eines Headerfiles angibt, das gelesen werden soll, und zwar vor allen Headerfiles, die von dem zu übersetzenden Sourcefile inkludiert werden (sogar vor einem eventuell einzulesenden precompiled header). Damit kann man also allerhand fiesen Schabernack treiben und Header inkludieren, ohne Sourcefiles zu ändern. Speziell im Fall sqlite3.c habe ich ein Headerfile namens sqltpref.h, bei dem ich über die include-Pfade dafür sorge, dass es in den relevanten Projekten automatisch über Angabe des Dateinamens gefunden wird, und das in etwa folgendermassen ausschaut:

#ifndef SQLTPREF_H__
#define SQLTPREF_H__

#ifdef _PREFAST_
///
/// here we collect all those warnings that prefast
/// shows if we compile the sqlite amalgamation:
///
#pragma warning (disable:6386 6326 6001 6246 6011 6292 6244 6385 6239 6235 6328 6295)

#endif /// _PREFAST_


#endif /// SQLTPREF_H__

Dann muss ich nur noch in jedem Projekt für die Datei sqlite3.c mit dem Compilerschalter /FI diesen Header injizieren, also durch Angabe von

/FI"sqltpref.h"

auf der Kommandozeile des Compilers. In Visual Studio geht das sehr einfach, indem man die Datei sqlite3.c im Baum vom Solution Explorer anwählt, sich die Properties anzeigen lässt und zur Anzeige der Kommandozeile navigiert unter "Configuration Properties"-"C/C++"-"Command Line". Dort trägt man einfach unter Additional Options den /FI"sqltpref.h" ein und fertig. So sieht das dann in echt aus:

Das war's, damit lässt sich nun sqlite3.c auch dann problemlos übersetzen, wenn mit PREfast übersetzt wird, und bleibt dabei mucksmäuschenstill. Happy PREfasting, you know, I am!

<< 1 ... 6 7 8 9 10 11 12 13 14 15 16 ... 46 >>