Paul Ganssle @pganssle@qoto.org

@freemo Haha, yeah everyone always comments on the reflective insulation. It's making me hesitate about putting accoustic damping panels on the wall behind my desk...

The workbench has taken its rightful place as a work station for electronics and such (though some of the components migrate to the main desk if I need to program a microcontroller...)

This is likely the last picture of a tidy workbench I'll get for a while.

"Bigger" here means 27" or 32". I probably would have upgraded long ago, but I find it hard to tell whether my day-to-day experience (using Linux and not playing games) would be significantly degraded by getting some of the drastically cheaper models available.

Some steps in the evolution of my workstation:

1. Workbench as desk
2-3. Switched to standing desk
4. Added monitor arms

Next steps: Get at least one bigger monitor, setup up my cable management game.

@freemo Yes, very much so! My first keynote.

I'm still a little sad that I can't do it in person, but logistically it's challenging to get there and back anyway (particularly with a family in tow), so it's probably for the best that it's virtual.

Exciting announcement: I'll be giving a keynote talk at PyConf Hyderabad, which will place December 5-6th, 2020 (virtually, this year):

https://twitter.com/pyconfhyd/status/1321728958052794368?s=20

Tickets are available here: https://pyconf.hydpy.org/2020/

CfP is still open until November 8th: https://twitter.com/pyconfhyd/status/1313690523555819522?s=20

#PyConfHyd2020 #python

@jasper I do think it's the sort of thing that hurts our ability to write optimizing compilers and such without modifying semantics. It's hard to do constant folding and such when the "constant" is actually an attribute on a mutable object (and may even be dynamically returned, see PEP 562: https://www.python.org/dev/peps/pep-0562/)

@jasper Some classes and objects can be made immutable (or, at least, immutable enough), but it's certainly not the default.

At the end of the day, I think the ability to monkey patch modules and classes is a net benefit. Everyone knows that it's a code smell, so it's not done widely, but the fact that you can do it allows you to avoid some other even worse patterns.

I just had a thread about this, actually: https://qoto.org/@pganssle/105107544104982635

@freemo Though I'm fine if it's not, it just means that I'm less likely to be able to take advantage of the features in some scenarios, which is not necessarily a big deal.

@freemo Yeah, presumably individual clients will support different features — that's one of the great benefits of choosing your own client.

The only worry I have is that if each instance implements "remote timeline" a little differently, every client needs to support every implementation. Most projects don't want to support every idiosyncratic thing on every instance, but would be happy to be "fully featured" clients if there's wide adoption of a non-standard feature.

I'm curious to know if you are developing /implementing this stuff in a siloed way, or if it's part of a broader "Mastodon+" type effort that is likely to be worth clients' effort to support.

Of course, there are legitimate reasons for this sort of dependency injection-style parameterization, but adding support for arbitrary interfaces broadens your "supported configuration surface" so much that usually it doesn't pass the YAGNI test — unless you need it for tests.

That's obviously a pithy twitter-sized take, but I think most of the time when you have some highly parameterized class / function, you aren't doing it because you actually want to support an interface where someone supplies their own provider of some core language functionality.

You do it because it makes your testing easier, and you can nominally it allows you to test using only the public interface.

That sort of thing is a necessity in languages without monkey patching, but it seems like it's a considerably worse code smell than patching in tests.

Listening to Anna-Lena Popkes on @TalkPython@twitter.com and I realized something I've never consciously understood: mocking is bad because it is tightly coupled to implementation details, but dependency injection solves this problem by promoting those details to be part of the public API.

In the book "Brooklyn", @builtbrooklyn@twitter.com says early aviator Calbraith Rodgers was "blogging all the way" on a cross-country flight.

I am kinda startled to find that I can't think of a non-anachronistic verb to describe what he was doing: sending regular dispatches for publication.

Citation: https://www.google.com/books/edition/Brooklyn/JHbTDwAAQBAJ?hl=en&gbpv=1&bsq=blogging

@freemo Awesome improvements. Is this stuff standardized enough that it could be supported by mobile apps? Probably >50% of my browsing fediverse is done on Tusky or something similar, so I miss out on some of the custom features of the qoto instance.

@freemo Also I'm in the 11th judicial district of NY. There are around 18 people running for 9 spots.

I wasn't able to find lists of cases for these people last time around, and I'm not especially interested in spending hours on it anyway, considering how unimportant my vote is with the hordes of party-line voters.

I think the fact that no one has bothered putting together voter guides or information about this, and that even candidates with no record seem to not campaign *at all* indicates that these are not properly contested elections and the outcome isn't really in doubt.