Archive for August, 2011
Linkpool Nummer 20
Serverseitige interne Informationen aus PHP-Applikationen im Client anzeigen, .NET macht vor was möglich ist:
PHP Sessions in node.js speichern:
Verteiltes Map-Reduce:
Cross Browser Test Tool Übersicht
HTML5 und CSS3 Features schön animiert gezeigt:
Ausflug in die Spieleentwicklung mit Javascript und dem Canvas Element:
Gute Zusammenfassung zu sicheren Login-Formularen und Dingen drumherum wie Passwort vergessen Funktionen etc:
PDFs dynamisch generieren: viele Möglichkeiten
Oft hat man eine Webseite in die man auch eine Export-Möglichkeit einbauen möchte, scheut aber den großen Aufwand, PDFs etc. zu generieren. Doch es gibt auch einfache schnelle Lösungen, die meistens ausreichen. Hier möchte ich einige im Überblick aufzählen.
- Einfach HTML nehmen und daraus ein PDF basteln. Viele Daten, die wir bereits auf der Webseite darstellen, sollen so oder ähnlich in das PDF fließen. Mit geeigneter Strukturierung verhindert man somit doppelten Code. Meine aktuellen Lieblinge für diese Aufgabe sind dompdf und WkhtmlToPDF (siehe Blogartikel). Es gibt aber noch einige mehr, beispielsweise mPDF, das intern FPDF und HTML2FPDF nutzt. Ein älterer Vertreter dieser Spezies ist HTML_ToPDF. Doch diese Lösungen haben einige Probleme, beispielsweise hängt die Ausgabe häufig stark von den Daten ab: HTML ist nicht seitenorientiert, sodass es sehr schwer sein kann ein mehrseitiges PDF zu erzeugen (wo der Seitenumbruch an der korrekten Stelle ist). Auch lässt die Unterstützung von CSS oder nicht-W3C-konformen HTML häufig zu wünschen übrig. Für einfache Einseiter jedoch gut geeignet.
<?php require_once("dompdf_config.inc.php"); $html = '<html><body>'. '<p>Put your html here, or generate it with your favourite '. 'templating system.</p>'. '</body></html>'; $dompdf = new DOMPDF(); $dompdf->load_html($html); $dompdf->render(); $dompdf->stream("sample.pdf");
Der Stand von HTML5
Da viele von uns wahrscheinlich bereits HTML5 Webseiten erstellen oder ältere Seiten um HTML5-Features erweitern ist es wichtig zu wissen welcher Browser welches Feature unterstützt, um abschätzen zu können wieviel Prozent der Besucher das neue Feature nutzen können und wie viele nicht.
Die wohl korrekteste Methode das herauszufinden ist auf die aktuelle Webseite ein paar Javascript-Zeilen hinzuzufügen die die entsprechende Feature-Unterstützung testet, die sogenannte Feature Detection. Die Liste mit unterstützten bzw. nicht unterstützten Features schickt man via AJAX zum Server zurück. Nur so hat man aktuelle und auf die eigenen Besucher abgestimmte Zahlen.
Man müßte also ähnlich wie hier für das canvas-Element einen Test schreiben:
function supports_canvas() {
return !!document.createElement('canvas').getContext;
}
Aber es gibt schon große Bibliotheken, die hunderte von solchen Tests kennen und wo man einfach eine Funktionalität testen kann, wie hier beispielsweise mit Modernizr:
if (Modernizr.canvas) {
// let's draw some shapes!
} else {
// no native canvas support available :(
}
Modernizr ist der bekannteste Vertreter, es ist auch möglich die unterstützten Codecs des <video> und <audio> Tags abzufragen und vieles mehr.
Es gibt aber auch Webseiten und Tabellen, die allgemein darstellen welche Browser-Versionen welche Features unterstützen. Wenn man diese Tabellen nimmt und ungefähr mit der Browser-Verteilung der eigenen Besucher verrechnet kommt man auch zu einem Ergebnis.
Die bekanntesten Seiten sind:
- http://html5test.com/results.html bzw. http://www.browserscope.org/user/tests/table/agt1YS1wcm9maWxlcnINCxIEVGVzdBiBsqYGDA
Wenn man nun das Ergebnis erhält dass bereits 85% der Besucher das Feature X unterstützt gilt es Entscheidungen zu treffen. Ist es noch zu früh, das Feature einzubauen? Was macht man mit denjenigen, die noch einen alten Browser haben? Versucht man das fehlende Feature nachzubilden? Für diese Nachbildungen gibt es Sammlungen von sogenannten Polyfills und Shims. Wenn der Browser also beispielsweise das placeholder-Attribut noch nicht unterstützt ist trotzdem möglich, sie mittels Javascript hinzuzufügen. Das geht natürlich nicht für alle neuen Features, aber für viele gibt es Nachbauten. Aber dieses zusätzliche Javascript bläht natürlich die Webseite auf und es ist auch nicht so schnell wie die native Unterstützung des Browsers. Aber was tut man nicht alles dafür, neue Features nutzen zu können ohne einen Teil seiner Besucher zu verärgern.
Hier eine schöne Liste der aktuell verfügbaren Polyfills und Shims:
Das SMTP Protokoll im Detail betrachtet
Vor einem Jahr habe ich bereits das IMAP-Protokoll näher betrachtet, nun soll das SMTP Protokoll folgen. Jeder versendet und empfängt E-Mails, und viele von euch werden auch eigene Mailserver betreiben, es kann also nicht schaden das Protokoll näher zu kennen. SMTP steht für Simple Mail Transport Protocol, und genau das ist es auch: Simple. Mit einer Hand voll Befehlen kann man E-Mails auf den Weg bringen. SMTP wird von Mailservern gesprochen die E-Mails empfangen oder an andere Mailserver weitergeben, zur E-Mail-Abholung durch einen Client wird IMAP oder POP3 genutzt.
Nehmen wir erstmal den einfachsten Fall: Wir möchten eine E-Mail an meine E-Mail Adresse schicken. Dazu müssen wir zuerst herausfinden welcher Server für diese E-Mail-Adresse zuständig ist. Wir befragen den DNS-Server nach dem sogenannten MX-Eintrag (Mail Exchange) und erhalten den oder die Server, an die wir uns wenden müssen:
dig -t MX phpgangsta.de +short 10 mail.phpgangsta.de.
Hier könnten auch mehrere Ergebnisse erscheinen wenn ich mehrere Mailserver betreiben würde. Wir schauen also als nächstes, wer hinter mail.phpgangsta.de steckt:
dig mail.phpgangsta.de +short 85.214.28.26
In diesem Fall ist es mein Server mit der IP 85.214.28.26, wir müssen unsere E-Mail also dort abgeben. Der SMTP Port ist TCP 25, wohin wir uns ganz einfach mittels Telnet verbinden können:
telnet 85.214.28.26 25 Trying 85.214.28.26... Connected to 85.214.28.26. Escape character is '^]'. 220 h1440682.stratoserver.net ESMTP Postfix (Debian/GNU)
Der Server begrüßt uns mit seinem Namen und verrät auch gleichzeitig, dass er nicht nur SMTP spricht, sondern auch Extended SMTP (ESMTP). Mittlerweile sollten alle dieses neue Protokoll unterstützen, das 1995 eingeführt wurde um spezielle Fähigkeiten (Extensions) hinzuzufügen wie beispielsweise Authentifizierung. Vorher gab es die nicht, daran hatte wohl niemand gedacht früher *tzz*. Aber auch TLS ist erst mit ESMTP möglich, heutzutage gibt es auch wahrscheinlich keine Server mehr, die kein ESMTP anbieten.
Da der Server auch TLS unterstützt können wir uns auch verschlüsselt verbinden, indem wir erst eine normale Verbindung (wie oben) aufbauen und dann direkt mit dem STARTTLS Befehl in den verschlüsselten Modus wechseln. Da man das in Telnet schlecht eintippen kann nutzen wir den openssl-Client, der genau dies macht:
Continuous Testing mit PHP?
Continuous Integration ist einigen eventuell ein Begriff. Dabei geht es darum, einen Server zu haben der bei jedem Commit (bzw. Push) des Quelltextes Dinge ausführt wie Unit Tests, Akzeptanz-Tests, PHP Lint, CodeSniffer oder auch ein Deployment auf einen Test-Rechner. Wenn man nun also häufig pushed kann man sicher sein dass (bei genügend guten Tests) die Software läuft und nichts kaputtgegangen ist. Und wenn doch, weiß man wann es ungefähr passiert ist.
Continuous Testing geht nun noch einen Schritt weiter. Hierbei werden nicht erst bei jedem Push die Unit-Tests gestartet sondern bei jedem Abspeichern einer Datei auf dem Entwicklungsrechner. Da gibt es nun mehrere Ansätze wie man das erreichen kann. Vielleicht kennt ihr andere und bessere Tools, um kontinuierlich auf der Workstation zu testen.
Möglichkeit 1: Die IDE bietet einen „On-Save“ Einstellung, wo man einen Befehl eingeben kann der ausgeführt wird sobald die IDE eine Datei abspeichert. Dort trägt man dann sein Shell-Script ein das die Unit-Tests startet. in PHPStorm kann man zum Beispiel auch einstellen dass nach 15 Sekunden IDLE automatisch gespeichert wird, oder wenn PHPStorm den Fokus verliert (weil man gerade in den Browser wechselt). Ein Garant für häufiges Testen.
