For many of our development projects, we use Ruby as our programming language. The language is not only interesting from a software development perspective, but also from a cultural one. Ruby was originally created by Yukihiro Matsumoto, and many of the core developers are also Japanese.  Although this programming language began in Japan, it is now popular throughout the world. 

Because many of the Japanese ruby developers are not so comfortable with English, there is a bit of a rift between the two communities.  This divide between the international and Japanese Ruby communities came up several times during RubyKaigi.  At the same time, both sides want to work to close this gap.

As a Canadian in Japan I feel I am in an excellent position to help bring these two communities together.  I am both tapped into the English speaking Ruby community around the world through the internet, and the Japanese Ruby community by virtue of my location.

With this in mind, I created Tokyo Rubyist Meetup. This group will give Japanese Rubyists a chance to meet with non-Japanese Rubyists like my self.  Within an hour of the announcement of the group over twitter, we already had 25 people sign up, so it seems there is a demand for such a group.

We are going to have our first meeting towards the end of this month (the exact date is to be decided).  If you are interested in Ruby and living in Tokyo please join us. 

The delayed_job plugin for Rails does a good job for pushing tasks that take some time to process into the background, so that your users (and your Rails processes) can do other things than to wait. It uses daemons to process the backgrounded tasks, so for your system to work correctly it is essential that those daemons are running. Thus you want to make sure that those daemons are getting started when the server boots and are restarted in case they die. Those points are not addressed by delayed_job.

The usual way to get processes started at boot time under Linux is to use an init.d script. But init.d scripts only address the boot process - if the daemon dies, it won't get restarted.

D.J. Bernstein's daemontools make it very simple to create system services which achieve both of the above points: starting your daemons at system boot time and restarting them in case they die. And the best feature: to create a new service, you don't even need to include any of the typical daemon features (such as backgrounding the process) into your program. So while delayed_job uses the daemons library to provide those features, we won't be needing those.

The following steps show how to set up a new service. This assumes that you already installed daemontools (available for Ubuntu/Debian for instance: apt-get install daemontools-run).

1. Create a new directory. This is going to be the service directory.
2. Create a shell script "run" in the service directory which runs your program. This can be as simple as exec /path/to/my/program.
3. Create a symlink from the system service directory (for Ubuntu that'd be /etc/service), pointing to your new service directory.

That's it. To control your service, use the svc tool. See the manpage for more information.

In case of delayed_job, we are using the following run script:

#!/bin/sh
export RAILS_ENV=production
exec 2>/dev/null
exec setuidgid railsuser /srv/railsuser/project/current/script/delayed_job run

The script changes the user to "railsuser" (you don't want to run your delayed job processing under root; change it to match your setup), and then starts the usual delayed_job script, telling it to not put itself into the background.

One specialty to note is the handling of stderr. We redirect it to /dev/null to avoid potential "Broken pipe" exceptions in case something writes to stderr, which isn't available. Redirecting sdterr to stdout did not work.

Now, when updating, you will want to restart the delayed_job service. With capistrano we use the following task definitions:

namespace :delayed_job do
  desc "Start delayed job (if not running)"
  task :start, :roles => :app do
    sudo "svc -u /etc/service/#{application}_#{rails_env}_delayed_job"
  end
  desc "Stop delayed job"
  task :stop, :roles => :app do
    sudo "svc -d /etc/service/#{application}_#{rails_env}_delayed_job"
  end
  desc "Restart delayed job"
  task :restart, :roles => :app do
    sudo "svc -t /etc/service/#{application}_#{rails_env}_delayed_job"
  end
end

after "deploy:start", "delayed_job:start" 
after "deploy:stop", "delayed_job:stop" 
after "deploy:restart", "delayed_job:restart"

This requires that your deployment user will be able to run svc using sudo, so make sure to add this to your sudoers.

Also note that for the service names in the system service directory we use the pattern #{application}_#{rails_env}_delayed_job. Those are links to the service's directory, which are located under /srv/railsuser/project/services for our setup.

With this setup we have a pretty reliable delayed_job, and can use the same framework to run most (if not all) other services we might need with very little effort.

For over a year, we have been helping with the organization of Mobile Monday Tokyo, a leading networking organization supporting the local mobile industry.  One challenge we faced with Mobile Monday Tokyo was at-the-door check-in, as finding a given participant required scanning through a list of over 200 registered participants.  To address this, we settled on distributing tickets with QR codes, which are ubiquitous in Japan.  As every standard Japanese mobile phone is equipped with a QR code scanner, this is a fast, easy to use, and cheap solution for handling at-the-door check-ins.

What began as a simple tool for checking-in attendees, evolved into a fully featured event management system.  Tailored to the needs of Mobile Monday Tokyo, we built a system that helps to

• register participants with minimal friction
• quickly check in attendees at the door
• engage the community of participants
• gather information about attendees
• sell tickets online

This event management system has helped to smoothly run many Mobile Monday events in Tokyo.

Enter Doorkeeper

The challenges faced by Mobile Monday Tokyo are similar to many other types of networking, industry and similar events.  So today we are opening this service to the public as Doorkeeper to allow everyone to take advantage of the easy ticketing and check-in it offers.

Doorkeeper delivers a compelling and cost-effective solution for many event organizers.  With Doorkeeper, we only take a small commission on tickets sold through our system.  No setup fees, no monthly fees, no other hidden fees.  You can use Doorkeeper to host your free events for free.

Why not try out Doorkeeper now?  Visit http://www.doorkeeper.jp/ for more information and to create your first event.

Also follow us on Twitter: doorkeeper_app

Out of the box, Ruby on Rails uses cookies to store a user's session ID. This is fine for most applications, but doesn't work if your application needs to support browsers that don't support cookies, such as some mobile browsers. Instead of putting the session ID in a cookie, it must be put in the URL. This increases the possibility of session fixation attacks, where one user can take over another's session, however if security isn't paramount, this is an acceptable trade off. See the Ruby on Rails Security Guide for more details on these kinds of attacks.

To enable parameter based sessions in Rails, there are a number of changes you need to make. First, in config/initializers/session_store.rb, change the default file from containing something like

ActionController::Base.session = {
  :key         => '_application_session',
  :secret      => 'secret'
}

to

ActionController::Base.session = {
  :key         => '_application_session',
  :secret      => 'secret',
  :cookie_only => false # allow session to be loaded from params
}

# Overwrite default cookie based store
ActionController::Base.session_store = :active_record_store

Now Rails can read the session ID from the URL parameters, and doesn't store the session in a cookie (the default behaviour). Besides the ActiveRecord session store, other server based stores, such as the memcache store, work as well.

In addition to enabling Rails to read the session ID from the URL parameters, the session ID must be added as a parameter. The most basic way of doing this is to define default_url_options in the ApplicationController:

def default_url_options(options = nil)
  { request.session_options[:key] => request.session_options[:id] }
end

This will ensure that the session ID is always set in the URL.

The session ID can also be added conditionally, by doing something like the following:

def default_url_options(options = nil)
  if cookies_supported?
    super
  else
    { request.session_options[:key] => request.session_options[:id] }
  end
end

If the session ID is not included in the parameters, it will fall back to the cookie.

We are proud to announce that the Mobalean wiki has been merged with the Keitai-dev wiki. The Keitai-dev wiki was created in 2004 to serve as an English language resource for Japanese mobile development. At Mobalean, we created our own wiki with a similar purpose in mind, so this merge is natural. With this merge, the Keitai-dev wiki becomes the premier English language resource for Japanese mobile web development.

Mobalean will now handle the management of this wiki, and continue to expand it with content relevant to Japanese mobile development. Thanks to Starling Software, the previous host of the Keitai-dev wiki, for creating this resource and helping us merge these two resources.

In June of 2009, mobalean release a patch for the WURFL containing Japanese handsets. This patch ignored the existing data on Japanese handsets in the WURFL as it was sparse and mostly incorrect. However, this also made it incompatible with the core WURFL, and applying the patch either required using one of the more lenient libraries, or manually editing the core WURFL.

After half a year, thanks to the hard work of the WURFL maintainers, these incompatibilities have been reconciled, and the data merged into the core WURFL. Any developer using the WURFL can now use it to start building Japanese sites right away.

Because our patch has been included in the core WURFL, we will no longer maintain a separate patch file. All new handset data will go directly into the core WURFL.

The updated WURFL is available through the WURFL project page.

IMJ Mobile has released Mobile User Book 2010,  a collection of 8 surveys (in Japanese) about the following topics:

• Mobile Video Usage
• New Mobile Services and Technology
• e-Commerce Sites
• iPhone
• Cloud Computing (what is the connection to mobile?)
• Industry's Usage of Mobile Sites
• Usability of Mobile e-mail Magazines
• Flash Mobile Site Usability

The book is available for download as a free pdf, so if you're interested in mobile in Japan, it's worth checking out.

matsui-san has written a new blog post on ke-tai.org, describing KEITAIALL, a service for viewing technical specs for Japanese mobile phones.  I'm a fan of the site's simple and clean design, that allows you to view information about handsets at a glance, or search for a specific model.

The information provided includes:

• Carrier
• Model Name
• Manufacturer
• Sale Name
• Series
• First Day of Sale
• Browser Version
• Generation (2G/3G)
• Cache
• Screen Width
• Flash Version
• Ranking According to Share

matsui-san ponders about the licensing of this data, and points out that you can view all the data in xml by visiting http://keitaiall.jp/inc/choice.xml.  If developers are free to use and adapt this data as they choose, it could be a great boon to developers.

Betrend has released a report on mobile access in Japan based on accesses to their mobile platform for the month of October 2009.  The results of the report follow.

Access by carrier

Handset Capabilities

Top handsets by carrier

docomo

au

SoftBank

In the past, a mobile site had to be built using carrier-specific markup to properly function for that carrier. However, now it is possible to use XHTML to build a cross-carrier site, as all Japanese 3G handsets support some form of it [1]. Unfortunately, it is not the same dialect of XHTML: Docomo use i-mode xhtml (based on XHTML mobile profile), au uses XHTML basic, and SoftBank uses XHTML Mobile Profile 1.2. Nevertheless, although there are some differences between these versions, they all share a common base, making it possible to make a site that will function more or less the same across all carriers.

Given that not all handsets support XHTML, if you were to build a mobile site using XHTML, what percentage of handsets would it support? I've scoured the web for the answer to this question, but haven't been able to directly find the answer anywhere. However, as the number of handsets subscribing to 3G vs 2G plans are available, if we assume a handset supports XHTML if and only if it is 3G, we can use these numbers to find the answer.

In total, over 95% of Japanese handsets natively support some form of XHTML. Almost all au handsets support XHTML natively and furthermore the au gateway handles conversion of XHTML to HDML (the markup that older au handsets used). As SoftBank will discontinue its 2G service on March 31, 2010, current subscribers will need to migrate to the 3G service (and handsets that support XHTML). Finally, although Docomo has, relative to the other carriers, a large number of handsets that are not XHTML compatible, Docomo claims that i-mode HTML (which older Docomo handsets use), and i-mode XHTML is mostly compatible. Therefore, I would suggest that if you are building a site for the Japanese market, you do so using XHTML.

[1] Although many Japanese web sites say this is the case, it does not appear to be technically true.  According to Docomo, handsets from the FOMA  2051V, 2002, and 2001series do not support XHTML.  However, we can assume these handsets are few enough to make this generalization.