Follow by Email

Monday, January 25, 2010

Aaron Sorkin didn't prepare us for this.

A friend of mine likes to say: "Democrats eat their young." She most recently repeated it while bemoaning the inability of a filibuster-proof majority to improve health care in America. There's no question: they beat themselves.

The last time the Democrats suffered a depressing defeat was in Bush v. Gore (2000). Fortunately back then we had The West Wing (1999-2006), the television drama about life inside the White House. Not only did it win many notable awards, not only did it give Democrats a president they could pine for in Josiah Bartlett, it taught us valuable lessons about national politics. Could the show help me understand today's political climate? I pulled three episodes with relevant story lines to compare with real life.

Episode One: On The Day Before (3x04)

The show starts with a presidential veto. The Republicans might have enough votes to override the veto, and it's up to Toby and Sam to get enough congressmen to vote against the override. One Democratic holdout, Congressman Kimble, realizes he's got the White House by the balls and asks for an inordinate number of special allowances in return for his vote. It looks like they'll have to give in to Kimble until they realize that by offering those same allowances to a moderate Republican, they can earn the vote while simultaneously teaching Rep. Kimble a lesson: play ball or play alone.

Back in real life, could you imagine the Democrats getting one single Republican Senator to support their health care bill? No way. Not even by snubbing Nebraska Senator Ben Nelson, who wrangled a deal that gave Nebraska a completely free ride on Medicaid costs. Nelson was the lone Democratic holdout, the last one to agree to vote for the bill. As we'll soon discuss, this protracted holdout was one of the key events that prevented a bicameral health care bill to reach Obama's desk before Congress lost its filibuster-proof majority.

West Wing Lesson: If you ask for too much, the Democrats will just find someone who wants a little less.

Real Life Lesson: If you ask for too much, you'll screw everybody.

Episode Two: The Stackhouse Filibuster (2x17)

The Senate is preparing to pass The Family Wellness Bill. (For crying out loud, a Wellness bill!) Senator Stackhouse starts a filibuster. This surprises and baffles the White House. Late in to the night Donna Moss discovers that Stackhouse's grandson has autism, and everyone realizes that all Stackhouse wants is more money for autism research. Stackhouse would rather die on the podium than see the bill pass without consideration of his special interest. President Bartlett, a grandfather himself, empathizes with Stackhouse and alerts other Grandpa Senators to Stackhouse's intentions. Stackhouse wins, as does everyone else in the United States.

In theory, great filibuster responsibility comes with great filibuster power. In reality, that doesn't mean a thing. The failure to pass a moderately substantial health care bill without a filibuster-proof majority is evidence of this. I've come the conclusion that it's impossible to get anything substantial done in Congress unless you either implement a massive deception campaign, or have a supermajority (Even then, a supermajority is no guarantee. It probably doesn't hurt to throw in a little deception campaign.) I liken it to the California legislature which needs a supermajority to override any destructive California Propositions. (The California Proposition system is a legislative tool that enhances the task of balancing state law by wrapping it in a pan of Jiffy Pop popcorn.)

West Wing Lesson: The filibuster is a powerful tool to be used sparingly in times of critical need.

Real Lesson: Majority rules, but supermajority super-rules. Unless it's a supermajority of yammering idiots. Oh, and also, Congress is staffed on all sides by thugs who will lead us to self-implosion.

Episode Three: Shutdown (5x08)

In the prior episode, Separation of Powers (5x07), Congress fails to negotiate a budget, the government runs out of money, and is shut down as a result. In this episode, the White House and Congress wait a couple of days for each other to cave. The President blinks first -- he's willing to reduce the federal budget by two percent to get restart the government. As a dramatic gesture, Bartlett walks to Congress to re-open budget negotiations. Wikipedia continues the story:
By marching to the Capitol, the President humbles himself and thus re-gains public support by symbolically proving that he is the one who is willing to make the effort to overcome the impasse. Speaker Haffley's counter-measure -- snubbing the President by refusing to meet with him right away -- backfires when the President eventually leaves, indicating to the public that after the President had taken the first step to resolving the shutdown crisis, it was Congress who had chosen politics over negotiation.
Who in real life recently managed to squander their precious advantage? You see my point. Even though real-world Congress passed bills passed from both houses, the reconciliation of both bills was never going to be possible because, among other things, the poisonous amendment  giving Nebraskans
free Medicaid. I can't blame the failed health care legislation on Nebraska Senator Nelson. I can't even blame Senator-elect Scott Brown or the Bay Staters for the soon-to-be-failed healthcare effort. The legislation was doomed to fail. I blame the Democratic party. Their members can't point in anything that remotely resembles a similar direction.

West Wing Lesson: Greedy people are experts at wasting time and imploding. Windows of opportunity are short, don't miss them.

Real Life Lesson: Um, the same thing.

I learned lots of other useful things from The West Wing. For instance, if you piss off your girlfriend, make it up with a mix of flowers, books, videos and popcorn. You can make it rain by smoking in church. I also learned that Democrats can be a force for good when they band together and ... no ... wait. They never made that episode.

(Update: 1/25 10:00AM, general content clean-up)




Monday, January 18, 2010

Welcome, Maplewood Patch readers

Big thanks to Mary Mann for pointing people from Maplewood Patch to my blog. Rather than subscribe to this blog, I recommend anyone interested in the jitney subscribe to myjitney.blogspot.com, a sibling to the jitney app. I'll put most updates there from now on.

My talk at EclipseCon

This EclipseCon will be my fourth, but it will be the first year I give a talk: Eclipse in the Enterprise, Lessons from Google, with my colleague and friend, Terry Parker. This will be a fairly similar talk to the one we gave at Eclipse Day at the Googleplex, only condensed and brought up to date (we make new mistakes learn things all the time!)

Terry and I are very excited to give this talk at EclipseCon, and if there are any areas you would like us to try to focus on, don't hesitate to let me know.

Tuesday, January 05, 2010

Township Jitney Schedule

(A technical writeup of this app can be found on the previous post.)

Hello Maplewoodians!

I've published a web application that visualizes Maplewood Township's Jitney schedule on Google Maps: http://myjitney.appspot.com. It shows:

  • each route
  • the paths each shuttle bus takes
  • the schedule for a selected stop
  • the arrival time of the next shuttle at a selected stop


I'm already working on a new feature: the ability to specify your home address as an additional marker, making it easier to identify your nearest jitney stop.

If you have any feedback, or want to know when new features are completed, contact me at konigsberg at gmail dot com.

(Has anyone in the Maplewood township considered publishing the Jitney schedule using GTFS?)

Township Jitney Schedule: Software Development History

This past weekend I wrote an app for my local town: it displays a route, and schedule information, for the town's jitney. (In local terms, a jitney is a township-sponsored shuttle service for resident commuters to and from the train station.) You can see it at http://myjitney.appspot.com.

I'd like to discuss the short development history of this web application.

The Original Plan


The original plan was to write a public, custom Google Map to be shared with the other residents using My Maps, a tool that allows users to create customized maps.

The problem with My Maps is that each marker had be placed individually, and that's tedious: at least to me. What I needed was a programmatic way to feed a set of addresses, determine each address' coordinates (you know, latitude, longitude) and place markers in a custom map.

For that I wanted the Google Maps API in Javascript, and if I had to use the Javascript API for determining coordinates, I might as well use it to build the map from scratch.

The Prototype

The prototype was written in pure Javascript, using the Google Maps API. It was really basic; routes were stored in JSON (natch), and the whole app lived inside a Google Maps widget.

To get started with the API I found an excellent Google Maps API Tutorial written by Mike Williams. The relevant entries were the entries on Markers and info windows,  Polylines from XML and Geocoding Multiple Addresses.

In fact, I hacked a version of the geocoding example by adding all the jitney stop addresses, and from that I got the coordinates of most of the map markers. For those addresses that the API couldn't parse, I used a tedious trial and error process.

The prototype took five hours to write: one hour to parse and codify the data, one hour for figuring out how to get reasonable coordinates for each address, and three hours to get my head around Javascript. For me, writing Javascript is like this: trial, error, trial, error, google, trial, trial, error, trial, error, google, but by the end, I got a map that showed all the jitney stops and their paths.

Two issues with writing the app in Javascript were my basic lack of comfort with Javascript, and also, the app didn't render on my Android phone. I dreaded debugging a web app on an Android phone.

The Rewrite


So I needed to rewrite the app, and by need, I mean want. 24 hours earlier I could have just manually built a damn custom map with My Maps, but now I was committed to code and more code. For the rewrite, I chose GWT. The Google Web Toolkit is a terrific piece of technology; you can write web applications using Java in Eclipse, my preferred IDE, and with a debugger. Since Google provides a GWT implementation of the Google Maps API, it was reasonable to port the existing prototype to GWT. The Google Plugin for Eclipse, a fabulous tool that combined GWT, AppEngine, and Eclipse, made it dead simple to deploy the app to to appspot.com which meant a permanent home to the app, along with a back-end infrastructure in case there was ever a need for servlets or a back-end data store.

(This is a great time to point out that I think that GWT is magic, and the GWT team are a bunch of magicians.)

It took four hours to write a feature-equivalent version of the application using GWT. Most of that time was spent familiarizing myself with the various APIs and getting reacquainted with GWT.


I didn't want to go through the effort of learning how to work with the AppEngine database, so the rewrite still shipped the route data as java source turned into javascript. One of the great benefits of this turned out to be that the map loaded super-quick. So I moved the CSS to the HTML <style> tag, removing yet another server request.

Thanks to GWT the app ran perfectly fine on Android. But more important, thanks to GWT I could write code in a more familiar style, and easily manipulate the DOM outside the web page's map object.

So I did.

Spit and Polish


I spent two more days adding features and polish: a pretty display of the schedule. A list of the routes so each could be viewed independent of the others. A visual indicator of when a jitney will next stop at a certain route.

One of the features was to replace the straight lines from stop to stop with paths along the street. The township had a map that laid out the supposed bus paths, so the trick was finding the coordinates where the paths turn. That turned out to be surprisingly easy with this small piece of Java:

map.addMapClickHandler(new MapClickHandler()
  @Override
  public void onClick(MapClickEvent event) {
    System.out.println(event.getLatLng());
  }
});


Then it was just a matter of running the web application and clicking each spot along the path, feeding the console output back to the web application as intermediate points.






Before

After

Besides adding features, I spent a ton of time dealing with things like positioning and formatting. I spent 30 minutes building a general purpose route building API. I spent 15 minutes on a general purpose algorithm for calculating the center of a group of points. 30 minutes went into making a widget that looks like, but isn't quite, an anchor tag. I spent endless time playing with different types of GWT panels, setting widths, heights and spans. I played with CSS. I failed at CSS, and then I played with it some more. It seems I have the same development cycle for CSS that I do with Javascript: trial, error, trial, error, google.

Done.

By Sunday night the app was done, and so was I. But it's still not done. Even with such a small one-off project, there so many features that could be added. For instance, while the app runs on Android (and reportedly the iPhone) it's not really built for small phones. The individual links are too small to be useful.

But also, I'd like to use Street View to show each stop. Unfortunately, while a Street View API exists in the Javascript API, there's no equivalent in the GWT API. I probably spent about two hours before I recognized that it would involve another painful, endless cycle of trial, error, trial, error, google. Too bad.

Done?

Damn. While writing this post, someone provided feedback, requesting a feature that made too much sense not to implement. So instead of cleaning up this post I'm reading about geocoding again. I love writing software.

Sunday, January 03, 2010

The New Year's Jackpot

This is a true story about New Year's Eve.

My niece and her new husband are visiting from California. They wanted to spend NYE in New York City, to see the ball drop on Times Square and what not. Of course, we didn't stop them, but warned them that it's not all it's cracked up to be -- mostly a mass of bodies freezing in place. That evening they head to the action, but the streets are already blocked off, from 50th street all the way to 42nd. There's no way to get in.


My niece sees a restaurant just on the other side of the barricade, and gets an idea. She found the phone number for the restaurant, called it, and asked if they could seat two more people.


"We can try to squeeze you in," they said.


With restaurant reservation in hand, and an escort by someone from the restaurant, they were able to pass through metal detectors, and brought in to the restaurant. The meal, I'm told, was amazing.
After dinner the manager stopped at their table to make polite conversation. He asked if they were from the area.


"Oh, no. We're visiting from California."


The manager asked why they were visiting. And here is where my niece shows how brilliant she is. She says "We just got married, and this is sort of our second honeymoon."


The manager says "It is? Oh, I'm gonna set you up."


The manager, who is, or knew, a retired police officer, had my niece and her husband escorted by four officers through more metal detectors and were dropped off right underneath the ball. This was about as close as you could get, closer than all the regular people who were behind a barricaide, whom, I'm told, were distinctly unhappy with this.


That's what hitting the jackpot looks like. I wish that you, too, hit the jackpot this year.