Sunday, November 9, 2008

Election Day 2008 in Chicago

As I do most days now since Ramona was born, I took Carlotta to school in the morning after voting. Since I had the camera with me, I took a shot of her as we walked from the bus stop to her school (walking past Wrigley Field along the way). I told Carlotta that I wouldn't be home that night, because I was going to see Barack Obama in Grant Park.

"Why are you going to see Barack Obama?", she asked.

"Because it's very important for him to be elected," I told her, and I realized that I had a deeper emotional investment in this election than I realized. It shouldn't have been a surprise, but it was.

I had gotten my ticket to the Obama Rally the night before. Delia said she could handle the kids solo (her first time doing this since Ramona was born).

The city had been putting the fear of God into all of the downtown office building tenants to encourage companies to let employees telecommute on Tuesday. Huge crowds were expected, and the light rail schedules were modified to accomodate more inbound passengers late in the day. Many people at work didn't come in on Tuesday.

My grand plans of getting lots of work done after work but before the rally crumbled as I was watching the news of the returns. So I headed out to get some dinner at a local restaurant. At around 8pm I started walking down to the rally.

As I neared Grant Park, the crowds increased, and hawkers selling Obama t-shirts, rally towels, and buttons were everywhere on the sidewalks.

Once I got to the entrance at Congress, I saw there was a line waiting to get in. After about a mile of walking, I finally reached the end of the line. I was despairing of ever getting in at this point. I couldn't see any way we were getting in before 1am if they were going to have any kind of security.
But the line started moving a little, then the pace picked up. We were walking at a good clip with few stops. Chants of "Obama! Obama!" and "Yes We Can!"rose among the crowd along the way.

The crowd was happy but mellow. Well-behaved, even. In the "Congress Hotel" photo at right, notice the man in the black jacket carrying a folded flag.

Despite the speed with which people were streaming in, there were, in fact, two security checkpoints. The first just checked to make sure you had a ticket (in that you had some piece of paper that looked something like a ticket). The picture at right is looking back just after getting through the first security checkpoint - the security folks are in the yellow jackets.

More walking. A second security checkpoint, where a cursory match of my driver's license to my ticket may have been done. I was never searched.

Some more walking, and then a sea of people. Bright lights everywhere. Jumbotron - apparently the Obama campaign favors CNN, by the way. In the picture at left, you can make out the Chicago skyline rising up above the crowd. Estimates would later put the crowd at a quarter million.

It's hard to capture the crowd adequately with these pictures - but in every direction you looked, it was more people.

Then suddenly, they called (I think) Virginia for Obama. The crowd erupted. In short order after that, McCain came on to concede. The crowd around me grew impatient as he seemed to keep talking and talking. There were a smattering of boos from the crowd when he mentioned Palin.

None of this had really sunk in yet. It was clear Obama would be coming on soon. Stevie Wonder's "Signed Sealed Delivered" was playing and I thought, "Wait, what just happened here?" People were dancing. The next song was "Sweet Home Chicago" and I took a deep breath and realized that we'd won.

Obama took the stage (you can see him on the Jumbotron in the picture to the left - that's as close as I got to him). His speech was not celebratory, but a bit somber. Many people began leaving after he finished, and I saw a few other faces still looking toward the stage that looked, frankly, stunned.

Walking away from Grant Park, I passed a building with lights spelling "USA". Somehow this took on a different tone for me than the with-us-or-against-us jingoism of the last eight years. It seemed... hopeful.

Friday, June 13, 2008

Command line Google searches with goosh

Goosh (short for Google Shell) is a web page that acts like a command-line interface for Google running in your browser window. It's the Google equivalent of the DOS prompt or Unix shell.

At first I just thought it was cute, which it is. But now I've found myself doing most of my searches from it. So let's take it for a spin.

Here's the empty goosh command line.

Now type a search term and hit Enter. The first 4 results display.

Type the number of the result to open that link in a new tab. Type m (for more) to see more results. Type c (for clear) to clear the results. Pressing the up arrow will cycle through previous commands that you typed, just like you can in a shell window. Nice.

There's a cleverness in the way Google's different search capabilities are partitioned in goosh. Type "cd images" and you switch to the images directory.

From the images directory, type your search term, and the image results display.

Or type "video chicago" and you'll search YouTube for Chicago videos.

Now, the kids on Slashdot don't seem to care for it because, well, you can't run unix commands in goosh, which utterly misses the point.

Finally, a geeky in-joke I just can't resist.

Wednesday, June 4, 2008

Agile development aligns business & IT

An interesting podcast from Scott Hanselman interviewing Owen Rogers. Scott does a consistently fantastic job with his interviews. (A transcript is available if you prefer to read.)

The discussion is about continuous integration and monitoring. But it touches on the concept of continuous integration as "the thin edge of the wedge" of agile adoption in an organization. That is, setting up continuous integration can have a viral quality that begins to inject more agile behavior into the organization.

That's an interesting concept in and of itself. But then the discussion also put forth the notion that agile development aligns IT more closely with the business. This is not an idea I recall hearing explicitly stated before. Thinking about how agile works, this seems patently obvious, of course. But agile is generally presented as an IT-driven effort, primarily for the benefit of IT.

This concept of agile being a mechanism by which to effect business/IT alignment is a good one to keep in your back pocket and could be a useful argument for enterprise architects to help sell agile to the business.

Friday, February 8, 2008

Designing a RESTful API

There's a bit of art that goes into designing any API. We've designed and refined a SOAP API over the last couple of years, and the RPC-like nature of SOAP does seem to make things fairly simple from an API designer's perspective. Everything looks more or less like methods you would see in C#, only exposed through a service.

Designing a RESTful API, on the other hand, is a process I am finding to be a much bigger mental leap.

The REST model is best suited for problems where you're dealing with assets - that is, things that you act upon. But I couldn't find any good examples that were truly RESTful and also handled complex asset scenarios.

What is truly RESTful? Well, to be truly RESTful you use all 4 HTTP verbs (GET, PUT, POST, DELETE). You don't add action verbs as params (?name=smith&action=delete). I could be flip and say it's not RESTful because it's cheating, but it's not about a dogma. The design criteria was to make the API as simple as possible, and having to know about special action= parameters requires additional knowledge on the part of the consumer. For us, the consumer should be able to have no prior knowledge of the API, just of the resources they want to access, and still be able to accomplish useful work.

The complex asset scenario is trickier, I think. Most of the RESTful APIs out there deal with rather flat and simple resource structures. Amazon's S3 resource structure never gets more complex than GET /[bucket-name]/[key-name], and Google's search API is also flat but decorated with lots of filters: GET /search?q=bill+material&output=xml&client=test&site=operations

Don't get me wrong - simple is good! It's just that these aren't great models to learn from for a more complex set of assets. For example, say I have a taxonomy of categories with n numbers of subcategories. Each category can contain n number of items. Items can also contain subitems. Categories and items can each have a set of properties, and furthermore each category and item can be one of a certain set of types, which means they can have different property sets. And the same items can appear in more than 1 category. In some cases I only want to retrieve a subset of all available properties for n items or categories.

Category A (categoryType=F1)
.|- Category AA (categoryType=G4)
....|-Item 27 (itemType=9H)
....|-Item 492 (itemType=4Y)
.|- Item 1 (itemType=9H)
Category B (categoryType=F1)
Category C (categoryType=F1)
.|-Category CC (categoryType=H8)
.|-Category CD (categoryType=H8)
...|-Item 1 (itemType=9H)
.....|-Item 303 (itemType=7T)
.....|-Item 305 (itemType=7T)
.....|-Item 306 (itemType=7T)
.|-Item 27 (itemType=9H)

This is, in a nutshell, the set of resources I need to be able to expose through the API.

For something with this level of complexity, where thinking in terms of sets becomes more natural, I found Microsoft's Astoria project (officially: ADO.NET Data Services) to be very helpful. Especially the concept of filtering resources.

Take the following example: GET /Customers[ALFKI]/Orders[1]/Employees, which filters the assets based on the data in the brackets, in this case returning those employees who created Order ID=1 for customer ID=ALFKI. The beauty of this approach is that it's easy to extend the filters in the brackets. So I could do GET /Customers[ALFKI]/Orders[1,2,9]/Employees or even /Customers[ALFKI,PDX,MSTR]/Orders[1-1000]/Employees.

The RESTful API we're working on isn't done yet - we're just starting to create a mock service that spits out static XML so we can get a feel for how the various consumers will actually use the API. This will let us play with the details of the API and the XML format before we commit to building all the data plumbing underneath it.

Here are some RESTful resources I found helpful:
  • Using ADO.NET Data Services - some great thinking from Microsoft on building a RESTful API for selecting complex data sets
  • Why REST Failed - the title is overstated, but Elliotte Rusty Harold (no relation to me) does a great job explaining the current challenges with PUT and DELETE support in modern browsers. Good for understanding what you're getting into.
  • Why PUT and DELETE? - an interview with Elliotte Rusty Harold that does a nice job of explaining why you want to go to the effort of supporting all 4 HTTP verbs despite the limited browser support. In a word - elegance.