When Noisebridge was new, I wrote a program to get the BART arrival times and play them (in a synthesized voice as close as I could find to the BART one, though clearly not the same one) through the loudspeakers at the space during the last half hour or so of BART service every night. Unfortunately, other people found this annoying, so it was disabled very quickly.
In my case my nostalgia is tied to the bubbly incoherent voice that says (in astonishingly clear manner) what train arrives first and then proceeds to say which platform and which track, which is so indistinguishable that you never know where to run to (before we had BARTs in the underground passage we used to check all the platforms, because there might have been a change)
I love how long the terrible speech synthesis on BART lasted. I don't mean this in a negative way at all. BART was so state of the art when it was built, that it still feels like the future today. They did a good job on ... everything.
Fun link. I saw this article and immediately thought "I need to go find the voice" and this is exactly what I was looking for.
Nah, they did a good job on one thing: PR. As public transit? We've been suffering the consequences of their chronic NIH for going on fifty years now.
Fun link. I saw this article and immediately thought "I need to go
find the voice" and this is exactly what I was looking for.
BART's covered the topic of their computerized voices a few times. This was the first I found, but they've covered it more recently with the arrival of their newer trains.
Trains in London in 1992 had announcements using recorded voice clips, so I'm surprised BART chose this synthesized system. Perhaps it sounded more futuristic than plain recordings?
Trains in London in 1992 had announcements using recorded voice clips
BART did too. I think the announcements date back to the early days of BART. The computerized text-to-speech didn't come around until 2000 and only cover train arrivals.
Perhaps it sounded more futuristic than plain recordings?
BART's always gone for style over substance, so yeah that probably played a part in it. There's a small chance that text-to-speech was cheaper than paying a human.
In San Francisco, Muni paid a Texan to record stop announcements for their buses. I've absolutely no idea how this ended up being the case but she absolutely massacred the pronunciation of a few (mostly Spanish) words.
The only rationales I've seen for using imperative ("fix bug") over the indicative ("fixed bug") are that it's what git does by default anyways.
Is it really that big of a deal to use the indicative sometimes and imperative other times?
For what it's worth, I always write commit messages in the imperative, out of habit. When others write commit messages in the indicative tense, part of me notices, but I move on because I can still understand the message if it adheres to the other guidelines.
None of this is really worth obsessing over I think, but one point in favor of imperative is it tends to also be the tersest phrasing, which is convenient if you're also aiming for 50 characters max.
So long as the meaning is clear, it really doesn't matter IMO. Just write it so that when viewed in isolation the meaning of the message is clear and matches the changes held within the commit.
Anyone who gets up in arms over "fixed" vs "fix" needs to get a life.
The imperative mood/future tense ("this commit will...") makes the commit the subject of the message, the past tense makes the developer the subject of the message. In my (limited, personal) experience, the people who insist on past tense commit messages have more trouble killing their darlings, are more likely to take review comments personal, and are more likely to view (part of) the codebase as theirs rather than the team's.
So for me, it's not about the commit message itself, but the communication style says something about the developer and how I best approach them.
My take on this requirement is that it helps developers let go of their attachment to the code they've written.
I use imperative, but for other projects which don't I switch to indicative if that is the style. Personally like imperative more, not sure why, just preference.
> Is it really that big of a deal to use the indicative sometimes and imperative other times?
'big', don't know, but wouldn't be surprised if there's an objectively provable higher cognitive load for having to read a mix of both (or, god forbid, other styles thrown in there as well) vs one consistent style. Just like there is for code etc. And some people are affected by striving for consistency more than others, so for them lack of consisteny might cause some extra friction.
reply