bulknews.typepad.com

Mobile Data services for visitors to Japan: 2011 Fall edition

Lots of friends have been asking me of options to get mobile internet in Japan, especially for a short visit (1-2 weeks). Here's the updated version of such options.

b-mobile Data Only SIM

If you have an unlocked GSM phone that supports W-CDMA 2100Mhz, getting b-mobile's data only SIM is the cheapest path. Get their latest in the lineup b-mobile 1GB Teigaku SIM from Amazon or at stores like Bic Camera, activate it by phone (they have English menu) and put it into your SIM slot and you get 1GB data for 1 month. No contracts required and there's no 300kbps bandwidth cap which they still have with cheaper SIM (U300). Note that they have standard SIM and micro SIM, choose whichever suits your needs.

The only barrier for getting a b-mobile SIM card is that you need a working Japanese cellphone number to make a call to activate the SIM card. Welcome to the bootstrap problem. If you have a Japanese friend this would be easy, but otherwise you might have to consult store employees.

• Network: DoCoMo
• Devices: Your own unlocked W-CDMA phones (e.g. iPhone 4, Nexus S) or hotspot (e.g. Huawei E585)
• Price: 3100 JPY
• Cap: 1GB data, no bandwidth limit

Also, if you plan to use b-mobile's data-only SIM with Android 2.x devices, be aware of a possible Android's bug where it drains battery a lot when used with Data only SIM. The only workaround is to enable Airplane mode when you don't need the data network.

Using a data only SIM also means you have to give up your regular SIM. It may or may not matter to you depending on how you use your phone numbers. To me it doesn't matter since I use google voice as my primary number, and i don't receive as many phone calls anyway.

Pocket Wi-Fi/mi-fi rental

There are some rental plans available for "Pocket Wi-Fi" (e-mobile's MiFi branding).

• Rent a Pocket WiFi
• XCom Global

I haven't personally tried any of these options, so i can't recommend any specific. You can google for Pocket WiFi rental Japan to see more options.

• Network: e-mobile/b-mobile(?)
• Devices: Pocket WiFi router
• Price: 5000-7000 JPY for a week
• Cap: Unlimited data/bandwidth

WiMAX Rental

I've been trying to find a prepaid/rental WiMax rental optoins from UQ and its MVNO partners, but couldn't find one. Some have 1-month option, but it still requires a setup fee.

The only "available" option is their trial service: Try WiMAX. You can choose the hotspot option and it is FREE for 15 days.

But obviously, they want some commitments - at least you have to prove your residency in Japan, and submit your credit card information, etc. So this should only be doable if you have a kind friend or family in Japan who can help you. But if it's there, this is the most affordable option - FREE!

• Network: UQ WiMAX
• Devices: Aterm WM3300R (hotspot)
• Price: Free
• Cap: Unlimited

Data Roaming from your own provider

If you have a good Wi-Fi connection at places you stay and work, and only need mobile data services for email/twitter/chat with your mobile devices, data roaming from your own provider might be the easiest and affordable option.

You might think that data roaming should result in a crazy bill, but with AT&T's global data roaming packages, you can get 125MB of data for $49.99/mo. Note that it prorates by day, so you have to be careful when to enable this option and disable, but this worked well for my wife's stay. AT&T partners with DoCoMo and Softbank for roaming, but unless you have a specific reason to, you should choose DoCoMO as a network since it has better coverage and speed.

• Network: DoCoMo/Softbank
• Devices: Your own W-CDMA phones with AT&T SIM
• Price: $49.99 (other prices available)
• Cap: 125MB data, no speed cap

If you're on T-Mobile US, their data roaming plan is $10/1MB - you don't want to do that.

Others

There may be other options that I am not aware of, but most of them are either a) pricy or b) requires residencies in Japan. Tell me in the comments if you have other suggestions.

On Perl and backward compatibilities

Much of my thinking about the future of Perl 5 stems from the following principles:

• New versions of Perl 5 should not break your existing software 
• Backward compatibility must not stop Perl 5 from evolving

via www.nntp.perl.org

The message linked here discusses lots of insights on perl 5.16 and beyond, based on the talk Jesse Vincent has been busy giving at various conferences this year. It's a great read if you're interested in the future of perl the language.

When Perl and Ruby get compared, it is often mentioned that Perl takes a lot of care and efforts to be as backward compatible as possible while Ruby (the language and its ecosystem such as rubygems, rails etc.) do not care that much and prioritize on evolving faster by making drastic change more frequently.

I think this holds true in some sense - for example, scripts written for perl 5.8 (released more than 8 years ago) will most likely just work on perl 5.14, without any changes. That's probably not the case with Ruby 1.6 and 1.9.

This makes people feel much less worried about upgrading perl, which is a great thing, but I could imagine that the restriction ("upgrading perl should not break existing code, even a major upgrade") definitely makes the development and evolution in perl harder than otherwise.

I can say that the similar thing is happening outside the language development as well: in CPAN modules.

CPAN module's policies

Most (but not all, I know) of the CPAN modules, once uploaded to CPAN, try to keep the API interface stable and as backward compatible as possible. That's the de-facto virtue of CPAN modules. If a module keeps changing API with every release, it will be rated horribly bad, and people would eventually stop using the module/framework, thinking it's unstable/fragile.

While generally it is a good thing to keep the interface stable, and I appreciate all the heroic efforts of perl module developers putting so much efforts to keep the backward compatibilities, I could say it is unfortunate if  that prevents their software from evolving as fast.

And I personally guess that this is simply because there's no good/easy way to manage this situation.

Example

Let's take some example. Although this is not a real example (notice the version numbers that are not real :D), this is pretty much what's happening today.

In 201X, Catalyst 8 introduced some feature X, and developer Joe wrote an extension called CatalystX::Foo based on the new feature. It declares the dependency on Catalyst by saying:

requires 'Catalyst', 8.0;

in Makefile.PL, which will later be written down to MYMETA.yml. He shipped the extension to CPAN. When an end user requires CatalystX::Foo, it will pull down the latest version of Catalyst and it works fine. So far, so good.

Few months later, Catalyst dev team decided that the feature X was a good idea but needs some modifications, and had to make some API incompatible changes that breaks CatalystX::Foo, and shipped Catalyst version 9.0. 

So now, CatalystX::Foo stops working when an end user upgrades Catalyst to version 9. As long as the user keeps version 8 it's fine, but it's like a time bomb now.

How do we prevent this kind of thing from happening? Today, here's what they do.

• Catalyst developers keep the list of affected downstream modules and notify authors to upgrade to the newer API.
• Downstream (e.g. CatalystX::Foo) author uploads the new version to CPAN, declaring the dependency on Catalyst version 9.
• Catalyst gets shipped with a giant list of conflicts table (search for %conflicts) which warns users that they have to upgrade these downstream modules after installations. They can't just depend on the new version.

While I respect the effort by the upstream developers (i.e. Catalyst developers) for maintaining the list, to me it looks like a non-ideal situation here, because:

• it is odd that upstream modules have to take care of downstream, not the other way round
• this doesn't scale, and doesn't work for modules that are not on CPAN (i.e. DarkPAN, github)
• the warnings generated by the upstream (Catalyst) is useful, but there are CPAN installer that ignores Makefile.PL output (like cpanminus :)) and the output is not given attention in the case of automatic scripted installs anyway

Personally, I don't want to maintain the list of Plack::Middleware modules once (say) I decide to break the API compatiblity in Plack 2.0.

Solutions

I don't have a magic bullet that solves this situation right away, but I have some ideas, and the actual code to implement that. Here's the gist of it:

• Downstream dependencies are advised to actually use version ranges in dependency declarations
• Upstream should use semantic versioning or something similar, so that downstream can somehow predict API incompatibilities using version numbers.
• CPAN installers should install MYMETA.yml files into site_perl library path so that it can be used for later instropections.
• Every project should use a separate local::lib to have an isolated library path.
• Write a tool to rescan the whole (per project) library path to ensure there's no conflicts, and urges end users to upgrade/downgrade if there are.

Overall, this is what bundler does for Ruby gems, and I'm trying to make carton do the same thing for CPAN and local::lib.

It will make the end user happy by allowing them to lock the dependencies, and will make the module authors happy by allowing them to evolve fast, without worrying too much about backward incompatibilities on downstream (although they really care about that to some extent anyways).

I plan to incorporate all of this into Carton 1.0 release, which should happen before or during YAPC::Asia 2011 in Tokyo, which is in 2 weeks.

In other words, this is how conference driven development works :)

Renting books from SFPL using Kindle

Go to SFPL overdrive library, look for books you want to read. The catalog is not as quite nice - you might need to request a hold for popular books, which I did yesterday and received updates this morning that it is available now.

When you click "Get for Kindle" you'll be redirected to Kindle site, and you're ready to go:

Like a normal Kindle book, you can sync wirelessly to any device from here. I chose my iPad but am now at work and can't read it here - so I launched the Android app and Kindle cloud reader, confirmed that I can read the book in any of the devices. (What is the pulldown for, if I can pull from them on any device anyway?)

This is really nice.

The SFPL account also gives access to O'Reilly Safari bookshelf (not all, but most of the catalog). Something you should really have if you live in the city :)

Going to London Perl Workshop 2011

Dotcloud sponsors my flight to London and LPW guys let me do the 2 hour tutorial for "Deploying Perl/Plack web apps to the cloud".

Looking forward to seeing my fellow hackers in London! The conference is free and you can register from London Perl Workshop website.

Game Center CX filming

via www.flickr.com

Game Center CX (Retro Game Master in USA) has been my favorite TV show all the time. The show is all about retro video games, and Shinya Arino, aka Kacho, does the challenge to beat these games in a day. He and the rest of the crew came to San Francisco to do the filming of upcoming episode for the show at Musee Mecanique.

If you haven't heard of the show, Kotaku is streaming old episodes with English dubs/subs for free.

Quite a few fans showed up to watch the filming, and I just talked to Kacho Arino and exchange my card with him!  I also talked to Kibe-san and Kan the producer, who told me about this event. They were super friendly and awesome.

More pictures can be found on my Flickr page.

The episode will be broadcasted in Japan in October apparently. Can't wait to see it :)