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.

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

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

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 instead of focusing on "boundaries".

Visualizing 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

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

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

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?

Rust has a release cadence of 6 weeks. There was another post about keeping 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. 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

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