Google made $280B in revenue in 2022 which means this article is claiming that at least 1/3 of it (since they said over $92B) is coming from Android only.

Does that align?

30% of the billions per year made by all the casino games on the app store is a tremendous amount of money. Just a single title like Fate Grand Order or Genshin Impact brings in over $1B every year. There are dozens of titles like them and hundreds more that bring in $100m+/year.

You are missing a few things about the Ruby based CLI:

1. dependencies for Gems are specified in the gemspec file and not the Gemfile. See https://github.com/Shopify/shopify-cli/blob/main/shopify-cli... for example. There's a few non-development dependencies.

2. since it's difficult to package up a Ruby gem for distribution, maybe dependencies were vendored directly in the codebase: https://github.com/Shopify/shopify-cli/tree/main/vendor

This isn't meant to be a comparison of the number of dependencies or anything. Just pointing out a few nuances to how the Ruby dependencies were handled.

This is an editorialized title. Bloomberg's is "Shopify Tells Employees to Just Say No to Meetings"

I'm highly in favour of this, but wanted to point out an important implementation detail in case people don't want to look through the code.

Since WordPress doesn't have a database abstraction, SQLite integration is done by transforming the SQL query strings meant for MySQL. This not only means doing regexp matches with string replacement, but trying to emulate MySQL functions with either SQLite equivalents, or in the worst case, in PHP application code.

This sqlite abstraction has been working well for me: https://github.com/aaemnnosttv/wp-sqlite-db

it’s one file — ‘db.php’ — you swap in for the core file. From there, it’s mostly been seamless. ~20% of the 5k LOC, is “Method to emulate MySQL XXX() function.”

Less than that for query parsing, regex & rewrites

https://github.com/aaemnnosttv/wp-sqlite-db/blob/master/src/...

Lol after decades of programming, there actually WAS a need in THIS project to 'abstract/subclass' the db.code. You know in case we want to switch dbs in the future.:)

... of course it would be fucking cursed, it's wordpress

Interestingly, WordPress does (kind of) have a database abstraction. The way you get it is to format your data model as a “custom post type,” and then you basically get an object store with various predefined functions to access it… kinda works for more use cases than you’d think, but also weird!

> Since WordPress doesn't have a database abstraction

How hard would it be to "add one"/refactor?

It doesn't even currently use real parameterized queries...it has a method that sounds like they are real, but they aren't...just a really hairy bunch of string escaping. They really need to re-write the database layer from scratch.

Behold: https://github.com/WordPress/WordPress/blob/master/wp-includ...

This brings back bad memories. I shouldn’t have reminded myself of what WP code looks like.

> How hard would it be to "add one"/refactor?

From a technical POV: This is potentially straightforward if WordPress leverages (and "blesses", for plug-in developers) a proven abstraction layer like Doctrine DBAL that supports both MySQL and SQLite.

From a non-technical POV: There are tens of thousands of WordPress plug-ins, and even updating the top 1,000 that are good/popular will be a multi-year lift.

plug-ins are likely the real burn.

MediaWiki technically supports PostgreSQL and SQLite for many years, but extensions are really MySQL focused making it the only real choice.

> How hard would it be to "add one"/refactor?

To add one? Trivial.

To refactor all of WP core to use it? I could probably do it in a week or two of focused work.

To enable all plugins and wordpress themes to use it? It is, literally, probably a million times more LOC.

I'd guess very hard. But just refactoring the WordPress codebase isn't enough, you'd ideally want every plugin to adopt the new API as well... Although you could always keep this implementation as the fallback behaviour.

The problem is not adding one. The problem is that it would complicate the infrastructure. From adding more performance requirement to WP wherever it is hosted to the compatibility concerns with plugins. Its a tall tale.

Probably easier to use MySQL as the db layer and have it use SQLite as the backend store somehow heh.

There's an existing WP "drop-in" plugin that can be used with Composer: https://github.com/aaemnnosttv/wp-sqlite-db

Using that + a WP composer package (like https://packagist.org/packages/roots/wordpress) is much easier to maintain that a full "fork" of WP.

Now I'm hopeful that (a fork of) WordPress can eventually run on Cloudflare's new D1 service:

https://blog.cloudflare.com/introducing-d1/

This repository is:

- the WP-sqlite-db plugin

- akismet added

- themes before twentytwenty removed

- an empty 'wordpress.db'

- wp-config.db setup set to use the WP-sqlite-db plugin with the right file

- README

Which is all work to do to get setup correctly.

NOTE: the wp-config.php also needs to be modified to remove the keys and salts as well.

(edit: formatting).

There's about 4-5 very predictable comments already that boil down to: "you’ll end up building a framework"

The author of this article directly addresses that common trope, so these comments are lazy. In fact, this article has a very nuanced but important rebuttal to that argument:

> no, you’re going to write an app instead of a framework.

The Information: A History, A Theory, A Flood by James Gleick

This is specific to "Information, communication, and information theory." but it's still quite broad and a great read.

I loved this book when I read it indeed. Really comprehensive and smart.

Of course not, their status page says All Systems Operational! (yes it's down)

https://status.digitalocean.com/

Their systems could be both operational, and unreachable from the network. The beauty of network partitions is that it's impossible to know for sure :)

You would expect that a company as big as they are to update their status page as well...Anyhow, at least they communicate via twitter.

The one caveat this article doesn't mention is worse handling but they replied in the comments about it. And handling matters way more at higher speeds, plus they commented the extra weight matters more for steep climbs too.

This, and a wider tire also has a larger front surface, resulting in more aerodynamic resistance. As every watt counts in the pro peloton, this is an important factor. For us amateur riders, probably not so much.

I was a little surprised: the weight difference isn't huge. It is about +27% between Conti 5k 25mm and 32mm, or 60 grams per tire.

Aerodynamics are the only real reason, I think.

We quickly ran into the same issue at Shopify. We've since moved from a flat list into sections by "domains"; within each section is the breakdown by type. You can see it here: https://shopify.dev/docs/admin-api/graphql/reference

Of course this grouping has to be done a little manually. And it's not perfect, but definitely better than the flat alternative. For reference, we have thousands of types.

I could see us adding support for grouping via the "metadata" that would inform the nav bar on how to group and accordion / collapse things. There already is a pattern for grouping in the library that is exemplified in the Query and Mutation carats