Ruby Studio Blog

We have recently completed and released another project: wor84.vaccbih.info It’s been a pleasure working with our VATSIM friends from vACCBiH and we’re looking forward to pushing other projects with them in the future!

We’re very excited to announce that we have adopted Gitlab as our internal development, collaboration and repository platform! All our current and future projects have been migrated from github to our dedicated gitlab server and we’ve been extremely pleased with the stability and maturity of the software.

We’ve upgraded our current projects to the newly released rails 3.2. The upgrade currently affects rubystudio.net, darvazaogrev.com, vasev.org. Rails 3.2 will be used for all future projects and revamps that are currently in development, and we’re also looking at moving IP.Trac to the 3.x branch.

If you’ve been using jQuery Mobile from the start or if you’re just beginning to play with it (beta 3 is current at the time of this writing) you might have noticed that in recent versions auto-resizing of page elements does not work for all devices out of the box and this was not the case in earlier versions. The answer is simple, but not well documented (if at all): you need to add the viewport meta tag in your layout:

<meta name="viewport" content="width=device-width, initial-scale=1">

If you happen to use non-ASCII characters in a ruby file within your rails app, say a controller, library, database seeds, etc, you might have the invalid multibyte char (US-ASCII) error thrown at you by ruby 1.9.x. This is something you’re bound to experience if you’re developing an app that is localized in a language that utilizes non-ASCII characters and you’re not using the i18n libraries of rails to define your strings. The solution is very easy and feels almost magical:

# encoding: utf-8

Put this line of code on top of all scripts that raise the error. Unfortunately there seems to be no way to deal with it on application level with a single entry.

All piblic websites need a way to track their visitors and while Google Analytics remains the de-facto standart for web analytics, in certain cases customers prefer alternatives. There might be several reasons to opt for an alternative, to name but a few:

• the customer might not trust Google or generally any external service with their web data
• the customer might want features that are missing from Google analytcis, such as real-time analytics
• the customer might want a more sophisticated API without quota limits to pull their data

Granted we still use and recommend Google analytics as the primary solution here at Ruby Studio, we looked for possible alternatives in an effort to accomodate these user cases.

For live tracking the popular choice is Woopra, and we still use it on some of our projects on customer request, however it has the downside of loading too much javascript too slowly and recent tests we’ve made indicate that Woopra code takes about as much to load and process as all the rest of our code and assets for a particular page put together. Some tweaks and hacks are possible for performance improvement, but overall it remains too slow and hence not a primary choice for us.

Ideally we would have picked a Ruby based solution, so we considered RailStat, but we decided it’s not yet mature enough for production, its feature set is still somewhat limited and there seems to be no active development. We’ll be keeping an eye on it for the future.

So eventually our choice fell on Piwik. An open source project with rich feature set, slick ajax-y interface, actively developed and maintained, with good market penetration (used on more than 150 000 sites). It also has a simplified, but fully working Live analytics module, allows extensive customization and provides a rich API. Performance seems also quite good, the speed of getting and parsing the tracking javascript seems on par with Google analytics, the impact on the webapp performance is minimal.

So we will be offering Piwik as an option for web analytics to our customers in 3 varieties:

• as part of our unified analytics service at http://analytics.rubystudio.net. This service will be used by multiple customers and web projects; user accounts for access and website permissions will be set at per customer basis.
• as a separate Piwik instance, hosted by us, but not shared with other customers or web sites, and the customer will receive full administration rights for the instance.
• as a customer-hosted solution. We can install and configure a Piwik instance for our customers on their own servers or at their chosen hosting provider, and in this case the customer retains all the privileges and responsibility of maintaining and hosting the software on their own

Having a sitemap for your website is a nice convention, it helps search engines find, index and build an hierarchy of your pages and it also gives you some control of what content is parsed and how often. At Ruby Studio we regard sitemaps as a mandatory aspect of development and SEO and always include them in the apps we build, even if it’s a simple app with no much dynamic content, such as our current homepage.

So what is our preferred method of incorporating sitemaps in rails applications? There is a really easy way, by using a gem that is actively maintained and fully compatible with rails 3.1. As an extra benefit, the gem is really well documented. It’s called sitemap_generator.

Here’s how to get going with it in a few easy steps:

• Add gem 'sitemap_generator' to your Gemfile and run bundle. This will install the gem
• Run rake sitemap:install to setup the gem. This will generate a config/sitemap.rb file which is your sitemap configuration descriptor file. You can run this task on your development machine and there will be no need to repeat the process for production.
• Open your sitemap.rb file to define the pages you need included in your sitemap. Only the root home pages is included by default. In your sitemap.rb file you” find initially a block of code: SitemapGenerator::Sitemap.default_host = "http://www.example.com"
SitemapGenerator::Sitemap.create do
  ……..
  end
• Edit the file, inserting into the block the links to your pages or resources like this:

    SitemapGenerator::Sitemap.default_host = "http://www.example.com"
    SitemapGenerator::Sitemap.create do
      add '/contact_us'
      Content.find_each do |content|
        add content_path(content), :lastmod => content.updated_at
      end
    end

As you can see from the example, static pages are added by a simple add declaration, and dynamic content can be easily added by a nested block selector, polling your rails models and extracting blogs, articles or any other dynamic assets you might have in your app. Neat and easy!

There are a number of supporter options you can add to your configuration to fine tune the crawling frequency, priority, etc, such as
add '/contact_us', :changefreq => 'monthly'
add '/about', :priority => 0.75
The full list is available in the gem documentation

• After writing the configuration, you’re ready to actually generate your sitemaps. Run rake sitemap:refresh. This will create the sitemaps and put them in your public/ folder, appropriately compressing them with gzip and naming them by default: sitemap_index.xml.gz, sitemap1.xml.gz, etc
• Next you should add the path to your sitemap in your robots.txt file, so that the spiders can find it automatically: Sitemap: http://www.example.com/sitemap_index.xml.gz
• Upon a sitemap generation, the script automatically notifies (pings) major search engines (Google, Yahoo, Bing, Ask, SitemapWriter) that a new sitemap is available. In development you can disable the notification by using instead rake sitemap:refresh:no_ping
• That’s all, you’re now ready to rumble with your new shiny sitemaps. In production you can add a crontab entry (either manually, or using the whenever gem) for the rake task to automatically re-generate your sitemaps on, say, a daily basis. Here’s an example of raw crontab entry:

0 5 * * * /bin/bash -l -c 'cd /path/to/webapp && RAILS_ENV=production rake -s sitemap:refresh --silent'

Or an example whenever entry:

    # config/schedule.rb
    every 1.day, :at => '5:00 am' do
      rake "-s sitemap:refresh"
    end

The whole setup and deployment process takes some 15 minutes and is really flexible and configurable. No more reasons to skip on this important part of search engine optimization and web development best practices. :)