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.

Call us

Upgrading Ruby, 1.8 to 2.3

One of our projects is an upgrade of old Ruby code (version 1.8.6, 2007) to modern Ruby. It's a fairly large, non-rails project that has been developed for the Japanese market during many years.
This article discusses the main issues we came across. Perhaps it will be useful to others who need to do the same. The reader should be familiar with Ruby, and tools such as irb.

$KCODE / encoding

One of the biggest changes since version 1.8 is the way in which character encodings are handled.

In Ruby 1.8, a String has no intrinsic character encoding; it's handled as a sequence of bytes. The global variable $KCODE is used to define the default encoding for regular expression matching. We usually see $KCODE set at the top of a file:

$KCODE='UTF8'

Valid values are 'UTF8', 'SJIS', 'EUC' and 'NONE', but the first letter of the encoding is sufficient.

$KCODE was deprecated in Ruby 1.9 (2007), so we removed it from the code.

Since Ruby 1.9, 'encoding' has become an attribute of the String class, and the default encoding is UTF-8, as God intended.

"Hi".encoding
=> #<Encoding:UTF-8>

When we run old code under Ruby 2.3, Strings which previously had no encoding become UTF-8 by default. This causes encoding errors if the string is actually a Shift JIS string. We can correct this using the 'force_encoding' method.

new_string = some_string.force_encoding('SJIS')

'force_encoding' doesn't change the characters in the string. It simply sets the 'encoding' attribute.

Iconv

In our legacy code, the gem 'iconv' is often used to convert between character encodings. The example below converts the text 'コメント' from UTF-8 to Shift JIS.

id / object_id

Every Ruby object has a unique identifier. In Ruby 1.8 this was Object#id, but 'id' was later deprecated and replaced with 'object_id'. The compiler prints out deprecation warnings, so this shouldn't be hard to fix, but as Captian Hunt always says, "It's never easy."

There is a technique for creating test cases called 'mocking'. If we have a class X, which we want to test, and class X processes data which it gets from class Y, we can 'mock' class Y. That is, we create a class which looks like Y, but returns values which we define for our test.

There are libraries which facilitate this. Some of our legacy code used Test-Unit-Mock, which was written before object_id existed. Test-Unit-Mock treated Object#object_id as an ordinary method, and 'mocked' it, which caused problems for some of our test cases.

Circular Requires

'Circular requires' occur when a Ruby file 'requires' files which in turn require the original file. For example, consider a file called Parent.rb, containing a class called Parent. There are child classes, ChildA, ChildB etc., which refer to Parent, because they are descended from it:

require './Parent'
class ChildA < Parent

If the Parent file requires the child classes, for example:

class Parent
...
end
Dir.glob("#{File.dirname(__FILE__)}/Child*.rb").each do |file|
require file
end

...then you have circular requires.

Ruby 1.8 gives no warning of circular requires, but later versions do, if warnings are enabled (with the -w flag):

The Parent/Child example shown above is artificial; it seems unlikely that a developer would intentionally write such code. But in large, complex systems, which have evolved over a number of years, the relationships between classes can become obscurred. Developers put in circular requires unintentionally.

When we started running our old source under 2.3, with warnings enabled as they should be, a *lot* of circular requires popped up.

Cleaning up these warnings was sometimes easy, and sometimes very difficult. In some cases we could just delete an unnecessary require. In other cases we had to refactor a file. Splitting a single file into two separate files, with different requires, sometimes solved the problem. A few times, with very tangled code, we used the c-header method of defining a variable and checking it for require'ing like this:

require 'BaseDBClass' unless defined?(BASEDBCLASS)

I hope this article has been helpful to those who need to modernize ancient code.