busybee fluffy rambles Notes

I removed Feedly from my Get Blogging resource for people who want to read and write blogs.

If you’d like to read blogs, there are some great other feed readers recommended in the list. I start every morning with Reeder and NewsBlur.

Molly White has written a great summary of why I can’t endorse Feedly anymore:

In a world of widespread, suspicionless surveillance of protests by law enforcement and other government entities, and of massive corporate union-busting and suppression of worker organizing, Feedly decided they should build a tool for the corporations, cops, and unionbusters.

I cannot support union-busting in any form, and it’s very disappointing to see a tool like Feedly attempt to capitalize on corporations who would like to engage in this activity. So it’s gone from the list, and I’d like to suggest: while they offer this product and cater to this market, please don’t use Feedly.

Personally I’m still a fan of self-hosting Feed on Feeds, which is pretty straightforward to do if you have even basic PHP webhosting. It isn’t the fanciest thing but it’s reliable and won’t sell your data to others, and it’s got the exact UX I want in a reader app (YMMV of course).

Jewish applicants are frequently passed over by hiring managers. In fact, 26% of hiring managers say they are less likely to move forward with Jewish applicants.

[…]

When asked how they come to believe that an applicant is Jewish, 56% say it’s because it was directly stated by the applicant. However, many also make assumptions based on the applicant’s educational background (35%), last name (33%), past or current experiences with Jewish organizations (28%), and even their appearance (26%).

[…]

When asked why they are less likely to move forward with Jewish applicants, the top reasons include Jews have too much power and control (38%), claim to be the ‘chosen people’ (38%), and have too much wealth (35%).

Why use ActivityPub when RSS still exists, and when IndieWeb adds social functionality to traditional, non-ActivityPub blogging?

Even at its best, ActivityPub is a very difficult standard to implement, with a lot of really hairy edge conditions and an at-best-mediocre experience for things that don’t fit neatly into its model, and Mastodon’s particular implementation of ActivityPub isn’t, y'know, great. (And I’ve written a bunch more about my thoughts on this as well.)

Basically I’d love to see more people support IndieWeb, using RSS/Atom and ideally also h-feed as the syndication formats, and to that end, I’d say that micro.blog is a better choice of “new Google Reader.”

asyncio generally requires that you provide a “session”/“client” object that contains the run loop for the async operations. I think that when you refactor a library to support asyncio, you provide a non-async wrapper around it which spins up the execution loop for each operation, although there might be a better pattern for it these days.

An antipattern I’ve seen a lot is people wrapping a non-async library in a threadpool and then have the async wrapper block on the future, but that completely misses the point to asyncio and makes everything perform way worse.

asyncio is kind of wonky to wrap your head around at first but it’s well worth it for the major performance gains you get. It can be a huge pill to swallow though, and given that most Python web apps are still running in a thread-per-connection context (because wsgi is designed around it) it can feel like a chicken-egg scenario at times. But doing the work of moving to asyncio (and providing a non-async wrapper around it) makes it easier for more things to move to asyncio and getting the performance benefits as a result, so it’s a net good IMO, even if it isn’t heavily used right away.