While I definitely understand what the author is saying, the reality is that, for the majority of writing developers will be doing, having something that is easy-to-produce and easy-to-consume is paramount. There are tons of more powerful and flexible options than Markdown, but none that let you create a document that is both computer- and human-readable quite as quickly. Documentation that is written is better than documentation that isn't.
Which is why I use rST - just as easy to write, but enough more powerful that I'm not left hanging when I realize I need to do something more complex.
> Documentation that is written is better than documentation that isn't.
I have to disagree with this. I've read too many out of date documents. If documentation exists that isn't correct it is worse than no documentation at all. The only useful documentation is documentation that is correct, easy to navigate, easy to search, and easy to update as the world changes (there might be more?).
Good documentation is better than bad, it is debatable if bad documentation is better than no documentation or not (in part because some bad documentation is worse than others).
This is sure to put them ahead of Apple Pay, Samsung Pay, Google Pay, Zelle, and Venmo. Everybody will be excited to use the payment system that charges them the most money!
If I'm reading this correctly, it's only for accounts with 12 months of inactivity. If you go for a year without logging into the service, then maybe you're not a Paypal customer anyway.
You certainly won’t return after they suddenly charge you 10 dollar for the privilege of retaining your personal information. It’s a money grab, pure and simple.
Seems to me that we will very, very quickly see why these teams were created.
Less snarkily, I appreciate that not everyone loved their work. But their work solved a particular problem, even if it created others. Now that problem is unsolved again. It will be interesting to see if a better solution to the problem appears by 2024, or if the decision is to allow that original problem to exist.
It goes without saying that the political landscape in 2012 vs now is completely different, where one party is actively working to undermine elections.
The world is a different place than it was in 2012. Imo, around 2010/2012 is when social media disinfo in politics really started taking off in an organized/concerted way from the big players.
> Adams' men called Vice President Jefferson "a mean-spirited, low-lived fellow, the son of a half-breed Indian squaw, sired by a Virginia mulatto father."
This is good, right? There are better languages for most (although certainly not all) purposes, whether you measure "better" through features like memory-safety or through developer happiness or anything in between.
Most of the systems that were written in C++ in the past didn't have to be written in C++. Now they'll become hard to support, because they are in fact hard to support, and eventually they will be refactored or rewritten.
Same thing happened with Assembly and COBOL programs being written into C++.
a) Yes I run technology at a more serious HFT firm than Jane Street.
b) Jane Street also use FPGAs, so you cannot exactly say they just use ocaml, it’s more nuanced than that, they are using a mixture of technologies. I think they made a very unfortunate choice early on and are still paying for it.
Rust becomes extremely painful as soon as you want to push the boundary. If you need to ensure you fit a struct into a cacheline, or you need to ensure an object is reused. All of these things can be done, even things like recycled intrusive structures, but it’s constant friction.
If you don’t try and push the boundaries it’s fine (and if you make everything unsafe you’d also be fine), but otherwise life quickly becomes painful.
If you are going to go to that level of effort then you’ll find it much easier in c++ and the downsides of c++ become insignificant.
On the other hand if you’re writing a web backend c++ would be a terrible terrible choice.
As a marketer in a former life, I can't understand why somebody would do this. It's very cheap to get a separate phone number for each inbound channel and there's tons of software that will track which channels are working for you, starting at the low end with an intern and Excel.
I read this as "evil Microsoft Product Managers researched the market and understand the competition and if they decide to compete with you watch out because they will be evil folks who understand market needs deeply and are intimately familiar with competitors."
I mean, I get that's hard to compete with for a smaller company or an less-formal org, like those who maintain many OSS projects, but that's just... being a good product manager. If you don't like that, hire a Product Manager and get those skills yourself.
It's interesting -- they ID the actual cause of the problem up top, and then just zip right past it. The problem wasn't the hardware failure, or the lack of backups, it was that customers expected them to have backups.
Gandi goes into some detail on the recovery process and on ways to fix the issue in the future. But, apart from some hand-waving, they don't have any specifics about how they'll communicate expectations better with their customers in the future.
Imagine the counterfactual: Gandi's docs clearly communicate "this service has no backups, you can take a snapshot through this api, you're on your own." Of course customers with data loss would've complained, but, at the end of the day, the message from both Gandi and the community would've been "well, next time buy a service with backups?" Yet there's no explicit plan to improve documentation.
People posted an excerpt of their manual, it explicitly called "snapshots" a "backup" and customers were surprised when they asked them to restore the snapshots and only now they explained the snapshots were not backups...
Absolutely! And yet no explicit planning for how they'd reword the manual in the future. That is the root cause of the real problem here -- not that there weren't backups, but that there weren't and the manual said that there were, and there's no plan to fix that!
A "personal key" was a 16-character string that was used as a salt(?) for encryption and as a backup for lost passwords, https://www.login.gov/help/creating-an-account/personal-key/. Frankly, this change seems like an improvement. While text messages are weak, the other options are strong and widely-available.
I think this is exactly it. Offices are prettier than ever and also less conducive to work than ever. I bet most people would choose an office with actual quiet workspaces -- even full-height cubicles! -- given that commutes were also reasonable.
