The formula is quite simple yet efficient: 54 hours to bootstrap a startup. Participants are pitching the first evening, then the audience decides what projects they want to see come to life during the weekend, and finally, teams are formed out of this first session.

I came with the goal of not writing a line of code during this weekend because this is the kind of activity I could do alone when the kids are asleep. I came to pitch an idea, understand the mechanics of writing a business model and meet people.

Those three goals have been reached.

1. The Pitch: 60 seconds to convince people that my idea was awesome. I used to talk a lot in front of people (at previous jobs, at conferences, at meetups or small events like Code Retreats), so there was no stress doing it, but I kinda failed at explaining the vision in such a reduced timeframe.
2. The Business Model: I discovered a lot of tools (like the Lean Business Model Canvas). The tools alone are useless, and the mentoring from more experienced people in the team and from the mentors like Jerry Nieuviarts, from Clubic, or Thierry Boiron, from… Boiron (!), were more than welcome.
3. The People: From the participants to the mentors thru the organizers, the work environment was awesome. I was afraid by the spirit of competition, which often ruin the general atmosphere, but everything went just fine.

As a conclusion, I’m definitely going to participate in the next sessions, and probably not only in Lyon. I met good people, inspiring people, and the format of the event is perfect to engage one’s attention on a single thing: bootstrap a startup.

1

gem install activevalidators

Read on for the full - yet concise - changelog.

From its first versions, ActiveValidators has been designed to rely on the mail gem. The mail gem is at the foundation of action_mailer, and doing so reduced the chances of having emails validated by ActiveValidators and rejected by action_mailer or MTAs.

The EmailValidator can validate emails in the form user@domain.tld, but mail accepts any RFC-valid email address (1), like "User" <user@domain.tld>. Although that kind of format is correct, most apps want to only keep the user@domain.tld part and leave the rest.

Since this commit, the email validator now accepts an option to constraint a bit more the email validation:

1

validates :field_to_validate, :email => { :strict => true/false }

By default, strict is set to false and the mail gem validation will apply. When strict is set to true, only emails in the form user@domain.tld will be valid.

I’m wondering it would make sense to switch the default to true (I tend to prefer sensible defaults). Don’t hesitate to give an opinion on that and thanks for using ActiveValidators.

1. RFC 5321, RFC 5322 and RFC 5396.

While pair-reviewing some code with my colleague Vincent Tourraine, we realized we wrote this kind of code into each viewDidLoad: method of each NSViewController subclasses we created:

1

managedObjectContext = [[[UIApplication sharedApplication] delegate] managedObjectContext];

Doing so is more or less the same as using a global variable, as calling sharedApplication on UIApplication returns the singleton application instance. I kind of felt this was a code smell so I investigated.

After a couple of minute of browsing Apple’s documentation, here’s what we can read

A view controller typically **shouldn’t retrieve** the context from a global object
such as the application delegate. This tends to make the application
architecture rigid. […]
[…]
When you create a view controller, you pass it a context. […]

If you use the good old nib|xibs (I’m acting as if I was confident with them) and instantiate your controllers programmatically, this sounds dead easy, but what if you use the brand new shiny Storyboards?

The only solution I came up with, that will comply with Apple’s recommendation, is to use prepareForSegue, like this:

1
2
3
4
5
6
7
8
9
10

#import "MyMainController.h"
#import "MyOtherController.h"
@implementation MyMainController
-(void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {
    if([[segue identifier] isEqualToString:@"SegueToMyOtherController"]) {
        MyOtherController *controller = [segue destinationViewController];
        controller.managedObjectContext = managedObjectContext;
    }
}
@end

If your main controller doesn’t have any NSManagedObjectContext, you might want to inject it from within the method application:didFinishLaunchingWithOptions: of your AppDelegate, as you can see if you create a new CoreData project from the templates.

So next time, no more abuse of the sharedApplication !

1

gem install activevalidators

Read on for the full changelog.

Features:

• Thanks to Renato, the phone validator now supports multiple countries.
• date_validator 0.6.1

Fixes:

• Some misleading info in the README
• 1.9 compatibility in the test suite

During the last LyonRb meetup we read a quite large portion of Rake’s source code. The idea was to find an easy way to determine what file was defining/enhancing what task.

Richard and I just opened Rake 0.8.7’s source code (from our local machine’s RVM directory) and started hacking a bit to have that feature…

Two days after I can tell you that you won’t need to hack anything because it’s actually already implemented in Rake’s master since May 19th 2009 by Jim Weirich.

It wasn’t obvious to us as Rake 0.8.7 has been released on… May 15th 2009!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

~  cd /tmp && git clone git://github.com/jimweirich/rake.git && cd rake && rake gem && gem install pkg/rake-0.8.99.5.gem
Cloning into rake...
remote: Counting objects: 5804, done.
remote: Compressing objects: 100% (2489/2489), done.
remote: Total 5804 (delta 3387), reused 5519 (delta 3180)
Receiving objects: 100% (5804/5804), 1.23 MiB | 613 KiB/s, done.
Resolving deltas: 100% (3387/3387), done.
RCov is not available
ERROR: unknown action 'gemsets'
Successfully installed rake-0.8.99.5
1 gem installed

/tmp  cat >> foo.rb << EOF
heredoc> desc 'foo'
heredoc> task :foo do; end
heredoc> desc 'foobar'
heredoc> task :foobar do; end
heredoc> EOF

/tmp  cat >> baz.rb << EOF
heredoc> desc 'baz'
heredoc> task :baz do; end
heredoc> task 'foobaz'
heredoc> task :foobar do; end
heredoc> EOF

/tmp  cat >> Rakefile << EOF
heredoc> load 'foo.rb'
heredoc> load 'baz.rb'
heredoc> EOF

/tmp  rake -T
rake baz      # baz
rake foo      # foo
rake foobar   # foobar

/tmp  rake --where
rake baz                            baz.rb:2:in `<top (required)>'
rake foo                            foo.rb:2:in `<top (required)>'
rake foobar                         foo.rb:4:in `<top (required)>'
rake foobar                         baz.rb:4:in `<top (required)>'

Quatre nouvelles têtes: Marion, Michel, Vincent et Richard. Bienvenue à vous!

Les discussions se sont rapidement orientées sur le StartUp Weekend Lyon, où Vincent, JM, Pierre-Alexandre et Frédéric ont eu pour mission de faire un peu se prosélytisme :)

Côté technique, nous avons eu un peu de temps pour:

• Disséquer Rake afin de trouver un moyen simple pour retrouver où une tâche est définie
• Discuter RESTful API et l’utilisation de l’entête Accept pour effectuer le versioning.
• Philosopher sur les frameworks MVC comme ASP.NET MVC (beaucoup de respect pour Scott Guthrie et le travail de son équipe), Symfony.

Je n’ai pas réussi à parler de Seaside (Smalltalk)… je ne désespère pas!

Le livre “The Rails 3 Way” a été gagné par Camille par tirage au sort.

• Anthony Maréchal et Benoît Maréchal, fondateurs de WaluuTwins
• Cédric Fabianski, développeur Ruby et Rails chez Certilience

Mais également Laurent, Guillaume, Damien, Camille et une autre personne dont je ne me souviens plus du nom mais qui travaille chez LIM SAS.

Discussions intéressantes autour de:

• Capistrano
• Git
• Diaspora
• Metaprogramming Ruby
• Eager/lazy loading des associations dans Rails
• Projets pro de chacun
• etc…

Je n’ai pas pu faire mon lightening talk sur une des expérimentations que je suis en train de faire, ce sera pour la prochaine fois!

TL;DR Make sure you understand the data you need in your views, because manipulating directly ActiveRecord objects in your view is both powerful (follow associations, use model methods, etc.) and dangerous (N+1 problem). (and yes, this is a copy of the No Querying Views README because the blog was not broken at the time I published it)

This Rails3 plugin will tell you when you and your folks are querying the database from something else than a controller and a model.

It supports SQLite, SQLite3, MySQL, PostgreSQL and Mongoid.

Context

Rails is a MVC framework. The separation of concern should be respected to prevent bad things to happen in your application.

Example: An order has N order lines. Each of these order lines has 1 related item, and each of these items belongs to 1 category.

In Ruby code, your models would look like this:

app/models/order.rb

class Order < ActiveRecord::Base
  has_many :lines
end

app/models/line.rb

class Line < ActiveRecord::Base
  has_one :item
end

app/models/item.rb

class Item < ActiveRecord::Base
  belongs_to :category
end

app/models/category.rb

class Category < ActiveRecord::Base
end

Now, if you want to display them on a single page, here is a naive version of order_controller.rb:

app/controllers/order_controller.rb

class OrderController < ApplicationController
  def show
    @order = Order.find(params[:id])  # 1 query
  end
end

And a naive version of the views used to display the result:

app/views/orders/show.html.haml

%h1
  = @order.title
%h2
  %span Items
  %ul
    = render :partial => 'lines', :collection => order.lines   # 1 query, so far: 2 queries

app/views/orders/_lines.html.haml executed for each single line

%li
  %span
    = line.item.title          # 1 query
    = line.price
  %div{:class => 'item_description'}
    = line.item.description    # 0 query (cached)
    = line.item.category       # 1 query

The problem

If you use a tool that generates execution traces (like NewRelic RPM), you will see that - for 1 order, 40 lines, 30 items, 20 categories - you will execute: 1 (select * from order) + 1 (select * from lines inner join … where order_id = foo) + 40 (select * from items inner join … where line.item_id = bar) + 40 (select * from categories inner join … where item.category_id = baz)

82 queries against the database!

This is called the N + 1 problem and it can be solved by an eager-loading strategy.

## OH: “Yeah, but my database is so small and so fast that I don’t even see that!”

This is true if you are the only user of the website. But Rails will also have troubles generating the page (HAML, ERB, whatever) and NewRelic won’t tell you that the queries are slowing down the application: the queries are fast as hell.

The combination of the rendering and the querying is slowing down the application, because:

1. Rendering a partial is slower than inline code
2. Executing a query costs time (retrieving the DB connection within the pool, executing and fetching the results, …): the resources are not being used for free on your machine.

The solution

Silver bullets don’t exist, but most of the time you can speed up the performance by eager-loading the data you expect in your views.

From an architectural point of view, it is wrong to query the DB from a view. There are many reasons not to do so and the internet is full of literature about it.

Right now, here is a piece of code to help you remove any DB query from your views.

What does this code do?

It will raise an exception everytime you and your people try to query the database from within a view.

It only overrides the execute method of the adapter and checks the call stack.

Rails 3.x

ActiveRecord

Install

cd /my/rails/3/app_root/
wget http://github.com/cesario/no_querying_views/raw/master/no_querying_views.rb > config/initializers/no_querying_views.rb

Uninstall

cd /my/rails/3/app_root/
rm config/initializers/no_querying_views.rb

Mongoid

Install

cd /my/rails/3/app_root/
wget http://github.com/cesario/no_querying_views/raw/master/mongoid_no_querying_views.rb > config/initializers/mongoid_no_querying_views.rb

Uninstall

cd /my/rails/3/app_root/
rm config/initializers/no_querying_views.rb

Je pense qu’il s’agit du premier apéro qui réunit tant de personnes. Nous étions une bonne douzaine (14?), dont Philippe de retour du Canada, Guillaume et bien d’autres curieux qui rejoignent nos rangs.

Philippe a pu présenter ActiveAdmin, un projet assez intéressant qui permet de monter des interfaces d’administrations assez facilement, et qui fournit une DSL assez bien pensée.

Pierre-Alexandre a enfin pu présenter son clavier basé sur la disposition BEPO. Amis assujettis aux troubles musculosquelettiques…

J’ai pu converser avec une autre personne, venant elle du monde Python, qui a pour but d’ouvrir le code de son ORM (toujours écrit en Python) d’ici la fin d’année. Projet très prometteur.

Cet apéro a surtout pu parler de Rails 3 et des nouveautés de cette version, du nouveau routeur à Arel. La faible adoption de cette dernière version est dûe à la compatibilité encore faible des plugins/librairies existantes avec Rails 3 (et Ruby 1.9.2).

Prochaine édition ce 2 décembre. Toutes les informations pour s’y rendre: ici!

Pretty simple backend: everything is stored on Github so publicly accessible.

I also obtained a last-minute sponsoring from Engine Yard, but as I obtained the required info the night before the presentation, I only showed a little bit the interface but didn’t do anything real with it. Instead, I used Heroku and presented the 60-second deployment stuff. I think I made my point there: configuring servers and low-level stuff isn’t fun anymore, let’s put the application at the center of all.

So here’s my slides. Be kind with the layout and content, it was best seeing me (or anybody else talking :)) live than it’s gonna be reading it.

I haven’t had time to go thru the other presentation I prepared called “Ruby Software Architecture”, but I’ll do that during another event.

Anyhoo… I’m looking forward to the next “Apéro Ruby” now that the group is in motion!

They bring the modularity that made code more reusable and easily integrable in your current code base. They also prove that there no reason to say that Rails is not ready for the Enterprise. One quick tip for the party poopers (you know who you are ;)): JRuby makes things even easier for your development operations team members as it allows you to run your Ruby app (ie: Rails) within your favorite App Server (Websphere, Tomcat, you name them).

In this article, I will try to explain a little bit what are these new classes, how they were implemented and how to start using them.

If you want to see a live presentation of this, come and join us to the RubyCamp Lyon 2010 on April 17th.

The history: Merb + Rails = Rails 3

If you’re reading the gurus’ blogs, you may already know that Rails have had a major refactoring and decoupling phase done by the Rails Core Team (Yehuda Katz being the one doing the communication about it).

This gave birth to an AbstractController class, that reduced the tight-coupling between ActionController and ActionView, and lots of other cool stuff. But the real change comes down to the addition of the Railtie class. If you want to know more about how Rails 3 layers fit one onto another, I suggest your read Jeremy McAnally’s post “The Path to Rails 3 : Introduction”

Introducing Railties and Engines

Note: To clear any future confusion, we can safely state that an Engine is a Railtie (line 89 of rails3_beta_gem/lib/rails/engines.rb : class Engine < Railtie).

The major components of Rails, from Action View to Active Record thru Action Mailer and others, have their own Railtie inherited from Rails::Railtie. Each Railtie has its own initializers being triggered by the overall Rails boot process, its own generators, tasks, … It’s then up to the Rails::Application object to coordinate the boot process and sequentially ask each Railtie to initialize itself. De facto, this removes the tight coupling that we used to see in the previous versions of Rails.

A Rails::Application is also a Railtie, but a bit more: an Engine. An Engine is an extension (a derived class) of the Railtie class. Please do not think about Rails 3 Railtie as the old Rails 2.x engines plugin! Rails 3 Engines are core aspects of Rails. The noticeable difference between a Railtie and an Engine (as far as I investigated) is that an Engine:

• comes with a predefined set of initializers (locales, metals, view paths, etc.)
• has its own load_paths, eager_load_paths and load_once_paths (scoped to the current Engine)

Engines make it easy for anyone to modify or extend, à la Merb, any part of a Rails application out of the box - from the ORM to the rendering system - and for instance drop Active Record in favor of DataMapper or add an authentication system (like Devise).

Let’s understand how it all works

Each Rails 3 Application has now a file called config/application.rb, that defines MyAppName::Application:

1
2
3
4
5
6
7
8
9

require File.expand_path('../boot', __FILE__)
require 'rails/all'
Bundler.require(:default, Rails.env) if defined?(Bundler)

module MyAppName
    class Application < Rails::Application
        ....
    end
end

You can only have one instance of a Rails::Application at a time, it’s a singleton and it will always point to MyAppName::Application.instance. If we now have a look at the code that defines Rails::Application, we can see this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

require 'fileutils'
require 'rails/plugin'
require 'rails/engine'

class Application < Engine
    autoload :Bootstrap,      'rails/application/bootstrap'
    autoload :Configurable,   'rails/application/configurable'
    autoload :Configuration,  'rails/application/configuration'
    autoload :Finisher,       'rails/application/finisher'
    ... snip ....

    def initialize!
        run_initializers(self)
        self
    end
    ... snip ....

    def initializers
        initializers = Bootstrap.initializers_for(self)
        railties.all { |r| initializers += r.initializers }
        initializers += super
        initializers += Finisher.initializers_for(self)
        initializers
    end
    ... snip ....
end

Interesting! If you have a look at the Rails::Application::Bootstrap and Rails::Application::Finisher modules, they are including another module: Rails::Initializable, which is defining the Initializer class, finally defining the run_initalizers method we can see above.

So what does that mean at the end? Each of your Engine and Railtie will be able to hook into the boot process, right before the other initializers or right after. From the user (aka developer) perspective, it’s easy to use:

1
2
3
4
5
6
7
8
9
10
11
12

module MyModule
    class Railtie < Rails::Railtie
        # initialize before
        initializer "my_module.initialize_my_thingy", :before => "some_other_railtie.initialize_its_thingy" do
        ... some code
        end
        # initialize after
        initializer "my_module.initialize_my_other_thingy", :after => "some_other_railtie.initialize_its_other_thingy" do
        ... some code
        end
    end
end

Creating an Engine

If you want your engine to work within your application, you obviously have to put in the load path of it. You can do this by putting it your code just like you would do for a plugin: in your vendor/plugins directory. The basic structure looks like:

1
2
3
4
5
6

# vendor/plugins/my_gem/lib/engine.rb
module MyEngine
  class Engine < Rails::Engine
    engine_name :my_engine
  end
end

To use it in your Rails application, just update your Gemfile and simply put:

1

  gem "my_gem", :require => "my_engine"

By putting it in your Gemfile, and your Gemfile being used during the startup of your applicaiton, the initializers of your engine will automatically run, settings up the routes, loading the models, controllers, tasks, translations… that you may have defined in your Engine. Available paths are all pointing to a Rails-style folder name from the root folder of your engine (ie: paths.app.views will point to app/views):

• app.[controllers, helpers, models, metals, views, observers, …]
• lib
• lib.tasks
• config.[initializers, locales, routes]

To be continued…

You will find on The Modest Rubyist very neat tutorials on how to create your Engine from the ground up.

I will continue with a new article that will be the base of the talk I will give during the RubyCamp Lyon 2010 about enterprise Ruby-based software architecture.

He even shot a video about it:

So I guess it’s time for me to make Live-Note a real product by setting up a couple of tools like an issue tracker and a wiki (for the documentation).

Few figures I’m kinda proud of. Live-Note is today:

• 42 users
• 3700+ notes added to Google Wave. These waves/blips are completely yours, only you (and the robot) have access to it, so it’s entirely private.

Fatal: GCJ (GNU Compiler for Java) is not supported by JRuby.

Doing

export JAVA_HOME=/usr/lib/jvm/java-6-sun/jre

could do the trick, given you’ve installed sun-java6’s packages on your machine.

I hope it’ll help.

If you ever encountered this when installing JRuby on Ubuntu:

Fatal: GCJ (GNU Compiler for Java) is not supported by JRuby.

Doing

export JAVA_HOME=/usr/lib/jvm/java-6-sun/jre

could do the trick, given you’ve installed sun-java6’s packages on your machine. I hope it’ll help.

Moving our current projects codebase from Subversion to Git was a nice move. This plus the adoption of the feature-centric way of developing (BDD + Scrum + Kanban) and our repositories are now cleared of any form of waste (useless LOC written “just in case”).

Now, we must adapt the usage we have of Git and one that we just initiated is the non fast forward merge.

Cheap branches with Git are great and it’s a pleasure to work with them for both new implementations and quick experimentations. Behavior-Driven Development and agile methodologies don’t have to prove they work anymore: it’s just our only way of working now (which is IMHO good, not because I am responsible for its adoption, but because it actually works).

Being a small company we don’t have so many branches, except master (for the continuously integrated trunk) and few tags (for deployed or “soon-deployed-yet-to-be-optimized” versions). But it’s quite simple to dive into the workflow, fork any branch and merge it back when done (“done” meaning: tests are still turning green). For a longer feature, if breaking the implementation in smaller tasks wasn’t possible, it’s easy to merge often the master to the feature’s branch to avoid the big bang integration resulting from a branch too long away from its parent.

In one of our projects, we wanted to experiment two different ways of coding the same feature. Easy to do, easy to figure out what branch to keep and merge to the master branch. Having low activity on our codebase, Git merges are fast-forward merges.

From the Git documentation:

Fast-forward merges

1

[...] Normally, a merge results in a merge commit, with two parents, one pointing at each of the two lines of development that were merged.

However, if the current branch is a descendant of the other—so every commit present in the one is already contained in the other—then git just performs a “fast-forward”; the head of the current branch is moved forward to point at the head of the merged-in branch, without any new commits being created.

So when we merged back, Git just doesn’t care about the branch we created and pretend that it never existed and so we can’t see anywhere in the log we entered “git merge”. At that time, working on master would have had the exact same effect. If we ask to ourselves “did we create a branch for that?” a couple of weeks after the development, we can only assume we did (as that’s our only - allowed - way to work).

What’s happening now we would like to revert that feature? We must read all the history searching for the very first change involved in that feature (and as things are so perfectly aweful the commits are not only focusing on the feature we implemented, so we must alread read all the code changed) and revert changes carefully each one at a time…

So now, not only we do branches but also we do non fast forward merges to ensure we see the merge in the history.

1

git merge --no-ff

As a result, it’s now easy to spot what is the involved changeset, and also we can just revert the entire branch easily.

Google released the Google Wave Robot API v2 (hurray). In that major revision, they are introducing the Active Robot API that makes it possible for robots (i.e. GAE-baked applications) to interact with Waves. In the previous version, your robot was being notified each time a wave (or wavelet, or blip) was modified or when a participant was added to the wave, but now, your application can actually be active and contact Wave on its own.

In the first part of this series of articles, I was demonstrating how to build a GAE-baked application and how to subscribe to a web hook (being a Rubyist I was taking the webhooks from Gemcutter / Rubygems.org). I went only half-way as I wanted to actually see the result inside Google Wave. But then I think to my self, what a wonderful world think it would be to do something actually useful in my everyday life instead of just demonstrating mix of technologies (even if it’s neat to be able to make applications talk to each others).

So today, it’s gonna be about a 12-hour-design application: Live-Note.

When I first created “Gemhooker”:http://gemhooker.appspot.com, GAE was kinda new for me and I was learning all about it. Even understanding how to plug request handlers within a Google Robot application was hard. But after a lot of investigations, I was able to create in no-time an app able to understand 3 over the 5 communication mediums: email, chat and web app forms. The only missing forms of communications are voice and video.

And this app, is Live-Note. I tried to use “280slides”:http://www.280slides.com for this:

It’s still in beta, and is likely to stay as it is for a while because I won’t have anytime to update it in the future weeks/months, but you can already work with it. I tried to do something nice using IUI, that emulates the iPhone GUI, but I gotta admit I can improve that a little bit :)

To wrap up:

• First time use: http://live-note.appspot.com
• Then Chat with live-note@appspot.com
• Or Mail live-note@live-note.appspotmail.com
• Or Use the “web app”:http://live-note.appspot.com

And of course, feel free to give your feedback!

Edit: I fixed the chat username and email… sorry about that :)

Bringing the ActiveRecord backend to light, the I18n gem allows us now to manage all our translations in a regular database.

The I18n gem (required to run Rails 3) has been released in late December and is providing all you need to store your translations into a database. A neat thing is the I18n::Backend::Base module, which makes it easy to start writing a new backend in no time.

Today we’ll just configure our Rails 3 application to start storing our translations in our ActiveRecord-baked database.

First of all, let’s create a database table that will be used for the translations. Fire up a new migration and fill-in the blanks in self.up with:

1
2
3
4
5
6
7

create_table :translations do |t|
  t.string :locale
  t.string :key
  t.text   :value
  t.text   :interpolations
  t.boolean :is_proc, :default => false
end

This table is required by I18n, but its structure obviously evolve for your own needs. You should now also create a model in app/models/translation.rb:

1
2

class Translation < ActiveRecord::Base
end

Now you can migrate (rake db:migrate), open up your config/application.rb file and modify it to make it looks like this:

1
2
3
4
5
6
7

[...]
module YourApplicationName
  class Application < Rails::Application
  [...]
    I18n.backend = I18n::Backend::ActiveRecord.new
  [...]
end

Voilà! To start creating some translations you can open a Rails console and :

1

Translation.create!(:locale => "en", :key => "activerecord.models.user", :value => "my user")

[Edit: Feb 28th] : Cédric and Nicolas got it right: you’re gonna run into a lot of troubles if you hit the database each and every time you need a translation. A solution to that: caching. How to proceed? Just again your config/application.rb and add:

1
2
3
4

[...]
I18n.backend = I18n::Backend::ActiveRecord.new
I18n::Backend::ActiveRecord.send(:include, I18n::Backend::Cache)
I18n.cache_store = ActiveSupport::Cache.lookup_store(:memory_store) # or whatever store you prefer

Ain’t it great? :)

In this post, I’ll explain how to proceed.

That’s not the kind of thing you usually do and it’s actually during the implementation of an online boutique that made me hit the issue.

1. A matter of time in the beginning…

Some banks have unobtrusive systems. They give you a very detailed specification of how to build the form that will allow your visitor to connect to the payment gateway and also, how to verify after the payment processing whether or not the payment has been successful.

Some others require to execute a binary file (with a couple of special parameters and files that must be relative to the Rails’ app root) that will return the actual HTML form.

2. … and a matter of hidden technical debt at the end.

As one would imagine it’s easier to really on the second option, but it also means that your hosting platform is now tight-coupled to your application and in the cloud-oriented future that is ours, it seems like you’re building your own time bomb but you don’t really know when it’s gonna blow out.

In any case, you’re still gonna need to actually execute a program so the underlying hosting plateform must be known and your binary must run on it.

3. The right choice.

In fact the choice is not entirely yours when you rely on someone else’s binary, but hopefully some operating systems are more or less recognized as standards: Debian-based GNU/Linux distributions, Red Hat’s, and Windows.

Saying that everybody can just go for Heroku would be misleading, but their stack is 100% business standard and unmodified (understand: if it’s working in-house, it’s working in the cloud).

4. Executing a binary in Ruby

That was actually the reason we’re here. If you made that far it’s only because you wanted to run one, so let’s get going. To effectively call the program you can use different methods as:

5. Executing a binary in a Ruby application

I really prefer the @Open3.popen3@ call cause it gives access to the well-known standard Unix I/O. But they all work and you can pick any of these given your own requirements.

First of all, create a directory at the root of your Ruby application called @bin@ and add it to your git repository:

Let me emphasize the last sentence: you must put in the @bin@ directory at the root of your application and make it executable.

You already know how to call your executable (or you should read again the beginning of the post :)). So let’s embed it in your model but I won’t cover that topic as it’s quite framework-related and we’re not here to talk about frameworks.

6. Wrap up

• The @bin@ directory at the root of your application.
• The executable flags have to be set up.
• Any of the described way of executing a binary will work, pick your favorite.

Anyhoo… Tonight I wanted to talk to Gemcutter, but not programmatically, I wanted to have it in my GTalk contact list and start having a little chat…

The very first step was to fire up a new application in App Engine web panel. Five seconds later, let’s fired up a GVim and create (within a new directory) app.yml and gemtalker.py.

Let’s start with the app.yml:

~Mind the inbound_services declaration~

Now fill-in some code in your main python file:

As one would notice it’s pretty easy to play with XMPP services and actually, we need to know very few things here (as we don’t even handle user registration to secure application access, etc…): * It’s all in the request object; * Replying is a no-brainer.

Now we must interact with Gemcutter’s API to get some information (that was the purpose of this article actually…). I’m not a real Pythonista, so I didn’t know how to make this more readable/simpler but please, don’t hesitate to fork me hard on Github.

I must admin I wanted to use method_missing but it’s a… method missing in Python (I found a way to do it thought but that’s gonna be for later on).

So let’s wrap it up:

• Gemcutter’s library: done;
• XMPP library: ready;

So we’re up for wiring it up and writing the logic behind the application.

I’ll let read the draft implementation of all of this on Github , but it’s already up and running and you can invite gemtalker@appengine.com in Google Talk and use the ”info” command.

What’s mising: * Activate the AUTH command and store api keys only for the current session * Search a gem * Modify webhooks, owners, etc… (requires the AUTH to be done)

Have fun!

As mentioned in the documentation, let’s install gemcutter’s gem if not already done:

Now this is done, let’s get it started and fire up a new Python’s powered GAE app (gemhooker.py):

If you deploy this app (with appcfg.py update gemhooker-clone-you-just-initialized), you won’t see anything so let’s ask Gemcutter to add a webhook that will notice our app everytime someone pushes changes onto Gemcutter! I’m subscribing to every event of all the existing gems:

You can see the result on gemhooker.appspot.com.

Nick Quanranto has done it (and it looks good, really good job!) using Ruby and deployed it on Heroku.

I wish I could have done this with Ruby too but as I need to make it work with Wave (and it seems like a PITA to make Rails 2.x work on AppEngine), I’ll suffer till the end of this project :)

In part 2, I’ll explain how to make a Wave Gadget.