Ruby Studio Blog

Agile web development and IT solutions based on modern open standarts and technologies

[rubystudio-blog]

New project: wor84.vaccbih.info

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!

[rubystudio-blog]

Gitlab adopted as internal development platform

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.

[rubystudio-blog]

Projects upgrade: Rails 3.2

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.

[rubystudio-blog]

Vasev.org has been rewritten as Rails 3.1.1 application, bringing speed and security improvements, usability enhancement and design tweaks.

[rubystudio-blog]

We're happy to announce the launch of the new version of darvazaogrev.com website. It's been completely rewritten as a rails 3.1.1 application with new minimalist html5 & css3 design.

[rubystudio-blog]

[js tips] Auto-resizing page elements with jQuery Mobile

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">

[rubystudio-blog]

[rubystudio-blog]

[Rails Tips] Dealing with the "invalid multibyte char" error

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.

[rubystudio-blog]

Piwik - the in-house web analytics solution

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](http://rubystudio.net/), we looked for possible alternatives in an effort to accomodate these user cases. For live tracking the popular choice is [Woopra](http://www.woopra.com/), 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](http://www.railstat.com/), 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](http://piwik.org/). 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](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

[rubystudio-blog]

Sitemaps: the rails 3.1 way

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](http://rubystudio.net/). 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](http://rubygems.org/gems/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](http://rdoc.info/github/kjvarga/sitemap_generator/master/frames) * 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](http://rubygems.org/gems/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. :)

[rubystudio-blog]

Development focus: RubyStudio.net

We've launched the initial version of our website today. It has pretty basic functionality right now, and we regard it as merely the surface layer of a system that will eventually let us manage and administer our customers and their projects with ease and convenience. So much of what is planned is actually irrelevant to the general audience and will remain invisible in the public section of the site. Some important public sections though are still incomplete and we will focus on bringing them up in the following days. These are the portfolio and testimonials listings, the FAQ section and the IP.Trac pages which are perhaps the most important for us right now, since IP.Trac is currently our flagman product and it still lacks consistent documentation and user-friendly manual, even though it's been used in production by ISPs for more than a year now, The fact of the matter is we needed web presence and we needed it quickly, to match the speed with which RubyStudio transitioned from a loosely linked group of individuals working occasionally together on random projects to a real company with its own face and branding.

Two things make us particularly happy about the current early version of the website. First is speed: it feels really fast; in a day or two we'll have accumulated statistics for the average load times for our pages, but I expect them to be around half a second. Hats off to the asset pipeline and the rendering improvements in Rails 3.1! And second is the fact that it validates as HTML5 with no errors, which of course has to be expected, considering all the bragging about standards compliance we've put in our promo pages :)