Links for 2020-04-232020-04-23 #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.
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.
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.
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".
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.
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.
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.
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.
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.
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