Versionsverwaltung mit git

Wie so oft in diesem Blog sprechen wir natürlich über ein technisches Thema – und zwar geht es um Versionsverwaltung. Vornehmlich im Bereich Softwareentwicklung angesiedelt kann man damit seinen Quellcode verwalten. Warum braucht man dazu ein eigenes Programm? Man hat die Dateien ja da und kann ab und zu ein Backup machen, oder?

Ganz so einfach ist es doch nicht, denn man kommt mit dieser Vorgehensweise sehr schnell an seine Grenzen. Ein paar Beispiele: mit einer einfachen Dateiverwaltung wird es teilweise unmöglich, im Team zu arbeiten, weil es zwangsläufig dazu kommt, dass mehr als eine Person an der gleichen Datei arbeiten muss. Software ist NIE fertig, es wird immer wieder Änderungen oder Bugfixes geben. Was macht man, wenn man zu einer älteren Version zurück will oder nur mal die Unterschiede zwischen zwei Versionen vergleichen will? Verbreite ich meinen Quellcode sinnvoll, damit mein Opensource-Projekt aktive Mitstreiter bekommt und diese ihr Änderungen auch wieder zu mir zurückfließen lassen können? Diese Liste kann man beliebig erweitern, und es wird immer wieder herauskommen, dass eine Versionsverwaltung doch immer der elegantere Weg sein wird.

Das haben Entwickler ziemlich zeitig bemerkt und entsprechende Programme entworfen, die einen bei diesem Problem unterstützen. Heraus kamen Systeme wie cvs oder Subversion. Die sind schon ganz gut, haben aber immer ein großes Problem: sie brauchen einen Server. Und das veringert die Geschwindigkeit sehr deutlich. Hinzu kommt, dass Arbeit von Unterwegs erheblich erschwert wird, weil man nur bei einer Verbindung zum Server Zugriff auf die Historie einer Datei hat.

Was mich persönlich am meisten gestört hat, war der Umstand, dass die bestehenden Systeme nur sehr schlecht mergen – also zusammenführen mehrerer Änderungen in der gleichen Datei – können. Auch sehr unschön war das Branching – also das Anlegen eigener Entwicklungszweige.

Git ist hier äußerst robust und bekommt nur Probleme, wenn man wirklich die gleiche Zeile verändert. Entwickelt wurde das System von keinem anderen als Linux Torvalds, dem Erfinder von Linux. Ihm war die Verwaltung des Linux Quellcodes schon lange ein Dorn im Auge und am Markt gab es kein Tool, was seinen Ansprüchen genügte. Also entwickelte er ein entsprechendes System selbst – heraus kam git.

Die großen Vorteile: Die Repositories liegen lokal auf jedem Rechner, merge-Prozesse sind sehr schnell und auch sehr genau und das Anlegen von Branches sowie der Wechseln zwischen ihnen stellt kein Problem mehr dar. Es zeigt sich einfach, dass man viel autarker arbeiten kann, da man alle benötigten Daten auf seinem PC hat und erst dann mit dem Server kommunizieren muss, wenn man Commits übertragen oder Updates ziehen möchte. Sehr schön gelöst ist auch die Aufbewahrung der Meta-Daten. Liegt bei Subversion oder cvs in jedem Ordner ein Unterordner mit den Daten, so ist es bei git pro Repository nur ein einziger Ordner, und der liegt im Hauptverzeichnis des Projekts. Möchte man also Dateien versenden, so kann man diese direkt nehmen und muss nicht erst anfangen, jeden Ordner einzeln zu reinigen. Wer schon einmal ein Subversion Projekt von Meta-Daten befreit hat, weiß, wovon ich spreche 😉

Um meine Einleitung zu diesem Artikel noch zu relativieren: Man kann mit git und auch anderen Versionskontrollsystemen jede Art von Datei verwalten. Es gibt z.B. viele Grafiker, die ihre Projekte mit git verwalten, weil sie dann einfach in der Historie vor und zurück springen können. Selbst Backup-Lösungen kann man damit aufbauen. Am effizientesten funktionieren die Systeme aber noch immer mit reinen Textdateien.

Zum Thema Versionskontrollsysteme sei euch übrigens auch folgender Podcast sehr ans Herz gelegt:
CRE 130 – Verteilte Versionskontrollsysteme

Links
git

[Quicktip] cgi Scripte mit Plesk

Am letzten Wochenende habe ich das erste mal in meinem Leben ein cgi Script verwendet. In Zeiten von php – welches im Prinzip auch cgi ist – braucht man derartige Tools einfach nicht mehr so wirklich. Der Vorteil ist aber ganz klar: cgi Programme sind schnell – sofern wir von c oder c++ sprechen. Es wird wohl kein php, ruby, python oder perl Script geben, welches mit einem sauber in C aufgesetzten cgi mithalten kann. Dafür hat man aber den Aufwand, dass man erst kompilieren muss, um das Programm verwenden zu können. Natürlich kann man aber auch alle weiteren Script- oder kompilierten Sprachen als cgi verwenden. Bei interpretierten Sprachen ist dies aber deutlich langsamer, als wenn man diese per Apache Modul betreibt, da sonst bei jedem Aufruf erst einmal der Interpreter initialisiert werden muss.

Egal, ich war dabei, cgit (ein grafisches Frontend für lokale git-Repositories) aufzusetzen – da kommt auch nochmal ein Blogeintrag zu. Nachdem ich mit der Compilierung und Installation durch war, legte ich in Plesk die Domain an, aktivierte in den Domaineinstellungen, dass cgi-Scripte unterstützt werden sollen – und dann stand ich da…

Einfach in den httpdocs Ordner der Domain werfen brachte nichts, dann war die Datei als Download verfügbar. Mir fiel dann schnell der cgi-bin Ordner auf, der sich in der Ordnerstruktur neben den httpdocs und httpsdocs Ordnern befindet. Nur wie ruft man diese auf? Nach etwas Probierarbeit kam ich dann drauf:

http://www.domain.de/cgi-bin/script.cgi

Eigentlich ganz einfach, aber naja 😉

Nachdem ich das herausgefunden hatte, lief mein Tool natürlich trotzdem nicht. Über die Console lief es wunderbar, nur eben nicht im Browser. Dann wurde mir klar, dass das nur noch mit Benutzerrechten zu tun haben kann – und so war es auch. Es ist wichtig (zumindest wenn man mit Plesk arbeitet), dass das cgi Script der Gruppe “psacln” gehört. Außerdem habe ich auch den Benutzer der Domain als Inhaber der Datei festgelegt, was aber wohl nicht zwingend notwendig ist.

[Quicktip] mit MYSQL nach % (Prozent) suchen

Gestern stand ich vor der Aufgabe, Datensätze in der Datenbank zu finden, die ein Prozentzeichen an einer bestimmten Stelle in einem Wort hatten. Sagen wir, ich wollte nach “Wo%rt” suchen. Nun könnte man einfach ein

SELECT * FROM `test` WHERE wert LIKE 'Wo%rt'

ausführen, wird aber sehr schnell feststellen, dass das gewünschte Ergebnis bzw. der gewünschte Datensatz zwar dabei ist, aber auch alle weiteren Einträge, die mit “Wo” anfangen und mit “rt” enden – wie z.B. “Wohnort”. Das Prozentzeichen (“%”) und der Unterstrich (“_”) dienen in MySQL als Platzhalter – % für beliebig viele Zeichen beliebigen Typs und _ für ein beliebiges Zeichen.

Pfiffig wie ich war nahm ich den Standard-Escape-Character unter Unix – das Backslash (“\”), um das % zu entschärfen:

SELECT * FROM `test` WHERE wert LIKE 'Wo\%rt'

Natürlich funktionierte das so auch nicht, denn das Backslash ist eben nicht für das Escaping unter MySQL gedacht. Nach ein wenig Recherche im Netz fand ich dann heraus, dass man selbst definieren muss, was das Escape-Zeichen sein soll. Und das geht so:

SELECT * FROM `test` WHERE word LIKE 'Wo!%rt' ESCAPE '!'

In diesem Fall habe ich also das Ausrufezeichen als Escape Character definiert, man kann aber jedes andere Zeichen einsetzen – außer natürlich % und _. Man kann für jedes einzelne Like ein eigenes Escape Zeichen definieren.

statische Code-Analyse mit dem php code sniffer

Foto von Dennis Wegner

Programmierer machen, wie jeder andere Mensch, auch Fehler. Nun gibt es zum einen Fehler in der Syntax, auf der anderen Seite gibt es die Logik-Fehler. Beide verursachen, dass ein Programm entweder gar nicht oder nicht wie erwartet funktioniert. Normalerweise kann (und muss) man diese Fehler entdecken – manchmal geht das leicht, manchmal aber auch nicht. Syntax-Fehler stellen hier den einfachsten Kandidaten dar, da diese meist schon von der verwendeten IDE erkannt werden, spätestens aber bei der Ausführung des Programms ein Fehler auftritt. Logische Fehler sind da schon etwas kniffliger, da sie rein aus Programmiersicht fehlerfrei sind. Nur die Art und Weise, wie sie ein Problem behandeln entspricht nicht dem, was der Programmierer ursprünglich vor hatte.

Zu diesen beiden Kandidaten gesellt sich aber noch eine weitere Gattung, nämlich die Art und Weise, wie Code geschrieben wird. Jeder Programmierer hat – genauso wie jeder Mensch die eigene Handschrift – einen eigenen Programmierstil. Das ist zuersteinmal nichts verwerfliches und wird weder Probleme in der Syntax noch in der Logik hervorrufen. So gesehen gibt es aus betriebswirtschaftlicher Sicht keinerlei Notwendigkeit, sich darum zu kümmern. Problematisch wird es aber dann, wenn mehrere Entwickler mit einem Projekt beschäftigt sind. Spätestens hier treffen Welten auseinander und es kann durchaus vorkommen, dass völlig korrekter Code einfach nicht mehr bzw. nur sehr schwer lesbar ist. Bei geringem Umfang stellt das nicht das große Problem dar, wenn man allerdings mit komplexen Projekten zu tun hat kann dies zu einem großen Hindernis werden. Das fiese daran ist, dass man das Problem anfangs einfach nicht erkennt. Wenn es dann auftritt, ist es meist zu spät.

Um dem Herr zu werden, setzen viele Unternehmen und Entwickler auf Coding-Standards. Dabei handelt es sich um Regeln, wie Code formatiert werden muss und welche Lösungswege nicht verwendet werden sollten. Oder eben, welche Prioritäten bestimmte Lösungswege haben. Dabei geht es z.B. um die Art und Weise, wie Klammern gesetzt werden, die Variablen formatiert werden, wie Klassen und Kontrollstrukturen (Schleifen usw.) auszusehen haben usw. Gerade große Open Source Projekte mit mehreren hundert oder gar tausend Entwicklern müssen einfach derartige Regeln definieren, da sonst reinstes Chaos entsteht. Das würde dann dazu führen, dass Code zwar sehr gut, aber aufgrund von schlechter Lesbarkeit nicht mehr wartbar wäre. Und somit leider unbrauchbar sein würde.

Ok, nun haben wir die Theorie geschafft. Nun kann man die Regeln definieren und jeder hält sich dran, aber wie es so bei den Menschen ist, unterlaufen einem Fehler, man wird faul oder man hat einfach keine Lust auf die Regeln. Die gegenseitige Kontrolle von Code mag bei kleineren Mengen noch durch Menschen machbar sein, wenn ein Projekt aber aus mehreren zehntausenden Zeilen Code besteht, ist das auch nicht mehr machbar. Und an dieser Stelle setzt man auf statische Code-Analyse. Mit den entsprechenden Tools kann man Code analysieren und anschließend anhand definierter Regeln auswerten lassen.

Eines dieser Tools, und das sagt ja schon die Überschrift, befasst sich mit der statischen Analyse von php Code und nennt sich “php code sniffer”. Das Tool ist kostenlos und kann über PEAR geladen werden:

pear install PHP_CodeSniffer-1.3.0RC2

Die Version 1.3 RC2 ist die derzeit aktuelle Version, um auf dem neusten Stand zu sein schaut doch einfach mal hier nach, welche die aktuelle Version ist.

Über die Console ist das Tool nach erfolgreicher Installation mittels “phpcs” verfügbar. Der Aufruf ist dann ganz leicht:

phpcs --standard=zend class.php

In diesem Beispiel wurde die Datei class.php auf die Coding-Standards von Zend hin überprüft. Das Ergebnis sieht dann ungefähr so aus:

FILE: /.../class.php
--------------------------------------------------------------------------------
FOUND 3 ERROR(S) AND 0 WARNING(S) AFFECTING 3 LINE(S)
--------------------------------------------------------------------------------
1 | ERROR | End of line character is invalid; expected "\n" but found "\r\n"
9 | ERROR | Expected 0 spaces before opening brace; 2 found
11 | ERROR | Spaces must be used to indent lines; tabs are not allowed

Als kurze Erklärung: In Zeile 1 wurde ein falscher Zeilenumbruch verwendet (kann passieren, wenn man mit Windows und Linux/Unix im Wechsel am gleichen Code arbeitet), in Zeile 9 waren zwei Leerzeichen vor der öffnenden geschweiften Klammer und in Zeile 11 wurde mit Tabs an Stelle von Leerzeichen eingerückt. Die Datei an sich funktioniert tadellos, allerdings verstoßen diese Punkte eben gegen die Konventionen von Zend.

Wie ihr seht, ist es mit dem php code sniffer sehr schnell und vor allem sehr einfach möglich, euren Code auf Regeln hin zu untersuchen und Fehler dieser Art zu finden. Neben den Regeln von Zend gibt es noch einige weitere vorgefertigte Rules, die ware Stärke zeigt das Tool aber mit der Möglichkeit, eigene Regeln zu definieren. Da ich den Umfang dieses Beitrags nicht sprengen will, schaut euch doch einfach mal folgenden Beitrag auf “php hates me” an, der genauer auf dieses Thema eingeht: PHP Code Sniffer – Eigene Regeln erstellen.

Links:
php code sniffer
phphatesme.com

Kinect – rockt?

Es ist der Wahnsinn, was sich Leute ausdenken, wenn man ihnen die Freiheit lässt, Technik so zu verwenden wie sie möchten. Microsoft war anfangs überhaupt nicht begeistert vom Open Source Treiber für Kinect – welches sich einfach per USB an den PC/Mac stecken lässt. Mittlerweile finden sie es auch cool, weil es die Popularität um einiges steigert. Viel krasser finde ich allerdings, wie genau das System ist – Wii oder Playstation Move sind einfach lachhaft dagegen. Ich persönlich würde mir mittlerweile lächerlich vorkommen, für eine Gestensteuerung irgendeinen komischen Controller (der teilweise stark an Erotikspielzeug erinnert) in der Hand halten zu müssen.

Hier ein Video, auf dem man erkennen kann, wie Kinect die Umgebung erkennt:

Hier nun mal eine kleine Auflistung mit “Hacks” von Kinect:

[Quicktip] MySQL Query-Ergebnis per Console in eine CSV Datei exportieren

Mit phpmyadmin und Konsorten ist es kein Problem, Ergebnisse von SQL Abfragen in CSV-Dateien zu exportieren. Problematisch wird es allerdings, wenn man eine aufwändigere Abfrage hat, die den php Timeout provoziert, oder aber man keinen Web-Client zu Verfügung hat. Dann greift man zur Konsolenversion von MySQL – welche diesen Export nicht direkt anbietet. Mittels ein bisschen Bash-Magie kann man sich aber behelfen:

mysql --database=database --execute="select a from b where a>1;" | sed 's/\t/","/g;s/^/"/;s/$/"/;s/\n//g' > filename.csv

Was passiert? Die Abfrage wird ausgeführt und die Ergebnisse werden in Textform ausgegeben. Mittels Pipe wird die Ausgabe an “sed” weitergegeben, welches diese in das CSV Format umwandelt und anschließend in die Datei “filename.csv” schreibt.

Via snipplr.com

[Quicktip] ssh Verbindung ohne Known-Hosts Eintrag

Es gibt gute Gründe, warum ssh die Fingerprints (also die virtuellen Fingerabdrücke) der Server speichert, mit denen man sich verbindet. Tut man dies nämlich erneut, so kann ssh prüfen, ob sich hinter dieser IP bzw. hinter diesem Hostnamen noch immer der gleiche Rechner befindet. Wenn nicht, gibt’s eine Warnung.

Nun gibt es aber auch Fälle, bei denen will man diesen Schutz unterbinden – vornehmlich beim Scripting. Und das macht man so:

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no root@server

Was passiert? Mit dem ersten Parameter wird das known-hosts-File “/dev/null”, also “nichts”, verwendet. Parameter 2 gibt an, dass die Überprüfung der Fingerprints deaktiviert werden soll. Lässt man den ersten Parameter weg, so werden trotzdem die Fingerprints in der normale known-hosts-File geschrieben.

[Quicktip] GIT Commit/Merge auf github rückgängig machen

Folgendes Problem: Ihr habt ein paar Änderungen commited und auch schon gepushed – in meinem Fall zu github -, merkt dann aber, dass ihr was falsches commited habt. Was nun?

Zuerst könnt ihr mit eurem GIT Client auf die Version resetten, die noch ok war. Oder ihr macht das per Git-Bash:

git reset --hard [Hashwert des gültigen Commits]

Damit setzt ihr euren Stand direkt auf diesen Commit zurück. Achtung! Wenn ihr den Parameter –hard verwendet werden sämtliche Änderungen überschrieben – und alle nachfolgenden Commits werden gelöscht!

Anschließend führt ihr ein

git push -f

aus und schon wird der Reset auch an Github oder evtl. andere entfernte Repositories übertragen. Achtung auch hier: die nachfolgende History wird gelöscht, auch von github. Wenn ihr den Parameter -f (für “force”) weglasst, so wird euch der Push verweigert, da ihr ja einen älteren Stand als im Repository pushen wollt. Daher ist er zwingend nötig.

[php] URLs effektiver zusammensetzen

Als PHP Entwickler muss man sich ja auch ab und zu mal um den Zusammenbau von URLs kümmern – entweder wird einem diese Arbeit von einem Framework abgenommen, oder man muss manuell ran. Mir geht es hier um den manuellen Weg. Man kann da folgendermaßen rangehen:

$url = "http://host/?id=10";
if($_GET["name"] != "")
{
	$url .= '&name='$_GET["name"];
}
if($_GET["country"] != "")
{
	$url .= '&country='$_GET["country"];
}
usw.


Wie man sieht, muss man für jeden eventuellen Parameter eigene if-Abfragen bauen, deren Muster ist aber immer das gleiche. Was spricht also dagegen, es folgendermaßen zu lösen?

$url = "http://host/?id=10";
$parameters = array(
	array("name"=>"name", "value"=>$_GET["name"]),
	array("name"=>"country", "value"=>$_GET["country"])
);
foreach($parameters as $parameter)
{
	if($parameter["value"] != "")
	{
		$url .= '&'.$parameter["name"].'='.$parameter["value"];
	}
}

Ok, im ersten Moment ist der neue Code bei gleichem Ergebnis etwas umfangreicher, jedoch ergibt sich ein erheblicher Vorteil, wenn neue Parameter dazu kommen. Denn nun muss man einfach dem $parameters-Array ein neues Element hinzufügen und schon wird dieses mit in die URL eingebaut.