Archiv für den Autor: Heiko Mamerow

Automattics AMP Plugin anpassen

Update (09.03.16 – 15:08 Uhr): Bei meiner Messung (siehe unten) hatte sich ein Server-Hiccup eingeschlichen. Ich habe die Messung wiederholt und dadurch hat sich die Auswertung etwas – aber nicht wesentlich – geändert. Danke an Bego für den Hinweis! :-))

Das ist ein kleines „How-To“ darüber, wie sich das Standardtemplate von Automattics AMP Plugin dem Design der eigenen Website anpassen lässt. Doch zunächst ein paar eigene Gedanken zu AMP im Allgemeinen. Wer sich nur für die reine Umsetzung in WordPress interessiert, überspringt den folgenden Abschnitt.

AMP – Sinn und Zweck

Accelerated Mobile Pages Project (AMP) ist ein Projekt von Google für schnellere Websites. Seit dem 24. Februar werden „geAMPte“ Websites in den Suchergebnissen von Google berücksichtigt.

amp-google

Quelle: Googleblog (https://googleblog.blogspot.de/2016/02/amping-up-in-mobile-search.html)

Im Grunde wird mit AMP nichts weiter getan, als die Seite auf das Wesentliche – den Content – zu entschlacken – vor allem überflüssiger Ballast aus Header, Footer und Sidebar wird weggelassen. Das ist keine Hexerei. Wer schon eine auf Performance optimierte Website hat, braucht AMP eigentlich nicht. Wer keine performante Website hat, sollte seine Energie besser erstmal auf eine grundlegende Optimierung verwerten.

AMP vs. native

Im Selbstversuch habe ich eine von meinen Seiten aus diesem Blog gemessen: einmal als normale Seite (native) wie gewohnt und einmal mit AMP:

AMPnative
Requests:938
Datenmenge:239KB284KB
Finish:5,92s646ms
DOM geladen:328ms641ms
Ladezeit:832ms693ms

Wie zu erwarten, ist die AMP-Version im DOM Aufbau deutlich schneller. Es wird dort schließlich viel weniger Content dargestellt.

Im Vergleich steht die AMP-Version auch bei der Anzahl der Requests viel besser da. Dabei gilt allerdings zu beachten, dass meine Seite über HTTP2 läuft und dafür optimiert ist. Das bedeutet, die Anzahl der Requests ist hier (relativ) egal. Ein Performancegewinn kann bei HTTP2 durch die Verringerung der Requests nicht erzielt werden. Das erkennt man gut daran, dass die Ladezeit (load) bei der native-Version trotzdem geringer ist. Die wenigen Requests bringen also überhaupt keinen Vorteil. Nur bei HTTP1.1 wäre das anders.

Besonders auffällig ist, dass die Datenmenge bei AMP – Obwohl weniger Content dargestellt wird! – deutlich höher ist als auf der native Version. Dort gibt es z.B. noch eine Sidebar. Es würde sich lohnen, den Code genauer zu inspizieren. (Das war nur ein Messfehler beim ersten Versuch.)

amp-vs-native
image-581846

Oben: Die Daten von der AMP-Version dieser Seite.
Unten: Die Daten von der normalen Version dieser Seite.
(Zum Vergrößern auf das Bild klicken oder tippen.)

Mit AMP wird die Seite also nicht unbedingt performanter, sondern unter Umständen sogar langsamer. Am Ende kann auch AMP nichts weiter machen, als sich an allgemein gültige Regeln für die Optimierung halten.

Bei mir läuft AMP bei den Beiträgen nur deshalb, damit ich es testen kann. Für mehr taugt es hier nicht.

Aber Moment, so einfach ist es nicht! Google führt mit AMP was ganz anderes im Schilde, als einfach nur Performanceoptimierung:

We also want to promote enhanced distribution so that publishers can take advantage of the open web’s potential for their content to appear everywhere quickly – across all platforms and apps – which can lead to more revenue via ads and subscriptions.
(Quelle: https://www.ampproject.org/….)

…Holzauge, sei wachsam! ;-)

AMP für WordPress

Wer die WordPress Website mit AMP aufwerten möchte, nimmt zum Beispiel das Plugin AMP von Automattic. Einmal installiert, sorgt es dafür, dass alle Beiträge (keine Seiten!) als AMP-Version vorliegen. Konfigurationsmöglichkeiten bietet das Plugin keine. Die AMP-Seite wird in einem Standard-Layout ausgeliefert. Das ist soweit ok. Doch wenigstens die Farben im Header und Links möchten sicher viele Ihrem eigenen Layout anpassen.

Auf der Github-Seite des Projektes ist sehr gut Dokumentiert, wie sich das Template anpassen lässt. Das lässt sich durch einige Zeilen Code in der functions.php erledigen. Wer nicht coden kann bzw. sich seine Konfiguration lieber zusammen klicken möchte, kann zum Beispiel mit diesem zusätzlichen Plugin grundlegende Anpassungen erledigen.

Ich bevorzuge die handgemachte Lösung in der functions.php. Damit sind viel individuellere Anpassungen möglich als mit einem Plugin.

AMP Template tweaken

Hier mal ein einfaches Beispiel, wie sich das Standard-Template anpassen lässt. ich habe bei mir die Farben für den Header und die Links an meinen Styleguide angepasst.

amp-css-change

Der Vorher-Nachher-Effekt: Links in Blau das Standard-Layout vom Plugin. und rechts eine kleine Anpassung der Farben.

Die Anpassungen lassen sich alle ganz praktisch im eigenen Theme erledigen. Öffne dazu die functions.php, trage folgenden Code ein und passe das CSS an Deine Werte an:

// AMP tweaking
function hm_amp_css_tweaks($amp_template) {
  ?>
  /* Headerfarbe ändern. */
  nav.amp-wp-title-bar {
    background: #b25e80;
  }
  /* Linkfarbe ändern. */
  a,
  a:visited {
    color: #b25e80;
  }
  a:hover,
  a:active,
  a:focus,
  .amp-wp-meta,
  .amp-wp-meta a {
    color: #73374f;
  }
  <?php
}
add_action('amp_post_template_css', 'hm_amp_css_tweaks');

Update: (10.03.2016 – 13:04 Uhr) Im obigen Code habe ich die Syntax der CSS-Kommtare berichtigt.

Mit diesem kleinen Snippet lässt sich schon das Wesentlichste im Layout anpassen. Wer will, kann natürlich noch viel mehr ändern. Bis hin zum Austausch des gesamten Templates ist alles möglich. Dank der sehr guten Doku von Automattic, erledigen sich die Anpassungen komfortabel.

Themes oder Plugins von einer externen Festplatte einbinden

Irgendwann ist selbst die größte Festplatte einmal voll. Glücklich darf sich schätzen, wer einen Computer besitzt, wo sich noch eine oder sogar mehrere weitere Platten einbauen lassen. Selbst wenn nicht, findet sich wenigstens noch ein USB-Anschluss für eine externe Festplatte.

Also einfach neue Festplatte rein und weiter geht es!
– Ja, schön wäre das…. ^^

Problem

Die Themes-Projekte, die ich nun auf meiner zweiten Festplatte ausgelagert hatte, wurden vom Multisite-WordPress – welches auf der ersten Festplatte installiert ist – nicht erkannt.

Mir ist bisher nicht klar, warum WordPress die Themes nicht erkennt. Wer mich da aufklären mag – nur zu! :-)

Grundsätzliches

Normalerweise entwickle ich ein Theme in einem speziellen Entwicklungsverzeichnis. Von dort binde ich es über einen Symlink in mein lokales WordPress ein. Das ist sehr praktisch, weil ich so eine saubere Trennung von Entwicklungs- und Testumgebung(en) habe. Und natürlich auch von der Liveumgebung beim Kunden.

Weiterer Vorteil: Wenn ich etwas in der Entwicklungsumgebung am Theme ändere, ist die Änderung sofort im „Test-WordPress“ verfügbar.

Übrigens meine Erklärung bezieht sich auf (Ubuntu-)Linux. Unter Mac-OS ist es ähnlich. Zu Windows kann ich nichts beitragen.

Einbinden mit Symlink

In der Entwicklungsumgebung bearbeite ich alle Dateien unter src. Die bearbeiteten Dateien landen dann im Verzeichnis build. Das build Verzeichnis beinhaltet das fertige Theme. Vom Theme-Verzeichnis meines lokalen „Entwicklungs-WordPress“ erzeuge ich eine symbolische Verknüpfung (Symlink) zu diesem build Verzeichnis.

mount-symlink1
image-581773

Im Terminal erzeugt man den Link nach folgendem Schema:

ln -s /Pfad-zum-Entwicklungsverzeichnis /Pfad-zu-WP-themes/theme-name

Einbinden mit mount

Auf die zweite Festplatte meines Rechners habe ich u.a. die Entwicklungsumgebung der Themes ausgelagert. Wenn ich versuche ein Theme wie gehabt mit Symlinks in WordPress auf der ersten Platte einzubinden, wird das Theme von WordPress nicht erkannt.

Statt der Symlinks habe ich – nach einigen Irrungen und Wirrungen – folgende Lösung gefunden:

mount-symlink2
image-581774

Die Themes von der zweiten Platte werden gemountet. Beim Mounten werden normalerweise ganze Datenträger und auch Netzwerke in das System eingebunden. Aber man kann damit auch einzelne Ordner von externen Datenträgern einbeziehen.

Anders als bei den Symlinks muss beim Mounten der Zielordner (theme-name) vorher angelegt werden. Das eigentliche Mounten erfolgt mit dem Befehl:

sudo mount --bind /Pfad-zum-Entwicklungsverzeichnis /Pfad-zu-WP-Themes/theme-name

In dem gemounteten (Theme-)Ordner liegen nun alle Ordner und Dateien bereit und werden auch anstandslos von WordPress erkannt.

Warning: Parameter 1 to [name of the plugin] Cache::[function name]()

After switching to PHP 7 you may find one or more warnings on your WordPress pages in this pattern:

Warning: Parameter 1 to [plugin name]::[function name]() expected to be a reference, value given in [absolute path to/wp-includes/functions.php on line [number]

Fixing is easy. Just go to your plugin and search/find the first [function name] – see above. This may lock like this:

function [function name](&$buffer) {

…now delete the „&“

function [function name]($buffer) {

Done :-)

PS: Of course this is only quick&dirty to make the website run. Don’t forget to inform the plugin author(s)!

 

HHVM vs. PHP7

Seit heute gibt es PHP7 und ich habe aus gegebenem Anlass einen Vergleich mit HHVM erstellt.

PHP 7

--------------------------------------
| PHP BENCHMARK SCRIPT |
--------------------------------------
Start : 2015-12-03 23:57:40
Server : webwork@127.0.1.1
PHP version : 7.0.0RC8
Platform : Linux
--------------------------------------
test_ifelse : 0.260 sec.
test_loops : 0.301 sec.
test_stringmanipulation : 0.450 sec.
test_math : 0.285 sec.
--------------------------------------
Total time: : 1.296 sec.

PHP 5.5

--------------------------------------
| PHP BENCHMARK SCRIPT |
--------------------------------------
Start : 2015-12-03 23:00:13
Server : vvv.dev@192.168.50.4
PHP version : 5.5.9-1ubuntu4.14
Platform : Linux
--------------------------------------
test_ifelse : 0.574 sec.
test_loops : 0.760 sec.
test_stringmanipulation : 1.258 sec.
test_math : 1.167 sec.
--------------------------------------
Total time: : 3.759 sec.

HHVM

--------------------------------------
| PHP BENCHMARK SCRIPT |
--------------------------------------
Start : 2015-12-03 23:04:10
Server : heikomamerow.de@78.47.120.139
PHP version : 5.6.99-hhvm
Platform : Linux
--------------------------------------
test_ifelse : 0.033 sec.
test_loops : 0.067 sec.
test_stringmanipulation : 0.511 sec.
test_math : 0.297 sec.
--------------------------------------
Total time: : 0.908 sec.

Sieger ist hier eindeutig HHVM.

Natürlich ist dieser Test nicht ausschlaggebend. Man müsste unter realistischen Bedingungen z.B. im Einsatz mit WordPress testen. Mal sehen, ob/wann ich die Zeit und Muse dazu finde. ;-)

Zum Testen habe ich übrigens das PHP benchmark Script verwendet.

Vagrant up: The name of your virtual machine couldn’t be set

Bei der Installation von Varying Vagrant Vagrants (VVV) ist mir diesmal ein ungewöhnlicher Fehler passiert. Scheinbar so ungewöhnlich, dass ich diesmal bei der Recherche im Netz keine Lösung finden konnte. Aber immerhin habe ich es dann ausnahmsweise mal mit eigenem Nachdenken hinbekommen . ;-)

Vagrant Logo

By Fco.plj (Own work) [CC BY-SA 3.0], via Wikimedia Commons

Der Fehler

Die Installation (vagrant up) bricht irgendwann mit folgender Fehlermeldung ab:

The name of your virtual machine couldn't be set because VirtualBox
is reporting another VM with that name already exists. Most of the
time, this is because of an error with VirtualBox not cleaning up
properly. To fix this, verify that no VMs with that name do exist
(by opening the VirtualBox GUI). If they don't, then look at the
folder in the error message from VirtualBox below and remove it
if there isn't any information you need in there.

Das Problem

Ich hatte VVV als Unterverzeichnis vagrant-local in das VM-Verzeichnis von VirtualBox – /media/webwork/sec/VirtualBox VMs – geklont. Damit hatte „vagrant up“ Probleme, weil es genau in dieses Unterverzeichnis seine VM anlegen wollte, aber nicht konnte, weil das Verzeichnis schon vorhanden war. Darum brach VVV die Installation mit obiger Fehlermeldung ab.

Die Lösung

Die Lösung besteht darin, das „Clone-Verzeichnis“ außerhalb des VirtualBox-Verzeichnisses anzulegen. Bei mir z.B. /media/webwork/sec/vagrant-local Danach konnte ich die Installation wie gewohnt durchführen.

Nginx mit HTTP/2

Seit dem 22. September unterstützt nginx das neue Protokoll HTTP/2. Gleich am nächsten Tag habe ich zum Testen meinen Web-Server umgestellt. Hier ein kurzer Bericht:

Ich spare mir, die Vorzüge von HTTP/2 aufzuführen und zeige die wichtigsten Messergebnisse meiner Startseite im Vergleich:

http2-http1

HTTP/2 vs. HTTP/1 meiner Startseite im Vergleich

Wie erhofft, haben sich dank HTTP/2 die Ladezeiten verbessert. Sehr überrascht bin ich von der deutlichen Verminderung der CPU Busy Time. Darüber dürften sich auch die Hoster ganz besonders freuen.

Voraussetzungen für die Umstellung auf HTTP/2

1) Eigener Server

Ganz zuvorderst braucht man einen eigenen (v)Server mit Root-Rechten. Wer das nicht hat, muss so lange warten, bis sein Hoster endlich umgestellt hat.

Ich habe einen vServer mit Ubuntu 15.04 15.10.

2) SSL

SSL wird zwar nicht zwingend in der HTTP/2-Spezifikation vorgegeben, aber aktuelle Browser tun es.

3) OpenSSL

Nginx empfiehlt OpenSSL in der Version 1.0.2 für den vollen Funktionsumfang von HTTP/2. Auf dem aktuellen Ubuntu Server 15.04 ist leider nur OpenSSL 1.0.1f. Nginx schreibt aber, dass man vorübergehend mit der alten Version arbeiten kann. Bei mir läuft HTTP/2 auch mit OpenSSL 1.0.1f.

Die gute Nachricht: Im Upgrade 15.10 – welches am 22. Oktober 2015 raus kommt – ist OpenSSL 1.02d dabei. Am besten bis dahin „Füße still halten“. ;-)

4) Nginx 1.9.5 1.9.6 1.9.7

Erst die aktuelle Mainline-Version 1.9.5 1.9.6 1.9.7 unterstützt HTTP/2. Es ist also notwendig, den Server upzudaten, falls „nur“ die Stable-Version im Einsatz ist.

In meinem Fall war das aufwendig. Denn ich verwende das ngx_pagespeed Modul von Google. Darum musste ich meinen nginx selber kompilieren. Das habe ich nach der Anleitung von Google erledigt. Dazu musste allerdings einiges angepasst werden.

Hier meine angepasste Anleitung für nginx mit HTTP/2 und ngx_pagespeed:

sudo apt-get install build-essential zlib1g-dev libpcre3 libpcre3-dev unzip
cd
NPS_VERSION=1.9.32.10
wget https://github.com/pagespeed/ngx_pagespeed/archive/release-${NPS_VERSION}-beta.zip
unzip release-${NPS_VERSION}-beta.zip
cd ngx_pagespeed-release-${NPS_VERSION}-beta/
wget https://dl.google.com/dl/page-speed/psol/${NPS_VERSION}.tar.gz
tar -xzvf ${NPS_VERSION}.tar.gz

Update 27.10.15: Neueste NPS Version

cd
NGINX_VERSION=1.9.7
wget http://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz
tar -xvzf nginx-${NGINX_VERSION}.tar.gz
cd nginx-${NGINX_VERSION}/
./configure --add-module=$HOME/ngx_pagespeed-release-${NPS_VERSION}-beta \
--prefix=/usr/local/share/nginx --conf-path=/etc/nginx/nginx.conf \
--with-http_ssl_module \
--with-http_v2_module \
--sbin-path=/usr/local/sbin --error-log-path=/var/log/nginx/error.log
make
sudo make install

Update 17.11.15: Neueste nginx Version

… in fünf Minuten erledigt. ;-D

HTTP/2 aktivieren

Wenn die Vorbereitungen erledigt sind, ist die eigentliche Aktivierung ein Kinderspiel:

  1. In config-Datei des virtuellen Hosts als Root in einem Editor öffnen.
  2. Die Direktive listen mit http2 erweitern:
    server {
        # https
        listen 443 ssl http2;
    ...usw...
  3. Nginx neu laden.

Testen

Zum Überprüfen, ob HTTP/2 läuft, kann man die folgende Erweiterung in seinem Chrome Browser aktivieren:

https://chrome.google.com/webstore/detail/http2-and-spdy-indicator/mpbpobfflnpcgagjijhmgnchggcjblin?hl=en

Wenn alles gut gegangen ist, sieht man in der Adressleiste von Chrome einen blauen Blitz.

http2-test

Blauer Blitz = Test bestanden

UPDATE – 29.09.15

Eben bin ich darauf aufmerksam gemacht worden, dass meine Seite bei diesem HTTP/2 Check nicht besteht: https://www.h2check.org/#heikomamerow.de

Jetzt wäre es gut zu wissen, wie der Test funktioniert und warum er nicht erfolgreich war… Ich bin gespannt und warte auf Antwort von h2check.

UPDATE – 05.11.15

Von h2check fehlt leider immer noch Rückmeldung. Aber dafür gibt es eine weitere HTTP/2 Check-Seite:  https://tools.keycdn.com/http2-test

Dort verläuft der Test meiner Seite positiv. 
(Danke an Bodo für den Tipp! :-))

 

Viel Spaß und Erfolg beim Umstellen!
:-)

 

 

WordCamp Berlin 2015 – Logbuch

Am 14. November findet das WordCamp Berlin 2015 statt. Ich bin im Orga-Team und helfe mit, so gut es geht. Hier möchte ich als Logbuch meine Orga Todos dokumentieren. Dieser Beitrag wird darum laufend aktualisiert.

wc-logo-final-540

DatumToDoZeit (min)
 Es geht weiter… ;-)
Hier fehlt noch einiges aus der Vergangenheit.
11.09.15Sponsoring: Sponsoringmappe erstellen120
13.09.15Sponsoring: Sponsoringmappe überarbeitet und veröffentlicht40
14.09.15Sponsoring: Rechnungsvorlage erstellen;
Sponsorenliste anlegen und Daten einsammeln und einpflegen; Rechnungen schreiben, Rechnungen verschicken
180
14.09.15Sponsoring: Teefonat und Absprache30
14.09.15Orga-Meeting60
16.09.15Kommunikation: E-Mail-Anfragen beantworten;
Sponsoring: Rechnungen schreiben und verschicken
95
17.09.15Kommunikation: E-Mails abarbeiten;
Sponsoring: englische Sponsoring-Mappe vorbereiten
70
20.09.15Website: Debugging; Ticket-Bestellung gecheckt; Beitrag geschrieben
Sponsoring: Kommunikation
90
21.09.15Website: Debugging;
Kommunikation: E-Mail Fragen beantwortet
Sponsoring: Rechnugnen, Fragen klären
90
22.09.15Ticketverkauf gestartet
nach knapp fünf Stunden alles ausverkauft.
Website: Beiträge veröffentlichen; Sponsorenliste ändern
Kommunikation: Emails, Twitter, Xing, Facebook, Google+
Sponsoring, Fragen, Kümmern, Rechnugnen…
330
23.09.15Kommunikation: Meeting (SRH), internes Meeting
Webiste: kleine Anpassungen
60
24.09.15Kommunikation: E-Mails beantworten/abarbeiten
Sponsoring: Rechnungen und Nachfragen
Website: Beitrag schreiben
180
28.09.15Kommunikation: E-Mails beantworten
Meeting
180
30.09.15Kommunikation: E-Mails; Sponsoring;
Website: Beitrag überarbeiten
60
01.10.15Kommunikation: E-Mails; Sponsoring; Beitrag editieren
Sponsoring: Rechnungen schreiben
45
03.10.15Ticketverkauf2 – 50 Tickets in sechs Minuten!
Notiz: Beim nächsten Mal Tickets nur einzeln verkaufen.
Website: Beitrag schreiben15
05.10.15Website: Beitrag schreiben
Meeting
Kommunikations: E-Mails
Sponsoring; Rechnungen
180
06.10.15Website: Beiträge veröffentlichen
Kommunikation: E-Mails
60
07.10.15Kommunikation: E-Mail; Intern
Sponsoring: Zahlungseingänge; Freikarten
60
08.10.15Kommunikation: Intern15
09.10.15Website: Beitrag editieren
T-Shirts: Kalkulation
Speaker: Abstimmung
Kommunikation: E-Mails
180
12.10.15Catering: Kalkulation, Angebot
Meeting
Kommunikation: E-Mails
240
13.10.15Sponsoring: Rechnungen, Zahlungseingänge, Fragen
Kommunikation: E-Mails
60
14.10.15Sponsoring: Fragen klären, Zahlungseingänge
Kommunikation: Telko Mediapartner
60
15.10.15Sponsoring: Tickets, Fragen
Kommunikation: E-Mails
20
16.10.15Sponsoring: Tickets, Fragen
Kommunikation: E-Mails
180
19.10.15Catering: Kalkulation neu; Angebot neu
Meeting
150
20.10.15Meeting Afterparty
Kommunikation: E-Mails
Sponsoring: Rechnungen, Kalkulation
120
21.10.15Kommunikation60
22.10.15Wapuu: – Auswertung; Beitrag30
25.10.15Sponsoring: Sponsorenliste Update
Kommunikation: E-Mails
20
26.10.15Meeting
Kommunikation
180
27.10.15Kommunikation
Catering
Poll
180
28.10.15Meeting SRH
Technische Daten
180
29.10.15T-Shirts/Swag Bestellung; Listencheck
E-Mails
120
09 – 15.11.15Orga-Orga-Orga :-)3360
25.11.15Abrechnungen, E-Mails60
 30.11.15Abrechnungen, E-Mails180
06.12.15Budgetliste geupdatet, Beitrag geschrieben120

Tschüss PhpStorm! Hallo NetBeans!

TL;DR: Herz ist Trumpf!

Für das Erstellen von WordPress Themes verwende ich seit ein paar Tagen eine für mich neue Entwicklungsumgebung (IDE): NetBeans. Davor hatte ich fast eineinhalb Jahre PhpStorm im Einsatz.

NetBeans

NetBeans“ by Source. Licensed under Fair use via Wikipedia.

Dieser Wechsel mag wahrscheinlich recht ungewöhnlich sein, denn ich habe den Eindruck, dass gerade sehr viele Entwickler zu PhpStorm wechseln bzw. sich nichts besseres mehr vorstellen können. PhpStorm dürfte zur Zeit als das Non plus ultra bei den IDEs gelten.

(K)Ein Grund zum Wechseln

Einen Grund zum Wechseln hatte ich eigentlich nicht. PhpStorm ist hervorragend. Auch wenn ich trotz intensiver Nutzung bislang nur einen Bruchteil der Features nutzen konnte, hat selbst dieser Bruchteil meine Produktivität enorm gesteigert. Also rational gab es keinen Grund zu wechseln. Aber was mich schon immer an PhpStorm gestört hat, ist die proprietäre Lizenz dieser Software. Diese Lizenz wurde mir dann vor Kurzem sogar zum Verhängnis:

Zufall ist nur die Unkenntnis der Zusammenhänge

Wie es der Zufall so wollte, ergab es sich, dass ich für ein paar Wochen, auf einem anderen Computer arbeiten musste. Dort hatte ich mir wie gewohnt PhpStorm installiert. Weil ich aber meinen gekauften Lizenzkey nicht zur Hand hatte, hatte ich die Installation erstmal als 30-Tage Testversion aktiviert. …Und später vergessen, den Lizenzkey nachträglich zu aktivieren. Das böse Erwachen kam mir dann ausgerechnet im Urlaub – fernab der Heimat – als die Testversion auslief.

phpstorm-30mins

Leider hatte ich im Urlaub meinen Lizenzkey nicht dabei. ;-(

 

Den Rest kann man sich denken: PhpStorm war nicht mehr benutzbar. Ich musste mir also eine Alternative suchen, weil ich dringend an einem Kundenprojekt etwas bearbeiten musste. (Als Selbstständiger muss man ab und zu auch im Urlaub arbeiten….) Von Netbeans hatte ich vorher schon einiges Gutes gelesen – insbesondere, dass es von den Features mit PhpStorm mithalten könne. Allerdings habe ich auch Schlechtes gelesen; nämlich, dass Netbeans im Vergleich zu PhpStorm recht lahm sein soll. Aber immerhin, Netbeans ist Open Source und fragt nicht nach einem Lizenzkey.

netbeans

Mit NetBeans konnte ich sofort loslegen und werde nie nach einem Lizenzkey gerfragt.

Herzensangelegenheit

Ich benutze normalerweise nur Open Source SoftwareUbuntu, nginx, Apache, HHVM, PHP, MariaDB, MySQL, Sass, Grunt, Node.js, Bower, LiveReload, PhantomJS, CasperJS, DalekJS usw. usf. etc. pp. Last not least die Software, mit der ich meinen Lebensunterhalt bestreite und für die ich mich ein kleines bisschen engagiere – WordPress – ist ebenfalls Open Source; genauso wie die Themes, die ich für meine Kunden erstelle. Einen Lizenzkey gibt es nicht.

Für Open Source habe ich mich ganz bewusst entschieden. Nur wenn die Software bzw. der Code offen – lesbar, bearbeitbar und verwendbar – ist, kann sich daraus etwas Großes entwickeln. Daran glaube ich. Es ist mir eine Herzensangelegenheit.

Warum also soll ausgerechnet die IDE, mit der ich Open Source Code schreibe, eine proprietäre Software sein? Nur weil sie so gut ist?? Reicht das??? Nein, mir reicht das nicht. Die Freiheit, die mir eine Software bieten kann, ist mir wichtiger als ihre Perfektion. Und darum hatte ich immer ein merkwürdiges Gefühl, wenn ich PhpStorm benutzt habe.

Dieses ungute Gefühl bin ich mit Netbeans los geworden. Der Umstieg mit meinen Projekten verlief bisher reibungslos!

Wie gesagt, PhpStorm ist mit die beste IDE, die es zur Zeit gibt, keine Frage. Aber mein Bauch hatte bedenken. Und mein Herz hat sich entschieden: Netbeans! :-)

Das Video passt zwar nicht wirklich zum Thema, aber ich konnte ich es mir einfach nicht verkneifen… ;-D