> “If you stop using Firefox,”, Mozilla advocates will tell you, “Chrome will become the only real web browser”.
> Yes, but isn’t it a bit too late to worry about that? And what change do individual choices make here?
I don't think it's too late. Firefox exists because the same situation was happening in the late 90s/early 2000s - replace Chrome with Internet Explorer and I could believe this was written in 2002.
It's a different landscape today[1], but I maintain it wasn't too late then and it isn't now - the fact that we're talking about FF almost 20 years after its first release is a testament to that.
I'm not a daily FF user, but I am part of the install base. I think that diversity in the browser ecosystem is extremely important and I'm not a "Mozilla advocate".
[1] I'm guessing part of the early success of FF was its support for OSX/Linux where IE had no reach and it gained them a lot of early traction/users so it isn't an apples to apples comparison with Chrome today. But, I remember the times, and many (even non-techie) people would adamantly install and switch to FF as the first action when they got a new PC/fresh Windows install - those individual choices added up to a very large user base.
I am in the same boat. We build a niche product that serves a Windows market (an add-on to Windows-only software). We use Macs for a variety of reasons and I'm terrified at the possibility of having to switch. If we don't get performant virtualization a la Parallels or VMWare Fusion for x86, my entire toolchain falls apart and I have no choice but to dump Mac. I'm sure there are a ton of other developers that depend on virtualization. I hope Apple has considered this and can talk about a solid path forward for x86 virtualization as soon as the ARM transition is announced.
Also, does it start with 0 or 1 (or -3023 for that matter)? As a programmer you would assume of course it starts at 0, but since this thread talks about "non-programmer" academic types I think it's worth mentioning. What if I want a range of 1-15, or 20-50, can I still use range()? I can't tell from the Python example but I can tell exactly what I would need to change with the Swift one to make it work exactly how I'd want.
Very true, and this is especially important in data science, where the majority of languages, other than Python, are 1 indexed (Matlab, Julia, R, FØRTRAN).
Your comment is accurate but I think its the fact that GitHub styles it in that way. I do wish it was possible to use markdown-types of elements in this way so that it could fallback on non-GitHub rendered web pages, or still look good in a text editor vs. HTML tags all over the place.
Maybe something like
^ Header
^^^
Collapsed
^^^
Similar to code blocks with the ``` syntax. I dunno.
My guess is that the notification in question was just letting you know that the person who imported your address is on LinkedIn and wants to connect?
It may look like an account notification but I'd think of it as more of an invitation.
It's not that they've connected your work email to the account with your personal email (publicly at least, privately I'm sure they keep that info). And it's not like they're sending any other types of sensitive/account/password reset information to that address assuming it's associated to the account connected to your personal email.
They're just trying to get you to join LinkedIn and connect with a coworker who gave them your work email address – assuming if you already have an account with a different email you'll login with that and connect with said coworker there.
Yes, the intended recipient sentence probably wouldn't be an email if LinkedIn was sending it to an existing account..
But I do think sending unsolicited emails in this fashion is illegal anyway in many places. I always found their attempt to get around this with a specific sender interesting, but I doubt it is universally legal.
I found the lack of any horizontal line separating rows in the given examples of good tables off-putting. In the examples given from The Economist they are using horizontal lines and I agree those are great examples.
In most cases they are using dotted horizontal line which is better than a solid line.
In Google Slides or Excel it's easy to use low-contrast shading between dark and light backgrounds which is another less-intrusive way to delineate rows without using a solid line.
This is an annoying trend; it's true that row lines add a lot of noise that distracts from the content, but you should use color and value to reduce the dominance of the table lines, not remove them altogether.
For a small 3 column table, it is not necessary. The tables on the page "Example Tables I" could have done without horizontal lines and a little more space between rows would have been enough.
Hmmm...I had the opposite reaction. "Good guidelines, why don't their Economist examples follow them?" I find very light shading to be way better than horizontal lines.
I know what you're saying but I'm okay with it. In this case Apple chose users over developers. iOS developers have to do a little more work (Apple has made it very easy from what I've seen of the framework) and have a little less freedom but users signing in to apps using 3rd party auth are guaranteed the privacy protections Apple is promising. They drew a line in the sand by making their solution mandatory but I think they had to to deliver what they're promising to users (which I think is great).
That privacy seems a bit overboard though. This is fine if a user can create his account directly inside the app. But it's not very clear how to support a workflow where you have an organization with multiple users authorized by an admin to use the app. How can the admin add a user to his organization, if he doesn't know in advance the user randomly generated email? I guess you could send an invitation code, and let the user enter that code after the apple sign in, to associate the account to the authorized user. This sounds more complex for the user than a workflow where the admin can directly authorize specific emails.
The randomly generated email is a user choice, they can also provide their real email. The randomly generated one would not work for things like slack sso etc.
This is true for Google, Facebook, and Twitter logins as well. It's a valid criticism for using any third party authentication provider (which I personally avoid and will be avoiding Apple's).
The login provider doesn't store the service account itself, so it's possible to "eject" your account and use some other sign in mechanism as long as you have control over the email address.
