Links for 2020-04-23

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)