Rails in a week — day 4

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.

Rails in a week — day 3

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…

Rails in a week — day 2

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.

Rails in a week — day 1

TL;DR: I began learning Rails this morning, and even though Rails in itself is (seems?) easy enough, setting everything up and deploying is hairier.

 

8:00: let’s get started! First step: getting vagrant up and running. We’ll hit the tutorial.
8:15: the lucid32 “box”, Vagrant’s parlance for a virtual machine image, is downloading. Time to get a cup of coffee.
8:40: box downloaded, let’s get on with the VM setup process. `vagrant ssh`… Yep, it works!
8:50: adding a few cookbooks. The Vagrantfile syntax (which is actually Ruby) isn’t recognized by vim; to fix that later.
9:00: first oops of the day:

[09:00:38] florent@Air:~ $ vagrant reload
[default] Attempting graceful shutdown of linux…
[default] Clearing any previously set forwarded ports…
[default] Forwarding ports…
[default] — ssh: 22 => 2222 (adapter 1)
[default] Cleaning previously set shared folders…
[default] Creating shared folders metadata…
[default] Running any VM customizations…
[default] Booting VM…
[default] Waiting for VM to boot. This can take a few minutes.

[default] Failed to connect to VM!
Failed to connect to VM via SSH. Please verify the VM successfully booted
by looking at the VirtualBox GUI.
[09:06:25] florent@Air:~ $

The VirtualBox GUI shows the VM running, but nothing more. Can’t force restarting the VM (or even stop it) from the GUI. Let’s start over: kill the VM process, vagrant destroy; vagrant up

Same error. Uh-oh. Is it because of the cookbooks I added? Let’s try deleting them and reverting to the original Vagrantfile. No luck.

Alright! Google to the rescue! And there we go, a Stack Overflow discussion leading to a bug report on GitHub. Well known network-related issue then, a fix seems to start the machine with GUI enabled and `/etc/init.d/networking restart` so that vagrant can SSH into the VM. Not ideal, but meh. Let’s advance!
9:45: phew! That took some time. Now let’s add back those cookbooks.
9:55: added to the Vagrantfile, the cookbooks install themselves.
10:00: port forwarding works, now’s time to go buy groceries while downloading a Debian Box for later.

13:45: back! Stomach full and coffee by my side.
14:30: that whole Vagrant/Chef thing is a bit strange. There seem to be a recipe for Rails on Opscode’s (the company behind Chef) GitHub account, but it seems to also installs a bunch of Java stuff. Anyway… We’ll get to the bottom of provisioning later, the goals here is to learn Rails, right? Let’s just install what’s needed by hand.
15:00: new Debian Vagrant box set up. Installing rvm to get ruby 1.9.2.
15:20: `rvm install 1.9.2` then `rvm use 1.9.2`: Ruby all set. Good.
15:22: `gem install rails` let’s go!

(Starting Rails for Zombies on the side)
Lesson 1: okay, so there’s a built-in ORM in Rails. That seems to be ActiveRecord if I understand correctly. Gives you methods like Tweets.find(id), etc.
Lesson 2: models. Models are the O in ORM, and the M in MVC.
Lesson 3: erb. Built-in templating. The V in MVC.
Lesson 4: controllers. The C in MVC.
Lesson 5: routes. The mapping between URLs and actual code.

17:00: alright! Rails for Zombies is done, I feel ready to start a real Rails project.
`rails new sample`
Bunch of stuff getting created… All done. Let’s launch!
`cd sample && scripts/rails server` … Crashes. Says it needs a Javascript runtime. Why? No idea. But here’s the fix.
“Still pretty lame that rails 3.1 is “broken” out of the box.”, says wonderfulthunk. Quite true. :|

17:20: gem added, bundler works (`bundle install` manages dependencies and puts the needed gem into the “/vendor” folder), `script/rails server` works! Let’s plug the host’s port 3000 to the VM’s one and set up a shared folder so that we can develop and test from the host machine while running everything in the VM. This is all done in the Vagrantfile.
17:30: setting up the shared folder ate the Rails project. Fun times. Re-create it, re-add the gem, re-bundle, re-start the server…
17:40: it works! I can see Rails’ welcome page.
17:41: so, what now? “1. Use rails generate to create your models and controllers” Okay, sure.
Let’s try and create something simple, say a blog. It need posts. `script/rails generate model post`: it creates the model I want, some migration (?) stuff and some testing stuff. But wait, it doesn’t create any view, or controller… There is a better way: scaffold. `script/rails generate scaffold` gives us an example of how the command works, by suggesting to create… A blog post. Great minds think alike, I guess. ;D [/narcissism]
Scaffolding creates another bunch of stuff. Looking at config/routes.rb, there is now a resources :posts. So I guess going to http://localhost:3000/posts should work?
=> Could not find table ‘posts’. Oh.
Let’s see what’s in the db then. I remember an option on the rails script about that: yep, `script/rails db`
It gives an SQLite shell:

sqlite> show tables;
Error: unable to open database “db/development.sqlite3”: unable to open database file

Ah! So there’s no database. Time to learn a bit more about that migration stuff.
18:15: So I checked the official Getting Started guide on RubyonRails.org, recommended by orta on HN, and it’s really well written and comprehensive. I should have started here actually; it’s exactly the right amount of conciseness and straightforwardness. That’ll teach me not listening to others.
The database is created with `rake db:migrate`.
18:20: http://localhost:3000/posts is now a fully functioning CRUD app. Is it supposed to be that easy? It really feels like cheating.
The example on the aforementioned Getting Started guide is a blog, so I’ll piggy-back on it for the rest of the day.
20:00: hmm. Learned about automatic code generation, configuration over convention (it’s all automatic! The error messages look like they might be a bit cryptic from time to time, though), migrations, and partials. Lots of nifty features indeed. And all is quite simple. So simple that I’m actually going to try and quickly write that antipodes application tomorrow, then practice TDD and stop worrying about deploying before I actually have an app to deploy.

 

On a side note, yesterday’s “day 0” post has been viewed nearly 1200 times thanks to a (brief) appearance on HN’s front page. That helps building up some pressure, I hope not to disappoint. :)

 

Come back tomorrow for more bug-fighting, stumbling in the dark and unstructured write-ups!

Rails in a week — day 0

Tl;dr: I’m learning Rails in a week! And I’ll blog about it all along. Any tips?

 

So. Learning Rails.

As a recent graduate in CS, moving to a new country in two weeks and looking forward to expand my skills, Rails looks like a good fit: it’s in demand, it focuses on developer happiness, vibrant ecosystem yadda yadda. You probably already know this so let’s cut the marketing speak!

Methodology

My main aim is to get familiar with the Rails ecosystem, but also to learn better processes in the way. This includes a more thorough use of version control, testing, server provisioning and deployment.

I plan on using the following tools:

  • Git (I already know a bit of git, but basically just add/commit/push to Github. We’ll see if I need more)
  • Vagrant & Chef to provision the VM
  • Capistrano to deploy
  • Test::Unit
  • Cucumber
  • RailsForZombies as a very first introduction

The plan is to spend about 8 hours a day for 7 days, including a day off on Sunday and time off when Rugby World Cup matches are on the telly (I’m not a bot!).

I’m not yet settled on using the Pomodoro technique, we’ll see how things work out.

Goal

My objective at the end of this week is to create a small webapp that will give you a map showing the antipodes of something the user entered (a city, a country, etc). The logic behind this isn’t very complicated at first glance: plug into Google Maps and revert GPS coordinates? Which makes it a good learning project.

Caveat/Gotchas

I already know Ruby (not inside and out, but a fair bit of it), which will undoubtedly make the learning process easier. I also wrote a few websites using Sinatra, so I have a basic awareness of what Rack is, how HAML works, etc — it’s not as if I was beginning from zero.

Of course, I won’t have time to learn all there is to know about Rails in a mere seven days. :) But I have to get started somewhere, get something done, and I hope I’ll be able to reduce the number of unknown unknowns I have about Rails as much as possible in that timeframe.

I have listed more tools centered around ops than in Rails itself because I don’t know much about what will take time right now. That’s where I’m looking for your help: do you have pointers for things I should learn? Things I should absolutely do/absolutely not do? Feel free to post them here, on Hacker News, or fire me an email.

 

Learning begins tomorrow at 8!