Browse Source

Merge branch 'draft/links-20200423' into preview

master
Julio Biason 5 years ago
parent
commit
433b5611d9
  1. 128
      content/links/20200423.md
  2. BIN
      content/thoughts/hiring-so-wrong/dev-a.png
  3. BIN
      content/thoughts/hiring-so-wrong/dev-b.png
  4. 1
      content/thoughts/hiring-so-wrong/hiring.drawio
  5. 72
      content/thoughts/hiring-so-wrong/index.md
  6. BIN
      content/thoughts/hiring-so-wrong/phenomenological.png
  7. BIN
      content/thoughts/hiring-so-wrong/requirements.png
  8. BIN
      content/thoughts/hiring-so-wrong/skills.png

128
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)

BIN
content/thoughts/hiring-so-wrong/dev-a.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

BIN
content/thoughts/hiring-so-wrong/dev-b.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 19 KiB

1
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>

72
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.

BIN
content/thoughts/hiring-so-wrong/phenomenological.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

BIN
content/thoughts/hiring-so-wrong/requirements.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 8.8 KiB

BIN
content/thoughts/hiring-so-wrong/skills.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 9.4 KiB

Loading…
Cancel
Save