Tech Blog

We switched to Git this morning. Before making this switch Gert-Jan (CTO of Floorplanner) asked me: “what is the advantage of Git over Subversion?”. I answered him and thought I’ll make a post of the answer as it can be useful for other bosses like Gert-Jan.

Since we started using Subversion, which was a couple of years ago, using a code versioning tool helped us a lot. We could work on Floorplanner with the whole team together without storing the “repository” on our remote FTP location (early days) or emailing changes up and forth (ancient times ). But when working with Subversion for some time, little things started to bother, i’ll sum them up:

1. We needed tutorials for creating a branch in SVN every time again
2. When merging the branch back, SVN didn’t know where that branch started.
3. When merging the branch back, each change was recorded back as the user who did the merge.

The consequences of these disadvantages.

We avoided creating branches.

Why is not creating branches bad practice?

I’ll give you an example. Sometimes when we were working on some big feature, we didn’t create a branch (it was a lot of work), we just committed it into the trunk when it was “kinda” ready. Then a sudden exception in the software that was online occurred, we now had a problem! That bug had to be fixed NOW, but the changes we just committed into the trunk were not fully tested and couldn’t go online. You understand this was a tedious process and resulted in more downtime sometimes.

But why is Git better?

1. Creating branches in Git is a lot easier than doing this in SVN.
2. Git keeps track where branches come from. So when creating a branch, merging back is very simple.
3. It keeps commit messages intact, when merging.

Conclusion

The whole point, remember this post is called “Git vs SVN for bosses”, branching is a joy in Git and this results in better being able to have access to different versions of the same software at the same time, which again results in being able to fix that bug NOW.

Other resources

http://git.or.cz/gitwiki/GitSvnComparsion

This week I was doing some work on a crossdomain JSON request. This was a pitty, because I had in mind, Ajax requests could be made between subdomains, but that wasn’t the case, therefore I had to come up with a solution.

Solution 1: Server-side proxy
One option we had, was a server-side proxy, but I didn’t like this solution. If you are proxying your crossdomain request through a webserver that has to handle a lot of requests per second, these requests can block other requests, because proxying is always a slow process.

Solution 2: JSONP
Then there is the JSONP method, which includes a script on the fly in the browser and this script is then evaluated. The problem however with this approach is that your JSON resources have to be rewritten as a evaluation. This evaluation is then executed and your JSON loaded in a variable.

Instead of:

{"somejsonobject":1}

you have to write:

var jsonobject = {"somejsonobject":1};
someCallback(jsonobject);

This is not very clean, because you have to decide in your remote JSON file what the variable will be named. JSONP is a method in which you give a variable and callback in the url and then the JSON will be rewritten. This solution is just not the right way, as we programmers all know why it is better to isolate logic from real data.

Solution 3: Crossdomain through flash
Then I looked at another solution that does crossdomain Ajax requests through a flash proxy. These solutions all gave a lot of problems, cause the encoding of characters was not handled properly by the Flash ExternalInterface compononent, which sended the JSON string it received to Javascript.

Solution 4: Parsing the JSON by flash
I then tried to make a solution myself that doesn’t send JSON string to Javascript, but (thanks for the idea Gert-Jan) sends the objects to Javascript. So the JSON is parsed into an object at the Actionscript side and it now all works. The project is opensourced under a MIT license and called: JSONCrossdomainRequest. It is a js file which includes a swf file in your page that can handle the requests. Please come over to GitHub and read more about how to install and use this project. The Actionscript project is also included. Good luck if you are going to use it and if you have any modifications let me know, it is a work in progress and we appreciate any help!

Project location:
http://github.com/japetheape/jsoncrossdomainrequest/tree/master

Last week we had to convert our existing Rails application, which uses Gettext to the new I18n API in combination with the SimpleBackend. I personally never liked Gettext, there was simply not enough control over translations as PO/MO files are not native ruby or at least can be easily accessed by Ruby (like YAML files).

We therefore decided to switch to the brand new, not even released, I18n API. But now we had a serious problem, our code base isn’t small and all that code had to be converted in some way. We could do it by hand, but hey, that’s a lot of work and especially very error-prone. Some convertor had to be written. Here it is as a rails plugin: GettextToI18n. 

What does the I18n convertor do?

It scrapes your whole application and searches for gettext calls, like this:

_("to be translated")

It will convert this gettext call to the newly I18n format: 

I18n.t :message_id

Then it builds up a big hash containing all the the translations. We decided it was handy to use the scopes that are introduced in the new I18n api. So it stores the translations in the following format: 

For models:

["model"]["model_name"]={:message_1 => "to be translated"}

For controller:

["controller"]["controller_name"]={:message_1 => "to be translated"}

After this hash of translations has been built up, the convertor writes it as a YAML file to:  config/locales/template.yml.That’s all!

What’s supported?

It supports basic gettext calls. We have run it over our code base and it converts all gettext calls we use without any problem. 

A normal gettext call

_("to be translated")

converts to:

I18n.t :message_0, :scope => [:txt, :controller, :controller_name])

A gettext call with variables

_("My name is %{name}" % {:name => "Jaap"})

converts to:

I18n.t :message_0, :name => "Jaap", :scope => [:txt, :controller, :controller_name])

A gettext call with variables that contain gettext calls

_("Click %{link} to go to the homepage" % {:link => link_to(_("Here"), root_path)})

converts to:

I18n.t :message_0, :link => link_to(I18n.t(:message_1, :scope => [:txt, :controller, :controller_name]), root_path), :scope => [:txt, :controller, :controller_name])

Installation

./script/plugin install git://github.com/japetheape/gettext_to_i18n.git

Usage

To convert your application:
rake gettext_to_i18n:transform

Please make sure you backup your complete application as it can screw things up.

Contribution

Please contribute to this plugin and make it better, as I won’t use it anymore, cause we are not going to convert another time (I think ). Things that has to be done are:

unnamed variables:

_("I play the %s" % "saxophone")

Go to the development location at github and fork this plugin!

Today I setup the first version of a RAPIDoc, a Rest API Rails Documentation Generator and we decided to open source this thing, from now on let’s call it RAPIDoc. It is a API code generator for Rails, describing your Rest resources. We we’re looking for a way to fully integrate documentation of our API into the code base, like Rdoc does. Rdoc didn’t suit our needs, cause it has got nothing to do with Rest and resource stuff, so we decided to hack something together and gave it a name: RAPIDoc.

What does it do?
It generates a API controller containing documenation maked up in a special language. It parses controllers you specify, and generates a ApiController with appropriate views for it. This makes it very easy to document a Rest API. For methods you use, and according to ERB templates you specify it generates the views for you. It doesn’t parse your routes.rb, it was not needed for us, but may be a nice extension for it.

Well how is that RAPI doc looking? Put this in front of a Restful method.

1
2
3
4
5
6
7
8
9
10
11

=begin rapidoc
url:: /projects
method:: GET
access:: FREE
return:: [JSON|XML] - some project
param:: page:int - the page
param:: per_page:int - max items per page
 
Get a list of projects. This method uses pagination. If you want to retreive project 1-10 for example:
/projects?page=1&per_page=10.
=end

For each resource you specify, a view is created and it is put into the index.

Opensource
It is available from now on on:

http://code.google.com/p/rapidoc/

If you find it useful and you want to change some things, become a submitter. Ow yeah, just a note: really experimental code

As Facebook is probably the most viral socal application out there, we couldn’t stay behind. We developed for Tjoon a Facebook application, this weekend. This application is like the normal website, but with the extension that you can show your recorded videos to all of your Facebook friends and you can also see what your friends recorded.

As you maybe know, we developed Tjoon as a fun project. You can create split screen videos with it. We hope you will like the new addition to Tjoon, the Facebook Tjoon. Here your can install the Tjoon application.

Jamming is always on our mind, we thought, why can’t we jam online? Therefore, we created a site called Tjoon.com. At Tjoon.com you can record split screen videos. Maybe you have seen such videos on YouTube. You need special video edit software, to create these splitscreen jams, but now there’s Tjoon! The only thing you have to do to make a video is plugin your webcam, go to the site and start recording. After that other people see your Tjoon with 1 track, and they can add another track, up to 4 tracks.

Tjoon is a fun project, we did it in our spare time. We had a lot of fun when Wobbo did his funny moves, Nico his burbs and Jeroen his great guitar solo’s. Well check it out and spread the word! Here is a little example of the Tjoon widget. Have fun.

Technically speaking Tjoon is a combination of Ruby on Rails and as media server Red 5, for if you wanted to know

http://www.tjoon.com/

Localization is easy with Gettext and Ruby on Rails. In this tutorial I’m going to describe from top which steps are needed to install gettext in your Rails application. We shall start with an empty Rails application and add Gettext to it.

Read the rest of this entry »

Today we started the development of a Rails API. The first thing we had to do was defining a cast from a model to a Struct, cause we didn’t want the API to send all the fields we have in some tables.
In the rails documentation I could only find that it was possible to hide fields from your models, but not how. This is how we did it. We included the defined the models as a base class ActionWebService::Struct within our Api class. Example:

Let’s say you have a model User (who doesn’t) which has as base class ActiceRecord::Base. Now we want to only show, let’s say the field email.
This is our API for now:

class SomeApi < ActionWebService::API::Base
class User < ActionWebService::Struct
member :email, :string
end
 
api_method :get_user,
:returns => [User]
 
end

Now the User model with 20 fields will only be casted through a Struct and sent through the webservice with only the field email. That’s what we wanted!

Last week I decided to tune the performance of our Rails applications, because I had suspicions the app performed not at it’s best.
I installed a fresh Rails application and started the simple script/server -e production. I did the command: ab -c 5 -n 1000 http://localhost:3000/ and found out that we had only 396 requests per second. On my own, slower laptop, I had 500 requests per second for a test app of the same Rails version. Why o why?

Decided to take a look at the Gems. I saw that Gem installed a new version on top of an old version, when I updated. These old versions were still used in our production application, while these new versions were installed! You can specify your GEM version in the Rails app, but if you haven’t done this, Rails will apparently take the oldest version. After removing these old versions I benchmarked the server again, and now 560 request per second, ow yeah!

So an advice to all of you, figuring out why rails doesn’t perform at it’s best: update your gems AND remove the old versions. Now we updated our real applications and they are running lots faster.

When you try to submit a form from Javascript, using form_remote_tag, like this:

Rails:

form_remote_tag :url => {:controller => "somecontroller", :action => "} , :html => {:id => "ajax-form-1">

If you just invoke form.submit(), like this:

var form = document.getElementById('ajax-form-1');
if(form)
   form.submit();

the form will be submitted to a new page, that’s not soo ajaxy you now think. Instead use:

var form = document.getElementById('ajax-form-1');<br />
if(form.onsubmit()){
   form.submit();
}

Now your form will be submitted on the AJAX way!