I’m flying home to San Diego today. Trying to check in to my American Airlines flight, they’re telling me I can’t carry on my bag, and offering to charge me to check it.
But their web site says:
… sooo which is it? I guess I’ll check in at the counter and see. Hopefully the lines aren’t bad. 🤞
So, working on FeoBlog, I wanted to print some data into a table in a terminal, and I was picky about how I wanted to do so, so I wrote my own.
In particular, I wanted to be able to:
The existing ones I found on crates.io required holding the table in memory.
So I just wrote my own:
Whew. Have been working on some nice FeoBlog changes that I'll probably release this weekend.
I should probably make another video. The UI is looking much better now than the one I showed in v0.1. Plus, I've learned a couple things about video capture since then.
But for now, shower and bed. 😴
Now available here! https://email@example.com
It adds support for syncing a single user's tweets to FeoBlog, as well as copying tweet attachments into FeoBlog.
Developing in Deno is still pretty fun. Though I did spend a couple days scratching my head due to this bug.
Apparently HTTP clients don't do well when you close the HTTP connection when they're still sending bytes at you, even if you've already sent a response.
The HTTP 1.1 spec isn't super clear on what should happen in this case. For example, it says this about closing connections, but seems to imply it's only for idle connections:
A client, server, or proxy MAY close the transport connection at any time. For example, a client might have started to send a new request at the same time that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed while it was idle, but from the client's point of view, a request is in progress.
This means that clients, servers, and proxies MUST be able to recover from asynchronous close events.
And it says this about "Client Behavior if Server Prematurely Closes Connection":
If at any point an error status is received, the client
SHOULD NOT continue and
SHOULD close the connection if it has not completed sending the request message.
... but that's only in the case of an "error" status, not an OK status.
Chrome handled this case by ... pausing for about 5 seconds, then continuing without error. (!?) And Deno handled this case by ... well, in the case I reproduced in that bug report, the next call to
fetch() would fail, but during debugging I saw other sorts of odd failures. Like calling
.read() on a
Deno.Reader that seemed completely unrelated to the HTTP connection would fail and say the
rid (Deno "resource ID") was invalid. Yeah, that one had me confused for a while. I wasn't able to reproduce that one in a minimal example, though.
I was able to work around the issue by just waiting for all the bytes to be sent before sending an HTTP response. But this seems like a thing that people could use to DoS your server. If you try to be nice and read all these unnecessary bytes they sent to you they can just do it forever. Though I guess there are countless other ways to DoS an HTTP server in addition to this, so what's one more?
And while there are some reasons why it can't interoperate directly with ActivityPub, it's always possible to sync data back and forth.
Some design decisions I'm interested to hear feedback on:
Since FeoBlog is all public, I decided to only sync "public" and "unlisted" posts from Mastodon, so as not to expose any private posts from users I follow. (i.e.: not "private" or "direct" posts.)
So as not to unnecessarily use bandwidth of (often for-free) Mastodon servers, I decided to not inline images. Though, I could see myself coming back and deciding to add them as FeoBlog attachments, which would allow for inlining them without touching Mastodon servers. (Beyond the first download.) For now, I just link to the attachments so you can click in and view them as you wish.
Let me know what you think!
I'm also still really enjoying writing stuff with Deno. Not having to deal with
npm, etc, just removes a lot of friction. Plus, it's super easy to write, run, and share a standalone script that imports dependencies from online. (Though, I haven't really used the new module stuff in Node, so maybe you can do that there too these days?)
Had fun writing code for Deno! :D
Just published my first #Deno package. It's pretty cool!
One unexpectedly nice thing -- if there are errors in code hosted on https://deno.land, the error message contains URLs that take you directly to the line(s) of code in a web page. ❤
It's a pretty fun and easy way to write and distribute some TypeScript!
I want to write more, but I was "done in 20 minutes" a couple hours ago, and I need to clean the apartment. We're heading out of town tomorrow to see some friends for the 4th of July. So I don't get to play with code again until we're back on Monday afternoon. 😢😛
I assume that's in response to this line in the blog post:
- No more societal and political discussions on our company Basecamp account.
This is such a tone-deaf "got my privilege blinders on" rule.
What counts as "political" discussion?
I've worked with people who I'm sure would claim it's "political" that I casually mention my husband in work chat, since they're "politically" (and likely religiously) against same-sex marriage.
Is openly mourning the death of yet another black person killed by a cop "political" because "black lives matter" is somehow a sentiment that needs to be "both sides"-'d politically?
What about saying that you're for equal pay for women, and compensation transparency?
I'm not saying work chat should have a
#politics channel or invite irrelevant quarrels, but when you're in chat with folks 8+ hours a day (especially when you're remote), "real life" stuff creeps into chat. It's impossible to separate politics and real life in general, but it's doubly impossible when your existence and lived experience is politicized.
I suspect what counts as "political" will just be whatever makes trouble for The Company, or makes the leaders uncomfortable. They don't want to take a side because that's hard, so they'd rather just pretend the problem doesn't exist. And who will bear the brunt of that rule? People who speak up about issues.
And that leads me to the thing that always makes me confused at this kind of thinking, something that feels like cognitive dissonance when I come across it at a company: You can't be for "diversity and inclusion" and against talking about "political issues". Your workplace is not inclusive if some of your coworkers need to censor themselves, and others get to be "the default". And your workplace will not be as diverse once those employees find other, better places to work.
But, maybe Basecamp isn't for diversity and inclusion? Seems like their "Diversity, Equity, and Inclusion" working group is getting axed:
- No more committees. For nearly all of our 21 year existence, we were proudly committee-free. [...] But recently, a few sprung up. No longer. We're turning things back over to the person (or people) who were distinctly hired to make those decisions. The responsibility for DEI work returns to Andrea, our head of People Ops.
I'd love to hear from members of that working group how they feel about these changes.
My ideal workplace would be one that actually sticks to and implements its stated values. If you value DEI, then it seems like the issue isn't "political" discussion, it's sexist, racist, homophobic, transphobic, etc., statements. And, hey, some of those are already illegal in the workplace so you're probably already enforcing bans on that kind of speech. If you've got people in your company who are angry because they don't get to be the "other side" of those "political" issues, I'd suggest you've found the "divisive" problem in your company culture.
We ended up buying the e-bikes that I was thinking about. They've been great! Definitely happy to have a motor to help me up some of the steep hills in this neighborhood. Even with the electric motor at full, and on the lowest gear, some of them are quite tough, so I definitely wouldn't be managing this on a non-electric bike.
After a few trips out, my husband found a nice circular route for us to ride which has been our de facto route recently. It starts with a climb up a into some hilly neighborhoods, and just when I'm getting exhausted it ends with a nice downhill coast most of the way back home.
We got a little bit of rain last month so the hillsides are looking nice and green. Here's one of my favorite views from that route:
A few months ago, I was perusing the YouTubes, as one does while social distancing during a pandemic, and it served up a video review of an e-bike. It's been a while since I owned a bicycle, so the tech was new to me, and I watched enough videos that now YouTube thinks I'm an e-bike fanatic or something.
So after months of watching videos I thought, hey, I should try riding one of those things. So, today Heiðar and I went out to test ride a few.
At the first stop, I tried out a Trek Verve+ 2, and (I think) the Trek Verve+ 3. They were both quite nice! They've got a "mid-drive" electric motor, situated down between the pedals, that assists you as you pedal. Even if you turn it off completely, the bike rode quite nicely despite the extra weight.
At the second stop, we tried out a brand whose name I'll avoid mentioning. When their sales guy heard we'd tried a Trek earlier that day, he spent a lot of time telling us how bad it was. He claimed mid-drive motors are worse because they're harder to pedal when the assist is off. (I did not find this to be the case, and in fact, the bikes he was selling with hub drives in the wheels seemed harder to pedal with no assist.)
Still, he was nice and we each tested a few different models. I'm both out of practice and out of shape so we called it quits for the day, but I'm looking forward to trying some more later this week.
I'm trying to decide if the expense will be worth it. I'd like some activity to get me out of the house, and biking sounds fun. We're thinking e-bikes because the neighborhood we live in (and San Diego in general) is pretty hilly, so having something to help get up the steeper hills would be nice. But there's always the chance that after biking for a while the novelty will wear off and we'll have bought ourselves a couple expensive, electrified dust collectors.
FeoBlog v0.3.0 is out and it supports file attachments. Everyone knows The Internet is for pictures of your cat, so here we go.