Eine sehr gute Sammlung an Hinweisen, wie man seinen php Quellcode optimieren und beschleunigen kann. Punkte wie ” ‘else if’ statements are faster than select statements aka switch/case.” oder “Use echo‘s multiple parameters (or stacked) instead of string concatenation. ” waren mir und sind sicher vielen Entwicklern nicht SO bewusst. Eine kleine Referenz, die man sich bookmarken sollte…
Über den Beitrag Passwortmythen oder „Was Du schon immer über Passwörter wusstest, aber nie zu sagen wagtest“ bin ich auf das Thema Passwortsicherheit bei Web-Applikationen gestoßen und habe mir ein paar Gedanken dazu gemacht.
Für alle technisch nicht so versierten Leser hier mal ein kurzer Abriss, wie die derzeitigen Möglichkeiten für die Passwort-Speicherung in Benutzertabellen aussieht: man kann (aber sollte dies NIEMALS tun) die Passwörter im Klartext abspeichern, man kann sie hashen, mit einem Salt hashen und mit per User Salts hashen. Dabei gehe ich natürlich die ganze Zeit aus Sicht der Web-Applikation vor.
Klartextpasswörter
Die Klartextspeicherung sollte klar sein: man speichert das übertragene Passwort einfach so, wie man es empfängt, in der Datenbank. Wenn der User sich im System anmeldet, dann gibt er seinen Benutzernamen und sein Passwort ein. Wenn man die Daten empfangen hat, zieht man sich den Datensatz dieses Benutzers aus der Datenbank und vergleicht das übertragene Passwort mit dem in dem Datensatz gespeicherten. Wenn beide übereinstimmen, kann man den User als eingeloggt markieren. An sich ist dieses Vorgehen nicht problematisch und von außen her sicher. ABER: wenn irgendjemand – über welchen Weg auch immer – Zugriff auf die Benutzertabelle bekommt, dann kann er die Passwörter direkt lesen. Auch das wäre noch nicht SO kritisch, wenn alle User verantwortungsvoll mit ihren Login-Daten umgehen würden. Das tun sie aber nicht. Denn: ein sehr großer Teil aller Computerbenutzer verwendet EIN Passwort für ALLE Logins – also Facebook, Ebay, Email, Online Games, usw. D.h., wenn man nun die Passwörter eines Systems herausfindet, dann ist es sehr wahrscheinlich, dass man sich bei der angegebenen Email-Adresse mit dem gleichen Passwort anmelden kann. Von dort aus kann man dann sehr leicht auf alle anderen Accounts des Benutzers zugreifen, da man ja nun die Passwörter zurück setzen kann und die entsprechenden Mails empfängt.
Hashes
Ok, dann müssen wir die Passwörter also verschlüsseln. Wichtig ist dabei, dass man dies mit einer Einweg-Berechnung erledigt – denn sonst könnte man den berechneten Wert einfach wieder zurück rechnen. Für diese Aufgabe gibt es die Hash-Funktionen. Diese Einwegfunktionen erzeugen aus einer beliebig langen Zeichenfolge einen 32-stelligen Text aus Zahlen und Buchstaben. Beispiele für solche Funktionen sind MD5 oder SHA-1. Der Vorteil ist: man kann diese Werte nicht in die Ursprungswerte zurück rechnen und man kann auch keine Rückschlüsse auf den ursprünglichen Wert schließen. Um das zu verdeutlichen, hier mal die MD5 Hashes für die Zahlen 0, 1, 2:
md5(0) = cfcd208495d565ef66e7dff9f98764da
md5(1) = c4ca4238a0b923820dcc509a6f75849b
md5(2) = c81e728d9d4c2f636f067f89cc14862c
Wie man sieht: völlig unterschiedliche Werte. Ok, wir haben nun also die Möglichkeit, Passwörter nicht rekonstruierbar abzuspeichern. Aber eines haben wir nicht beachtet: die Freaks. Nach einiger Zeit kamen ein paar Verrückte auf die Idee, einfach alle möglichen Zeichenkombinationen zu nehmen, die entsprechenden Hashes zu erzeugen und diese dann in einer Datenbank abzuspeichern. Hat man nun einen Hash aus einer Benutzertabelle, fragt man einfach diese Datenbank ab und erhält das entsprechende Klartext-Passwort. Außerdem ist anhand der Hashes sehr schnell erkennbar, wenn unterschiedliche Benutzer das gleiche Passwort verwenden – denn dann steht bei diesen jeweils der gleiche Hash in der Datenbank.
Rainbow Tables
Die Sache hat aber den Haken, dass bereits bei einem Wort mit 6 Zeichen der Typen [A-Za-z0-9./] über 1,4 Tb an Daten zusammenkommen. Also hat man die sogn. Rainbow-Tables entwickelt, die zwar genauso vorgehen, aber nur einen Teil des Hashes in der Datenbank abspeichern (wird durch Reduktionsfunktionen verkürzt). Dadurch reduziert sich die Menge der Daten deutlich. Mittels der Rainbow Tables kann man also mit einem gegebenen Hash sehr schnell auf das ursprüngliche Passwort kommen.
Salted Hashes
Da wir nun wissen, dass unsere in der Datenbank abgespeicherten, gehashten Passwörter zwar auf den ersten Blick nicht direkt lesbar sind, aber mittels Rainbow Tables innerhalb kürzester Zeit sehr schnell zum Vorschein kommen, verwenden wir einen einfachen Trick, um den Hash doch wieder einzigartig zu machen: wir salzen ihn. Man nimmt also einfach das zu verschlüsselnde Passwort und setzt eine beliebige Zeichenfolge davor oder hinten dran – oder beides, und bildet davon den Hash. Beispiel:
Unser Passwort lautet = Passwort
Unser Salt lautet = s3cureIt
Hash: md5(Passwort) = 3e45af4ca27ea2b03fc6183af40ea112
salted Hash: md5(s3cureItPasswort) = 81fc33ece07aa1357d469ec36f5e2e55
Wie ihr seht, kommen 2 völlig unterschiedliche Hashes heraus, obwohl wir in beiden Fällen das gleiche Passwort verschlüsselt haben. Der Vorteil an diesem Verfahren ist, dass man nun den Hash nicht mehr ohne weiteres über eine vor-generierte Datenbank abfragen kann, da das Passwort, welches verschlüsselt wurde, ja nicht “Passwort”, sondern “s3cureItPasswort” lautet. Man hat durch das Salt so gesehen ein viel längeres Passwort, und außerdem kann man auf diesem Wege nun doch Sonderzeichen einbauen, die der Benutzer in seinem Passwort so wohl nicht verwendet. Der Punkt ist: wenn jemand die Benutzertabelle entwenden kann, dann kommt er auch an den verwendeten Salt-Text heran. Was aber nicht weiter schlimm ist, denn auch mit dem Salt braucht der “Einbrecher” sehr sehr lange, um die Passwörter zu entschlüsseln.
Wenn man nun eine Benutzertabelle mit 1 Million Einträgen erhält, dann kann man durchaus die Zeit investieren und einfach Rainbow-Tables erzeugen, die eben alle möglichen Wörter mit dem gegebenen Salt verwenden. Man baut also speziell für diese Tabelle eine eigene Datenbank auf. So steckt man vielleicht den Rechenaufwand von ein paar Monaten hinein, hat dann aber schlagartig Zugriff auf 1 Million Benutzernamen und Passwörter.
per User salted Hashes
Um auch diese Problematik zu umgehen, hat man die Salt-Variante noch etwas abgewandelt und geht nun so vor: Für jeden Benutzer wird ein eigener Salt erzeugt und in dem Datensatz des Benutzers gespeichert. Wenn er sich nun einloggt, wird der Datensatz des Benutzers gelesen, das eingegebene Passwort mit dem gespeicherten Salt kombiniert und erst dann der Hash gebildet. Anschließend vergleicht man dieses Ergebnis wieder mit dem aus der Datenbank und bei Übereinstimmung kann man den Benutzer einloggen.
Dieser kleine Umweg führt aber dazu, dass, selbst wenn man über eine komplette Benutzertabelle mit den Hashes und den Salts verfügt, man pro Benutzer mehrere Monate benötigt, um das jeweilige Klartextpasswort herauszufinden.
Zusammenfassung
Der kleine Abriss ist nun doch etwas umfangreicher geworden, zeigt aber grob die Vorgehensweisen. Ich möchte hier anmerken, dass das nur die stark gekürzte Variante für Laien ist – wer sich umfangreicher mit den Themen beschäftigen möchte, sollte die Begriffe einfach mal bei Wikipedia nachlesen.
Bisher setze ich auf (per user) salted Hashes, die meiner Meinung nach eine relativ hohe Sicherheit bieten – solange sichere Passwörter verwendet werden. Da man bei Usern aber nicht davon ausgehen kann, dass sie sichere Passwörter wie “#,hgfsdU4358$%&§jkdfg8734ä#++..-” verwenden, ist die Sicherheit natürlich eingeschränkt. Leider verwenden viele Benutzer noch immer Passwörter wie “Sommer”, “Gott” oder “Erde”, welche sehr sehr schnell zu knacken sind. Wenn solche Passwörter verwendet werden, helfen auch die ausgeklügeltesten Sicherungsverfahren nicht viel weiter, da die Berechnungszeit der Passwörter dadurch auf wenige Sekunden verkürzt werden.
Als Fazit für alle Internetnutzer kann ich daher ganz klar sagen: VERWENDET NIE DAS GLEICHE PASSWORT FÜR ALLE EURE ZUGÄNGE!
Wie mache ich es besser?
Das große Problem, mit welchem im Prinzip jede Verschlüsselung zu kämpfen hat, ist Zeit. Wie viel Zeit brauche ich, um ein Passwort zu knacken? Da Rechner mit jedem Jahr schneller und schneller werden und nun auch sehr performante Chips wie GPUs zum Einsatz kommen, sind viele Verschlüsselungen nutzlos geworden – man kann sie einfach innerhalb kürzester Zeit knacken.
Und somit kommen wir auf den eigentlichen Inhalt dieses Artikels: bcrypt. Das Tool setzt nämlich genau bei diesem Problem an: man kann die Zeit, die man benötigt, um einen Hash zu erzeugen, beeinflussen. Das hat den großen Vorteil, dass man die Verschlüsselung an die Geschwindigkeit moderner Rechner anpassen kann und diese somit nicht automatisch in ein paar Jahren unbrauchbar wird. Das restliche Handling ist gleich – man übergibt einen Wert plus eben einen Zeitfaktor und erhält danach einen Hash-Wert. Da man nun die Berechnungszeit beeinflussen kann, dauert es eben nicht mehr eine Mikrosekunde, um einen Hash zu berechnen, sondern 0,5 Sekunden. Wenn dieser Fall eintritt, dann ist es einfach nicht mehr möglich, innerhalb einer sinnvollen Zeitspanne gegen diese Verschlüsselung mit Bruteforce (also dem Durchprobieren aller möglichen Zeichenkombinationen) oder großen Wordlisten vorzugehen – egal wie schnell der Rechner ist.
Gerade für php Entwickler ist dies eine sehr einfache Möglichkeit, die Benutzertabellen ihrer Applikationen abzusichern – denn bcrypt ist seit php 5.3 im Basissystem enthalten: crypt.
Ich hoffe, dass ich nichts vergessen habe – andernfalls freue ich mich natürlich über Meinungen in den Kommentaren…
Nach nun knapp 6 Jahren in der Programmierung und mehreren kleinen und großen Projekten, habe auch ich mir ein Bild von der Welt der Softwareentwicklung machen können. Ich konnte einige Charaktäre kennenlernen und für mich haben sich bestimmte Punkte herauskristalisiert, welche meiner Meinung nach einen guten Entwickler ausmachen.
Beginnen wir erstmal mit dem handwerklichem Teil, den wohl jeder Entwickler drauf haben sollte. Neben Syntax und Semantik gehören auch Kenntnisse der Wirkungsweise von Programmiersprachen, Netzwerktechnik, Computertechnik im Allgemeinen, Design Patterns, Datenbanken, Betriebssystemeigenheiten usw. zum Erfahrungsschatz. Erst wenn man das komplexe Zusammenspiel dieser Komponenten versteht, so kann man auch alle Probleme, die da so kommen mögen, lösen.
Ein anderer Punkt, und den finde ich besonders wichtig, ist die Erfahrung. Entwickler, die eine Programmiersprache beherschen, können zwar schnell neue Sprachen erlernen, weil sie sich fast alle ähneln oder zumindest die gleichen Prinzipien verfolgen (hier gibt es natürlich Ausnahmen). Aber auch wenn der Entwickler die neue Sprache erlernt hat, so kennt er bestimmte Eigenheiten eben erst, wenn er auch eine gewisse Praxis hat (min. 0,5 – 1 Jahr). Das hat Auswirkungen auf die Geschwindigkeit des entwickelten Codes und natürlich auch auf die Produktivität des Entwicklers. Meiner Meinung nach ein häufig nicht bedachtes Problem.
Ein wichtiges Kriterium für einen guten Entwickler ist seine Arbeitsweise. Man kann streng nach Lehrbuch programmieren, man kann aber auch lösungsorientiert an ein Problem herangehen. Obwohl ich mich möglichst an die Konventionen halte, so bin ich doch auch öfter mal der lösungsorientierte Typ. Ich denke einfach, das man immer eine gute Balance zwischen Lesbarkeit des Codes und aber auch dessen Performance halten sollte. Natürlich macht es Sinn, streng objektorientiert zu entwickeln, an manchen Stellen kann dies aber sowohl in der Lesbarkeit als auch in der Geschwindigkeit des Codes negative Auswirkungen haben. Es ist aber von Fall zu Fall unterschiedlich – und die Grenze zum Gefrickel ist hauchdünn.
Neben der Art und Weise, wie man seinen Code strickt, hat natürlich auch die Verwendung von Kommentaren und geeigneten Funktions/Variablennamen einen sehr großen Einfluss auf die Lesbarkeit. Meine Devise: lieber eine Funktion “getLoggedInUserData()” nennen als “getData()” – sagt beides das gleiche aus, jedoch gibt erste Funktion deutlich mehr Randinformationen und beschleunigt so sehr schnell das Verständnis für den Code. Wie lang eine Funktionsbezeichnung oder ein Variablenname ist, hat keinerlei Auswirkung auf die Ausführungsgeschwindigkeit – denn beim Kompilieren werden die Namen sowieso verworfen. Also warum geizen, wenn man diese Fähigkeit gut ausreizen kann. Natürlich sollte man es auch nicht übertreiben und zum Schluss Funktionen wie “todayIsAGoodDaySoGiveMeTheUserData()” nehmen 😉
Dokumentation des Codes ist natürlich immer ein leidiges Thema. Ich persönlich bin eigentlich immer ganz froh, wenn wie oben beschrieben Variablen und Funktionen selbsterklärend sind und sich doch ab und zu eine Kommentarzeile im Code verläuft. Wenn ich dann noch eine zusätzliche Dokumentation erhalte, die mir grob einen Gesamtüberblick über das System verschafft, bin ich schon glücklich. Als Entwickler kann man sich, mit etwas Erfahrung, sehr schnell in Systeme “reindenken” – gibt es dann dazu eine automatisiert generierte 1000-Seiten Doku, wird zumindest bei mir der gegenteilige Effekt erziehlt.
Sätze wie “Kommentare schreibe ich dann später rein” kennen wir wohl zuhauf – und seien wir mal ehrlich: in diesem Fall wird es nie einen Kommentar geben. Ein guter Ansatz ist daher, zuerst den Klassen- oder Methodenrumpf zu bauen, grob zu dokumentieren und erst dann mit der Implementierung zu beginnen.
Optimalerweise kann man abschließend noch ein paar erläuternde Kommentarzeilen verpacken und schon hat man wieder deutlich zur Verständlichkeit beigetragen.
Fazit
Ein nettes Zitat, welches ich kürzlich gelesen hatte, sagt folgendes: “Entwickle immer so, als ob der Typ, der den Code später warten muss, ein Psychopat ist, der deine Adresse hat.”. Besser kann man es wohl nicht formulieren 😉
Links:
Geek&Poke (Bildquelle)
Da ich durch meinen Jobwechsel nun in der Frontend Entwicklung tätig bin, muss ich mich natürlich auch stärker mit Javascript – speziell mit jQuery – beschäftigen. Das System ist ziemlich genial gebaut und so kann man sehr schnell einsteigen.
Aber wie das so ist – man stößt auch mal auf Probleme. Und so hing ich an der Aufgabe, ein Hover-Event verzögert auszulösen. Zunächst ging ich davon aus, das jQuery diese Möglichkeit von Haus aus bietet – was aber nicht der Fall ist. Man kann zwar das Plugin HoverIntent verwenden, ich wollte aber eher eine Lösung mit Bordmitteln. Und die gibt es:
$("#cart-summary").mouseenter(function () {
$("#cart-summary").addClass("hasFocus");
setTimeout(function(){
if ($("#cart-summary").hasClass("hasFocus")) {}
$('.flycart').slideDown('fast');
}
}, 500 );
});
$("#cart-summary").mouseleave(function () {
$("#cart-summary").removeClass("hasFocus");
});
Das Prinzip ist eigentlich ziemlich genial: Per “Mousenter” wird erkannt, ob sich die Maus über dem Element (in diesem Beispiel “#cart-summary”)befindet. Sofort wird dem Element die Klasse “hasFocus” zugewiesen und der eigentliche Funktionsaufruf (z.B. “slideDown”) wird mittels der TimeOut Funktion verzögert (hier um 0,5 Sekunden) aufgerufen. Der Trick ist nun, dass innerhalb der Timeoutfunktion noch einmal geprüft wird, ob das Element noch die Klasse “hasFocus” hat. Nur wenn dies der Fall ist, wird die “slideDown” Funktion ausgeführt.
Der findige Entwickler wird nun bemerken, dass trotz dieser Raffinessen, das gleiche Ergebnis, wie bei einem einfachen Hover, erziehlt wird – denn auch mit Timeout wird die Funktion in jedem Fall aufgerufen. Und da kommt das zweite Event ins Spiel: bei einem “MouseLeave” wird dem aktuellen Element die Klasse “hasFocus” entfernt. Dadurch schlägt die Prüfung in der TimeOut Funktion fehl und die hinterlegte “slideDown” Funktion wird nicht ausgeführt.
Erst mittels der “MouseLeave” Funktion wird also das verzögerte MouseOver Event ermöglicht.
Webentwickler kennen Firebug – DAS Tool um Javascript und HTML/CSS zu debuggen. Natürlich zähle ich auch dazu und das Tool hat mir bereits viele Male geholfen. Neu war mir allerdings FirePHP, eine Erweiterung für Firebug. Wie der Name bereits sagt dient es dem Debugging von php, vor allem im Hinblick auf die Ajax Entwicklung.
Kann man sonst mit einfachen print_r, vardump und die() einfach durch eine Anwendung gehen – was sicher nicht die professionelste Lösung ist – so hat man diese Möglichkeit bei Ajax nicht, da es sich dabei ja um eine reine Kommunikation zwischen Javascript und dem php Backend handelt. Mittels FirePHP hat man aber nun die Möglichkeit, Nachrichten an Firebug zu senden und diese anzeigen zu lassen.
Neben der Möglichkeit des Ajax Debuggings ist das Tool auch sehr hilfreich, ohne störende print_r’s, vardump’s und die()’s Debug-Meldungen zu erhalten und somit z.B. nicht das Layout der Seite zu zerstören.
So, nun aber genug der Einführung, schauen wir uns das System doch einfach mal an…
Unter addons.mozilla.org bekommt ihr die Erweiterung FirePHP. Wichtig ist, das ihr vorher Firebug installiert habt.
FirePHP erkennt ihr nun an dem blauen Käfer neben dem Firebug Symbol:
Bevor die Zend-Applikation läuft, also am besten in der public/index.php oder der application/bootstrap.php, einfach folgende Zeilen implementieren:
$writer = new Zend_Log_Writer_Firebug();
$logger = new Zend_Log($writer);
Zend_Registry::set('debug_logger', $logger);
Damit wird der FirePHP Logger initialisiert und ist ab sofort über die Zend_Registry überall in der Applikation verfügbar.
Nun könnt ihr an jeder beliebigen Stelle folgendes ausführen (das Array in der ersten Zeile dient natürlich nur dem Test, ihr braucht nur die 2. Zeile):
$var = array("Part_1"=>"Blabla", "Item2"=>array("Part_2"=>"Blabla"));
Zend_Registry::get('debug_logger')->log($var, Zend_Log::INFO);
Und schon bekommt ihr unter Firebug folgendes serviert:
Wenn ihr auf diese Log-Zeile klickt, so öffnet sich noch ein schöner Overlay in dem die Daten noch besser lesbar werden:
Ganz wichtig noch: Damit die Debug-Meldungen erscheinen, müsst ihr den Punkt “Netzwerk” aktiviert haben – sonst kommen die Meldungen bei Firebug nicht an:
Links:
firephp.org
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
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.
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.
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
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: