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