Paul Ganssle @pganssle@qoto.org

My goal for Q4 2022 was to get out at least one new blog post or public talk. *Almost* made it.

Attractive nuisances in software design: https://blog.ganssle.io/articles/2023/01/attractive-nuisances.html

A common anti-pattern where a problem has a solution that is obvious, intuitive and wrong.

#python #programming

@cfbolz I wrote a blog post about this from the other side as well: https://blog.ganssle.io/articles/2019/11/string-concat.html

I was mildly surprised that it was quadratic in PyPy because in my smaller benchmarks it was always so fast anyway for realistic cases. 😅

@hynek Oh wait sorry I didn't realize the thing you said about getting invited to local cons based on PyCon performance.

That hasn't really happened for me, and invited talks I know about tend to be Keynotes where the social capital is "this person is a good speaker and will draw attendees" rather than "this talk they gave at PyCon was interesting we should have them do it here too"

@hynek I think maybe reading between the lines, your process is you do not give talks unless you know they are getting into PyCon US, whereas I treat regional Python conferences as a "minor league" where my talks prove themselves out before graduating to the big stage.

@hynek I actually, non-rhetorically, don't understand the problem or the relevance of the amount of time spent on talks.

For me PyCon US is usually the "capstone performance" of my talk, not the debut - and that's not usually my choice, so whether or not PyCon accepts my talk this year has no real bearing on other conferences from this year, since usually a talk gets rejected once or twice from PyCon US before I actually give it. A lot of investment in the talk makes me *less* sensitive to the timing of when I give it, not more.

@hynek I have found that regional python conferences are more likely to accept new talks I've never given before, while PyCon US is happy to accept an encore presentation, so my pipeline usually ends up with say PyGotham 2023's talk being PyCon US 2024's talk.

@hynek I don't understand the issue. Is it that people will prepare a talk only for PyCon and if they get a different talk accepted in a local con then they have to prepare two talks?

We seem to have lost one of the "2" decorations, but thanks to a bit of quick thinking, I don't think anyone will notice.

Anyone have other examples of "Here's a common thing that most people are doing wrong, along the lines of https://blog.ganssle.io/articles/2019/11/utcnow.html and https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html ?

@gpshead Well I'm not that interested in boosting Signal anymore anyway. The main selling point is gone and and non-technical types I have convinced to use Signal now have to deal with two apps plus a migration of their SMS history.

This plus the general vendor lock-in model Signal has going don't make me enthusiastic to spend what limited influence I have over my contacts' technical choices on promoting Signal.

@lucifargundam Yeah. I understand where they are coming from — ironically, I'm complaining about this in between drafts of a blog post about how sometimes you should deliberately choose to *not* implement features that people want if a sufficiently high percentage of people will use those features wrong. That's basically the whole justification for removing SMS, so you'd think I'd be in support of it, except:

1. I think SMS support was actually a core feature of Signal and they should probably lean in to UX design to minimize any potential harm rather than give up on it

2. In the same blog post I suggest that when you have a feature that some people might use correctly but a larger fraction of people might use incorrectly, you should probably still include the feature, but just make it *more difficult*. In this case adding a setting like, "Enable SMS even though it's insecure" would really help.

@gpshead I think the main reason Signal has taken off so much is that it was effortless. It was a better SMS client than the default one *plus* it did opportunistic encryption.

Anecdotally, it seems to me that Signal adoption is lower among iOS users, and I've always attributed that to the fact that they have a basically degraded experience, since they can't set Signal as their SMS app.

@gpshead I don't really understand this. It sounds like you are saying that I should disdain SMS so much that I don't care about my client, but it's not like I can stop using SMS.

I'm almost certainly going to need to start using SMS *more* now, because a good chunk of the people I talk to on Signal are people where I went to send them a text message through Signal and I got a "blue send button". Now I'm just going to go straight for the SMS app, and all those communications will be unencrypted.

OK, I upgraded to the latest Signal and it still works as an SMS client.

Kind of a twist of the knife that they are also prominently pushing "stories" in this update, which.... does not seem like it was any sort of user-requested feature.

@jerub I don't know, I think I used Google Voice before Signal, and I actually really like Signal as an SMS client. I assume Messages is not good because I'm not sure I've ever liked a default app, but maybe it's OK?

@obi What does direct APK mean? If I upgrade today through the play store is that the same thing? I'd be happy to delay this decision a while.

#Signal users on #Android, anyone have a suggestion for a decent replacement SMS client? Looks like I am going to have to upgrade the app soon. 🙁