Linux Archive - SUCKUP.de

Timeout Problems: Web Server + PHP

What?

First there is an HTTP request and that will hit your Web server, then it will pass the request via TCP- or UNIT-Socket via FastCGI to your PHP-FPM Daemon, here we will start a new PHP process and in this process we will connect e.g. to the database and run some queries.

PHP-Request

The Problem!

There are different timeout problems here because we connect different pieces together and this parts need to communicate. But what if one of the pieces does not respond in a given time or, even more bad, if one process is running forever like a bad SQL-query.

Understand your Timeouts.

Timeouts are a way to limit the time that a request can run, and otherwise an attacker could simply run a denial-of-service with a simple request. But there are many configurations in several layers: Web server, PHP, application, database, curl, …

– Web server

Mostly you will use Apache or Nginx as Web server and in the end it makes not really a difference, there are different timeout settings, but the idea is almost the same: The Web server will stop the execution and kills the PHP process, now you got a 504 HTTP error (Gateway Timeout) and you will lose your stack trace and error-tracking because we killed our application in the middle of nothing. So, we should keep the Web server running as long as needed.

“`grep -Ri timeout /etc/apache2/“`

/etc/apache2/conf-enabled/timeout.conf:Timeout 60

/etc/apache2/mods-available/reqtimeout.conf:<IfModule reqtimeout_module>

/etc/apache2/mods-available/reqtimeout.conf: # mod_reqtimeout limits the time waiting on the client to prevent an

/etc/apache2/mods-available/reqtimeout.conf: # configuration, but it may be necessary to tune the timeout values to

/etc/apache2/mods-available/reqtimeout.conf: # mod_reqtimeout per virtual host.

/etc/apache2/mods-available/reqtimeout.conf: # Note: Lower timeouts may make sense on non-ssl virtual hosts but can

/etc/apache2/mods-available/reqtimeout.conf: # cause problem with ssl enabled virtual hosts: This timeout includes

/etc/apache2/mods-available/reqtimeout.conf: RequestReadTimeout header=20-40,minrate=500

/etc/apache2/mods-available/reqtimeout.conf: RequestReadTimeout body=10,minrate=500

/etc/apache2/mods-available/reqtimeout.load:LoadModule reqtimeout_module /usr/lib/apache2/modules/mod_reqtimeout.so

/etc/apache2/mods-available/ssl.conf: # to use and second the expiring timeout (in seconds).

/etc/apache2/mods-available/ssl.conf: SSLSessionCacheTimeout 300

/etc/apache2/conf-available/timeout.conf:Timeout 60

/etc/apache2/apache2.conf:# Timeout: The number of seconds before receives and sends time out.

/etc/apache2/apache2.conf:Timeout 60

/etc/apache2/apache2.conf:# KeepAliveTimeout: Number of seconds to wait for the next request from the

/etc/apache2/apache2.conf:KeepAliveTimeout 5

/etc/apache2/mods-enabled/reqtimeout.conf:<IfModule reqtimeout_module>

/etc/apache2/mods-enabled/reqtimeout.conf: # mod_reqtimeout limits the time waiting on the client to prevent an

/etc/apache2/mods-enabled/reqtimeout.conf: # configuration, but it may be necessary to tune the timeout values to

/etc/apache2/mods-enabled/reqtimeout.conf: # mod_reqtimeout per virtual host.

/etc/apache2/mods-enabled/reqtimeout.conf: # Note: Lower timeouts may make sense on non-ssl virtual hosts but can

/etc/apache2/mods-enabled/reqtimeout.conf: # cause problem with ssl enabled virtual hosts: This timeout includes

/etc/apache2/mods-enabled/reqtimeout.conf: RequestReadTimeout header=20-40,minrate=500

/etc/apache2/mods-enabled/reqtimeout.conf: RequestReadTimeout body=10,minrate=500

/etc/apache2/mods-enabled/reqtimeout.load:LoadModule reqtimeout_module /usr/lib/apache2/modules/mod_reqtimeout.so

/etc/apache2/mods-enabled/ssl.conf: # to use and second the expiring timeout (in seconds).

/etc/apache2/mods-enabled/ssl.conf: SSLSessionCacheTimeout 300

Here you can see all configurations for Apache2 timeouts, but we only need to change etc/apache2/conf-enabled/timeout.conf`` because it will overwrite `/etc/apache2/apache2.conf` anyway.

PS: Remember to reload / restart your Web server after you change the configurations.

If we want to show the user at least a custom error page, we could add something like:

ErrorDocument503 /error.php?errorcode=503
ErrorDocument 504 /error.php?errorcode=504

… into our Apache configuration or in a .htaccess file, so that we can still use PHP to show an error page, also if the requested PHP call was killed. The problem here is that we will lose the error message / stack trace / request etc. from the error, and we can’t send e.g. an error into our error logging system. (take a look at sentry, it’s really helpful)

– PHP-FPM

Our PHP-FPM (FastCGI Process Manager) pool can be configured with a timeout (request-terminate-timeout), but just like the Web server setting, this will kill the PHP worker in the middle of the process, and we can’t handle the error in PHP itself. There is also a setting (process_control_timeout) that tells the child processes to wait for this much time before executing the signal received from the parent process, but I am uncertain if this is somehow helpfully here? So, our error handling in PHP can’t catch / log / show the error, and we will get a 503 HTTP error (Service Unavailable) in case of a timeout.

Shutdown functions will not be executed if the process is killed with a SIGTERM or SIGKILL signal. :-/

Source: register_shutdown_function

PS: Remember to reload / restart your PHP-FPM Daemon after you change the configurations.

– PHP

The first idea from most of us would be maybe to limit the PHP execution time itself, and we are done, but that sounds easier than it is because `max_execution_time` ignores time spent on I/O (system commands e.g. `sleep()`, database queries (SELECT SLEEP(100)). But these are the bottlenecks of nearly all PHP applications, PHP itself is fast but the external called stuff isn’t.

Theset_time_limit()function and the configuration directive max_execution_time only affect the execution time of the script itself. Any time spent on activity that happens outside the execution of the script such as system calls using system(), stream operations, database queries, etc. is not included when determining the maximum time that the script has been running. This is not true on Windows where the measured time is real.

Source: set_time_limit

– Database (MySQLi)

Many PHP applications spend most of their time waiting for some bad SQL queries, where the developer missed adding the correct indexes and because we learned that the PHP max execution time did not work for database queries, we need one more timeout setting here.

There is the MYSQLI_OPT_CONNECT_TIMEOUT and MYSQLI_OPT_READ_TIMEOUT (Command execution result timeout in seconds. Available as of PHP 7.2.0. – mysqli.options) setting, and we can use that to limit the time for our queries.

In the end you will see a “Errno: 2006 | Error: MySQL server has gone away” error in your PHP application, but this error can be caught / reported, and the SQL query can be fixed, otherwise the Apache or PHP-FPM would kill the process, and we do not see the error because our error handler can’t handle it anyway.

Summary:

It’s complicated. PHP is not designed for long execution and that is good as it is, but if you need to increase the timeout it will be more complicated than I first thought. You need for example different “timeout”-code for testing different settings:

// DEBUG: long-running sql-call
// Query(‘SELECT SLEEP(600);’);

// DEBUG: long-running system-call
// sleep(600);

// DEBUG: long-running php-call
// while (1) { } // infinite loop

Solution:

We can combine different timeout, but the timeout from the called commands e.g. database, curl, etc. will be combined with the timeout from PHP (max_execution_time) itself. The timeout from the Web server (e.g. Apache2: Timeout) and from PHP-FPM (request_terminate_timeout) need to be longer than the combined timeout from the application so that we still can use our PHP error handler.

e.g.: ~ 5 min. timeout

MySQL read timeout: 240s ⇾ 4 min.

link->options(MYSQLI_OPT_READ_TIMEOUT, 240);

PHP timeout: 300s ⇾ 5 min.
```
max_execution_time = 300
```
Apache timeout: 360s ⇾ 6 min.
```
Timeout 360
```
PHP-FPM: 420s ⇾ 7 min.
```
request_terminate_timeout = 420
```

Links:

Was habe ich als Fachinformatiker bisher gelernt?

Nachdem ich nun bereits seit einigen Jahren lerne zu deklarieren und zu programmieren, werde ich im folgenden beschreiben was ich bisher gelernt habe.

Kurz zu mir: Lars Moelleken |
> Assistent für Betriebsinformatik
> Fachinformatiker Systemintegration
> Informatik Studium (Abgebrochen)
> Fachinformatiker Anwendungsentwicklung

Was habe ich in meiner Ausbildung zum Fachinformatiker Systemintegration gelernt?

– Du lernst nur soviel, wie du lernen willst.

Im Gegensatz zur Schule / Fachhochschule konnte und musste ich mir vieles in der Ausbildung selber beibringen und erarbeiten. Und man erkennt schnell, dass man nur soviel lernt wie man möchte. Wenn man dies einmal verstanden hat, dann setzt man sich auch gerne hin und lernt z.B. Linux- / Shell-Befehle auswendig, besucht weitere Kurse (z.B. bei der VHS), geht zu Meetups oder Konferenzen. Krümmer dich um dein Können, denn wenn man etwas macht, sollte man es auch richtig machen.

“Eine Investition in Wissen bringt noch immer die besten Zinsen.” – Benjamin Franklin

– Keine Panik!

Was man ziemlich schnell als Sysadmin lernt ist „Ruhe bewahren“ and think first – then act. Überstürzter Aktionismus hilft nicht weiter und schadet meistens sogar. Bevor man handelt, sollte man zuvor selber einige Informationen einholen (Infos von Logfiles, Hardware Status, System Status, …) so dass man auch wirklich weiß was wie man den Fehler behene kann.

– Linux && Kommandozeile <3

Wer bisher noch nicht mit einem Unix Betriebssystem gearbeitet hat, weiß leider nicht was er verpasst. Wer aus welchen Gründen auch immer Windows nutzen möchten oder muss, kann trotzdem mit der Git-Bash [+ .dotfiles] einige Vorteile von Linux nutzen. Und seine eigene Komfortzone zu verlassen und neue Betriebssysteme auszuprobieren hilft dabei den Computer insgesamt besser zu verstehen. An dieser Stelle empfehle ich mal wieder “Arch Linux”.

Man sollte sich außerdem mit der Kommandozeile vertraut machen, wenn du deine Produktivität rapide steigern möchtest. Zum Beispiel sollte man folgende Befehle man genauer ansehen: find / grep / lsof / strace

find – Linux

– Lies in der offizielle Dokumentation (und erst dann bei “Stack Overflow”).

Ob Cisco oder Manpages man liest am besten die offizielle Dokumentation zu der Programm-Version / Hardware-Version welche man gerade einsetzt. Beim programmieren nutzt man jedoch häufig stackoverflow.com und findet schnell Antworteten und Code-Beispiele, aber das “Warum” und “Wie” kommt dabei meistens zu kurz. Wenn man als erstes in die Spezifikation / Dokumentation schaut löst man nicht nur dieses Problem, sondern man versteht ggf. das Problem und weiß auch wie man ähnliche Probleme lösen kann.

– Mach immer ein Backup (benutze nieeemals betrunken “sudo”).

Manche Sachen muss man auf die hart Tour lernen, apt-get install safe-rm zu installieren gehörte für mich anscheinend dazu!

“Der Mensch hat dreierlei Wege klug zu handeln; erstens durch Nachdenken, das ist der edelste; zweitens durch Nachahmen, das ist der leichteste; und drittens durch Erfahrung, das ist der bitterest.” – (Konfuzius)

– Sei ehrlich zu Kunden, Mitarbeitern und dir selbst.

Sei ehrlich zu Kunden, insbesondere wenn etwas schief geht. Wenn das Produkt (z.B. Server) vom Kunden ausfällt, dann biete Lösungsvorschläge an und keine Ausreden und löse das Problem nicht die Schuldfrage. Niemandem ist damit geholfen, wenn man mit dem Finger auf den Kollegen oder Kunden zeigt, dem Server nicht, dem Kunden nicht und letztlich einem selbst nicht.

– Stelle Fragen, wenn du etwas nicht verstanden hast.

Rede mit Kunden nicht über etwas was du nicht verstehst, etwas nicht zu wissen (insbesondere in der Ausbildung) ist nicht schlimm, aber dann frage einen Kollegen bevor du mit einem Kunden darüber sprichst!

– Denke über dein Tun nach (nicht nur auf der Arbeit).

Wenn man Dinge hinterfragt und über seine Arbeit und sein Tun nachdenkt, dann kann man sich persönlich weiterentwickeln. Hinterfrag kritische zum Beispiel ob man wirklich bei Amazon bestellen sollte oder sollte man das Buch lieber direkt beim Verlag bestellt? Welchen Vorteil hat der Autor davon und habe ich Nachteile? Sollten wir Nagios3 oder besser direkt Icinga einsetzen? Hinterfrage deine Arbeit und bewerte kritisch ob dies wirklich eine gute / sichere / zukunftsorientierte Lösung ist.

Falls man sich selber nicht sicher ist oder eine zu eingeschränkte Sichtweise hat (weil man z.B. nur diese eine Lösung kennt), dann sollte man sich neues Wissen aneignen, ggf. andere Lösungen oder „best practices“ recherchieren und mit anderen über die Thematik diskutieren.

– Google korrekt nutzen …

Wenn man ein Problem recherchiert, dann sucht man nach der Fehlermeldung in Anführungszeichen. Und wenn man keine Fehlermeldung hat sucht man zusätzlich nach der Versionsnummer oder / und einer entsprechenden Jahreszahl.

https://suckup.de/2010/02/google-hacks-und-tricks/

Was habe ich in meiner Ausbildung zum Fachinformatiker Anwendungsentwicklung gelernt?

– Du lernst niemals aus …

Wenn man anfängt sich mit der Web-Programmierung (HTML, CSS, JS, Node.js, PHP, …) zu beschäftigen, weiß man zunächst gar nicht wo man anfangen soll! Es gibt so vieles zu lernen und dieses Gefühl begleitet einen einige Zeit (Jahre), bis man wiederkehrende Konzepte erkennt. Der Vorteil in der Web-Programmierung ist jedoch, dass viele unterschiedliche Dinge gemeinsame APIs haben oder zumindest kombiniert werden können. Ich kann in PHP eine Klasse schreiben, welche mir Data-Attribute für mein HTML erstellt, welche ich wiederum mit JavaScript auslesen kann, um diese entsprechend über CSS-Klassen zu gestalten. Aber es bleibt dabei, man lernt niemals aus und genau das ist das Spannende an diesem Job!

– Programmiere jeden Tag. (aber setzte dir selber ein LIMIT 1, x)

Auch wenn der Chef heute nicht im Büro ist und man als Azubi gerade keine Aufgabe hat, dann programmiere, wenn du Zuhause auf der Couch sitzt (und keine neue Serie auf Netflix läuft), dann programmiere und wenn du Urlaub hast, hast du Urlaub!

Hier ein interessanter Link von „John Resig“ (jQuery):
http://ejohn.org/blog/write-code-every-day/

– Denke in Modulen und Packages …

Wenn man jeden Tag Software schreibt, möchte man die selbe Funktionalität (z.B. Datenbankverbindung, E-Mail senden oder Error-Logging …) nicht mehrfach für verschiedene Projekte programmieren (und eigentlich will man Standard-Funktionen gar nicht selber programmieren). Daher sollte jeder Programmierer in Modulen denken und eine Applikation in verschiedenen, am besten austauschbaren Teilen konzipieren. In vielen Fällen kann man das System dann auch besser erweitern, da es bereits eine Schnittstelle für Module gibt, welche man nutzen kann. Die Unabhängigkeit und Entkopplung von Programmteilen hat auch den Vorteil, dass Seiteneffekte von unterschiedlichen Stellen im Quelltext weiter vermieden werden. Außerdem sollte man die Kopplung von den entsprechenden Modulen minimieren, da man ansonsten nichts durch Modulen gewinnt.

Für fast alle Dinge in der Web-Entwicklung gibt es bereits Paket-Manager:
– Frontend (css, js): bower (npm)
– Backend (Node.js): npm
– Backend (php): composer
– Backend (ruby): gem

– Open Source <3

Wenn man bereits mit Modulen und Packages arbeitet, kann man diese auch gleich als Open Source Projekt veröffentlichen + Tests via Travis-CI + Code-Coverage anzeigen + zumindest einer kleinen Dokumentation und schon allein aus diesen Gründen lohnt sich die Veröffentlichung als Open Source. Auch die Code-Qualität steigt (nach meiner Erfahrung), da man den Quelltext der Öffentlichkeit freigibt und sich daher mehr oder weniger Bewusst auf die Code-Qualität achtet.

Der Moment, wenn man seinen ersten Pull-Request für seine Software erhält oder mit jemanden aus Israel, der Türkei und der USA zusammen programmiert, unbezahlbar.

– Git und Gut!

Ich weiß nicht wie Menschen ohne eine Versionskontrolle mit dem PC arbeiten können. Selbst bei privaten kleineren Projekten oder für Konfigurations-Dateien setze ich “git” ein. Es folgende einige Vorteile, aber die Liste kann man bestimmt noch um einige Punkte erweitern …

Vorteile:
– Änderungen können nachvollzogen werden (git log, git blame)
– Änderungen können rückgängig gemacht werden (git revert, git reset)
– Änderungen können von anderen Mitarbeitern gereviewed werden
– Mitarbeiter können gleichzeitig an einem Projekt arbeiten (git commit, git pull, git push)
– Entwicklungszweige (Forks) können gleichzeitig entwickelt werden (git checkout -b , git branches)

– Nutze “github.com” und lerne von den besten.

Github ist noch einmal was ganz anders als zum Beispiel ein privater (kostenloses / freies) „gitlab“-Server, da man sich indirekt darauf geeinigt hat, dass man die Plattform für Open Source Projekte verwendet, obwohl github selbst nicht Open Source ist. Man findet daher wirklich viele gute Entwickler und Projekte auf github.com und man kann bereits durch das lesen von Quelltext / Quelltextänderungen vieles lernen. Insbesondere weil man die Entwicklung der Projekte nachvollziehen und verfolgen kann: Wie strukturieren andere Ihren Code? Wie schreiben andere Ihre “commit”-messages? Wie viel Code sollte eine Methoden beinhalten? Wie viel Code sollte eine Klasse beinhalten? Welche Variablen-Namen sollte man besser vermeiden? …

https://github.com/trending
https://twitter.com/trendinggithub

– Tests ausprobieren.

Gerade wenn man Tests für seine eigenen Funktionen und Klassen schreibt, erwischt man sich dabei genau die Fällte zu testen, welche man bereits bedacht hat, daher sollte man die entsprechende Funktionalität mit unterschiedlichen (noch nicht bedachten) Daten testen. Außerdem ist es manchmal hilfreich den Quelltext absichtlich (temporär) zu sabotieren, so dass man seine Tests ebenfalls einmal testen kann. Hier einige Listen mit Eingaben welche man testen könnte: https://github.com/minimaxir/big-list-of-naughty-strings

PS: außerdem sollte man einen zusätzlichen Test hinzufügen, wenn ein Fehler bereits aufgetreten ist, so dass man Fehler nur einmal finden muss. Hier ein Beispiel: https://github.com/swiftmailer/swiftmailer/tree/5.x/tests/bug/Swift

– Automatisiere deine Tests.

Unit-Tests, Integrationstest und Frontend-Tests helfen nur, wenn diese auch ausgeführt werden, daher sollte man sich frühzeitig mit automatisierten Tests beschäftigen und diese bei Quelltextänderungen auch automatisch ausführen. Wo und wann diese Tests ausgeführt werden entscheidet gleichermaßen darüber, wie effektiv diese Tests letztendlich sind. Sobald man einige Tests geschrieben hat, versteht man auch warum man auf zusätzliche Parameter bei Methoden und Funktionen besser verzichten sollte, da die Anzahl der Tests exponentiell ansteigt.

https://en.wikipedia.org/wiki/Software_testing

– Deployment ist wichtig …

Sobald man mit mehr als einem Entwickler an einem Projekte arbeitet, möchte man irgendeine Art von Deployment einsetzten, weil man seine Änderungen sonst gegenseitig überschreibt. Außerdem möchte man, dass der Quelltext aus dem Versionskontroll-System auf dem Server liegt, ansonsten kann man eine Applikation nicht warten bzw. erweitern!

– Konzepte zu verstehen ist wichtiger als dessen Implementierung.

Design-Patterns (Programmier-Konzepte) zu verstehen hilft einem nicht nur in der aktuellen Programmiersprache, sondern kann meistens auch auf andere Programmiersprachen angewendet werden.

Grundlegende Konzepte (Klassen, Objekte, OOP, Funktionen, ORM, MVC, DDD, Unit-Tests, Data-Binding, Hooks, Template-Engine, …) findet man in vielen Frameworks / Programmiersprechen und sobald man die Begriffe und Konzepte einmal verstanden hat, ist es gar nicht mehr so schwer neue / unterschiedliche Frameworks einzusetzen. Und man erkennt unterschiedliche stärken und schwächen von diesen Frameworks / Werkzeugen: „Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.“

– Probleme lösen heißt auch Kunden verstehen.

Design-Patterns gehören zur Grundausstattung, aber man sollte sich auch immer wieder die Frage stellen: Welches Problem mit der gegebenen Lösung eigentlich gelöst werden soll? Ggf. findet man eine noch eleganterer / einfacherer Lösung. Und manchmal will der Kunde eigentlich auch was ganz anders, er weiß es nur noch nicht oder jemand hat den Kunden falsch verstanden.

– Probleme lösen heißt auch Prozesse verstehen.

Es ist aber ebenso wichtig zu verstehen warum ein bestimmtes Feature implementiert wird, da man ansonsten etwas programmiert was entweder gar nicht gebraucht bzw. genutzt wird. Man sollte daher die entsprechende Aufgabenstellung vor der Implementierung und noch vor der Planung im Gesamtkontext verstehen.

projekt-schaukel-baum

– Verteile auf mehreren Dateien.

Nutze eine Datei für eine Klasse, nutze eine Datei für CSS-Eigenschaften eines Modules oder einer speziellen Seite, nutze eine neue Datei für jeden neuen View. Den Quelltext auf verschiedene Dateien / Verzeichnisse aufzuteilen bietet viele Vorteile, so weiß der nächste Entwickler wo neuer Quelltext abgelegt werden soll und man findet sich schneller im Quelltext zurecht. So geben viele Frameworks bereits eine vordefinierte Verzeichnisstruktur für z.B. Model / View / Controller vor.

– Lesbarkeit geht vor!

Die Lesbarkeit von Quelltext sollte immer an erster Stelle stehen, da man selber oder Arbeitskollegen diesen Code in Zukunft warten bzw. erweitern müssen.

YouTube Videos zum Thema “Clean Code”: https://www.youtube.com/results?search_query=%22Clean+Code%22&search_sort=video_view_count

Best Practices: http://code.tutsplus.com/tutorials/top-15-best-practices-for-writing-super-readable-code–net-8118

– Gute Namensgebung ist eine der schwierigsten Aufgaben in der Programmierung.

Es fängt beim Domainnamen / Projektnamen an, geht über Dateinamen zu Namen von Verzeichnissen, Klassennamen, Methodennamen, Variablennamen, CSS-Klassennamen. Mache dir immer bewusst, dass andere dies lesen werden und verstehen müssen. Daher sollte man auch auf unnötige Abkürzungen verzichten und schreiben, was man beschreiben möchte.

Wir wollen beschreiben was die Funktion macht und nicht wie diese implementiert ist.

-> Falsch: farbeBlack(), nutzeFarbe(), …
-> Richtig: $page->setColor(‘black’), $page->getColor(), …

Variablen sollten beschreiben was diese beinhalten und nicht wie diese gespeichert sind.

-> Falsch: $array2use, $personenArray, …
-> Richtig: $pages, $persons, …

Zusammenfassung: Beschreibe was die Variable / Methode / Funktion / Klasse ist, nicht wie diese implementiert ist.

Weniger schlecht PHP programmieren

– An Kommentare sparen (zumindest inline) …

Gute Kommentare erklären “Warum” und nicht “Was” gemacht wird und sollten dem Leser einem Mehrwert bieten, welcher nicht bereits im Quelltext (Stichwort: Namensgebung) beschrieben ist.

Beschreibungen für Methoden, Funktionen und Klassen (javadoc, phpdoc, …) sollte meiner Meinung nach immer hinterlegt werden, so dass man seine Dokumentation im Quelltext abbildet. Moderne IDEs können zudem prüfen, ob die Parameter und Rückgaben korrekt hinterlegt wurden.

https://de.wikipedia.org/wiki/PHPDoc
https://en.wikipedia.org/wiki/JSDoc
https://de.wikipedia.org/wiki/Javadoc

Beispiele für inline Kommentare:

schlechter Code:

// Prüfen ob der User bereits einloggt ist
if (isset($_SESSION['user_loggedin']) && $_SESSION['user_loggedin'] > 1) { ... }

etwas besserer Code:

// check if the user is already logged-in
if (session('user_loggedin') > 1) { ... }

besserer Code:

if ($user->isLoggedin === true) { ... }

… und noch ein Beispiel …

schlechter Code:

// regex: email
if (!preg_match('/^(.*<?)(.*)@(.*)(>?)$/', $email) { ... }

besserer Code:

define('EMAIL_REGEX_SIMPLE', '/^(.*<?)(.*)@(.*)(>?)$/');

if (!preg_match(EMAIL_REGEX_SIMPLE, $email) { ... }

– Konsistenz in einem Projekt, ist wichtiger als persönliche Präferenzen!

Nutze den bestehenden Code und nutze gegebene Funktionen. Wenn es Vorteile bringt, dann ändern / refactor den entsprechenden Code aber refactor dann alle Stellen im Projekt welche auf diese Weise implementiert sind.

Beispiel: Wenn man bisher ohne Template-System gearbeitet hat und aus „Gründen“ eines einsetzten möchte, dann nutze dies für alle Templates im Projekt und nicht nur für deinen aktuellen Use-Case, da ansonsten inkonsistenten im Projekt entstehen. Wenn man z.B. eine neue „Email→isValid()“ Methode, dann sollte man auch alle bisherigen RegEx-Versuche im aktuellen Projekt durch die „Email“-Klasse ersetzten, weil ansonsten wieder inkonsistenten entstehen.

– Ein einheitlicher Code-Style wirkt sich sehr positiv auf die Qualität aus!

Wie im echten Leben gilt auch hier, wenn irgendwo bereits Müll liegt, sinkt die Hemmschwelle seinen einen Müll dort abzuladen extrem an. Wenn aber alles schön ordentlich aussieht, wirft man nicht einfach eine “randumInt() { return 4; } “-Funktion hinzu.

Man sollte sich im Team einen Code-Style überlegen und diesen in neuen Projekten einsetzten. In bestehenden Projekten gibt wieder Konsistent geht vor.

– Nutze Funktionale-Prinzipien && Objekt-Orientierte-Konzepte.

Eine reine Funktion (“Pure Functions”) ist nur von ihren Parametern abhängig und mit den selben Parametern liefert diese immer das selbe Ergebnis. Diese Prinzipien kann man auch in OOP berücksichtigen und sogenannte Unveränderbare Klassen erstellen (immutable class).

https://en.wikipedia.org/wiki/Pure_function
https://de.wikipedia.org/wiki/Objektorientierte_Programmierung
https://en.wikipedia.org/wiki/Immutable_object

– Bitte keine globalen Variablen verwenden!

Globale Variablen erschweren das Testen, da diese Seiteneffekte verursachen können. Außerdem kann man Quelltext mit globalen Variablen nur schwer refactoren, da man nicht weiß welche Effekte diese Änderungen auf andere Teile des Systems haben.

In einigen Programmiersprachen (z.B. JavaScript, Shell) sind alle Variablen global und werden erst durch eine bestimmtes Schlüsselwort lokal (z.B. im Scope einer Funktion oder einer Klasse).

Admin meets Frontend

– Lerne deine Werkzeuge richtig einzusetzen!

Wenn man z.B. mit Notepad Quelltext schreibt kann man auch mit einem Löffel ein Loch graben, denn dies ist ähnlich effizient. Lerne Tastatur-Shortcuts für deine Programme und dein Betriebssystem! Nutze eine IDE z.B. von JetBrains (https://www.jetbrains.com/products.html) und nutze zusätzliche Plugins und Einstellungen.

Moderne IDEs geben auch Hinweise / Vorschläge, wie man seinen Code verbessern kann. Für PHP kann man z.B. PhpStorm + Php Inspections (EA Extended) einsetzten und die globalen IDE- Inspections-Einstellungen im Team teilen.

– Performance?

In vielen Situationen muss man sich um die Performance gar nicht so viele Gedanken machen, da uns dabei moderne Programmiersprachen / Frameworks unterstützen und mit einem gesunden Menschenverstand kann man bereits vieles abschätzen, ansonsten heißt die Devise „Profiling, Profiling… Profiling“!

– Exceptions === Ausnahmen

Man sollte Ausnahmebehandlungen niemals zur Behandlung normaler (d.h. häufig auftretender) Fehler einsetzen. Ausnahmen sind Ausnahmen und sollten aus Ausnahmen bleiben. Regulärer Code behandelt die regulären Fälle! „Verwenden Sie Ausnahmen nur ausnahmsweise“ (Pragmatische Programmierer). Und auf keinen Fall sollte man Ausnahmen “abwürgen”, z.B. durch triviale Abfangen mehreren Exceptions.

– Führe deine Arbeit zu Ende

Man sollte in einer Funktion zu Ende führen, was man begonnen hat. So sollte man z.B. „fopen()“ und „fclose()“ immer in einem Code-Block (Methode || Funktion) nutzen, weil man ansonsten darauf vertrauen müsste, dass jemand anders die entsprechende Ressourcen wieder frei gibt.

– Quelltext sollte durchsuchbar sein [Strg + F] …

Der Quelltext sollte einfach zu durchsuchen sein, daher sollte man z.B. auf String-Nesting + „&” bei Sass verzichten und auch bei PHP-Funktionen wie “extract()” vermeiden. Immer wenn Variablen nicht deklariert, sondern wie von Zauberhand (z.B.: bei PHP durch Magic-Methoden) erzeugt werden, kann man den Quelltext anschließend nicht mehr so einfach ändern.

Beispiel in PHP: (schlecht)

extract(array('bar' => 'bar', 'lall' => 1));
var_dump($bar); // string 'bar' (length=3)

Beispiel in Sass: (schlecht)

.teaser {
  font-size: 12px;

  &__link {
    color: rgb(210,210,22);
  }
}

Sass Nesting (Code-Style): https://github.com/grvcoelho/css#nesting

– Programmiere für deinen Use-Case!

Ein großes Problem in der Programmierung ist, dass man versuchen muss generalisiert zu denken und zu programmieren, so dass man den Quelltext entsprechende (einfach) erweitern kann, wenn neue Anforderungen hinzukommen bzw. auch (einfach) ändern kann.

Wie sehen IT-Projekte manchmal aus? → Ein Kunde bestellt bei einem Bauernhof 10.000 grüne Äpfel, ändert seine Bestellung am morgen vor der Lieferung auf 10.000 rote Äpfel und als diese geliefert werden möchte der Kunde aber doch lieber 10.000 Birnen und möchte diese gerne erst in 6 Monaten bezahlen.

Und gerade aus diesem Grund sollte man nur den Quelltext schreiben, der wirklich für den aktuellen Use-Case benötigt ist, denn alle Eventualitäten kann man sowieso nicht abbilden und der Quelltext wird unnötig verkompliziert.

– KISS – Keep it simple, stupid.

Man sollte immer beachten, dass der Quelltext selber gar nicht so viel Wert besitzt. Der Wert entsteht erst dadurch, dass andere Entwickler diesen verstehen und für den Kunden oder sich selbst anpassen / konfigurieren / nutzen können. Dies sollte man während der Programmierung im Hinterkopf behalten, so dass man eine Lösung möglichst nachvollziehbar und „einfach“ implementiert. Und wenn ich keine neue Klasse oder schönes Design-Pattern für das aktuelle Problem verwenden muss, sollte ich dies ggf. auch nicht tun. Was jedoch auch nicht heißt, dass man alle guten Absichten über Board werfen und überall global Variablen / Singletons einsetzten sollte. Wenn jedoch eine einfache Lösung die Aufgabe bereits erfüllt, entscheide dich für diese.

Ein gutes Beispiel wie man es nicht machen sollte, stellt die JavaScript Dom Selector API da. Nicht gerade schön zu lesen oder zu schreiben …

Schlecht: (DOM Selector via JS)

document.getElementsByTagName("div")
document.getElementById("foo")
document.getElementsByClassName("bar")
document.querySelector(".foo")
document.querySelectorAll("div.bar")

Besser: (DOM Selector via jQuery)

$("div")
$("#foo")
$(".bar")
$(".foo")
$("div.bar")

(Ich weiß welche Schreibweise ich bevorzugen würde!)

– DRY – Don’t Reapeat Yourself.

Wiederholungen / Redundanzen im Quelltext oder auch in wiederkehrenden Arbeiten, entsteht relativ schnell wenn die Leute z.B. nicht miteinander kommunizieren. Aber auch unbeabsichtigt durch Fehler im Software-Entwurf, weil man es gerade keine bessere Idee hat oder meint dafür keine Zeit zu haben.

improve

Um Wiederholungen zu vermeiden, sollte man den Quelltext bzw. den Task so ablegen, dass dieser einfach zu finden und einfach wiederzuverwenden ist, denn wenn es nicht einfach zu verwenden ist, werden die Leute es nicht nutzen.

– Der Wille etwas neues zu lernen und zu verstehen ist wichtiger als Vorkenntnisse.

Wenn man bereits z.B. ActionScript (Flash) programmieren kann, aber nicht willens ist etwas neues zu lernen dann bringt einem das vorherige Wissen nichts, denn „Die einzige Konstante im Universum ist die Veränderung.“ – Heraklit von Ephesus (etwa 540 – 480 v. Chr.)

– Lese gute Bücher und Zeitschriften.

Habe mir letztes Jahr das Ziel gesetzt mehr Fachbücher zu lesen. Dafür habe ich mir folgendes auferlegt: bevor ich ein “normales” Buch lesen darf, muss ich ein Fachbuch lesen und anschließend darf ich erst ein normales lesen …

Bücher die ich gelsen habe: https://www.goodreads.com/user/show/3949219-lars-moelleken
Free Books: https://github.com/vhf/free-programming-books/blob/master/free-programming-books.md
Bücher für Programmierer: http://stackoverflow.com/questions/1711/what-is-the-single-most-influential-book-every-programmer-should-read

– Infos: folge anderen Programmieren auf Twitter / Github / Google+ / Medium / Pocket …

http://programmers.stackexchange.com/questions/135/as-a-software-engineer-who-should-i-be-following-on-twitter

– Infos: höre Podcast & abonniere RSS-Feeds / Newsletter & schaue Videos z.B. von Web-Konferenzen

Um sich über neue Technologien, Techniken, Standards, Pattern etc. zu informieren nutzt man am besten verschiedene Medien, welche man in unterschiedlichen Situationen konsumieren kann. Ein interessanten Podcast zum Thema “Frontend Architektur” vor dem einschlafen oder ein Video zum Thema “DevOp” beim zubereiten vom Mittagessen, morgens in der Straßenbahn ein Buch lesen mit dem Titel “Weniger schlecht programmieren” … um nur ein paar Beispiele zu nennen.

Podcasts: https://github.com/voku/awesome-web/blob/master/README.md#-audio-podcast
Newsletter: https://github.com/Freizeitler/Awesome-WebDev-Newsletters
github is awesome: https://github.com/sindresorhus/awesome
and there is more: https://github.com/jnv/lists

– Besuche Meetup’s & Web-Konferenzen und rede mit anderen Entwicklern.

Meetup’s sind Gruppen von Leuten die sich regelmäßig treffen und über z.B. Python, Scala, PHP, etc. austauschen. Meistens hält jemand einen Vortrag zu einem vorher abgestimmten Thema.

-> http://www.meetup.com/de-DE/members/136733532/

Web-Konferenzen machen Spaß. Punkt. Und jeder Entwickler / Administrator sollte diese besuchen, da man neue Eindrücke gewinnt und wirklich gute Leute trifft. Einige Konferenzen sind wirklich teuer, aber hier sollte man sich an seinen Arbeitgeber wenden, ggf. wird dies von der Firma übernommen. Außerdem gibt es auch wirklich günstige Konferenzen.

– Schreibe Antworten bei quora.com || stackoverflow.com || in Foren || deinem Blog …

Um sich selber mit einer bestimmten Thematik auseinander zu setzten und
wirklich zu verstehen, lohnt es sich zu recherchieren und einen Text (ggf. sogar einen Vortrag) zu verfassen, welchen andere lesen und kritisieren und somit verbessern können.

– Bleib nicht jeden Tag so lange auf der Arbeit, ansonsten wartet Zuhause irgendwann keiner mehr auf dich!!!

Bei all der Begeisterung für den “Job” (auch wenn es Spaß macht) sollte man die wirklich wichtigen Dinge nicht aus den Augen verlieren. Wieder etwas was ich auf die hart Tour lernen musste. :/

HTTP/2: Welchen Vorteil bringt der neue Webstandard?

Diesen Artikel habe ich bereits im Firmen Blog von menadwork GmbH veröffentlicht: Düsseldorf, am 04.11.2015 von Lars Moelleken

Der im Mai 2015 veröffentlichte Webstandard HTTP/2 bewirkt, dass Webseiten schneller angezeigt werden. Die Kompatibilität von HTTP/2 ist in fast allen aktuellen Webbrowsern gegeben, wer dies jedoch einsetzen will muss zwangsläufig ein SSL-Zertifikat einsetzen, so dass die Webseite verschlüsselt übertragen wird.

In Kürze vorab:

Haben Browser und Ser 73_221_de_ ver im vorherigen HTTP/1.x Standard aus dem Jahr 1996 noch sehr viel Zeit mit „Warten“ verbracht, können durch den neuen Webstandard HTTP2 Webseiten schneller angezeigt werden.

Die Kompatibilität von HTTP/2 ist in fast allen aktuellen Webbrowsern gegeben – ein guter Grund, auf das neue Protokoll zu setzen. Serverseitig unterstützt der Apache Webserver (v2.4.17) den entsprechenden Webstandard.

73_222_de

Wer HTTP/2 einsetzen will muss zwangsläufig ein SSL-Zertifikat einsetzen, so dass die Webseite verschlüsselt (via https://) übertragen wird.

Und nun zu den Details …

Grundsätzliches: So funktioniert das Internet

73_224_de

Um zu erklären, was HTTP/2 ist, sollte man zuerst verstehen wie das Internet grundsätzlich funktioniert. Alle Daten im Computer und auch im Internet sind digital, das bedeutet so viel wie „die Daten werden intern binär verarbeitet“ (z.B. a => 01100001, b => 01100010, c => 01100011).

Um diese Daten nun an einen anderen Computer zu übertragen, benötigt jeder Computer, jedes Smartphone usw. eine eindeutige Adresse, die sogenannte IP-Adresse.

Die Daten werden bei der Übertragung im Internet bzw. im Netzwerk zu sogenannten Paketen zusammengefasst. Jedes Paket wird zusätzlich mit der Information bestückt von welcher IP-Adresse diese gesendet und an welche IP-Adresse diese gesendet werden sollten, solche Informationen nennt man Header-Informationen.

Um nun eine Verbindung von einem zum anderen Computer herzustellen, nutzt man sogenannte Netzwerkprotokolle: Diese definieren einen Standard, so dass unterschiedliche Systeme miteinander kommunizieren können. Im Internet werden UDP (User Datagram Protocol) bzw. TCP (Transmission Control Protocol) verwendet.Das Netzwerkprotokoll UDP ist im Gegensatz zu TCP verbindungslos, d. h. es wird keine eindeutige Verbindung aufgebaut. UDP wird z. B. verwendet um eine Domain (menadwork.com) in die entsprechende IP-Adresse aufzulösen.

Diese Netzwerkprotokolle nutzen unterschiedliche Ports, welche man sich wie Türen vorstellen kann: Jeder Computer hat – ähnlich einem Haus – eine eindeutige Adresse (IP-Adresse) und bietet Platz für unterschiedliche Dinge. diese Dinge können z. B. Webseiten (Port:80), E-Mails (Port:143) oder Dateien (Port:21) sein. Dies ist der Grund, warum man beispielsweise eine Webseite auch wie folgt aufrufen kann: “menadwork.com:80“.

Auch diese Ports sind zumindest von 0 bis 1023 mit fest definierten Anwendungsprotokollen (z. B. HTTP: 80, IMAP: 143, FTP: 21) belegt, so dass man verschiedene Anwendungen über TCP bzw. UDP ansteuern kann.

Die Einführung von HTTP/1.0 und HTTP/1.1

HTTP (Hypertext Transfer Protocol) wurde zusammen mit den Konzepten für die URL und HTML geschaffen und 1996 als HTTP/1.0 publiziert. Für jede verknüpfte Datei in einem HTML-Dokument – wie z. B. Bilder – wurde eine neue TCP-Verbindung aufgebaut.

Im Jahr 1999 wurde dann HTTP/1.1 publiziert, welches unter anderem Pipelining ermöglicht: Dabei werden mehrere HTTP-Anfragen über eine TCP/IP-Verbindung geschickt, so dass man den Overhead beim Verbindungsauf- und -abbau nicht bei jeder HTTP-Anfrage (Bilder, JavaScript-Dateien oder CSS-Dateien) hat. Jedoch ist dieses Feature bei fast allen Browsern standardmäßig deaktiviert und kann somit meistens nicht genutzt werden. Zudem kollidiert hier mal wieder Theorie und Praxis, da zwar theoretisch mehrere Anfragen direkt nacheinander abgearbeitet werden können, aber das sogenannte “head-of-line blocking”-Problem tritt auf: Denn die Anfragen werden noch immer nach dem FIFO-Prinzip (First In – First Out) verarbeitet und die erste Anfrage muss vor der zweiten Anfrage vom Server verarbeitet werden. Man kann sich dies wie die Kasse beim Supermarkt vorstellen: Nur, weil man mehrere Kunden an einer Kasse bedient heißt dies nicht, dass diese schneller bedient werden, solange man auch hier nach dem FIFO-Prinzip arbeitet.

Der neue Webstandard HTTP/2

HTTP/2 wurde im Mai 2015 veröffentlicht und unterstützt unter anderem das Zusammenfassen von mehrere HTTP-Anfragen über ein Multiplexverfahren. Beim Multiplexen werden Daten gebündelt und gemeinsam übertragen. Außerdem werden die Daten und Header nun komprimiert übermittelt und Daten werden binär kodiert übermittelt.

Webseite via HTTP/1.1 laden	Webseite via HTTP/2 laden
1. Erstellt sechs bis acht HTTP-Verbindungen zum Server	1. Erstellt eine Verbindung zum Server
2. Anfrage der HTML-Seite	2. Anfrage der HTML-Seite
3. Empfang der HTML-Seite	3. Empfang der HTML-Seite
4. Decode der HTML-Seite	4. Decode der HTML-Seite
5. Erstellt sechs bis acht Verbindungen zu Dateien in der HTML-Seite, ohne Prioritäten (unkomprimierten, plain-text Header)	5. Empfang von allen Dateien in der HTML-Seite, mit Prooritäten (komprimierte, binary Header)
6. Die Verbindung wartet, bis die angeforderte Datei ankommen ist	(Dateien werden über den gemultiplexten Stream gesendet)
7. Fordert die nächste Datei, auf der jetzt offenen Verbindung an	—
8. Wiederhole Punkt 6-7 bis alle Dateien angekommen sind	—
9. Schließe sechs bis acht HTTP-Verbindungen	8. Schließe die eine Verbindung

Quelle: https://www.nginx.com/wp-content/uploads/2015/09/NGINX_HTTP2_White_Paper_v4.pdf

73_227_de

Statement von Google: “Google observed an ~88% reduction in the size of request headers and an ~85% reduction in the size of response headers after enabling compression. This amounted to a saving of between 45 and 1142 ms in the overall page load time.” Quelle: http://www.chromium.org/spdy/spdy-whitepaper

Diese binären Daten werden als Streams bezeichnet und können mit unterschiedlichen Priorisierungen angefordert werden, zum Beispiel 1. HTML, 2. JavaScript, 3. CSS, 4. Fonts, 5. Bilder. Zudem kann man theoretisch mit der Funktion “Server-Push” auch Dateien zum Client senden, welche dieser gar nicht angefragt hat, so könnte man HTML, CSS und Font senden, wenn nur das HTML angefragt wurde, jedoch ist dieses Funktion z. B. in der aktuellen Version von Apache (v2.4.17) noch nicht implementiert.

Im offiziellen Standard ist HTTP/2 zwar auch ohne SSL (https://) geplant, aber die Browser-Hersteller bieten HTTP/2 nicht ohne Verschlüsselung an. Da SSL-Zertifikate jedoch momentan nicht kostenlos sind, haben Mozilla, die Electronic Frontier Foundation (EFF), Cisco, Akamai und IdenTrust eine neue SSL-Zertifizierungsstelle (CA) mit dem Namen “Let’s Encrypt” gegründet, welche in Zukunft kostenlose Zertifikate ausstellt.

UPDATE: (04.11.2015)

Let’s Encrypt hat heute sein Beta-Programm gestartet, sodass man über wenige Zeilen auf der Kommandozeile bereits ein gültiges SSL-Zertifikat nutzen kann.

  git clone https://github.com/letsencrypt/letsencrypt
  cd letsencrypt
  ./letsencrypt-auto --agree-dev-preview --server \
  https://acme-v01.api.letsencrypt.org/directory certonly

Wer noch einen weiteren Grund benötigt, seine Webseite über eine verschlüsselte Verbindung (SSL) auszuliefern, der sollte sich das neue Feature von Firefox 44 anschauen, welches eine Warnung anzeigt, wenn Login-Daten über eine nicht verschlüsselte Verbindung übermittelt werden.

Was ändert sich für Webentwickler?

Jede Technik, welche HTTP-Anfragen reduziert, ist mittels HTTP/2 obsolet, da einzelne kleine HTTP-Anfragen nun schneller abgearbeitet werden als eine große Anfrage. Zu diesen Techniken zählen z. B. das Zusammenfassen (concat) von JavaScript- und CSS-Dateien oder auch das Sprite-Image, welches mehrere kleine Bilder zu einem Bild darstellt. Aber auch das aufteilen von HTTP-Request auf verschiedene Subdomains ist nicht länger sinnvoll, da ansonsten wieder neue TCP-Verbindungen aufgebaut werden müssen. Zudem ist das „Inlinen“ von z. B. Bildern via Data-URIs (data:image:png;base64,…) nicht mehr zweckmäßig.

Mit der „Server-Push-Funktion“ können bereits einige Webserver umgehen, so dass man serverseitig bestimmen kann, dass bestimmte Dateien zusätzlich ausgeliefert werden sollen, wenn z. B. eine HTML-Datei angefragt wird. Dafür müssen in den meisten Fällen bestimmte Header-Daten definiert werden (z. B. X-Associated-Content: “/foo.css”:1,”/bar.js”:1,”/baz.js”:1).

Alle diese Änderungen spielen Frameworks wie Polymer in die Hände, da der Quelltext hier in einzelne Pakete bzw. Komponenten geordnet ist und somit schneller übertragen werden kann.

Was ändert sich für Administratoren?

Administratoren müssen zunächst Server aktualisieren, da z. B. nur die aktuelle Version von Apache (v2.4.17) HTTP/2 unterstützt. Darüber hinaus müssen Pakete für die verschiedenen Linux-Distributionen müssen gebaut werden.

Indem via HTTP/2 die HTTP-Anfragen über eine TCP-Verbindung laufen, werden weniger Verbindungen pro User zum Server aufgebaut, der Web-Server benötigt weniger Speicher und die CPU-Last wird verringert.

HTTP	HTTPS	SPDY (HTTP/2)
Max. pages/s	16.3 @ 120 users	15.9 @ 120 users	98 @ 777 users
Response @ 100 users	1.1s	1.3s	1.1s
Response @ 120 users	1.4 s	1.5s	1.1s
Response @ 200 users	7.1s	7.8s	1.1s
Response @ 777 users	70.2s	72s	2.7s
First error	405 Users	225 Users	884 Users

Quelle: http://www.neotys.com/blog/performance-of-spdy-enabled-web-servers/

Server-Anfrage	Speicherverbrauch (für die selbe Beispiel-Anfrage)
HTTP	59 MB
HTTPS	79 MB
SPDY (HTTP/2)	24 MB

Quelle: http://www.neotys.com/blog/performance-of-spdy-enabled-web-servers/

Vergleich der Ladezeiten

73_232_de

Außerdem sollte man sich ein wenig mehr mit dem Thema SSL auseinandersetzen, so kann man z. B. über den “Strict Transport Security“-Header die Ladezeit von HTTP/2 Seiten weiter reduzieren. Dies geschieht, indem die Nutzung von HTTPS sozusagen gecacht wird und Anfragen via HTTP direkt via HTTPS verarbeitet werden.

Quellen:

Apache & HTTP/2: http://www.apache.org/dist/httpd/CHANGES_2.4.17
“Can I use” HTTP/2: http://caniuse.com/#search=http%2F2
Info zu HTTP/2: http://http2-explained.readthedocs.org/en/latest/
FAQ zu HTTP/2: https://http2.github.io/faq/
Spec zu HTTP/2: https://http2.github.io/http2-spec/
Präsentation zu HTTP/2 (von @derSchepp): https://schepp.github.io/HTTP-2/#/
Präsentation zu HTTP/2 (von @mnot): https://www.mnot.net/talks/http2-expectations/#/
W3C – preload: http://w3c.github.io/preload/
nghttp2 – Server-Push: https://nghttp2.org/documentation/nghttpx.1.html#server-push
heise: HTTP/2: http://www.heise.de/netze/artikel/Wie-HTTP-2-0-das-Surfen-beschleunigt-2164146.html
Free SSL: https://letsencrypt.org/2015/10/19/lets-encrypt-is-trusted.html
heise: Free SSL: http://www.heise.de/netze/meldung/Let-s-Encrypt-Meilenstein-zu-kostenlosen-SSL-Zertifikaten-fuer-alle-2679600.html

Demos:

https://http2.akamai.com/demo
http://http2.golang.org/gophertiles?latency=0

[Update] Top Chrome Erweiterungen für Webdeveloper

Tipps zu Chrome:

in Chrome kann man verschiedene User anlegen, welche auch unterschiedliche Chrome-Erweiterungen installieren können (man kann z.B. einen Privacy-User anlegen): chrome://settings/
die DevTools sollte man kennen: https://speakerdeck.com/addyosmani/whats-new-in-chrome-devtools
Chrome-Extensions kann man auch ganz einfach selber erstellen:

Code: https://github.com/voku/Web-Analyse-Tools-for-Chrome

Demo: https://chrome.google.com/webstore/detail/web-development-analysis/ebhbpdaejpgndphbdcphdiefknmeciph

Beispiele: https://developer.chrome.com/extensions/samples)

Dev-Tools:

Name	Url	Info
Accessibility Developer Tools	Link	Barrierefreiheit von Webseiten Testen via Chrome-Dev-Tools
Blackfire Companion	Link	PHP: Better app performance with a low-overhead Profiler
Caspr: Enforcer	Link	Content Security Policy (CSP) Änderungen prüfen und testen
Codecov Extension	Link	Code-Coverage Report-Overlay innerhalb von Github und Bitbucket
Ember Inspector	Link	Debugging für Ember-Anwendungen
GitHub Linker	Link	Verlinkte Packages via npm, bower, composer etc.
GitHub Mate	Link	Extra Features für github.com z.B. Download-Button
HTML5 Outliner	Link	Zeigt eine Übersicht über alle Inhalte einer Webseite an, wenn HTML korrekt ver
HTTP/2 and SPDY indicator	Link	Zeigt in der Adresszeile an, ob HTTP/2 verwendet wird
JetBrains IDE Support	Link	HTML/CSS/JavaScript editing and JavaScript debugging using JetBrains IDEs
JetBrains Toolbox Extension	Link	Adds link to open project from GitHub in JetBrains IDEs
JSON Editor	Link	JSON Editor, welcher sowohl einen Daten-Tree in JSON also auch JSON in einen Daten-Tree konvertieren kann
JSONView	Link	Validiert und zeigt JSON an
LiveReload	Link	CSS kann ohne Browser-Reload aktualisiert werden (siehe z.B. grunt-contrib-watch)
Lovely forks	Link	Zeigt Forks auf github.com Seiten an
Octotree	Link	Zeigt GitHub-Code in einer Baumstruktur dar
SelectorGadget	Link	CSS (xPath) Elemente auf Webseiten per Maus auswählen
Web Developer Checklist	Link	Schnelle Check-Liste für Webseiten (Favicon, robots.txt, …)
WAVE Evaluation Tool	Link	Barrierefreiheit-Overlay für Webseiten

Privacy-Tools:

Name	Url	Info
AdBlock	Link	Entfernt Werbung von Webseiten …
Deaktivierungs-Add-on von Google Analytics	Link	Weist das JavaScript (ga.js) von Google Analytics an, keine Informationen an Google Analytics zu übermitteln
Disconnect	Link	Ein weites Privacy-Tool …
HTTPS Everywhere	Link	Sichern Sie Ihre Internetverbindung! Automatische HTTPS-Sicherheit auf vielen Webseiten
uBlock	Link	Ein effizienter Blocker …
uMatrix	Link	Kontrolliere alle Anfragen deines Browsers …

Organisation- / Extra-Tools:

Name	Url	Info
Boards for Trello	Link	Schnellzugriff auf trello.com
Der Camelizer	Link	Einfaches Anzeigen historischen Preisdaten direkt in Amazon
feedly	Link	Ein sehr guter RSS-Reader
Google Cast	Link	Senden Sie Inhalte an Ihren Chromecast und andere Geräte, die Google Cast unterstützen.
Lazarus: Form Recovery	Link	Speichert alle Daten von Formularen ab, so dass diese Informationen nicht verloren gehen
SimpleExtManager	Link	Eine schnelle Verwaltung für Chrome-Erweiterungen
Tabs Outliner	Link	Session- und Tab-Manager für Chrome
OneTab	Link	Tabs in einer Liste zusammenfassen, um Speicher zu sparen
Save to Pocket	Link	Speicher Artikeln, Videos und mehr …
Web Timer	Link	Zeigt an wie viel Zeit man auf den jeweiligen Webseiten verbringt

HTTP/2 ist angekommen | Apache 2.4.17

Was ist HTTP/2? Diese Frage haben andere bereits ausführlich geklärt. https://http2.github.io/faq/ :) daher wollen wir dies heute in Kombination mit dem Apache Webserver ausprobieren.

Im Februar 2015 hat Google den Support für SPDY bereits zugunsten von HTTP/2 eingestellt. Und die Kompatibilität von HTTP/2 ist in fast allen aktuellen Webbrowsern gegeben, so das es bereits seit einiger Zeit keinen Grund gibt, nicht auf das neue Protokoll zu setzen. Seit dieser Woche unterstützt auch der Apache Webserver (2.4.17) das Protokoll, “Stefan Eissing” hat das Module “mod_http2” gesponsert, welches wir im folgenden testen werden.

Installation unter Ubuntu 14.04 via Fremdquellen (PPA)

Warnung: “Zusätzliche Fremdquellen können das System gefährden.”
–> https://wiki.ubuntuusers.de/paketquellen_freischalten/ppa

Zu beginn stellen wir sicher, dass SPDY nicht mehr verwendet wird.

a2dismod spdy

Und deinstallieren dies am besten direkt, falls dies über den Paket-Manager installiert wurde.

apt-get purge mod-spdy-beta

service apache2 restart

Um die Quellen (/etc/apt/sources.list.d/) nicht manuell zu ändern, installieren wir kurzerhand das Programm “add-apt-repository” via:

aptitude install software-properties-common

# Web: https://launchpad.net/~ondrej/+archive/ubuntu/apache2
# Issues: https://github.com/oerdnj/deb.sury.org/issues
#
add-apt-repository ppa:ondrej/apache2

Falls es beim Hinzufügen des Keys zu Problem kommt, kann man dies auch manuell durchführen:

apt-key adv –keyserver keyserver.ubuntu.com –recv-keys 4F4EA0AAE5267A6C

Anschließend installieren wir das Update via “aptitude“, sodass wir mehr Kontrolle über den Update-Prozess haben.

apt-get update; aptitude

Nach der Installation können wir das “http2”-Module wie folgt aktivieren.

cd /etc/apache2/mods-available/

vim http2.load

# Depends: setenvif mime socache_shmcb
LoadModule http2_module /usr/lib/apache2/modules/mod_http2.so

vim http2.conf

<IfModule http2_module>
ProtocolsHonorOrder On
Protocols h2 h2c http/1.1
</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Und anschließend muss das Module nur noch aktiviert werden:

a2enmod http2

service apache2 restart

Um zu testen, ob HTTP/2 via https genutzt wird, können wir z.B. direkt im Chrome nachschauen. Dafür öffnen wir einfach die Seite chrome://net-internals und nutzen oben links im DropDown-Menü den Punkt “HTTP/2”.

Quellen:

Apache + HTTP/2: http://www.us.apache.org/dist//httpd/CHANGES_2.4.17
Nginx + HTTP/2: http://mailman.nginx.org/pipermail/nginx-devel/2015-September/007328.html
HowTo: https://icing.github.io/mod_h2/howto.html
Repo: https://launchpad.net/~ondrej/+archive/ubuntu/apache2
Präsentation: http://slidedeck.io/Schepp/HTTP-2
Demo: https://http2.akamai.com/demo

Mr. Robot | Staffel 1, Folge 1 in a nutshell

Die Fernsehserie folgt einem jungen Programmierer (Elliot), der von dem mysteriösen Mr. Robot für eine Hackergruppe rekrutiert wird und wer die Serie bisher noch nicht geschaut hat, sollte dies nachholen.

In Folge 1 muss Elliot einen Rootkit ausfindig machen, viel mehr werde ich an dieser Stelle nicht vorwegnehmen. Viele der folgenden Befehle sind nicht ohne weiteres auf jedem Linux System auszuführen oder es gibt diese gar nicht. Jedoch versteht bzw. sieht man was diese bewirken sollen.

1. Status

Um das Problem vom Büro aus zu analysieren, werden zunächst Netzwerk und Dienste geprüft.

status -scanports -s WBUSl12345678WB1 -p[80-7655]

Hier hat Elliot sich anscheinend eine Shell-Funktion geschrieben, welche einen Portscan auf der Server “WBUSl12345678WB1” mit der Port-Range 80 bis 7655 durchführt.

Der folgender Befehl würde wirklich funktionieren.

nmap WBUSl12345678WB1 -p80-7655

Als nächstes wird anscheinend geprüft welche Prozesse momentan auf dem Remote-Server ausgeführt werden.

status -services -s WBUSl12345678WB1

Dies könnte auch eine selbst programmiere Shell-Funktion sein, welche sich auf dem Remote-Server einloggt und die Prozesse z.B. via “ps aux” auflistet.

ssh user@WBUSl12345678WB1 ‘ps aux’

Resultat: Die Services sind nicht mehr erreichbar und anscheinend läuft auf dem Server ein Xorg. ;) Da der Fehler nicht einzugrenzen ist, wird Elliot (mit dem Jet) zum Rechenzentrum geflogen, um den infizierten Server zu lokalisieren und zu isolieren. *freu*

2. Ping

Der Befehl selbst ist in der Sequenz nicht zu sehen aber dies könnte so ähnlich aussehen.

fping -g 194.122.82.0/24

Resultat: Ein Server ist noch aktiv, dies muss der Übeltäter sein …

3. Locate WBKUW300PS345672

Der gehackte Server soll in der nächsten Szene manuell durch den Backup-Server ersetzt werden. Es wird der Befehl “Locate” ausgeführt, um sich zunächst an dem gehacktem Server anzumelden.

Der “locate” Befehl ist eigentlich zum suchen von Dateien gedacht, aber diese wird ja auch klein geschrieben.

4. astsu

Hier wird außerdem der fiktive Befehl “astsu” ausgeführt, um Informationen vom Netzwerk-Informationen vom Server zu erhalten.

Folgende Befehle funktionieren tatsächlich…

DNS:

cat /etc/resolv.conf

IP:

ifconfig

ROUTING:

route

In der nächsten Szene sehen wir sowohl die vorherigen aus auch die nächsten Befehle welche auf der Konsole eingegeben wurden.

astsu -close port: * -persistent

Und wie wir sehen übernimmt der Befehl “astsu” auch noch die Funktionalität von “iptables“. ;)

Locate BKUW300PS345672

Hier kommt nocheinmal der “Locate” Befehl zum Einsatz, um sich auf den Backup-Server einzuloggen.

set waneth0* : * 23.234.45.1 255.255.255.0 [45.85.123.10; 45.85.124.10; 45.85.125.10]

Im Output kann man ein “false” sehen, aber Elliot verwendet “-force” um dieses Problem zu lösen. Natürlich ist auch diese Befehl ausgedacht, aber viele andere Linux Kommandos akzepieren ebenfalls einen “–force” Parameter, daher ist dies gar nicht so abwegig.

set -force -ovr02 waneth04 : 23.234.45.62:441 23.234.45.1 255.255.255.0 [45.85.123.10; 45.85.124.10;

Um die IP-Adresse wirklich zu konfigurieren kann man z.B. “ifconfig & route” oder “ip” verwenden.

ip addr add 45.85.123.10/24 dev eth0

ip addr add 45.85.124.10/24 dev eth0

ip addr add 45.85.125.10/24 dev eth0

ip route add default via 23.234.45.1

Resultat: Der gehacket Server ist offline und der Backup-Server hat dessen Funktion übernommen.

5. ps aux | grep root

ps aux | grep root

Nachdem die Gefahr gebannt ist, schau Elliot sich den gehackten Server noch einmal genauer an und findet einen Prozess (pid: 24) welcher mit höchster Priorität (-20) läuft.

astu trace -pid 244 -cmd

Hier tauch eine abgewandelte Version vom fiktiven Befehl “astsu” auf, warum die pid 244 und nicht die 24 weiter untersucht wird, bleibt ungeklärt.

Um einen Prozess tatsächlich näher zu untersuch, würde ich zunächst folgende Befehle nutzen.

strace -p 24

lsof -p 24

Beispiel für “strace” & “lsof”

6. ps aux | grep root | cpuset

ps aux| grep root | cpuset

“cpuset” würde hier nicht funktionieren und ich bin mir nicht ganz sicher was “cpuset” überhaupt macht?!

astu -ls ./root/fsociety/ -a

Nun wird der Inhalt vom Verzeichnis “/root/fsociety/” angezeigt, folgender Befehl würde funktionieren.

ls -la /root/fsociety/

Elliot schau sich nun die README Datei der Hacker an und möchte den Rootkit zunächst im folgenden löschen.

more readme.txt

astu -rm -norecycle /root/ fsociety/

Um das Verzeichnis wirklich zu löschen, müsste der folgende Befehl ausgeführt werden.

rm -rf /root/fsociety/

Aber er entscheidet sich dagegen und ändert stattdessen die Berechtigungen der Datei, so dass nur noch er selber Zugriff darauf hat.

chmod -R ER280652 600

Auch dieser Befehl wird so nicht funktionieren, da man “chmod” und “chown” unterscheidet. Folgende Befehle würden funktionieren.

chmod -R 600 /root/fsociety/

chown -R ER280652 /root/fsociety/

Resultat: Der ursprüngliche Server ist offline, der Backup-Server ist online und der Rootkit ist noch immer im System.

Fazit: echo “Ich mag diese Serie.” | sed ‘s/Serie/Nerd-Serie/’

Guideline für Open Source Software

SLIDES

Was ist Open Source Software?
Wo veröffentliche ich Open Source Software?
Welche Open Source Software Standards gibt es?
1. Lizenz
2. Quellcode-Organisatzion
3. Dokumentation
4. Kommunikation
5. Versionsnummern
6. Abhängigkeitsmanagement
7. Testabdeckung
8. Issue-Tracking-System
Wie veröffentliche ich Open Source Software?
1. Beispiel: npm
2. Beispiel: bower
3. Beispiel: composer
Beispiel-Repository

1. Was ist Open Source Software?

Freiheit 0: Das Programm zu jedem Zweck auszuführen.

Freiheit 1: Das Programm zu untersuchen und zu verändern.

Freiheit 2: Das Programm zu verbreiten.

Freiheit 3: Das Programm zu verbessern und diese Verbesserungen zu verbreiten, um damit einen Nutzen für die Gemeinschaft zu erzeugen.

1.1 Geschichte

1893: AT&T wird gegründet

1911: IBM wird gegründet

1969: AT&T beginnt mit der Entwicklung eines quelloffenes Betriebssystem – Unix

1972: Dennis Ritchie veröffentlciht die Programmiersprache – C

1975: Microsoft wird von Bill Gates und Paul Allen gegründet

1976: Apple wird von Steve Jobs, Steve Wozniak und Ron Wayne gegründet

1977: Universität von Kalifornien in Berkeley entwickelt einen Fork von Unix – BSD

1980: Unix wird proprietär

1981: 86-DOS wird von Microsoft gekauft und an IBM verkauft ~ MS-DOS

1984: Richard Stallman beginnt mit der Entwicklung eines freien Betriebssystems – GNU

1985: Richard Stallman gründet eine gemeinnützliche Organisation – Free Software Foundation

1985: NeXT wird von Steve Jobs gegründet

1987: IBM und Microsoft veröffentlichen ein proprietäres Betriebssystem – OS/2

1987: Andrew S. Tanenbaum Minix veröffentlichen ein freies Betriebssystem – Minix

1988: MIT-Lizenz wird veröffentlicht

1988: NeXT, Inc. veröffentlicht ein proprietäres Betriebssystem, ein Fork von BSD – NeXTStep

1989: Richard Stallman schreibt eine Lizenz für Freie Software: GNU General Public License

1991: Linus Torvalds entwickelt einen freien Kernel – Linux

1993: Ian Murdock beginnt mit der Entwicklung eines freien Betriebssystems – Debian (GNU/Linux)

1993: Open-Source-Community veröffentlicht ein freies unixoides Betriebssystem – FreeBSD 1.0

1993: Microsoft veröffentlicht ein proprietäres Betriebssystem – Microsoft_Windows_3.1

1995: Rasmus Lerdorf entwickelt eine Skriptsprache für Webanwendungen – PHP

1995: Sun Microsystems entwickelt eine objektorientierte Programmiersprache – Java

1995: Netscape entwickelt eine Skriptsprache für Client-Webanwendungen – JavaScript

1996: erste Version des Betriebssystems Debian wird veröffentlicht – Debian 1.1 (GNU/Linux)

1998: Goolge wird von Larry Page und Sergey Brin gegründet – Google

1998: Organisation, zur Förderung von Open-Source-Software wird gegründet – OSI

2000: Apple veröffentlicht ein freies unixoides Betriebssystem, einen Fork von NeXTStep (FreeBSD) – Darwin

2001: Microsoft veröffentlicht ein proprietäres Betriebssystem – Microsoft Windows XP

2001: ein freies Onlinelexikon geht online – Wikipedia

2001: gemeinnützliche Organisation für freie Software (Europa) wird gegründet – FSFE

2001: gemeinnützliche Organisation für freie Lizenzen wird gegründente – Creative Commons

2002: freie Software wird im deutschen Urhebergesetz rechtskräftig – Linux-Klausel

2003: ein freie Software zur Verwaltung von Websiten wird veröffentlicht – WordPress

2005: Linux Torvalds beginnt mit der Entwicklung einer freien Versionsverwaltung – git

2008: Google Chrome (freeware) / Chromium (free) wird veröffentlicht – Chrom[e|ium]

2008: Google veröffentlicht ein freies Betriebssystem – Android

2009: Joyent Inc. entwickelt freie serverseitige Plattform für Netzwerkanwendungen – NodeJS

2012: Microsoft veröffentlicht ein proprietäres Betriebssystem – Microsoft Windows 8

2013: Mozilla veröffentlicht ein freies Betriebssystem – Firefox OS

2014: Open-Source-Community veröffentlicht ein freies unixoides Betriebssystem – FreeBSD 10 .0

2015: Linus Torvalds veröffentlicht eine neue Version seines freien Kernels – Linux 4.0

…

Umsatz: Um zu verdeutlichen, wie viel Geld mit Software (Computer) verdient werden kann, auch mit Open Source Software …

Apple: 182,8 Mrd. USD (2014)
AT&T: 128,8 Mrd. USD (2013)
IBM: 92,8 Mrd. USD (2014)
Microsoft: 85,8 Mrd. USD (2014)
Google: 66 Mrd. USD (2014)
Red Hat: 1,33 Mrd. USD (2013)
Mozilla: 0,3 Mrd. USD (2013)
Canonical (Ubuntu): 0,065 Mrd. USD (2014)

1.2 Freie Software ⊆ Open Source Software

Man kann “Freie Software” als Teilmenge von “Open Source Software” verstehen, wobei der Begriff “Open Source” erst später eingeführt wurde, da man freie Software als geschäftsfreundlich und weniger ideologisch belastet darstellen wollte. Außerdem wollte man dem Begriffsproblem von „free software“ entgegenwirken, denn auch wenn viele freie Software kostenlos (free) ist, ist dies keine “freeware”.

Für die Definition von freier Software findet man folgenden Satz auf der GNU/GPL Webseite: To understand the concept, you should think of “free” as in “free speech,” not as in “free beer”.

Freie Software gewährt demnach dem Nutzer Freiheiten, was bei proprietärer Software nicht der Fall ist: z.B.:

https://govtrequests.facebook.com/: Hier kann man nachlesen, wie viele Anfragen die entsprechenden Regierungen an Facebook gestellt haben, um an unsere Informationen zu kommen oder uns bestimmte Informationen vorzuenthalten.

http://www.heise.de/newsticker/meldung/Amazon-loescht-gekaufte-Kindle-eBooks-6887.html: Hier hat Amazon Kindle-eBooks (“1984” und “Animal Farm” von George Orwell) von extern gelöscht, da der Verkäufer die nötigen Rechte zum verkaufen gar nicht besaß.

http://blogs.technet.com/b/mmpc/archive/2014/01/09/tackling-the-sefnit-botnet-tor-hazard.aspx: Hier wurde ebenfalls Software von extern gelöscht – Microsoft löscht Tor-Software nach Trojaner-Befall.

1.3 Lizenzen

Es gibt es mittlerweile (zu) viele verschiedene Open Source Lizenzen und Lizenz-Versionen, welche teilweise nicht einmal miteinander kompatibel sind, so z.B. bei GPLv2 und GPLv3 welche man nicht gemeinsam in einem Programm nutzen darf: https://www.gnu.org/philosophy/license-list.html

Allgemein kann man die verschiedenen Open Source Lizenzen jedoch in folgende Kategorien einteilen: Copyleft / Copyright

Copyleft ist eine Form von freier Software, bei der die Freiheit des Endanwenders hervorgehoben wird und die Freiheit der Programmierer hinten anstellt, so kann (darf) man z.B. “Google APIs Client Library for PHP” nicht für WordPress-Plugins verwenden, da diese Bibliothek nicht mit GPL kompatibel ist.

Art des Copyleft	Starkes Copyleft	Schwaches Copyleft	kein Copyleft
Kombinationsmöglichkeit mit proprietärer Software	keine Einbindung in proprietären Code möglich	statisches und dynamisches Linken von Code mit proprietärer Software möglich. Eigen-Entwicklungen dürfen als proprietäre Software weitergegeben werden	darf auch in proprietäre Software verwendet werden
Beispiel-Lizenz	GPL	LGPL, MPL	BSD, Apache, MIT

1.4 Geschäftsmodelle

Beispiele:

– Adobe Systems veröffentlicht Flex (Apache License 2.0) und verkauft die Flash Builder IDE.
– Apple Inc. veröffentlicht Darwin (Apple Public Source License) und verkauft Mac OS X.
– Asterisk (PBX), verkauft Hardware auf welcher Open Source Software (GPL) läuft.
– Codeweavers verkauft CrossOver (proprietär + LGPL) und nutzt dafür als Grundlage Wine (LGPL)
– Canonical Ltd. bietet Ubuntu als Open Source an und bietet technischen Support gegen Zahlung an.
– Mozilla Foundation lässt sich von Google, Yahoo und anderen Unternehmen bezahlen, um z.B. die entsprechende Suchmaschine in Mozilla Firefox zu integrieren.
– Oracle bietet MySQL als Open Source Version (GPL) und als Enterprise Version (proprietär) mit Support und zusätzlichen Features an.

2. Wo veröffentliche ich Open Source Software?

Allein durch die Veröffentlichung von Quellcode entsteht zur noch keine Open Source Software, aber es bleibt die Grundvoraussetzung. Mittlerweile gibt es viele Plattformen, welche sich auf Quellcode-Repositories spezialisiert haben, dabei hat man sich inoffiziell bereits darauf geeinigt, dass “github.com” als Standard für Open Source Software angesehen wird. Sowohl npm, composer als auch bower nutzen github.com als Standard-Repository.

3. Welche Open Source Software Standards gibt es?

Unix ist der Ursprung von Open Source und die Unix-Philosophie von ~1970 lässt sich noch immer auf heutige Software Projekte anwenden: „Mache nur eine Sache und mache sie gut.“

– Schreibe Computerprogramme so, dass sie nur eine Aufgabe erledigen und diese gut machen. (Packages?)
– Schreibe Programme so, dass sie zusammenarbeiten. (REST?)
– Schreibe Programme so, dass sie Textströme verarbeiten, denn das ist eine universelle Schnittstelle. (JSON?)

Es gibt viele inoffizelle Standards bei Open Source Projekten, welche ggf. jedoch auch erst von der Community erstellt oder / und überhaupt erst im laufe des Projektes erstellt werden.

3.1 Open Source Lizenz für Software angeben (z.B.: LICENSE.txt)
– kann man verwenden: GPL, LGPL, MIT, BSD3
– sollte man ggf. vermeiden: Creative Commons, Beerware, WTFPL
– CLA (Contributor License Agreement) beachten: z.B.: Zend Framework 1

3.2 Quellcode Organisatzion (z.B. “src/”, “tests/”, “lib/”)
– Wie heißt das Verzeichnis für Tests?
– Wo findet man die Abhänigkeiten (vendor)?
– Wo findet man den Quellcode?

3.3 Dokumentation für Entwickler und Anwender
– Beschreibung, Code-Beispiele, Testabdeckung, Version, Lizenz, … (z.B.: README.md)
– Wie man mithelfen kann (z.B.: CONTRIBUTING.md)
– Anwender-Dokumentation (nicht im Code-Repository), z.B.:
– Beschreibung mit Beispielen / Bildern / Demos
– Wie man Bugs melden sollte (yourbugreportsucks.com / Beispiel)
– Entwickler-Dokumentation (nicht im Code-Repository), z.B.:
– Wie man den Quelltext herunterlädt
– Wie ist die Verzeichnis-Strucktur des Projektes
– Wie installiert man das Build-System / Wie nutzt man das Build-System
– Wie führt man die entsprechenden Tests aus
– Wie sieht der Code-Style aus (z.B.: google-styleguide)

3.4 Plattform für Fragen und Kommunikation, z.B.:
– Mailingliste / Forum
– Stack Overflow
– gitter.im
– groups.google.com

3.5 Versionsnummern korrekt verwenden
– Semantic Versioning via MAJOR.MINOR.PATCH
– MAJOR: Hauptversion, wenn die API geändert wird
– MINOR: neue Funktionen, welche keine API-Änderungen hervorrufen
– PATCH: bei abwärtskompatibelen Bugfixes
– Tag-Versionen in der Quellcodeverwaltung nutzen (z.B. git tag)
– ggf. einen Changelog schreiben (z.B.: CHANGELOG.md)
– Abhängigkeiten definieren (z.B.: package-versions with composer)

3.6 Abhängigkeitsmanagement für verwendete Bibliotheken nutzen, z.B.:
– PHP: Composer (packagist.org)
– JS / Node.JS: npm
– HTML / CSS / JS: bower

3.7 Testabdeckung und automatische Tests bei jeder Änderung
– Unit-Tests / BDD / TDD, z.B.:
– PHP: PHPUnit / phpspec
– JavaScript: mocha, Jasmine, qUnit …
– Frontend-Testing, z.B.:
– CasperJS / DalekJS / Selenium
– automatisierte Tests
– Travis CI (Linux)
– AppVeyor (Windows)

3.8 Issue-Tracking-System zur Verwaltung von Bugs verwenden
– z.B.: github – Issue-Tracking aktivieren
– Übersicht über Fehler und wer diese fixed
– “Gruppenzwang”, da das Issue-Tracking für jeden einsehbar ist

3.9 Contributor-Model bei größeren Projekten, z.B.: yui3

4. Wie veröffentliche ich Open Source Software?

4.2 Beispiel: npm

# Installation von node.js, z.B.:
sudo apt-get install nodejs

# Konfiguriere npm
npm set init.author.name "Lars Moelleken"
npm set init.author.email "lars@moelleken.org"
npm set init.author.url "http://moelleken.org"

# npm User erstellen (~/.npmrc)
npm adduser

# interaktiv eine “package.json”-Datei erstellen
npm init

# Abhänigkeiten & Tests hinzufügen
npm install mocha --save-dev
npm install chai --save-dev

# Veröffentliche dein Paket
npm publish

4.2 Beispiel: bower

# Installation von node.js, z.B.:
sudo apt-get install nodejs

# Installation von bower
npm install -g bower

# interaktiv eine “bower.json”-Datei erstellen
bower init

# Veröffentliche dein Paket
bower register <my-package-name> <git-endpoint>

4.3 Beispiel: composer

# Installation von composer, z.B.:
curl -sS https://getcomposer.org/installer | php

# interaktiv eine “composer.json”-Datei erstellen
composer init

# Veröffentliche dein Paket
https://packagist.org/packages/submit

5. Beispiel-Repositories

https://github.com/voku/node-lettering

https://github.com/voku/bower-lettering

Quellen / Links:

– eine Liste von offiziellen “Open Source” Lizenzen: http://opensource.org/licenses/alphabetical

– eine Liste von Programmiersprachen und deren Lizenzen: http://en.wikipedia.org/wiki/List_of_open-source_programming_languages

– Gespräch: Unterstützen von Open Source Projekten: https://www.radiotux.de/index.php?/archives/7995-RadioTux-Sendung-Maerz-2015.html

– Support for Open-Source Software: https://www.bountysource.com/

– Easy Pick (einfach zu behebende Bugs) -> z.B.: https://github.com/symfony/symfony/issues?q=is%3Aopen+is%3Aissue+label%3A%22Easy+Pick%22

– Help your favorite open source projects: http://www.codetriage.com/

– Statistik über freie Lizenzen auf github: http://ostatic.com/blog/the-top-licenses-on-github

– Erklärung zu freie Lizenzen: http://www.webmasterpro.de/management/article/freie-lizenzen.html

– A Beginner’s Guide to Creating a README: https://thechangelog.com/a-beginners-guide-to-creating-a-readme/

– Starting An Open-Source Project: http://www.smashingmagazine.com/2013/01/03/starting-an-open-source-project/

– qUnit vs Jasmine vs Mocha: http://www.techtalkdc.com/which-javascript-test-library-should-you-use-qunit-vs-jasmine-vs-mocha/

– Which programming language has the best package manager?http://blog.versioneye.com/2014/01/15/which-programming-language-has-the-best-package-manager/

– Erstelle Packages via bower: http://bower.io/docs/creating-packages/

– Open-Source-Lizenzen: http://www.heise.de/open/artikel/Open-Source-Lizenzen-224724.html

– Think about the license! http://lucumr.pocoo.org/2009/2/12/are-you-sure-you-want-to-use-gpl/

– Linus Torvalds says GPL v3 violates everything that GPLv2 stood for: https://www.youtube.com/watch?v=PaKIZ7gJlRU

– GNU – Free Software: https://www.gnu.org/philosophy/free-sw.en.html

– GNU/GPL: https://www.gnu.org/copyleft/gpl.html

– GNU/Packages: http://www.gnu.org/manual/blurbs

– FreeBSD über Vor- und Nachteile von GPL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/bsdl-gpl/gpl-advantages.html

– Geschäftsmodelle für Open-Source: http://t3n.de/magazin/geschaftsmodelle-open-source-unternehmer-welche-ansatze-221154/

– Open-Source-Finanzierung (Podcast): http://chaosradio.ccc.de/cr209.html

Admin meets Frontend

… oder was „JavaScript“ und „Shell-Script“ gemeinsam haben.

Zu beginn muss ich zugeben, dass ich bei meinen ersten Skripten auch nicht auf den Sichtbarkeitsbereich von Variablen (Scope) geachtet habe. Wenn man sich jedoch etwas mit Softwareentwicklung auseinandersetze stellt man schnell fest, dass globale Variablen direkt aus der Hölle kommen und nichts im Quelltext zu suchen haben.

Variablen sind zumindest in der Shell und in JavaScript zunächst global, selbst innerhalb von Funktionen und werden erst durch den Zusatz „var“ bzw. „local“ zur lokalen Variable. In vielen anderen Programmiersprachen erkennt man den Scope einer Variable direkt im Zusammenhang, ist z.B. eine Variable innerhalb einer Methode deklariert, so ist diese nur innerhalb dieser Methode verfügbar. Wird die Variable jedoch innerhalb der Klasse deklariert, so ist diese für die ganze Klasse und somit für alle Ihre Methoden verfügbar.

Es folgen ein paar Beispiele, wo der Inhalt (Title der Beiträge) des RSS-Feeds von “planet.ubuntuusers.de” ausgegeben werden soll.

JS-Beispiel: mit globalen Variablen

Um dies selber zu testen, öffne die Verlinkte Datei im Browser (leere Webseite) und öffne die Entwicklertools (F12), schalte die Ansicht auf “Konsole” und lade die Seite neu. Im Quelltext sind ausschließlich globale Variablen verwendet, jedoch funktioniert dieses Script “leider” wie gewünscht. Das Problem mit globalen Variablen ist, dass man den Quelltext dadurch ggf. schwerer lesen kann und diesen nicht wiederverwenden kann. Wenn man z.B. verschiedene Funkionen als unterschiedlichen Skripten zusammenfügt oder zusammen nutzen möchte, welche jedoch ebenfalls globale Variablen nutzen, dann können da sehr eigenartige Ergebnisse bei herauskommen.

JS-Beispiel: mit lokalen Variablen

In den DevTools von Chrome kann man jetzt den entsprechenden Variablen-Scope sehen. Jedoch ist der Quellcode noch nicht wirklich wiederverwendbar, da wir das zu lösende Problem (also das laden und parsen einer JSON-Datei) nicht auf eine eigene Abstraktionsschicht gebracht haben.

JS-Beispiel: mit lokalen Variablen und Klassen

In diesem Beispiel wurde nun die Klasse “PlanetUbuntuuserJsonData” erstellt welche wiederum von der Klasse “JsonData” dessen Eigenschaften (Variablen & Methoden) erbt. Leider ist der Quelltext hierbei von zirka 50 auf zirka 80 Zeilen erhört worden und funktioniert dabei z.B. nicht im IE < 10. (siehe Kommentare im Quelltext)

JS-Beispiel: ohne Variablen + jQuery

Dieses Beispiel benötigt zwar die “jQuery”-Bibliothek, welche jedoch bereits entsprechende Funktionalitäten kapselt. Vergleich man diesen Quellcode mit der Vorherigem Version, kann man schnell erkennen, das entschieden weniger Quellcode deutlich besser zu lesen ist. ;-)

Shell-Beispiel: mit globalen Variablen (test_1.sh)

In diesem Beispiel sind wieder sehr viele globale Variablen verwendet und wieder funktioniert das entsprechende Skript “leider” trotzdem. Die Funktion “parse_json()” gibt nicht einmal einen Rückgabewert zurück, dafür teilen sich die beiden Funktionen die Variablen. Und im Grunde könnte man den ganzen Quelltext auch einfach ohne Funktionen untereinander schreiben, dies hätte den selben Effekt.

Shell-Beispiel: mit lokalen Variablen (test_2.sh)

Die entsprechende Ausgabe ist bereits im Vorherigen Bild zu sehen. Bei Shell-Skripten kommt es seltener vor, dass man dessen Funktionalität wirklich wiederverwenden möchte, jedoch ist der Quelltext deutlich besser zu lesen, wenn man entsprechende Rückgabewerte und Übergabeparameter verwendet.

Quellen / Links:
– Shell: Advanced Bash-Scripting Guide
– Shell: Coding-Style-Guide von “Oh My Zsh”
– JS: Sichtbarkeitsbereich (Scope) von Variablen
– JS: Objektattribut

Server-Probleme im Zeitalter von HTTP/2

Ich hatte heute das Problem, dass einige Webseiten extrem langsam bis gar nicht mehr vom Webserver ausgeliefert wurden. Also prüfe ich als erstes mit “htop” ob die CPU ausgelastet ist, danach via “iotop” die Festplatte, mit “iftop” den Traffic, mit “netstat” die offenen Netzwerkverbindungen und via “free” wie viel Speicher noch zur Verfügung steht. Und die Hardware war nicht mal ansatzweise ausgelastet. Nach einigen weitere Tests ist schnell aufgefallen, dass nur “http”-Anfragen betroffen waren. Selbst eine einfach GET-Anfrage eines Bildes ist zeitweise fehlgeschlagen.

Die größte Änderung am Vortag war, dass eine Webseite mit zirka 1 Millionen Usern komplett auf “https://” umgestellt wurde. Daher habe ich kurzfristig wieder auf “http://” umgestellt, jedoch ohne eine Änderung festzustellen.

linux_kill_9 — Quelle: http://www.reddit.com/r/ProgrammerHumor/comments/27vcjg/signal_kill/

Zeitgleich ist aufgefallen das der MySQL-Prozess nicht korrekt neugestartet ist, somit liefen zwei MySQL-Server (ps aux | grep mysql), wobei nur einer wirklich Anfragen angenommen hat. Der zweite Prozess wollte sich nicht mehr via “service mysql restart” neustarten lassen, hat die Fehlermeldung “Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysql.sock’” produziert und wurde daher via “kill” getötet und anschließend der MySQL-Server neugestartet.

Dies hat auch das Problem mit den langsamen Webseiten behoben, zumindest kurzweilig. Danach hatten “http”-Anfragen wieder Probleme. Im “error”-Logfile (/var/log/apache2/error.log) vom Apache habe ich dann endlich eine Meldung gefunden, welche mich auf die richtige Fährte gebracht hat: “server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers settings”

Vor einer Woche hatte ich das “SPDY“-Protokoll auf dem Server aktiviert und getestet, alles hat ohne Probleme funktioniert. Dann habe ich gestern die bereits erwähnte Webseite komplett auf “https” umgeroutet und noch immer kein Problem festgestellt. Am Morgen wurden dann Newsletter versendet und eine ganze Menge Leute sind in kurzer Zeit via “https” auf die Webseite gekommen, da das “SPDY”-Protokoll nur mit “https” arbeite haben diese User nicht die üblichen Anfragen (HTTP 1.0 / 1.1) an den Server gestellt, sondern durch Multiplexverfahren mehrere Anfragen gleichzeitig verarbeitet werden.

http-diagram-spdy — Quelle: http://stackoverflow.com/questions/10480122/difference-between-http-pipeling-and-http-multiplexing-with-spdy

Die erste Intuition, dass es etwas mit der “SSL”-Umstellung zu tun hatte war schon mal nicht verkehrt, jedoch hatte ich die entsprechenden Einstellungen nur in der “.htaccess” auskommentiert, die “https”-Verbindungen jedoch nicht zurück nach “http” umgeleitet …

RewriteCond %{SERVER_PORT} !^443
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

… und den Apache nicht neugestartet, somit waren die aktuellen Anfragen noch aktiv und Nutzer welche auf der Webseite waren haben weiter “https”-Anfragen generiert.

Im nächsten Schritt musste nun festgestellt werden, wie viele Apache Prozesse bzw. gleichzeitige Verbindungen einstellt werden mussten und wie man dies am besten konfiguriert. Die Apache-Dokumentation sagt hierzu folgendes:

“The MaxRequestWorkers directive sets the limit on the number of simultaneous requests that will be served … For non-threaded servers (i.e., prefork), MaxRequestWorkers translates into the maximum number of child processes that will be launched to serve requests. The default value is 256; to increase it, you must also raise ServerLimit.”

Also habe ich via …

netstat -anp | grep -E ":80|:443" | grep ESTABLISHED | wc -l

… bzw. zur groben Orientierung via …

ps aux | grep apache | wc -l

… herausgefunden wie viele http(s) Anfragen bzw. Apache Prozesse aktuell vorhanden sind und habe diese Einstellungen zunächst entsprechend hoch eingestellt (“/etc/apache2/mods-enabled/mpm_prefork.conf”), so dass die Webseite wieder korrekt funktionierte. Anschließend habe ich die zuvor beschriebenen Befehle verwendet, um die endgültigen Einstellungen zu ermitteln. Die folgenden Einstellungen sind an einen Server mit 32G Arbeitsspeicher getestet und sollte nicht einfach übernommen werden.

<IfModule mpm_prefork_module>
ServerLimit 1024
StartServers 1
MinSpareServers 32
MaxSpareServers 250
MaxRequestWorkers 1024
MaxConnectionsPerChild 0
</IfModule>

————————————————–

Lösung: Wenn man das “SPDY”-Modul aktiviert und später auf “SSL” umstellt, sollten man vorher die Apache-Konfiguration anpassen! ;)

————————————————–

Es folgt noch ein kleines Tutorial, wie man “SPDY” für Apache installieren kann. Jeder der bereits auf “nginx” umgestiegen ist, kann dies ggf. bereits ohne weitere Installation ausprobieren: http://ginx.org/en/docs/http/ngx_http_spdy_module.html

Installation: SPDY für Apache 2.2

Download: https://developers.google.com/speed/spdy/mod_spdy/

# z.B.: wget https://dl-ssl.google.com/dl/linux/direct/mod-spdy-beta_current_amd64.deb

dpkg -i mod-spdy-*.deb

apt-get -f install

Installation: spdy für Apache 2.4

apt-get -y install git g++ apache2 libapr1-dev libaprutil1-dev patch binutils make devscripts fakeroot

cd /usr/src/

git clone https://github.com/eousphoros/mod-spdy.git

## wähle deine Apache Version

# z.B.: git checkout apache-2.4.7

# z.B.: git checkout apache-2.4.10

cd mod-spdy/src

./build_modssl_with_npn.sh

chmod +x ./build/gyp_chromium

rm -f out/Release/mod-spdy-beta*.deb

BUILDTYPE=Release make linux_package_deb

dpkg-i out/Release/mod-spdy-beta*.deb

Video:

Links:

– Projekt Webseite: http://www.chromium.org/spdy/

– Quellcode: https://code.google.com/p/mod-spdy/wiki/GettingStarted

– “mod_spdy” für Apache 2.2: https://developers.google.com/speed/spdy/mod_spdy/

– “mod_spdy” für Apache 2.4: https://github.com/eousphoros/mod-spdy

– Online-Test für “SPDY”: https://spdycheck.org/

– Präsentation zum Thema “HTTP/2” von @derschepp: https://schepp.github.io/HTTP-2/

– Browserkompatibilität mit “SPDY”: http://caniuse.com/#search=spdy

I ❤ ~/

Vor einiger Zeit habe ich bereits einen Blog-Post über meine “.dotfiles” geschrieben, jedoch habe ich mich damals mehr auf die Installation beschränkt und habe keine Beispiele gezeigt, so dass man den Vorteil der .dotfiles nur schwer erfassen konnte.

Außerdem benötigt man ggf. nur einige Funktionen oder Dateien um sein System an an seine Bedürfnisse anzupassen. Auf der Webseite GitHub ❤ ~/ gibt es sehr gute .dotfiles Sammlungen, welche man einfach “forken” und anpassen und nutzen kann.

PS: wer sich bisher nicht mit “git” auskennt, sollte sich einmal eines der folgenden interaktiven git-Tutorials anschauen:
– try.github.io/
– pcottle.github.io/learnGitBranching/
– gitreal.codeschool.com/

Beispiele zu meinen .dotfiles:

Navigation:
https://github.com/voku/dotfiles/blob/master/.aliases#L75

Farben für die Kommandozeile:
https://github.com/voku/dotfiles/blob/master/.aliases#L116

Nützliche Shortcuts: z.B. date_*
https://github.com/voku/dotfiles/blob/master/.aliases#L295

Copy&Past via “getclip” und “putclip”: https://github.com/voku/dotfiles/blob/master/.aliases#L368

kill & pkill via z-shell: https://github.com/voku/dotfiles/blob/master/.redpill/lib/4_completion.zsh#L122

grep & ack: https://github.com/voku/dotfiles/blob/master/.aliases#L242

git via z-shell: https://github.com/voku/dotfiles/blob/master/.gitconfig

“ls”-aliases: https://github.com/voku/dotfiles/blob/master/.aliases#L196

vim » Automatisch zur letzten Position springen
https://github.com/voku/dotfiles/blob/master/.vimrc

vim » Schell-Suche via “#”

vim » markieren Leerzeichen am Ende der Zeile

vim » Tabs nutzen
https://github.com/voku/dotfiles/blob/master/.vimrc#L564
vim » NERD Tree via “,” + “-“
https://github.com/voku/dotfiles/blob/master/.vimrc.bundles#L18

vim » Autovervollständigung via Tabulatur-Taste
https://github.com/voku/dotfiles/blob/master/.vimrc#L755

Erklärungen zu meinen .dotfiles:

.bash_profile & .bashrc // .zprofile & .zshrc

Wenn man sich direkt über die Konsole einloggt (ohne GUI) oder remote über ssh, dann wird die Datei: “~/.bash_profile” (bash) bzw. “~/.zprofile” (zsh) ausgeführt, um Ihre Shell vor der ersten Eingabeaufforderung zu konfigurieren.
Wenn man jedoch bereits angemeldet ist und ein neues Terminalfenster z.B. in Gnome oder KDE öffnet, dann wird die “~/.bashrc” bzw. “~/.zshrc”-Datei ausgeführt. Außerdem wird die “.[bash|z]rc” auch ausgeführt, wenn man eine neue Bash-Instanze via “/bin/bash” in einem Terminal ausführt. Um zu verhindern, dass unsere Einstellungen automatisierte Skripte negativ beeinflussen, führen wir die folgenden Anpassungen nur bei interaktiven Konsolen aus.

In meiner “.bashrc”-Datei ist nicht viel zu sehen, da diese Datei auf die “.bash_profile”-Datei zugreift, so dass man bei Änderungen nur eine Datei bearbeiten muss. In “.bash_profile#L19” werden wiederum andere Dateien geladen, so dass wir die selben “Funktionen” und “Aliases” sowohl in der “Bash” als auch in der “Z-Shell” verwenden können.

.config_dotfiles

In dieser Datei kann man Einstellungen für meine .dotfiles vornehmen. Wenn du z.B. deinen Standard-User-Namen in der Variable “CONFIG_DEFAULT_USER” hinterlegst, wird diese nicht mehr in der Shell-Prompt angezeigt.

.path

In dieser Datei kannst du Pfade zu deinen Ausführbaren Dateien einfügen, so dass du diese ohne Angabe des Pfades ausführen kannst.

Diese Datei ist nicht im öffentlichen Repository und ist via “.gitignore” aus git verbannt, da es vertrauliche Informationen enthalten kann. z.B.: export PATH=”$HOME/utils:$PATH”

.load

In dieser Datei laden wir weitere optionale Einstellungen, welche ggf. gar nicht installiert und somit auch nicht geladen werden müssen.

.colors

Hier definieren wir einige Farben, welche dann in den folgenden Dateien verwendet werden können. z.B.: COLOR_BLACK=‘\e[0;30m‘

.exports

Variablen in Shell-Scriptes verhalten sich so ähnlich wie in JavaScript. Variablen sind Standardmäßig “global”, dass heißt selbst Variable innerhalb einer Funktion sind anschließend auch außerhalb der Funktion verfügbar. Daher verwenden wir “local” innerhalb von Funktionen, für Variablen welche nur innerhalb der Funktion zur Verfügung steht sollen. Außerdem können wir Variablen via “export” exportieren, so dass diese nicht nur zur Ausführungszeit, sondern anschließend ebenfalls allen Kindprozessen als Umgebungsvariable zur Verfügung stehen.

.icons

Wie die Farben werden auch die entsprechenden Icons exportiert, so dass wir diese anschließend in Funktionen etc. nutzen können.

.aliases

In dieser Datei werden Abkürzungen für komplexe Befehle oder / und Fallbacks definiert, welche anschließend als Befehl ausgeführt werden.

z.B.:
alias starwars=’telnet towel.blinkenlights.nl’
alias sgrep=’grep -R -n -H -C 5 –exclude-dir={.git,.svn,CVS}’

.bash_complete // completion.zsh

Auch wenn die “Z-Shell” (zsh) bessere Tabcompletion bietet, kann man auch in der “Bash” einige Tabcompletion-Features nutzen.

z.B.:

apt- [Tabulator]
apt-g [Tabulator]
apt-get [Tabulator]
apt-get i [Tabulator]
apt-get install [Tabulator] [Tabulator]
apt-get install apa [Tabulator]

.functions

Hier habe ich einige praktische Funktionen gesammelt, welche ich öfters nutze und nicht als Plugin auslagern möchte.

z.B.:
lman() -> “Open the manual page for the last command you executed”
netstat_free_local_port() -> “get one free tcp-port”
iptablesBlockIP() -> “block a IP via ‘iptables'”

Überlegungen: In der “normalen” Programmierung nutzt man lowerCamelCase für normale Variablen / Funktionen und Methoden, jedoch sind eigentlich alle Funktionen in der Shell lowercase z.B.: whoami, updatedb, killall. Ich mich dafür entschieden mich bei neuen Funktionen und Aliases an einem Original-Befehl zu orientieren, so dass man diese nicht neu lernen muss, sondern diese via [Tabulator] nutzen kann.

.extra

Auch diese Datei ist nicht im öffentlichen Repository und ist via “.gitignore” aus git verbannt, da es vertrauliche Informationen enthalten kann. Hier kann man alle zuvor gesetzten Variablen, Einstellungen, Funktionen überschreiben oder ergänzen.

What?

The Problem!

Understand your Timeouts.

– Web server

– PHP-FPM

– PHP

– Database (MySQLi)

Summary:

Solution:

Ähnliche Beiträge:

Was habe ich in meiner Ausbildung zum Fachinformatiker Systemintegration gelernt?

– Du lernst nur soviel, wie du lernen willst.

– Keine Panik!

– Linux && Kommandozeile <3

– Lies in der offizielle Dokumentation (und erst dann bei “Stack Overflow”).

– Mach immer ein Backup (benutze nieeemals betrunken “sudo”).

– Sei ehrlich zu Kunden, Mitarbeitern und dir selbst.

– Stelle Fragen, wenn du etwas nicht verstanden hast.

– Denke über dein Tun nach (nicht nur auf der Arbeit).

– Google korrekt nutzen …

Was habe ich in meiner Ausbildung zum Fachinformatiker Anwendungsentwicklung gelernt?

– Du lernst niemals aus …

– Programmiere jeden Tag. (aber setzte dir selber ein LIMIT 1, x)

– Denke in Modulen und Packages …

– Open Source <3

– Git und Gut!

– Nutze “github.com” und lerne von den besten.

– Tests ausprobieren.

– Automatisiere deine Tests.

– Deployment ist wichtig …

– Konzepte zu verstehen ist wichtiger als dessen Implementierung.

– Probleme lösen heißt auch Kunden verstehen.

– Probleme lösen heißt auch Prozesse verstehen.

– Verteile auf mehreren Dateien.

– Lesbarkeit geht vor!

– Gute Namensgebung ist eine der schwierigsten Aufgaben in der Programmierung.

– An Kommentare sparen (zumindest inline) …

– Konsistenz in einem Projekt, ist wichtiger als persönliche Präferenzen!

– Ein einheitlicher Code-Style wirkt sich sehr positiv auf die Qualität aus!

– Nutze Funktionale-Prinzipien && Objekt-Orientierte-Konzepte.

– Bitte keine globalen Variablen verwenden!

– Lerne deine Werkzeuge richtig einzusetzen!

– Performance?

– Exceptions === Ausnahmen

– Führe deine Arbeit zu Ende

– Quelltext sollte durchsuchbar sein [Strg + F] …

– Programmiere für deinen Use-Case!

– KISS – Keep it simple, stupid.

– DRY – Don’t Reapeat Yourself.

– Der Wille etwas neues zu lernen und zu verstehen ist wichtiger als Vorkenntnisse.

– Lese gute Bücher und Zeitschriften.

– Infos: folge anderen Programmieren auf Twitter / Github / Google+ / Medium / Pocket …

– Infos: höre Podcast & abonniere RSS-Feeds / Newsletter & schaue Videos z.B. von Web-Konferenzen

– Besuche Meetup’s & Web-Konferenzen und rede mit anderen Entwicklern.

– Schreibe Antworten bei quora.com || stackoverflow.com || in Foren || deinem Blog …

– Bleib nicht jeden Tag so lange auf der Arbeit, ansonsten wartet Zuhause irgendwann keiner mehr auf dich!!!

Ähnliche Beiträge:

Was ändert sich für Webentwickler?

Was ändert sich für Administratoren?

Ähnliche Beiträge:

Dev-Tools:

Privacy-Tools:

Organisation- / Extra-Tools:

Ähnliche Beiträge:

Installation unter Ubuntu 14.04 via Fremdquellen (PPA)

Ähnliche Beiträge:

Ähnliche Beiträge:

1. Was ist Open Source Software?

1.1 Geschichte

1.2 Freie Software ⊆ Open Source Software

1.3 Lizenzen

1.4 Geschäftsmodelle

2. Wo veröffentliche ich Open Source Software?

3. Welche Open Source Software Standards gibt es?

4. Wie veröffentliche ich Open Source Software?

4.2 Beispiel: npm

4.2 Beispiel: bower

4.3 Beispiel: composer

5. Beispiel-Repositories

Quellen / Links: