Archiv für Kategorie Tools
Einstieg in GIT? Warum?
In der Webentwicklung ist der Umstieg auf GIT ein echter Trend. Vor einem Monat gab Fabien Potencier den Wechsel von svn zu GIT in der Entwicklung der neuen Symfony Version bekannt, CakePHP hat den Wechsel genauso wie phpBB schon vor einer ganzen Weile gemacht. Als Weitere wären da auch noch PHPUnit oder RubyOnRails. Dieser Trend hat natürlich auch mich interessiert, weshalb ich mein neues Projekt gleich mit GIT aufgesetzt habe. Am Anfang braucht man natürlich etwas Starthilfe, weil GIT vom Ansatz her anders als Subversion ist, aber diese Hilfe findet man in den zahlreichen Tutorials schnell.
Warum nutze ich GIT:
- Die Geschwindigkeit:
Da das gesamte Repository lokal gespeichert ist, sind die üblichen Arbeitsschritte wesentlich schneller als bei vielen anderen Versionsverwaltungen. - Offline Arbeiten
Durch das lokale Repository kann man wunderbar Offline arbeiten. Wenn man dann später wieder online ist, kann man alle Änderungen einfach in ein anderes Repository schieben. - Einfaches Taggen und Branching
Natürlich gibt es auch bei GIT Konflikte, aber das Erstellen von Branchs und Tags ist SEHR einfach. - Jedes Repository ist ein Backup
Mit GIT macht man keinen Checkout eines neuen Repositories sondern ein Clone, so hat man mit jedem neuen Repository ein komplettes Backup/eine komplette Kopie des Repositories. Bei einem Ausfall des “Hauptrepositories” kann man so sehr schnell auf ein anderes Repository umstellen. - Commits einfach Vorbereiten
Git hat eine sogenannte Staging Area der man alle Änderungen für den nächsten Commit hinzufügen kann, wenn man nicht alle Dateien oder einzelne Datei Commiten möchte.
Weitere Gründe findet man hier.
Erste Schritte mit GIT:
Nun zu meinem kleinen Tutorial
Installation:
Unter Linux reicht es das Paket “git-core” zu installieren. Für Mac OS gibt es hier einen Installer und für Windows hier.
Einstellungen:
Als erstes muss man seinen Namen und die Emailadresse einstellen:
git config --global user.name "<Benutzername>" git config --global user.email "<Email>"
Erstes Repository:
Nachdem wir uns mit GIT bekannt gemacht haben, können wir unser erstes Repository erstellen. Ich nehme einfach ein vorhandenes Projekt und führe git init aus:
david@ubuntu-server:~$ cd /home/david/project/ david@ubuntu-server:~/project$ git init Initialized empty Git repository in /home/david/project/.git/
Jetzt fügt man einfach alle Dateien hinzu und macht den ersten commit.
david@ubuntu-server:~/project$ git add . david@ubuntu-server:~/project$ git commit -m "initial commit" [master (root-commit) 25c342d] initial commit 5234 files changed, 502420 insertions(+), 0 deletions(-) create mode 100644 Readme create mode 100644 apps/admin/config/adminConfiguration.class.php create mode 100644 apps/admin/config/app.yml ...
Jetzt ändern wir etwas und zeigen an, was die Unterschiede sind:
david@ubuntu-server:~/project$ vim Readme david@ubuntu-server:~/project$ git status # On branch master # Changed but not updated: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: Readme # no changes added to commit (use "git add" and/or "git commit -a") david@ubuntu-server:~/project$ git diff Readme diff --git a/Readme b/Readme index a40145f..5c72d5b 100644 --- a/Readme +++ b/Readme @@ -1 +1,2 @@ + A Readme TestFile david@ubuntu-server:~/project$ git commit -m "Readme File" Readme [master 15563d6] Readme File 1 files changed, 1 insertions(+), 0 deletions(-)
Mit git status sieht man also die geänderten Dateien, mit git diff die Unterschiede und mit git commit commitet man die Änderungen. Da GIT keine Dateien sondern Inhalte verwaltet muss man jede Änderung vor einem Commit hinzufügen, sowohl bei neuen Dateien als auch von bereits verwalteten Dateien.
Wie geht es nun weiter? Git kann natürlich noch viel mehr als nur commits und Unterschiede anzeigen. Viele weitergehende Informationen findet ihr im opensource Buch “Pro GIT” oder in folgenden Tutorials auf meinem Blog.
Xdebug – PHP Profiler
Heute möchte ich euch wieder ein Tool vorstellen, mit dem man die Performance seiner PHP Anwendung testen kann bzw. die Performance-Engpässe in der Anwendung aufspüren kann. Xdebug wird von vielen als Debugger in der Entwicklungsphase genutzt, bietet aber auch einen Profiler. Viele kennen Profiler nur aus Kriminalserien im Fernsehen, aber ein Entwickler sollte damit auch ein Tool zur Performance-Analyse von Anwendungen in Verbindung bringen. Profiler aus dem Fernsehen erzeugen Täterprofile anhand von operativen Analysen, ähnliches macht ein Software-Profiler auch, er erzeugt Softwareprofile anhand operativer Analysen.
Die Funktionsweise eines Profilers lässt sich am besten anhand eines Beispiels/Tutorials erklären. Also fangen wir an:
Unter Ubuntu lässt sich Xdebug sehr einfach installieren:
sudo apt-get install php5-xdebug
Danach ist Xdebug installiert und automatisch aktiviert, nun müssen wir nur noch den Profiler in der php.ini aktivieren. Wenn man den Profiler in der globalen php.ini aktiviert, wird jedes ausgeführt PHP Skript aufgezeichnet, deshalb kann es sinnvoll sein, die Einstellung in einer htaccess oder lokalen php.ini zu setzen, oder die Einstellung xdebug.profiler_enable_trigger zu nutzen. Da ich auf einem Testserver Arbeite, aktiviere ich den Profiler in der globalen php.ini (folgendes in der php.ini hinzufügen):
xdebug.profiler_enable=1 xdebug.profiler_output_dir="/tmp/xdebug" xdebug.profiler_output_name="trace%s"
Mit den Einstellungen haben wir den Profiler aktiviert, danach müssen wir natürlich den Apache neustarten (evtl. reicht auch ein reload):
sudo /etc/init.d/apache2 restart
Jetzt müssen wir nur noch eine Seite (natürlich von dem konfigurierten Server) im Browser öffnen und das Profiling beginnt. Nach dem Aufruf finden wir in dem oben angegebenen Verzeichnis ein Datei mit dem Namen der eben Aufgerufenen Seite (trace_name_der_datei).
Den Inhalt der Datei muss man natürlich nicht Zeile für Zeile lesen und einen Graphen auf Papier malen, sondern auch hierfür gibt es ein Tool. Das bekannteste ich wohl KCacheGrind (Linux KDE), oder MacCallGrind (wer hätte es gedacht: Mac OS). Betriebssystem unabhängig gibt es noch WebGrind, ob man damit aber auch große CallGrinds analysieren kann weiss ich nicht. Falls ich noch ein Betriebssystem vergessen habe, solltet ihr einfach mal Google fragen (Stichwort: WinCacheGrind)! Meiner aktuellen Betriebssystemsituation geschuldet, stelle ich euch hier erstmal nur MacCallGrind vor. KCacheGrind zeige ich euch dann in einem späteren Beitrag, WinCacheGrind müsst ihr euch selbst angucken.
Ich habe folgendes Skript auswerten lassen:
<?php
test();
test();
test();
test();
test();
test();
test();
test();
test();
function test(){
$i = 1;
while($i < 10000) {
$i++;
echo "test";
usleep(100);
}
}
?>
Das ganze sieht im MacCallGrind dann so aus (Einfach die erzeugten Dateien öffnen):
Nun kann man genau gucken wo die Ausführungszeit der Anwendung verschwindet, welche Funktion wie oft aufgerufen wird und wie lange die Ausführungen der einzelnen Funktionen dauern. Mit KCacheGrind kann man dann noch ein paar weitere Auswertungen anfertigen, aber dazu in einem späteren Beitrag mehr. Sonst ist MacCallGrind größtenteils selbsterklärend.
Meiner Meinung nach kann man so gute Analysen der eigenen Software machen, um Performance Engpässe schon bei der Entwicklung aufzuspüren und zu einer ordentlichen Softwareanalyse gehört es einfach dazu.
Letzte Kommentare