Merge branch 'draft/links-20200423' into preview

content/links/20200423.md

@@ -0,0 +1,128 @@
++++
+title = "Links for 2020-04-23"
+date = 2020-04-23
+
+[taxonomies]
+tags = ["links", "google", "privacy", "commits", "messages", "microservices",
+"rust", "memory", "testing", "tests", "asciiflow", "vscode", "linux",
+"laptop"]
++++
+
+Google, Commit Messages, Microservices, How Rust Sees Memory, More About
+Tests, Asciiflow in VS Code, Does Rust Change Too Much?, Linux Laptop.
+ 
+<!-- more -->
+
+# [Google Says It Doesn’t 'Sell' Your Data. Here’s How the Company Shares, Monetizes, and Exploits It.](https://www.eff.org/deeplinks/2020/03/google-says-it-doesnt-sell-your-data-heres-how-company-shares-monetizes-and)
+
+Alright, let's start by picking on who we like to pick the most: Google.
+
+While the EFF article sounds a bit too scary and demonizes the company a bit
+too much, it brings a good point: Google is trying to escape regulations by
+using wording instead of actually fixing it.
+
+# [Why my commit messages for configuration files describe my changes](https://utcc.utoronto.ca/~cks/space/blog/sysadmin/SysadminCommitMsgWhat)
+
+While I don't fully agree with this idea of "describing the changes in the
+commit message even when the change is there", even with the reason pointed in
+the article, I think it still misses something:
+
+_Why_ you did the change.
+
+Sure, you can describe the changes, duplicating the already-there description
+by its changes, but you need to explain _why_ you did so. Bob got into group
+'fred'? Ok, but why? 
+
+This isn't just so people, in the future, when asking themselves "Why does Bob
+is a member of fred?" but also forces you to go after the reason for doing it.
+We are not machines that receive requests to, say, add Bob to the fred group,
+and do so without any questions. There must be a reason for this kind of
+stuff.
+
+# [Untangling Microservices, or Balancing Complexity in Distributed Systems](https://vladikk.com/2020/04/09/untangling-microservices/)
+
+There is a movement on _killing_ microservices raising recently. The article
+points one of the reasons: It's hard to find boundaries and where to split
+services.
+
+Did we jump into the "microservices" bandwagon too early? What are we missing
+for people to get those boundaries in a simple and understandable way? Are
+boundaries really that necessary for microservices? Can't we use some other
+metric to split the services?
+
+Honestly, I have no idea. There are some good points about microservices --
+like each having its own database and no shared state between services. But
+maybe we should look into [what the service should
+produce](https://blog.juliobiason.me/code/microservices-artifact-input-state/)
+instead of focusing on "boundaries".
+
+# [Visualizing memory management in Rust](https://deepu.tech/memory-management-in-rust/)
+
+While the article focuses on the Rust memory management, the same works for
+every language that doesn't have a runtime, AFAIK. So, if you're trying to get
+out of a language with runtime and switch to a language that has to deal with
+memory directly, there is some good information here.
+
+# [How We Test Vector](https://vector.dev/blog/how-we-test-vector/)
+
+A lot of discussion about testing on Vector, a transformation pipeline.
+
+One of the aspects that I liked on this is that they mention unit tests as "in
+isolation" (which I agree) and that they used for one single component, the
+transformations. And while they don't talk anything about using the classical
+"on test per function", it seems they actually used this way but only for a
+subset of everything.
+
+# [Asciiflow in VS Code](https://github.com/zenghongtu/vscode-asciiflow2)
+
+While I'm not a user of either Asciiflow or VS Code, it looks really
+interesting the fact that the whole design thing is in ASCII, WYSIWYG and
+mouse-oriented.
+
+# [The OAuth Bible](https://github.com/Kong/mashape-oauth/blob/master/FLOWS.md)
+
+I'm not a fan of OAuth, basically 'cause I tried to implement it myself
+(instead of using an already existing library) and it was too much work
+without seeing any real protection.
+
+On the other hand, since a lot of services use OAuth, it may be a good idea to
+fully understand the protocol. And that's what is here.
+
+# [How often does Rust change?](https://words.steveklabnik.com/how-often-does-rust-change)
+
+Rust has a release cadence of 6 weeks. There was another post about [keeping up with idiomatic
+Rust](https://timidger.github.io/posts/i-cant-keep-up-with-idiomatic-rust/).
+But does Rust change that much?
+
+Although Klabnik points that yes, I personally don't think that much. The
+language is still pretty usable since the 2018 edition.
+
+On the other hand, some things must be taking in the big picture. There is a
+huge run towards async in the ecosystem -- and not by Rust itself -- that
+seems a bit... disorientating. One example I can point is
+[reqwest](https://github.com/seanmonstar/reqwest). I'm using it for a lot of
+stuff and, suddenly, the API changed to use async, something I don't need
+right now. While there is a `blocking` module for using the old, non-async
+calls... it is still confusing that I can't use the main module 'cause I don't
+want/need async yet.
+
+# [System76 Launches Lemur Pro Linux Laptop with Open Source Firmware](https://9to5linux.com/system76-launches-lemur-pro-linux-laptop-with-open-source-firmware)
+
+While I'm quite happy with the XPS and an open source firmware may not be that
+much of a fuss (actually, it kinda is, but still...), you can't deny that's
+one hell of a pretty laptop.
+
+The fact that it comes with Linux installed probably means all its hardware is
+compatible and you won't find any troubles with drivers and such.
+
+Did I mention it was one hell of a pretty laptop?
+
+---
+
+This post was built with the help of
+
+* [9to5linux](https://floss.social/@9to5linux)
+* [HN Tooter](https://mastodon.social/@hntooter)
+* [newsbot](https://mastodon.social/@newsbot)
+* [Nextcloud 📱☁️💻](https://mastodon.xyz/@nextcloud)
+* [Read Rust](https://botsin.space/@readrust)

content/thoughts/hiring-so-wrong/hiring.drawio

@@ -0,0 +1 @@
+<mxfile host="app.diagrams.net" modified="2020-04-20T16:54:02.195Z" agent="5.0 (X11)" etag="3IN96yEPUU8pcOjBG7EO" version="12.9.14" type="device" pages="3"><diagram id="3228e29e-7158-1315-38df-8450db1d8a1d" name="Page-1">1ddNb5swGAfwT8N1Atu8HZOs7XboZZ20swcOWDV+Isd526ffQzAJialUqWlEUQ7x3y+Yn4kDAV00+yfDV/UzlEIFJCz3Af0eEBIxQoL2E5aHLsmipAsqI0vX6By8yH/ChaFLN7IU64uGFkBZuboMC9BaFPYi48bA7rLZEtTlWVe8El7wUnDlp39kaWuXRkl+rvghZFW7U2ck7Sr+8uK1MrDR7nwBocvj0VU3vB/LXei65iXsBhF9COjCANjuW7NfCNXa9mxdv8c3ak/zNkLb93QgUUxdpy1XG9HP+jg3e+g9sBPSY2G+lEotQIE5VtDHMEvDGHNY8ULadrmTEItra+BV9A016LZvbRuFpagdBrQdDnM8MPfn389OGCv2g8hdz5OARlhzwCaultL8W9x1cncfDbM+2Z1XMw7dGtSDhTyF3N1B1Wn8syJ+cZBvo5IPoEZkNptPCzVKr1Gj+5vSD5iKLE4YmZQpyyZgyjzTn3qL1yRBe7h4XdaRuC2bMCxzJSuNhQK7CXSatwQSN9OZq2hkWar7uZL82hU36BHYKB+BTW/kGnuuv8QW1OYrwyZTgE082N+Gl/IruzLPNY7v7pp6rs9SScvdSCOsHuM7tAZLgY+EN9GLE28bzcf02AgeuxFe5uEtQC+VxEfTaeMxdo3HRv+EPhMv9/FqDuuJy/mb4d3l+mEGcqjDdSEmbuf/ZCn7RDssnt+ojnWD11b68B8=</diagram><diagram name="Requirements" id="_mFYKGmZYzxxgRB4uli3">rZNLc4MgEMc/Dcd2FGIeR2NMc+nBZCY9EyXKBF2HkMb00xcFfDSHTmfKeGB/u/xxHyASlc2bpHXxDhkTCHtZg8gGYezPMEbt52UPQ5b+3IBc8swGDeDAv5iFnqU3nrHrJFABCMXrKUyhqliqJoxKCfdp2BnE9Naa5uwJHFIqnukHz1RhqT9fDY4d43lhr17ihXGcaHrJJdwqex/C5Nwt4y6p07KJXguawX2ESIxIJAGU2ZVNxERbW1e2cL8/7ZMwCVabI54l8XGd7F6M2PYvR/oMJavU/0oTI/1JxY25KnS5qoerr1bRrdTG+syFiECA7BzEx2G4DjSHmqZcteMz97R5VRIuzAVWULVnC1UKbfmtDFRqJLPtlub2V5hUrPnR2l8S9/tu6ClnUDIlH/qcU1msXgOjZEfcXzpwHyYm8Gyfi9Gw9JDaKc17+aHUemOr7cxhKDrf6OWR+Bs=</diagram><diagram name="skills" id="KO3FsDjXEZ7HhlBQ8uJI">zVTRboIwFP0aHpfQooiPirotccky3Uz2snS0QmPhYq2Cfv0KFJBpsrjsYQ0PvefennLPPWA5fpzfS5JGT0CZsLBNc8uZWBijHsZW8dj0WCEecisglJyaohZY8BMzoG3QPads1ylUAELxtAsGkCQsUB2MSAlZt2wNontrSkJ2ASwCIi7RFacqMihyh23igfEwMld7eFAlPkmwCSXsE3OfhZ11uap0TGou0+guIhSyM8iZWo4vAVS1i3OfiULbWrbV6e15tkpHvpiTx+0yex1O6F1FNrvlSNOhZIn6W2qnoj4QsWe1CmWv6ljrq1n0KHUwXnMhfBAgy4QzQUMPuxqHlARcFfZxbR3ulIQNqwsTSIqzkYqFjlBBA4k6o5mVS+PmVZhULP822h8aR800tMsZxEzJoz5nWHoDM0Bj8IExRta6xa1LojOjNCAxDg0b6lZmvTFKX1c9SecfL6ctokv78L73Zj7iBzOo36mO8Gg07v9/1VGvqzry7AvZ+/YV2RvwBtl12H6HZe7sZ+dMvwA=</diagram></mxfile>

content/thoughts/hiring-so-wrong/index.md

@@ -0,0 +1,72 @@
++++
+title = "Hiring So Wrong..."
+date = 2020-04-20
+
+[taxonomies]
+tags = ["work", "hiring"]
++++
+
+Today I found this [article by Neil Sainsbury on hiring
+coders](https://www.neilwithdata.com/developer-myth) and how the process is
+wrong. While I agree that the whole process is nothing more than red tape, I
+don't think the problem is what the article actually says.
+
+<!-- more -->
+
+The point Sainsbury makes is that we lack empathy when hiring. While I may
+have got this wrong -- as in "We lack empathy to understand people" instead of
+"We lack empathy to give people some chance" -- I believe the problem is that
+hiring is done by managers, not coders.
+
+I'm not going to bash managers here -- I worked with pretty damn good managers
+but also some awful -- I believe the problem is that managers don't actually
+understand what coding actually is. Heck, I don't believe _we_ understand what
+coding actually is.
+
+Here, let me show you this with Venn diagrams -- 'cause Venn diagrams are
+awesome.
+
+Imagine there is a company hiring developers. They have a set of necessities
+they want to fulfil:
+
+![The set of things a company works on and requires](requirements.png)
+
+And then we have the developer skills:
+
+![The set of skills a developer have](skills.png)
+
+... which is not what a company actually wants. What they want (or should
+want) is actually the size of the developer _phenomenological field_. This
+field describes the experiences someone had.
+
+Imagine two developers: Developer A spent the last 5 years working on the same
+field (let's say, mobile, or web development), using the same technology (say,
+Java, or React); developer B has done a bit of everything: they worked on the
+backend in two different languages, played a bit with three different
+JavaScript frameworks and did some play with different languages. Both have
+the same time in the field, and one could claim that A is a senior developer
+'cause they spent so much time in the same field, they probably know
+everything about it. But the fact is, when you check their phenomenological
+areas, you get something like
+
+![not in scale](phenomenological.png)
+
+What we actually have is that A is an _full_ worker, while B is
+actually a _senior_[^1].
+
+But nevermind, 'cause what we actually want is to fulfil the spot with someone
+that matches our requirements, right?
+
+Developer B, 'cause we experienced a lot but never got deep into anything,
+would have a match like
+
+![](dev-b.png)
+
+But developer A actually fits like this
+
+![](dev-a.png)
+
+---
+
+[^1]: I once said that what made a difference between full and seniors is the
+  amount of crap they had to deal with.