The source content for blog.juliobiason.me
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

129 lines
5.8 KiB

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