One thing to keep in mind when judging what's 'appropriate' is that Cloudflare was effectively responding to an ongoing security incident outside of their control (the React Server RCE vulnerability). Part of Cloudlfare's value proposition is being quick to react to such threats. That changes the equation a bit: any hour you wait longer to deploy, your customers are actively getting hacked through a known high-severity vulnerability.
In this case it's not just a matter of 'hold back for another day to make sure it's done right', like when adding a new feature to a normal SaaS application. In Cloudflare's case moving slower also comes with a real cost.
That isn't to say it didn't work out badly this time, just that the calculation is a bit different.
These engineering insights were not worth the 16 seconds load time this website took.
It's extremely easy, and correspondingly valueless, to ask all kinds of "hard questions" about a system 24h after it had a huge incident. The hard part is doing this appropriately for every part of the system before something happens, while maintaining the other equally rightful goals of the organizations (such as cost-efficiency, product experience, performance, etc.). There's little evidence that suggests Cloudflare isn't doing that, and their track record is definitely good for their scale.
It's not even clear that the premise is true. There's lots of 'research' done in the big tech companies.
The biggest reason why companies don't seek to emulate "Dupont, Bell Labs, IBM, AT&T, Xerox, Kodak, GE", is probably that it reads like a list of textbox examples of "companies that failed to execute on their research findings", so clearly there was something wrong with this approach.
From "framework fatigue" to "new framework" in five paragraphs.
Personally, I find all these minimalist, back-to-the-basics frameworks a bit misguided. It's always reeks a bit of "well my farts don't smell" – other developers' frameworks are bloated, dependency-overloaded and too complex. My new framework is simple, based on a powerful idea, and just right.
Imo, the best way to build a truly good web app in 2025 is to embrace both server-side rendering and client-side rendering, by sharing the same rendering logic between client and server, like e.g. SvelteKit, Next.js and others do.
- no company generates revenue in its first second. Even if you start a lemonade stand tomorrow, you'll have to buy some lemons first. The time-to-revenue might be very short, but it's never zero. Therefore, making no revenue for 1 day or for 10 years is not a step change, but simply a point on a curve.
- Capitalism is basically a long history of creating vehicles with increasing sophistication to bridge that gap: provide funding for ventures that have returns in the future. This is intrinsically difficult, and it's easy to waste money, but it can work immensely. This started with the Dutch inventing limited liability corporations to fund ship expeditions, and today's VC is essentially an extension of that.
- It has worked well in the past to bet on companies that don't optimize for time-to-revenue, but something else – famous examples being e.g. Amazon, Google, Meta, who all lost lots of money initially.
Hence there can be companies that make no money for quite a while. And it can even turn out that the vast majority of the companies that make no money for a while never make any money. Accepting this risk is a feature, not a bug.
I think what changed is that we at least can attempt to limit 'bad' things with technical measures. It was legitimately technically impossible 10 years ago to prevent Photoshop from designing propaganda posters. Of course today's 'LLM safety' features aren't watertight either, but with the combination of 'input is natural language' plus LLM-based safety measures, there are more options today to restrict what the software can do than in the past.
The example you gave about preventing money counterfeiting with technical measures also supports this, since this was an easier thing to detect technically, and so it was done.
Whether that's a good thing or bad thing everyone has to decide for themselves, but objectively I think this is the reason.
It's valid to think of this as Microsoft sort of squandering a unique opportunity to become the ubiquitous video conferencing standard by not investing in Skype, back when it had a market-leading position. Another way to look at this is that even though they bungled this, they still managed to become that solution through Teams. Even though they failed to compete with Skype, got leapfrogged by Slack, and then again by Zoom, they still manage to come out on top, at least in corporate America.
You can argue that they could have been Zoom, too, but looking at Zoom's 22bn market capitalization I don't think Microsoft sheds many tears about that thought. It's more a testament to the incredible market power and distribution muscle Microsoft has, that they can afford this many bad decisions and still win in a way.
This really reads like a parody. Press release, “a consortium of 20 research institutions”, “awarded the STEP (Strategic Technologies for Europe Platform) seal”. Lots of grandiose self-congratulations. All with nothing to run, download or try of course.
You should read the article in full, and/or learn the difference between a share and asset deal. Your link is about the former, the article about the latter.
We're looking for product/UI/UX designers, both for brand & communications as well as our data visualization product.
Datawrapper is a data visualization tool for journalists & other publishers. Used by NYT, Washington Post, AP, and many others. You’ve likely seen a Datawrapper visualization before - election results, Covid numbers, maps on world events, etc. are created using Datawrapper. We reach >200 million unique monthly visualisation viewers with a team of just over 30 people, fully bootstrapped. Looking for 2 talented designers to join our team.
This hack seems to affect the Dropbox Sign application, which is based on HelloSign which they acquired a few years ago. It’s still running on the hellosign.com domain and seems mostly separate, so it wouldn’t surprise me if they also store passwords differently.
I find it a strange choice to explain double-entry bookkeeping with the example of "one entry for Alice, one entry for Bob". That's really not what it's about. It's obvious that a transaction with two parties could be recorded in two places, but to me the crucial point of double-entry bookkeeping is that it requires two entries for each party of the transaction. So if Alice buys book from Bob, four entries are made.
I get that this is supposed to be a simplification for educational purposes, but I find this is simplification is an oversimplification, since it omits the key point.
I'm not a psychiatrist, but this bit stroke me as funny:
> Solving the problem of conditional self-worth is less complicated than you might think. You don’t have to go through regression therapy and get a better understanding of how your early-life caretakers gave you implied messages of contingent worth, neither do you have to sift through the wreckage of emotional or physical suffering you endured growing up.
> You simply need to recognize that you are worthy exactly as you.
How's that different from telling a depressed person to 'simply stop being sad', or a disabled person 'simply stand up and walk'? I'm sure the point of regression therapy is to get to that point, and this 'realization' is not a shortcut to it (caveat: I don't actually know what regression therapy is).
On mobile, the "Let's talk" button in the top right corner is cut off by the carousel menu overlay. Seems like CSS is still out of scope of the bug fixing magic for now.
On a more serious note, it's an interesting blog post, but it comes off as veeery confident about what is clearly an incredibly broad and complex topic. Curious to see how it will work in production.
"I value Figma the product, I couldn't care less about how much money they raised" is an argument like "My power comes out the socket, so I couldn't care less about building power plants". It's hard to have one without the other. Figma the product was built with the the money they raised.