HackerTrans
TopNewTrendsCommentsPastAskShowJobs

bretthopper

no profile record

Submissions

Accept: Text/Markdown

acceptmarkdown.com
4 points·by bretthopper·3 maanden geleden·0 comments

Quien – A better WHOIS lookup tool

github.com
100 points·by bretthopper·3 maanden geleden·45 comments

There's a Reason Bar Ice Looks Better Than Yours (and You Can Fix It)

seriouseats.com
28 points·by bretthopper·12 maanden geleden·4 comments

Don't Tolerate Unsolicited Spam

benword.com
2 points·by bretthopper·vorig jaar·0 comments

Kenton's House

kentonshouse.com
2 points·by bretthopper·3 jaar geleden·2 comments

Adventures in Garbage Collection: Improving GC Performance in Our Monolith

shopify.engineering
12 points·by bretthopper·3 jaar geleden·0 comments

The Mysterious Case of the Fucking Good Pizza (2021)

vice.com
3 points·by bretthopper·4 jaar geleden·0 comments

Neural network from scratch

sirupsen.com
208 points·by bretthopper·5 jaar geleden·38 comments

comments

bretthopper
·7 maanden geleden·discuss
https://brandur.org/
bretthopper
·3 jaar geleden·discuss
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?
bretthopper
·4 jaar geleden·discuss
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.
bretthopper
·4 jaar geleden·discuss
This is an editorialized title. Bloomberg's is "Shopify Tells Employees to Just Say No to Meetings"
bretthopper
·4 jaar geleden·discuss
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.
bretthopper
·4 jaar geleden·discuss
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.
bretthopper
·4 jaar geleden·discuss
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.
bretthopper
·4 jaar geleden·discuss
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.
bretthopper
·4 jaar geleden·discuss
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.