About "Good to know"
Each morning during my "coffee hour" I read a couple of IT (and photography) related articles from various sources.
And each couple of days I intend to create a note of the most worthwhile articles or tools that I've encountered. So far it took around 2 months since my previous issue... :)
(for the web developer) Google's plan to "ensuring HTTPS pages can only load secure sub-resources"
Starting with Chrome 79 Google intends to rewrite, behind the scenes, various http:// URL's to https://.
They will start with scripts, CSS, and by Chrome 81 (due for February 2020), anything that fails to correctly load over HTTPS will be blocked.
One can already force this in all modern browsers by setting the HTTP response header:
Content-Security-Policy: upgrade-insecure-requests
(for the Go web developer) Arguments against heavy-weight Go web frameworks
I've just started a Go-based project that will require an web API / dashboard / site. Thus I've started searching for some Go-based web frameworks / libraries.
Apparently the general consensus is that one is better-off without heavy-weight Rails-like frameworks, and better served by mix-and-matching various smaller libraries:
- Why I Don't Use Go Web Frameworks -- a case for using Go's provided HTTP related building-blocks;
- Working with Go Web Frameworks -- Gin and Echo -- discusses the issues of migrating from one library to another (in case you need);
- Build You Own Web Framework In Go -- an interesting multi-post tutorial describing how one can build his own solution, tailored for the problem at-hand;
- The Case for Go Web Frameworks -- a counter-point for pro-comprehensive web frameworks;
I have also reviewed all the libraries and frameworks listed at Awesome Go, and the following are my choices (as of now):
- if I really need to use a framework I'll chose Echo;
- for the HTTP server I'll use fasthttp with fasthttp/router;
- for templating I'll use Go's built-in html/template;
(for "the ancient one" Linux administrator) "A developer goes to a DevOps conference"
A humoristic take on "DevOps" culture... (It made my day...) :) :)
(for the Linux network operator) Low-level details about Linux networking stack
I must admit I haven't thoroughly read these articles, but rather skimmed over them. However, now I know where to look when I have network performance issues:
- When TCP sockets refuse to die -- it focuses on what happens during establishment of TCP connections (especially with regard to timeouts);
- TCP Keepalive is a lie -- it focuses on the interaction between TCP Keep-Alive feature and "busy" but "slow" clients;
- Monitoring and Tuning the Linux Networking Stack: Sending Data -- the following two focus on in-kernel low-level details on what happens inside Linux networking stack;
- Monitoring and Tuning the Linux Networking Stack: Receiving Data;