The value of a default argument in Ruby is the result of an executed expression. Most of the time the value is set to some object:

def int(i=1) i; end
def str(s="") s; end

Under normal usage, the fact that the value can be arbitrary code isn't immediately apparent. However, the value really can be any code:

def foo(a = puts("bar")); end

Furthermore, previous arguments can be referenced in the default argument expression:

def bar(a,b=a) puts "a: #{a} b: #{b}"; end

I wondered how far I could take this, and came up with the following method:

def fib(n, t = n < 2 ? n : fib(n-1) + fib(n-2)) t; end

Although it makes little sense to define methods this way, it does highlight the power of Ruby's default arguments.

docomo will launch a social network like service, docomo community (ドコモコミュニティ),  on March 2, 2009.  The service bills itself as a way to share photos and journal entries between friends and family members, and seems especially targeted at sharing between children and parents.  This is shrewd marketing on the part of docomo, who along with SoftBank and au introduced content filtering earlier this year, blocking sites in categories including SNS for all users under 18.  Perhaps in part to preempt others from crying foul, the site will not have any user search feature and to add a "friend" will require a user to input the other user's i-mode email address.  The service itself will be free (though normal packet charges apply), and be limited to users with FOMA handsets and above (non docomo handsets will not be supported).

(Hat tip: matsuiさん)

It's been a busy six weeks getting mobalean up and running. 

Incorporating in Japan is relatively easy and cheap. If you can speak Japanese and are able to register your seal (hanko), you can probably do this work yourself. The whole process took us about a month to complete. 

Apart from setting up the company, we've been pursuing development contracts and participating in community events. Since the beginning of the year, we've helped MoMo with their event organization, done system admin work for TLUG and gave a presentation at Ninjava. We intend to continue participating in these events and continue our work in the development community. 

As a development company, mobalean needs to keep learning and developing new technology. Sharing is part of this process, so we will post our findings and other experiences on this blog and also use the wiki for more technical details.

Cheers!

 

 

 

 

 

 

 

 

Last Thursday, I gave a presentation at Ninjava on mobile web development in Japan. Although Ninjava usually has about 20 attendees, this time it had over forty. As this was my first presentation since university, the large crowd was a little intimidating.

However, I think it served as a good opportunity to get the word out about mobalean, and particularly about our wiki for Japanese mobile development. As I mentioned during the presentation, there are not so many resources for mobile development in Japan, especially in English. Though our wiki is still in its infancy, I believe it will grow into a valuable resource over the coming months.

In addition, it was a chance to meet other mobile developers. In response to a question, we generated a simple page that allows you to see the headers for a request. This can be useful for debugging as the carriers often set special headers for mobile requests. To try it out, go to http://www.mobalean.com/tools/headers or use the following QR Code:

By the way, this QR Code was generated by the Google Chart API.

Thanks to everyone who attended the presentation, I hope you enjoyed it.  Our slides are available for download here.

If you're using git to manage your homepage / blog / little web application, it is relatively easy to add automatic deployment functionality to simplify your work flow. Deploying a new version can then be a simple git push!

For this article, I'll use a Ruby on Rails application as the example. It should be easy enough to adapt this approach to other situations. You can even do more complex actions such as compiling a deployment archive as long as no manual intervention is required.

Let's assume you want to install your RoR application in /srv/web/my_app, and you have a bare git repository on the same server, in /srv/gitosis/repositories/my_app.git. All you need to do is create a clone from the repository in the deployment location, adjust the permissions of the log and tmp directories, configure the database connection if required and then you are done.

Applying updates with git in such an environment is already simple: develop and test on your local machine, eventually push your changes to the server and finally pull the changes into the deployment directory. For example:

client $ git commit ...
client $ git push
client $ ssh server
server # cd /srv/web/my_app
server # git pull
server # touch tmp/restart.txt

This way, your local configuration is also protected by git and will be merged if possible (commit any local changes).

To further automate this, we can use the post-receive hook. In our example this is located at /srv/gitosis/repositories/my_app.git/hooks/post-receive. I have this hook call a script called update-rails.sh with the application name (my_app) as the parameter.

update-rails.sh looks like this:

#!/bin/sh
name=$1
if [ -z "$name" ] ; then
        echo "need to give name of checkout dir on command line"
        exit 1
fi

dir=/srv/web/$name
if [ ! -d $dir ] ; then
        echo "the directory $dir does not exist"
        exit 1
fi

cd $dir
env -i git pull
rake db:migrate
touch $dir/tmp/restart.txt

As you can see, this script will also run any required DB migrations.

Simple, isn't it?

A bit more on hosting git repositories:

I first tried to simply go with a shared directory on a server, i.e. a directory owned by a specific unix group, the group sticky bit switched on, and all users who are supposed to have access to the repository in that group. This works to some degree, but has some drawbacks as git does not auto-magically handle file permissions correctly. So on a system using a umask of 022 (which I guess is a majority of systems?), newly created files are not writable by the group, only by the user who created the files.

So I decided to go with gitosis, which not only eliminates the file permission problem, but is also a more flexible solution as it doesn't require an actual system user for everyone who is supposed to have access to your git repositories. Instead it relies on your user's ssh keys for authentication plus an ACL to determine read/write access to repositories.

There is already a good setup manual, so I won't repeat everything here. On a server running Debian Etch, it boils down to the following commands (make sure you have the backports repository installed):

# apt-get -t etch-backports install gitosis
# sudo -H -u gitosis gitosis-init < YOUR_PUBLIC_SSH_KEY

That is the setup work required on the server. Then you can clone gitosis' admin repository on your local system:

$ git clone gitosis@YOUR_SERVER_HOSTNAME:gitosis-admin.git

I'll again refer you to the setup manual on how to configure gitosis. Just one thing I stumbled over: When adding new users, make sure that you name the key files correctly. I forgot the .pub extension, and wondered why those users didn't get access...