Links for 2020-06-01

Distributed Systems, C in Rust, Protecting Projects, No Code, Android, Research Blog, Contact Tracing and Privacy (again).

Notes on Distributed Systems for Young Bloods

A bunch of "things you need to remember when working on distributed systems", not only for "young bloods", but also for those who are doing this for sometime, just as a reminder.

writing c library in rust

One of the cool things about Rust is that you can combine Rust applications with any other C library. But not only that, it is also possible to write code in Rust and export it as a C interface -- and, with that, combine with any other language that can bind with C, which are basically every language around.

Self-Protecting Projects

Projects without a CI/CD pipeline are doomed to fail.

That's basically the gist of the post and I'm all for it too. There are a few missing bits, like you can have a CI/CD pipeline and not having a policy for writing tests; but, at the same time, I reckon there is no easy way to measure if the proper things are being tested (and no, "every single function" is not a measure).

Also, the idea of making the application open tickets every time the application crashes is cool and all, but that only works for applications that run on your own environment -- an embedded application would have a hard time making this.

Why I Keep a Research Blog

I've been thinking about this for some time: I have a list of "Things I Don't Know", which I keep on Joplin. The idea is that, when I have some time, or when I see some information related to the topic, I can add to the note, till I finally feel confident enough to say "Ok, now I understand this".

But for some time I've been writing this kind of post (the "Links" ones) as a way to keep a list of things that I feel I may need in the future. So, if I keep a list of "maybe in the future" links, why don't I put the research topics also in this blog? Surely, right now, it will have only the topics and no content (sorry!) but making it available may also help someone else.

There is one point that one could make: If I share links, why not share links related to those topics, and let the blog engine worry about grouping them? The point is actually to write whatever I learnt in my own words, 'cause those are easier to recall in the future.

I'm still wrangling with the idea, though. No promises.

Minnesota is now using contact tracing to track protestors, as demonstrations escalate

You may recall that I've been, for a while, mentioning that contact tracing applications may sound good to find someone that had contact with another someone with COVID-19 (so we could alert and/or take that person to a hospital, before it was too late for treatment), but there were serious privacy problems with it? Well, there we go.

A black person was brutally killed by the police in the USA, and the community rioted to the point that a police department was set afire -- I'm not saying it was right or wrong, but you have to think the type of indignation that make people set a police department on fire.

And those people who worried that they may get in contact with someone that got infected with COVID-19 and installed any contact tracing application are now being tracked by their association with other demonstrators.

And that's what I was talking about. There is no policy that says "this tracing information may be only used for diseases and nothing else".

The 'No Code' Delusion

Ignoring the fact that the post talks about a movement for "creating business rules without the need of a developer", what I found interesting is the visual comparison of the business rule (in a diagram) and the code (a piece of Python code). Why? Because that's exactly the way applications should be written: There is logic and it is described in a combination of functions, which content doesn't make part of the rule itself and there are no rules "hidden" inside the function of a rule. There is nothing of "let me put a regexp here to validate the email". That's not what the business rule says, so that's not in the code. If the business rule said "You should test this, convert to that and send this to there", that's exactly what the function should have.

On the other hand, I didn't realized that diagrams require some previous knowledge: Which symbol represents a test? Which symbol represents "white in the screen"? And so on.

What I need to mention, though, is that COBOL was created for non-programmers so they could describe business rules and run them; SQL was desgiedn so non-programmers could describe how to retrieve and process data; BDD has always been described as a way for non-programmers to describe how a system should be validated.

Google pushed to take action against Android bloatware by 50+ organizations

A post from earlier this year, but there is one point that I need to bring:

Android is "open source", right? If it is, why doesn't those 50+ organizations just fork it and make their own Android? Surely, in a 50+ organization group, there should be a few developers and making them all work on that could solve the problem, right?

Well, thing is, Google controls Android. You can't simply fork and hope that you can run on your device. You can't simply make a pull request and hope it will, one day, be part of the system.

"Android is opensource" is a farce. It is "source available", not "open source" by any stretch of imagination.

This post was built with the help of

• HN Tooter
• Read Rust