bretthopper

This comment is 10x more useful than your website. I'd suggest moving most of this copy onto the site just in a better format.

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?

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'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.

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.

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.

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.

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

https://status.digitalocean.com/

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.

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 clicked on an example site (https://singlel.ink/u/gloomytoons) and opened up my network inspector:

15 requests 18.65 MB / 3.55 MB transferred Finish: 2.22 s DOMContentLoaded: 529 ms load: 2.23 s

All of that just to render a simple"micro site" that displays a little text and 6 links.

You make a good point and I do agree. Also at any bigger company, no one person's experience is completely representative. It depends on the person, manager, team, org, etc. There's no way any one person could know everything about a company.

But my comment wasn't really about cultural or org issues (which can be much more subjective); it was more about specific facts that are binary. I'll read people say something like "x company is rewriting everything in Go because Rails is slow" when it's not true at all.

Over the past year I've slowly started to realize this as well. What changed? Working for a company that is publicly known enough for people on HN (and Reddit) to comment about it. It has been hilarious and scary to read comments from people who don't work at the company say completely inaccurate things like they are facts.

In this case, it's easy for me to recognize they are wrong. But what about other topics (or companies) I don't know much about? I have no easy way of recognizing inaccuracies so I default to mostly accepting them. Sadly, you need to be skeptical of almost everything you read even when the person sounds like they know the subject matter.

No, it's still Ruby but built directly on top of Rack.

Doesn't it come from Bitkeeper?

See https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/H... for master/slave terminology.

I was using the "Remote Sticky" bookmarklet in Chrome for 1-2 years now but when I moved to Firefox I switched to an add-on which does it: https://addons.mozilla.org/en-CA/firefox/addon/kill-sticky/

The benefit of using the add-on in Firefox is it a keyboard shortcut (that you can customize). So now instead of having to find+click a bookmarklet, I just hit cmd+shift+k on most sites I visit.

I figured I'd activate it again and test it first... and of course it's way better now! Consistently getting around 40ms now so I'll keep it enabled and try again :)

I really wanted to like and use NextDNS but my latency was ~200ms vs maybe 10-40ms for my ISP resolver. I'm fine with paying a bit of a latency price for the extra features and privacy, but not that much. And I'm located in Toronto, not somewhere remote.