https://github.com/esc/git-cheatsheet-de/

http://github.com/AlexZeitler/gitcheatsheet

http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html

http://cheat.errtheblog.com/s/git/

http://www.xcombinator.com/2010/09/01/git-cheat-sheet-and-class-notes/

http://refcardz.dzone.com/refcardz/getting-started-git

http://www.cheatography.com/samcollett/cheat-sheets/git/

sudo easy_install cctrl
Die Fehlermeldung sieht dann so aus:
Processing pycrypto-2.3.tar.gz
Running pycrypto-2.3/setup.py -q bdist_egg --dist-dir /tmp/easy_install-a3AMTg/pycrypto-2.3/egg-dist-tmp-wqqPb7
warning: GMP library not found; Not building Crypto.PublicKey._fastmath.
/usr/libexec/gcc/powerpc-apple-darwin10/4.2.1/as: assembler (/usr/bin/../libexec/gcc/darwin/ppc/as or /usr/bin/../local/libexec/gcc/darwin/ppc/as) for architecture ppc not installed
Installed assemblers are:
/usr/bin/../libexec/gcc/darwin/x86_64/as for architecture x86_64
/usr/bin/../libexec/gcc/darwin/i386/as for architecture i386
src/MD2.c:134: fatal error: error writing to -: Broken pipe
compilation terminated.
lipo: can't open input file: /var/tmp//ccZdh65J.out (No such file or directory)
error: Setup script exited with error: command 'gcc-4.2' failed with exit status 1


Abhilfe schafft hier das setzen einer Umgebungsvariable für den Compiler.
sudo env ARCHFLAGS="-arch x86_64" easy_install cctrl

Nun läuft die Installation ohne weitere Probleme durch. Dieser Trick hilft auch beim Nachinstallieren von nativen Ruby GEMs oder PHP-Erweiterungen.

Nur wo ist jetzt der Harken? Leider ist es einfach so: Wenn sich etwas zu gut anhört um wahr zu sein – dann ist es auch nicht wahr. Warum wird eigentlich niemand stutzig, wenn man in den komfortablen Web-GUIs Optionen oder ganze Seiten zum Thema „Backup auf externe USB Datenträger“ findet? Besser wäre es, denn diese Geräte sind einfach nicht sicher. Sie weisen oft viele Schwachstellen auf, die sich frei nach Murphy’s Gesetz zu einer Menge FUN. multiplizieren. Und damit meine ich einen „fucking unbelievable nightmare“.

Zum Beispiel die Hardware dieser Kisten. Software-RAID in Kombination mit billigem Labtop-Speicher ohne ECC Funktion. Ein Fehler im Arbeitsspeicher kann also dazu führen das Datenmüll auf die Platten geschrieben wird und das NAS es noch nicht einmal merkt. Ich weis es immer noch nicht genau, aber das ist im Prinzip die Geschichte eines guten Freundes der gestern Abend verzweifelt mit einem NAS bei mir auf der Matte stand.

Ich habe interessanterweise das selbe NAS deshalb wusste ich, das es sich um ein normales Linux Software-RAID handelte, auf dem LVM2 mit ext2 Volumen rumhantiert. Also fix einen Server aufgestellt, Platten angesteckt, Ohrstöpsel rein und ein Linux booten. Der mdadm fand auf anhieb 3 RAID-Partitionen: Ein 2GB RAID1 mit 4 Volumen für die Firmware, ein 10GB RAID5 für whatever und die 750GB RAID5 für die eigentlichen Daten. Das Kommando bestätigte mir auch, das zwar die Volumen der Firmware nicht alle den Status „clean“ hatten, aber immerhin die eigentlichen Daten. Nur ließ sich das RAID5 Volumen nicht starten. Nach stundenlangem Googeln fand ich einen Blogpost eines Netgear-Technikers, der für solche Fälle vorschlägt das RAID bewusst mit einer fehlenden Platte zu starten, was auch funktionierte. Leider fand nun fdisk auf diesem Volumen keine Partitionen und auch der LVM erkannte kein physikalisches Volumen. Das ist anscheinend mal wieder ein klassischer Fall einer proprietären Lösung. Na toll. Da die alte Hardware so defekt war, das auch der „support mode“ nicht mehr funktionierte, beschlossen wir die Platten in mein Gehäuse zu stecken und von dort den „support mode“ zu starten, was überraschenderweise auch sofort funktionierte. Der Zugang per Telnet(!) blieb uns allerdings verwehrt, da dort ein Passwort verlangt wird, das wir nicht kennen, sicher aber alle Hacker dieser Erde.

Und jetzt kommt das wirklich unfassbare. Das NAS hängt jetzt auf Anweisung von Netgear für ungewisse Zeit mit Portweiterleitung von TCP/23 am Internet, damit ein Netgear-Supportmitarbeiter das Gerät per Telnet fixen kann. Diese Mitarbeiter arbeiten entweder aus Amerika oder China. Noch Fragen?

Das Fazit für uns ist auf jeden Fall, das unsere Geräte auf den Müll oder in die Bucht fliegen und wir ab sofort auf gängige Standards setzen. Es gibt im Moment NAS Gehäuse für 4 Platten mit Intel Atom CPUs und Windows Home Server. Wenn Man den Home Server wegwirft und zum Beispiel Openfiler oder FreeNAS installiert sind das sicher performante Geräte. ECC Speicher wird es wohl nicht geben, aber dafür einen nachgerüsteten Hardware-RAID Controller.

Also falls Ihr so ein NAS besitzt, IMMER an die Datensicherung der Datensicherung denken ;-)

Nähere Informationen gibt es hier auf der Zend Seite.

Soweit noch keine Kunst. Seine ware Stärke spielt das Plugin erst in Verbindung mit dem AjaxAction View Helper aus. Die zwei sind zusammen das dynamische Duo :-)

Das Prinzip ist einfach:
Liegen die Ergebnisse von einer Controlleraktion bereits im Cache vor, so wir der Inhalt ohne Umwege, direkt in das HTML der Hauptseite eingebaut und ausgeliefert. Ist das Ergebnis noch nicht im Cache, wir die Seite unvollständig, aber schnell ausgeliefert und der fehlende Inhalt kommt per AJAX hinterher.

Die Konfiguration
Damit der Entwickler komfortabel und zentral entscheiden kann, ob eine Route und wielange sie gecacht werden soll. Dazu wird dem dem Request einfach der Parameter cacheaction-ttl mit der Anzahl an Sekunden, die eine Antwort gespeichert werden soll mitgegeben. Zum Beispiel so:

resources.router.routes.content.route = "/content/:action/*"
resources.router.routes.content.defaults.controller = "content"
resources.router.routes.content.defaults.action = "index"
resources.router.routes.content.defaults.module = "default"
resources.router.routes.content.defaults.cacheaction-ttl = "20"

Das Plugin in sebst benötigt nur die Information, welchen Cache es aus der CacheManager Ressource verwenden soll und ob es aktiv ist, oder nicht In unserem Fall den “action” Cache.

cacheaction.cache = "action"
cacheaction.enabled = "true"
resources.frontController.plugins.cacheaction.class = "Webrocker_Plugin_CacheAction"

Auf diese Konfigutation greift auch der AjaxAction View Helper zurück, weitere Konfiguration ist nicht notwendig.

Wenn das Plugin geladen ist, gibt es zusätzliche Header in der Response, um die Fehlersuche zu vereinfachen. Die Header beginnen mit x-cacheaction-*.

In dem Video kann man schön sehen, wie hoch der spontan die Seite reagiert und wie vereinzelt Daten per AJAX nachgeladen werden müssen, weil der Cache abgelaufen ist.

Näheres dazu auf der Projektseite.

Viel Spaß beim Ausprobieren!

Im Prinzip wird die Webseite unvollständig an den User übermittelt und dann in seinem Webbrowser fertig gerendert.

Um die Problemstellung zu verdeutlichen habe ich einen ContentController geschrieben, dessen Geschwindigkeitsengpässe wohl keiner weiteren Erklärung bedürfen :-)

class ContentController extends Zend_Controller_Action
{
    public function getnavigationAction()
    {
        sleep(1);
        $this->view->assign('navi', 'This Navigation takes 1 second');
    }
    public function getcontentAction()
    {
        sleep(2);
        $this->view->assign('content', 'Delicious content takes 2 seconds');
    }
    public function gettweetsAction()
    {
        sleep(2);
        $twitter = new Zend_Service_Twitter_Search();
        $this->view->assign(
            'tweets',
            $twitter->search('php', array('lang' => 'en', 'rpp' => 5))
        );
    }
}

Dieser ContentController liefert Teilbereiche meiner Webseite aus. Eine Navigation, den Inhalt und einen Twitterstream. Aller Actions sind mit einer Zeitverzögerung von 1 oder 2 Sekunden ausgestattet, um den Vergleich deutlicher darstellen zu können.

Diese Teilbereiche fasse ich in der Index View, mit Hilfe des von Zend mitgelieferten Action View Helpers zusammen:

<div>
 <h1>old-school version</h1>
 <ul>
 <li><a href="/index/async">open the same page using AjaxAction helper</a></li>
 </ul>
 <h3>This is a REALLY expensive navigation</h3>
 <?php echo $this->action('getnavigation', 'content', null, array()); ?>
 <h3>This is the content</h3>
 <?php echo $this->action('getcontent', 'content', null, array()); ?>
 <h3>This is a cool result of a call to the Twitter-API</h3>
 <?php echo $this->action('gettweets', 'content', null, array()); ?>
</div>

Lade ich nur die Seite dauert es natürlich geschlagene 6 Sekunden, bis die Seite an den Webbrowser ausgeliefert wird.

Ersetze ich jetzt den View Helper Action durch AjaxAction und füge einen Parameter mit einem AJAX-Partial hinzu, das sich um die AJAX Magic kümmert, sieht meine View wie folgt aus:

<div>
 <h1>Welcome to the AjaxAction View Helper Demo</h1>
 <ul>
 <li><a href="/index/sync">open the oldschool version (synchronous)</a></li>
 </ul>
 <h3>This is a REALLY expensive navigation</h3>
 <?php echo $this->ajaxAction('getnavigation', 'content', null, array(), '_partials/ajax.phtml'); ?>
 <h3>This is the content</h3>
 <?php echo $this->ajaxAction('getcontent', 'content', null, array(), '_partials/ajax.phtml'); ?>
 <h3>This is a cool result of a call to the Twitter-API</h3>
 <?php echo $this->ajaxAction('gettweets', 'content', null, array(), '_partials/ajax.phtml'); ?>
</div>

Jetzt Rufe ich die Seite erneut auf:

Die komplette Seite konnte nun trotz der langlaufenden Prozesse unter 3 Sekunden, vollständig gerendert dargestellt werden.

Die Anpassung an das AJAX Framework der Wahl gestaltet sich einfach, es muss nur das Partial ajax.phtml angepasst werden. Hier mein Partial mit JQuery:

<div id="<?php echo $this->ajaxActionId ?>">
Content is beeing generated for You, please stand by...
</div>
<script type="text/javascript">
$('#<?php echo $this->ajaxActionId; ?>').load('<?php echo $this->ajaxActionUrl; ?>');
</script>

Schaut Euch einfach mal das Demoprojekt an, ich habe es komplett bei GitHub hochgeladen: AjaxAction-View-Helper-for-Zend-Framework

Dieser View Helper ist aber erst der Anfang! In Kürze werde ich ein FrontController Plugin mit dem tollen Namen ActionCache veröffentlichen. Es arbeitet Hand in Hand mit dem AjaxAction View Helper und ermöglicht ein hervorragend einfaches Caching von Teilbereichen und geringe Wartezeiten für User, die eine Seite aus einem kalten Cache abrufen.

Hier gehts weiter:
Artikel CacheAction Plugin For Zend Framework

Mein Versuchsaufbau sieht wie folgt aus:

Hardware:
Dell PowerEdge 860
Intel XEON QuadCore mit 2,13 Ghz
4 Gb Arbeitsspeicher
SAS300 Hardware RAID0
2x 73Gb 10k SAS HDDs

Software:
Debian 5.0.7 x86_64
Apache Bench
Htop

Testapplikation:
Einfachst denkbare Applikation. Eine Standart-Applikation die mit dem ZF-Kommando erzeugt wurde. Zusätzlich wir mit den Kommandos ein Page-Controller mit Index-Action und View erzeugt. Das Frameworks läuft im Environment “production”.

Testverfahren:
Mit ApacheBench wird 10.000 mal die URL http://127.0.0.1/page/index/ aufgerufen, 1x als Warmup und sofort im Anschluß 1x für die Messung. Die Durchläufe werden mit 1, 2, 4, 8, 16, 32, 64 und 128 zeitgleichen Zugriffen durchgeführt. Wenn ungefähr 9.000 Zugriffe geschehen sind, ermittele ich mit  Htop die Hardwarenutzung. Danach notiere ich die Ergebnisse von Apache Bench. Hier interessierten mich diesmal nur die ermittelten Requests pro Sekunde.

Ergebnisse:

Fazit:
Die Kommerzielle Version des Zend Servers ist im Schnitt 150% leistungsfähiger als die Community Edition und praktisch gleich auf mit dem PHP-Stack aus dem DotDeb-Repository. Wem es nur um die Leitung und weniger um SLA’s und kommerziellen Support geht, kann die Lizenzgebühr sparen und wird sicher mit DotDeb bestens bedient sein.

Zum Schluss stellt sich die Frage, ob der Zend Server CE künstlich verlangsamt wurde, um den Kauf der kommerziellen Version schmackhaft zu machen. Was meint Ihr?

Am Beispiel der Google-Suche werde ich zeigen, wie einfach man Tests mit Cucumber anlegen kann und das Testen damit wirklich Spaß macht :-)

Die Installation von Cucumber ist denkbar einfach. Als Basis benötigen wir eine lauffähige Ruby Umgebung. Wie man die einrichtet findet man zur genüge im Netz. Die glücklichen Mac Benutzer unter uns können sich an dieser Stelle ins gemachte Nest setzen, hier wird alles ab Werk mitgeliefert. Cucumber, Webrat und Mechanize können wir ganz einfach mit gem, dem Paketmanager von Ruby, installieren:

sudo gem install cucumber
sudo gem install webrat
sudo gem install mechanize

Jetzt erstellen wir die Verzeichnisstruktur für die Cucumber Tests, sowie 3 leere Dateien:

mkdir tests
mkdir tests/features
mkdir tests/features/support
mkdir tests/features/step_definitions
touch tests/features/search.feature
touch tests/features/support/env.rb
touch tests/features/step_definitions/search_steps.rb

Zuerst definieren wir das Environment für die Cucumber Tests. Wir laden im Prinzip Webrat und sagen Webrat das er “mechanize” benutzen soll, um die Webseiten zu rendern. Die Datei tests/features/support/env.rb füllen wir also mit folgendem Inhalt:

require 'webrat'
Webrat.configure do |config|
  config.mode = :mechanize
end
World(Webrat::Methods)
World(Webrat::Matchers)

Jetzt schreiben wir unser erstes Testszenario, eine einfache Suche, in die Datei tests/features/search.feature:

Feature: Search
  In order to find information
  As an user
  I want to use the search function
  Scenario: Simple search and check for result
    Given I am on the Google search page
    When I search for "car"
    Then I should see "car" in the search results

Nun rufen wir Cucumber auf um zu sehen, was es von unserem Szenario hält:

cd tests
cucumber

Jetzt sagt uns Cucumber das es undefinierte Schritte gibt und schlägt uns ein Gerüst vor, um diese Schritte einfach implementieren zu können:

Dieses Gerüst kopieren wir einfach 1:1 in die Datei tests/features/step_definitions/search_steps.rb:

Given /^I am on the Google search page$/ do
  pending # express the regexp above with the code you wish you had
end
When /^I search for "([^"]*)"$/ do |arg1|
  pending # express the regexp above with the code you wish you had
end
Then /^I should see "([^"]*)" in the search results$/ do |arg1|
  pending # express the regexp above with the code you wish you had
end

Nun führen wir Cucumber erneut aus:

Nun weist Cucumber uns darauf hin das es noch Schritte gibt, die wir noch nicht implementiert haben. Im folgenden implementieren wir Schritt für Schritt die fehlenden Schritte. Zuerst das Öffnen der Webseite. Dazu ersetzen wir in Zeile 2 das “pending” durch die Zeile:

visit "http://www.google.de"

Nun führen wir Cucumber erneut aus, um zu sehen ob der Schritt funktioniert:

Hervorragend! Ein Schritt ist grün, wir haben noch zwei vor uns. Jetzt füllen wir das Imput-Feld mit dem Namen “q” mit unserem Suchberiff und klicken auf den Button mit dem Namen “Google-Suche”. Dazu ersetzen wir ab Zeile 7 das “pending” durch folgende Zeilen:

fill_in "q", :with => arg1
click_button "Google-Suche"

Nun führen wir Cucumber erneut aus:

Jetzt implementieren wir den letzten Schritt. Wir überprüfen ob wir mindestens einen Suchtreffer zu “car” haben. In der Ergebnisseite suchen wir also in allen Div’s der Klasse “s” nach Em-Tags mit dem Inhalt “car”. Der letzte Schritt lautet also wie folgt:

response_body.should have_selector('div.s em') do |em|
  em.should contain(arg1)
end

Das Gesamtkunstwerk sieht jetzt also so aus:

Given /^I am on the Google search page$/ do
  visit "http://www.google.de"
end
When /^I search for "([^"]*)"$/ do |arg1|
  fill_in "q", :with => arg1
  click_button "Google-Suche"
end
Then /^I should see "([^"]*)" in the search results$/ do |arg1|
  response_body.should have_selector('div.r em') do |em|
    em.should contain(arg1)
  end
end

Nun rufen wir wieder Cucumber auf:

Jetzt habe ich unerwarteterweise einen Fehler bekommen. Die Ursache liegt in einem 302-Redirect. Es kommt einfach kein Suchergebnis.

Ich hätte diesen kleinen Ausflug in die Welt von Cucumber natürlich gerne mit einem “grünen” Testlauf abgeschlossen, aber ich hoffe das ich trotzdem ein wenig Neugierde bei dem ein oder anderen wecken konnte.

In den nächsten Wochen werde ich noch weitere Beispiel-Szenarien veröffentlichen, also schön am Ball bleiben :-)

Viel Spaß beim Ausprobieren!

Mein Versuchsaufbau sieht wie folgt aus:

Hardware:
Dell PowerEdge 860
Intel XEON QuadCore mit 2,13 Ghz
4 Gb Arbeitsspeicher
SAS300 Hardware RAID0
2x 73Gb 10k SAS HDDs

Software:
Debian 5.0.7 x86_64
Apache Bench
Htop

Server Zend Framework:
Zend Server CE 5.0.4
PHP 5.3.3
Opcode Cache

Server RAILS3:
Zend Server CE 5.0.4
mod_rails (Phusion Passenger)
Ruby 1.8.7

Testapplikation:
Einfachst denkbare Applikation. Eine Standart-Applikation die mit dem ZF-Kommando und RAILS-Kommando erzeugt wurde. Zusätzlich wir mit den Kommandos ein Page-Controller mit Index-Action und Views erzeugt. Die Views wurden so angepasst, das auf das Byte genau, das gleiche HTML erzeugt wird. Beide Frameworks laufen im Environment “production”.

Testverfahren:
Mit Apache Bench wird 10.000 mal die URL http://127.0.0.1/page/index/ aufgerufen, 1x als Warmup und sofort im Anschluß 1x für die Messung. Die Durchläufe werden mit 1, 2, 4, 8, 16, 32, 64 und 128 zeitgleichen Zugriffen durchgeführt. Wenn ungefähr 9.000 Zugriffe geschehen sind, mache ich einen Screenshot von Htop, um die CPU-Auslastung ermitteln zu können. Danach notiere ich die Ergebnisse von ApacheBench. Hier interessierte mich die gemittelte Antwortzeit pro Request und die ermittelten Requests pro Sekunde.

Ergebnisse:
Requests pro Sekunde

Antwortzeit in Millisekunden

Hardwarenutzung:
Im folgenden nur die Screenshots von 1, 2 und 4 Zeitgleichen Zugriffen. Die Screenshots von 8 – 128 sehen nahezu identisch aus, wie mit 4 zeitgleichen Zugriffen.

Fazit:
Ruby On Rails zusammen mit dem mod_rails nutzt die Hardware optimal aus. Die Gesamtperformance ist ungefähr 3x besser, als beim Zend Framework MVC auf einem Zend Server, mit allen Optimierungen. Zwischen 4 bis 16 Zeitgleichen Verbindungen arbeitet Rails am effizientesten auf einem 4-Kern-Server. Die PHP-Applikation hingegen liefert ab 4 Verbindungen durchweg die gleiche Anzahl an Verbindungen pro Sekunde. Wenn der Zend Server die Hardware vollständig ausnutzen würde, könnte das Zend Framework MVC sicher noch 50% mehr Leistung bringen. Ich werde bei Gelegenheit mal nachforschen, was dort blockiert hat.

And the winner is: Ruby On Rails mit mod_rails

Update:

Nachdem ich in meinem Artikel Zend Server CE vs Zend Server vs DotDeb herausgefunden habe, das der Zend Server CE nicht die geeignete Platform war um diese zwei Frameworks zu vergleichen, habe ich die Ergebnisse des ZF vs. Rails Showdowns noch mal neu aufgetragen. Entgegen meiner Vemutung das ich noch 50% mehr Leistung erwarten könnte waren es satte 150%, die der kommerzielle Zend Server und der PHP-Stack aus dem DotDeb Repository schneller waren. Seht selbst:

Fazit 2:
Es gibt keinen Gewinner in diesem Vergleich. Wie wir aber sehen konnten hat die Wahl des richtigen PHP-Stacks eine enorme Tragweite, wenn es um die Performance geht.

Die meisten Entwicklungsumgebungen sehen oft wie folgt aus:

• – Linuxserver
• – Samba-Freigabe vom Rootverzeichnis der Webservers oder einzelner Projekt-VHosts
• – Apache Webserver mit VHosts für jedes Projekt
• – Die Entwickler mounten die Samba-Freigaben und arbeiten auf ihnen

Nun kommen wir zum eigentlichen Problem: Der Apache erzeugt Dateien als Benutzer www-data in Gruppe www-data, die Entwickler als Benutzer entwicklerx in Gruppe users.
Natürlich kann man die Verzeichnisrechte durch Stickybits, PHP-Umasks usw. in den Griff bekommen. Das ist aber recht kompliziert und funktioniert auch nicht überall wirklich zuverlässig.

Mit dem Modul apache2-itk-mpm läuft der Webserver als Benutzer root und ist dadurch in der Lage für jeden VHost einen Worker-Thread mit der Identität eines normalen Benutzer zu starten. Für einen Livebetrieb ist das natürlich ein Sicherheitsrisiko, der Livebetrieb ist aber auch selten das Problem. Die Entwicklungsarbeit kostet und jeden Tag Nerven.

Und so funktioniert es am Beispiel eines Debianartigen Systems:

apt-get install apache2-itk-mpm

Jetzt können wir pro VHost den dazugehörigen Benutzer konfigurieren.

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    ServerName projektx.devserver.local
    DocumentRoot /www/projektx/
    <Directory />
        Options FollowSymLinks
        AllowOverride All
    </Directory>
    <Directory /www/projektx/>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
    </Directory>
    <IfModule mpm_itk_module>
        AssignUserId entwicklerx users
    </IfModule>
</VirtualHost>

Jetzt noch einmal den Apache durchstarten.

/etc/init.d/apache2 restart

Das wars schon!