More wolf packs

Everything is organized. Helge Nowak and I will be running a Wolf Pack Programming workshop at XPDays in Hamburg. The workshop is on Thursday, November 25th and runs from 9:30am to 12:30pm.

Almost simultaneously—yes, we were double booked!—Jason Ayers and Michael Lucas-Smith will be running their own workshop at XPDays Benelux, in Eindhoven, the Netherlands. Theirs will get under way at 3:30pm.

Last week, Agical hosted a workshop in Stockholm as part of their monthly Geek Nights. Attendees included Scrum's Jeff Sutherland and, as usual, the event generated lots of interesting thoughts and discussion. A number of the participants did not have their own laptops and, as a result, most people were working in pairs at shared computers; we were amazed by the "heads down" behaviour and reduction in pack communication that this change seemed to cause. The enthusiastic response to the session netted several invitations to run further events in Scandinavia, so keep an eye out for more in the upcoming months.

Impressions of Stockholm

After just over a day in Stockholm, the city seems wonderful. The architecture reminds me somehow of Vienna, while the surrounding water has a distinctly Venetian quality: dividing and yet simultaneously tying the place together. The sun has been shining and the crisp air, cold enough to require bundling up, has me thinking of Christmas and longing for a mug of mulled wine and an open fire.

Aside from a lot of walking, I've had a couple of other highlights. The first was a delicious meal last night at Bakfickan ("The Hip Pocket"), the low-end of a set of restaurants in The Royal Opera House. The prices aren't exactly low-end but, having grown accustomed to London prices, I didn't find them too shocking. I chose Swedish meatballs in a flavourful cream sauce, served with some of the best mashed potatoes I've ever eaten, sweet lingonberries, and deliciously refreshing pickled cucumber. I washed it all down with a bottle of Landsort Lager, which turned out to be surprisingly tasty as well. The chocolate mousse, ordered in a flurry of food excitement, didn't quite manage to live up to the rest: despite a lovely delicate flavour, the mixed-in crunchy chocolate bits made for a strange texture and the mousse itself was a bit heavy. Still, with great atmosphere—including a conversation about Opera with the friendly Swedish gentleman at the bar stool next to me—and friendly service, I consider it £30 well spent.

My other recommendation is the Vasa Museum, just over the bridge onto Djurgården. This well-thought-out museum was built over top of an old navy dry dock and houses the imposing wreck of the Vasa, a 37-meter warship, which foundered and sunk on her maiden voyage in 1628. She was raised, almost fully intact, in 1961 and restored. The museum is well laid out, with a wide range of interesting exhibits about the ship, her sinking and restoration, and life onboard a ship and in Sweden in the 17th century. The museum is particularly commendable for having avoided the trap of adding flaps and drawers to make the exhibits "more interactive", opting instead to use good presentation and just the right level of detail to make them engaging. A hands-on computer exhibit on the top floor does an excellent job of explaining the forces involved in the stability (or instability!) of a floating ship.

Tomorrow I turn my attention back to work for a few days before heading on to Oslo.

Computer Adaptive Testing and the GMAT

Back around Christmas, I had a few weeks free and decided to prepare for the GMAT exam, a "computer-adaptive" standardized test required (or at least accepted) by business schools around the world. With university application deadlines looming, most of the testing sessions were already fully booked, but I managed to find a mid-January test date just a few hours' drive away.

I'll start by saying that I finished university eight years ago, so—ignoring a few intense weeks of German classes—it's been a while since I "studied". And it was about half my lifetime ago that I last wrote a standardized test: you know, with those sealed envelopes, bar-coded stickers, big machine-readable answer papers, and detailed instruction books reminding you to use a #2 pencil and "chose the BEST answer". If, like me, you haven’t written one of these in a while, you may be surprised by how much has changed.

The GMAT, like a number of other admissions tests, is now administered exclusively by computer and the test centres even have palm and iris scanners, which are used any time you enter or leave the room. Unlike most computer-based tests, though, which stray little from the well-worn paths of their pencil-and-paper siblings, the GMAT uses a computer-adaptive process undoubtedly conceived by a singularly sinister set of scholars and statisticians. This process is complex and has a number of interesting implications but basically it works like this: when you get an answer wrong, the questions get easier; when you get an answer right, they get harder. The theory is that by adjusting the test to your ability, the computer is able to rate you more precisely against people of about the same level.

The material on the test is not really that hard. It's no walk in the park either, but it mostly limits itself to stuff you learned (then unfortunately forgot) in high school. Everything else about the GMAT, though, seems designed to maximize stress:

• The test is long. Nearly four hours long. There are three sections 60-75 minutes long, with a short break between each.

• The test is timed. Ok, what test doesn’t have a time limit? But this one has a clock counting down in the corner of your screen, taunting you to pick up the pace. Worse than that: you'll probably actually need all the time because the questions keep getting harder as you get them right, remember? The challenge on this test is not usually solving the problems, but rather solving them in time.

• The breaks are timed. Again, not surprising, I guess. But your break is only eight minutes long and, if you’re not back, the next section simply starts running without you! Inevitably you spend the entire break worrying about how many minutes you have left. Since you need to scan your palm and iris at the beginning and end of each break, your trip to the bathroom is not going to be leisurely.

• Erasable notepads. No pens or paper are allowed, presumably so you can't smuggle out questions. Try working out math problems quickly on a laminated card with a dry-erase marker.

• You can't skip a question. Remember that the questions get harder as you get them right and easier as you get them wrong. This means that the next question you see is largely determined by how you answer the current one. The computer needs an answer to the question, so you can’t skip it.

• You can't go back. Similarly, since your current position is determined by your earlier answers, you can't go back and change them. So if you're used to finishing early and then checking over your work, you'd better start unlearning that habit.

• You don't know the difficulty level of the questions. Is the test feeling easy because you really know your stuff or are you simply earning yourself easier questions by choosing a lot of wrong answers? The only saving grace here is that you're so busy madly answering questions that you don't have many brain cycles left to worry about this.

• Some of the questions are "experimental". About 25% of the test is made up of new questions being tested on you to determine their difficulty level, but of course you don’t know which. That's right: that really hard question you just spent 5 minutes working on because you were sure you could solve it... doesn't count!

• You are heavily penalized for not finishing. Right, ok, so you have a fixed time, you can't skip or come back, and you can’t predict the difficulty of the remaining questions. But if you want a decent score, you still need to pace yourself to answer all of them. Remember that countdown clock? You have about two minutes per question–so keep an eye on that average time! Oh, and the clock counts down but of course the question numbers go up, so you’d better get real quick at subtracting your time from 75 (you’ll be working out your average question time every few questions).

• Data Sufficiency questions. These nasty little buggers are, I think, unique to the GMAT. Given a math problem and two statements, you are asked whether the problem can be solved using either statement, both statements, or both statements together. You don't need to work out the answer to the problem but you need partially solve it several times with different information and keep each attempt separate in your mind. Don't think that sounds tricky? Try searching for "sample gmat data sufficiency questions" and try a few. I think I got only about a quarter of these right on my first practice test.

You have to admire the brilliantly evil minds that came up with this thing. The experience for the test-taker is four hours of pure, non-stop stress. At least that was my experience: my brain literally didn’t stop whirring. The adaptive process pushes everyone to their limit, challenging them to keep their feet under them and ensuring that they're sweating right until the end.

The test designers have really optimized the experience around their own needs: the test is easy for them to grade, minimizes cheating, allows new questions evaluated automatically, and measures something in a pretty precise, consistent way. I’m not entirely certain what it measures, but I’m pretty confidant that people who are generally smarter, better organized, faster to learn and adapt, and better at dealing with stress will obtain a better result.

As a company selling a product, it might seem odd that GMAC (the company that runs the test) can get away with optimizing the test for their own needs. But, although it may appear that the test is the product you’re buying, I think what you’re really buying is the report that is sent to the universities. The cost of this report just happens to be $250 + study time + four hours of stress. If GMAC had competitors, they might be forced to optimize for the test-taker but, as a virtual monopoly, the motivation just isn’t there.

The challenge with the GMAT, I think, is really learning an entirely new test-taking strategy. I used a couple of books (Cracking the GMAT, by Princeton Review and The Official Guide for GMAT Review) to first understand the test and the differences in approach that were required and then to practice as many questions as possible of the specific types that appear. Doing computer-based practice exams is, of course, also essential given that what you’re learning is the test-taking strategy more than the material.

I emerged from the exam feeling absolutely drained but energized by the rush of tackling something so intense and coming out on top. In some ways it was fun but I have no intention of rewriting it any time soon. :)

Off to the races

This week I made my first ever trip to a race track. "The Races" are a perfect opportunity for the class-based British society to strut its stuff, with innumerable options for different seating areas and "enclosures", each slightly more prestigious than the next. A number of people seemed to have paid extra for the ability to watch the races from the center section in the middle of the course; I can't see that the seating was any better but they did get to be seen by everyone else walking across the track before each race. Somebody even arrived by helicopter, parking their aircraft (and leaving it all night—you can see it in the photo above) in the middle of the course!
It was fun though with everyone in their posh summer dresses, running back and forth from the track to the tables to the betting windows. And we even managed to win enough to just about cover admission, food, and drinks. Not bad for an evening's entertainment.

Among other things I learned that the odds on the favourites shorten closer to the race as more people bet on them. So if you're betting on a favourite, you should do so early and with one of the betting houses near the track, which pay out based on the odds printed on your ticket. Conversely, if you're not betting on a favourite, you should place your bet at the last minute or with the betting windows, which pay out odds based on the final total of bets placed (they make a risk-free killing from a straight mathematical percentage off the top). Also, the "three-way" bets, which cost double but pay out 125% for a win and 25% for a 2nd- or 3rd-place finish, seem like a good idea for decently-ranked (but non-favourite) horses with odds between, say, 5-1 and 7-1.
So of course, now that I have a fool-proof guaranteed system, we're going to have to head back more often to capitalize on it. Or... maybe I should quite while I'm ahead.

Seaside 3 "Release Candidate"

You could say it's been a long time coming.

Seaside 3.0 began ambitiously and grew from there. We began (at least I did) with the goal of cleaning up the architecture, revisiting each aspect and asking what could be simplified, clarified, or standardized. As functional layers were teased apart, suddenly pieces became unloadable and a repackaging effort got under way. From this we realized we could make the process of porting Seaside much less painful. Along the way, we lowered response times and reduced memory usage, added 10x the number of unit tests (1467 at last count), standardized code and improved code documentation, added jQuery support, and, oh, did you hear there's a book?

The result? This release runs leaner, on at least six Smalltalk platforms and is, I think, easier to learn, easier to use, and easier to extend. Seaside 3.0 is the best platform out there for developing complex, server-side web applications. Is it perfect? No, but I'll come to that part in a moment. It is the result of literally thousands of hours of work by a small group of people across all six platforms. But this release also exists only due to the generosity of Seaside users who tried it, filed bugs against it, submitted patches for it, and eventually deployed it.

Deployed it?! Yeah, you see, not only have all the commercial vendors chosen to ship our alphas and betas, but our users have also used them to put national-scale commercial projects into production. I alluded last month to a conference session I attended, in which somebody made the statement that

The best way to kill a product is to publicly announce a rewrite. Customers will immediately avoid investing in the "old" system like the plague, starving the product of all its revenue and eventually killing it.

It was a shocking moment as I realized we'd attempted just that. At first we justified the long release cycle because we were "doing a major rewrite"; then we just had "a lot more work to do". Eventually there were "just too many bugs" and things "just weren't stable enough". And, finally, once we realized we desperately needed to release and move forward, we just ran out of steam (no quotes there—we really did).

I still think the original architectural work needed doing and I'm really happy about where we ended up, but here's what I've learned:

• When your wonderful, dedicated users start putting your code into production, they're telling you it's ready to be released. Listen to them.
• We don't have the manpower to carry out the kind of QA process that goes along with an Development, Alpha, Beta, RC, Final release process.
• We need to figure out how to get more users actively involved in the project. This could be by writing code but probably more importantly by writing documentation, improving usability, building releases, managing the website, doing graphical design, or something else entirely. The small core team simply can't handle it all.
  

Trying to apply these lessons over the past month, I asked for help from a few people (thank you!) and we closed some final bugs, ran through the functional tests, developed a brand new welcome screen, and managed to bundle everything up. We're releasing this today as 3.0RC.

We're not planning a standard multi-RC process. The "Release Candidate" simply signifies that you all have one last chance to download it, try it , and let us know about any major explosions before we do a final release, hopefully at the end of the month. From there we'll be reverting to a simpler process, using frequent point releases to fix bugs. 3.1 will have a smaller, better defined scope and a shorter cycle. I have some ideas but before we start thinking about that, we all need a breather.

I also have some ideas about the challenges that potential contributors to the project may face. But I'd like to hear your thoughts and experiences. So, if you have any suggestions or you'd like to help but something is stopping you, send me an email or (better yet if you're there) pull me aside at Camp Smalltalk London or ESUG and tell me about it.

Ok, ok. You've waited long enough—thank you. Here's the 3.0RC one-click image, based on Pharo 1.1 RC3 and Grease 1.0RC (just the image here). Dale has promised an updated Metacello definition soon. Enjoy!

The Trouble with Twitter

The thing about Twitter is it's so easy. Sitting down to write a blog post takes time and effort. I want to develop a thesis, establish a reasonable structure, and edit the thing until it flows and becomes a pleasure to read. Ignoring the time spent in advance thinking about the topic, a well-written non-trivial blog post might take me an hour to write (some have taken longer). As a result, I find it increasingly tempting to just dash off 140 characters and toss the result out to the masses.

The trouble is, if you have something to say and you want people to spend their time reading it, you really ought to take the time to craft a proper argument; it seems only fair. I would much rather read a handful of well-written, thought-provoking blog posts than a hundred trivial tweets. And besides, I actually enjoy the writing process.

I'm pretty confidant that some ideas are better suited for tweets and others for blog postss, but the line can be fuzzy. And the temptation of laziness persists so I'm going to need to increase the temptation of effort to counter it. In the meantime, I'll be on Twitter throwing out undeveloped thoughts with everyone else.

This week's events

The VASt Forum in Stuttgart this week was well attended, with maybe 40 attendees. Unfortunately, as the presentations were all running long and I had to leave before the social event, there was quite limited time for discussion; but it was clear that most people were either past or existing Smalltalk users (though not necessarily current VASt customers). This, combined with the increasing regularity of Pharo sprints and the more than forty people who have already signed up for Camp Smalltalk London, seems to be a very good indication of the enthusiasm and growth in the Smalltalk community these days.

Attendance at the Irish Software Show in Dublin has been lower than we expected. My informal counts suggest about 60-80 people in attendance each day. Of interest to me was Wicket, which I had never looked at before; I was quite surprised to see how similar it is to Seaside in some respects and how similarly Andrew Lombardi, who was giving the presentation, described the framework's benefits and his joy when using it.

The web framework panel discussion had about 30 people watching and we had some good discussion there. Attendance at my Seaside talk was probably closer to 10. It would have been nice to have attracted more of the Java developers at the conference (there were about 20 people at the Wicket session earlier in the day) but it was interesting to find out that the majority of those who came had at least played with Smalltalk before.

Other interesting highlights include Kevin Noonan's talk on Clojure (seq's are much like Smalltalk's collection protocol but available on more classes), Matthew McCullough's presentation on Java debugging tools (interesting to see their progress and a also few ideas to look at ourselves), and Tim Berglund's overview of Gaelyk (reminds me disturbingly of writing PHP but the easy deployability and integration of XMPP, email, and Google Auth are cool). The speakers' dinner at the Odessa Club last night was great and we had a number of good discussions there as well.

The above photograph was humourously hung over the urinals in a restroom here in Dublin. I would have thought the slightly disturbing visual association was accidental if there hadn't been five separate copies!

Berlin, product management, and Smalltalk events

Beach bars, cuba libres, bircher müsli. I'd forgotten how classically German these things are but it only takes being away for a few months to make them stand out again.

Thanks to the official un-organizers of Product Camp Berlin, yesterday was a very successful day of discussions and networking. Some interesting points for me were:

• Kill a feature every day. That way people get used to the process and don't scream so loudly when support for features and platforms needs to be removed. This reminds me of the concepts of constant refactoring and non-ownership in software development, which helps ensure that people are similarly used to code going away.
• The problem may be your pricing model. When products (in startups particularly) begin to flounder, there may be nothing wrong with the product itself. Sometimes a simple tweak of the pricing model can be the most effective solution.
• The best way to unofficially kill a product is to publicly announce a "rewrite". Customers will avoid investing in the old system like the plague, rapidly starving the product of all its revenue.
• It sounds like there are some interesting products on the way from Nokia.
• This is my second conference since I actively started using twitter — it was not as well used this time but I still really like the technology for this sort of use case: it's great to see what you're missing, share your thoughts, and catch up with people after the event is over.
  

The weather was gorgeous in Berlin but has turned foul in southern Germany today. No big deal though as I've been slogging away indoors at my presentation for epicenter in Dublin on Thursday. I'm getting close with my slides and looking forward to the event but, before I can get that checked off my list, it's off to Stuttgart tomorrow evening for the VASt Forum.

[update: I've been offered 10 discount tickets for epicenter to give away; details here if you'd like to come see me in Dublin this week.]

For those wanting to attend the Camp Smalltalk London event on July 16-18, make sure you head over and sign up now. It's looking like we're going to fill up even our expanded capacity. If it's full by the time you get there, add yourself to the waiting list and we'll see what we can do.

Camp Smalltalk is popular

When the UK Smalltalk User Group started planning the Camp Smalltalk London event a few weeks ago, we imagined we might get 20 people. After only four days, 30 have signed up and we're jumping to figure out how many more people are interested and how many more we can handle. There are certainly worse problems to have!

If you're still interested in attending, please do us a favour and add yourself to the waiting list at cslondon2010.eventbrite.com.

Upcoming Smalltalk events

There are a number of Smalltalk events coming up in Europe over the next few months (Joachim posted about some of them a little while ago).

[edited to add:] I forgot to mention that I recorded another Industry Misinterpretations podcast with James Robertson and Michael Lucas Smith last week. It's a two-part episode talking about cross-platform Smalltalk development. The audio for the first part is available now; and (if I'm lucky) this link should be the second part once it is posted.

The UK Smalltalk User Group is up and running again and the next meeting will be at 6:30pm this Monday, April 26 at the Counting House.

[added] Markus Gälli pointed me to a talk by Claus Gittinger, creator of Smalltalk/X, on Flow-Based Programming. This will be in Zurich on April 28.

On May 4, Cincom is planning to host an experiment on "Wolfpack Programming" at the eXtreme Tuesday Club's weekly meeting. The idea is to play with how wolves' social structure and hunting strategies can be applied to a large team of programmers working in a single live system (kind of like extreme pair programming). It should be a fun evening and we're providing food and drinks for the night as thanks for your participation. More details will be posted on the May 4 meeting page shortly—please post your name there if you're coming.

May 16-19 is the SPA 2010 conference in London. This isn't a Smalltalk event, per se, but Cincom is sponsoring it and a few of us will there. We're hoping to have some results from the Wolfpack Programming experiment to discuss.

June 8 is the VA Smalltalk Forum Europe 2010 in Stuttgart. John O'Keefe from Instantiations will be presenting as well as Sebastian Heidbrink, Joachim Tuchel, and a number of others. Lukas Renggli will be talking about Seaside. I'm not presenting but I am planing to attend.

Also starting June 8 and running until the 11th is epicenter 2010: The Irish Software Show in Dublin. They asked me last fall to come talk about Seaside and I'm happy that we've got the details all worked out (though I'm still waiting for my bio to be updated). I'll be talking on Thursday the 10th and also, I think, taking part in a panel at one of the evening events.

On June 10, the 3rd Smalltalk Stammtisch in Köln (Cologne) is happening. Ich möchte gerne hingehen, aber das ist nicht möglich als ich nach Dublin fliegen muß.

July and August are quiet months in Europe since everyone goes on vacation. But I've heard rumours of a sprint or other event being discussed in London. I'll pass on anything I hear.

Then of course there's the annual ESUG 2010, in Barcelona this year from September 11 to 17. This has been one of my favourite events over the last few years.

Finally, we're also working on something in France (probably in June) and Sweden/Norway (Sep/Oct) but they're still preliminary, so I'll post details as they're available. Toss in some vacation and a couple of weddings this year and I'm going to be busy.

In the meantime, if I missed any events, please pass them along. Also, if you can think of conferences or events where Smalltalk should be represented or groups that would be interested in hearing about Seaside or Smalltalk in general, let me know and I'll see what I can do to make it happen.

The penny drops

Steven shared a post arguing for the scrapping of the US dollar bill and one-cent coin. Canada scrapped the dollar bill ages ago but are still trucking along with the penny.

Of pennies, the author says "few rich countries have a coin so worthless", which I find a bit strange since all of Europe has a penny... I guess it's not technically "so worthless" since it's worth 1.5 US cents, but in relative terms it amounts to more or less the same thing. They also have a 2c coin, which is curious in the eyes of a North American.

Australia, though, got rid of its penny a while back and now rounds all prices to the nearest 5 cents. As a result, I recall seeing a guy with a Ferrari right smack in the middle of the Nullarbor, hundreds of kilometers from the next gas station, making sure to get the "perfect" pump that would give him his two cents of "free" rounded-off gasoline.

Interestingly, Europe (including the UK) and Australia both have 5,10,20,50 cent (or pence) coins instead of the 5,10,25 cent coins used in North America. When giving change, the North American system requires more coins in almost every case. Having a 2c coin gives Europe another edge here and dropping the one- and two-cent coins put Australia firmly in the lead for fewest coins required on average.

Of course the sub-five-cent coins are rarely used in Europe anyway because sales tax is already included in the prices. This means your €3.95 sandwich will get you 5 cents (one coin) in change while your $3.99+7% tax sandwich will put 73 cents (7 coins) in your pocket. Simply moving to include the tax in prices would significantly reduce demand for the US penny.

From the things-I-did-on-Saturday dept...

Saturday I continued what seems to have become a personal weekend tradition of running along the banks of the Thames. I've been trying to run different parts each week and I may actually make it a goal to work my way along the river, though I'm not sure what to pick as start and end points (maybe the edges of Zone 6 would be a good start).

This weekend I ran from Putney Bridge upstream to Kew Bridge, a little farther than the finish line for the annual Oxford and Cambridge Boat Race, which it turns out starts in Putney and was also being held that afternoon. This 6.8km race started in 1829 and has been held annually on the Thames tideway since 1856. People here take this event seriously, apparently, with 250,000 people arriving to watch it live from the riverbanks and nearly 8 million people watching it on television.

London graced us with pretty nice weather for the day and people were out enjoying BBQs and beer. I had to enjoy by watching since I don't normally run with a wallet, but I did make it back to Putney on the tube in time to catch the start of the race. And that's about all you can catch because those guys move fast and are out of sight pretty quickly. In the end, Cambridge held strong on the outside of a long bend in the river and managed to score a narrow come-from-behind victory near the end.

I also popped into town to catch the final evening of Waiting for Godot at the Theatre Royal Haymarket. I was curious to see this production—with Sir Ian McKellen opposite Sir Patrick Stewart—last summer, and was delighted to find it had been remounted, albeit with Stewart replaced by Roger Rees. I found the scenes between Vladimir and Estragon quite engaging (McKellen is marvelous and the pair have excellent comic timing) but the scenes with Pozzo just seemed to drag. I've seen the play once before but can't recall the event well enough to know whether this is a script problem or one unique to this production. Apparently they're taking the show on a world tour; if you can handle this 1940's take on a "show about nothing", I'd recommend it, even just for a chance to catch Ian McKellen in a more intimate setting than the supposedly-upcoming Hobbit movies.

My new job

I'm happy to announce that I have accepted a full-time position with Cincom in the UK. As a result, I will be laying down my consulting hat for a while, and heading to London at the end of the month. I'll be doing Pre-Sales Consulting (or Sales Engineering, as some call it) for their Smalltalk products in Europe and also working on another product in development. I'm really looking forward to focusing my energy on customers and product/business challenges for a while... it should be interesting.

I still intend to keep active with Seaside, though my role and availability may shift somewhat. With an active user base providing amazing support on the mailing list these days and a 3.0 beta release just around the corner, this is pretty good timing. Once we get the beta out there, we'll need to start discussing what comes next but first things first... and more on that in the next little while.

In the meantime, I encourage those of you in and around London to keep in touch - I'm going to need to find out where the good watering holes are. :)

Ceremonies and sun

What a beautiful day: the sun is out, the sky is blue, and the temperature is comfortably mild. I went for a run this afternoon and there was a crisp view of the city and the North Shore mountains. Over the next few days, viewers of the snowboarding events should catch a glimpse of the cityscape that pushed the mountain forward as a venue despite the risk of lackluster snow. Maëlle Ricker just secured Canada's second gold medal and, jogging my way along the neighbourhood's streets, I have never seen so many Canadian flags adorning cars, houses, and shop windows.

The big event seems to be running well. I've heard numerous complaints about this and that: what should have been done differently, where the lineups are too long, and so on. Events have been postponed and some tickets refunded but I guess that must be pretty common for the winter Olympics (the effects of weather are a major difference vs. the summer games). But from my perspective, the whole thing is a nightmarish logistical balancing act and the results have been acceptably smooth so far.

Just over an hour until the ceremonies

We watched the opening ceremonies on TV at the (relatively quiet) German Deutsches Haus downtown. I was initially disappointed. Like most, I cringed through the national anthem and the weird performance by Bryan Adams and Nelly Furtado, singing the same phrase over and over. Despite being well executed, the segment with the boy flying over the wheat fields was random and, frankly, long. And overall the show just didn't feel "big", particularly after the massive event put on in Beijing. The "hydraulic malfunction" at the end was disappointing and I was spared Wayne Gretzky's awkward slow-truck-ride to the second cauldron because German media cut away after the first one was lit.

But numerous people around me said they liked the Vancouver opening better than Beijing's, so I looked at it again. Watching highlights later in the evening, I started realizing how visually impressive some of the scenes were: the mountains, the trees, the streaking time-lapsed tail lights on the floor beneath the inline skaters. Canada's diversity—both cultural and geographic—was well represented. The use of the audience as a projection surface was an interesting touch and the blowing wales were surprising and effective. In the end, although I would have liked less cheesy "wire flying" and more variety in projection effects, I have to admit the performance was quite beautiful in a typically-Canadian understated kind of way.

After the ceremonies, we crossed the road to the German Fan Fest, where we were entertained by a lively cover band from Thüringen. The beer is pretty pricey at over $8 and the crowd was quite a bit younger than us but we had a good time. The German-style beer garden table layout, combined (I assume) with BC-style fire and liquor regulations, means the maximum occupancy is a tad low, so show up early if you don't want to wait in line.

The trip home after 1am was completely painless: there were night buses lining Howe St. and sometimes driving three abreast. Like I said: pretty smooth.

Dress rehearsals are over, let the games begin!

It's hard to believe it's been a year and a half since my experiences at the Beijing Olympics and it's curious to find myself in an Olympic city—not coincidentally, but largely due to circumstance—for the second consecutive time.

I wandered downtown today after collecting my event tickets, watching final preparations underway: people pressure-washing, filling flower beds, cleaning windows, and just generally putting the final touches on months (in some cases, years) of work. Traffic was sparse and the yellow-jacketed traffic officers, though numerous, were easily outnumbered by blue-jacketed volunteers.

Media coverage here has droned on and on about the lack of snow, the probability of rain, the chance of lasting debt, and fact that Vancouver hotels are not sold out. While I desperately wish the media would drop the cries for drama and focus more on news, I guess these are the normal concerns of any host: what if the party sucks? what if nobody comes? But downtown, people are just carrying on getting ready.

It's interesting to note how similar one Olympics is to the next. All the details have been tweaked but the structure and rhythms are the same. The accreditations are the same; the security screening tents are the same; the timelines and schedules are the same. This time it's my German language skills and European citizenship that are securing me tickets, but the collection procedures are the same. And of course there must be stacks of procedure manuals handed from one organizing committee to the next; it would be madness to re-invent it all. More than that, though, it's mostly the same people putting on every Olympic Games: I'm going out for drinks here with many of the people I knew in Beijing, and most are carrying on next to London or other big worldwide events.

I only began to sense the excitement and anticipation here at the end of last week (probably more than a month later than in China), but it's building now. And one major difference here is the number of free concerts and other events. The Richmond O-Zone, Heineken House, Atlantic Canada House, Ontario House, and Vancouver LiveCity sites are all high on my list for entertainment, but you can check out the City Caucus Free Events Guide for many other options.

The torch will be traveling around Vancouver on Thursday and Friday. Check out the route map if you want to catch a glimpse. If you'd like to advertise your willingness to help out the tourists, you can pick up Ask Me buttons in 24 languages at the Vancouver Public Library downtown.

And finally, a cleanly-organized resource I found helpful last time for up to date event schedules, competitor information, and medal counts is Google's Olympic portal.

Easing compatibility with Grease

Photo by DarkSide, sxc.hu

In December, I gave a presentation on portability to the NYC Smalltalk group. Seaside now runs on at least seven different Smalltalk distributions. Given the lack of standardization, this is no minor feat; for Seaside’s developers, the need to keep code portable is always on our mind. As a result, we have gradually accumulated a set of tools, patterns, and conventions to help keep our code as portable as possible and to factor out code that needs to be implemented differently on each platform.

In our work on other projects, we found the same portability challenges came up over and over and we wanted to use the tools we had developed for Seaside to address them. So we began to split out the Seaside-specific functionality, allowing us to leverage the generic parts it in our other work. And thus Grease was born.

So what exactly is Grease?

• Grease enhances the ANSI Smalltalk standard. With only a few exceptions, we assume platforms are fully ANSI-compliant. Platforms want to support Seaside and standardization makes this easier for the project’s developers and its porters.
• Grease defines expected APIs with unit tests. Platforms can quickly determine if they are compatible and users can examine the tests to determine exactly which behaviours they can count on.
• Grease takes a pragmatic approach to compatibility. Sometimes a method behaves so differently on two platforms, for example, that we are forced to avoid it or to standardize on a new selector. To get standard exception signaling on all platforms, Grease is forced to provide special exception classes that can be subclassed. Sometimes we need to put “right” aside and settle, instead, on a solution that can be implemented everywhere.
• Grease tries to be concise and consistent. Despite its pragmatic approach, we still want to be “right” as much as possible. Because it’s hard to remove functionality once it has been added, we need to carefully consider each addition before proceeding. We’re moving slowly and looking for methods that are commonly used and that have clear names and semantics.
• Grease does not try to solve all problems. We are not testing Sockets or HTTP clients. We don’t expect platforms to have standard SSL or graphics libraries. Its scope may grow over time, but for now we’re focusing on extending the functionality of the core classes defined in the ANSI standard (collections, exceptions, streams, blocks, etc.) and on other pieces of functionality that are critical to the Seaside project (e.g. random number generation and secure hashing).
• Grease is widely adopted. Implementations exist already for all platforms that support Seaside 3.0. As well as Seaside, new versions of Magritte, Pier, and Monticello are already being implemented on top of Grease.

If you’re developing on Squeak or Pharo, you can also benefit from Slime, which uses the Refactoring Browser to find and, in some cases, rewrite common compatibility problems. Think of Grease as defining what you can write and Slime as defining what you can’t. It would be nice if Slime could be extended to other platforms, but their RB implementations are currently not compatible enough (a perfect target for Grease!).

Grease will continue to be part of the Seaside project and to be driven, for now, primarily by Seaside’s requirements. But we hope other projects will find it increasingly useful over time. Since each platform has already ported it, you may already be able to leverage it to provide increased consistency and portability for your applications. For the moment, consider Grease a prerelease and subject to major change; it will track Seaside releases for now, though I’m thinking of assigning independent version numbers to Grease releases to make things clearer.

The Grease packages can be found in the Seaside 3.0 repository or through your vendor's standard code distribution mechanism.

Happy Australia Day!

Sure it seems like January 25th to the rest of us, but in that upside-down land across the Pacific, it's already the 26th, the anniversary of the First Fleet's arrival in Sydney Cove in 1788. And that means barbecues, more beer than usual, and "back yard cricket" (don't ask—I never even got the rules of normal cricket).
While in Australia, I developed a soft spot for their national holiday and their stereotypically easy-going form of celebration (also for the Southern Cross, but that's another story). On top of that, several close friends have recently moved down under, so in honour of their first Australia Day, I thought I'd post a couple of "iconic" images from my collection (click the image above).
To all of you in Australia or with a bit of it in you, Happy Australia Day!

Facebook time

I was poking through some of Seth Godin's eBook What Matters Now this afternoon (apparently, in my case, it didn't matter until 6 weeks later). I like this message from Howard Mann:

There are tens of thousands of businesses making many millions a year in profits that still haven’t ever heard of twitter, blogs or facebook. Are they all wrong? Have they missed out or is the joke really on us? They do business through personal relationships, by delivering great customer service and it’s working for them.

How much time are you spending with your customers?

Chinese Feast

Last weekend, inspired I guess by a fancy gas stove and now long-glorified reminiscences of China, I decided to attempt a four-dish Chinese dinner. I have previously tried hand-pulled noodles and boiled dumplings, but this meal was all about the wok. Altogether, it took about three hours of washing, chopping, dicing, kneading, marinating, deep frying, boiling, and stir frying. Given that this is the sort of meal people eat in China on a regular basis, I can only hope that the process gets faster once you have the recipes internalized.

My companion through most of this was Yan-kit's Classic Chinese Cookbook by Yan-kit So, which I once read is the best overall Chinese cookbook out there. It has a very helpful section at the beginning that illustrates all the ingredients, the different ways to chop them, how to stir fry them, and so on.

I decided to try out my new f/1.8 50mm prime lens to capture the results but, as the depth of field was even shallower than I expected, the focus in many of the images just didn't work out. The images here are the few that were passable.

The menu was as follows:

Scallion Cakes (蔥油餅, cōngyóubǐng "scallion oil biscuits") are apparently a common street food across China, though I don't specifically recall seeing them. A simple dough is rolled flat then topped with salt, scallions (green onion), and lard or margarine. The whole thing is rolled up, twisted, and then flattened to form a thick, filled pancake which gets fried in a skillet. The end result was pretty satisfactory, though I would have liked a bit more salt, and they tasted even better out of the fridge the next day. Page 178.

Dry-fried Four-season Beans (干煸四季豆, gānbiān sìjìdòu) is a typical Sichuan dish that really lets the crispy green beans shine. The beans were first deep-fried before being stir-fried with the rest of the ingredients. I left the preserved vegetable out because I didn't have it and the dried shrimp because I was feeding a vegetarian. Still, it was delicious. Most people have a fear of deep-frying, but it's actually pretty straightforward and not too greasy if the oil is hot enough. Page 220.

Kung Pao Tofu (宫爆豆腐, gōngbào dòufu) is a variation on the well-known Sichuan spicy chicken and peanut dish, simply replacing the meat with deep-fried cubes of tofu. We ate this quite often in Beijing and, although I've made it a couple of times, I find the result tastes too strongly of soy sauce. I'm not sure yet if I just don't like the particular recipe, if it's a result of not having quite the right ingredients, or if the tofu simply soaks up a lot more of the marinade than the chicken would. You can buy packaged deep-fried tofu in some stores to save deep-frying it yourself. Page 102.

Di San Xian (地三鲜, dìsānxiān "Earth three fresh")—a mixture of twice-fried potato, eggplant, and green pepper—was one of our favourite dishes in China. The cookbook doesn't have a recipe so I used this one and the result was delicious and very authentic.

For those in Vancouver looking for an easier alternative, I ate last night at the Golden Sichuan Restaurant on No. 3 Road in Richmond. This place was recommended to me years ago by Chinese colleagues but I never made it out there until now. We had the dry-fried beans, a mushroom and pork dish, and some pork and green onion dumplings. All were delicious. The restaurant's Chinese name, 老四川, and its translation are interesting. The last two characters 四 (sì, four) and 川 (chuān, river) form the name of the Sichuan (or Szechuan) province. The first character 老 (lǎo), means literally "old" or "revered" but can also be used as a prefix to indicate affection, much like you could use "my old man" to refer to your father in English. It's also the first character in, e.g. 老家 (lǎojiā, place of origin), 老师 (lǎoshī, teacher), and 老外 (lǎowài, foreigner). You overhear that last one a lot as you walk around China.

Google re-evaluating its position in China

Google made an interesting announcement today about their approach to doing business in China. Apparently they intend to take a stand again and stop censoring the results on google.cn, even if this means they are prevented from conducting business in the country. I think the unstated message is that Google believes the "attacks and the surveillance they have uncovered" were conducted from within the Chinese government and this has prompted their change in stance (or at least, I can't follow the logic of the article any other way).

Somehow I don't see the Chinese government doing anything more than shrugging its figurative shoulders, but it will be interesting to see what, if anything, is the fallout.