Monatsarchive: August 2014

Was man alles wissen muss…

Vor kurzem ist mir erstmals aufgefallen, mit welchen Technologien, Sprachen und Konfigurationen man sich als Webentwickler eigentlich (grundlegend) auskennen sollte. Die Liste ist wirklich lang geworden – und ich bin mir sicher, dass sie nichtmal vollständig ist. Je länger man nachdenkt, desto mehr fällt einem einfach ein.

Basics

  • Dateiformate / Encodings

Sprachen / Formate

  • PHP + Extensions (PEAR, PECL, …)
  • (demnächst Hack)
  • JavaScript (jQuery, Prototype, CoffeeScript, nodejs, …)
  • CSS (SCSS, LESS, Media Queries…)
  • HTML 4 & 5
  • XML (XSLT, XSD, xpath)
  • JSON
  • CSV
  • (evtl. noch ruby, perl, python)

Frameworks

  • Zend (2)
  • Symfony 2
  • Smarty, Twig
  • phpUnit
  • Behat

Entwicklungstools

  • git
  • phpStorm
  • docker
  • SVN
  • composer / phing / bower
  • modman
  • grunt / gulp
  • vagrant
  • ci (travis ci, …)
  • node / npm
  • brew
  • Selenium

Protokolle

  • HTTP / HTTPS (get, post, put, head, XHR, Ajax)
  • SSL / TLS
  • TCP/IP
  • POP / IMAP / SMTP
  • FTP / SFTP / SCP
  • SSH

Server & Tools

  • bash basics
  • vi / nano
  • apt
  • Berechtigungen
  • Apache (Virtual hosts, htaccess, …) / nginx / HHVM
  • Netzwerke (Klassen, Subnetze, Ports, Routing, VPN, …)
  • SSH (inkl. key management RSA / DSA) / known_hosts / authorized_keys
  • Postfix
  • mysql / mysqldump
  • Remote Desktop / Teamviewer / VNC / …

Datenbanken & Tools

  • mySQL, MSSQL, Oracle (Tabellen, Constraints, Trigger, …)
  • elasticsearch
  • mongoDB
  • postgresql
  • phpMyAdmin

Natürlich kann man nicht auf jedem Gebiet alles können. Aber man sollte doch irgendwie jedes Thema einordnen können und grundlegend wissen worum es geht. Die (in meinen Augen) weniger wichtigen Themen habe ich kursiv gekennzeichnet. Ich habe ganz sicher noch viel vergessen.

Anmerkungen gerne in den Kommentaren.

phpStorm: Standardeinstellungen für Projekte

Ich habe immer wieder das Problem, dass ich für jedes Projekt die selben nervigen Einstellungen mache. Da wären zum Beispiel:

  • xDebug richtig konfigurieren
  • VCS root errors deaktivieren
  • Pfade zu Composer und Phing pflegen
  • JSLint und JSHint konfigurieren
  • Eventuell SASS und LESS File Watcher konfigurieren
  • Magicento einrichten

All das macht man immer und immer wieder. Abhilfe schaffen die Default Settings von phpStorm. Dazu öffnet man ein beliebiges Projekt und geht dann durch das Menu nach „File -> Default Settings…“. In dem sich öffnenden Dialog kann man nun alle Einstellungen vornehmen, welche man für zukünftige Projekte als Standard haben möchte.

phpcs: Code-Sniffer für PHP

Gerade wenn man in größeren Projekten arbeitet, müssen sich Menschen an Standards halten, da ansonsten Chaos entsteht. Ein Standard wäre hier zum Beispiel PSR (ich berichtete). Aber wie stellt man nun sicher, dass man sich auch immer daran hält? Die Antwort lautet hier: phpcs.

Sofern man seine Entwicklungsumgebung korrekt eingerichtet hat, geht die Installation recht einfach von der Hand:

Falls man seine Path-Variable nun richtig konfiguriert hat, steht einem der Befehl nun überall zur Verfügung. Soweit, so gut.

phpcs und phpStorm

Jetzt könnte man natürlich immer alle Befehlt per Hand ausführen. Da das aber nervt, nutzt man seine geliebte IDE dafür. Dazu öffnet man die Projekt-Settings eines beliebigen Projektes. Hier findet man in den Projekteinstellungen unter PHP den Punkt „Code-Sniffer“ (oder einfach die Suche bemühen). Dort gibt man nun einfach den absoluten Pfad zu phpcs an und klickt „validate“ um die Einstellungen zu prüfen. Sieht man die Ausgabe der Versionsnummer, läuft alles.

Das macht das Ganze nun aber noch nicht sonderlich spektakulär. Als nächstes öffnet man in den Projekteinstellungen den Punkt „Inspections“ und sucht ebenfalls nach „Code Sniffer“. Hier hakt man den entsprechenden Menu-Punkt an.

phpStorm-phpcs-Inspections

Danach wählt man, etwas weiter unten, den Coding-Standard aus. Falls hier nur „Custom“ angeboten wird, muss man einmal den Aktualisieren-Button betätigen. Danach kann man sich zwischen vielen Standards entscheiden. Meine Wahl fällt hier auf PSR2. Danach bekommt man (je nach eingestelltem Error-Level), die Probleme farbig in den Dateien präsentiert. Das sieht dann z.B. so aus:

phpStorm-phpcs

Weitere Einstellungen

Damit man sich das Leben etwas leichter macht, kann man natürlich noch in den Projekt-Einstellungen den entsprechenden Code-Style für PHP pflegen. Mit einem „Reformat Code“ ist man dann auf Wunsch schon PSR-Konform. Um das Ganze dann immer auszuführen, kann man noch im Commit-Dialog den Haken bei „Reformat Code“ setzen. Dann kann man unterwegs soviel vergessen wie man möchte – vorm Commit wird alles in PSR2 gerückt.

phpStorm-reformatCode

Herzlichen Glückwunsch – ab jetzt wird immer alles korrekt abgeliefert. Ohne Ausnahmen!

PHP: Coding Style Guides & Standards

Wer kennt das nicht? Man öffnet fremden Quellcode und alles fühlt sich unschön an – die Klammern sind ganz wo anders, plötzlich schleichen sich Leerzeichen wo ein, wo man selbst keine macht, die Parameter sind anders aufgeführt, oder zwischen den Funktionen ist komisch viel Platz.

Spätestens wenn man gemeinsam an Projekten arbeitet, ist es unglaublich sinnvoll, wenn man sich auf deinen Coding-Standard einigt. Für genau dieses Problem wurde der „PHP Specification Request“ (kurz PSR) ins Leben gerufen. Hier wird sehr genau festgehalten, wie man zu Entwickeln hat. Also nicht nur, wo Klammern gesetzt werden etc., sondern beispielsweise auch:

  • welches Encoding die Dateien aufzuweisen haben
  • wie viele Klassen pro Datei erlaubt sind
  • dass keine Short-Open-Tags genutzt werden dürfen
  • wie man Namespaces zu verwenden hat
  • wie das Dateisystem / die Ordnerstruktur auszusehen hat
  • wie Methoden und Attribute benannt werden dürfen

und vieles mehr. Aus meiner Sicht sollte sich jeder Entwickler einmal diese Standards durchlesen. Natürlich hat man sich eventuell über Jahre schon seine Ticks angesammelt und es fällt schwer sich umzugewöhnen. Das macht aber in jedem Fall Sinn. Immerhin folgt jedes größere Framework diesem Standard und somit fällt es auch viel einfacher, sich in bestehende Frameworks einzulesen und zu orientieren.

Was aber noch viel wichtiger ist: Andere Menschen sind nicht genervt von eurem Code. Dank phpStorm und anderen Tools ist es zwar nur eine Tastenkombination, welche mich vom einhalten des Codingstandards trennt, aber spätestens wenn jemand an eurem GitHub-Projekt mitarbeiten möchte, wird hier jemand entweder genervt sein, oder aber ein riesen Commit mit der Message „Reformat Code“ pushen.

Der PSR ist dabei in mehrere Teile gegliedert:

Also, nicht länger drücken, sondern lesen und anwenden. Und vergrabt eure bisherigen Erfindungen. Bitte.

Mac OS X: Die eingebaute Diktierfunktion nutzen

Wer etwas schreibfaul ist, für den sind Diktierfunktionen sicherlich der beste Freund. Auch ich hatte früher (noch zu Windows-Zeiten) einmal eine der bekanntesten Softwarelösungen für diese Aufgabe im Einsatz, von welcher sicher jeder schon einmal gehört hat: „Dragon naturally speaking„.

Seit Mac OS X 10.9 ist die Diktierfunktion, welche man schon aus iOS kannte, auch auf dem Mac verfügbar. Diese kann in den Systemeinstellungen unter „Diktieren und Sprache“ aktiviert werden. Dazu gibt man einfach eine Tastenkombination an, bei welcher die Diktierfunktion aktiviert werden soll. Danach ist sie in jeder Anwendung nutzbar, wo man auch mit der Tastatur Daten eingeben kann.

Der Funktionsumfang ist mit professioneller Software natürlich erstmal nicht vergleichbar – aber dafür diktiert man erst einmal völlig kostenlos.

MacOSX-Diktieren

WordPress-Themes entwickeln – mein Workflow

Nachdem ich aktuell dabei bin meine eigenen Themes zu entwickeln und zu verkaufen, möchte ich hier einmal kurz vorstellen, wie ich dabei vorgehe. Damit das Tutorial verständlich ist, sollte man folgende Themen grundlegend beherrschen und sein eigen nennen:

  • git
  • Unix / Mac OS X
  • Webserver mit SSH-Zugang (für git)

Zusätzlich setze ich noch phpStorm als IDE ein – aber das ist eher unerheblich und sorgt nur für etwas Komfort. Als erstes Problem steht man vor der Dateistruktur. Am Ende ist ein Theme dann doch mehr als ein einzelnes Theme-Verzeichnis. Daher habe ich mir folgende Struktur überlegt.

Wie man sieht, liegt innerhalb meiner WordPress-Entwicklungs-Instanz ein dev-Verzeichnis. Darunter folgt der Typ des zu entwickelnden Stück Software (plugins, themes, …). Dann ein allgemeiner Name, welcher den Inhalt beschreibt und als git-Repo angelegt wird.

Im Themes-Verzecihnis selbst liegt dann nur noch ein Symlink auf das eigentliche Theme-Verzeichnis. So kann ich zusätzlich zum eigentlichen Theme noch weitere Dateien wie Dokumentationen, Beispieldaten oder Bilder in das Repo legen und bin innerhalb von WordPress immer auf dem aktuellsten Stand des Repos. So spart man sich das hin und her kopieren und kann auch innerhalb des Repos ganz entspannt Branches wechseln etc.

Da bei einer Veröffentlichung eines Theme-Updates immer genau der eine Stand zur Verfügung gestellt wird, arbeite ich hier mit git-Tags. Diese sind dann auch immer identisch mit der Version des Themes. Generell arbeite ich also in einem develop-branch bis eine Version fertig gestellt ist. Diese wird dann mit einem Tag versehen. Der Vorteil daran ist, dass ich auch in meiner Demo-Installation (online) git nutzen kann. Dazu lege ich einfach die selbe Struktur an wie lokal und kann einfach den nächst-höchsten Tag auschecken. Schon ist die neue Version zur Vorschau freigeschaltet.

Falls irgendwann jemand eine Frage zu dem Theme hat, muss er mir nur die Versionsnummer nennen und ich kann viel besser nachvollziehen was dort falsch laufen könnte.

Wie man sieht, ist das alles nichts besonderes und eigentlich nur klassisches git mit einem Symlink und etwas System und Disziplin beim Entwickeln. So beugt man extrem viel Chaos vor und kann alles genaustens nachvollziehen.

Meine Repos liegen als privat auf Bitbucket. Wer eh schon Geld für GitHub ausgibt kann diese natürlich auch hier ablegen. Hauptsache alle Server haben dort Zugriff. So hat man auch gleichzeitig ein Backup der sensiblen Daten.

WordPress: Eigenen oEmbed-Provider registrieren

Wer einen eigenen Provider für oEmbed (siehe codex) registrieren möchte, ist relativ schnell am Ziel. Doch was ist das eigentlich?

oEmbed ist ein offenes Format, welches erlaubt, Daten in eine andere Webseite einzubetten. Dazu braucht man die Struktur der Daten nicht genau kennen. Alles was man braucht, ist ein Link zu einer Ressource. Das Ergebnis ist dabei immer gleich aufgebaut. Einziger Unterschied eventuell das Format – hier wird immer XML und JSON unterstützt. Weiterlesen…