This held up much better in the earlier days of Python.
Sooner or later every sufficiently popular programming language is confronted with the dilemma of either breaking backwards compatibility and/or adding "alternative ways to do things"
Pathlib is an interesting one. It even has a correspondence table [1]. The introduction of pathlib made sense because it is just much nicer to use. But you couldn't drop the equivalent functionality in the "os" module for backwards compatibility. It's just far too widely used.
The is no magic bullet for this one. Either you accept introducing duplication in your language or you go through a hard change (f.ex. the Python 2 to 3 change).
The softest way to migrate might be to flag functionality as deprecated and give users a fairly long time (talking years) before dropping it. But no matter how much time you give the users there will be users who won't change until it's too late.
So there really isn't a winning path for this one.
I've been in the industry for over 30 years and I absolutely get where you're coming from. It is an ever changing field and it can be exhausting. I hear this repeatedly from many coworkers (and workers from the same field).
All I can give is some advice from my lengthy experience.
Most of the changes happen on the "edges". Those edges are primarily three fold:
First, the user interface: everything that deals with input parsing and formatting. This also includes protocol marshalling (Http, JSON, XML, ...)
Second the data persistence. This involves choice of database or any other persistence. Including serialisation of your data. Any I/O really.
Third, anything to do with deployment. This includes environment isolation, configuration management, process automation and so on.
These the edges have nothing to do with your core application logic.
You can reduce the impact of a switch to a new stack by inflating your core logic and shielding it from the rest of your stack.
This is tricky and I still catch myself all the time doing it wrong. Because doing it wrong is tempting and easy.
For example, consider a connection to the db: you will need a connection string. You can fetch that from an environment variable somewhere deep in your core code. But by reaching out to the system like that, you make that core piece of code dependent on the deployment strategy. Instead, you can move that part as close as possible to the entry point and then pass it down as function/class arguments. You can group similar operations together, close to the entry point. That way, if the dependent e strategy or the stack changes, your core code does not need to change.
Another example is the case where your core code is dependent on a library from your stack. For example, when working with python and flask, it's easy to import "request" or "g" from the framework. But every piece of code relying on that will be tightly coupled to the framework and subject to change whenever the framework changes (either same framework with breaking changes, or framework switch). The solution is the same. Move those elements as close as possible to the entry points. In this example of flask, keep this as close as possible to your routes. But also keep your routes clean of core logic. Interact with the HTTP layer only and pass the values as arguments to your core.
Finally, a similar situation, but much more sneaky and hard to spot is reliance on data types from your stack. Spotting cases where you rely too much on library modules can be done by investigating imports. But reliance on data types is harder to spot. Sticking with the flask example: the http headers are encapsulated by an object of the flask stack (werkzeug in this case). You may be careful and extract the headers in the route to follow my earlier example. But if you then pass the headers unmodified down into your core logic you will again be coupled to the stack. Instead you should extract only the values you care about and hand only those down to break the coupling.
Finding the right balance where to cut the coupling is challenging. The more you cut, the better you will be shielded from changes. But the less you can benefit from pre existing implementations from the stack. Where to cut is ultimately a design decision.
When done well, it will be far less frustrating to jump on the bandwagon of the latest tech. Not completely painless but far less stressful. Not least because you will have confidence that you didn't accidentally break core logic.
Ah, I’m red/green blind too but most blue leds in electronics don’t seem to have a status function beyond "on/off", they’re there just to look futuristic.
Has there been any kind of analysis about potential biases? From the top of my head I can think of the fact that Spotify was not available in every country from the start. Also, not every person on the world streams their music. Does this data include record sales for examlpe? Does it normalise the data somehow taking into account the percentage of the population that streams music versus other means of consuming music?
Or is it just plain and simple data gathered from Spotify?
I'm not saying that there is anything wrong/bad about the results. But without knowing the details on how the data is collected, it's hard to read anything from the results.
Granted it's not groundbreaking but it's attempting to make UUIDs "better". For computers it doesn't really matter what an identifier looks like (minus memory to store long strings, maybe). For users, it does matter.
Long UUIDs are just an artifact we've grown accustomed too. By no means are they the ideal solution.
The type of namespacing OpenPhoto does doesn't apply to everyone either. Sometimes you do need a UUID that isn't namespaced. Sometimes you don't.
Yes... I mixed up the terms. Thanks for spotting that.
While I have never fooled around with it, I think using the LAB colorspace could be interesting as well. As I remember from my psy course, the two most common forms of colorblindness are red/green and yellow/blue.
Given that the LAB colorspace models these exact axes, it could be interesting for something like this.
But as I said, I have not yet investigated a lot in this direction.
> [...] those are really ugly; mine are much nicer (and more flexible).
This is a matter of personal preference. The more people you ask, the more opinions you will get. I could chip in mine, but that would serve no purpose.
You could see statements like these as a form of libel/defamation. While the statements are not necessarily false, they may cast a negative light on whomever is generating these images (in this case, gravatar.com).
I would try to avoid these statements, and simply go ahead with your project. And let the people decide for themselves which one they prefer.
He's being honest. The existing solutions aren't any good, so he made one that is better.
There are thousands or millions of FOSS projects that were started because the existing ones are bad, and they've all said that they were started because the existing ones are bad. It's just the way it works.
Now, if both he and his competitors were serious companies with a handful of employees that were charging money, then it would be less appropriate. But they aren't. His project was created because the competition's projects are ugly, and he should be able to say that.
You cannot solve colorblind problems with these changes alone. The best way, is to change shape.
There are different types of colorblindness. The worst being the one where you are totally unable to discern colors. Hue and Value alone won't solve the problem.
For example, at first I didn't see the difference between "Alice" and "Bob" on your about page. I had to look closely to see it. And I'm only mildly color-blind.
Sooner or later every sufficiently popular programming language is confronted with the dilemma of either breaking backwards compatibility and/or adding "alternative ways to do things"
Pathlib is an interesting one. It even has a correspondence table [1]. The introduction of pathlib made sense because it is just much nicer to use. But you couldn't drop the equivalent functionality in the "os" module for backwards compatibility. It's just far too widely used.
The is no magic bullet for this one. Either you accept introducing duplication in your language or you go through a hard change (f.ex. the Python 2 to 3 change).
The softest way to migrate might be to flag functionality as deprecated and give users a fairly long time (talking years) before dropping it. But no matter how much time you give the users there will be users who won't change until it's too late.
So there really isn't a winning path for this one.
[1]: https://docs.python.org/3/library/pathlib.html#correspondenc...