A Weekend in Quebec

I recently traveled to Montreal on business and, having never experienced Quebec before, I stayed over the weekend. Like most of North America, a heatwave was gripping the area and sunshine abounded.

When I asked my Montreal friends for recommendations of things to do, their suggestions almost invariably involved eating. "You have to try poutine!", "Montreal has *real* bagels," and "You should definitely stop at Schwartz's, it's an institution." (Sadly Schwartz's wasn't yet open for business when I visited. Tip: don't get there before 10:30 in the morning)

Friday evening I spent visiting the Vieux Montreal, the oldest, most touristy section of Montreal. Quaint cobblestone streets and old buildings. The Notre Dame basilica is worth visiting. I had my first poutine at a restaurant called, you'll never guess, Montreal Poutine. So what it this famous delicacy? A culinary masterpiece of fries smothered in gravy and cottage cheese (i.e. cheese curds). It wasn't that bad, but not really that enjoyable either. I expect this may well be my last poutine. The bagels were good.

On Saturday I walked over 15 miles, most of them in the company of a German tourist, Frederik, who I ran into in the morning. Having someone to enjoy the sights with made it all the more fun. We first explored the Mont Royal, a large hill just north west of the Vieux Montreal with great views of the city. On the other side of the hill is the biggest cemetery I've ever visited. It's well maintained and I took pleasure in wandering through it on our way to Saint Joseph's Oratory, one of the most famous churches in Montreal. A walk down Sherbrooke Street rounded out the afternoon with visits to McGill University and the Museum of Fine Arts (which is free BTW, I love it when a government sponsors learning!). In the evening I thoroughly enjoyed a hilarious rendition of Moliere's play Les Fouberies de Scapin.

Sunday was time for a change. I wanted to get out of Montreal and experience some of Quebec's beautiful countryside. So I set out for Mont Tremblant, one of the highest peaks in the area at 900m (3000ft) and about 2 hours' drive north. The area is very pretty and resembles a cross between Switzerland and Norway. After visiting the summit by gondola, I headed over to the national park (which is over half the size of Luxemburg!) for five hours of climbing a via ferrata. Our group of eight had great fun.

All in all I had a wonderful time, not least of which because Montreal is the first place I've been in North America where I can speak French to almost everyone. I just wish the rest of my family had been with me!

Nine Tips to Reclaim your Focus and Creativity

Skip down a bit and follow these three tips: Eliminate notifications, Maximize your apps, and Use a Pomodoro timer. Later on, come back to read the rest! :-)

I recently finished Nick Carr's book "The Shallows", which describes the impact that technology has on our brains. While I can't say I enjoyed the book (a shame, I was very keen to read it), part of the author's introduction resonated strongly with me:

"Over the last few years I've had an uncomfortable sense that someone, or something, has been tinkering with my brain [...]. I'm not thinking the way I used to think. I feel it most strongly when I'm reading. I used to find it easy to immerse myself in a book or a lengthy article. [...] That's rarely the case anymore. Now my concentration starts to drift after a page or two. I get fidgety, lose the thread, begin looking for something else to do. [...] The deep reading that used to come naturally has become a struggle."

Carr states that the single biggest change in his professional life over this last decade has been the internet. The many boons it brings come at a price:

"[W]hat the Net seems to be doing is chipping away my capacity for concentration and contemplation. Whether I'm online or not, my mind now expects to take in information the way the Net distributes it: in a swiftly moving stream of particles. Once I was a scuba diver in the sea of words. Now I zip along the surface like a guy on a Jet Ski."

As the years pass I've noticed the same thing: checking email, reading new blog posts, or perusing interesting tweets sometimes have an almost inescapable appeal. What's worse is that, according to Carr's book, the more information I take in this way, the greater my appetite for it, and the harder it becomes to focus for any length of time.

In my experience, the "consumer half" of me crowds out my "producer half". I end up preferring the consumption of other people's work over the creation of my own.

Here are some of the techniques I've found useful in keeping both halves happy.

Eliminate notifications, or at least audible / visible cues
This is one of the basic rules: information should not announce its arrival. It's hard enough to resist infodrugs without arming them with a way to pull you in. Turn those notifications off!

Process information on your schedule
You'll find it difficult to live without notifications at first: the desire to frequently check for emails, tweets, and facebook updates will be hard to resist. Don't give in! If you do, you'll defeat the purpose of turning off notifications. Instead, make it a point to check at regular intervals, or between activities.

Maximize or "Full screen" your apps
There are many studies showing that multitasking impacts focus. Context switching is expensive. By maximizing your current application's window, it's harder for other apps to pull you away from your task. If your eye catches movement in a twitter client, or your Inbox suddenly becoming Inbox (1) you know what will happen next! :-)

David Allen's Getting Things Done is full great advice. A few principles I've found particularly useful to combat attention:
  • Keep your Inbox at zero: Knowing you've dealt with all your emails makes it easier to focus on other things
  • Log all thoughts / ideas / todos: Write them down, if you keep them in your head they waste precious "mind cycles"
  • Schedule tasks for the future: I found this technique particularly powerful yet I rarely see it mentioned. When you capture a todo that doesn't need to be done today, set its start date accordingly, and use a tool that can hide all future tasks. I've always found it disheartening to see a never ending stream of future todos, which is what most task managers show you. The feeling you get when all the day's tasks are accomplished is a powerful incentive to stay focused.

Organize workspaces by activity
I covered this more in-depth in an earlier post but the gist of it is to leverage tools like OS X's Spaces to keep your communication tools (i.e. distractions!) on one screen, while keeping productive work well away on a different screen.

Use a Pomodoro timer 
The premise of Pomodoro (Italian for tomato) is simple: if you focus for 25min without interruptions, you can reward yourself with a 5 minute break. As long as you can stick to your side of the bargain (no distractions for 25min!) that 5 min of relaxation does wonders to recharge your concentration. There are lots of Pomodoro apps out there (mobile, web, and desktop). Or you can just use a kitchen timer :-)

Listening to music also helps me concentrate, as long as it's music I know well, otherwise my minds pays too much attention to the new lyrics and music. 

Reclaiming your attention does a lot to "protect" your creativity in my experience but here are a couple techniques more focused on creativity itself..

I've stopped listening to podcasts and audiobooks while exercising (usually running or cycling). I've found that physical exertion combined with being outside frees my mind to think new thoughts. Many of my ideas for blog posts, applications, or activities come during this time. Bring a means of capturing those ideas with you!

That's the name of a daily activity in my task list. It's there to remind me that I want to create something every day. It doesn't have to be big, it doesn't have to be amazing, it just needs to be something: a draft of a blog post, a drawing, a poem to my lovely wife. They all count. And the great thing is that once you get started doing something creative, it's a lot easier to keep going.

Finally done with this post! Can't wait to see what's arrived in my twitter feed! :-)

World Population by Time Zone

Cory Doctorow, scifi author and BoingBoing co-founder, once wrote a scifi novel called Eastern Standard Tribe (available free). It was fun read but what I enjoyed most was his idea that people would belong to a "tribe" based on their time zone. In Doctorow's world, your loyalties lie not with the country of your birth but with the people who are up when you are.

This evening I was thinking about this novel and idly wondered which tribe would be the biggest? In other words, which time zone is the most highly populated?

Looking at a map, the answer was obvious: it had to be UTC+8 which includes not only China but Malaysia, the Philippines, and more.

Still, the fun of such a frivolous question is less in the answer than in the answering, so I fired up Mathematica and a few calculations later generated this graph.

I cheated a little by using a simplifying assumption: if a country has multiple time zones, I divide its population evenly between them. This inaccuracy doesn't change the fact that our top three are... <drumroll>
  1. UTC+8: China and others
  2. UTC+5.5: India and others
  3. UTC+1: Western Europe and a good chunk of Africa

According to Mathematica, there are 39 different time zones ranging from UTC-11.5 to UTC+14. I wonder if anyone has visited them all? Now that would be a glorious adventure! :-)

Flying over the Bay Area

This May my friend and fellow pilot Serge and I flew from Oakland airport to Half Moon Bay to visit the Pacific Coast Dream Machines faire. While the faire itself was nothing special, flying in the Bay Area is always a treat. We flew in Serge's Piper Cherokee, which Serge has flown all over the world (well, nearly :-) including crossing the Atlantic twice. I'd never piloted a Cherokee and enjoyed the experience, esp. since it's more powerful than the Cessna 172 I'm used to. 

Pictures below: Downtown San Francisco & Bay Bridge, Golden Gate Bridge, Ocean Beach, New (expensive!) Bay Bridge, and the Transamerica Pyramid.

How eBay Scales its Platform

In these days of discussing how Facebook, Twitter, Foursquare, Tumblr, and others scale, I don't often think of eBay anymore. Yet eBay, despite its age and ugly UI, is still one of the largest sites on the internet, esp. given its global nature. So I enjoyed this QCon talk by Randy Shoup, eBay Chief Engineer, about Best Practices for Large-Scale Websites.

Here are few lessons that caught my eye:
  • Partition functions as well as data: eBay has 220 clusters of servers running different functions like bidding, search, etc. This is the same model Amazon and other use
  • Asynchrony everywhere: The only way to scale is to allow events to flow asynchronously throughout the app
  • Consistency isn't a yes/no issue: A few datastores require immediate consistency (Bids), most can handle eventual consistency (Search), a few can have no consistency (Preferences)
  • Automate everything and embed machine learning in your automation loops so the system improves on its own
  • Master-detail storage is done detail first, then master. If a transaction fails in the middle, eBay prefers having unreachable details than a partial master record. Reconciliation processes clean up orphaned detail records
  • Schema-wise, eBay is moving away from strict schemas towards key/value pairs and object storage
  • Transitional states are the norm. Most of the time eBay is running multiple versions of its systems in parallel, it's rare that all parts of a system are in sync. This means that backwards compatibility is essential
  • "It is fundamentally the consumer's responsibility to manage unavailability and quality-of-service violations." In other words: expect and prepare for failure
  • You have only one authoritative source of truth for each piece of data but many secondary sources, which are often preferable to the system of record itself
  • There is never enough data: Collect everything you never know you'll need. eBay processes 50TB of new data / day and analyzes 50PB of data / day. Predictions in the long tail require massive amounts of data

Fearless Fire Eating at The Crucible

My 12 year old son Thomas and I took a three hour fire eating course yesterday in downtown Oakland at The Crucible. We found it through the excellent Workshop Weekend program, which offers many interesting courses. We were the only two students and our teacher, Patricia, gave us a great introduction to both the art and science of fire eating

Warning: fire eating is dangerous and an easy way to get hurt quickly. The information below is no substitute for proper instruction (it's incomplete too!). In other words... Don't do this at home!

After a comprehensive review of safety precautions, Patricia taught us how to make our own torches. These consisted of 18" aluminum rods with a wick at one end. Interestingly, the wick is made of a 12" long strip of kevlar and held in place by kevlar string. Kevlar has high heat resistance and is reasonably absorbent so it makes for a great wick. 

For our initial foray into fire eating, we used rubbing alcohol as fuel because the flame is small. Maybe so but we were still more than a little apprehensive about putting a flaming torch in our mouths!

After the first try it became a lot easier and we soon graduated to white (camping) gas which generates much bigger and brighter flames, as the pictures below show. We quickly conquered any fears we had and became pretty comfortable eating fire.

The science behind this art wasn't what I'd expected. I'd assumed that fire eating consisted of closing your mouth around the flaming torch to deprive it of oxygen and so stop it burning. Not so. You never fully close your mouth around the torch (burnt lips anyone?) instead you close them partially and exhale to extinguish the flame.

Once our basic skills were in place we moved on to art. Patricia taught us various tricks such as flame transfers and ways to light the torches. She was particularly impressed by Thomas who, in the six years she's been teaching the class, was by far her youngest student.

All in all it was indeed a glorious adventure and one we're going to practice ourselves, safely.


Platforms as a Service Revisited

In September 2007, Marc Andreessen wrote a thought provoking blog post describing a way to categorize different types of Platforms as a Service (PaaS). Over the years we’ve often made use of Andreessen’s levels within our Engineering team as a convenient way to discuss how we want our own platform to evolve.

So I was surprised when I went looking for that article the other day and it was nowhere to be found on Andreessen’s blog! Fortunately I was able to rescue it from oblivion thanks to the internet archive. I’ve also uploaded a PDF of the article to Scribd.

Andreessen’s premise is that there are three levels of internet platforms (the term Platform as a Service didn’t exist back then):
  1. At level 1 a platform is essentially a series of APIs in the cloud (another term that had yet to make its appearance) that app developers can leverage in their own apps.
  2. The prime example of a level 2 platform is Facebook. In addition to the APIs it makes available, Facebook also gives developers a way to embed their apps into its user interface.
  3. A level 3 platform achieves something the other two levels can’t: It runs developers’ apps for them. Examples here include Force.com (Salesforce.com’s PaaS) and Andreessen’s own Ning.

As the levels go up they become easier for developers to program on and manage. A company working on a level 3 platform shouldn’t need to worry about hardware and operating systems. The categories aren’t perfect though: Amazon’s Web Services offerings are clearly level 3 (they run your code) while forcing you to still manage a virtual infrastructure.

That said, many platforms do fit the model well. Thousands of companies offer APIs and therefore qualify as level 1. Platforms such as Google App Engine, Microsoft Azure, Heroku, EngineYard, etc. all offer flavors of level 3, some “purer” than others, I.e. with more or less hardware/OS abstraction.

At RelayHealth we put a number of APIs at our partners’ and clients’ disposal. Some are web services, others rely on healthcare specific protocols such as HL7 or CCD riding on top of a variety of communication channels.

Our approach to level 2 turns Andreessen’s definition inside out: instead of embedding third party apps into our UI, we make it easy for them to customize and embed our modules into their applications. This is important to many partners as building features like ePrescribing themselves is prohibitive. By providing these capabilities we enable our partners not only to deliver key features to their customers but also complete their EHR certifications (vital so their clients qualify for federal incentives).

Regardless of your approach, if you’re building a whole platform or some simple APIs, Andreessen’s article is worth reading.

The Beauty of Reversed Expectations

Michael Crichton's "The Great Train Robbery" is one of my favorite novels. It's part history, part thriller, and lots of fun. You follow master criminal Edward Pierce as he plans and carries out the crime of the century: stealing gold bullion from Her Majesty's government in Victorian England. Interestingly the mastermind was caught: Crichton used Pierce's courtroom testimony to write the book.

One of my favorite passages focuses on reversed expectations. Pierce needs to get his accomplice on board the railway car that's carrying the gold. The problem is that guards are checking all luggage to ensure no one can be smuggled aboard.

Pierce solves this very cleverly by hiding his accomplice in a coffin with a dead, very dead, cat hidden inside. Pierce's girlfriend plays the role of a grieving sister taking her poor brother's body home for burial. In those days Victorians were very afraid of being buried alive. Many coffins, including the one Pierce used, had a small bell mounted on them that could be triggered from the inside: just in case the dead "woke up". That's where the expression "saved by the bell" comes from.

Pierce's girlfriend is weeping on the railway quay when suddenly that little bell begins to ring. She cries out in alarm, then in joy. Elated, she begs the guards to hurry, to undo the latches. In her state of faked excited she tries to help but her fumbling slows the men down. "Oh please hurry!" she shouts.

The coffin is almost open. "My brother is alive after five days! I knew it wasn't cholera!" That gives the guards pause: cholera was a very real danger in those days. When the coffin's finally opened, the stench is unbearable, the "corpse" (Pierce's heavily made-up accomplice) is a nauseating shade of green, and the "sister" swoons in the arms of a guard.

The coffin is hastily closed, the sister revived, and the coffin placed in a railway car... The one with the gold.

Here's what Pierce had to say about this:
In later courtroom testimony, Pierce explained the psychology behind the plan. "Any guard watches for certain happenings, which he suspects at any moment, and lies in wait for. I knew the railway guard suspected some fakement to smuggle a living body onto the van. Now, a vigilant guard will know a coffin can easily hold a body; he will suspect it less, because it seems such a poor trick for smuggling. It is too obvious.

"Yet, he will likely wonder if the body is truly dead, and if he is vigilant he will call to have the box opened, and spend some moments making a thorough examination of the body to insure that it is dead. He may feel the pulse, or the warmth of the flesh, or he may stick a pin here or there. Now, no living soul scan pass such an examination without detection.

"But how different it is if all believe that the body is not dead, but alive, and wrongly incarcerated. Now all emotions are reversed: instead of suspicion, there is hope the body is vital. Instead of a solemn and respectful opening of the casket, there is a frantic rush to break it free, and in this the relatives join in willingly, sure proof there is nothing to hide.

"And then, when the lid is raised and the decomposed remains come to light, how different is the response of the spectators. Their desperate hopes are dashed in an instant; the cruel and ghastly truth is immediately apparent at a moment's glance, and warrants no prolonged investigation. The relatives are bitterly disappointed and wildly distraught. The lid is quickly closed--- and all because of reversed expectations. This is simple human nature, as evidenced in every ordinary man."


It's social engineering at its best.

Microsoft's Losing the Web Application War

Netcraft's surveys of internet web servers has been a staple of the net since 1995. Eons in internet time! In those early days I fondly remember regularly checking Netcraft for updates and discussing the merits of the various web servers with friends and colleagues.

I hadn't thought of Netcraft in years and when I suddenly remembered them the other day, I had to go check. How were the different web servers doing?

I wasn't surprised by the rapid growth of Apache but I was surprised by the dramatic fall and subsequent slow rise of Microsoft's web server.  According to Netcraft the drop in Jan-Jun 2009 was caused by a reduction in activity in Microsoft's Live Sites.

Looking at web server popularity in relative terms, the slow rise becomes a rapid decline in market share: from close to 40% to around 15% penetration in four years.

It's useful to remember that there are lies, damn lies, and statistics. There could be many explanations for Microsoft IIS' relative decline. 

One is that Netcraft is measuring incorrectly. Netcraft has been at this for a long time, so I'm going to assume they know how accurately count servers. Part of the decline is due to the Live Spaces moving to Wordpress. Clearly Microsoft doesn't view blogging as strategic. Fair enough.

Another point to keep in mind is that Netcraft's survey is internet-focused. If they could survey intranets, I'm sure the number of IIS servers would be significantly higher.

Still, I can't help thinking that this is yet another front Microsoft is losing ground on. And the web server is just the tip of the iceberg. Internet sites aren't choosing Apache as much as they are choosing web application stacks that use it.

Continued loss of web application stack market share will have significant repercussions in terms revenues. Hard costs such as server and software licenses. Soft costs such as losing popularity among developers. This isn't enough of a reason to ditch Microsoft for established sites. It is a reason to think twice before going with the Microsoft stack for new projects.

It's a shame. Microsoft's web application stack has decent technology, and Microsoft has smart engineers. They are quite capable of innovating in this space. They're just not doing so.