Natürlich nicht – ausser die Stunden monotoner Arbeit um all die Strings in Resource-Files zu verschieben. Moment – monoton, verschieben – das könnte was für meinen Freund ReSharper sein!

Also mal [CTRL]+[SHIFT]+R drücken und schauen was er mir da so anbietet:

Perfekt!

Hier lassen sich die einzelnen Werte abfüllen und mit Next werden diese dann in das ausgewählte Resource-File verschoben und der Code entsprechend angepasst.

Und es kommt noch besser! ReSharper kann auch noch den weiteren Code nach demselben Text durchsuchen und diesen Code dann ebenfalls entsprechend anpassen:

Eines der Kommandos, welches ich sicher einmal in der Woche nachschlage ist ,

git reset HEAD

was so in etwa einem “Revert” in Subversion gleichkommt.

Natürlich offeriert das reset-Kommando noch eine Vielzahl von Optionen, aber in 99% der Fällen brauche ich halt genau genanntes. Da Git ein offenes System ist, hat es auch nix dagegen, wenn ich mir da halt eigene Befehle definiere – mit Aliasen.

Um solche zu definieren, öffnet man die .gitconfig-Datei, welche sich normalerweise unter %userprofile%\.gitconfig befindet.

Um einen Alias zu definieren, ergänzt man die Datei einfach wiefolgt:


[alias]
unstage = reset HEAD


Damit kann ich nun mit git unstage ein git reset HEAD ausführen, was, zumindest für mich, wesentlich naheliegender ist und so auch besser hängenbleibt. Natürlich können so auch komplexe Befehle die man immer wiedermal braucht mit einem einfachen Alias versehen werden – zum Beispiel eine hübsch formatierte Log-Ausgabe.

Die Antwort: Doch, kann er natürlich mit links, aber ganz ohne Köpfchen gehts dann doch nicht.

Das Problem…

… liegt eigentlich auf der Hand. Eine Klassenmethode hat in der Regel Abhängigkeiten zu Membern der Klasse in der sie sich befindet. Wie soll nun ReSharper mit diesen Abhängigkeiten umgehen? Zum Glück macht er das nicht irgendwie, sondern erwartet da etwas Vorarbeit vom Entwickler.

Die Lösung…

… liegt meist nahe, wenn man sich das Problem mal klar gemacht hat – so auch hier. Es gilt also, diese Abhängigkeiten aufzulösen – was bei statischen Methoden der Fall ist.

Als einfaches Beispiel nachfolgende Methode,  welche in die Klasse C verschoben werden soll:

public int Compute()
{
    int result = _b.Read();
    return result;
}

Hier gibt es eine Abhängigkeit auf _b. Um diese Abhängigkeit aufzulösen, übergibt man sie als Parameter an die Methode. Und da eilt ReSharper natürlich bereits mit einem Helferlein herbei:

public int Compute(B b)
{
     int result = b.Read();
     return result;
}

Damit hat die Methode keine direkten Abhängigkeiten mehr zur Klasse, was es einem erlaubt, diese auch als statisch zu deklarieren.

Die beiden Schritte könnte man in diesem Fall sogar in einem Rutsch tun. Der Dialog von “Make Static…” bietet eine Option, die Abhängigkeit _b als Parameter zu definieren:

Je nach Komplexität der Methode, muss man jedoch doch auf die obere, zweistufige Methode zurückgreifen.

Und ist die Methode dann erstmal statisch, verweigert ReSharper auch die Move-Funktion nicht mehr:

TextTrimming zeigt bei einem Überlauf eines Textes automatisch 3 Punkte an – im Gegensatz zum Beispiel ohne TextTrimming, wo das ganze einfach abgeschnitten wird.

Die Umsetzung könnte einfacher nicht sein:

<TextBlock Text="Ich bin ein langer Text" TextTrimming="WordEllipsis" Width="116" />

Mehr Verfeinerungsmöglichkeiten gibt es zwar – wie etwa bei WPF – nicht, aber immerhin.

Da meckert also der Compiler “Cannot resolve ‘EntityState’”. EntityState ist ein Property, welches in der Klasse EntityObject definiert ist – welche in Nicht-Poco-Szenarien die Basisklasse aller Entities ist. Da die POCO’s natürlich nicht von dieser Klasse ableiten (und dies auch nicht tun sollen), ist hier eine Alternative gefragt.

Die ObjectContext-Instanz bietet Zugriff auf den ObjectStateManager. Mit dessen Methode “TryGetObjectStateEntry” kann man den EntityState jeder Entität herausfinden. Eine entsprechende Hilfsmethode könnte so aussehen:

private EntityState GetEntityState(object entity)
{
    ObjectStateEntry stateEntry;
    if (ObjectContext.ObjectStateManager.TryGetObjectStateEntry(entity, out stateEntry))
    {
        return stateEntry.State;
    }
    return EntityState.Detached;
}

Noch einfacher wirds, wenn die Entitäten eine gemeinsame Basis teilen (hier BaseEntity). Mit etwas ExtensionMethod-Magic lassen sich die notwendigen Anpassungen an der generierten Service-Klasse dann auch mit “Find and Replace” lösen:

private EntityState GetEntitySate(this EntityBase entity, ObjectStateManager stateManager)
{
    ObjectStateEntry stateEntry;
    if (stateManager.TryGetObjectStateEntry(entity, out stateEntry))
    {
        return stateEntry.State;
    }
    return EntityState.Detached;
}

Eigentlich etwas armselig, dass sowas überhaupt nötig ist – aber zumindest eine einigermassen komfortable Lösung.

Um einen Data Generation Plan zu machen, muss man ein Datenbank-Projekt erstellen.

Dann importiert man die Schema-Informationen.

Danach kann man dem Projekt einen neuen Data Generation Plan anfügen.

In dem Generation Plan können dann pro Feld einige Einstellungen zu den Generierungsdaten gemacht werden – und vor allem kann auch die Anzahl der zu generierenden Datensätze definiert werden.

Dann nur noch den Plan starten – und schon ist die Tabelle voll von Daten

So mächtig wie der Data Generator von Red Gate ist das zwar bei weitem nicht, aber so für eine einfache Testdaten-Generierung reicht das allemal.

Die TechDays fanden dieses Jahr im Congress Center in Basel statt. Die Location war soweit in Ordnung, ausser das in div. Sessions die Internetverbindung unbrauchbar instabil war – wer auch immer dafuer grade stehen muss, kriegt hoffentlich einen Rüffel. Wenigstens auf die Swisscom Hotspots war verlass, so konnte auf diese ausgewichen werden.

Aber das wichtigste sind wohl die Sessions, und diese enttäuschten (mit wenigen Ausnahmen) durchs Band.

Schon die KeyNote liess nichts gutes erahnen: nachdem man die zwei, milde gesagt, unkomischen Komiker ertragen hatte, gabs einen Vortrag über das eigentlich sehr verheissungsvolle Thema Film-Effekte. Leider war das ganze viel zu wenig konkret und technisch, so dass es mehr oder weniger darauf hinauslief, dass man Szenen aus Hellboy II (ohne Ton) geniessen konnte. Da wäre mehr drin gelegen.

Die eigentlichen Sessions fingen dann sehr gut an. Ronnie Saurenmann gab bei seiner Silverlight 4 Introduction alles! Das war komischer als die beiden angestellten Komiker und informativ zugleich. Bis auf die Advanced Silverlight-Session (wieder von Ronnie Saurenmann) konnte man den ersten Tag aber getrost vergessen. Tiefpunkt war der zweiteilige Vortrag “Sharepoint fuer Entwickler” von Olaf Feldkamp. Da war einfach viel zu wenig Fleisch am Knochen und das ganze war trotz des Titels eher auf ein Management-Publikum ausgerichtet.

Am zweiten Tag kann ich nur die Session von Michael Hofer zu den Sandboxed Solutions positiv herausheben. Der Inhalt war dem Publikum entsprechend technisch und hatte auch etwas Tiefe. Vorgetragen war das ganze locker und angenehm. Schade nur das Michael den Lumpensammler-Slot ganz am Schluss erhalten hat.

Ansonsten hätte ich auch den zweiten Tag besser an der Sonne verbracht.

Als Tüpfelchen auf dem i stellte sich dann das “Abschlussgeschenk” von Microsoft heraus. Beim rauslaufen erhielt jeder Teilnehmer eine gefuellte Strandtasche – gefuellt mit Werbung – komplett für die Tonne. Das alles in Kombination ist fast schon eine Frechheit für eine Veranstaltung die fast CHF 520 kostet. Da habe ich an kostenlosen (Partner-) Events von Microsoft schon viel besseres erlebt.

Ach ja – damit sich der Kreis wieder schliesst. Nein auch das Essen holte das ganze nicht raus. Es war zwar einigermassen ok, aber mehr auch nicht.

Ich hoffe MS geht hier für naechstes Jahr nochmals  ueber die Bücher – sonst waren das meine letzten TechDays. Gefordert sind mehr Tiefe, mehr Technik, weniger Marketing – und gutes Essen Und bitte lasst das mit den Drittliga-Komikern, das braucht niemand.

Die entsprechende Option kann in den ReSharper-Optionen aktiviert werden:

Nachdem in meiner Twitter-Timeline der #git-Hashtag immer öfters auftauchte, schaute ich mir das doch  mal etwas genauer an. Ein paar Tage später, laufen sind nun alle meine SVN-Repositories nach git migriert…

Was ist git?

git gehört zu den Distributed Version Control Systemen. Verteilt heisst hier, dass es nicht ein zentrales Repository gibt, sondern eben verschiedene, verteilte. Holt man sich bei Subversion eine lokale Arbeitskopie eines Repositories, hält man sich bei git das komplette Repository lokal. Ein lokales Repository bietet diverse Vorteile:

• Offline Commits: Da ich lokal nicht nur eine Arbeitskopie habe, sondern aber ein komplettes Repository samt History, kann ich auch lokal (bzw. offline) committen. Auch für Diffs etc. ist kein Online-Zugriff notwendig.
• lokale Branches: Auch Branches können dementsprechend lokal erstellt werden, ohne dass die Co-Devs jemals etwas davon erfahren müssen
• Geschwindigkeit: Files adden, committen – es flutscht gewaltig
• Speicherplatz: Durch die Art wie git intern arbeitet, braucht es massiv weniger Speicherplatz wie Subversion (massiv kann durchaus Faktor 2-3 heissen).

Jeder Entwickler hält sich also lokal ein Repository. Natürlich muss es dann trotzdem irgendwo ein “Master”-Repository geben, wohin dann die Änderungen dann mal gepusht werden. Dies alles bedarf natürlich möglichst effizienten und einfachen Branching und Merging-Mechanismen – da hab ich noch nicht allzuviel probiert, aber was ich bis jetzt gesehen habe reicht, um Subversion in Rente zu schicken!

Bald folgt mehr

Der Resharper bringt hier schon einige von Haus aus mit:

Da gibt es solche darunter, die einem einfach etwas Tipparbeit sparen (aus “thr” resultiert “throw new “) und andere, die etwas aufwändigere Konstruktur kreieren, so entsteht aus “itdic” eine Iteration über ein Dictionary:

Dabei sind die grün bzw. blau hinterlegten Bezeichnungen Platzhalter, welche mit TAB durchsprungen werden können – so hat man das eingefügt Snippet innert kürze für die jeweilige Situation angepasst. Resharper probiert bei der Wahl der Platzhalter jeweils auch herauszufinden, was man tun möchte. So leitet er aus meiner vorgängigen Initialisierung des dic-Dictionaries automatisch ab, dass ich wahrscheinlich darüber iterieren möchte, und dass dieses Dictionary einen Key vom Typ Integer und den Wert als String enthält.

Wer sieht den Fehler? Genau, die Iterationsvariable ist vom Typ DictionaryEntry statt KeyValuePair und die Casts im Body sind überflüssig. Das heisst, dieses Live Template ist für die Verwendung mit “klassischen” Dictionaries gedacht, nicht aber für generische.

Was nicht ist, kann ja noch werden

Und hier wirds erst richtig spassig. Live-Templates können auch ganz einfach selbst erstellt werden. Hierfür gibt es einen einfachen Editor, wo man sich die Live-Templates erstellen kann. Unser angepasstes Skript von oben sieht nun folgendermassen aus:

Man definiert also das Template mit Platzhalter. Für diese wiederum kann man dann Makros definieren, welche dem Live Template eine gewisse Inteligenz mitgeben. So wird hier als Beispiel für den DICT-Platzhalter definiert, dass eine Variable vom Typ System.Collections.Generic.Dictionary vorgeschlagen werden soll. Dies veranlasst Resharper bei der Verwendung des Templates dann dazu, im Code nach einer entsprechenden Variable zu suchen.

Wenden wir nun das Template auf unseren Code von oben an:

Et voilà – nun passts perfekt. Die Typen werden korrekt erkannt und die Iterationsvariable hat jetzt auch den korrekten Datentyp. Nettes Gimmick dazu: Im eingeblendeten DropDown macht uns Resharper gleich noch Namensvorschläge die an dieser Stelle evtl. Sinn machen könnten.