Episode 102/2017: Wie kann ich mit git auf der Kommandozeile alle Änderungen an einer Datei nachvollziehen?

Eine oft gehörte und gestellte Frage, die Antwort darauf ist eigentlich ganz einfach:

git log -p <datei>

Siehe manpage:

COMMON DIFF OPTIONS
 -p, -u, --patch
 Generate patch (see section on generating patches).

Episode 68/2017: Durcheinander scp, ssh und uwsgi

Wieder was gelernt. Genauer gesagt, drei Dinge. Fangen wir an:

  1. Caching mit nginx ist eine tolle Sache. Auf einem Server wollten wir die Auswirkung von „Microcaching“, bei dem die Ressourcen beispielsweise nur 1 Sekunde lang vorgehalten werden, prüfen. Caching-Parameter gibt es z.B. als proxy_cache_*, scgi_cache_* oder fastcgi_cache_* Direktiven. Wir brauchten die uwsgi_cache-Direktiven für eine Django-App.
    Alles da, wunderbar.
    Aber: Ausgerechnet das tolle uwsgi-Modul hat keinen Defaultwert beim uwsgi_cache_key. Der Key setzt sich normalerweise aus verschiedenen Parametern wie dem Schema, dem Host und dem Request-URI zusammen, darüber wird ein MD5-Hash gebildet und die Dateien darüber identifiziert.
    Bei leerem Cache-Key wird genau eine Datei zwischengespeichert (die erste, die angefragt wurde) und jeder weitere Request führt zur gleichen Datei. Nicht gut.
  2. Kopieren mit scp. Du sitzt auf Rechner A, willst etwas von Rechner B auf Rechner C kopieren? Von A aus hast Du Zugriff auf B, aber wenn dann von B nach C kopiert wird, fehlen C die entsprechenden Credentials – was tun?
    „scp -3“ kopiert die Datei von B nach A und dann von A nach B. Schön unauffällig, aber sehr praktisch.
  3. Du hast eine ~/.ssh/config Datei mit verschiedenen nützlichen und spezifischen Host-Angaben, insbesondere gibst Du via IdentityFile Deinen Key an? Wenn Du sicherstellen willst, dass wirklich genau nur dieser Key benutzt wird und keine anderen beim Verbindungsaufbau probiert werden, setze „IdentitiesOnly yes“ mit dazu.
    Sagt die Doku: „Specifies that ssh(1) should only use the authentication identity and certificate files explicitly configured in the ssh_config files or passed on the ssh(1) command-line […]“.

Das wars.

Episode 3/2017: A terminal built on web technologies

Heute mal Hyper ausprobiert. Ein JS/HTML/CSS-Terminal.  Nett. Gibts als Electron-verpacktes Binary für alle drei Betriebssysteme.

Die Config-Datei liegt im Regelfall unter ~/.hyper.js, Änderungen werden sofort wirksam (Hot-Reload). Der Sourcecode von Hyper auf Github.

Plugins (Extensions) können in Javascript erstellt werden. Das ganze Terminal lässt sich via Browser-Dev-Tools inspizieren (und auch live verändern).

Tag 363/2016: Packaging

Der Tag war überwiegend Docker gewidmet, vor allem dem Packaging von Applikationen. Docker-Compose rauf und runter, Container anlegen und löschen, Dockerfiles schreiben und Varianten testen, mit Entryfiles spielen; überlegt, welche Schritte bei Installations- bzw. Setup-intensiven Anwendungen wohin zu verorten sind (ins Image, Volumes, Entryfile oder gar nachgelagerte exec-Script-Läufe). Verschiedene Images mit ähnlicher Zielrichtung ausprobiert, Größen verglichen.

Viele hilfreiche Blogs gefunden, manche Artikel allerdings auch schon wieder veraltet und so manche Dockerfiles nicht wirklich an den Best Practices von Docker orientiert. Und viele nehmen die Isolation der Container-Prozesse vom Host als gegeben und hinreichend hin, wenn sie von Security sprechen, ohne sich um weitergehende Möglichkeiten wie die capability-drops oder Absicherung durch Zertifikate zu kümmern.

Alles in allem: Viel gelernt.

Update Tag 15/2017: Link zu einem guten Docker-Cheat-Sheet.

Tag 357/2016: Tränen gelacht

Beim Lesen von Javascript: 2016 in Review von Craig Buckler auf SitePoint bin ich auf diesen Post gestoßen: How it feels to learn Javascript in 2016.

Meine Güte, was hab ich Tränen gelacht.

Es beginnt schon mit

No JavaScript frameworks were created during the writing of this article.

Ok, ein alter Witz, aber immer wieder gut.

Look, it’s easy. Code everything in Typescript. All modules that use Fetch compile them to target ES6, transpile them with Babel on a stage-3 preset, and load them with SystemJS. If you don’t have Fetch, polyfill it, or use Bluebird, Request or Axios, and handle all your promises with await.

Einfach nur gut. Unbedingt lesen.

Tag 333/2016: JS-Kongress in München, Tag 2

Immer noch der JS-Kongress, zweiter und letzter Tag, daher fast das gleiche Foto. Diesmal mit anderen Musikern (analoge Gitarrenmusik). Der Gebärdensprachdolmetscher war der Hammer: Nicht nur, dass er die Musik der Musiker 1a übersetzte – bei der Flut an Fachbegriffen während der Vorträge musste er generell Schwerstarbeit leisten, was er mit Bravour  ([braˈvuːɐ̯]) gemeistert hat.

Heute nochmal Javascript & Robotik + Internet of Things, aber auch Performance Profiling für V8 und die GPU via WebGL für bestimmte Arten von Berechnungen nutzen.

Bei aller Faszination über die Möglichkeiten, die javascriptfähige Microcontroller bzw. -Boards bieten, kam mir doch der Aspekt des Internet of Shit etwas zu kurz: Enthusiasmus und Fun in allen Ehren, aber die Entwicklungen der letzten Monate machen klar, dass Sicherheitsfragen nicht ausgeblendet, sondern elementarer Bestandteil der IoT-Vorträge werden sollten. Der Vortrag vom Vortag Writing Secure Javascript von Guy Podjarny befasste sich ja mit JS im Allgemeinen; er lenkte das Augenmerk darauf, dass der eigene Code im Verhältnis zu den integrierten Bibliotheken meistens eher gering ist und die Sicherheitsanalyse deshalb die Abhängigkeiten auch miteinschließen muss. Sein Projekt snyk bietet dazu Lösungsansätze.

Fazit der letzten beide Tage: Tolle Organisation, viele anregende Vorträge. Hier oder da hätte man zwar noch etwas rausarbeiten können, warum im spezifischen Einsatzzweck nun ausgerechnet Javascript die Sprache der Wahl ist, statt nur die weite Verbreitung zu zitieren, aber hey.

Tag 332/2016: JS-Kongress in München

JavaScript für Microcontroller, 360 & VR-Video, Maschinenlernen mit neuronalen Netzwerken, Security, Spieleentwicklung, Memory-Leaks unter Javascript, Katzen-Tracken mit JS auf dem Raspi, … der erste Tag war ordentlich vollgepackt und Dank der perfekten Organisation ein voller Erfolg. Besonders gut fand ich die Impulse vom Security-Vortrag und die Memory-Leak-Suche, die Hinweise haben einfach Praxisbezug. Beim Spielen mit Arduino-Boards oder Raspi ist mir JS relativ egal, finde es sogar fast ein bisschen „gewollt“, zumindest auf dem Raspi – dort ist Python einfach die Sprache der Wahl.

Die Pausen zwischen den Vorträgen wurden musikalisch von 9-Volt gefüllt, die ihre Musik auf übergroßen CDs verkaufen. „Schallplatten“ nennt man das wohl. Nice!

Tag 281/2016: Lua

Lua kommt dieses Wochenende auf die Todo-Liste. Es wird Zeit, ein paar Sachen direkt in vorgelagerte Proxies auszulagern, statt die (langsamen) Anwendungen dahinter mit Anfragen zu belästigen.

Weblinks von Wikipedia:

Tag 279/2016: Reguläre Ausdrücke, PCRE

Reguläre Ausdrücke sind Quell eleganter Lösungen und zerraufter Haare. Manche lösen gerne Puzzles, andere entziffern gerne in Gruppen angeordnete negative Lookaheads. Ein paar schnelle Links mit knappem und präzisem Das-wichtigste-was-man-wissen-sollte-Gehalt sowie Dokumentationen für Python, PHP & Javascript.

The absolute bare minimum every programmer should know about regular expressions

5 Regular Expressions Every Web Programmer Should Know

Extreme regex foo: what you need to know to become a regular expression pro

Python-Documentation: Regular expression operations und ein Online-Testtool

PHP-Documentation: Regular expressions (Perl-compatible)

Javascript-Documentation: RegExp

nginx benutzt PCRE in location-Blöcken, maps und beim ngx_http_rewrite_module (einfaches Beispiel).

RegExpBuddy, eine von vielen gelobte kostenpflichtige Software zum Testen von regulären Ausdrücken, leider nur unter Windows.

Tag 278/2016: Server-Optimierungs-Fetisch versus Einsatz-Kontext

Eine schreckliche Überschrift, wer hat sich die nur ausgedacht.

Beim Erforschen der Leistungsgrenzen eines VPS, der als Webserver dienen soll, kann man sich unverzagt daran machen, ein paar Kernelparameter zu überprüfen, z.B. net.core.somaxconn,  tcp_max_syn_backlog oder die Anzahl maximal geöffneter Dateien zu erhöhen (ulimits, /etc/security/limits.conf).

Aber nicht immer muss es das Ziel sein, dass das Ding abertausende von TCP-Verbindungen zulässt, welche die eigentliche Anwendung (lies: Webserver) dann eh nicht in der gleichen Anzahl bedienen kann.

Wenn beispielsweise der VPS Teil eines Clusters ist, dem ein Loadbalancer vorgesetzt ist, kann es schlauer sein, die Anzahl maximaler Verbindungen bewusst zu reduzieren (kleineres listen-backlog) und damit die Leistung des Loadbalancers zu optimieren. Wenn die Verbindungen abgelehnt werden und nicht in einer Warteschlange landen, kann der Loadbalancer schneller eine weniger ausgelastete Maschine finden.