We ♥ web applications!

Mobalean is lead by Henri Servomaa, the original founder and mobile developer.
At Mobalean we strive to develop services which are loved by our clients and users.
By working in an agile manner, quickly adapting to changing requirements,
we can deliver quickly and often.

Henri Servomaa

Hailing from Finland, Henri has a long history with computers and the internet.
With a background in Electrical Engineering and Computer Science, he has worked
in Japan as Software Developer and System Admin since 2001. In 2005, he joined a
company to develop mobile sites for the Japanese market and has been involved in mobile ever since.

Cleve Lendon

Cleve is a Canadian engineer. He came to Tokyo in 1994, and has lived here ever since.
He has broad experience as a software developer, which includes development of mainframe software,
Internet applications and mobile apps (Android and iOS).
He is especially skilled at writing Java applications (vd. Simredo 4, Grafikilo 15).
When not programming, Cleve enjoys improv acting and studying languages, such as Latin and Esperanto.

Mobalean Alumni

Paul McMahon and Michael Reinsch were co-founders of Mobalean. They have moved to Doorkeeper KK, a company they established in 2013. Both are now actively developing the doorkeeper platform.

Web Development

Our strength is crafting web services for both Japanese and international markets.
We bring our technical and cultural experience to help you adapt your ideas into successful products.

We develop with Ruby on Rails and use the best agile practices and tools,
such as test driven development and continuous integration to achieve quality.

Japanese Mobile Consulting

We are the leading provider of technical expertise about the Japanese mobile web.
Our
Keitai Web Technology Guide is a great starting point for learning
about the challenges of Japanese mobile development. Developers can find more technical
details in our Ketai-Dev Wiki.

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).

Create a new directory. This is going to be the service directory.

Create a shell script "run" in the service directory which runs your program. This can be as simple as exec /path/to/my/program.

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.

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:

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.