Wer eine ausgecheckte Version mit einer Revisionierten vergleichen möchte, kann das mit

svn diff -r {rev_nr} lokale_datei.php

tun. {rev_nr} muss die Nummer einer Revision sein, in der die Datei verändert wurde, sonst wird schlicht nichts ausgegeben.

Ähnliche Artikel:

1. PHP Handbuch über die Shell

Was könnte man nur mit Port-Fetischismus meinen? Ich liebe Code-Usability. Ein super Thema, über das ich ja schon öfter referiert habe. Es ist so schön wie zeitlos… Was dabei bis lang unter den Tisch gefallen ist, sind lesbare URLs (Vielleicht mal in einem anderen Artikel) und Portangaben. Also schöne Portangaben.

Nur so zur Erinnerung: http://www.phpblogger.net:80/ ist eine Möglichkeit, einen Port zu erzwingen. Klar, das Du das schon wusstest. Welcher Port macht denn im Browser noch Sinn? Naja 443 für SSL zum Beispiel. Aber statt das zu erzwingen, wird einfach das Protokoll auf HTTPS geändert, was implizit auf Port 443 verweist.

Um das klar zustellen: Schöne Portangaben, sind nicht vorhandene Portangaben. Aber wie ein aufmerksamer Leser im Artikel zu HTTPS und SSL richtig angemerkt hat, kann man über verschiedene Ports unter ein und derselben IP mehrere SSL-Zertifikate betreiben. Und jetzt geht es mit den dreckigen Spielchen weiter, die man mit Portangaben in der URL machen kann:

Natürlich gibt es sinnvolle Möglichkeiten, die das Web-Protokoll erlaubt, um Webseiten abzurufen und Web-Applikationen anzusteuern:

• Mehrere SSL-Zertifikate über eine einzige IP betreiben
• Den PHP-Interpreter switchen (z.B. Port 80 = PHP 5, Port 8080 = PHP 4)
• Den Webroot wechseln
• Allgemein die Webserver-Konfiguration switchen (z.B. zwischen Entwicklungs- und Live-Modus einer Web-Applikation umschalten)
• Mehrere Webserver gleichzeitig betreiben
• Prinzipiell eine andere Server-Applikation oder einen Webservice ansteuern
• Durch einen Reverse-Proxy einen Blackbox-Server in einer DMZ ansprechen

Okay, wer es gemerkt hat, wurde eigentlich in allen Fällen die Serverconfig geswitched. Ich wollte aber ja eigentlich auch nur die Vielzahl an Möglichkeiten aufzeigen, die es unter Umständen rechtfertigen, mit Port-basierten zu arbeiten.

Wie bereits erwähnt - ich finde Port-Angaben in der URL grundsätzlich hässlich. In den meisten Fällen kann man alles, was über Port-Basierte-VirtualHosts gelöst wird, auch mit Subdomains lösen. Im Falle eines SSL-Betriebes müsste natürlich unter Umständen auf eine separate IP-Adresse in Verbindung mit einem Zertifikat zurückgegriffen werden.

Aber auch dort gibt es die Möglichkeit mit kostenlosen selbst ausgestellten Zertifikaten zu arbeiten und eine zusätzliche IP ist im lokalen Netz auch schnell und kostenlos organisiert. Sogar eine einzige Netzwerkkarte kann mit verschiedenen IPs betrieben werden, falls kein weiterer freier Netzwerkport zur Verfügung steht.

Du stehst trotzdem auf “dreckige Spielchen” mit Ports? Sinn macht die Verwendung von unterschiedlichen Ports aus meiner Sicht vor allem auf Staging- oder Entwicklungs-Servern.

Aber auch um seine Applikation besonders abzusichern, kann man mit verschiedenen Ports oder Subdomains arbeiten. Sicherheit ergibt sich dadurch, das eine eventuelle Admin-Oberfläche nur auf solchen besonderen Vhosts zur Verfügung steht oder gleichzeitig noch eine IP-Sperre eingebaut ist.

Auch die Applikation kann mit Hilfe von $_SERVER["SERVER_PORT"] auf einen anderen Port reagieren, Deiner Phantasie sind keine Grenzen gesetzt - ob das dann schön oder praktisch ist, ist eine andere Frage ;)

Fazit

Mit portbasierten Vhosts sind schöne Spielereien möglich. Ich würde solche Dinge allerdings nur auf Entwicklungs- oder Stagingservern umsetzen. Maschinen im Livebetrieb freuen sich über die Verwendung von Subdomains.

Ähnliche Artikel:

1. SSH Server absichern: Port-Salat
2. Wissenswertes über SSL und HTTPS

Eigentlich müsste ich vor Kreativität und Innovationslust explodieren. Als Entwickler, als Gestalter, als Mensch. Schicken PHP Code schreiben. Elegante Menüs entwerfen. Morgens mit Élan aus dem Bett springen, beim Brötchen holen alten Omis über die Straße helfen, andere Menschen mit wahllosen Heldentaten beeindrucken. Hui. Wenn ich so drüber nachdenke, kann Kreativität ganz schön anstrengend sein.

Ich leg mich dann mal wieder ins Bett. Oder bin ich doch so motiviert, dass ich diesen Artikel weiterschreibe? Ja ich bin. Los gehts.

Woher also bloß Kreativität nehmen, wenn keine mehr da ist?

Mit der Kreativität ist es wie mit der Milch aus dem Beutel: Wenn keine Milch mehr rauskommt, ist sie leer. Wie beim Backpulver im Papiertütchen. Benzin im Tank. Okay, okay ich drifte ab. Festzustellen ist: Kreativität kann man sich nicht einfach im Supermarkt kaufen, wenn man gerade unkreativ ist. Eine unkreative, lustlose Phase ist so schlimm wie die Pest: Wenn man nix dagegen macht, wirds immer schlimmer. Sie geht nicht einfach vorbei. Ich wette, es sind schon Leute an Lustlosigkeit gestorben. Mist. Schon wieder die falsche Richtung.

Jetzt also mal meine medizinischen Kompetenzen bei Seite gelassen: Wo kriegt man Kreativität her, wenn man gerade welche braucht und keine hat?

Timo Off hat sich in seinem erstaunlich krativen Werk “Best Off” dazu ausführlich geäußert. Das Buch ist mittlerweile als kostenlose PDF Version erhältlich und schwankt zwischen Poesi, Wortspielereien von einem kreativen Akt zum nächsten. Er verpackt die Kreativitätssuche in dem schönen Wort “Ideenfindung”. Tatsächlich verbirgt sich dahinter wesentlich mehr.

Beruhigend kann er auf den letzten Seiten feststellen, das “die Möglichkeiten kreativen Lebens mit dem Tod enden. Nicht früher.” Na dann machen wir uns doch mal auf die Suche nach dem kreativen Leben: Und dafür möchte ich nochmal auf die Milch aus dem Beutel nebst Backpulver zurückkommen.

Für mich bedeutet kreativ sein, zu backen. Nach Rezept. Ich denke, jeder hat da sein eigenes Rezept, um gedanklich wieder auf die Sprünge zu kommen. Ich zeig’ Euch mal, wie ich das mache:

Der Basisteig

Die Grundlage einer guten Idee sind viele Teilideen in Summe. Beeindruckende und inspirierende Momente, die von aussen aufgesaugt und im Hirn abgespeichert werden. Das bedeutet: Die Umwelt aufmerksam betrachten. Lesen.

Ich habe jeden Tag einen Blick auf meine RSS Feeds. Schnappe manchmal nur Titel auf, lese ganze Artikel. Ich teile mit Euch ;) Die meisten Feeds, Blogs bzw. Sites werdet ihr sicherlich kennen. Die Reihenfolge hat übrigens nichts mit Favoriten oder besonderer Güte zu tun.

• Der Brettspiel-Blog: Ich liebe es, zu spielen, frische Infos gibts hier.
• Mandolux Dual-Screen Backgrounds: Immer wieder neue Wallpaper. Anspruchsvoll.
• Neuerdings, das Gadget Blog: Elektronische Spielsachen für den Herrn von heute.
• Photoshop Disasters: Immer für einen Lacher gut…
• Smashing Magazine: Vielseitige Infos rund ums Web und Gestaltung.
• Francesco Mugnai: Noch mehr Gestaltung

Aber auch Bücher und Zeitschriften sind mir wichtig. Neben dem ganzen digitalen Abklatsch, mit dem ich jeden Tag zu tun habe, freue ich mehr sehr über haptische Erlebnisse wie das Umblättern einer Buchseite aus Papier *freu* Eine kleine Auswahl:

• Wie man im Schach gewinnt: Klingt banal, ist es aber nicht.
• Ben & Jerry’s Homemade Ice Cream: Ein sehr amüsanter Einblick in die Welt des Speiseeises *schmatz* Echt lecker!
• Die Spielbox: Ein Magazin rund um Brett- und Kartenspiele.
• Der Web Design Index: Die besten Webseiten in Druckform

Alles schön verkneten

Jetzt muss der ganze Ideen-Teig im Kopf schön verknetet werden. Ach egal, ob schön oder nicht. Hauptsache es wird. Mürbe wird man am Tagesende sowieso - muss man aktiv kneten?

Ich behaupte: Nein. Das geht gar nicht. Ideenverknetung oder Ideenfindung (wie das die Profis nennen) kann man nicht provozieren. Das passiert lässig nebenbei. Wer es erzwingt, macht eigentlich direkt einen Griff ins Klo. Mann kennt das: Auf der intensiven Suche nach der Frau des Lebens begegnet sie einem einfach ums Verrecken nicht. Aber dann. Ganz plötzlich, unverhofft, einfach so, ist der Partner fürs Leben gefunden. Und man hat gar nicht damit gerechnet.

Faszinierend. Auch lässig sein lässt sich provozieren. Oh Verzeihung: Trainieren natürlich. Manche nennen es Yoga. Andere Muskelrelaxation. Ich nennen es Musik hören, sich an einen belebten Platz setzen und Leute beobachten, ein Getränk ganz bewusst zu trinken, jeden Geschmacksnerv spüren, laangsam eeiin- und aauusaaaaatmen, gaaaaanz ruhig, entspannt…

*schnarch* *schreckauf*

Hui, jetzt war ich von meinem Geschreibe so entspannt, das ich doch glatt eingeschlafen bin. *lach* Aber weiter. Spazieren gehen, die Umwelt beobachten. Nichts machen. Ein Konsolenspiel anfangen und nicht beenden. Einen Blogartikel schreiben, der nie fertig wird.

Ausschlafen. Oh, das Geheimrezept überhaupt. Die ganze Kreativität eines Menschen offenbart sich im Schlaf: Der Körper entspannt sich, Muskeln werden weich, Gedanken werden verarbeitet und einsortiert.

Aber noch mal zurück zum Menschen beobachten - es ist unglaublich witzig und gleichzeitig faszinierend zu sehen, wie unterschiedlich sich Menschen bewegen. Die Körpersprache: individuell. Der Klamotten-Mix: meist individuell und auch wenn von der Stange - die selbe Klamotte wirkt an jedem Menschen anders.

Ich amüsiere mich gerne über andere Menschen. Obwohl ich weiß, das ich auch ein Freak bin, über den sich andere amüsieren, kann ich dabei herrlich abschalten. Und weil ich mich aufs Beobachten nicht konzentrieren muss, hat mein Gehirn noch genügend Ressourcen, um ein Problem im Hintergrund zu bearbeiten oder einen neuen Zusammenhang plötzlich zu entdecken.

Auch die Natur gibt viel her. Nicht umsonst sind die meisten Erfindungen der Natur oder Lebewesen nachempfunden. Selten sind biologische Mechanismen durch Effizienz zu toppen.

Aber auch bestehende nicht-biologische Mechanismen können inspirieren: Die Hebelwirkung beim Flaschenöffner kann eine spontane Idee liefern. Ein Klappmechanismus an einer Tür ein lange vermisstes Bindeglied sein. Das Ablaufmuster eines Brettspieles die Lösung für ein ganz anderes Problem sein, das man mit sich herumträgt.

Schön ziehen lassen

Viele, die aktiv an einem Problem sitzen, versuchen sich von der Außenwelt zu isolieren, um sich ganz auf ein Problem zu konzentrieren: Treffen mit Freuden? Muss ausfallen. Ein spontanes Bierchen mit dem besten Kumpel? Auf keinen Fall. Ein Kinobesuch mit der Clique? Ne ne.

FALSCH! Ich verspreche Euch: Genau, wenn man das macht, was man eigentlich nicht machen sollte, kommen einem die besten Ideen. Man entspannt sich, lacht und genießt die Möglichkeit einfach mal anderen zuzuhören, statt dauernd in sich hinein.

Nutzt die Möglichkeit, Probleme mit anderen zu diskutieren, die nicht auf dem gleichen fachlichen Level sind und vielleicht gar kein Verständnis für Euer Problem haben. Warum? Klingt sinnlos? Na, ist doch klar: Wenn man sein Problem jemandem schildert, der keine Ahnung vom Thema hat, muss man es fantasievoll formulieren. Vielleicht veranschaulichen, vergleichen. Und schwups! Ist die Lösung da.

Ideen kriegen Kinder! Das einzige, das nicht weniger wird, wenn man es benutzt, ist Wissen. Das gilt es auszunutzen.

Rezeptbuch führen

Schreibe Ideen und Lösungen direkt auf, sonst sind sie weg. Ein Notizbuch im Nachttisch. Ein Moleskine in der Jackentasche. Ein Post-It am Bildschirm. Ein Schmierzettel im Schwimmbad. Alles ist möglich.

Ab in den Ofen

Ausprobieren ist alles. Oft stellt man bei einem Real-World-Versuch fest, das die Lösung nicht funktioniert oder irgendwas zum Finalisieren fehlt. Lass Dich nicht entmutigen! Mach weiter. Verfeinere Deine Idee. Forme Sie aus. Fang vielleicht noch mal von vorne an.

Vielleicht fehlt der Mut, eine waaghalsige Idee auszuprobieren. Aber es ist wie mit dem Mädel, das man nie angesprochen hat: Mein weiß einfach nicht, ob es geklappt hätte.

Außerdem kann ich Dir eines versichern: Fehlschläge sind meist die Grundpfeiler ein super Lösung. Vielleicht unmittelbar im Jetzt, vielleicht braucht die Idee noch einige Zeit zum Reifen und es wird ein paar Jahre später.

Alles ganz easy

Ideenfindung funktioniert von alleine. Das Gehirn braucht Dich dazu eigentlich nicht. Nur Impulse. Und die kannst Du ganz einfach beisteuern.

Lies ein Buch, trink Dein Lieblingsgetränk, lehne Dich zurück und höre für einen Moment mit dem Analysieren auf. Und

z z Z Z A C K K

sie wird Kommen: Die Inspiration. Die Idee, die Lösung.

Ähnliche Artikel:

1. Der ultimative Guide für Fehlerbeschreibungen

PHP nimmt es bei Wertvergleichen standardmäßig nicht so genau. Die Vergleichs-Operatoren gleich bzw. ungleich (== und !=, oh jetzt kratze ich wirklich an den Basics) sind zunächst ja nicht Typen beeindruckt. Weniger was Lederjacken-Träger angeht, als die Werte von Variablen.

Für ganz Genaue müssen da schon die Operatoren === (Identisch) und !== (Nicht identisch) herhalten. Mit welchen Operatoren man Variablen vergleichen sollte, ist wieder mal Geschmackssache. Ich halte das in der Regel wie folgt: Geht es um einen wichtigen Vergleich - eine Typ-Validierung in einer Setter-Methode beispielsweise - nutze ich die strengen Operatoren. Bei einer unkritischen Abfrage von Rückgabewerten (wie gesagt, sie muss unkritisch sein) bediene ich mich oft bei den Standard-Operatoren.

Und genau bei Rückgabewerten will ich mich einhaken. Es geht um das Thema Lesbarkeit. Wir holen uns mal schnell ein Objekt aus einer Fabrik:

$objekt= $fabrik->neueInstanz();

Nehmen wir mal an, unserer Fabrik gelingt es nicht ein neues Objekt produzieren zu können. Wer übernimmt die Fehlerbehandlung und wirft z.B. eine Exception? Die Fabrik selbst? Denkbar. Meiner Meinung nach (ich denke, das ist fallabhängig zu betrachten) sollten Fabriken recht dumm und simpel sein und sich auf das konzentrieren, was sie können: Neue ObjektInstanzen. Wenn überhaupt sollte ein Exception geschmissen werden.

Was wenn nicht? Was, wenn man auf einen Rückgabewert wie null testen möchte? Man könnte schreiben:

if($objekt == null) { ... }

oder

if($objekt == false) { ... }

Letzteres funktioniert, weil null im Normalfall als false interpretiert wird. Hm. Was noch? Als false wird sonst noch 0 (numerische Null) gewertet. Zahlen größer oder kleiner Null werden als true gewertet, ebenfalls Variablen, die mit gültigen Objekten besetzt sind.

Einer meiner Lieblings-Operatoren ist übrigens NOT. Man könnte also auch schreiben:

if(!$objekt) { ... }

Ach, wie herrlich kurz und präzise das ist. Und zugleich super lesbar - Ich sprech es mal laut nach:

“If not objekt then …”

Dagegen klingen die ausgesprochenen ersten beiden Versuche richtig sperrig: Also ich liebe das. Kurz und knackig - aber wer die Lesbarkeit noch weiter verbessern möchte, kann auch auf eine Wrapper-Variable zurückgreifen:

$objekt_nicht_verfuegbar= (!$objekt);
if($objekt_nicht_verfuegbar) { ... }

Auch sehr gut. Der Vollständigkeit will ich noch erwähnen, das man das natürlich auch mit einer Exception abfangen kann. Was besser ist, muss jeder Entwickler selbst entscheiden, wenn er vor dem Problem sitzt - denn Exceptions müssen nicht zwangsweise sicherer sein als Bedingungs-Abfragen.

Ähnliche Artikel:

1. Lesbaren Code schreiben
2. Die Mutter aller Objekte
3. Hook- und Callback-Funktionen (Teil 3)

Immer wieder passiert es, das ich mit Kollegen diskutieren muss, wie nun SSL funktioniert und was man darüber wissen sollte, wenn man es konfiguriert. Selbst eingefleischte Entwicker und Adminprofis tun sich manchmal bei eigentlich trivialen Dingen schwer.

Herzlich Willkommen also zur Nachhilfestunde zum Thema SSL und HTTPS. (Du musst ja keinem davon erzählen, das Du diesen Artikel gelesen hast ;). Und man weiss ja nie, vielleicht erfährt man ja doch was Neues.

— Sendung mit der Maus AN —

Buh, sticknormales HTTP kann ja jeder.

Ja stimmt. Aber wofür braucht man denn überhaupt HTTPS, bzw. SSL? Naja das Grundübel ist eingentlich, das HTTP grundsätzlich unverschlüsselt übertragen wird: Jeder kann mitlesen. Ein paar Menschen hat abgehärtet, das es bei E-Mail und FTP auch so ist; ein paar andere fanden das Scheisse und haben sich überlegt, das was Sicheres her muss.

Um zu beweisen, das man einen sicheren Service anbietet, gibt es Zertifikate. Wenn man mit einem Texteditor reinguckt, sehen die Dinger verschlüsselt aus. Und sind es auch. Damit gewährleistet ist, das es sich um ein echtes Zertifikat handel (Ja es gibt auch unechte), werden die Teile von einer Zertifizierungsstelle ausgestellt (CA), die selbst wieder zertifiziert ist (CA-Zertifikat). Damit nicht jedes Zertifikat installiert werden muss, werden die Zertifikate der größten Zertifizierungsstellen schon im Browser vorinstalliert ausgeliefert.

Ein eigenes Zertifikat kostet mindestens 80-100 Euro pro Jahr und muss verlängert werden. Bei einem niedrigeren Preis sollte man die Dienstleitung bzw. Zertifizierungsstelle mal kritischer beäugen. Das Zertifikat (und damit die Verschlüsselung) ist um so sicherer, je höher die Bit-Stärke ist, mit der verschlüsselt wird. Beispiel: Ein 128 Bit verschlüsseltes Zertifikat ist nicht so sicher wie eines, das mit 256 Bit verschlüsselt wurde. Genauer will ich da jetzt nicht drauf eingehen, die Tatsache zählt.

Das Prinzip ist eigentlich ganz einfach: Man speichert das eigene Zertifikat auf dem eigenen Server. Bei einer SSL-Anfrage über HTTPS wird das Zertifikat ausgeliefert und vom Browser auf Echtheit geprüft. Wenn alles in Ordnung geht, steht die sichere Verbindung.

— Sendung mit der Maus AUS —

Die Tücken stecken allerdings wie immer im Detail:

• Ein SSL-Zertifikat ist immer an einen Hostnamen gebunden. www.phpblogger.net ist dabei ein anderer Hostname als phpblogger.net (ohne www.) - man sollte sich also vorher gut überlegen, für welchen Hostnamen man ein Zertifikat benötigt. Es gibt auch Wildcard-Zertifikate, die verschiedene Subdomains zulassen. Wildcard-Zertifikate sind allerdings recht teuer.
• Pro Zertifikat wird eine IP-Adresse benötigt. Für ein Zertifikat benötigt man eine IP-Adresse (die auch mit nicht SSL-geschützten Seiten geteilt werden kann), für jedes weitere Zertifikat eine weitere IP-Adresse. Warum? Weil der SSL-Handshake auf IP-Basis stattfindet. Die Domain wird via DNS zur IP aufgelöst und dort wird direkt auf Port 443 der Handshake gestartet - ein Hostname wird dabei nicht übermittelt. Technisch ist es also nicht möglich mehrere Zertifikate unter einer IP laufen zu lassen, weil der Webserver nicht ermitteln kann, welches Zertifikat zu welcher Domain gehört.
• Um ein Zertifikat zu beantragen benötigt man einen Certificate Signing Request (CSR). Diese Datei wird auf dem Webserver generiert, der das SSL Zertifikat einsetzen möchte. Im Zuge der Generierung wird in der Regel gleich noch ein Key mit erzeugt. Der CSR wird an die ausstellende Behörde (CA) übermittelt, die daraus dann das Zertifikat (CRT) generiert.
• Wichtig: Die Key-Datei muss geheim bleiben und wird nicht an die CA übermittelt. SSL verwendet eine asynchrone Verschlüsselung. Die Key-Datei ist der private Key, während das Zertifikat der public Key ist, der für die Entschlüsselung (und umgekehrt) vom Browser verwendet wird.
• Beim Erstellen der CSR-Datei kann man ein Passwort (Passphrase) angeben - das muss dann jedes Mal beim Start des Webservers eingegeben werden. Mann muss aber nicht und spart sich dann den Act, ein Post-It an den Monitor zu kleben. *zwinker* Ist natürlich ne schlechte Idee.
• Zertifikat und Key muss man bei der SSL-Konfiguration angeben. Das CSR jedoch nicht. Je nach Server-Distribution kann es sein, das auch das CA-Zertifikat besorgt werden muss. Das bekommt man dann bei der ausstellenden Zertifizierungsstelle zum Download.
• Die Domains muss via DNS auf die selbe IP aufgelöst werden, unter der das Zertifikat ausgeliefert wird. Eigentlich eine Selbstverständlichkeit, wird aber trotzdem oft vergessen. Der Fehler, der dadurch unter anderem entstehen kann, heißt “(Fehlercode: ssl_error_rx_record_too_long)”
• Die Zertifikate sind Textdateien. Meist bekommt man die Zertifikate von der Zertifizierungsstelle oft inline in einer Textmail zugesendet. Um eine CRT-Datei daraus zu machen, erstellt man eine leere ASCII Text-Datei, kopiert alles von —–BEGIN CERTIFICATE—– bis —–END CERTIFICATE—– (die beiden BEGIN bzw. END Zeilen werden mitkopiert) und fügt das ganze in die leere Textdatei ein. Speichern, Hochladen fertig!
• Root bzw. CA-Zertifikate können ablaufen. Das war z.B. bei Verisign im Jahr 2004 mal so. Ich kann mich noch bestens daran erinnern: Dann wird das eigene SSL Zertifikat für ungültig erklärt, weil die Beweiskette durch das abgelaufene CA-Zertifikat unterbrochen wurde. Die Zertifikatshierarchie kann man sich übrigens in jedem Browser angucken. Im Firefox unter “Seiteninformationen” / “Sicherheit” / “Zertifikat anzeigen” / “Details”. Das CA-Zertifikat muss zum Bugfix auf dem Server gegen ein Neues ausgetauscht werden.

Zum Schluss noch ein paar nützliche Code-Schnipsel und Links, wenn man mit SSL-Zertifikaten arbeiten will oder muss:

Das Generieren eines CSR (Certificate Signing Request) mit OpenSSL:

openssl req -new -keyout my-domain_de.key -out my-domain_de.csr

Die SSL-Konfiguration testen mit dem s_client (gehört zu OpenSSL):

openssl s_client -connect my-domain_de:443

CA- bzw. Root-Zertifikate gibts hier:

z.B. von VeriSign, thawte (bekannt durch die günstigen 1-2-3 Zertifikate), GeoTrust und GlobalSign.

Auf dem Server vorinstallierte (CA-)Zertifikate:

• Debian: /etc/ssl/certs
• Fedora bzw. RedHat: /etc/httpd/conf/ssl.*
• SuSE / SLES: /etc/apache2/ssl.*

SSL-Pflichtlektüre in gedruckter Form:

Wer einen Apache mit SSL konfigurieren möchte, dem sei das Apache Kochbuch. empfohlen. Ohnehin eine Pflichtlektüre für Admins, die viel mit dem Apache machen (möchten).

Wer gerne seine eigene Zertifizierungsstelle wäre, erfährt bei Werthmöller (wer das auch immer ist) recht anschaulich, wie es funktioniert.

Ähnliche Artikel:

1. Port-Fetischismus oder dirty Games mit Ports

Fangen wir mal an - mit dem Thema Performance. Ein alter Hut sozusagen. Aber welche Applikation benötigt nicht mal den einen oder andren Performance-Boost? Die alten Hasen unter Euch freuen sich bestimmt über eine kleine Auffrischung mit Hilfe der Tipps, PHP-Anfänger wahrscheinlich allein über die Existenz derselben.

Über die Zend Developer Zone (engl.) bin ich auf den Beitrag von Stas Malyshev aufmerksam geworden. Bei seinem Beitrag mit dem schicken Titel “more on PHP performance” versucht er in einer Art Übersicht aufzuzeigen, worauf man achten kann bzw. sollte, wenn man seiner Applikation etwas Gutes in Form von Performance tun möchte. Wirklich ausführlich ist das natürlich nicht, dafür spricht er vielfältige Themen an.

Ich möchte Euch vor allem auf folgende Dinge aufmerksam machen:

• Arbeitet mit Caches. Alles was sich nicht ständig verändert, will gecacht werden. Es schreit förmlich nach Caching! Erweitert Eure Caches durch sinnvolle Aktualisierungs-Routinen. Ein gecachtes Objekt ändert sich? Dann sollte der Controller oder der Applikationsteil, der die Änderung veranlasst, auch den Cache aktualisieren oder neu berechnen lassen.
• Optimiert Eure Datenhaltung und vor allem den Zugriff darauf. Versucht, nicht nur alles in 1000 Objekte zu kapseln, sondern Zugriffsmethoden logisch zu gruppieren. Dann benötigt ihr weniger Instanzen von Zugriffsobjekten. Werden immer wieder die selben Daten abgefragt? Auch dann kann man die Zugriffsroutinen mit Caches ausstatten. Vom billigen Query-Caching bis hin zu ganzen Cache-Tabellen kann alles mögliche Sinn machen.
• Sortiert PHP-Extensions aus. Gerade auf Produktivmaschinen, die nicht mehr als 1, 2 Projekte hosten, werden oft nicht alle Extensions benötigt. Deaktiviert alles, was ihr nicht braucht.
• Reduziert die Dateisystemaufrufe. Das kann vor allem bei virtualisierten Maschinen einen extremen Performance-Schub bringen… Wenn ihr bestimmte Daten oft braucht, solltet ihr mal über den Einsatz von memcached nachdenken. Memcached speichert Daten direkt im Arbeitsspeicher - schneller geht’s oft nicht.

Der zweite Part ist die Produktivität. Kann man immer verbessern. Das ist schön und vor allem schön vielseitig. Mit 2 Monitoren arbeitet man oft richtig schön produktiv. Aber vor allem, wenn man sich auf das konzentrieren kann, was man gerade tut. Ordnung auf dem Schreibtisch kann da Wunder wirken. Mein Schreibtisch quillt gerade wieder über vor Kabelsalat von Lade- und USB-Geräten. Unterm Schreibtisch häufen sich auch wieder die Ansammlungen von Kabelstrecken. Aber was könnte man dagegen tun?

Ein Besuch bei Bluelounge gibt Aufschluss: Neben einem sündhaft teuren Tisch gibts dort massenweise Produkte gegen Kabelsalat. Ich muss zugeben, ich war fasziniert von den Bluelounge-Produkten und habe gleich mal eingekauft:

• Cable-Drop Halter. Damit fallen keine Kabel mehr von der Tischkaten. Die Ohrstöpsel schnell mal am Monitor eingehängt? Kein Problem. Leitungen unterm Tisch verlegen? Hält.
• Eine Cable-Box. Steckdosenleisten sind Pfui! die Dinger sehen hässlich aus und mit Ordnung hat das Steckerdurcheinander meist nix zu tun. Also ab damit in die Cable-Box!
• The Sanctuary: Der heilige Platz für Gadgets. Ein Multiladegerät als Ablage-Platte getarnt. Enthalten sind für die gängigsten Handy- und Gadget-Adapterkabel. Damit landen alle Gadgets übersichtlich an einem Platz und werden gleichzeitig ohne große Kabelaction aufgeladen.

Guckt Euch auf den Bluelounge-Seiten mal in aller Ruhe um. Da gibts auch vorher-nachher-Bildchen zu bestaunen, damit man gleich sieht, was man sich Gutes tut.

Jetzt muss ich mir nur noch was gegen den Blätterwust einfallen lassen, der meinen Schreibtisch bedeckt. Ablagefächer sind doch viel zu offensichtlich.

Ähnliche Artikel:

1. Objektorientierung vs. Performance
2. MySql Performance steigern
3. Performance durch PHP Benchmarks

svn st|grep ^?|sed s/?//|xargs svn add $1

Die ganz Faulen unter uns machen es sich sogar noch einfacher mit einem Alias:

alias svn-add-all-new-files=
'svn st|grep ^?|sed s/?//|xargs svn add $1'

Funktioniert prächtig

Ähnliche Artikel:

1. Argument list too long

Das war hoffentlich nur die Ausgeburt meine grenzenlosen Fantasie, denn wer veröffentlicht schon freiwillig Details seiner Klositzung in aller Öffentlichkeit? Puh, das wäre echt dumm und ekelhaft. Aber ich bin mir sicher, einer hats schon mal getwittert *lach*

Aber ich tippe darauf, das die breite Masse genau diese Themen von Twitterern erwartet und/oder hat. Zugegeben, die Möglichkeit, kostenlose RSS-SMS im Internet via Rechner und mobilen Endgeräten zu verschicken, ist für jüngere PC (okay auch Mac)-Besitzer verlockend.

Ich trete jetzt mal einen Schritt zurück und schaue mir Twitter aus einiger Entfernung und möglichst neutral an, um Features und ggf. Schwachstellen und dieser Technik zu beleuchten. Und Du bist eingeladen! Scheinbar ist es ja ansteckend, denn wer sich das Wachstum von Twitter auschaut, sollte beeindruckt sein. 1000% Wachstum würden sich viele Web-Applikationen wünschen - da hinkt sogar Facebook hinterher…

Jeder Hype in Ehren, aber was ist nun wirklich dran?

Die Grundlagen

Schon mal getwittert? Dann kannst Du diesen Abschnitt überspringen ;)

Twitter wird mit allerhand verglichen: Mit kurzen RSS-Feeds oder zum Beispiel SMS. In der Tat kann man zusammenfassen feststellen: Twitter ist ein Mix der beiden Technologien. Die Textmitteilungen, die man Absetzen kann, sind auf 140 Zeichen beschränkt - meist verlinken diese über einen Kurz-URL Service auf eine ausführliche Nachricht im Web. Diese Beschränkung ist künstlich und gewollt.

Zusätzlich ist eine Community-Funktion verbaut: Twitter-Mitglieder können unter einander Tweets (also die Mitteilungen eines Users) abbonieren. Bei Twitter heisst das “Follow” (engl. für “folgen”). Alle Tweets (eigene und jene, denen man folgt), werden zu einem Gesamt-Tweet zusammen gefasst.

Über Clients im Web oder auf dem eigenen Rechner kann man seinen Tweet (im Prinzip seine eigene Newszusammenstellung) abrufen. Der wird aktualisert, sobald man selbst oder jemand dem man folgt, etwas twittert. Die Darstellungsweise des getwitterten Inhaltes ist von Client zu Client verschieden. Manche bereiten die Inhalt analog zu einem Instant-Messenger in Gesprächsform auf (das Antworten auf Tweets ist durch eine bestimmte Syntax auch möglich) oder bilden den Twitter-Inhalt einfach in Protokollform ab. Natürlich gibt es auch Multiprotokoll-Clients, die mehrere Protokolle und Communities wie Facebook im Blick haben.

Ähnlich wie bei RSS-Feeds funktioniert auch der Abruf von Tweets via HTTP. Das Applikationsprotokoll ist offen und über eine API von verschiedenen Programmiersprachen aus nutzbar.

Binärdateien werden übrigens wie bei RSS-Feeds nicht direkt übertragen, sondern können lediglich verlinkt werden.

Sinnlosigkeit vs. Nutzen

Die Entwickler von Twitter fordern tatsächlich Ihre Nutzer auf: “Sagt uns, was Ihr gerade macht…” Natürlich hat die Gruppe von Teens, Kids und verspielten sonstigen Usern diesen Ansatz dankbar aufgegriffen und unmissverständlich begonnen, ihr Privatleben schriftlich auf Twitter zu dokumentieren. In aller Öffentlichkeit, versteht sich. Die Party-Pics liegen bei StudiVZ und Wer-kenn-wen (bewusst nicht verlinkt), der Lebenslauf bei Xing (bewusst verlinkt), die beliebtesten Freizeitziele bei Qype (ätsch, auch verlinkt).

Über Communities hatte ich mich ja bereits vor einem Jahr schon mal ausgelassen… Mir ist nach wie vor unverständlich, wieso viele ihr komplettes Privatleben in die Öffentlichkeit tranferrieren - freiwillig.

Wie kann man Twitter aber sonst noch verstehen? Als einfache, schnelle Methode, Nachrichten zu verbreiten. Ein gutes Beispiel sind TweetBots. TweetBots werden z.B. dazu verwendet, Informationen im Internet zusammeln und als Tweet rauszublasen.

Ich habe gleich 3 TweetBots abboniert:

• Neuigkeiten aus meiner Stadt von Qype
• Neuigkeiten aus der lokalen Presse
• Infos lokaler Gastronomien

Gepaart mit einem schlanken und unauffälligen Client (Pwitter; Das Vogelei hängt nur als Menulet neben meiner Mac-Uhr und postet über Growl) weiß ich also über alles aus meiner Stadt bescheid. Informationen, die mich nicht interessieren, sehe ich, aber ignoriere sie.

Ich nutze Twitter also als Schnell-RSS - für kurze Informationen, die mir kein RSS-Feed-Abo wert sind. Ausserdem kann man mit Twitter Newsletter oder Notification Mails ersetzen. Applikationen können also Informationen automatisiert in einen Tweet schieben.

Natürlich ist wichtig, das man sich bewusst ist, das alle Informationen auf Twitter gefunden und von jedem gelesen werden können. Zwar können viele Clients Direkt-Antworten, die nicht an den Leser direkt sind ausblenden, geladen und gespeichert werden sie jedoch trotzdem.

Praktische Anwendungfälle

Für Applikationen bietet sich Twitter an, um unsensible Daten an Clients zu posten. Da muss man aber mit offenen Augen durch die Welt gehen: Wer z.B. seine Serverupdates quer durch die halbe Welt twittert, verrät Angreifern schnell ein mögliches Ziel und Schwachstellen wie nicht installierte Pakete gleich mit dazu.

Gerade bei Applikationen sollte man vorsichtig sein: Was auf den ersten Blick sinnvoll erscheint, muss nicht unbedingt jeden erfreuen. Vielleicht möchte ja ein Benutzer der Applikation gar nicht, das seine CMS-Internen Nachrichten in Twitter gepostet werden? Kann er das Feature dann abschalten?

Twitter als kommerzielle PR-Maschine funktioniert nur so lange, bis Nutzer mit Informationen zugeschüttet werden und die Übersichtlichkeit verlieren. Immerhin hat man die Möglichkeit, gezielt auswählen zu können, was interessant ist. Als Mechanimus für private PR taugt Twitter grundsätzlich nur als Sprungbrett. Gute PR ist von schlechter PR so gut trennbar, wie eine Apfelsortet von der Nächsten = eine Geschmacksfrage und deshalb untrennbar.

Fazit

Twitter ist eine feine Übertragungsmöglichkeit unsensibler Daten und Informationen und eine prima Alternative bzw. Ergänzung zu RSS-Feeds und Newslettern.

Ein großes Problem für eine professionelle Nutzung sehe ich in der Mitlesbarkeit von Tweets. Man kann zwar geschlossene Gruppen definieren (Die Folgenden muss man zunächst akzeptieren) - trotzdem sollte man sich bewusst sein, das alle Informationen nicht auf dem eigenen Server liegen (wie etwa RSS-Feeds), sondern bei einem Provider gespeichert sind, auf dessen Wohlwollen man angewiesen ist.

Wenn man wissen will, welche Perücke sich der Nachbar heute aufgesetzt hat und welche Farbe das Höschen von der Dame gegenüber hat, KANN das via Twitter erfahren. MUSS aber nicht - Gezwungen wird nämlich keiner.

Ich nutze Twitter gerne: Die Tweets denen ich folgen möchte, suche ich sorgsam aus. So, dass es nicht zu viele werden. Im Gegenzug habe ich Newsletter abbestellt und RSS Feed aussortiert - durch meine schlanken und unauffälligen Twitter-Client kann ich Uninteressantes vorbeiziehen lassen und beachte nur für mich wesentliche Mitteilungen.

Übrigens: Die 140 Zeichen empfinge ich als angenehm übersichtlich. Wer nur wenige Zeichen zum Texten zur Verfügung hat, macht sich um so mehr Gedanken über den Inhalt. So kann ich schon auf einen Blick einschätzen, ob eine Information für mich wirklich wichtig ist.

Alles nix neues? Genau - obwohl jeder weiß, was Komfort ist, werden viel zu wenig Websites komfortabel gestaltet oder mit schlanken, schnellen und vor allem komfortabelen Funktionen ausgestattet. Schnell werden feine Funktionen als Luxus deklariert und ins dunkle Entwickler-Kämmerlein eingesperrt: Die Usability leidet.

Eine Möglichkeit, seinen Benutzern die Usability zu erleichten, kann bedeuten, Events aus einem Terminkalender downloadbar zu machen. So ziemlich jedes aktive Unternehmen, das sich zeitgemäß im Internet präsentiert, stellt seinen Benutzern eine Terminliste bereit.

Was könnte man dort Sinnvolles reinpacken?

• Messetermine mit Standposition
• Termine von Weiterbildungsseminaren
• Sonstige Events / Veranstaltungen
• Happy-Hours (z.B. bei Gastronomien)
• Betriebsferien

Jede beliebige Newsliste mit einem downloadbaren Event auszustatten, wäre sicherlich etwas übertrieben. Mal kurz überlegen schadet hier also nicht.

Welches Format wäre wohl das Richtige? Okay, wer kurz in den Titel schaut, hat es schnell raus - iCal wäre das Format der Wahl, wenn es um downloadbare Dateien gehen soll. So ziemlich jeder Kalender kann es (Outlook, iCal, Gmail und viele weitere) - gute Voraussetzungen also, oder?

Prinzipiell gibt es zwei Möglichkeiten:

1. Man exportiert eine statische Datei aus seinem Kalender und verlinkt sie mit dem Event auf der Website oder
2. Man generiert aus seiner CMS-Datenbank eben mal schnell eine iCal-Datei.

Auch hier hilft der Titel weiter ;) Wir schauen uns mal einen Generator für PHP an: die Klasse iCalcreator hilft uns weiter. Die Webseite sieht zwar ziemlich beschissen aus und die Dokumentation ist auch etwas spärlich - trotzdem eröffnet uns das Tool viele Möglichkeiten. Denn es ist ziemlich flexibel, was die Ausgabe und Formatierung angeht.

Mit einigen wenigen Zeilen hat man das Objekt initialisiert:

$v = new vcalendar();
$v->setConfig('unique_id', 'phpblogger.net');
$v->setProperty('method', 'PUBLISH' );

Neue Events werden auch ziemlich easy erzeugt:

$vevent = new vevent();
$vevent->setProperty('DTSTART;VALUE=DATE', date("Ymd", $ts));
$vevent->setProperty('DTEND;VALUE=DATE', date("Ymd", $ts));
$vevent->setProperty('SUMMARY', $title);

Mit…

$v->setComponent($vevent);

…wird der Decorator bestückt und via…

$v->returnCalendar();

…an den Browser weitergeleitet. Das obige Beispiel zeigt gleich, wie man einen mehrtägigen Event ohne Uhrzeit generiert (Was im Howto der Klasse leider fehlt).

Natürlich sind auch Events möglich, die nur wenige Stunden oder Minuten dauern, Wiederholungen aller Art und ganze Sammelkalender (Wer mehr als einen Termin in eine Kalenderdatei packen möchte.

Wer Applikationen baut, kann sicher jede Menge Anwendungsfälle entdecken, den generierte iCal-Files lassen sich auch an Mails anhängen oder twittern.

Ähnliche Artikel:

1. Zufalls-Passworte zu generieren
2. jQuery Update
3. RSS Feeds mit PHP generieren

Es handelt sich um die PHP-Funktion “ucwords“: Die soll (eigentlich) in einzelnen Worten in einem String den Anfangsbuchstaben in Grossbuchstaben und alle restlichen Buchstaben in Kleinbuchstaben umwandeln. Funktioniert prima, so lange es sich um einen String in Kleinbuchstaben handelt. Wer einen String mit Grossbuchstaben übergibt, wird enttäuscht: Nix passiert.

Das gleiche übrigens bei “ucfirst“. Dieses Verhalten ist zwar in einem Beispiel dokumentiert, aber nicht begründet. Wer macht so eine Scheisse bitte? Selbst wenn es einen Grund gibt, solche impliziten Verhaltensweisen zu implementieren, sollten Sie aus dem Namen der Funktion hervorgehen oder mit einem Flag deaktivierbar sein.

Also nur so als Tipp: Wenn eine Funktion etwas macht, was nicht direkt aus ihrem Namen hervorgeht, sollte

• entweder die Funktion umbenannt werden,
• um ein Flag zum Deaktivieren erweitert werden,
• oder am Besten: so umgebaut werden, das sie das tut, was man von ihr erwartet…

Achso: Mit Unit-Tests wäre das nicht passiert ;)

Ähnliche Artikel:

1. Aufwärtkompatibel zu PHP 6