Da ich in der Vergangenheit hier einen bunten Mix an Themen abgearbeitet habe, werde ich in Zukunft alle Technik-Themen auf meinem neuen Blog abhandeln.
Ihr findet ihn unter
www.developersdevelopersdevelopersdevelopers.net
Hier gibt es in Zukunft nur noch Fotos oder irgendwelche Belanglosigkeiten.
Im Visual Studio gibt es ein Feature das “Reconcile” heißt. Wenn es eine Kategorie der unbekanntesten Features in Visual Studio gäbe, dann wäre das sicherlich in den top 10%. (Also irgendwo in der Nähe von “Cloak”)
Mit Reconcile kann ich mir den Unterschied zwischen einem lokalen Folder und dem Stand im TFS anzeigen lassen. Wenn man weiß, wo das geht ist es auch ganz einfach. So kommst Du hin:
Im SourceControl Explorer einen Ordner anwählen, Rechtsklick darauf machen und “Compare” wählen. Im folgenden Dialog ein paar Einstellungen zur Anzeige machen. Hier kannst Du auch wählen, gegen welche Version auf dem Server Du vergleichen willst.
Klicke auf OK. Im nachfolgenden Dialog kriegst Du – abhängig von Deinen Einstellungen – angezeigt, welche Files wahlweise nur auf Platte oder nur auf dem Server vorhanden oder unterschiedlich sind.
Das wichtigste kommt aber noch: Der Reconcile Button! Leider ist der Button recht unscheinbar und auch nur enabled, wenn Du einen Eintrag in der Liste markiert hast: Wenn Du jetzt einen Eintrag aus der Liste markierst und “Reconcile” drückst, erscheint folgender Dialog:
Hier hast Du die Möglichkeit den lokalen Stand auf dem Server einzuspielen, bzw Deinen lokalen Stand zu aktualisieren. Dass kann ganz hilfreich sein, wenn man aus irgendwelchen Gründen mal außerhalb des gewohnten Workspaces arbeitet oder aber mal ein paar Dateien hin und herkopiert hat.
Schön ist: Wenn Du vorher noch wissen willst, welche Unterschiede zwischen Files auf lokaler Platte und auf dem Server bestehen, kannst Du über einen Rechtsklick aufs eine Datei “Compare” aufrufen und die beiden Stände vergleichen.
So ganz problemlos war der Umzug dann doch nicht. Kaum umgezogen, konnte ich nicht mehr posten. So musste ich einen Tag warten, bis ich diesen und den vorherigen Post nach dem Umzug abschicken konnte. Folgende Fehlermeldung im Windows Live Writer stellte sich mir in den Weg:
400 Bad Request
Blog has exceeded rate limit or otherwise requires word verification for new posts
Schade, schade. Ich hab schon überlegt, gleich wieder zurückzuwechseln. Offensichtlich war das Problem aber mein Importvorgang des alten Blogs. Dadurch wurde einen Höchstzahl an zulässigen Posts pro Tag überschritten. Kein Wunder, dass es am nächsten Tag (also heute) wieder ging. Dann bleib ich also doch hier.
Ich bin von meinem privat gehostetem Wordpress auf Blogspot.com umgezogen. Warum? Weil ich mich nicht um diesen ganzen administrativen Krempel kümmern will. Und weil mir das Design von genau diesem Blog gefällt 
Der Umzug war relativ einfach:
1. Wordpress exportieren /geht in den Admin Seiten)
2. Auf http://wordpress2blogger.appspot.com/ das exportierte File konvertieren
3. Das konvertierte File bei Blogspot importieren.
4. Anschließend noch meine Domain umbiegen.
5. Fertig.
Von den fleißigen ALM Rangers gibt es wieder wertvolle Beiträge für die Arbeit rund um den TFS und Visual Studio.
Zum einen den Build Customization Guide, zum anderen eine Anleitung wie man am besten Lab Management einsetzen kann.
So, hier noch mal eine Sammlung von wertvollen Links mit Info über die nächste Version von Visual Studio:
Brian Keller (Evangelist bei Microsoft USA):
Hier gibt’s auch ein ganz witziges (aber vielleicht auch etwas unhandliches) Speakflow-Chart zum Download.
Brian Harry (TFS Oberguru bei Microsoft USA):
Christian Binder (Platform Strategy Manager bei Microsoft Deutschland) hat dazu auch einen Webcast gedreht:
http://blogs.msdn.com/b/cbinder/archive/2011/05/28/webcast-preview-visual-studio-vnext-alm.aspx
Jason Zander (Microsoft USA Vice-President) hat auch sehr ausführlich geschrieben was man so erwarten darf:
Hier findet sich auch ein Link zu einem Whitepaper für vNext:
http://go.microsoft.com/?linkid=9772730
Ich freu mich momentan besonders über die wesentlichen Verbesserungen in der Webansicht, über die integrierten Codereviews und über “Intellitrace in Production”. Sehr cool!
If you get TF270015: 'MSTest.exe' returned an unexpected exit code. Expected '0'; actual '1' when running a Team Build in TFS 2010 and can’t get it solved, you should try installing the QFE provided on http://archive.msdn.microsoft.com/KB983504
Even thoug the problem is not listed in the documentation of this QFE, is still seems to fixed it for me. Other guys seem to have made the same experience, as you can see in the discussions on this QFE.
Jeder, der den TFS 2010 im Einsatz hat und sich über die hierarchischen Work Items in der 2010er Version freut, wird früher oder später ganze Subttrees von Work Items auf einmal kopieren wollen. Eventuell auch nur die Userstories, aber nicht die Tasks. Oder die Userstories und die zugehörigen Testfälle, aber nicht die Tasks.
Das Ganze wird dann gerne mal – eventuell noch um ein paar Anforderungen erweitert – als Baselining oder Versioning bezeichnet. Der TFS kann das standardmäßig nicht, so dass es bisweilen lange Gesichter gibt, weil einem die hierarchischen Work Items plötzlich gar nicht mehr so wertvoll vorkommen. Aaaaber, wie wir in der Vergangenheit schon des Öfteren gelernt haben, kann der TFS eigentlich alles – es hat sich nur noch nicht für jedes Thema auch schon jemand gefunden der es mal implementiert hat, um zu beweisen, dass es wirklich geht. 
In diesem Fall schon: Seit gestern ist in der Visual Studio Gallery Work Item Tree Copy verfügbar. Damit können Subtrees von Work Items, die auf Parent/Child Beziehungen beruhen rekursiv kopiert werden. Dazu gibt es einen ganzen Sack voller Optionen, inklusive der Möglichkeit Hyperlinks umzubiegen, Changesetlinks zu erhalten etc, etc, etc.
Entstanden ist das Tool übrigens (wieder mal) unter Zuhilfenahme des (großartigen) Feature Builder Power Tools.
Ist das der Hit? Ich würde sagen: Ja! Probiert es aus! Wenn Ihr Fragen habt oder Feature vermisst, meldet Euch beim Autor. Der freut sich bestimmt.
Endlich ist es soweit: Auf Basis des (großartigen) Feature Builder Power Tools (dem Nachfolger des inoffiziellen Blueprints-Projektes aus dem Jahr 2009) für Visual Studio 2010 habe ich den Check-In Policy Builder erstellt – ein Tool, das mir hilft Check-In Policies für den TFS zu schreiben. Nicht, dass das schwer wäre – aber es gibt ein paar Schritte, die vielleicht einfach etwas lästig sind und jetzt automatisch gehen. Momentan noch als Version 0.7 – ich freu mich über Feedback.
Ich nutze seit einiger Zeit IE 9 Beta. Meine I love Opera Kategorie ist vorerst trotzdem noch gültig. Dennoch gibt es so einige Dinge, die ich an IE9 Beta wirklich mag. Die will ich der Welt natürlich nicht vorenthalten.
1. Der Farbwechsel des Navigationsbuttons
Der Rückwärts-Button wechselt abhängig von der besuchten Seite die Farbe.. Das ist zwar sinnlos, aber irgendwie schick. (Und funktioniert auch nur, wenn man einen Link auf die Seite aufruft.) Das sieht dann ungefähr so aus:
2. Der schnelle Start
IE9 startet schnell. Das ist gut. Mehr muss man nicht wissen.
3. Die Anzeige der Ladezeiten für Add-Ins
Wenn IE9 nicht schnell startet, liegt es wahrscheinlich an einem Add-In. An welchem? Das sagt einem IE9 selbst. Hier hat man dann auch die Möglichkeit die Schuldigen abzuschalten.
Auch, wenn das alles keine Killerfeatures sind: Die gute Nachricht dabei ist: Ich vermisse gerade noch fast nix. D.h. ich kann problemlos IE 9 beta nutzten, statt meiner alten Liebe Opera. Dadurch hat IE9 echte Chancen im Alltag als Standardbrowser zu bestehen. Ein bisschen was fehlt mir aber trotzdem noch, nämlich:
1. Die (anpassbare!) Adressleistensuchfunktion (bekannt aus Opera und Chrome)
2. Die Mausgesten (auch wenn ich gar nicht mehr so oft mit Mäusen arbeite)
3. Die “Roll-Over-Tabs” (ich weiß nicht, wie das wirklich heißt, wenn man eine Maus hat, ist das aber der Hit!)
Aber vielleicht kommt davon ja noch was. Vielleicht in der Beta zwei. Oder in RTM. Die Adressleistensuchfunktion möchte ich auf jeden Fall nicht mehr missen. Den Rest brauch ich nur, wenn ich auch einen Maus hab…
Freudige Neuigkeiten für alle VS2010 Fans: Es gibt einen ganzen Sack voll neuer MSDN Webcasts, die über eine ansprechende Silverlight-App von Christian Binder und Dariusz Parys gebrowsed werden können. Einige der Webcasts habe ich beigesteuert, einen zum Thema Architekturvalidierung und einen zum Thema Code-Visualisierung. Hoffe es hilft ein bisschen bei der Orientierung in diesem umfangreichen Themengebiet…
Edit: Vielleicht nicht zwangsweise informativ, aber immerhin amüsant ist das Announcement auf der offiziellen Visual Studio Website (Monitore te salutant). :-)
Windows Azure ist leider kein Spielzeug. Denn das Pricing Modell ist so undurchsichtig, dass man als Dev jegliche Lust verliert überhaupt das Spielen damit anzufangen. Nicht nur, dass es unglaublich schwierig ist, im Voraus abzuschätzen, wieviel Geld man verbraten würde, wenn man eine “produktive” Anwendung in die Cloud hebt, es gibt auch keinen Limiter oder eine Notbremse, um die Kosten irgendwie zu begrenzen, wenn man nur mal sehen will, was geht.
Zum Vergleich: Wenn ich bei meinem Hoster Webspace anmiete, oder bei meinem Telefonanbieter einen DSL Anschluss will oder einen Datentarif für’s Handy, dann will ich unter Umständen gedeckelte Kosten. Im Gegenzug kann ich damit rechnen, dass meine Leitung gedrosselt wird, wenn ich nach den ersten Tagen des Monats fast das halbe Internet übers Mobiltelefon heruntergeladen habe. Dies nehme ich aber bewusst in Kauf, damit ich auch nach der ersten Rechnung noch mein Frühstücksbrötchen finanzieren kann.
Bei Windows Azure ist das zum heutigen Zeitpunkt nicht so – für produktive, kommerzielle Anwendungen würde es wahrscheinlich auch kein sinnvolles Szenario sein, da ja dort gerade dann Geld verdient wird (nicht nur durch Microsoft, sondern auch durch die in der Cloud gehostete App) wenn viel passiert, also, wenn viel Traffic herrscht. Für die Entwickler Community ist der fehlende Kostendeckel aber ein Problem: Bei Windows Azure kann ich nicht nur konfigurativ, sondern gerade auch programmatisch dafür sorgen, dass ich mehr mehr Rechenpower aus den Microsoft Containern bekomme – in Form von weiteren VMs, die dynamisch hochgefahren werden. Das heißt: Wenn ich falsch programmiere, verbrate ich durch einen einzigen Programmierfehler unter Umständen sehr viel Geld – auch wenn letztlich niemand die Anwendung benutzt – ich wollte ja nur spielen. Und das ist nur einer von vielen denkbaren Fällen und vielleicht sogar noch der unwahrscheinlichste. Ebenso ist es möglich, dass ich schlichtweg vergesse mein Cloud-VM-Cluster abzuschalten oder die Kosten schlichtweg nicht im Blick habe und erst feststelle, wie viel Stunden Rechenzeit ich gebraucht habe, wenn die Rechnung kommt.
Wunschkonzert
Was ich mir wünsche, wäre also eine Art Flatrate: Meinetwegen X€ im Monat für monatlich Y Stunden Rechenpower auf maximal Z VMs plus ein bisschen Traffic. Wenn ich die Grenzen überschreite wird die Bandbreite für “Nutztraffic” reduziert, die Rechenpower meinetwegen auch, aber ich will noch weiterhin vernünftig darauf entwickeln können und meine Anwendung testen können – und natürlich, dass keine weiteren Kosten entstehen. Und: Klaro, ich werde keine kommerziellen Anwendungen darauf hosten, das darf natürlich in die AGBs… ich will ja nur spielen.
Für die Community ist es vielleicht nur ärgerlich, für Windows Azure kann diese Unzulänglichkeit doch bedeutend sein: Spätenstens seit David Chappells Vortrag über IT Innovations bei der Teched 2009 wissen wir ja, dass man gute Ideen nicht nur haben (Idea) und umsetzen muss (Implement), sondern dass man auch Menschen dazu bringen muss diese einzusetzen (Inject). Microsoft war bisher nicht zuletzt im letzten Punkt sehr gut. Aber momentan ist das Pricing für die Cloud leider alles anders als förderlich, was diesen letzten Punkt angeht. Ich hoffe das ändert sich – letzlich steht und fällt der Erfolg für Microsofts Cloud Lösung vielleicht genau mit den Leuten, die sie heute noch nicht ausprobieren – einer breiten Basis in der Community und einem Haufen erstklassiger Entwickler.
Wie schon in einem alten Blogposting erwähnt stellt Microsoft selbst jetzt ein Scrum Prozess Template für den TFS zur Verfügung. Bisher war dieses bereits als Beta verfügbar. Ich bin gespannt, ob die Strukturierung der Workitems über den Workitem-Typen “Sprint” nur als Übergangslösung zu sehen ist, oder ob das die neue Stoßrichtung für Dev11 vorgibt. Bisher wurde die Sprintzugehörigkeit ja ausschließlich über Attribute geregelt. Aus eigener Erfahrung weiß ich, dass das immer wieder für heiße Diskussionen sorgt. Da das Template kostenlos über die VS Gallery kommt, empfehle ich, sich das Ganze einfach mal anzusehen.
Dass die Bilder auf Google’s Internetseite je nach Tagesgeschehen und Jahreszeit ab und an mal geändert werden, dürfte ja jedem schon mal aufgefallen sein. Aktuell zu sehen: Ein Fußballstadion und die Fähnchen der Finalisten. Schätze in ein paar Stunden ist es wieder weg… für alle die zu spät kommen:
Wenn die WM gut läuft, dann hat das schon mal Auswirkungen auf Fortschrittsgraphen jeglicher Art…
Opera 10.60 bietet jetzt die Möglichkeit andere Opera User zu finden. Ich bin mir noch nicht im Klaren darüber, was es bringt, aber es ist auf jeden Fall witzig. Und die Genauigkeit ist beängstigend. Hier bin ich:
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.
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.
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”.
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.
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.
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.
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.
Was ist schiefgelaufen? Man hat doch scheinbar alles richtig gemacht – auch tfpt query /help bringt nicht mehr Infos.
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:
Wunderbar. Hoffe geholfen zu haben
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.
