Archives de
Author: Dayo

Développeur depuis 2008, j’écris pour me souvenir et explorer de nouveau horizons.
Rails 4 et MongoDB part 3 : Travis

Rails 4 et MongoDB part 3 : Travis

Tout d’abord, qu’est-ce que Travis-CI ?

Travis-CI est un serveur d’intégration continue gratuit pour les projects open source.

Il est utilisé par beaucoup de projet afin de vérifier que les pull request n’introduise pas de bug et qu’il n’y a pas de régression lors de modifications.

Afin de l’utiliser il faut suivre les étapes suivantes:

  • Se connecter sur travis-ci.org avec son compte GitHub
  • Activer les dépôts que l’on souhaites tester
  • Ajouter un fichier .travis.yml a la racine de notre projet

Le fichier .travis.yml contient les informations dont Travis-CI a besoin afin de lancer les tests de votre dépôt.

Dans le cas de notre projet RoR avec MongoDB, il nous faut spécifier :

  • le langague
  • la version de interpréteur Ruby
  • notre base de données
  • l’environnement et la commende pour lancer les tests

Au final notre fichier .travis.yml sera le suivant :

language: ruby
rvm:
  -  2.0.0

services:
  - mongodb

script:
  - RAILS_ENV=test
  - bundle exec rake cucumber

Une fois se fichier disponible sur GitHub, Travis-CI va automatiquement lancer les tests a chaque commit.

Pour le dépôt du projet GitHub utilisé pour mes articles, la page Travis-CI est la suivante : https://travis-ci.org/dayofr/rails_tuto

On peux y voir le dernier test, la sortie de la console ainsi que l’historique des builds :

travis

Il est possible de rajouter un badge fin d’indiquer l’état actuel des tests du projet, généralement dans le fichier README à la racine du dépôt.

Rails 4 et MongoDB part 2 : Cucumber

Rails 4 et MongoDB part 2 : Cucumber

Dans l’article précédent, nous nous étions arrêté après l’utilisation du scaffolding pour créer un document dans MongoDB et le CRUD qui va avec.

Parmi les fichiers générés nous avons :

Afin de commencer par de bonnes pratiques, nous allons créer nos premiers tests BDD avec Cucumber.

Le BDD, Behavior Driven Developmen, est une méthode agile qui consiste à écrire des tests de scénarios décrivant le comportement de l’application dans un langage le plus proche possible de celui de l’humain. Un exemple valant mieux qu’un long discoure, voilà le scénario décrivant la page de listing des posts :

Scenario: Posts List
    Given I have posts titled Paris, Marseille
    When I go to the list of posts
    Then I should see "Paris"
    And I should see "Marseille"

En lisant ce texte, il est facile de savoir ce qu’il se passe et ce qui va être testé.

Afin de commencer, copiez le code suivant dans le fichier features/posts.feature :

Feature: Manage posts
  In order to make a blog
  As an author
  I want to create and manage posts

  Scenario: Posts List
    Given I have posts titled Paris, Marseille
    When I go to the list of posts
    Then I should see "Paris"
    And I should see "Marseille"

Ici nous avons juste rajouté le bloc Feature afin de décrire la fonctionnalité qui sera testée.
Une fois fait, en ligne de commande lancez : rake cucumber

Vous devriez alors avoir la sortie suivante :

cucumber1Cucumber nous indique ici qu’il ne comprend pas les différentes étapes de notre test. En effet il ne peut pas comprend sans qu’on lui explique ce qu’il faire pour la ligne Given I have posts titled Paris, Marseille. Il nous faut écrire le code correspondant a cette étape. Créez alors un fichier step_definitions/posts_steps.rb puis ajoutez-y :

Given /^I have posts titled (.+)$/ do |names|
  names.split(', ').each do |name|
    Post.create!(:name => name)
  end
end

Que faisons-nous ici ? La 1re ligne est une expression régulière afin de définir quelle étape nous définissons, elle capture tout ce qui suit et le fournit dans la variable names .

À la ligne 2, nous divisons la variable sur et itérons sur les valeurs retournées afin de les ajouter dans MongoDB grâce à la ligne 3.

Si nous relançons les tests nous pouvons voir que nous somme allez plus loin cette fois.

cucumber2Il ne nous reste plus qu’à définir les autres étapes de notre test afin d’avoir 100% dans nos scénarios :

cucumber3Pour voir le code, j’ai créé un dépôt GitHub : https://github.com/dayofr/rails_tuto .

Dans le prochain article je parlerais d’intégration continue avec Travis-ci.

Rails 4 et MongoDB part 1

Rails 4 et MongoDB part 1

Changeons un peu et parlons de Ruby, Ruby on Rails et MongoDB.

J’ai eu envie de voir ce qu’il se fait ailleurs et je pense que l’univers de RoR vaut le détour.

En partant du principe que vous avez Ruby d’installer sur votre machine, l’installation de RoR est aussi simple que :

gem install rails

Une fois cela fait, il suffit d’une autre ligne de commande pour créer un projet RoR :

rails new my_project --skip-active-record --skip-test-unit

Dans le cas présent, je n’installe pas ce qui concerne les bases de données si les tests unitaires.

Pour voir le résultat il suffit de se déplacer dans le dossier my_project et de lancer le serveur embarqué :

cd my_project/
rails server

Rendez-vous sur http://localhost:3000/ afin de voir la page par défaut.

Passons à l’ajout de la gestion de MongoDB à Mongoid travers la gem et des gem de tests. Pour cela il faut editer le fichier Gemfile et y rajouter:

gem 'mongoid', github: 'mongoid/mongoid'
gem 'bson_ext'

group :test do
  gem "rspec-rails"
  gem 'cucumber-rails', :require => false
  gem 'database_cleaner'
end

Avec la sortie récente de RoR 4, la gem mongoid n’est pas encore totalement compatible, dans notre cas nous disons à bundler d’aller la chercher sur github.

Un petit bundle install afin d’installer les nouvelles gem et nous voila prêt pour la suite.

Premièrement, il faut configurer mongoid avec :

rails generate mongoid:config

Afin de générer les fichiers pour les tests, lançons les 2 commandes suivantes :

rails generate rspec:install
rails generate cucumber:install

Avant d’aller plus loin, il faut désactiver quelques éléments prévus pour des applications avec une base de données relationnelle.

Dans le fichier spec/spec_helper.rb commentez les lignes :

config.fixture_path = "#{::Rails.root}/spec/fixtures"
config.use_transactional_fixtures = true

Pour finir dans le fichier features/support/env.rb  changez DatabaseCleaner.strategy = :transaction  par DatabaseCleaner.strategy = :truncation .

Passons aux choses sérieuses avec la génération d’un model et du CRUD associé. Comme souvent, une ligne de commande suffit :

rails generate scaffold post name:string description:text

Je vous laisse découvrir ce qui fonctionne en allant sur : http://localhost:3000/posts

Mes débuts avec Ember.js 2 [FR]

Mes débuts avec Ember.js 2 [FR]

Voici la suite de ma découverte d’Ember.js. Dans cette partie, nous verrons

Afin d’afficher les onglets en haut de la page il nous faut modifier le code html généré par handlebarsjs:

<script type="text/x-handlebars">
    <div class="container">
        {{outlet}}
    </div>
</script>

Le placeholder {{outlet}} permet le changement de template en fonction de la page demandé.

<script type="text/x-handlebars" data-template-name="races">
    <div class="masthead">
        <h3 class="muted">Welcome to Blood Bowl Team</h3>
        <div class="navbar">
            <div class="navbar-inner">
                <div class="container">
                    <ul class="nav">
                        {{#each item in model}}
                        <li><a href="#">{{item.name}}</a></li>
                        {{/each}}
                    </ul>
                </div>
            </div>
        </div>
    </div>
</script>

Ce template sert à créer les onglets a l’aide de bootstrap.

L’attribut data-template-name= »races » sert a lié ce template avec la ressource this.resource(‘races’, { path: ‘/’ }); afin que.

Les lignes 8 à 10 parcourent la liste des équipes afin d’afficher le nom.

A ce niveau, vous devriez voir:

tabs

Mes débuts avec Ember.js 1 [FR]

Mes débuts avec Ember.js 1 [FR]

Voulant m’essayer au framework JavaScript pour des Single Page Application j’ai cherché sur internet ce qu’il se fessait et mon choix c’est arrêté sur Ember.js.

Pour commencer il faut créer la base l’application:

  • Télécharger les dépendances, jQuery, Handlebars, Ember.js et Ember Data.
  • Créer un fichier html
  • Ajouter les feuilles de styles

Le code de base est disponible dans un de mes dépôts github sous le tag 0.1.

Dans un premier temps, nous allons créer notre application :

App = Ember.Application.create();

Puis notre modèle de donnée :

App.Race = DS.Model.extend({
    name: DS.attr('string'),
    avatar: DS.attr('string'),
    description: DS.attr('string')
});

Puis nous définissons le data store utilisé :

App.Store = DS.Store.extend({
    revision: 13,
    adapter: 'DS.FixtureAdapter'
});

Dans notre cas nous utilisons la version 13 de l’api et l’adaptateur DS.FixtureAdapter.

Nous déclarons enfin nos fixtures :

App.Race.FIXTURES = [
    {id: 1, name: 'Amazon', description: "Long ago, driven by a desire for adventure, the Valkyries of the Norse settlement in Lustria sailed away from their menfolk and founded a colony deep within the estuary of the river Amaxon. Now these ferocious warriors have taken to the Blood Bowl pitch – and Nuffle save those who dare to challenge them!"},
    {id: 2, name: 'Ogre', description: 'Ogre teams have existed since the forming of the NAF and have even won the XV Blood Bowl. However, as any right-minded person will tell you, having more than one Ogre in the same place at the same time is a disaster waiting to happen!'},
    {id: 3, name: 'Elves', description: 'When the NAF collapsed, many Elven teams were left penniless. Those that survived the financial fallout are not as rich as their High Elf cousins nor as well equipped, but they still sure know how to play!'},
    {id: 4, name: 'Human', description: "Although Human teams do not have the individual strength or outstanding abilities available to other races, they do not suffer from any outstanding weaknesses either. This makes Human teams extremely flexible, equally at home running the ball, passing it, or ignoring it and pounding the opposition into the turf instead."}
]

Enfin, nous déclarons la route :

App.ApplicationRoute = Ember.Route.extend({
    model: function() {
        return App.Race.find();
    }
});

Passons au fichier html. Il faut parcourir la liste des élément et afficher le nom pour chacun d’eux. Pour ce la nous déclarons un script x-handlebars a l’intérieur duquel nous itérons avec l’instruction {{#each item in model}} :

<script type="text/x-handlebars">
    <ul class="nav well">
        {{#each item in model}}
        <li>{{item.name}}</a></li>
        {{/each}}
    </ul>
</script>

Le résultat doit être le suivant :

races

Dans la console web on peut voir les versions des librairies utilisées pas Ember.js. Si il y avait une erreur, elle serait également visible à cet endroit.

Le code de cette version est accessible sur le tag 0.2.