// TODO: come up with witty tagline

TL;DR: testing works, I learned i18n, and fixed a bug through TDD.

After writing a simple little functional test and making it run through rake test, albeit slowly, I installed Spork and autotest. From what I gathered, Spork is an RSpec-only thing, so I wrote a few RSpec tests instead of functional tests. After a bit of tweaking, everything was going smoothly between Spork and autotest, all running RSpec, but my file in test/ was ignored. Moving on.

I fixed the bug causing a 500 error when an empty string was entered on the main screen, by writing the following spec:

it "should not render en empty request" do
  get :address, :q => ""
  response.should_not render_template("address")
  response.should redirect_to("/")
end

Which was red, then green (yay!). I once read that TDD introduced a “strange smoothing feeling” (paraphrasing), which is definitely true: seeing automated tests pass contributes quite a lot to one’s peace of mind.

I also used the flash hash to flash a notification that the address was invalid. Actually making the notice “flash” (i.e. appear and disappear) took a bit of jQuery (nothing fancy, but still!).

Moving on, my next goal was i18n (internationalisation), to make my website switch automatically from English to French depending on the browser’s HTTP Accept-language header. After a quick read of the official website’s own guide on i18n (excellent as usual), I modified the files as needed (just noticed I didn’t split up my locale files, which maybe I should have done) and set out to find how to change the language depending on the HTTP header.

Apparently this isn’t “the Rails way”, because it isn’t RESTful; two request to the same URL won’t give back the same result depending on the browser’s configured language. Instead, Rails recommends either 1) an explicit ?locale= parameter in the URL, 2) modifying the routing scheme from, say, /page to /en/page and /fr/page, or even 3) using two separate domains, e.g. myapp.com and myapp.fr. I’m not really fond of the first solution, the second one is okay but should be thought out from the start, and the third one is great but doesn’t fit my needs here. HTTP headers it is.

Thankfully, the http-accept-language gem allows you to easily find the best match between which language(s) the browser demands and which language(s) you can provide. Changing the locale according to this data was a simple before_filter away in the ApplicationController. I used the debugger and curl commands (the -H option allows writing custom headers) to make sure everything was working correctly.

I went back to Spork after a while, not exactly understanding why autotest wasn’t doing the same thing as rake test. If I understand correctly, it looks like autotest runs either rspec or test::unit (which doesn’t only cover unit tests, but also functional tests, etc, as long as they’re under test/), and that Spork being RSpec-only, autotest+Spork only worked with RSpec. After some more research, Spork actually supports test::unit… As a separate gem, spork-testunit. And those two are completely separated: they don’t listen on the same port and are called by completely different commands (respectively rspec spec and testdrb).

A quite hackish workaround is to start two different Spork servers with bin/spork TestUnit & bin/spork RSpec, and to add hooks to autotest to launch Unit::Tests too in the .autotest file. It means Test::Unit is only launched after some specs needed re-testing instead of the traditional “a file change, it runs tests”, but it still works.

Now, I guess the problem is that a project won’t need to have testing done both in RSpec and in Test::Unit. I could be wrong about that, but it seems that the goals and end results of both framework are pretty similar.

With all that testing, I didn’t have time to implement my country-wide search, which I hope to do tomorrow for this week’s final day.

TL;DR: polishing. Trying to get into TDD, but slowness makes it a strange experience.

This “day 5″ has been more or less spread over two days because of other engagements (mowing the lawn and subscribing an insurance policy for abroad if you wish to know the details), and I didn’t keep precise tracks of the steps I took.

The major milestone is that the MVP for Antipodes is online at http://antipodes.plui.es (and has its own repo on GitHub). I threw away all of the first rails project and restarted from a clean slate, then roughly followed the same steps again (Bundler, Capistrano, etc) and added back the logic. I also polished the whole thing: instead of manually entering the request in the URL (eh, it was a prototype…), there’s a form and everything. There’s even a purdy logo!

Back to some more Rails-y stuff: I tried to start working on some Test-Driven Development, but at over 30 seconds per test round with a single assert true, I couldn’t really get into any sort of good flow. autotest manages to run the tests in around 20 seconds (and more importantly in the background), but it’s still way too much. I just noticed that Spork might be a good solution, I will try it tomorrow.

Once the tests are automated and fast enough, I will start bugfixing (for example right now an empty chain results in a 500 error) and adding another new functionality: whole countries!

TL;DR: it deploys! Finally!

After a full day spend battling cryptic error messages, I finally got my 10-lines Rails app to deploy.

First thing in the morning, I decided to switch to using rvm on my production machine too, in order to have the same setup and version on Ruby (1.9.2) for testing and production. This meant also reinstalling the important gems (bundler, rails, rake).

The production machine uses nginx+Passenger, which I reinstalled (following instructions here) in order to work smoothly with this now rvm-ed ruby.

The first problems I ran into were Capistrano issues. For some reason, the git repository for the rails project (the one I also put on GitHub) wasn’t the base rails folder, but merely contained all of rails under /sample/. Capistrano didn’t like that at all: it relies on having the standard Rails architecture available at root level.

For example, in order to run bundler on the remote machine during deployment, Capistrano looks for the Gemfile and Gemfile.lock (possibly only the Gemfile.lock) in the base folder of the git repo. My Gemfile wasn’t in /Gemfile, but in /sample/Gemfile. A setting exists to tell Capistrano where to look for the Gemfile, but it then breaks in other subtle ways (notably during the migrations). I changed the structure so that all of the rails things appear at the root of the git repo (i.e. the Right Way), and Capistrano bundled gems like a champ.

Another problem was nginx configuration. In order to follow Capistrano’s model, nginx ‘server’ directive must look something like:

	server {
		listen 80;
		server_name (server name);
		root /(capistrano's deploy_to in deploy.rb)/current/public/;
		passenger_enabled on;
	}

Yesterday night, it was set up at (capistrano’s deploy_to)/current/sample/public/, because of the peculiar directory structure. That’s what caused the 403 forbidden: Passenger had no idea what was there, because Capistrano couldn’t understand it either and deploy correctly.

Once all of this was straightened up, I switched from nginx error messages to Passenger error messages, which was a good thing (getting closer to Rails!). The first few ones were gems that couldn’t be found due to a missing lines in the Gemfile and commented out line in deploy.rb. Then, a notice that rake was missing despite it being included in the Gemfile and correctly bundled (I saw it being bundled, I swear!): it turned out that Bundler was using the production machine’s ruby 1.8 to create his bundle when he should have been using rvm’s 1.9.2. A few more lines in deploy.rb. The last error was that the database didn’t exist. Indeed, when running a `cap deploy:update`, the whole directory was swiped out and replaced by the latest revision in Git, and Git excludes the database by default (which is sensible). `cap deploy:migrations` is the way to go to recreate you SQLite3 database in production.

After all of this, Capistrano seemed to deploy without any trouble, the gems were correctly bundled, and loading the app in a browser went to… Suspense… An error message. But a Rails one this time, which is still a Good Thing.

Going through nginx production logs showed this message:

ActionView::Template::Error (gmaps4rails.css isn't precompiled):
    1: <% #thanks to enable_css, user can avoid this css to be loaded
    2: if enable_css == true and options[:scripts].nil? %>
    3:     <% content_for :head do %>
    4:     <%= stylesheet_link_tag 'gmaps4rails' %>
    5:     <% end %>
    6: <% end %>
    7: <% content_for :scripts do %>
  app/views/antipodes_one/show.html.erb:5:in `_app_views_antipodes_one_show_html_erb___4541095793564774527_30741960'

And here began my journey though the magical world of Rails 3.1 Brand New Asset Pipeline.

The asset pipeline is a great idea implemented in a weird way that breaks things. The more I learn about rails, the more it seems like that’s the standard modus operandi of the community: move fast, don’t worry if it breaks ancient stuff (“ancient” being loosely defined as “more than a year old”). The biggest problem of this approach is the constant learning it implies, and the fact that a lot of the tutorials or workarounds you find with a quick googling will be out of date or broken. I guess that’s the price to pay for the constant innovation going on in the Ruby world. Ah, well, software philosophy.

Anyways, Rails’ new Asset Pipeline’s job is to interpret, downsize and concatenate coffeescript and scss files into static files ready to be served — a step referred to as “precompilation” — in order to facilitate caching and reduce load times. Precompilation can either be done during deployment, e.g. as a Capistrano hook (“recipe” if I understand the lingo), or before deploying entirely, through a rake task: `RAILS_ENV=production bundle exec rake assets:precompile` — you’ll then add those new files to source control and they’ll be transferred during the standard Capistrano deploy phase. You can even skip the precompilation phase entirely and set a config switch in application.rb telling rails to compile the assets on-the-fly at runtime.

None of those options worked. gmaps4rails.css stubbornly stayed uncompiled.

After a fair amount of time being stuck on this issue (notably because each precompiling takes 30 seconds for a handful of files), I found an answer on StackOverflow: adding `config.assets.precompile += ['gmaps4rails.css']` in application.rb managed to convince Rails to precompile that file too.

A quick (sorta) precompiling, git add && push and Capistrano deploy later, everything finally came together and worked. Phew!

Goals for tomorrow: stop worrying about deployment and go deeper in pure Rails code. Add some custom CSS, more logic, and get some tests up and running.

TL;DR: phew. Deployment is hard. Testing is slow.

Morning: off due to World Cup; watching of the match against New Zealand. :(

Afternoon: while playing a bit more with the prototype, I noticed the logic is actually broken and my way to calculate an antipode was actually broken. This came from the fact that the longitude and latitude coordinates aren’t logically the same. Latitude divides the globe on its equator while longitude is arbitrarily positioned… I guess? It doesn’t really make sense; considering it’s a sphere, any division is arbitrary. Anyways, that’s how the coordinates system work: to get to the other side of the globe, you just have to change the sign of the latitude, and either add or substract 180° to the longitude depending on whether it’s negative or positive.

A foray into testing: I began investigating RSpec, who doesn’t seem to work on my two pages (because of the custom routes ?). To add insult to injury, that’s how long it takes to test one spec:

vagrant@vagrant-debian-squeeze:/rails/sample$ time bundle exec rspec spec/
F

Failures:

1) AntipodesOneController GET ‘/a/washington’ should be successful
Failure/Error: get ‘/a/washington’
ActionController::RoutingError:
No route matches {:controller=>”antipodes_one”, :action=>”/a/washington”}
# ./spec/controllers/antipodes_one_controller_spec.rb:7:in `block (3 levels) in <top (required)>’

Finished in 0.10063 seconds
1 example, 1 failure

Failed examples:

rspec ./spec/controllers/antipodes_one_controller_spec.rb:6 # AntipodesOneController GET ‘/a/washington’ should be successful

real    0m26.167s
user    0m13.769s
sys    0m5.716s

I’ll get back to that later then, and focus and deployment. And oh, wow.

I feel like I’m not learning Rails, but merely fighting my way through Builder and Capistrano, their total integration with Git, and the stupidly complex overhead introduced by developing on a VM. But after a day and a bit of a night of tinkering and googling four different successive Capistrano error messages, it looks like deployment to my VPS finally works! Although it still doesn’t work; passenger gives a 403 forbidden error message. I hope to make some progress tomorrow…

TL;DR: I have a terribly ugly first draft of the application working!

Day 0 — Day 1

Morning: spent finishing reading the Getting Started guide and beginning the Rails Tutorial.

Afternoon: so, let’s get down to maps…
What’s cool in Rails is that there are plenty of gems, and you just have to plug them in, right?

GoogleMapsForRails seems like the right tool for the job.

After trying to get my posts to be geolocalized… Success! It took some time to get a marker on the maps, because I thought the locations were created on-the-fly by a geocoding of the address returned by the model, when it actually just fishes the database for the lat/lng data. I had to display the json sent by the controller in rails to confirm that nothing was sent, then add a dummy post in the db with some lat/lng data.

So it seems that geocoding (the process of finding lat/lng coordinates from a string, e.g. “main street, san francisco” => [37.790621,-122.393355]) isn’t done by GoogleMapsForRails. What shall I use? Googling suggests Geokit, but separating the gem from its Rails counterpart sounds strange to me. And apparently it doesn’t work for Rails 3. Some more research, and the Geocoder gem turns up: looks good!

Some more time working with the bolts and nuts… And ta-dah! A first version is working.

The code is up on Github. To get the desired results:

http://localhost:3000/a/washington gives a straightforward geocoding for “washington” and displays it on a map.

http://localhost:3000/b/washington finds the opposite coordinates (i.e. the antipodes) and displays it on a map.

Coming up tomorrow: making things pretty, *testing*, then deploying.