barbershop terminology, and queuing theory, in Tokyo

Normally I buzz/cut my own hair, so haven’t been to a barbershop in years. However, traveling for a month in Japan with only carryon bags meant no hairclippers, so I went looking for a barbershop.

In US, and Ireland, for buzzcuts, the terminology is
#1 (3mm length)
#2 (6mm length)
#3 (9.5mm length)

In Japan, for buzzcuts, it seems the terminology is:
#1 (1mm length)
#2 (2mm length)
#3 (3mm length)

I discovered this difference while *in* the barbers seat, and yes, thankfully I was able to sort it out in time, despite the language barrier!

The place I went to near my hotel (QBHouse) put a lot of thought into making a haircut as quick and cheap as possible. For example:

  • Each shop has a green/orange/red traffic light outside – you can see it for blocks away. Green = no wait. Orange = waittime of 5-10mins. Red = waittime > 15 mins, go do something else in the area and come back in a few mins. Because of this traffic light system, they dont need much space for waiting customers, and also customers feel like it takes less time to get a haircut, so they return more frequently.
  • All haircuts are the same price and you pay by putting money ((1000Yen ~= $10USD, exact amount only) into a machine at the door as you come in. Tipping is not allowed. There’s no cashier and they dont take no credit cards, hence lower overheads.
  • Instead of washing hair, and hence drying it afterwards, they use a retractable vacuum and sterilizing equipment instead. This speeds up haircut time, and also saves on plumbing costs.
  • They aim to get you seated-cut-and-out within 10mins, so slow/complicated haircuts like bleach/dyes are simply not done, which improves accurate traffic light predictability.
  • Each hair-cutting-station is cleverly designed to be very compact, and also something that the barber can keep totally clean in a few seconds between each customer… further reducing wait times.
  • Instead of having a few large stores, they instead have many small stores (2-3 hair-cutting-stations, and waiting space for 3-4 people, seemed typical per store). They can then afford to have multiple smaller stores in the same area. This makes it more likely that there is a store within a few minutes walk of you whenever you decide to get a cut. In case its busy, there’s going to be another store nearby you can try instead, and because of the external traffic lights, you can tell if its busy by looking from a distance.
  • By being open for long hours, (10am->8pm, not closed for lunch), they spread the user load to reduce wait times even further.
  • All the focus to improve efficiency and reduce overhead means that each store can quickly be profitable, even if there are other branches nearby. Also, because they are each small, its easy to make guesses in new areas, and less painful to cut losses on unprofitable stores.

I’ve been meaning to post this for a while, but after last week’s fun and games with wait times for queued pending jobs, I dug this up again, as the analogies seems interesting. Cheap to use. Low wait times. Streamline setup/cleanup between jobs. Lots of small “cheap” stores make it easy to scale up, or reduce down, as needed.
What do you think?

[UPDATED: fixed links to external sites that had moved, updated photo. joduinn 15nov2010.]

Changing timezones across Zimbra / OSX 10.5 / iCal / iPhone

One of the drawbacks of working when newly arrived in a new, different timezone is how it complicates coordinating meetings with people in other timezones. Being here in Tokyo, this is my first time working while on the other side of the International Date Line and it took me a while to get used to that.

Adding to the confusion, I’ve had trouble keeping all my various electronic calendars in sync with each other; some calendars were in one timezone, some in another timezone, while some ignored timezone and displayed meetings at mixed times. Having finally figured it out, I’m posting here in case others find this useful, and also so I can remember what exactly to undo when I get back to MountainView. 🙂

  1. In Zimbra: click on the “Preferences” tab, and select new timezone from the “Default Timezone” popdown list. Click “save”. Logout. Login. Notice the calendar map existing events to the new local time.
  2. In OSX 10.5 10.6 on my MacBookPro: click on clock/timer on menu bar,  and select “Open Date & Time…”. Select the “TimeZone” tab, pick your new home timezone and then close that dialog box.
  3. In iCal, go to Preferences->Advanced, make sure that “Turn on timezone support” is enabled and close the dialog box. Now, back to the iCal main display of calendar events, in the top right corner, click on whatever timezone is written in gray font above the search box. This will show a popup list which includes all time zones already enabled in iCal, and has “Other…” at the bottom of the list. If your new timezone is not listed, select “Other…”,  add it to the list, and click “ok”. Now back at the iCal main display, make sure your new timezone is selected in the popup list. Notice the calendar now display existing events in the new local time.
  4. In iPhone: go to “Settings->Mail,Contacts,Calendars”. At the bottom of the list, select “Time Zone Support”. Make sure “Time Zone Support” is “on”, and set “TimeZone” to your new local city. Notice the calendar now display existing events in the new local time. UPDATE: With iOS4.1, I noticed that the new timezone did not change as expected. I went into “General->Date&Time”, turned off “Set Automatically”, then turned it back on,a and presto the timezone changed as expected. joduinn 13nov2010
  5. Add one test calendar entry into the iPhone and another into Zimbra. Force a sync, and confirm you can see both test entries in iPhone, iCal, and Zimbra – and all are at the right time.

Finally: Get the FoxClocks addon. Its accurate. It takes up very little screen space. Its a real gem. And it handled all the Daylight Savings changes this week just perfectly in “real world testing” (ie when I watched the US-times change Sunday and then re-asked someone in each timezone what their new time was!). Because of my calendar woes, I missed a few meetings this week, but things would have been much worse without FoxClocks!

Expiry dates on food

When traveling, my packing-list includes emptying out the fridge before heading to the airport. Fortunately, I have almost nothing perishable in the fridge (chocolate, cliff bars, coffee, beer, vodka all last a *long* time), so this is quick.
However, when throwing out the last of the milk, I noticed the expiry date:

  1. A typo; ARP should be APR! Huh!? I always assumed those dates were all computer timestamped, but is there really a human putting in a new expiry date every day? Has anyone else ever noticed something like this?
  2. Since when did milk last over a month? This milk was bought slightly over a week ago (approx Feb 20th) and claims to be good until April 5th, which is approx 6 weeks!?! How is that possible? I’m used to milk only being good for a few days.

If you don’t already know of it, check out www.stilltasty.com. It answers all important questions like how long will pizza safely last when frozen / when in fridge / when left out at room temperature. 🙂

How to search Thunderbird emails with Spotlight on a MacBookPro (OSX 10.5)

After upgrading from OSX10.4 -> OSX10.5, I was surprised to discover that Spotlight was no longer indexing Thunderbird emails.

I went back and rechecked all the steps in my earlier blog post, thinking maybe some files were lost in the upgrade, but all appeared ok. Using “/usr/bin/mdimport -L" I verified that the importer was present and still running. I even tried "/usr/bin/mdimportmdutil -E" to do a complete new re-index, in case it was somehow corrupted. Still no success.

Re-reading my earlier instructions, this step caught my eye:

  • Move Thunderbird.mdimporter to either “~/Library/Spotlight/” (which I did) or “/Library/Spotlight/” (as suggested in some other posts)

…so as an experiment, I moved the Thunderbird.mdimporter directory from “~/Library/Spotlight/” to “/Library/Spotlight/”, used "/usr/bin/mdimport -L" to verify that it was running in the new location. Immediately, Spotlight was finding matches within my Thunderbird emails.

The only change I did was to move the Thunderbird.mdimporter – could the location of this really be o.s. version specific? Maybe that explains why some people used one location, and some the other?

(If anyone reading this has done these same steps, I’d be very curious what location are you using for Thunderbird.mdimporter, and what version of OSX you are using!)

UPDATE: At first, Spotlight worked fine, but problems arose soon after the original blog post. Spotlight started giving garbage results pointing to unrelated files, showing confusing icons and filenames for matches, and eventually a system crash. I suspect that Spotlight from 10.5 got confused by the existing indexed data of Spotlight from 10.4, but have no data to back that theory.

To get Spotlight working with Thunderbird properly, I did the following:

  • move the Thunderbird.mdimporter directory from “~/Library/Spotlight/” to “/Library/Spotlight/”
  • use "/usr/bin/mdutil -E" to clean out the existing indices.
  • reboot the computer
  • use "/usr/bin/mdutil -E" to clean out the existing indices again. (maybe unneeded but by now I was being paranoid!)
  • used "/usr/bin/mdimport -L" to verify that it was running in the new “/Library/Spotlight” location.
  • wait a few mins, then try searching your email.
  • smile and celebrate with a cup of coffee.

Hope that helps – John. 04dec2008

How to export Contact info from Palm Pilot/Treo to Apple iPhone 3G/4Gs

The basic technique here is to export all your Contact info from Palm’s format to Microsoft Address format, and then import from there into the Apple iPhone Contacts app. The best instructions I’ve found so far were here, but I’ve added extra gotchas below in case it helps others. Note: this only transfers Contact info, and does not transfer Calendaring, ToDo or anything else.

Before starting, you need to do the following:

  1. On a MS Windows PC, install palm desktop and iTunes. (If you primarily use iTunes on another computer, its ok to just install iTunes on the windows PC, do this one-off data transfer, and then throw away that iTunes installation).
  2. Start Programs->Accessories->AddressBook and make sure that the Microsoft Address book is empty. (Note: this is not to be confused with MS Outlook, which is very different!)
  3. On the Palm Pilot/Treo, look through all the contacts for the following gotchas:
    • If any contact has two entries of the same type (for example, a person with two mobile numbers, or two work phone numbers), you will need to manually remove/rename one of these numbers before you start. I noticed that any contacts with multiple entries of the same type ended up losing all but one.
    • If you have the same person listed multiple times in your Palm Pilot/Treo, this will cause an error later on. I discovered that I accidentally had the same person entered twice, in two different categories. These duplicate names caused errors later on in the export process, so its best to check and fix this before you start. Worst case, if you miss a duplicate, its quick and easy to just throw away all the conversion work and restart from the beginning again….but it sure it annoying!
    • Check for any occurrences of  ‘=  (single-quote followed by equals)  in your contacts, or attached notes. If you find this anywhere, you must change them to something else before you can continue. It seems that ‘= (single-quote followed by equals) is used as a delimiter somewhere in the conversion process, so anything after that gets cut from that specific person’s info, and never transferred.
    • “Custom fields” are not transferred, so you should either migrate that data to one of the “standard” fields, or make a note of them, and come back later to cleanup by manually copying from palm desktop into MS Address book.

OK, thats it. Now we’re ready to begin:

  1. Hotsync your Palm pilot/treo with the Palm Desktop one final time. Remember, backups are your friend!
  2. Start Palm Desktop and view the Address page. Select the contacts you want to bring over (ctrl-A on keyboard if you want them all), then choose File->ExportvCard… to save all your contacts into one single file on your desktop.
  3. Start Programs->Accessories->AddressBook
  4. Drag and drop the newly created file from your desktop into Microsoft AddressBook. You’ll be asked to press “ok” for each entry being imported into AddressBook. Annoying but its very quick.
  5. Unplug your Palm Pilot/Treo, and plug in your iPhone.
  6. Start iTunes. On the iPhone page, Info tab, choose to sync contacts with Microsoft Address Book and click Apply.
  7. Sync your iPhone with iTunes – this will in turn pull the contacts from the Microsoft Address Book.
  8. On iPhone, look in Contacts app, and verify that all your contacts transferred over correctly. Specifically, look for long attached notes to make sure nothing was truncated.
  9. Undo step (6) in iTunes.

Thats it!

Again, this only transfers Contact info; I’m still investigating exporting Calendaring, ToDo and other types of “legacy data” – any hints? 🙂

Big tip-o-the-hat to: http://www.fixya.com/support/t161691-downloading_contacts_from_palm_iphone and also http://www.dba2csv.com. Both were wonderful help!

All this left me wondering why Apple didnt provide an import utility to handle migrating from Palm Pilot to iPhone…or from BlackBerry to iPhone.  That would sure make it easier for business users to migrate over to iPhone. Oh well.

UPDATE: These same instructions worked great tonight when migrating a friend from a Palm Pilot to a new iPhone 4Gs. Added warning about custom fields, which I missed in this first blog. joduinn 04-dec-2011

1.4 million Firefox MajorUpdates in 6 hours?!?

Its been exactly 6 hours since we made FF2.0.0.16 -> FF3.0.1 Major Update live.

In those 6 hours, we’ve now served major updates to 1,416,982 users.

Thats impressive when you think that we pushed the updates live exactly 6 hours ago. (7.15pm PST), and we initially had throtting enabled. Now, with throttling off for the last 3 hours, we’re picking up the pace, doing 7095 major updates *per minute*. Thats 118 major updates *per second*. This means the total for the next 6 hours should be higher again.

After the Guinness Book of Records event, its easy to take numbers like that as “ho hum”… but thats a *lot* of people upgrading. Very exciting times!

This Major Update release feels like it went really smoothly. Especially going from start to finish in only 10 days. To be fair, we have been working on this since Dec2007, when it was on the RelEng and QA goals for Q2 2007. At the time, we wanted to make sure that, as much as possible, any major-upgrade-blockers were found and fixed *before* we released Firefox 3.0. This was our 5th complete end-to-end “test run”, and it worked great. It also forced us to cross-check partner builds, and all sorts of interesting upgrade scenarios, long before we released, …not after! See bug#394046 for some details. All this behind-the-scenes-homework was already done, so this rapid turnaround was totally possible.

Big tip-o-the-hat to nthomas (after months of work, he was on leave when the actual release happened!), bhearsum (for stepping in at the last minute), Tomcat, juanb and last-but-not-least to rhelmer (who came back to help with moral support and sanity checking!).

How to search Thunderbird emails with Spotlight on a MacBookPro (OSX 10.4.11)

Ever since I started using Thunderbird on a mac (over a year ago), its been annoying that Spotlight searches other files on my laptop, but not my emails. I finally had time to put aside an evening to try this, and got it working in just a few minutes.

Here’s what I did:

  • Shutdown Thunderbird. The more cautious should backup their files – I was feeling cavalier so didn’t bother.
  • Go to https://bugzilla.mozilla.org/show_bug.cgi?id=290057#c110 and download the attached Thunderbird.mdimporter.zip zipfile.
  • Open the zipfile on your desktop, and extract the file Thunderbird.mdimporter.
  • Move Thunderbird.mdimporter to either “~/Library/Spotlight/” (which I did) or “/Library/Spotlight/” (as suggested in some other posts)
  • Start Thunderbird, and go to Thunderbird->Preferences. In the Preferences dialog, go to the Advanced tab, and then at the bottom of the General sub-tab, click on the “Config Editor…” button. Search for mail.spotlight.enable, and double-click it in the search results to change the value from “false” to “true”.
  • Close Thunderbird.
  • Open a terminal shell, and run "/usr/bin/mdimport -L" to verify that the new Thunderbird importer is correctly found and now running. If Thunderbird.mdimporter is not here, go back and verify the steps above.
  • Some posts commented that you needed to restart your machine, but I cant remember if I needed to do this.
  • After waiting a few minutes, use Spotlight to search for an email. Try searching for something obvious – like “@” or your email address – the point is to see if any of the indexing has started. If the indexes are still being built, you might find very few results, but should at least get something. Allow time for indexes to get built on all emails.
  • Observe that Spotlight lists email messages in “Mail Messages” section of search results. Observe that clicking on an email message in search results will open a new Thunderbird window of that actual email.
  • Thats it – enjoy! 🙂

Tip of the hat to razal.de, dennis.ca, rosshollman.com, macosxhints.com for pointing the way; I ended up doing a subset/combination of parts of each of their instructions, so hope folks find the steps I followed useful.

For the record, I was using the following:

  • MacBookPro running OSX 10.4.11
  • Thunderbird 2.0.0.16

How to use Jawbone headset with Skype/SJPhone on a MacBookPro

I wanted to setup a headset for my work VOIP phone calls from my laptop. I already had a Jawbone headset for my cellphone, why not use that?
Literally all I had to do was:

  • make Jawbone discoverable (when powered off, press the black shiney section with raised lettering, until the LED starts alternating Red/White)
  • on Mac, in Bluetooth menu, “Set up Bluetooth Device”, pick “Headset”and walk through the dialogs to find devices. Enter passcode, which is defaulted to ‘0000’.
  • in Skype, preferences dialog, audio tab, set the “Audio Output”, “Audio Input” and “Ringing” options to each use the “Jawbone” menu item.
  • in SJPhone preferences dialog, audio tab, set the “Output” and “Input” options to each use the “Jawbone” menu item.

That was it.
It all just worked first time, and was literally all up and running in two minutes. It would have been even faster except I had to dig up the instructions on making Jawbone discoverable! It took me much longer to write this blog post, but thought this info might be useful to others.

For the record, I was using the following:

  • MacBookPro running OSX 10.4.11
  • Skype v2.7.0.330
  • SJPhone v1.60.299a
  • Jawbone headset(!)

Thunderbird 2.0.0.9 by the (wall-clock) numbers

Mozilla released Thunderbird 2.0.0.9 on Wednesday 14-nov-2007, at 5.10pm PST.

From “Dev says code ready to release” to “release is now available to public” was 15 days 22.5 hours wall-clock time, of which the Beta period took 6 days 8 hours, and Build&Release took just over 2.5 days (62.5 hours).

17:30 30oct: Dev say go
09:40 31oct: mac builds handed to QA
10:00 31oct: linux builds handed to QA
17:55 31oct: win32 signed builds handed to QA
06:50 02nov: update snippets available on betatest update channel
14:30 06nov: QA says “go” for Beta
16:10 06nov: update snippets available on beta update channel
00:30 13nov: Dev & QA says “go” for Release; Build starts final signing, bouncer entries
08:25 13nov: final signing, bouncer entries done; mirror replication started
09:40 13nov: Build announced enough mirror coverage for QA to use releasetest channel
12:40 13nov: win32 installer bug#403670 discovered
14:00 13nov: declare bug#403670 as showstopper, put TB2.0.0.9 on hold.
18:20 13nov: root cause and fix of bug#403670 found.
05:05 14nov: one rebuilt win32 installer handed to QA to verify bugfix
05:40 14nov: QA confirmed new win32 installer is ok.
08:30 14nov: all rebuilt win32 installers handed to QA
10:10 14nov: QA signoff on rebuilt win32 installers, mirror replication started
15:00 14nov: mirror replication confirmed complete on new win32 installers
16:00 14nov: update snippets available on release update channel (for end users)
17:10 14nov: release announced

1) This was not a “human free” release. The automation work done for FF2.0.0.9 has not been tested for TB2.0.0.9. In theory it should work just fine, but we just havent had time to test it, so we chose to play safe and do this release manually. Hence this took more time for Build to produce. All of that time was manually intensive Build work.
2) bug#403670 was caused by a combination of factors. One factor was human error, I incorrectly setup a workarea on a signing machine, the same incorrect setup works fine for Firefox releases; the signing doc has now been updated. The other factor was a long-standing-but-previously-unknown error handling problem in one of our signing scripts, how to fix this is being debated within the Build team. Note: this problem was with the windows installer only, not with any Thunderbird code, and not the linux/mac installers. Overall, this delayed the release by approx 22hours.
3) Mirror absorption times were messed up by the stop-and-restart caused by bug#403670.
4) The daylight savings PST change happened during this release, giving us an extra hour. That is counted in the overall times above.

take care
John

Keeping perspective: 34hours vs 37hours

It took 34 hours to produce Firefox3.0beta1 rc1.

Those 34 hours were frantic. Two people, tag teaming day & night, working with the nervous tension of knowing that a single one character typo could invalidate the entire build, and force us to start all over again. Those 34 hours only got us as far as producing unsigned builds on each platform – roughly 1/3 of the overall Build work needed to do a release – before we hit a problem. A typo. At the beginning of it all, one person typed PDT into one computer, while the other person typed PST into another computer. That typo meant rc1 did not include a last minute important bugfix. So, we scrapped rc1 and started all over again, building rc2. (I note that the D and S are even next to each other on the keyboard [sigh!]. And if it wasnt for the timezone change last week, it would have not mattered either[sigh! sigh!])

To put that 34 hours in perspective, Build took 37 hours to do everything needed for the complete FF2.0.0.9 release… and most of that was actually just watching the automation chugging along. Active human work was down to a handful of hours for signing, bouncer/mirror updates, and a little nervous manual rechecking of the automated checks, just to be sure, to be sure.

Why the night and day difference?

We’ve been focusing on automation for the FF2.0.0.x branch over the last few months, shipping FF2.0.0.7, FF2.0.0.8 and FF2.0.0.9 each time with automation improved from the previous release. Sadly, none of this automation work is live on trunk yet. All the trunk releases, like the alphas, and now this FF3.0beta1, are done the old fashioned way. By hand. One command at a time.

This week was a stark reminder of what things used to be like, and gave perspective on how much we’ve accomplished so far this year.