Archiv

Archive for Oktober 2012

GitHub for Windows – oder Git einmal einfach

23. Oktober 2012 4 Kommentare

Die Versionsverwaltung Git wird unter Windows immer noch zurückhalten eingesetzt. Auch wenn man mit Helfern wie der Console 2 vieles einfacher machen kann, so bleibt Git doch ein komplexes Kommandozeilen-Tool. Die grafischen Oberflächen konnten einem meist auch nicht wirklich überzeugen – fehlende Befehle und Beschriftungen wie von Subversion her störten den Arbeitsfluss zu sehr.

Dieses Problem fiel auch GitHub auf. Eine Firma die ihr Geld mit Dienstleistungen rund um Git verdient möchte natürlich überall präsent sein. Da es an einem guten GUI für Windows fehlte, machte man halt selber eines.

 

Installation

GitHub for Windows lässt sich von http://windows.github.com/ herunterladen. Im *.exe ist ein Installer verpackt der Git in einer Sandbox installiert. Damit kann man problemlos Git installieren und braucht sich um sein System keine Gedanken zu machen – dies bleibt bis auf die Desktop-Icons unangetastet.

Idealerweise erzeugt man nebenher einen Account bei GitHub und verbindet sich gleich mit diesem. Dies ist nicht notwendig um die Applikation zu nutzen, man hat so aber gleich alle Einstellungen im Client und muss nichts mehr von Hand anpassen.

 

Klonen leicht gemacht

Wie man erwarten darf wurde die Anwendung sehr gut in GitHub integriert. Schaut man sich nun ein Projekt auf GitHub.com an, sieht man in seinem Browser (Firefox, IE und Chrome) den Knopf [Clone in Windows]:

Ein Klick darauf genügt und GitHub for Windows öffnet sich und klont das gerade ausgewählte Repository auf den Rechner.

 

Neues Repository anlegen

Ein neues Repository kann man genau so einfach anlegen wie eines zu klonen. Man kann entweder den Knopf [add] auf der Übersichtsseite anklicken oder den Ordner der als neues Repository geführt werden soll auf die Anwendung ziehen. Der einfach gehaltene Dialog ermöglicht einem einen Namen und eine Beschreibung zu vergeben. Wählt man die Option „Push to GitHub“ wird auch gleich alles konfiguriert um das Repository auf GitHub zu veröffentlichen.

Neben dem .git Ordner wird in diesem Schritt ebenfalls eine .gitignore und .gitattributes Datei angelegt. So werden automatisch all die temporären und benutzerspezifischen Dateien ausgeschlossen, die man meist nicht veröffentlichen will. (Will man diese Dateien doch drin haben kann man .gitignore selber anpassen.)

 

Änderungen speichern und anschauen

Nachdem man seine Änderungen gemacht hat geht es an den commit. Dazu öffnet man das Repository in GitHub for Windows und sieht auf einen Blick was sich verändert hat:

Nach dem man eine passende Beschreibung eingetragen hat genügt es auf [commit] zu klicken und die Änderungen sind als neue Version gespeichert.

Der gleiche Dialog dient einem auch um die Änderungen zu verfolgen. Dazu wählt man in der rechten Spalte die gewünschte Version und sieht alle veränderten Dateien mit den Anpassungen.

 

Änderungen publizieren

Wer seine Arbeit veröffentlichen will wird auch hier von GitHub for Windows unterstützt. Dazu genügt auf dem Repository ein Klick auf [push to github]. Im Dialog genügt es den Namen zu überprüfen (und bei Bedarf zu ändern) und mit einem weiteren Klick auf [push] wird das Repository zu GitHub hochgeladen:

Hat man dies einmalig gemacht genügt ein Klick auf [sync] um die lokale Arbeitsversion mit dem Repository auf GitHub abzugleichen.

 

Wenn mal etwas schiefläuft

Nicht immer gelingen einem allen Änderungen im ersten Anlauf. GitHub for Windows hat dafür auf der Repository-Seite 2 hilfreichen Funktionen:

  • [Revert commit] erzeugt einem die Gegenaktion zum gemachten Commit. Was man dort gelöscht hatte ist nun wieder drin und was hinzugekommen ist wird entfernt.
  • [Rollback to this commit] verwirft alle Änderungen zurück bis zur ausgewählten Version. Ist dies die letzte Version kann man den letzten Commit nochmals verändern. Andernfalls löscht es alle Änderungen die seit der ausgewählten Version gemacht wurden.

Genügt einem dies nicht kann man über [Tools] / [open a shell here] auf der Kommandozeile auf alle Git-Befehle zurückgreifen.

 

Nicht nur GitHub

Mit GitHub for Windows kann man jedes beliebige Git-Repository verwalten. Da GitHub private Repositories nur gegen Bezahlung anbietet greife ich gerne auf den Service von Bitbucket zurück.
Um das Repository mit Bitbucket zu verknüpfen muss man den Settings-Dialog auf dem Repository öffnen und die URL gemäss den Angaben von Bitbucket einfügen. Von da an gehen alle Aktionen genauso wie sie auch mit GitHub laufen.

 

Fazit

GitHub for Windows ist aus meiner Sicht der derzeit beste Client für Git auf Windows. Die Funktionalität der GUI-Anwendung deckt das ab was man als „normaler“ Anwender mit Git machen will. Soll es doch einmal nicht genügen stehen einem mehrere konfigurierte Konsolen zur Verfügung.

Das problemlose Zusammenspiel mit anderen Hostern wie Bitbucket macht dieses Tool auch für all diejenigen interessant, die nicht mit GitHub arbeiten wollen.

Schlagworte: ,

Schnellere Webanwendungen dank MiniProfiler

17. Oktober 2012 Kommentare aus

Performance-Probleme bemerkt man meist erst dann wenn es zu spät ist – in der Produktion. Die kleine Menge an Testdaten auf dem Entwicklungssystem verzeihen einem so manche Unachtsamkeit und Ressourcenverschwendung. Unnötige SQL-Abfragen und die Select N+1 Problematik könnte man schon früh erkennen. Nur wer nimmt sich die Zeit immer den Profiler zu starten und alles zu überprüfen?

Wäre es nicht toll wenn im Hintergrund immer ein Profiler laufen und einem mit den Auswertungen versorgen würde? So könnte man immer mal wieder einen Blick aufs Ergebnis werfen und bei lange dauernden Aktionen gleich sehen wo die Ursache liegt. Tönt dies zu schön um wahr zu sein?

MiniProfiler bietet einem genau diese Funktionalität für ASP.Net und ASP.Net MVC Anwendungen. Dieser Profiler stammt von Stack Exchange und hilft dort beim optimieren aller Seiten der Stack Overflow-Familie.

 

Installieren

Die Installation von MiniProfiler erfolgt über NuGet. Wie immer kann man über die grafische Oberfläche das Paket suchen und installieren oder man nutzt die Konsole:

Install-Package MiniProfiler

 

Aktivieren

Um dem Profiler den Anfang und das Ende eines Requests mitzuteilen muss man die Datei Global.asax um diese beiden Methoden Erweitern:

protected void Application_BeginRequest()
{
    if (Request.IsLocal)
    {
        MiniProfiler.Start();
    }
}

protected void Application_EndRequest()
{
    MiniProfiler.Stop();
}

Damit auch etwas angezeigt wird muss die Datei \Views\Shared\_Layout.cshtml direkt vor dem schliessenden Body-Tag mit einem Aufruf zum Rendern der Resultate ergänzt werden:

    @StackExchange.Profiling.MiniProfiler.RenderIncludes() 
  </body>
</html>

Will man MiniProfiler in einem Webforms-Projekt einsetzten ist der Header in der Datei Site.Master so zu ergänzen:

<%= StackExchange.Profiling.MiniProfiler.RenderIncludes() %>
</head>

Bei mir war zudem noch eine Anpassung im web.config nötig:

<system.webServer>
  ...
  <handlers>
    <add name="MiniProfiler" path="mini-profiler-resources/*" verb="*" type="System.Web.Routing.UrlRoutingModule" resourceType="Unspecified" preCondition="integratedMode" />
  </handlers>
</system.webServer>

 

Auswerten

Sobald man die Webanwendung neu kompiliert und gestartet hat erscheint eine kleine Box in der linken oberen Ecke der Seite:

MiniProfiler beschränkt sich nicht nur aufs anzeigen der Ladezeit. Klickt man auf die Box wird ein detaillierter Report angezeigt:

Neben den allgemeinen Informationen über die Dauer des Request und die Dom Events kann man auch eigene Schritte definieren. Dazu setzt man den zu überwachenden Code in einen Using-Block und benennt den Step mit einem prägnanten Titel:

using (MiniProfiler.Current.Step("Step Set Message"))
{
  ViewBag.Message = "Your contact page.";
  Thread.Sleep(100);
}

Normalerweise werden die Ereignisse die keine relevante Zeit verbrauchen ausgeblendet. Fehlt einem der gesuchte Schritt kann man über den Link „show trivial“ das anzeigen aller Einträge erzwingen.

 

EF-Abfragen überprüfen

Richtig praktisch wird MiniProfiler wenn man auch gleich noch die Datenbankabfragen anzeigen kann. Dazu muss man zusätzlich das Paket MiniProfiler.EF installieren und Application_Start() in der Global.asax um einen Aufruf zur Initialisierung ergänzen:

MiniProfilerEF.Initialize();

Von nun an wird neben der Dauer der Aktionen die Anzahl darin ausgeführten SQL-Abfragen angezeigt:

Von dieser Zusammenfassung aus genügt 1 Klick und man sieht was genau für SQL-Befehle auf die DB losgelassen wurden:

Der Hinweis auf doppelte Abfragen oder Select N+1 ist äusserst hilfreich und hilft einem die gröbsten Schnitzer einfach zu finden.

 

Fazit

MiniProfiler ist schnell installiert und sehr einfach zu konfigurieren. Die Ladezeit als eine der wichtigsten Kennzahlen steht einem von nun an jederzeit und gut sichtbar zur Verfügung. Zusätzliche Informationen lassen sich mit geringem Aufwand hinzufügen und ermöglichen einen Einblick ins Innere der Anwendung.

Meiner Meinung nach ist dieses kleine Tool ein tolles Hilfsmittel um schon zur Entwicklungszeit die Ursachen der häufigsten Produktionsprobleme anzugehen.

Schlagworte:

Buch-Rezension zu “The Rails View”

14. Oktober 2012 Kommentare aus

The Rails View: Create a Beautiful and Maintainable User Experience” von Bruce Williams und John Athayde erschien im April 2012 bei The Pragmatic Programmers. Zu Ruby on Rails gibt es unzählige Bücher, doch bisher fehlte es an einem Buch das sich dem View-Layer annimmt. Diese Lücke wollen Williams und Athayde mit ihrem Buch schliessen.

Um dem Buch folgen zu können sollte man sich mit CSS und JavaScript auskennen. Es wird kein grosses Wissen vorausgesetzt, aber ganz ohne geht es nicht.

 

Aufbau

Im Buch wird eine Rails-Anwendung Schritt für Schritt ausgebaut. Die Autoren folgen dabei der Häufigkeit der Arbeiten und gliedern ihr Buch in diese Kapitel:

  • Das Layout der Anwendung erstellen
  • Die Lesbarkeit erhöhen
  • CSS hinzufügen
  • JavaScript hinzufügen
  • Wartbare Formulare erstellen
  • Presenters nutzen
  • Mobile Views erstellen
  • E-Mails erzeugen
  • Performance optimieren

 

Viele praktische Hilfen

Gerade bei den „einfachen“ Themen wird oft ein simpler Weg gezeigt und anschliessend ein Ansatz, der zwar komplexer ist aber einem einen deutlich besser zu pflegenden Code liefert. Ich fand das Gegenüberstellen der Ansätze sehr hilfreich um zu erkennen worauf man achten sollte.

Es gibt viele Tricks mit denen man mit CSS und JavaScript seine Rails-Anwendung aufpeppen kann. Mit diesem Buch bekommt man einen Einblick in die Möglichkeiten und ist in der Lage eine deutlich angenehmere Benutzerführung zu erstellen als was einem Rails mit seinen Generatoren von Haus aus liefert.

Der Einsatz von Helpern und Presentern fand ich einen eleganten Ansatz um Code aus der View zu extrahieren. Weniger Code in der View ermöglicht einem sich auf das zu konzentrieren was dort wichtig ist – die Ausgabe der Informationen.

 

Verbesserungsmöglichkeiten

Bei den Beispielen scheint es einem ab und zu noch an Informationen zu fehlen die in einem späteren Kapitel erklärt werden. Wer das im Buch vorgestellte gleich Schritt für Schritt in seine Anwendung übernehmen will wird so bald einmal vor Probleme gestellt. Da das Buch doch recht viele Themen behandelt wäre es praktisch wenn jedes Kapitel für sich alleine funktionieren würde.

Will man nach dem Lesen im bereitgestellten Code etwas nachschauen muss man sehr viel suchen. Der Aufbau der Ordnerstruktur hätte man gerne ein wenig nachvollziehbarer gestalten können.

 

Fazit

“The Rails View” liefert einem eine gute Übersicht über die für den View-Layer relevanten Technologien. Das Buch zeigt auf wie man mit JavaScript und CSS eine angenehme Benutzerführung realisieren kann und dabei nicht auf die Lesbarkeit seines Codes verzichten muss.

Wenn das Buch auch keine grundlegende Einführung in die vorgestellten Technologien liefert, so gelingt es den Autoren zu zeigen wie man diese mit Rails kombinieren und nutzen kann.

 

Zum Buch

The Rails View: Create a Beautiful and Maintainable User Experience” von Bruce Williams und John Athayde, 2012 The Pragmatic Programmers, ISBN 978-1-9343-5687-6, 264 Seiten, Englisch

Schlagworte: ,

Von Subversion zu Git migrieren

2. Oktober 2012 Kommentare aus

Der Wechsel von Subversion zu Git für die Versionsverwaltung ist an sich ein einfacher Vorgang. Da das Web aber voller veralteter Anleitungen ist steht man bald einmal in einer Sackgasse. Nachdem es mir auch so ergangen ist habe ich hier meine Lösungsansätze für Git 1.7.9.5 zusammengetragen.

 

History: Übernehmen oder verwerfen?

Die wohl wichtigste Frage bei der Migration dreht sich um die Änderungsgeschichte. Soll jeder einzelne je gemachter Commit übernommen werden? Oder will man nur einen bestimmten Stand migrieren? Bei beiden Ansätzen lassen sich Argumente dafür und dagegen finden. Wichtig ist das man diese Entscheidung überlegt trifft, da ein nachträgliche Änderung mit viel Arbeit verbunden ist.

 

Variante ohne History

Kann man auf die History verzichten ist die Migration sehr einfach. Es genügt den aktuellen Stand im SVN-Repository zu exportieren und damit ein Git-Repository zu initialisieren. Dies kann man sowohl mit grafischen Tools wie TortoiseSVN und GitHub for Windows machen wie auch direkt über die Kommandozeile.

svn export svn+ssh://user@localhost/svn/jgraber
cd jgraber
git init
git add .
git commit -m "init migrated repo"

 

Variante mit History

Wenn die History erhalten bleiben soll hilft git svn. Dies wird bei GitHub for Windows mitgeliefert und ist unter Linux über apt-get installierbar. Als Vorarbeit benötigen wir einen Checkout aus Subversion:

svn co svn+ssh://user@localhost/svn/jgraber
cd jgraber
svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > authors-transform.txt
cat authors-transform.txt
jgr = Johnny Graber <dev@JGraber.ch>

Zeile 3 erstellt eine Liste mit allen Personen die jemals in dieses Subversion Repository eingecheckt haben. Diese Liste benötigt man um die Usernamen von Subversion in die von Git her bekannten Autoren (im Format Vorname Nachname ) umzuwandeln. Sobald die Datei authors-transform.txt korrekt ausgefüllt ist geht es weiter mit der Migration:

git svn clone svn+ssh://user@localhost/svn/jgraber --no-metadata -A authors-transform.txt --stdlayout ../git_jgraber
cd ../git_jgraber

Dieser Befehl funktioniert nur wenn das Repository dem Standard mit den Verzeichnissen /trunk, /branches und /tags folgt. Hat man einen anderen Aufbau gewählt beendet sich git svn ohne Fehlermeldung. Die Lösung für dieses Problem ist das Weglassen der Option “--stdlayout“.

Branches übernehmen
Durch die bisherigen Aktionen wurde nur der Trunk von SVN in den Master bei Git überführt. Falls man unter SVN Branches verwendete müssen diese nun explizit übernommen werden. Dazu holt man sich erst eine Übersicht über alle Branches und übernimmt diese dann einzeln:

$ git branch -av
  1.0              2ef18cb Release 1.0 bugfixes
* master           e64eda5 litte changes on trunk
  remotes/1.0      2ef18cb Release 1.0 bugfixes
  remotes/tags/1.0 8604640 Release 1.0
  remotes/tags/1.1 9059098 bugfixed version 1.1
  remotes/trunk    e64eda5 litte changes on trunk
git checkout -b <local_branch> remotes/<remote_branch>
git branch -d -r <remote_branch>

Der letzte Befehl entfernt den Verweis auf den ursprünglichen Branch in SVN. Will man nicht mehr zurücksynchronisieren hat der Remote-Branch seinen Zweck erfüllt und kann entfernt werden.

Tags übernehmen
Wie die Branches müssen auch die Tags übernommen werden. Da SVN einem nicht zwingt Tags nur für einzelne Markierungen zu nutzen sollte man erst prüfen ob nicht ein Tag als Branch verwendet wurde. Ist dies der Fall migriert man diesen Tag wie einen Branch.

Sobald man nur noch „richtige“ Tags hat kann man diese Befehle für eine Übernahme nutzen:

$ git branch -av
  1.0              2ef18cb Release 1.0 bugfixes
* master           e64eda5 litte changes on trunk
  remotes/tags/1.0 8604640 Release 1.0
  remotes/tags/1.1 9059098 bugfixed version 1.1
git tag <local_tag> remotes/tags/<remote_tag>
git branch -d -r <remote_tag>

$ git tag
t1.0
t1.1

 

Ab zu GitHub

Als letzten optionalen Schritt kann man das migrierte Repository zu GitHub oder Bitbucket hochladen. Dazu legt man über die Weboberfläche des jeweiligen Anbieters ein neues Repository an. Die URL zu diesem Repository kann man nun dem lokalen hinzufügen und die Daten hochladen:

git remote add origin ssh://git@bitbucket.org/jgraber/
git push -u origin master
git push --tags
git push origin <branch>

 

Fazit

Ein Repository von Subversion nach Git zu migrieren ist gar nicht so schwer. Alles was man dazu braucht ist eine aktuelle Anleitung und eine Arbeitskopie die man auch einmal löschen kann. Sollte jemand einen einfacheren Weg für die Migration kennen würde ich mich über einen Kommentar freuen.

Schlagworte:
Follow

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 254 Followern an