Earlier today, the 600,000th commit was pushed to Wikimedia's Code Review server.

Time to reflect on our community of developers, be they Wikimedia staff, third-party workers, or volunteers!

phabricator.wikimedia.org/pham

A periodic reminder that you should back up your own Masto account by downloading your archive

I'm not posting this for any particular reason other than that it's good to make backups and sometimes servers just go down

New post, in which I explain why I think 'browser ecosystem health' is a considerably better lens to view/discuss than 'browser engine diversity', and paints a different kind of picture

bkardell.com/blog/EcosystemHea

"Correlation is not causation" per se, but...

It does make me wonder even more about the impact of companies' tunnel focus on engagement metrics.

Show thread

Interesting correlation between time spent in apps and user's (self-reported) happiness.

Relatively small scale study. But certainly a perspective I hadn't thought of explicitly before.

humanetech.com/resources/app-r

Huh.. I just realized Apple made both iBook and iBooks. 🤔

I don't recall it causing confusion, which seems.. surprising?

(iBook, device, is now known as MacBook; iBooks, app, is now known as Books.)

Folding@Home 

This is a good lesson in performance. I was researching whether doing blurhash in WASM would be faster than the JS version.

This is 3 iterations against 16 images. If I had only measured the first 4 images, or taken the average, then I may have concluded that WASM is way faster. But in fact the JS version starts out slow but then quickly catches up (probably because it gets JITed). So there's really very little point in using WASM for this. github.com/nolanlawson/pinafor

Mozilla wrote a balanced and nuanced overview of the dot ORG issue.

In short: We're not out of the woods yet.

blog.mozilla.org/blog/2020/05/

"Server-side rendering is not a fallback; client-side rendering is an enhancement."

I would further and say client-side rendering can be (not "is"), a performance optimization for subsequent page loads (and offline). It's only a net-win if you invest non-trivial effort (SW, streams, race network, handle long-lived tabs and cache misses to old JS, etc).

In almost all other cases, it merely produces a slower, less usable, less available version of itself.

by @adactio

adactio.com/journal/9963

@bcallah Perhaps one of the positions for Wikipedia would interest you?

(ask me anything, DM or email)

boards.greenhouse.io/wikimedia

Think twice before disabling `user-select` on (part of) a web page.

tip via Remy Sharp (🐦@rem)

@brion Oh boy, I just realized I've misunderstood this expression for over a decade.

Now that it clicks, it's hard to see why it didn't before, but...

For some reason I always interpreted the "have" part as receiving/being given cake. And the "eat" part to mean not letting it go to waste. Don't be ungrateful. Use the tools you have. Finish what you started. Etc. In that general direction.

It always felt just a little off whenever I heard it, but, never enough to make me question it.

TIL :)

"Measuring the performance of Wikipedia visitors’ devices" by Gilles Dubuc techblog.wikimedia.org/2020/05

This is super fascinating: Wikipedia ran a microbenchmark on 0.1% of visitors, and tracked the performance over time. Looks like devices have been getting faster over the past year (or maybe browser updates improved the benchmark time… it's not clear).

@liw Yeah, I too would like more of them to be inboxy.

RSS is inboxy for me, though. I use Feedly, NetNewsWire, and Podcasts. These have a "show unread" concept.

@brion Ha, I noticed the same today!

For me, post-Catalina upgrade, the muscle memory of `cmd+Shift, "itu", Enter` initially led to the TV app launching instead.... (to my doubly surprise)

A day later, it seems to have learned I prefer "Music" :)

Show more
Mastodon for Tech Folks

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!