Bluerail Weblog

Beheer van ontwikkelomgeving met Foreman

info@bluerail.nl (Bluerail) — Fri, 20 Jan 2012 00:00:00 CET

De ontwikkeling van een applicatie vereist tegenwoordig meer dan enkel een teksteditor en een rails server. Door het gebruik van bijvoorbeeld verschillende databases, achtergrondtaken of afhandeling van e-mail is het noodzakelijk bij de ontwikkeling de beschikking te hebben over software die hiertoe in staat is.

Nu is het hebben van deze software enkel een preconditie die vastgelegd kan worden bij het project en daarmee ook niet echt een probleem. Wanneer verschillende projecten verschillende verzamelingen software vereisen ontstaat de behoefte om de ontwikkelaar hierin te ondersteunen. De Rubygem Foreman komt hierbij bijzonder goed van pas!

Procfile

De Foreman gem heeft als insteek het starten van de applicatie eenvoudiger te maken door de precondities op het gebied van software die gestart moet worden vast te leggen in een Procfile. Dit bestand bevat enkel een naam en een uitvoerregel.

Een Rails project dat gebruik maakt van mongoDB voor opslag van gegevens, Redis voor snelle toegang tot key-value opslag, Resque voor de uitvoer taken in de achtergrond, Resque scheduler voor het periodiek starten van taken en Post Office voor het beschikbaar stellen van een mailserver in de ontwikkelomgeving heeft een volgend Procfile:

web:            bundle exec unicorn
mongodb:        mongod --quiet --dbpath=db/mongo/
redis:          redis-server /opt/local/etc/redis.conf
worker:         bundle exec rake environment resque:work QUEUE=*
scheduler:      bundle exec rake resque:scheduler QUEUE=*
post_office:    post_office --smtp 10025 --pop3 10110

Foreman

Normaal gesproken zou het een hele klus zijn om alle software te starten om zo aan ontwikkeling te beginnen. Met Foreman kunnen we aan de slag na het uitvoeren van één commando:

$ foreman start

Vervolgens worden de verschillende onderdelen van Procfile gestart en wordt het resultaat daarvan weergegeven:

my_project git:(master) foreman start
10:39:42 web.1          | started with pid 5873
10:39:42 mongodb.1      | started with pid 5874
10:39:42 redis.1        | started with pid 5877
10:39:42 worker.1       | started with pid 5878
10:39:42 scheduler.1    | started with pid 5881
10:39:42 post_office.1  | started with pid 5883
10:39:42 mongodb.1      | Fri Jan 20 10:39:42 [initandlisten] MongoDB starting : pid=5874 port=27017 dbpath=db/mongo/
10:39:42 web.1          | I, [2012-01-20T10:39:46.316708 #5873]  INFO -- : listening on addr=0.0.0.0:8080 fd=12
10:39:42 web.1          | I, [2012-01-20T10:39:46.317231 #5873]  INFO -- : worker=0 spawning...

Afhankelijkheden

Het is mogelijk dat bepaalde software afhankelijk is van andere. Zo zal in bovenstaand voorbeeld Resque niet werken zonder Redis. Foreman biedt op dit moment nog geen ondersteuning aan om aan te geven welke processen van elkaar afhankelijk zijn.

Een door ons voorgesteld concept voegt deze ondersteuning toe door in de Procfile gebruik te maken van het sluisteken. De onderdelen uit het eerdere voorbeeld worden dan beschreven als:

web:            bundle exec unicorn
mongodb:        mongod --quiet --dbpath=db/mongo/
redis:          redis-server /opt/local/etc/redis.conf
| worker:       bundle exec rake environment resque:work QUEUE=*
| scheduler:    bundle exec rake resque:scheduler QUEUE=*
post_office:    post_office --smtp 10025 --pop3 10110

De onderdelen die afhankelijk zijn van Redis worden op deze manier pas na enkele seconden gestart. Een versie van Foreman met ondersteuning voor dit concept is te downloaden vanaf Github.

E-mail spamfilters in prijs verlaagd

info@bluerail.nl (Bluerail) — Fri, 25 Nov 2011 00:00:00 CET

Sinds enige tijd bieden wij de uitstekende spam filters van Spam Experts aan. Bluerail beschikt over een eigen filtercluster wat onder andere scant op ongewenste mail en virussen. De gefilterde mail wordt vervolgens in uw in uw Bluerail hostingaccount afgeleverd, of bijvoorbeeld op uw eigen Exchange server op kantoor. U hoeft hoe dan ook zelf niets in te stellen en geen software te installeren.

Door het grote succes van deze spamfilters hebben wij de prijs kunnen verlagen van 40 euro naar slechts 30 euro per jaar. Voor bestaande gebruikers wordt bij de volgende verlenging automatisch de nieuwe prijs berekend.

Wilt u het spamfilter gratis uitproberen? Volg ons op Twitter, stuur ons een tweet en u krijg een maand vrijblijvend een spamfilter op proef bij uw Bluerail hosting pakket of VPS!

Doeltreffend filter

Alle SpamExperts technologieën zijn uniek, intern ontwikkeld en vormen een uitstekend samengaand geheel om de meest optimale filterresultaten te behalen. De Incoming Email Security Firewall combineert meer dan 50 verschillende filtermechanismen die voortdurend geüpdate, gemonitord en verfijnd worden om u altijd van de doeltreffende resultaten te kunnen verzekeren.

De filtering is grofweg verdeeld in twee fases. Fase 1, de SMTP-fase, analyseert het gedrag en de reputatie van de zendende server. Ongeveer 95% van alle spam kan al in deze fase opgespoord worden. In fase 2, de inhoudsfase, wordt de werkelijke inhoud van het bericht gecontroleerd en wordt de overige 5% van de spam berichten opgespoord. De twee fases samen berekenen een spam-score plausibiliteit. Op deze persoonlijke score worden berichten geaccepteerd, geweigerd of in quarantaine geplaatst.

Overzichtelijk control panel

U krijgt zelf toegang tot een overzichtelijk control panel waar u de instellingen van het spamfilter zelf kunt aanpassen en bovendien direct de e-mail quarantaine kunt inzien. Hieronder ziet u enkele screenshots van het paneel voor de domeinbeheerder. U kunt ook individuele gebruikers toegang geven tot hun eigen deel van het paneel, zij zien dan minder opties.

Dashboard

Logbestanden doorzoeken

‘Whitelist’ van afzenders

Statistieken

Ideaal voor organisaties met een eigen mailserver

Bedrijven met een mailserver op hun eigen locatie lopen soms tegen problemen aan omdat providers dit niet toelaten. Bovendien kan er bij storingen in de verbinding geen mail afgeleverd worden. Ons spamfilter kan hierbij een uitkomst bieden. Alle mail van buitenaf wordt op ons filter aangenomen en bewaard. Het filter zal vervolgens proberen om de mail op uw server af te leveren. Dit kan ook op een andere poort dan de standaard poort 25 om beperkingen van providers te omzeilen. Indien uw server tijdelijk niet bereikbaar is wordt de mail op onze filter servers bewaard. Zo heeft u dus het gemak van een lokale mailserver, zonder bereikbaarheidsproblemen.

Applicatieversies met git describe

info@bluerail.nl (Bluerail) — Tue, 22 Nov 2011 00:00:00 CET

Het gebruik van versienummers in Ruby on Rails applicaties is niet erg wijd verspreid. Doordat er van veel applicaties in feite maar een versie van belang is (de versie die op dat moment on-line is) wordt er geen melding gemaakt van een specifieke versie. Desondanks kan het toch nuttig zijn om de releases van de applicatie te nummeren. Dit geeft een handvat om wijzigingen naar de gebruikers te communiceren en bovendien geeft het de gebruikers het gevoel dat de applicatie actief ontwikkeld wordt.

In deze post laten we zien hoe met behulp van git describe en enkele regels code zeer eenvoudig versienummers aan een Rails applicatie kunnen worden toegevoegd.

Git describe: zoek een tag bij een commit

Ons belangrijkste hulpmiddel voor deze post is git describe. We zullen de werking demonstreren aan de hand van een voorbeeld.

De eerste stap is het opzetten van een repository in een lege directory:

    $ git init .
    Initialized empty Git repository in /Users/martijn/Developer/versies/.git/
    $ echo "Dit is nog geen versie" > README 
    $ git add README 
    $ git commit -m "Eerste commit"
    [master (root-commit) f828a77] Eerste commit
     1 files changed, 1 insertions(+), 0 deletions(-)
     create mode 100644 README

De eerste commit heeft als hash f828a77. Als we nu git describe uitvoeren op dit repository geeft deze die hash terug:

    $ git describe --always
    f828a77

We gebruiken hier de –always optie zodat git een hash gebruikt als beschrijving indien hij geen tag kan vinden.

Op het moment dat een versie klaar is om uit te brengen kunnen we een tag aanmaken voor deze versie. In de Semantic Versioning richtlijnen wordt aanbevolen om versie tags te laten beginnen met een letter v. Tevens wordt het gebruik van annotated tags in Git over het algemeen aanbevolen. Voor ons voorbeeld is dit ook van belang. We committen en taggen de update daarom als volgt:

    $ echo "Versie 0.1.0" > README ; git add README ; git commit -m "Versie update"
    [master 633b8a0] Versie update
     1 files changed, 1 insertions(+), 1 deletions(-)
    $ git tag -a "v0.1.0" -m "Versie 0.1.0"

Als we nu git describe uitvoeren zien we dat onze tag als omschrijving wordt gebruikt:

    $ git describe
    v0.1.0

Dit gegeven zouden we dus al kunnen gebruiken om de huidige versie weer te geven in onze applicatie. Daarover straks meer. Wat gebeurt er nu als we een commit maken na deze tag?

    $ echo "Versie 0.1.1" > README ; git add README ; git commit -m "Versie update"
    [master a85330d] Versie update
     1 files changed, 1 insertions(+), 1 deletions(-)
    $ git describe
    v0.1.0-1-ga85330d

Wat deze omschrijving aangeeft is dat er een commit is geweest sinds de tag en dat onze HEAD momenteel op commit a85330d zit. Dit zou geen acceptabel versienummer zijn voor een productie release, dus hier zullen we straks bij het deployen op controleren.

Om nu een geldige productie versie te maken zullen we nog even een v0.1.1 commit taggen:

    $ git tag -a "v0.1.1" -m "Versie 0.1.1"
    $ git describe
    v0.1.1

In een Git client als SourceTree zien we de tags netjes op een rij onder elkaar:

Versie tonen in de Rails applicatie

Om de versie te kunnen tonen in de Rails applicaite stellen we deze vast tijdens het opstarten van de applicatie. Maak hiervoor een bestaand config/initializers/app_version.rb aan met de volgende inhoud:

    APP_VERSION = `git describe --always` unless defined? APP_VERSION

Vervolgens kun je op de gewenste plek, bijvoorbeeld in de layout eenvoudig de versie opvragen, bijvoorbeeld door dit op te nemen in de layout view:

    <%= APP_VERSION %>

Versie controleren voor het deployen met Capistrano

Om er nu voor te zorgen dat een productie release altijd een correct getagde versie heeft zullen we in de deploy.rb een controle opnemen die kijkt of er een tag is.

Hier een voorbeeld stap voor een multistage setup, waarbij we voor elke stage een gelijknamige branch hebben:

task :check_tag do
  desc = `git describe #{stage} --exact-match`
  unless desc =~ /^v(\d+)\.(\d+).(\d+)/
    Capistrano::CLI.ui.say(<<-EOM)
    The branch #{stage} does not have a version tag!

    Please tag the release to enable deployment. Last tags were:
    EOM
    Capistrano::CLI.ui.say "    "+`git tag -l | head -5`.lines.to_a.join(', ').gsub("\n",'')
    exit
  else
    Capistrano::CLI.ui.say("    Releasing #{desc}")
  end
end

before "deploy", "check_tag"

Er wordt een branch en een optie –exact-match weergegeven. Deze optie zorgt ervoor dat er alleen een resultaat wordt gegeven als er een exacte tag voor de versie bestaat. Als de laatste commit in de branch niet getagged is komt er dus geen resultaat.

Met een regex controleren we of er een tag is terug gegeven met een geldig formaat. Zo niet, dan krijgt de gebruiker een waarschuwing. Voor de volledigheid geven we de laatste vijf tags weer zodat de gebruiker de volgende versie kan bepalen. Een script om automatisch de versie op te hogen zou hier een mooie toevoeging zijn.

Indien er wel een geldige tag is gevonden geeft het script hier netjes een melding van. Hierna zal in de productieapplicatie netjes de getagde versie weergegeven worden.

Door de versienummering te centraliseren in Git is beheer van versies eenvoudig en overzichtelijk. Met Semantic Versioning krijgen de versienummers een duidelijke mening voor de buitenwereld. Het bijhouden van versienummers lijkt niet overal nuttig, maar wellicht geeft het uw applicatie net dat stukje extra uitstraling.

Includes versus Joins: een vuistregel

info@bluerail.nl (Bluerail) — Mon, 14 Nov 2011 00:00:00 CET

In Ruby on Rails applicaties is het gebruik van relaties tussen objecten een vrij algemeen begrip. Een minder bekend gedeelte is de techniek die hier achter schuil gaat: het gebruik van een LEFT OUTER JOIN in de database en het gewicht van een dergelijke operatie. Door een keuze te maken tussen de includes en joins methode van ActiveRecord kun je de gebruikte join beïnvloeden. In dit artikel zullen we de gevolgen van deze operators demonstreren met een testcase en geven we een vuistregel die helpt bij het kiezen tussen includes en joins.

In SQL zijn de meest gangbare manieren van het koppelen van tabellen de LEFT OUTER JOIN en de INNER JOIN. Het belangrijkste verschil tussen de twee is dat bij een OUTER JOIN het niet verplicht is dat een overeenkomend record tussen de gekoppelde tabellen aanwezig is.

Scenario

Het verschil tussen een LEFT OUTER en INNER join is het beste te demonstreren met een testcase. Laten we uitgaan van een omgeving met studenten (Student), klassen (Classroom) en leraren (Teacher). Elke student heeft over een aantal jaar ingeschreven gestaan in een aantal klassen (Enrollment) en een klas wordt geleid door meerdere leraren (ClassroomTeacher).

In Ruby on Rails ziet onze applicatie er als volgt uit:

Student

class Student < ActiveRecord::Base
  has_many :enrollments
  has_many :classrooms, :through => :enrollments
  
  validates_presence_of :name
end

Enrollment

class Enrollment < ActiveRecord::Base
  belongs_to :student
  belongs_to :classroom
end

Classroom

class Classroom < ActiveRecord::Base
  has_many :classroom_teachers
  has_many :teachers, :through => :classroom_teachers

  has_many :enrollments
  has_many :students, :through => :enrollments

  validates_presence_of :year
end

ClassroomTeacher

class ClassroomTeacher < ActiveRecord::Base
  belongs_to :classroom
  belongs_to :teacher
end

Teacher

class Teacher < ActiveRecord::Base
  has_many :classroom_teachers
  has_many :classrooms, :through => :classroom_teachers

  validates_presence_of :name
end

Om de applicatie wat context te geven hebben we hem gevuld door gebruik te maken van de gem factory_randomizer. Deze gem stelt ons in staat een database te vullen met willekeurige data.

4000.times do
  Classroom.create(:year => Randomizer.number(:min => 1980, :max => 2010))
end

250.times do 
  t = Teacher.new(:name => Randomizer.full_name)
  2.times do
    t.classrooms << Classroom.order("rand()").limit(1).first
  end
  t.save
end

100000.times do
  s = Student.new(:name => Randomizer.full_name)
  5.times do
    s.classrooms << Classroom.order("rand()").limit(1).first
  end
  s.save
end

We hebben nu een applicatie met 100.000 studenten die elk in 5 van de 4000 willekeurige klassen ingeschreven zijn geweest. Elk van deze klassen is geleid door een tweetal leraren.

Testcase

Om het verschil tussen een LEFT OUTER en INNER join duidelijk te maken zoeken we naar alle studenten die in 1989 of 1995 les hebben gehad van Monica Slater of Philip Rhodes. Aangezien Rails 3.1 slim genoeg is om pas de SQL uit te voeren op het moment dat de verzameling gebruikt wordt vragen we van elke student de naam op.

In Ruby on Rails is dit geplaatst in een Rake taak:

require 'timer'

task :fetch_students => :environment do
  years = [1989, 1995]
  teachers = ["Monica Slater", "Philip Rhodes"]

  total_duration_includes = 0
  total_duration_joins = 0
  total_runs = 100
  ignore_runs = 10

  total_runs.times do |index|
    duration_includes = Timer.time do
      # .includes = LEFT OUTER JOIN
      Student.includes(:enrollments => { :classroom => :teachers }).
              where(:classrooms => { :year => years }).
              where(:teachers => { :name => teachers}).
              all.map(&:name)
    end
    
    duration_joins = Timer.time do
      # .joins = INNER JOIN
      Student.joins(:enrollments => { :classroom => :teachers }).
              where(:classrooms => { :year => years }).
              where(:teachers => { :name => teachers}).
              all.map(&:name)
    end
    
    # allow the database to 'warm up'
    if index > ignore_runs
      total_duration_includes += duration_includes
      total_duration_joins += duration_joins
    end
  end
  
  puts "Average: #{total_runs - ignore_runs} runs"
  puts "Includes: #{sprintf("%.2f", total_duration_includes)}"
  puts "Joins: #{sprintf("%.2f", total_duration_joins)}"
  puts "Remaining load: #{sprintf("%.2f", (100 / total_duration_includes) * total_duration_joins)} %"
end

De taak zal 100 maal de studenten op verschillende manieren ophalen. De eerste 10 pogingen worden buiten beschouwing gelaten, om de database server de kans te geven de gegevens in de cache op te slaan.

rake fetch_students

Average: 90 runs
Includes: 0.31
Joins: 0.17
Remaining load: 54.44 %

40% winst

In deze simpele test behalen we door enkel het woord ‘includes’ te vervangen door ‘joins’ meer dan 40% snelheidswinst. Dit verschil kan zelfs nog groter worden als:

De database wordt actief gebruikt (waardoor tabellen / records regelmatig in geblokkeerd worden door andere transacties)
De gebruikte gegevens meer dan alleen een id en een naam zijn

Wanneer toepassen?

Er is een groot verschil tussen het resultaat van een LEFT OUTER en INNER JOIN. Het belangrijkste verschil: De relatie hoeft bij een LEFT OUTER JOIN niet te bestaan, waar deze bij een INNER JOIN verplicht is. Onderstaand voorbeeld laat zien dat bij een kleine tabel met boeken met daaraan de auteurs gekoppeld. Merk op dat er geen auteur is gekoppeld aan boek 3 ‘The Magic Of Reality’.

mysql> SELECT * FROM books;
+----+-----------------------+-----------+
| id | name                  | author_id |
+----+-----------------------+-----------+
|  1 | A Dance with Dragons  |         1 |
|  2 | The Affair            |         2 |
|  3 | The Magic Of Reality  |      NULL |
+----+-----------------------+-----------+
3 rows in set

mysql> SELECT * FROM authors;
+----+--------------------+
| id | name               |
+----+--------------------+
|  1 | George R.R. Martin |
|  2 | Lee Child          |
+----+--------------------+
2 rows in set

mysql> SELECT * FROM books INNER JOIN authors ON authors.id = books.author_id;
+----+----------------------+-----------+----+--------------------+
| id | name                 | author_id | id | name               |
+----+----------------------+-----------+----+--------------------+
|  1 | A Dance with Dragons |         1 |  1 | George R.R. Martin |
|  2 | The Affair           |         2 |  2 | Lee Child          |
+----+----------------------+-----------+----+--------------------+
2 rows in set

mysql> SELECT * FROM books LEFT OUTER JOIN authors ON authors.id = books.author_id;
+----+-----------------------+-----------+------+--------------------+
| id | name                  | author_id | id   | name               |
+----+-----------------------+-----------+------+--------------------+
|  1 | A Dance with Dragons  |         1 |    1 | George R.R. Martin |
|  2 | The Affair            |         2 |    2 | Lee Child          |
|  3 | The Magic Of Reality  |      NULL | NULL | NULL               |
+----+-----------------------+-----------+------+--------------------+
3 rows in set

Beide queries vragen om alle boeken met daaraan gekoppeld de auteurs. De query met de INNER JOIN stelt alleen de verplichting dat er een auteur is. Deze methode kan dus alleen gebruikt worden als met 100% zekerheid is te zeggen dat de relatie aanwezig moet zijn. Het is uiteraard wel mogelijk om LEFT OUTER en INNER JOINS te combineren.

Een vuistregel om te onthouden:

Gebruik een .joins als de condities bij het ophalen de relatie verplicht maken.

Bluerail sponsort Music BOXtel

info@bluerail.nl (Bluerail) — Mon, 07 Nov 2011 00:00:00 CET

Deze week is in het Brabantse Boxtel het project Music BOXtel van MiK Kunsteducatie van start gegaan. Dit is een uniek project wat deel uitmaakt van het landelijke project Kinderen maken Muziek, geïnitieerd door Prinses Maxima op haar 40e verjaardag. In dit project leren 130 kinderen van twee lokale bassischolen een instrument te spelen. Het wordt aan het eind van dit schooljaar besloten met een landelijke einduitvoering.

Bluerail is trots om een bijdrage te kunnen leveren aan dit mooie project dat mede mogelijk wordt gemaakt door het Oranje Fonds. Wij verzorgden voor Music BOXtel een op Refinery CMS gebaseerde website en de bijbehorende hosting.

Enkele foto’s van de opening:

Een compleet verslag van de opening en meer informatie over dit project is te vinden op de webiste van Music BOXtel

Hudson Continuous Integration testing met Rails 3 en RVM

info@bluerail.nl (Bluerail) — Fri, 21 Oct 2011 00:00:00 CEST

In de Rails wereld zijn het gebruik van versiebeheer en het schrijven van tests of specs gemeengoed. Een Continuous Integration server is een nuttige toevoeging aan je bestaande ontwikkelproces. Deze server houdt het centrale repository in de gaten en zodra er een wijzing is voert de CI server de specs uit. Indien de specs falen wordt er een mail gestuurd aan de aangewezen beheerder en eventueel aan degene die de verantwoordelijke commit heeft gemaakt. In deze post geven we kort een up-to-date uitleg over het configureren van de Hudson CI server voor Ruby on Rails.

Hudson is een volwassen CI server die zijn oorsprong vindt in de Java wereld. Er zijn ook Ruby-specifieke CI servers, maar Hudson kwam op ons over als de meest volwassen oplossing. Bovendien heeft het standaard support voor Ruby, Rails en Git, dus het sluit perfect aan bij onze werkwijze. Bovendien is Hudson zeer eenvoudig te installeren. Op de Hudson wiki staan installatieinstructies voor verschillende besuringssystemen: Installing Hudson.

Op onze CentOS server was de installatie zo gepiept met de officiële RPM:

rpm -ivh http://hudson-ci.org/downloads/redhat/hudson-2.1.2-1.1.noarch.rpm
/sbin/service hudson start

Hudson start dankzij zijn ingebouwde servlet container op poort 8080 en is na enkele minuten klaar voor gebruik. Elk project is in Hudson een losse job. Laten we gelijk een job aanmaken voor ons ‘Depot’ project:

Een Free-style project biedt volledige vrijheid in de configuratie van het build proces. Na het aamaken komen we direct in de configuratie terecht. De eerste stap, de configuratie van SCM, wijst zichtzelf:

Onder ‘Build triggers’ stellen we in dat Hudson elke 5 minuten ons repository nazoekt op wijzigingen. De interval wordt opgegeven in crontab notatie. Vervolgens voegen we met de ‘Add build step’ een ‘Execute shell’ stap toe:

Dit geeft ons een textvak waarin we ons build proces kunnen specificeren. Het onderstaande script is geschikt voor een Rails 3 applicatie op een server met een systeem-brede RVM installatie:

#!/bin/bash -

# Laad RVM
source "/usr/local/rvm/scripts/rvm"

# Gebruik de juiste Ruby versie
rvm use 1.9.2

# Installeer de gems uit de Gemfile
bundle install --deployment

# Maak een database.yml aan
echo "development:
  adapter: mysql2
  encoding: utf8
  database: hudson_depot_dev
  username: hudson_depot_dev
  password: ...
  pool: 5
  timeout: 5000
test:
  adapter: mysql2
  encoding: utf8
  database: hudson_depot_test
  username: hudson_depot_test
  password: ...
  pool: 5
  timeout: 5000" > config/database.yml

# Laad het database schema
bundle exec rake db:schema:load --trace

# Voer de specs uit, met rcov
bundle exec rake spec:rcov --trace

Er zullen ongetwijfeld aanpassingen nodig zijn voor je eigen applicatie, maar met dit voorbeeld zou je uit de voeten moeten kunnen. Voordat we op de Build now knop kunnen duwen moeten we Hudson nog toegang geven tot het repository door een SSH key aan te maken en deze op de juiste plaats in de homedir van de hudson gebruiker te plaatsen. Mogelijk moet je bij de Hudson instellingen (_Manage Hudson_) nog even de juiste locatie van de git binary op je systeem aangeven. Daarna kun je met Build now de eerste build uitvoeren. Via de console log kun je exact zien wat er gebeurt.

Meer stappen zijn er niet nodig om je Rails applicatie automatisch te testen. Uiteraard is het niet de bedoeling dat er code gecommit wordt die tot falende specs leidt maar de praktijk leert dat het toch wel eens voorkomt. CI testing is een extra stok achter de deur die ervoor zorgt dat problemen snel opgemerkt en opgelost worden. Het hoofdscherm geeft een mooi overzicht van de status van de verschillende projecten:

De weersverwachtingen geven de staat van het project aan. Een zonnetje betekent dat alle recente ‘builds’ succesvol waren. Wolken, regen of onweer geven aan dat het minder goed gaat. De status van de laatste build zie je aan de gekleurde bol vooraan de regel. Blauw = gezonde build, Geel = build met problemen, Rood = mislukte build. Met de Console knop kun je de output van de laatste build bekijken en met de ‘Schedule build’ knop kun je direct een nieuwe build starten.

Het sturen van een e-mail bij problemen is natuurlijk leuk, maar dankzij de flexibiliteit van Hudson kunnen er ook direct maatregelen genomen worden, zoals we in deze blog post van Papercut zien:

Bekijk het filmpje op Youtube

Ruby 1.9.2 nu standaard bij virtual hosting

info@bluerail.nl (Bluerail) — Wed, 05 Oct 2011 00:00:00 CEST

Sinds de lancering van Rails 3 wordt door de ontwikkelaars van Ruby on Rails geadviseerd om nieuwe applicaties te ontwikkelen met Ruby 1.9.2. Bluerail biedt sinds april van dit jaar ondersteuning voor Ruby 1.9.2 door middel van een losse Thin applicatieserver. Inmiddels kiest meer dan de helft van de nieuwe gebruikers voor deze oplossing. De tijd is daarom rijp voor een volwaardige implementatie.

Vanaf nu worden onze servers standaard uitgerust met Ruby 1.9.2 in combinatie met Phusion Passenger zodat u deze met hetzelfde gemak kunt uitrollen als u van ons gewend bent. Bij het bestellen kunt u aangeven van welke Ruby versie u gebruik wenst te maken. Wij zijn van plan om beide versies geruime tijd naast elkaar aan te bieden. Huidige Ruby 1.8.7 gebruikers zijn dus niet verplicht om over te stappen.

Ruby on Rails object id's in Youtube-stijl, met Redis

info@bluerail.nl (Bluerail) — Fri, 16 Sep 2011 00:00:00 CEST

Recentelijk wilden wij voor een applicatie de gewoonlijke opvolgende id’s in URL’s vervangen door iets onherkenbaars. We wilden de URL’s echter wel kort houden, /posts/101 wordt bijvoorbeeld /posts/D4qPPkZ4.

Om dit te bereiken hebben we een stuk code geschreven dat een korte hash berekent op basis van het ID en de modelnaam. Deze hash slaan we op in Redis (dat reeds gebruikt werd in deze applicatie) zodat we het eenvoudig kunnen toevoegen aan elk gewenst model zonder de database aan te hoeven passen.

Met 8 karakters uit 61 tekens is er ruim voldoende entropie om botsingen tussen de hashes te voorkomen. De hashes worden opgebouwd uit 2 CRC32 checksums. De code is als volgt:

# HashParam generates an id hash for an ActiveRecord model and
# exposes that through the to_param method. The hash is stored
# in Redis so find_by_param can retrieve it.
module Bluerail
  module HashParam
    # The characters that are used in constructing the hash
    HASH_CHARS = '123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'

    def self.included(base)
      base.class_eval do
        # Store param in Redis upon creation of the model
        after_create :update_redis_param

        def self.find_by_param! param
          if $redis.get("params:#{self.to_s}:#{param}") =~ /(\d+)/
            return self.find($~[1])
          else
            raise ActiveRecord::RecordNotFound, "Cannot find key 'params:#{self.to_s}:#{param}' in Redis"
          end
        end

        def self.find_by_param param
          begin
            self.find_by_param! param
          rescue
            return nil
          end
        end
      end
    end

    def update_redis_param
      # Set the value in Redis only if it doesn't exist yet
      $redis.setnx("params:#{self.class}:#{self.to_param}", self.id.to_s)
    end

    def to_param
      # Generate two digests, the second one is for additional entropy
      s1 = self.created_at ? "#{self.class}#{self.id}#{self.created_at.to_i}" : "#{self.class}#{self.id}"
      d1 = Zlib.crc32(s1 + "application-salt1")           # add your own salt here
      d2 = Zlib.crc32("#{d1}#{self.id}application-salt2") # add your own salt here

      # Our output buffer
      out = ''

      # Append the second digest as characters
      while d2 > 0
        d2, char = d2.divmod HASH_CHARS.length
        out += HASH_CHARS[char,1]
      end

      # Append the first digest as characters
      while d1 > 0
        d1, char = d1.divmod HASH_CHARS.length
        out += HASH_CHARS[char,1]
      end

      # Output the last 8 characters of the output buffer
      out[-8,8]
    end
  end
end

Deze code plaats je in lib/bluerail/hashparam.rb_. De code verwacht een Redis verbinding via $redis. Voor een introductie van Redis en het opzetten van een verbinding kun je hebt beste deze blog post van Jim Neath over Redis en Ruby on Rails eens doorlezen. De HashParam module activeren in een model kan eenvoudig met:

  class Post < ActiveRecord::Base
    include Bluerail::HashParam
  end

Daarna is het wel zaak om eenmalig voor alle bestaande objecten een hash aan te maken:

  Post.all.each(&:update_redis_param)

De to_param methode zorgt ervoor dat de URL helpers van Ruby on Rails automatisch de hash in plaats van het id gebruiken bij het opstellen van URL’s. Dit betekent wel dat u in de controller records zult moeten zoeken aan de hand van de find_by_param methode. Indien u CanCan gebruikt kan dit heel eenvoudig automatisch op de volgende manier:

  load_and_authorize_resource :find_by => :param

Er zijn natuurlijk talloze variaties mogelijk op het opbouwen en opslaan van de hash.

Waarschuwing bij een Capistrano production deploy

info@bluerail.nl (Bluerail) — Fri, 26 Aug 2011 00:00:00 CEST

Met de multistage plugin voor Capistrano is het mogelijk om je applicatie uit te rollen naar verschillende omgevingen. Zo kun je bijvoorbeeld cap staging deploy uitvoeren om een nieuwe versie op je staging-omgeving te plaatsen en -als alles naar behoren werkt- door middel van cap production deploy dezelfde versie op de productieomgeving plaatsen.

In sommige gevallen is de productieomgeving zo kritiek dat je zeker wilt weten een uitrol daadwerkelijk uitgevoerd dient te worden. Door het onderstaande stuk code op te nemen in je deploy.rb wordt de gebruiker om een bevestiging gevraagd voordat zijn uitrol naar de productieomgeving uitgevoerd wordt.

Neem het volgende stuk code op in je deploy.rb, buiten de deploy namespace:

task :ask_production_confirmation do
  Capistrano::CLI.ui.say(<<-EOM)

    ===========================================================================
         WARNING: You're about to perform actions on production server(s)
      Please confirm that all your intentions are kind and friendly and that      
       you're confident that this deployment will not break the application.
    ===========================================================================

  EOM

  agree = Capistrano::CLI.ui.agree("    Continue deployment? ") do |q|
    q.default = 'n'
  end

  exit unless agree
end

before "production", "ask_production_confirmation"

Deze bevestiging geeft de ontwikkelaar een extra moment om na te denken over zijn actie waardoor een onbedoelde productie-uitrol voorkomen kan worden.

Achtergrondtaken en versiebeheer: Whenever gem

info@bluerail.nl (Bluerail) — Fri, 19 Aug 2011 00:00:00 CEST

Het gebruik van versiebeheer is zeer populair bij Ruby on Rails ontwikkelaars. Met name git is een populair hulpmiddel om de historie en verschillen tussen de productie-, test- en ontwikkelomgevingen te beheren. Daarnaast is het niet wenselijk om gebruikers te laten wachten op de uitvoer van zware taken, waardoor deze in de achtergrond via een Cronjob uitgevoerd worden.

Zou het dan niet handig zijn als de inhoud van de achtergrondtaken opgenomen kan worden in het versiebeheer?

Waarom dan een Cronjob?

Er zijn tal van oplossingen voor het op de achtergrond uitvoeren van taken. Helaas vereisen de meeste van deze oplossingen (zoals Resque of Delayed job) een permanent draaiend achtergrondproces. Bij Virtual Hosting pakketten is het alleen niet mogelijk achtergrondprocessen te draaien. Het gebruik van Cronjob is dan een goed alternatief.

Whenever

Gelukkig is er een oplossing: de Whenever gem. Deze gem stelt ons in staat in een Ruby bestand aan te geven welke taken wanneer uitgevoerd moeten worden. Bij het plaatsen van de applicatie op de server kan met de aanroep van een commando ervoor gezorgd worden dat de achtergrondtaken ingesteld worden, op basis van de instellingen in het Ruby bestand.

Installatie

De installatie van de Whenever gem is eenvoudig uit te voeren wanneer gebruik wordt gemaakt van Bundler voor het beheren van de benodigde gems. Voeg hiervoor in Gemfile het volgende toe:

gem 'whenever', :require => false

Het gedeelte :require => false geeft aan dat bij het starten van de applicatie het niet nodig is dat de gem geladen wordt. De hulpmiddelen zijn tenslotte alleen nodig om op de server de achtergrondtaken in te stellen.

Vervolgens dient nog een commando te worden gestart om een initieel config/schedule.rb bestand aan te maken. Voer het onderstaande commando uit in de Rails.root-map (de map van het Ruby on Rails project):

$ cd pad_naar_rails_applicatie
$ wheneverize .

Gebruik

De achtergrondtaken die uitgevoerd dienen te worden staan beschreven in config/schedule.rb. Een voorbeeld zegt in dit geval ook meer dan 1000 woorden:

every :friday, :at => "5am" do  
  rake "apply_weekend_call_forwarding"
end

every :month do
  rake "generate_monthly_statistics"
end

every 2.hours do
  rake "process_pending_deliveries"
end

Whenever biedt naast bovengenoemde nog tal van andere middelen om taken te beschrijven. Kijk voor meer voorbeelden op de website van de Whenever gem.

Publicatie

De publicatie middels Capistrano en het gebruik van Whenever is eenvoudig te koppelen door aan config/deploy.rb een enkele regel toe te voegen:

require "whenever/capistrano"

Wanneer gebruik wordt gemaakt van de multistage extensie voor Capistrano kan het wenselijk zijn om de naam van omgeving te gebruik in config/schedule.rb. Voeg daarvoor in config/deploy.rb het volgende toe:

set :whenever_environment, defer { stage }

In config/schedule.rb is het dan mogelijk om bepaalde taken alleen uit te voeren bij een bepaalde omgeving:

if environment == 'production'
  every 1.day do
    # Specifieke taken voor productieomgeving
  end
end

De Whenever gem maakt het zeer eenvoudig om cronjobs te configureren voor Rails applicaties, zonder dat daarvoor handmatig wijzigingen op de server uit hoeft te voeren. Dankzij de goede integratie met Capistrano is het uitrollen van nieuwe taken kinderspel.

Bekijk de Whenever gem op Github

Het Bluerail weblog, aangedreven door Jekyll

info@bluerail.nl (Bluerail) — Mon, 15 Aug 2011 00:00:00 CEST

Vanaf vandaag bevat de Bluerail website een blog. Op dit blog zullen we schrijven over zaken die niet alleen voor onze klanten, maar ook voor andere Ruby on Rails gebruikers interessant zijn. Denk daarbij aan nuttige gems, codeknipsels of links naar interessante sites. Om het weblog in de site te integreren hebben we de site van de oude PHP engine gemigreerd naar een nieuw platform op basis van Jekyll.

Wat is Jekyll?

Jekyll noemt zichzelf een “simple, blog aware, static site generator”. Het in Ruby geschreven Jekyll genereert een statische site op basis van een directory met templates, blogposts met Markdown of Textile opmaak en statische HTML pagina’s. Het resultaat is een verzameling HTML bestanden die direct naar elke willekeurige webhost geupload kunnen worden. Aangezien wij zelf programmeurs zijn sluit dit perfect aan bij onze wensen. We kunnen nu een post schrijven in Vim of Textmate en met een rsync de gegenereerde pagina’s rsyncen naar onze server.

Dynamische functionaliteit

Uiteraard hebben de door Jekyll gegenereerde statische pagina’s wel een beperking. Ze zijn namelijk statisch. Ineens was het duidelijk waarom door Javascript ingesloten tools als Disqus en Gist zo in populariteit zijn gestegen. Het is immers niet mogelijk om in een statische pagina een reactie-systeem te maken. Gelukkig stelt Disqus ons in staat om met een paar regels Javascript een reactiesysteem aan te bieden waar bovendien veel bezoekers al reeds een login voor zullen hebben. Ideaal!

Het laatste probleem wat we nog hadden was het contact- en bestelformulier. Hiervoor zijn ook verschillende on-line diensten beschikbaar, maar we hebben besloten om een kleine Sinatra applicatie te maken die deze formulieren afhandelt. De Sinatra app staat helemaal los van de Jekyll pagina’s. De formulieren worden in de pagina geplaatst door middel van een iframe. Dit is niet de netste oplossing, dus we zijn nog aan het kijken hoe we het een en ander kunen verbeteren.

Open source

Tijdens het opzetten van de op Jekyll en Sinatra gebaseerde website hebben we veel gehad aan de publiek gemaakte source code van andere websites. We zullen daarom op korte termijn ook de source code van onze eigen website openbaar maken. Overigens hebben we een fork van Jekyll gemaakt om de datums van blog posts in het Nederlands te kunnen weergeven. Er is inmiddels een pull request geplaatst om deze functie in Jekyll op te nemen.

We zijn zeer tevreden met Jekyll. Wil je meer weten, kijk dan eens op de Jekyll Wiki.

Nu nog meer schijfruimte bij het Business pakket

info@bluerail.nl (Bluerail) — Mon, 30 May 2011 00:00:00 CEST

Het Business Virtual Hosting pakket bevat met ingang van vandaag 1 gigabyte schijfruimte, een verdubbeling van de oude hoeveelheid. Dit maakt het Business pakket het ideale pakket voor middelgrote applicaties en een aantrekkelijke upgrade vanaf het Hobby pakket. De wijziging is per direct voor alle huidige Business klanten doorgevoerd.

Kijk op de Virtual Hosting pagina voor meer informatie over onze hostingpakketten.

Ruby 1.9.2 ondersteuning bij Bluerail

info@bluerail.nl (Bluerail) — Wed, 06 Apr 2011 00:00:00 CEST

Deze maand hebben wij Ruby 1.9.2 opgenomen in ons standaardpakket, naast de bestaande Ruby 1.8.7 ondersteuning. Hiermee kan de nieuwste generatie applicaties optimaal presteren op ons platform. Voor nieuwe Rails 3 en Sinatra applicaties kunnen wij het gebruik van Ruby 1.9.2 van harte aanbevelen.

Uw Ruby 1.9.2 applicatie wordt geserveerd door een eigen Thin server achter onze Apache proxy. Op het bestelformulier kunt u de voorkeur voor uw Ruby versie aangeven. In de nabije toekomst zal het hosten van Ruby 1.9.2 applicaties via het gebruikelijke Passenger platform ook mogelijk worden. Op Virtual Private Servers en dedicated servers is het gebruik van Ruby on Rails met Ruby 1.9.2 uiteraard ook mogelijk.

Kijk voor meer informatie over onze Virtual Hosting diensten op de Virtual Hosting pagina.