Dienstag, 12. April 2016

Keep Simple Things Simple

Einige Skriptsprache bieten das Feature, dass der letzte Wert einer Methode der Returnwert dieser Methode ist. Man muss ihn also nicht explizite zurückgeben. Das ist ein durchaus hilfreiches Feature, was den zu schreibenden Code reduziert. In der Regel ist Convention zutreffend und damit hilfreich. Leider kann man diese Hilfe auch zu seltsamen Code führen. Hier ein R Beispiel.

Hier wird die Variable visitData explizit noch einmal aufgeführt damit sie von der Methode zurückgeben wird. Und dazu kommt noch der Kommentar der dieses Verhalten beschreibt. Besser wäre hier die konventionelle Schreibweise mit explizitem Return. Sie ist besser zu verstehen und kürzer.

Montag, 21. März 2016

Buch: Ilya Grigorik High Performance Browser Networking

Jeder der professionell sich mit Webperformance auseinandersetzt sollte dieses Buch besitzen. Es beschäftigt sich sehr gut beschrieben mit dem Browser Networking. Es geht auf alle relevanten Aspekte wie Latenz, Übertragungsgeschwindigkeit, TCP, TLS (aka HTTPS), drahtlose Netzwerke, WLAN ein. Das Networking wir gut und umfangreich beschrieben und sollte Jedem vertraut sein, der über Performance nachdenkt. Der Teil zu HTTP ist gut und endet mit einer kurzen Einführung von HTTP 2.0, das hier nur relativ kurz angerissen wird. Abgerundet wird dieses empfehlenswerte Buch mit XMLHttpRequests, SSE, WebSockekts und WebRTC. Das Buch ist gelungen ist aus meiner Sicht ein Standardwerk für den Bereich Performance und Web, ach wenn der zweite Teil ein wenig schwächer ist.
Wer Themen sucht zur Optimierung der Browserperformance, der wird in diesem Buch leider nicht fündig. Dieser Zweite wichtige Themenkomplex bleibt aussen vor. Hier wünscht man sich ein zweites Buch zu diesem Thema vom Autor. Ilya Grigorik hat diese Dinge leider nicht zu einem Buch zusammengefasst, sondern man findet sie auf der Seite von Google, bei Google Developers unter Webfundamentals, Performance (Link). Auch diese Seiten sind wirklich lesenswert.


Donnerstag, 17. März 2016

Neue Ideen zur Performance Optimierung von Webapps

Nach Brodli und Zopli als Alternativen zur Gzip Kompression im Webbrowser, dachte man das wäre es jetzt. Aber nein es gibt, wieder von Google, nach eine andere weniger bekannte Idee um Bytes in der Übertragung vom Webserver zum Wenbbrowser des Kunden zu sparen, sie heisst SDHC. SDHC oder lang Shared Dictionary Kompression over HTTP, benutz ein gemeinsames Dictionary für die Kompression. Das Dictionary ist bei einigen Kompressionsverfahren ein grundlegendes Element und wird z.B. bei Gzip immer neu aufgebaut in Abhängigkeit zum zu komprimierenden Inhalt. Googles Idee ist, irgendwie ähnelt sich alle Responses also kann man vielleicht mit einem zentralen Dictionary, wenn man es nur einmal überträgt, weitere Bytes sparen. Ich bin gespannt auf die ersten Messergebnisse.

Links:

  1. https://engineering.linkedin.com/shared-dictionary-compression-http-linkedin
  2. http://blog.endpoint.com/2009/07/sdch-shared-dictionary-compression-over.html

Und es gibt mal wieder ein neues Bildformat, das sich anschickt das alte Ross JPEG in den Ruhestand schicken. Es heisst, jetzt kommt's,  Better Portable Graphics oder BPG. Es greift auf die Still Image Kodierung von HEVC zurück. Mal sehen wie es im Vergleich aussieht, vor allem mit den anderen JPEG Nachfolgern wie WebP oder JPEG2000 und mal sehen wie es mit Browsersupport vorangeht. Auf den ersten Blick ergeben sich bei hohen Kompression Weichzeichnungseffekte, die kennt man ja schon von JPEG2000. Hier könnt ihr das ganze mal selbst probieren: http://xooyoozoo.github.io/yolo-octo-bugfixes/#cologne-cathedral&jpg=s&bpg=s



Die dritte Performance Idee heisst Tubolink und ist die geschickte Anwendung von Javascript um den HTML Body des aktuellen HTML Dokuments im Browserfenster auszutauschen und das Parsen und Kompilieren von inkludierten JS Dateien zu sparen. Die Idee kling ganz nett, die Frage ist, wie hoch das Einsparpotential ist und ob dies mit jeder Webseite funktioniert.



Mittwoch, 13. Januar 2016

Dienstag, 12. Januar 2016

HTTP2

HTTP2 is the new, better, faster HTTP and it replaces Googles SPDY (http://programming-2.blogspot.de/search?q=SPDY). One really informative site to HTTP2 is https://http2-explained.readthedocs.org/en/latest/index.html

To use HTTP2, you need an client. CURL support it, but not as default. To use HTTP2 with CURL on MacOSX, you have to install CURL with brew:

brew install curl --with-nghttp2

Now you can check out HTTP2 with CURL

If you got following error:
curl: (1) Unsupported protocol
You use an CURL without compiled HTTP2 support. On MacOSX brew doesn't replace the existing CURL. You have to use the full path to the CURL from brew:

/usr/local/opt/curl/bin/curl --http2 -I -v https://google.com

Sonntag, 18. Oktober 2015

The 2nd Most Important Task of a Software Developer

The most import task of a software developer is to write code. Well, this answer was pretty easy. Really, yes! But what is second most important skill. I ask my colleagues, first guy says, watching youtube - nice but wrong, 2nd guy: write good documentation - good shot but also wrong.
For me and I'm confident that I'm right, the second most important task of a software developer is to delete code. The first important task is to write code and the second important task is to delete code.
I don't mean delete bugy code, I mean delete working code. Why should you do this?

We have limited time and limited count of developer, this means, we have a more or less constant velocity developing code. If our code base grows, we spend time for maintenance code an we have less time for developing new features, an so on and so on util we reached standstill.

To avoid the standstill, we suggest following tasks to reduce the code size, it a little bit like the Simplify your Life Literature

  1. remove dead code
  2. refactor code to build simpler and shorter code
  3. reimplement code in an effective way, change tools, ... 
  4. delete working code if there is users don't require the function anymore
If somebody say's that we keep this function because, we may use them - then remove the code. The word may is the indicator to remove the code. If we delete to much code, don't worry. Most of the times it cheaper to rewrite a little peace of code instead of keeping all old code fragments.


Here some link illustrating the problems:

  1. Linux Maintainer needed, because of heavy load and huge Code base http://www.golem.de/news/linuxcon-dem-linux-kernel-fehlen-maintainer-1510-116749.html
  2. Linux is planning to remove EXT3 filesystem http://www.pro-linux.de/news/1/22532/ext3-dateisystemtreiber-soll-aus-linux-entfernt-werden.html


Dienstag, 13. Oktober 2015

Log Jmeter Variables with Flexible File Writer

There is no easy way to write a JMeter variable into a standard log file. Also the flexible file writer is not able to use calculated variables into the log file. The flexible file writer is only able to use the properties of the previous sampler. These properties are fixed. So I use a small hack to implement this functionality in Jmeter.

First is calculate a variable called CACHE_INFO e.g. with the regular expression extractor.

Second, I use the BeanShell PostProcessor to overwrite an unused property, here I use ThreadName, of the previous sampler.


Third, I use this abused sampler property with the flexible file writer.