Owning Your Data, Latency in Async Python, eBay Port Scanning, Rust Macros, Rust Tests, Rust Project Organization, Going Remote, Shapes of Code, Public Domain vs Copyright, Libre vs Open.
While the idea is commendable, I think the proposed solutions have a number of problems:
- Having an open standard only means having multiple "open" standards. XKCD explained this pretty well.
- Exporting data could, indeed, be in different formats, but using a database could also mean that each application would use their own schema (and remember the thing about the standards and everyone having their own?).
- As the author pointed, creating an API is costly. Why would some company implement the API when they can do nothing and save money?
- Worse: In a time when "data is the new oil", why would companies share their oil well?
I don't mean to diss the post, but there are a few things that need to be fixed before we can dream of something like this -- for example, closing the damn data-oil well.
I'm not sure I follow the author description on how to solve the problem presented.
Thing is, async (in any form) cannot be compared with threads, which seems the
initial idea on the description of the problem. Async is cooperative
multitasking, which means someone has to say "I'm done" so another task can
continue; by using a heartbeat task but doing I/O (
In today's "Let's Abuse The Web To Find a New Way To Track People", some people found out that the eBay website (yes, the website, not an app or something like that) is using WebSockets (yes, websockets, not some fancy technology, not some raw socket thingy) to do a port scan on the user's computer.
There are two things that will happen now: People will start looking for those things and stupid people will add that to their websites.
Maybe browsers could block websockets to one single address and, once it is used, the site can't open a new one on a different address/port.
Macros is a part of Rust I still have to explore. This post describes one of the simples macro types Rust have (there are three).
On my last live (it was in Portuguese, sorry English speakers), we discussed the fact that my toy project had no tests -- in my defence, that was kinda intentional, as all I'm doing is exploring more of the language.
An just out of the blue this post appears, which describes a bunch -- maybe I bit too much -- of testing strategies for Rust code.
And just related to the previous event (you know, the live discussing Rust code), I was also reorganizing my code, and now have a few more ideas on what to do in the future.
A good collection of points now that large tech companies switched to remote working (some as "remote first" now) about what may and what may not work straight away when a company switches to remote working.
This is one hell of an interesting post: Describing code by its shape -- basically, what you see in one of those "minimaps" -- instead of their content. The curious parts is that it describes "what" the shape means and how it can be improved in some refactoring.
I understand what the EFF is trying to say here but, at the same point, we have to understand that copyleft -- the thing that powers every open source project today -- is based on copyright. The thing that prevents open source being abused is the fact that is copyrighted by someone, and that someone will tell exactly what others can do with the code. It's the copyright that protects it from being snatched by someone else and being used to lock-in users.
Maybe the idea of copyright is being abused in a lot of places, but it doesn't mean it is (totally) broken.
One thing to keep in mind here: Public Domain means anyone can do anything with it. It could mean anyone could pick an free software and turn it into a locked-in version of it.
This is a quick and good explanation of the old discussion of the difference between "free software" and "open source".
This post was built with the help of