diff --git a/content/links/20200423.md b/content/links/20200423.md new file mode 100644 index 0000000..4a768a4 --- /dev/null +++ b/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. + + + +# [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) diff --git a/content/thoughts/hiring-so-wrong/dev-a.png b/content/thoughts/hiring-so-wrong/dev-a.png new file mode 100644 index 0000000..2b4fc3e Binary files /dev/null and b/content/thoughts/hiring-so-wrong/dev-a.png differ diff --git a/content/thoughts/hiring-so-wrong/dev-b.png b/content/thoughts/hiring-so-wrong/dev-b.png new file mode 100644 index 0000000..8f43b55 Binary files /dev/null and b/content/thoughts/hiring-so-wrong/dev-b.png differ diff --git a/content/thoughts/hiring-so-wrong/hiring.drawio b/content/thoughts/hiring-so-wrong/hiring.drawio new file mode 100644 index 0000000..857dffb --- /dev/null +++ b/content/thoughts/hiring-so-wrong/hiring.drawio @@ -0,0 +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=rZNLc4MgEMc/Dcd2FGIeR2NMc+nBZCY9EyXKBF2HkMb00xcFfDSHTmfKeGB/u/xxHyASlc2bpHXxDhkTCHtZg8gGYezPMEbt52UPQ5b+3IBc8swGDeDAv5iFnqU3nrHrJFABCMXrKUyhqliqJoxKCfdp2BnE9Naa5uwJHFIqnukHz1RhqT9fDY4d43lhr17ihXGcaHrJJdwqex/C5Nwt4y6p07KJXguawX2ESIxIJAGU2ZVNxERbW1e2cL8/7ZMwCVabI54l8XGd7F6M2PYvR/oMJavU/0oTI/1JxY25KnS5qoerr1bRrdTG+syFiECA7BzEx2G4DjSHmqZcteMz97R5VRIuzAVWULVnC1UKbfmtDFRqJLPtlub2V5hUrPnR2l8S9/tu6ClnUDIlH/qcU1msXgOjZEfcXzpwHyYm8Gyfi9Gw9JDaKc17+aHUemOr7cxhKDrf6OWR+Bs=zVTRboIwFP0aHpfQooiPirotccky3Uz2snS0QmPhYq2Cfv0KFJBpsrjsYQ0PvefennLPPWA5fpzfS5JGT0CZsLBNc8uZWBijHsZW8dj0WCEecisglJyaohZY8BMzoG3QPads1ylUAELxtAsGkCQsUB2MSAlZt2wNontrSkJ2ASwCIi7RFacqMihyh23igfEwMld7eFAlPkmwCSXsE3OfhZ11uap0TGou0+guIhSyM8iZWo4vAVS1i3OfiULbWrbV6e15tkpHvpiTx+0yex1O6F1FNrvlSNOhZIn6W2qnoj4QsWe1CmWv6ljrq1n0KHUwXnMhfBAgy4QzQUMPuxqHlARcFfZxbR3ulIQNqwsTSIqzkYqFjlBBA4k6o5mVS+PmVZhULP822h8aR800tMsZxEzJoz5nWHoDM0Bj8IExRta6xa1LojOjNCAxDg0b6lZmvTFKX1c9SecfL6ctokv78L73Zj7iBzOo36mO8Gg07v9/1VGvqzry7AvZ+/YV2RvwBtl12H6HZe7sZ+dMvwA= \ No newline at end of file diff --git a/content/thoughts/hiring-so-wrong/index.md b/content/thoughts/hiring-so-wrong/index.md new file mode 100644 index 0000000..faf5927 --- /dev/null +++ b/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. + + + +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. diff --git a/content/thoughts/hiring-so-wrong/phenomenological.png b/content/thoughts/hiring-so-wrong/phenomenological.png new file mode 100644 index 0000000..9c607e0 Binary files /dev/null and b/content/thoughts/hiring-so-wrong/phenomenological.png differ diff --git a/content/thoughts/hiring-so-wrong/requirements.png b/content/thoughts/hiring-so-wrong/requirements.png new file mode 100644 index 0000000..2586c85 Binary files /dev/null and b/content/thoughts/hiring-so-wrong/requirements.png differ diff --git a/content/thoughts/hiring-so-wrong/skills.png b/content/thoughts/hiring-so-wrong/skills.png new file mode 100644 index 0000000..a359620 Binary files /dev/null and b/content/thoughts/hiring-so-wrong/skills.png differ