If you stood on the commuter rail platform at Porter Square and looked towards Boston, there has always been a pair of signals, one for each track. They were replaced around 2015 as part of the general Fitchburg Line upgrade project, at the same time the line was double-tracked through Acton and Littleton: they moved east behind the car wash, and with a block signal near Union Square removed, became a distant signal for Swift Interlocking at the McGrath Highway overpass.

Those signals got removed this week as part of the T's Positive Train Control project.

There's very established technology to tell a train what the next signal will be by sending signals through the rails, and displaying the corresponding signal in the operator's cab.  Of note, Amtrak's Northeast Corridor uses a variation on this system that displays both a signal and a speed limit, and so MBTA trains that operate on the Providence Line are already equipped with the ACSES hardware.  In the wake of the 2008 Metrolink crash, Congress mandated that all passenger trains be equipped with a positive train control system that can stop a train before it passes a red signal, and in turn this has caused the T to install cab signaling everywhere on the commuter rail system.

If the train already has a display in the cab telling it what the next signal should be and how fast it should go, you don't also need signals next to the track displaying the same thing.  So the wayside automatic signals are also disappearing across the MBTA commuter rail network.  The Old Colony lines never had them; if you drive on the Pike next to the Worcester Line, you'll also notice the signals there have been removed.

Still, I have a fondness for seeing these signals as I go past.  This is one of a couple of locations where I said "...so what does yellow-over-green mean?" and actually looked it up.  As my...well, "home signal" is a technical term, but you get the idea...I'll miss seeing them.

Yesterday rode the Minuteman as far as Lexington; today explored the various Boscamberville roadway improvements.

In Boston proper, the cycle track around the North End is actually pretty awesome. But navigating through downtown Boston, especially the Scollay Square/Post Office Square area, is horrific. (I at least think I know how I'd get to work.) The bridge into Charlestown would be worth avoiding if there were any other way to go that direction.

The cycle track along Beacon Street in Somerville is somehow less impressive; maybe because the driveway crossings aren't as smooth and it's not totally clear what to do when it stops and starts and stops again.

"Sharrows" feel better than I give them credit for. They tend to communicate "sorry there's not bike lane for this block" to me, a little more than "you can take up this space in the lane which you legally could have done anyways".

The other end of the Erlang experiment is the libraries I was working with. My application was built on the Sumo Rest stack, built on top of the Erlang Cowboy HTTP server.

I found this finicky and prone to vague runtime errors. That's not important, though. The overall style of the system was pretty reasonable, and is probably a good way to write REST services in general.

( Read more... )

The layout implications of this are useful and generic: one source file per type, where each type file defines its storage, serialization, and documentation; and one source file per route, where each route file has its own URL path, complete machine-processable documentation and metadata, and understands the standard failure cases. You just need the right high-level REST library in your language of choice to support this.

The same username I have in the rest of the world, except for here, and my gmail, and my Flickr.

I've managed to find the half-dozen people who have said they're relocating in the current exodus, but not the people who thought the air was starting to smell funny when the new overlords turned out to be Russian years ago.

DW will probably get about as much use as LJ has been, which is to say, very occasional long-form blogging for a social audience that's not really suited to one of the newer trendier social networks.  But I'm there.

The past decade in Boston transit has seen a massive increase in the number of CCTV cameras deployed around the MBTA system.  Several are seen in most rapid transit stations, newer buses have several apiece (and a video monitor showing you what's being recorded), and the monitoring stations are consciously placed in places like the South Station subway concourse where the general public can see them.  "Sure, Big Brother is watching you," the T says, "but it's for your own safety."

This rubs me the wrong way.

Meanwhile, across the pond, I also read the reports of the British Rail Accident Investigation Branch.  These are fascinating from an engineering point of view because they try to explain and analyse, in plain English, what actually happened and could be improved: maybe a lorry backed into a bridge pushing the 150-year-old brickwork on to the tracks, which a train hit 10 minutes later, but why didn't 999 contact the signaler to have them stop the train, and why was the damaged train allowed to continue at 100 mph after the accident cleanup?

The RAIB reports are also good for including pictures of relevant parts of an incident: here's a picture of the pin assembly on an intermodal flat car, here's what it would look like if it was hanging off the edge of the train, here's the picture of the train platform said pin assembly hit at 60 mph.  Depending on the incident, many of the pictures come from CCTV imagery, including pictures from remotely manually controlled level crossings and station platforms.

This use of CCTV imagery I'm very okay with; but it does actually depend on having cameras in a lot of places so that you can collect together a photographic history of the train.  "We're watching our infrastructure and our trains to make an already safe system safer" seems like a positive message; much better than "we're watching you".

(0) They removed the signal behind the Market Basket, and changed the area between Sherman St. and Alewife Brook Parkway to no longer be a signaled junction, which affects what the signal at Porter can show.

(1) Old signals showed red, unless the track was running in this direction.  New signals show a normal block signal aspect unless the track is running in the opposite direction.  (Or else, new control system makes it harder to set default "trains run on the right" routes and forget about it; but I'm pretty sure I've seen the old signals show red in both directions before.)

(2) The new signals take quite a while to reset to red when a train passes, like 10 seconds or so.  (It is possible that the train needs to completely pass the signal, but I don't think it actually works that way from watching two trains go by, and it would be odd for a new installation at this location anyways.)

This in combination means that the new default is yellow-over-red (approach) on both tracks; red-over-red (stop), probably on the left-hand track, means a train is coming from North Station; yellow-over-green (approach medium), probably on the right-hand track, means a train is going to North Station; and green-over-red (or -over-green, clear), for wonderfully geeky reasons, means a train has a route set all the way into a platform at North Station.  The outbound signals only show red/yellow/green; I have not yet observed whether these (or other new installations, like on the Lowell line) show flashing-yellow (advance approach) (rumor from the Internet is that they don't).

Go is the new trendy programming language. In style it's kind of a backwards C, with an interesting amount of object-oriented features baked in. You can definitely get things done in Go, especially if you're not trying to interface to legacy systems.

As a modern language, though, the things it's missing seem odd. C++ has had parameterized template types as long as I've known it, and Java added them in eventually, but not Go, it's complicated. This means that basic functional-language primitives that are addictingly useful are essentially impossible to write. ( Remember 6.001? )

Most things in Go work by returning pairs of an actual result and a flag or error object. This does lead to making it more obvious to try to do some error handling, and it is "better" than both exception-based languages (where it's easy to ignore errors until they crash your program) or C's magic return value (where an int is an int, unless it's -1). But it also leads to more boilerplate. ( In which we briefly introduce monads )

There's one other oddity I've run into: ( When is nil not nil? )

Even so, the things that people find attractive about Go are still attractive. It's a compiled language, that isn't 30+ years old or owned by Oracle, that compiles reasonably obviously but can't obviously crash from pointer arithmetic errors. It's garbage-collected, which you may object to, but it beats the pants off of explicit memory management. The language includes maps and queues as base types, and if you secretly did like C memory management, you can relive the past with concrete arrays underneath slice views. I admit to having done almost nothing with goroutines, but the promise of the runtime having a select loop and thread management and synchronized channels in the core is much better than anything I've used that doesn't involve a big C library.

Last month's Asia trip included a couple of museums: the Shanghai railway museum, the Mint Museum of Toys in Singapore, and the Singapore World War II museum Reflections at Bukit Chandu.  This leaves me with a much better sense of what I appreciate in museums: they should be able to tell me some consistent story that I can appreciate and put in context.

( Read more... )

Google News decided I needed to read this diatribe pushing Republican tax policies.  They all seem like terrible social policy to me.  I'd think the basic rules should be:

• Taxes cover the cost of running government


• People who can afford to pay more should


• The tax code should be comprehensible by mere mortals

( Read more... )

The ACBL's latest Web page redesign includes a page that gives your rank (inverse matchpoints) and percentile in a wide range of masterpoint categories, for instance where you are relative to all players that got any gold points this year. If you just copy-and-paste that page into a spreadsheet and do some basic math, you can find out the size of each category, which makes some interesting statements.

( probably not interesting except to active bridge players )