We ♥ web applications!
At mobalean we love to build innovative web services for Japan and the world. Our experience will help transform your ideas into successful online services.
At mobalean we love to build innovative web services for Japan and the world. Our experience will help transform your ideas into successful online services.
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.
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 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.
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.
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.
Email address: info@mobalean.com
If you prefer to call us, feel free to do so under +81 (0)70-6251-7245
For users of Skype, please call mobalean
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.
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.
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
is
85d91d1c49f0e76c9f449248936a0f85
.
The new filename becomes:
klivo-001-85d91d1c49f0e76c9f449248936a0f85.jpgWe copy this file into the public assets folder (under img). Our image tag now becomes:
<img src="http://d1z08j3q0h3g1y.cloudfront.net/assets/img/klivo-001-85d91d1c49f0e76c9f449248936a0f85.jpg">
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.
Originally, we had three folders under 'public':
public -- css -- img -- js
To implement our asset pipeline, we added a couple asset folders.
assets -- css -- img -- js public -- css -- img -- js -- assets -- css -- img -- js
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 .
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:
The file assets.txt
contains a Clojure map, which maps original file names to fingerprinted file names. Exempli gratia:
{ "/css/assets.css" "/css/assets-ff532fc647635d3ebb8f1b929ac28026.css" "/img/mobalean_top4.png" "/img/mobalean_top4-7526f5c70858044d259434bdfdc75ba9.png" "/img/klivo-001.jpg" "/img/klivo-001-85d91d1c49f0e76c9f449248936a0f85.jpg" "/js/assets.js" "/js/assets-0d59832f2151666e8bafd20082214da3.js" }
GenerateAssets gives us a folder full of assets, and a file which lists them. The next step is to insert links to these CloudFronted fingerprinted assets into our HTML content.
Our template system is Clostache, which is a Clojure version of Mustache. In our template file, index.mustache, we put tags around our assets. This image tag:
<img src="/img/klivo-001.jpg">
becomes
<img src="{{#asset}}/img/klivo-001.jpg{{/asset}}">
In our web application (core.clj), we render the template thusly:
(defn read-template [template-name] (slurp (io/resource (str "templates/" template-name ".mustache")))) (defn render-template [template-file params] (clostache/render (read-template template-file) params)) (render-template "index" { :asset #(asset-filename %) :other-tags other-data } )
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
(def asset-map (read-string (slurp "resources/assets/assets.txt" :encoding "UTF-8"))) (defn asset-filename "Get an asset filename (filename with MD5 hash)." [filename] (let [cf (or (System/getenv "CLOUDFRONT") "") fn (asset-map filename)] (if fn (str cf "/assets" fn) filename) ) )
For example, if /img/klivo-001.jpg
is listed in assets.txt
, asset-filename
will return:
d1z08j3q0h3g1y.cloudfront.net/assets/img/klivo-001-85d91d1c49f0e76c9f449248936a0f85.jpg
If not, asset-filename will return the original name, /img/klivo-001.jpg
.
Of course, we run GenerateAssets at the top of our deploy script:
javac GenerateAssets.java java GenerateAssets
If you have any comments or suggestions, please contact us.