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.

Contractors

Cleve Lendon is a Canadian engineer who has been contracting for Mobalean. 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. Mobalean started when the smartphones were just appearing on the market.
Our Keitai Web Technology Guide
is a quick starting point for learning about the initial challenges of Japanese mobile development. Although the technology stacks have changed since the proliferation of iOS and Android, some of the idiosyncrasies remain. Most notably, the Japanese market is still very much dominated by the big three carriers: DoCoMo, au and Softbank.
Developers can find more technical details in our Keitai-Dev Wiki.

Call us

Asset Pipeline for Clojure

At Mobalean, we do a lot of Ruby on Rails web development. Recently, we've become interested in Clojure (a Lisp-like language), and the Clojure libraries which support web development, such as Ring, Compojure, etc. We wanted to implement an 'asset pipeline' for Clojure, similar to that which the sprockets-rails gem provides for Rails. We decided to roll our own.

'Assets' are the images, Javascript files, and style sheets (css) which make up a web application. The goal of an asset pipeline is to decrease the time needed to load web pages. Rails' asset pipeline uses several techniques to achieve this, which are explained here briefly.

There is overhead involved in fetching files over the internet; the more files to fetch, the slower a page will load. Some kinds of files can be concatenated. If the contents of four Javascript files are concatenated into one file, a web client will only need to fetch once to get the contents of all four. CSS files can also be concatenated.

Large files take longer to load than small ones. A Javascript file with comments and unnecessary whitespace removed is significantly smaller than the original source. The process of removing comments and whitespace is called 'minification'.

Another technique to increase speed is caching. A cache is a storage area which can be accessed quickly. When a file is first fetched from a server, it is copied into a cache. Next time that file is requested, it is retrieved from the cache, instead of the original server. There are various caching strategies; the user's own computer or ISP might cache files. A popular technique is to use Content Distribution Networks.

Content Distribution Networks

A CDN is a network of servers which are optimized to provide content quickly, by minimizing the number of network hops required to fetch it. We use Amazon's CloudFront service, as explained below.

Using the Amazon Web Services' Management Console, we created a 'CloudFront Distribution', which relates our company's domain name, www.mobalean.com, to a CloudFront URL, d1z08j3q0h3g1y.cloudfront.net .

Consider this image tag:

<img src="/img/klivo-001.jpg">

We append the CloudFront URL to the path:

<img src="http://d1z08j3q0h3g1y.cloudfront.net/img/klivo-001.jpg">

When a web client makes the first fetch request for this image, CloudFront determines that it doesn't have it; CloudFront will fetch the image from our server, cache it, and deliver it to the requesting client. For subsequent requests, CloudFront will deliver the image from its cache.

What if we change the image on our server? We might decide that the image is too large, and make a smaller version. If we use the same image filename, CloudFront will continue to deliver the old cached image. A technique called 'fingerprinting' is commonly used to solve this problem.

Fingerprinting

To fingerprint a file, we generate an MD5 hash code, which is based on the contents of the file; next we copy the file into a public assets folder, with the hash code included in its filename.

For example, the hash code for klivo-001.jpg is85d91d1c49f0e76c9f449248936a0f85.
The new filename becomes:

klivo-001-85d91d1c49f0e76c9f449248936a0f85.jpg

We copy this file into the public assets folder (under img). Our image tag now becomes:

When we change the contents of an image file, we need to regenerate its hash code and copy the new fingerprinted file to the public asset folder. The new URL will force CloudFront to fetch the image and cache it.

The top level asset folder is for source files. The asset folder under public contains the concatenated and fingerprinted asset files. For example, we moved klivo-001.jpg from the folder public/img to the source asset folder assets/img. Our asset generation program (GenerateAssets) sees this file and creates klivo-001-85d91d1c49f0e76c9f449248936a0f85.jpg
under public/assets/img .

Generate Assets

We wrote GenerateAssets in Java (1.7). (You can find the source at Github.)
GenerateAssets is called whenever we do a deploy. It does the following:

Text between the template asset tags, {{#asset}} and {{/asset}}, is passed to #(asset-filename %) . This is an anonymous function which takes a parameter and calls asset-filename.

The function asset-filename uses asset-map (read from assets.txt) to convert original filenames to the fingerprinted names. The CloudFront URL is read as an environment variable and appended on the front