Seiten

Freitag, 25. Juni 2010

Letzter Aufruf: Dot-Net-Day

Jeder, der immer noch nicht weiß, was er an diesem Wochenende treiben soll, dem sei der .Net-Day Franken ans Herz gelegt. Wann? Morgen! Mehr Info gibt’s hier. Hingehen! Wir sehn uns dort.

Montag, 14. Juni 2010

Cloaking is a Private Thing

Visual Studio versteckt ja so einige Perlen, die man erst nach und nach entdeckt. Eines dieser mitunter wertvollen – aber auch reichlich unbekannten Features  - ist das “Cloaking”. Wie geht das, was ist darunter zu verstehen, wofür ist es gut?

Wie geht’s? 
Man kann im Visual Studio – unter Verwendung von Team Foundation Server als Quellcodeverwaltungssystem –. beliebige Ordner und Branches im Source Control Explorer über das Kontextmenü “Cloaken”. Einfach Ordner anwählen, rechte Maustaste, Cloak. Die Inhalte der Folder werden dann im SourceControl Explorer ausgegraut dargestellt.

Cloaking - so geht's.

Was bewirkt das?
Das hat zu Folge, dass die “gecloakten” Inhalte nicht mehr vom Team Foundation Server nachgeladen werden – auch wenn zum Beispiel auf den übergeordneten Ordner ein “Get Latest” ausgeführt wird.

Wer braucht das?
Man stelle sich die Situation vor, dass man als Mitglied eines Entwicklungsteams bestimmte Bereiche der Quellcodeverwaltung schlicht und ergreifend nicht benötigt. Zum Beispiel, weil darin Quellcode für Komponenten entwickelt wird, mit denen man nie in Berührung kommt, und deren Schnittstellen einem auch herzlich egal sein können. Oder Branches, auf denen man eben gerade nicht arbeitet. Oder es liegen dort zwar Dateien, diese sind aber nicht für das Produkt selbst, sondern für die Herstellung der Binaries relevant – zum Beispiel Buildskripte. Dann ist genau der richtige Zeitpunkt um zu “Cloaken”.

Prädestiniert für's Cloaken - der BuildProcessTemplates Ordner in VS2010. Auch wenn hier nicht viel Bandbreite gespart wrden wird.

Welchen Vorteil bringt es?
Das Cloaken bringt folgenden Vorteile mit sich:
1. Zeitersparnis – beim Ausführen des “Get Latest” Befehls werden gecloakte Unterordner nicht mit vom Server geladen. Unterm Strich geht’s also schneller, bis man die neueste Version der benötigten Files auf seiner lokalen Platte hat.
2. Bandbreitenersparnis. Aus genau dem gleichen Grund. Aus eigener Erfahrung kann ich berichten, dass Bandbreite in vielen Firmen noch ein wesentlich limitierender Faktor ist, als man im Jahr 2010 erwarten würde. Gut also, wenn man hier auf einfache Weise was sparen kann.
3. Plattenplatzersparnis – es werden weniger Files geladen. Man kann also, wenn es sinnvoll ist, gewisse gemappte Folder einfach nie getten – nicht mal einmalig. Bei riesigen Quellcodebeständen spart man sich so haufenweise Plattenplatz. Natürlich geht das nur dann, wenn man den entsprechenden Quellcode nicht doch lokal benötigt…

Gibt’s auch Nachteile?
Ja. Größter Nachteil ist, dass man genau wissen muss, was man tut. Es ist zwar einfach zu bedienen, aber man muss sich bewusst sein, dass die gecloakten Files zwar noch physikalisch auf der Platte liegen (wenn sie überhaupt schon da waren)  – d.h. sie können auch referenziert werden (bspw Dlls) – aber die neueste Version eben nicht mehr automatisch vom Server geladen wird (was ja auch Sinn und Zweck ist). Wenn man also mal “vergisst”, dass man Cloaking verwendet hat, läuft man Gefahr Inkonsistenzen zu produzieren. Also: Mit Bedacht wählen was gecloakt wird – natürlich kann man es jederzeit wieder rückgängig machen.

Cloaking - so macht man's rückgängig.

Wen betrifft meine Cloaking-Einstellung eigentlich?
Sehr gute Frage, die immer wieder gestellt wird und bereits mit der Überschrift dieses Posts beantwortet wird: “Cloaking is a private thing” – man trifft diese Einstellung also immer nur für sich alleine und immer nur für jeweils genau einen Workspace zur gleichen Zeit. Das ist eigentlich auch sehr logisch. Den Ordner BuildProcessTemplates beispielsweise kann so ziemlich jeder im Team gefahrlos cloaken,  bis auf diejenigen, die tatächlich daran arbeiten – also eben z.B. der Buildmanager. Eine Entscheidung auf Teamebene was geclaokt wird und was nicht wäre also ziemlich sinnlos.
Das gleiche gilt für Workspaces: Die Einstellungen für Cloaking kann für den Laptop zuhause grundlegend anders sein, als die Einstellung für den Arbeitsplatzrechner im Büro.

Donnerstag, 10. Juni 2010

TFS Powertools: TFPT – Unable to determine the source control server

Kurzversion:  Um das Problem zu lösen, braucht Ihr mit TFS2010 den Parameter “/collection”. Unter TFS 2008 “/server”.

Langversion: An dieser Stelle mal ein kleiner Hinweis für alle, die die Team Foundation Powertools auch über die Kommandozeile benutzen wollen - ich stolpere selbst oft genug und immer wieder darüber. Man will ein Kommando abfeuern und um sich zu versichern, was man tun muss, gibt man erstmal nur “tfpt” ein. Ergebnis: Siehe Screenshot.

Die Befehle der Powertools über die Kommandozeile

Nächster Schritt: Zum Beispiel eine Query absetzen. Also, laut Screenshot ungefähr sowas eingeben:

tfpt query /wiql”Select [System.Id]  from WorkItems“

Aber – so leicht ist es nicht! Man bekommt folgende Fehlermeldung: Unable to determine the source control server.

Fehlermeldung: Unable to determine the source control server.

Was ist schiefgelaufen? Man hat doch scheinbar alles richtig gemacht – auch tfpt query /help bringt nicht mehr Infos.

Die Hilfe bringt eben leider keine Hilfe.

Die Lösung

Ok, was muss man also tun?

Schritt 1: Googlen (oder Bingen), auf (zum Beispiel) diesen Blog-Eintrag stoßen, lesen.

Schritt 2: Den fehlenden Parameter angeben, der irgendwie NIRGENDWO beschrieben ist: /collection . Kleiner Hinweis an dieser Stelle:  Bei VS 2008 hieß der Parameter noch /server, da es ja die Collections noch nicht gab. Entsprechend hat man auch nur die URL des Servers übergeben. Jetzt ist es die URL der Collection.

So heißt der Befehl in meinem Fall also richtig:

tfpt query /wiql:"Select [System.Id]  from   WorkItems" /collection:http://mrblonde:8080/tfs/DefaultCollection

Natürlich müsst Ihr “mrblonde” noch mit Eurem eigenen Servernamen ersetzen und auch den Collectionnamen anpassen.

Und so schaut das Ergebnis aus:

Undokumentierten Parameter /collection nicht vergessen - und schon geht's!

Wunderbar. Hoffe geholfen zu haben

Montag, 7. Juni 2010

Scrum Process Template für Team Foundation Server 2010

Heute wurde auf der Teched in New Orleans das erste offizielle Scrum Prozess Template für Visual Studio 2010 / Team Foundation Server 2010  vorgestellt – und zwar nicht von Drittherstellern, sondern von Microsoft selbst. Man konnte zwar schon bisher Scrum mit dem eingebauten MSF for Agile abbilden, 100% passend war es aber ohne eigene Modifikationen nicht. Momentan ist die verfügbare Version noch im Beta Status, einen geplanten Relase Termin habe ich noch nirgendwo gefunden. Wer mehr wissen will, ist gut beraten den entsprechenden Blogeintrag von Brian Harry zu lesen.

Freitag, 4. Juni 2010

Was ist cool an Visual Studio 2010?

Wer es schon immer wissen wollte – hier die Antwort. Das Video ist das Ergebnis einer spontane Aufnahme einiger Arbeitskollegen, die versuchen auf die Frage “Was ist cool an Visual Studio 2010?” eine Antwort zu geben. Das Video ist auch zu finden als Video Response im offizellen Developerstories YouTube Channel . Ungestellt und genauso unvorbereitet. Und trotzdem wahr. Enjoy!

Mittwoch, 2. Juni 2010

ALM – ab welcher TeamGröße lohnt es sich?

Bei der Diskussion über Application Lifecycle Management (beispielsweise, aber nicht zwingend auf Basis von Microsoft Visual Studio 2010) taucht immer wieder die gleiche Frage auf: Wann ist ein Team groß genug, damit es sich lohnt über ALM nachzudenken?

Die Antwort ist eigentlich relativ einfach. Mindestteamgröße: 1 Person. Es lohnt sich also immer. Und überall. Mag sein, dass es unglaubwürdig scheint. Ein Beispiel folgt sogleich. Wichtig ist vorab eines zu beachten: ALM ist nicht gleich ALM. Entscheidend ist, dass man sich über die Prinzipien von ALM im Klaren ist – dann kann man sich die Stücke rauspicken, die einen weiterbringen.

Ein Beispiel aus meinem eigenen Erfahrungsschatz

Als jemand, der beruflich mit SW-Entwicklung zu tun hat, ist man ja Ansprechpartner Nummer eins für die ganze (potentiell sehr große) Verwandtschaft und Bekanntschaft, wenn es darum geht “nur ganz schnell” mal “eine kleine” Website zu basteln. Und weil man ja nicht so sein will, sagt man eben mal “Ja” und tut’s. Das Basteln von privaten Homepages entspricht in vielerlei Hinsicht der Entwicklung einer kommerziellen Software. Größter und vielleicht einziger Unterschied ist: Der Ersteller sieht dafür kein Geld. Der Rest verläuft eigentlich wie immer …

Alles wie immer

Ihr glaubt es nicht? Hier ein Auszug…

1. Der Auftraggeber hat am Anfang überhaupt keinen Plan, was er überhaupt will. Fest steht allerdings, dass die Website am Ende supersexy sein muss.

2. Der Auftraggeber weiß noch nicht mal wofür er die Website eigentlich will. Es ist also vollkommen unklar, ob er ein Gästebuch, ein Fotoalbum oder irgendeine Art User-Authentifizierung braucht. (Oder nichts von alledem.) Klar ist nur: Am besten alles mal einbauen, damit er danach sagen kann, dass er’s doch nicht will.

3. Der Auftraggeber hat keinen Schimmer von der Technik. Es hilft nix irgendwas zu erklären. Das einzige was den Auftraggeber dazu bringen wird irgendwann mal zu sagen “Gut” oder “Schlecht” ist, wenn er die fertige Seite vor sich hat und feststellt, was überflüssig ist.

Entscheidet selbst, inwieweit das Euren Erfahrungen aus dem “echten” Berufsleben entspricht…

Die Anforderungen

Um sich das Leben nicht unnötig schwer zu machen, müssen wir nach gesundem Menschenverstand unter Berücksichtigung der obigen Punkte ungefähr folgendermaßen vorgehen, um zum Ziel zu kommen.

1. Den Auftraggeber frühzeitig in die “Lösung” einbinden.
2. Feedback ermöglichen und strukturiert sammeln und ebenso strukturiert abarbeiten.
3. Eine Möglichkeit finden, dem Auftraggeber heute nachzuweisen, dass er die Meinung von vorgestern gestern verworfen und heute wieder für gut befunden hat.
4. Aus genau diesem Grund eine Möglichkeit schaffen, den Quellcodestand von gestern wieder herzustellen – und dann auch zu wissen, was da eigentlich schon implementiert war.
5. Sich Schritt für Schritt vortasten.
6. Die Übersicht bewahren. Das heißt, genau wissen was erledigt ist, was wichtig ist, was nichtig ist.

Moment. Das klingt doch irgendwie nach ... irgendeiner Art Arbeitspaketverwaltung jenseits von Post-Its und Emails und vielleicht sogar iterativem Vorgehen? Nach Nachverfolgbarkeit und Reproduzierbarkeit?

Die Lösung

Struktur in den Arbeitspaketen? Workitems! Feedback? Workitems! Requirement Tracking? Workitems! Und schon sind wir mittendrin in der wunderbaren Welt von ALM. Und am Rande: Die Technologie des Produkts ist uns zu diesem Zeitpunkt noch absolut egal!

Das Beispiel ist übrigens nicht frei erfunden, sondern ich bin tatsächlich dazu übergegangen auch im Privaten (im konkreten Fall ein PHP-Projekt) mit Workitems und Team Foundation Server 2010 als ALM Plattform zu arbeiten.  Die sieht zwar nicht zwangsweise der “Kunde”, ich pflege die  gesammelte Information selbst in den TFS ein. Meine Erfahrung bisher: Alles supi. Übersicht ohne Ende. Kein Stöbern mehr in alten Mails, kein Wühlen in Post-Its oder anderen Zettelwirtschaften. Und gleichzeitig die hervorragende Möglichkeit Quellcodeänderungen auf Workitems zurückzuführen. Durchgehendes Nachverfolgen von Anforderungen im TFS  - klingelt da was?  Ich musste auch keinen separaten Server installieren: Microsofts TFS Basic läuft auch unter Windows 7 und Windows Vista. Sonst noch Wünsche?

Natürlich ist Workitem Management und Quellcodeverwaltung nicht alles, was ALM ausmacht. Es ist vielmehr nur der Anfang - aber das schöne ist ja: Man braucht nicht immer gleich alles. Ich zum Beispiel muss mir bei meinen privaten Projekten kaum Sorgen machen über Termine. Sie werden fertig, wenn sie fertig werden. Dafür sind sie auch privat.

Das ist in den wenigsten anderen Fällen so. Wenn im Privaten unter diesen “weichen” Rahmenbedingungen allerdings schon der Nutzen spürbar ist, alleine dadurch, dass ich eine Quellcodeverwaltung und ein anständiges Workitem Management etabliert habe und mir Gedanken über die Qualität meines Codes mache – wie hoch darf man dann erst den Nutzen ansetzen, wenn es wirklich ums Geld geht? Und um’s Geld geht’s nun mal, sobald ein Entwickler das Entwickeln anfängt.  

Vielleicht ändert sich das irgendwann bei mir auch einmal und meine privaten Projekte müssen plötzlich höhere Anforderungen erfüllen. Dann nehme ich eben noch die Planungskomponente des TFS auf Basis von Excel und Project dazu. Oder ich möchte noch wertvolles und aktuelles Reporting – das wird spätestens wichtig, wenn es um Geld und Zeit geht. Oder ich lass mal ein bisschen automatisiert die Web-UIs testen, um Zeit zu sparen und gegen Regression gefeit zu sein. Muss ich dann auf eine neue ALM Plattform? Nein, mein TFS bringt’s mit und ich aktiviere es, wenn ich es benötige. Check-In Policies um die Qualität oben zu halten? Oh, ganz vergessen: Hab ich eh schon eingeschalten… hilft mir ja selbst am meisten. Und wenn man den TFS sowieso schon nutzt, bekommt sie ja ohnehin geschenkt…

Fazit

Wie gesagt: Mindestgröße ist 1 Person. Schon da kann es sich spürbar lohnen. Und spürbar heißt, dass die Beteiligten leichter/schneller/besser  arbeiten können. Verundet oder verodert. Man braucht nicht immer alles, was irgendwelche Tools hergeben. Man entscheidet selbst, was weiterhilft. Aber wissen muss man schon was es noch gibt und was noch geht. Sonst weiß man ja auch nicht, was man beruhigt weglassen darf…