Menu

Tag Archives: ruby

There’s lot of d3 examples on the web but they mainly very simple tutorial examples, which is great for getting started but if you plan to have a complex set of visualisations you want to avoid duplicating JS in your different visualisations and do automated testing.

I’ve created an example of how to write testable d3 javascript with inheritance so multiple visualisations can share common functionality. Having a base object for your visualisations means you can write common code once and automated testing allows you to validate changes without manual testing. Obviously there is a limit to how much you can or should test your visualisations without looking at them in browser, but this allows you to write testable code, do TDD coding and encourage re-use in your javascript.

Using jasmine to test the Javascript, extending jasmine with jasmine-jquery for jquery selectors and ruby (1.9.2+) to install dependencies (not required but makes life easier). I’ll also use jasmine-headless to run tests without opening the browser.

I put off using Capistrano as I thought it would take as much effort to learn as msbuild or ant, but after trying it I regret not doing it sooner. It’s really simple to use, has great source integration and offers a very reliable process for deployments using ssh onto unix boxes. It works well with other languages/frameworks, so you can also deploy your Java/Scala/php projects. The focus of this post is deploying a simple Ruby/Sinatra app from git onto a server which doesn’t have direct access to source (e.g. private git host).

Ignore the Capfile created, it’s pretty standard and you shouldn’t have to touch it. Edit the config/deploy.rb file and clear down, this contains some standard Rails deployment stuff which you won’t need.

set :application, “My Sinatra Application”

set :scm, :git

set :repository, “git@github.com:mygit/myproject.git”

set :deploy_via, :copy # makes capistrano clone and copy source locally rather than on server

set :deploy_to, “/var/www/mysite.com” # current release will be symlinked in ‘/var/www/mysite.com/current’

run “echo this is where the actions necessary to restart the application should go”

end

task :finalize_update, :roles => :web do

# Overwrite default rails action and perform any steps before symlink

run “echo this is the path to the release folder #{ current_release }”

end

end

Run setup before deployment to create deployment folders:

cap deploy:setup

Check:

cap deploy:check

Deploy!

cap deploy

Now you should have your application copied over to the server under the :deploy_to ‘current’ folder. Old releases (default 5) will be stored in the ‘release’ folder. You can use the restart task to call any commands necessary to restart the application. You can do a lot more complex things, like setup dbs, stage multiple servers simultaneously, tag release in source etc.

Recently banged my head against this issue for ages until someone with nginx knowledge pointed out it wasn’t nginx but a sinatra/unicorn issue.

Basically the symtoms were after setting up my Sinatra application, with Unicorn as the webserver and Nginx as the SSL proxy (redirecting http to https for the domain) anytime the application received a post request on my login screen it responded with “forbidden” (403). Get requests for the login screen worked fine.

Initially I thought the error came from Nginx, but it turned out it came from Rack (running via Unicorn). The issue was as part of the login post sinatra-authentication was redirecting to http, not https. Nginx then redirected the client to https but lost the auth details, so Rack gave the forbidden response (with no helpful debug).

To fix this all I had to do was add the following to the nginx conf at the proxy settings:

proxy_set_header X-Forwarded-Ssl on;

That told Rack it was working via an ssl proxy and changed the redirects to use https. No clue why I needed to do this, but in future I’ll use something like rack-ssl-enforcer and handle the redirects in the application itself rather than nginx conf.

This has caught me out twice now, so typing it up to remember. By default Unicorn outputs stderr/stdout to terminal, which is great if you have one running, but if you don’t (i.e. you logged off) you get a massive error screen were your app was “Errno::EIO Input/output error” in “lint.rb” or something similar.

To fix this just add the following lines to your unicorn.conf file you create for your application, which redirect the output to log files instead:

# By default, the Unicorn logger will write to stderr.# Additionally, some applications/frameworks log to stderr or stdout,# So prevent them from going to /dev/null when daemonized here:stderr_path "/srv/www/logs/unicorn.stderr.log"stdout_path "/srv/www/logs/unicorn.stdout.log"

Using Unicorn and NGINX together we get the best of both for hosting our site, Unicorn handles the requests to the Ruby app and NGINX handles the static public files (Images/CSS/JS). GitHub posted a blog why they switched to Unicorn and the benefits.