Heroku est vraiment formidable et j'admire le travail effectué par l'équipe de développement, mais son seul point faible actuellement est qu'il ne permet pas (encore ?) de choisir la zone géographique dans laquelle on souhaite déployer notre application. En effet, Heroku se base sur les services d'Amazon, mais utilise par défaut les serveurs basés aux États-Unis. Partant de ce constat, deux problèmes se posent à moi :

• étant situé à la l'île de la Réunion, le temps de latence peut être très long juste pour le chargement d'une simple page.
• je souhaite déclarer ma base de données à la CNIL, mais celle-ci ne doit pas quitter la zone européenne, ou doit être hébergée par un membre du Safe Harbor, ce qui n'est pas le cas d'Heroku.

Dans ce cas, je n'ai plus le choix, je dois me lancer sans les filets d'Heroku. Et vous allez m'accompagner dans cette aventure, en espérant que cela puisse vous être utile !

S'inscrire sur Amazon AWS

De toute évidence, il y a beaucoup de chance pour que vous ayez déjà un compte chez Amazon... Mais bon, si ce n'est pas le cas, procédez à l'inscription via cette page et revenez tout de suite après.

Créer une instance EC2 (Elastic Compute Cloud)

Connectez-vous à la console d'administration EC2. La première chose à faire est de choisir la région sur laquelle vous souhaitez créer votre instance. Si vous êtes en Europe, ou comme moi à la Réunion, la zone sur laquelle vous aurez le moins de latence est EU West (Ireland). Ce choix se fait tout en haut du menu de gauche.

Toujours dans le menu de gauche, cliquez sur "Instances" dans le sous-menu du même nom. Cliquez sur "Launch instance". Sélectionnez "Quick Launch Wizard" puis appuyez sur "Continue". Entrez les quelques informations demandées comme dans l'aperçu ci-dessous :

Le choix proposé par défaut pour l'image est Amazon Linux AMI. Personnellement, j'ai préféré choisir la Ubuntu Server 12.04 LTS en 64 bits (attention, la suite de l'article se base sur ce choix).

Dans la section "Choose a Key Pair", entrez le nom de votre jeu de clé (qui vous verrez, vous permettra de vous connecter à votre instance par la suite) puis cliquez sur "Download". Sauvegardez précieusement le fichier .pem dans un dossier ~/.ec2 créé pour l'occasion. Vous pouvez maintenant cliquer sur "Continue". La page suivante affiche un récapitulatif. Vous pouvez cliquer sur "Launch" pour créer immédiatement votre instance. Cliquez ensuite sur "Close" pour fermer la fenêtre d'informations.

Se connecter à l'instance EC2

Maintenant que votre instance est créée et démarrée (au bout de quelques secondes), vous devez vous y connecter. Faites un clic droit sur la ligne représentant votre instance, puis cliquez sur "Connect".

Choisissez ensuite la première option "Connect with a standalone SSH Client" et copier (Ctrl-C) le texte donné en exemple, qui devrait ressembler à ceci :

ssh -i mykeypair.pem ubuntu@ec2-xx-xxx-xx-xx.eu-west-1.compute.amazonaws.com

Puis servez-vous en pour vous connecter. Si vous aviez précédemment placé votre fichier .pem dans le dossier ~/.ec2, placez-vous dans votre dossier personnel et entrez la commande suivante :

ssh -i .ec2/mykeypair.pem ubuntu@ec2-xx-xxx-xx-xx.eu-west-1.compute.amazonaws.com
Are you sure you want to continue connecting (yes/no)?

Tapez yes puis appuyez sur la touche Entrée.

Voilà, vous êtes maintenant connecté à votre instance EC2 via SSH. Les commandes root peuvent être lancées via la commande sudo.

Configurer et préparer l'instance EC2 à héberger une application Rails

Les commandes suivantes doivent être lancées dans votre instance EC2 via SSH.

Installation des dépendances

sudo apt-get update
sudo apt-get install build-essential zlib1g-dev libssl-dev libreadline-dev libyaml-dev libcurl4-openssl-dev curl git-core ruby rubygems libv8-dev libmysql-ruby libmysqlclient-dev

Installation de Rails, Bundler et Passenger

sudo gem install rails bundler passenger --no-ri --no-rdoc

Installation de Nginx avec Passenger

sudo passenger-install-nginx-module

Appuyez sur Entrée au message d'accueil pour passer à l'installation. Puis entrez le chiffre 1 pour choisir "download, compile, and install Nginx for me" et appuyez sur Entrée. Ensuite acceptez les valeurs par défaut pour toutes les autres questions.

wget -O init-deb.sh http://library.linode.com/assets/660-init-deb.sh
sudo mv init-deb.sh /etc/init.d/nginx
sudo chmod +x /etc/init.d/nginx
sudo /usr/sbin/update-rc.d -f nginx defaults

sudo /etc/init.d/nginx stop
sudo /etc/init.d/nginx start

Configuration de Nginx

Modifier le fichier /opt/nginx/config/nginx.conf afin d'obtenir quelque chose comme ceci :

server {
listen 80;
server_name localhost;
root /home/ubuntu/www/sample/public;
passenger_enabled on;
}

Pensez à bien supprimer ou commenter les lignes suivantes :

location / {
root html;
index index.html index.htm;
}

Puis redémarrer le serveur Nginx avec la commande suivante :

sudo service nginx restart

Création d'un projet pour tester l'environnement

mkdir /home/ubuntu/www; cd /home/ubuntu/www
rails new sample -d mysql

Configuration du pare-feu

Dans la console d'administration EC2, cliquez sur "Security Groups" dans le sous-menu "Network & Security". Sélectionnez la première ligne qui devrait s'appeler "quicklaunch-0", puis dans le panneau de propriétés du bas, sélectionnez l'onglet "Inbound".

Créez une nouvelle règle en sélectionnant HTTP dans la liste de choix "Create a new rule", en laissant 0.0.0.0/0 dans "Source" et en cliquant sur "Add rule".

Cliquez sur "Apply Rule Changes" pour appliquer les changements.

Vous pouvez maintenant tester si l'application Rails fonctionne correctement en tapant l'adresse DNS publique temporaire de votre instance EC2 dans votre navigateur. Vous pouvez récupérer cette adresse dans la console d'administration EC2, menu "Instances", onglet "Description", valeur "Public DNS". Cette adresse est susceptible de changer à chaque redémarrage de votre instance.

Si vous obtenez cet écran, c'est que tout fonctionne correctement !

Dans la deuxième et dernière partie de cet article, nous verrons comment configurer Capistrano pour simplifier le déploiement de notre application sur notre instance EC2, et comment configurer Rails pour utiliser RDS (Relational Database Service) et SES (Simple Email Service).

Cet article a pour objectif de vous donner quelques astuces pour mettre toutes les chances de votre côté.

Pour ceux qui ne connaissent pas ce qu'est la WebCup, il s'agit d'une compétition où il est demandé de réaliser une site internet en 24h. Vous pouvez y aller en équipe ou en solo, que vous soyez professionnel, étudiant ou amateur.

Définissez votre baseline

Avant tout, vous devez savoir quelle direction vous voulez prendre, et quels sont vos objectifs. Voulez-vous remporter le Grand Prix du Jury, le Prix du Meilleur Graphisme ou le Prix du Meilleur Développement ? Ou peut-être même les trois ?

En fonction de vos objectifs, vous saurez sur quels éléments vous allez devoir vous focaliser pendant la compétition.

Ensuite, vous devez savoir si vous voulez vous orienter vers un style sérieux, "corporate", réaliste, sophistiqué, futuriste, fun, humoristique, ou que sais-je ? Il est important de prendre cette direction suffisamment tôt, et de la garder en tête pour toutes vos décisions futures. Votre site en sortira plus cohérent et fort d'un esprit bien ancré.

Commencez par la fin

Ce qu'il faut savoir, c'est que la WebCup est une compétition impitoyable ! Vous n'avez que cinq petites minutes pour défendre un travail réalisé en 24h, devant un jury qui ne demande qu'à être impressionné. Vous l'avez donc compris, la présentation finale de votre site est très importante si vous espérez obtenir un prix.

Mise en scène

Vous devez commencer par réfléchir à la mise en scène de votre présentation finale. Chaque seconde doit être calculée et utilisée à bon escient. Pour cela, réfléchissez et répondez aux questions suivantes :

• Quelles fonctionnalités souhaiteriez-vous présenter ? (astuce : choisir les fonctionnalités qui ont le plus de potentiel pour que les membres du jury poussent un "Wooaaaw !!")
• Le jury peut-il être sollicité ou impliqué ? (la seule réponse possible devrait être oui !) Comment ?
• Le public peut-il être sollicité ou impliqué ? Si oui, comment ?

Une fois que vous avez votre liste de fonctionnalités, classez les par importance (c'est simple, le plus gros "Woooaaaaw !!" en premier, le plus petit en dernier). C'est dans cet ordre que vous allez les développer par la suite.

Casting

Une fois que vous avez terminé la mise en scène, il vous reste à attribuer les rôles. Si vous êtes en solo, la question ne se pose même pas. Si vous êtes une équipe, vous devez choisir la personne ayant le plus de charisme et d'aisance devant une "assemblée". Si votre équipe ne dispose pas d'un tel profil, choisissez la personne qui parle le plus fort et le plus clairement possible.

Vous pouvez aussi décider que plusieurs personnes s'expriment lors de la présentation, mais uniquement si cela apporte une plus-value (mouvement, dynamisme), et si chaque personne respecte son temps de parole.

Les autres membres de l'équipe qui ne parlent pas peuvent servir d'assistants pour manipuler le site web, faire défiler une diapositive, faire passer un objet au public ou au jury, etc.

Développez d'abord les tâches prioritaires

Ne nous leurrons pas, il est impossible de terminer à 100% un site web en seulement 24h. Du moins pas le genre de site demandé pour cette compétition. L'objectif est bien entendu de vous apprendre à repousser vos limites, de vous comparer aux autres acteurs du marché local, de vous amuser... mais surtout de voir si vous êtes capable de définir correctement vos priorités.

Si vous connaissez un peu les méthodes agiles, vous comprendrez toute de suite où je veux en venir dans le paragraphe suivant. Sinon je vous suggère de vous documenter sur le sujet.

À mon sens, la WebCup s'inscrit très bien dans les valeurs des méthodes agiles, dont voici le Premier (avec un P majuscule) principe :

La plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à forte valeur ajoutée

24h pour une première version, je trouve que c'est suffisamment rapide, tout comme le préconise le manifeste agile.

Des fonctionnalités à forte valeur ajoutée signifie que vous devez absolument commencer par les tâches prioritaires, et dans notre cas ce sont celles qui vont sublimer le jury.

Pour cela, la WebCup représente un très bon exercice pour tous ceux qui souhaitent mettre en pratique les méthodes agiles et les inclure dans leurs méthodes de développement.

Ne laissez rien au hasard

Attention, la WebCup c'est du sérieux ! N'allez pas croire que vous allez vous en tirer avec un simple coquille vide, c'est-à-dire avec quelques beaux écrans et quelques animations et sans réel développement derrière. En effet, entre la fin de la compétition et votre présentation devant le jury - ce qui représente environ 2h de temps - des experts scrutent votre code et vérifient que votre site est réellement fonctionnel. Chaque fonctionnalité est testée - en votre compagnie - puis évaluée.

C'est pourquoi une fois que les fonctionnalités principales sont développées à 100%, et prêtes à être présentées au jury, vous pouvez vous concentrer sur les fonctionnalités secondaires. Ne laissez rien au hasard, même les plus petits détails feront la différence.

Bon courage, et dites-moi si cette méthode vous a (ou "aurait") été utile.

N.B. : Cet article n'est pas affilié à l'association WebCup, et tout ce qui y est écrit l'est en mon nom, et non à celui de l'association WebCup. Le nom WebCup est une marque déposée.

Le temps passe et les outils ont évolué, une petite mise à jour s'impose donc !

Voyons ensemble la démarche à suivre pour déployer une application Rails 3.1 sur Heroku (Cedar)

Prérequis

• Installer Git :$ apt-get install git-core
• Avoir une application Rails qui fonctionne
• Placer le code source de l'application Rails sous Git (versionning)
• Créer et configurer votre clé SSH
• Créer un compte sur le site heroku.com
• Installer la gem Heroku : $ gem install heroku
• Ajouter votre clé SSH au server Heroku : $ heroku keys:add

$ heroku create -s cedar my_app

group :production do
  gem 'pg'
end

gem 'pg'

group :assets do
  gem 'coffee-rails', '~> 3.1.1'
  gem 'uglifier',     '>= 1.0.3'
end

gem 'sass-rails', '~> 3.1.4'

rake assets:precompile RAILS_ENV=production

git add public/assets
git commit -m "add public/assets into repo and set up locally compiled assets"

git push heroku master

-----> Preparing app for Rails asset pipeline
       Detected manifest.yml, assuming assets were compiled locally

gem 'execjs'
gem 'sass-rails', '~> 3.1.4'
gem 'compass'
gem 'haml'

project_type = :rails
http_path    = '/'
css_dir      = 'tmp/stylesheets'
sass_dir     = 'app/views/stylesheets'

require 'fileutils'
FileUtils.mkdir_p(Rails.root.join("tmp", "stylesheets"))

Rails.configuration.middleware.insert_before('Rack::Sendfile', 'Rack::Static',
    :urls => ['/stylesheets'],
    :root => "#{Rails.root}/tmp")

/public/assets/*

git add .
git commit -m "ignore public/assets and set up assets compilation during deployment"

git push heroku master

-----> Preparing Rails asset pipeline
       Running: rake assets:precompile

-----> Preparing Rails asset pipeline
       Running: rake assets:precompile
       ERROR: Unable to connect to memcached
       Precompiling assets failed, enabling runtime asset compilation
       Injecting rails31_enable_runtime_asset_compilation

config.action_mailer.default_url_options = { :host => 'localhost:3000' }

config.action_mailer.default_url_options = { :host => 'yourapp.heroku.com' }

heroku addons:add sendgrid:starter

heroku run rake db:migrate

heroku run rake db:seed

heroku run console

Au total, 23 projets ont été pitchés, 13 ont été retenus par le staff, et 10 sont arrivés au terme des 3 jours.

J'ai essayé de faire un petit récap des projets selon mes souvenirs, dans l'ordre de passage. J'ai également donné mon avis (qui reste mon avis), et une note (je me base sur la qualité du pitch, le potentiel du projet, et sa capacité à être rentable rapidement et sur le long terme).

1. Servanoo

C'est une sorte d'Amazon, mais pour la restauration. En gros, il est tard, on est fatigué et on a faim. On se connecte sur Servanoo. On choisit son/ses repas et on commande (j'imagine que le paiement se fait en ligne?). Servanoo s'occupe de passer la commande auprès du/des prestataire(s) (restaurant, pizzeria, etc) et de lui donner les informations de livraison. Le(s) prestataire(s) livrent directement chez nous. On mange.
Business Model : Récupérer une commission sur chaque commande effectuée

Mon avis : L'idée peut être bonne, mais beaucoup de détails sont passés à la trappe (logistique, beaucoup de restaurant ne livrent pas à domicile, frais d'hébergement du site web, etc). Il faut également se poser la question si ce service répond réellement à un problème/besoin.
Ma note : 2/10

2. Fleur d'arôme

C'est un présentoir de bouteille de vin en forme de moule ouverte (dit comme ça, c'est pas très glamour), qui a l'avantage de présenter la bouteille sous un nouvel angle, avec un éclairage original et un système de refroidissement par coussinet (pour maintenir la bouteille à la bonne température).
Business Model : Tout simplement, le vendre à un maximum de clients dans le réseau CHR (Café - Hôtel - Restaurant)

Mon avis : Je ne m'y connais pas de tout dans le domaine de la présentation de vin, donc je ne pourrais pas dire si ce projet est innovant. Si c'est le cas, pourquoi pas ? Mais je doute qu'une startup puisse se reposer sur ce seul produit. À mon avis pour se lancer dans ce domaine, il faudrait avoir au moins une dizaine de produits similaires (ou au moins, d'autres idées, d'autres concepts), pour fournir au client un minimum de choix. Ensuite il était question de breveter le double système éclairage/refroidissement. Dans ce cas, il faudrait absolument basculer le produit dans une gamme de luxe, pour espérer récupérer l'investissement et l'énergie dépensée pour l'obtention du brevet !
Ma note : 4/10

3. LiveReunion

Il s'agit pour ce projet de faire mieux que les PagesJaunes et Reunitoo. Comment s'y prendre ? En faisant un mix de ces deux concurrents et en prenant le meilleur de chacun : plus étoffé que Reunitoo (grâce à la gratuité pour les annonceurs) et mieux fournis en information que les PagesJaunes (présentation des produits des annonceurs).
Business Model : La publicité, et le développement de modules spécifiques pour certains annonceurs (si je me souviens bien)

Mon avis : Beaucoup d'entreprises s'y sont essayées et se sont cassées la figure. Plus récemment, MyVisite360, qui pourtant propose un produit "innovant" et différent de la concurrence, n'a pas réussi à séduire les annonceurs et à prendre son envol.
Je pense qu'il faut un projet beaucoup plus solide et novateur pour se lancer dans ce domaine.
Ma note : 2/10

4. GreeFood

Ce projet consiste à fabriquer de la farine alimentaire protéinée à base d'insectes, dans un premier temps pour nourrir les animaux, puis dans un second temps pour nourrir l'Homme. Pour résumer, si j'ai bien compris le procédé, il s'agirait d'ébouillanter les petites bestioles, puis de les faire sécher avant de les réduire en poudre/farine. Et tout ceci sans perdre les caractéristiques bénéfiques des insectes, notamment leur fort taux en protéine.
Business Model : Vendre cette farine alimentaire protéinée à un maximum d'agriculteurs locaux (pour résumer). Visiblement, la fabrication de cette farine alimentaire serait moins coûteuse, et plus respectueuse de l'environnement.

Mon avis : Projet intéressant et novateur, mais qui pourrait faire peur à certains agriculteurs. Une petite étude sur les effets de cette nouvelle alimentation sur les animaux en rassurerait plus d'un. Dommage également de proposer un prix plus élevé que la farine alimentaire utilisée actuellement par les agriculteurs, qui ne verront pas forcément d'intérêt de s'y lancer. En partant sur un prix de départ légèrement plus bas que le marché, cela couplé avec un label "Bio", il est nettement plus probable que de nombreux agriculteurs adoptent le produit les yeux fermés.
Ma note : 6/10

5. GreenWifi Everywhere

Le but de ce projet est noble : fournir un accès Wifi à tous, gratuitement. Comment ? Grâce à l'énergie solaire, qui alimenterait les différents spots repartis un peu partout sur l'île. Et pour couronner le tout, l'idée est de fournir un accès complet, en garantissant une connexion permanente, même en déplacement ("roaming" wifi).
Business Model : Aucun...

Mon avis : Ce projet repose uniquement sur les aides/subventions des collectivités, et ne génère quasiment aucun revenu. Bien que l'intention soit noble, elle n'en est pas pour autant viable. La réalisation de ce type de projet serait plutôt la vocation d'une fondation ou d'une association à but non lucratif. Une startup (et toute entreprise) est faite évidemment pour aider les gens, mais aussi (et surtout) pour générer de l'argent !
Ma note : 1/10

6. SuperBook

Ce projet a vraisemblablement connu plusieurs retournements de situation. À l'origine, le but du projet est de fournir une nouvelle expérience de lecture en proposant du contenu immersif pendant la lecture d'un livre sur une tablette. Le bruit de la pluie sur la tôle, l'orage, un coup de feu... ce sont autant d’évènements sonores qui pourraient venir accompagner votre lecture et vous immerger encore plus dans l'histoire que vous lisez. Mais après avoir découvert que le projet existait déjà outre-atlantique, et qu'un brevet aurait été déposé, l'équipe décide de se focaliser sur un genre particulier (les mangas) et imagine un tout nouveau concept. Les évènements sonores se déclencheraient maintenant de manière automatique, grâce à un procédé qui permet de détecter le positionnement des yeux sur la page (via la caméra frontale de l'appareil).
Business Model : Vendre aux éditeurs des licences d'utilisation de leur kit de développement qui permet de fabriquer des "SuperBook" + une commission sur chaque "SuperBook" vendu (du moins je l'imagine, je ne me rappelle plus exactement)

Mon avis : Grâce à un pitcheur charismatique et une équipe déjà bien formée, on a eu droit à une présentation bluffante (et immersive) pour ce projet innovant. Ce projet nécessitant une bonne maîtrise technologique et une veille concurrentielle accrue risque de rencontrer des difficultés à la hauteur de leur ambition. Ils ont tout intérêt à bien s'entourer, des points de vue technologique et juridique notamment.
Ma note : 8/10

7. Cherry Redlips

Il parait qu'une vague de mode "rétro" s'empare de la France, et Cherry Redlips compte bien en tirer profit. Sur la base d'un système de distribution à la Tupperware (ou Frédéric M, et cie), l'objectif est de proposer à une clientèle féminine un catalogue de vêtement s'inspirant des années 20 à 50 aux États-Unis. Il sera possible de parcourir le catalogue de produit en ligne, et certainement d'y faire des achats. Des réunions seront également organisées (toujours sur le modèle Tupperware) où les clientes pourront toucher et essayer certains vêtements pré-sélectionnés.
Business Model : "Tupperware-like"

Mon avis : Pourquoi pas ? Le système de distribution est rôdé, on n'invente rien, donc on ne prend pas beaucoup de risque à ce niveau. Malheureusement le succès du projet dépend beaucoup de la tendance et de la mode actuelle (ou dans un futur proche), et n'offre donc très peu de perspective dans l'avenir... Évidemment ce n'est pas une excuse pour ne pas se lancer dans ce genre d'aventure, à condition de continuer la veille et de guetter les prochaines tendances.
Ma note : 5/10

8. BTPlink

Une plateforme permettant de simplifier les relations (et "restaurer la confiance") entre les particuliers et les artisans.
Business Model : Prélever 6% de commission sur le prix total du chantier.

Mon avis : J'avoue ne pas avoir suivi la présentation entièrement, donc je ne pourrais pas en dire grand chose. Je me rappelle que le jury avait relevé un problème de positionnement vis-à-vis des architectes, ou encore concernant la gestion des aléas (retards, non qualités, etc). Le pitcheur a été très déstabilisé et n'a pas su répondre correctement. On voit que le projet n'est pas encore mature et manque clairement de stabilité. Un projet à creuser et à bien ficeler de bout-en-bout, par exemple en sondant les principaux acteurs du marché sur le fait d'avoir ce nouveau type d'intermédiaire.
Ma note : 4/10

9. Saint-Denis Pass

Il s'agit de proposer au dionysiens des avantages dans les commerces de Saint-Denis, et cela proposé par un natif de la ville. Attention, il ne compte pas s'arrêter là. Une fois la ville de Saint-Denis "maîtrisée", il compte créer le Saint-Pierre Pass, le Saint-Gilles Pass... et j'en passe.
Business Model : Chaque commerçant partenaire reverse 200€/mois, en échange d'une augmentation "significative" de clients.

Mon avis : 3 points négatifs pour ce projet. D'une part, c'est aberrant de cibler uniquement les commerçants et les habitants de Saint-Denis. Pour une petite île comme la Réunion, ce ne serait pas de la folie de lancer directement une carte pour l'ensemble des habitants de l'île. Et dans l'optique de lancer une carte par grande ville, comment les clients vont s'y retrouver avec leur dizaine de carte en poche ? Deuxièmement, il semble que le meneur de ce projet n'a pas conscience de la concurrence déjà en place (Sésame, qui donne également des avantages à Maurice, Cartatout, Bourbon Avantage, etc), ou du nombre d'échecs précédents dans le domaine. Finalement, ce projet n'a rien d'innovant. Il aurait été largement plus intéressant de proposer un système de cartes de fidélité centralisées (chaque commerçant garde l'identité sur sa carte de fidélité) et se basant sur la technologie du futur : le NFC (à bon entendeur, vous savez ce qu'il vous reste à faire).
Ma note : 1/10

10. Dream 2 Real

Le but de ce projet est de créer un coffret cadeau, du même genre que les coffrets Aladin, mais cette fois-ci à destination d'un public bien spécifique : les personnes à mobilité réduite. Le coffret, qui se décline en 3 versions (de 69€ à 149€, si mes souvenirs sont bons), permettrait aux handicapés d’accéder à des activités qui leur sont "à priori" inaccessibles. Un vol en ULM, un saut à l'élastique, ou encore un saut en parachute sont autant de rêves que pourront réaliser ces personnes grâce à Dream 2 Real.
Business Model : Vendre un maximum de coffret cadeau (évidemment). Même les coffrets non utilisés ont été pris en compte dans leur prévisionnel.

Mon avis : En plus de répondre à une juste cause, ce projet me semble tout à fait viable. Le business plan présenté est réaliste, on voit que le projet a été réfléchi et que les membres de l'équipe ont pensé à tout (avec l'aide des mentors, évidemment). Pour illustrer le sujet, la présentation se termine par une vidéo d'une personne qui effectue un saut à l'élastique en fauteuil roulant. Tout comme le jury, je m'étais demandé si cette personne s'en était sorti vivante... on voit dans la vidéo complète que oui, il s'en sort indemne
Ma note : 9/10

Mon classement est donc un peu différent de celui du jury :

1er : Dream 2 Real
2ème : SuperBook
3ème : GreeFood

Pour rappel, le classement du jury est celui-ci :

1er : SuperBook
2ème : Dream 2 Real
3ème : Fleur d'arôme
Prix spécial du jury : GreeFood

PS: je me suis basé essentiellement sur mes souvenirs pour rédiger cet article, donc si je me suis trompé quelque part, n'hésitez pas à me le signaler.

• Avoir une application Rails qui fonctionne
• Installer Git : $ apt-get install git-core

Placer votre code source sous GIT (versionning)

$ cd PATH/TO/MY_APP
$ git init
Initialized empty Git repository in .git/
$ git add .
$ git commit -m "new app"

Configurer votre clé SSH

Git utilise SSH comme protocole de transport sécurisé. Si vous n'en avez pas déjà une, vous devez créer une clé SSH et envoyé la clé publique sur Heroku. Avant de continuer, suivez les instructions pour savoir comment générer des clés SSH sous Linux. Pour savoir si vous pouvez passer à l'étape suivante, il suffit de vérifier que le fichier ~/.ssh/id_rsa.pub existe bien.

Créer un compte sur Heroku et créer votre application

Inscrivez-vous sur Heroku. Une fois que vous avez terminer la procédure d'inscription, il faut ouvrir un terminal pour installer le client Heroku (gem) :

$ gem install heroku

La gem Heroku installe un client qui permet de gérer toutes vos applications, les add-ons, les variables d'environnements, les clés SSH, les logs, et bien plus encore... tout cela en ligne de commande !

Pour avoir la liste complète des commandes disponibles, il suffit de taper $ heroku help ou simplement $ heroku

Avant de continuer, il est préférable d'ajouter immédiatement la clé SSH créée précédemment sur le serveur de Heroku. Ce qui permettra de déployer le code source sur le serveur par la suite :

$ heroku keys:add

Il n'y a rien d'autre à faire. Le script récupère automatiquement votre clé publique ~/.ssh/id_rsa.pub et l'envoie sur le serveur.

Voyons maintenant comment créer une application Heroku. Rien de plus simple :

$ heroku create
Creating hollow-summer-129... done
http://hollow-summer-129.heroku.com/ | git@heroku.com:hollow-summer-129.git
Git remote heroku added

Vous pouvez également spécifier le nom de l'application comme ceci :

$ heroku create my_app

On peut noter que la dernière ligne qui est renvoyée "Git remote heroku added" indique qu'un dépôt distant a automatiquement été ajouté à Git. Cette ligne n'apparait pas si vous lancer la commande $ heroku create depuis un dossier qui n'est pas soumis au système de versionning Git.
Pour vous en rendre compte, vous pouvez taper la ligne de commande suivante :

$ git remote
heroku
origin

Et pour avoir plus de détails :

$ git remote show heroku
* remote heroku
Fetch URL: git@heroku.com:hollow-summer-129.git
Push URL: git@heroku.com:hollow-summer-129.git
HEAD branch: (unknown)

La commande $ heroku open vous permet d'ouvrir un navigateur avec un message d'accueil vous indiquant que votre application a bien été créée, et qu'il ne reste plus qu'à la déployer.

Déployer votre code sur le serveur Heroku

$ git push heroku master
Counting objects: 65, done.
Compressing objects: 100% (58/58), done.
Writing objects: 100% (65/65), 80.54 KiB, done.
Total 65 (delta 14), reused 0 (delta 0)

Heroku receiving push
-----> Rails app detected
Compiled slug size is 0.1MB
-----> Launching....... done
App deployed to Heroku

To git@heroku.com:hollow-summer-129.git
* [new branch] master -> master

Voilààà ! Le déploiement est effectué... en une seule ligne de commande !

Bon il reste maintenant à mettre en place votre base de données, car votre application ne fonctionnera pas sans tables dans votre base :

$ heroku rake db:migrate

Il est bon de noter que toutes les commandes rake que vous avez l'habitude de lancer en local peuvent être lancer à distance grâce au client heroku. Par exemple vous pouvez lancer la commande suivante pour alimenter votre base avec les données par défaut :

$ heroku rake db:seed

Vous pouvez maintenant vous féliciter en admirant votre site déployé sur Heroku après avoir taper la commande $ heroku open

Utiliser un nom de domaine personnalisé (autre que *.heroku.com)

Pour cela, il faut d'abord installer un add-on Heroku : Custom Domains

$ heroku addons:add custom_domains:basic

Ensuite il suffit de spécifier le domaine à partir duquel vous voulez accéder à votre site comme ceci :

$ heroku domains:add hollow-summer.com
$ heroku domains:add www.hollow-summer.com

La plus grande difficulté consiste maintenant à modifier votre DNS via votre fournisseur de noms de domaine (ou de DNS) pour que votre nom de domaine (ici "www.hollow-summer.com") pointe vers les serveurs Heroku. Pour cela il faut modifier le Zone File pour obtenir un résultat comme ceci :

@ 3600 IN A 75.101.163.44
@ 3600 IN A 75.101.145.87
@ 3600 IN A 174.129.212.2
www 3600 IN CNAME proxy.heroku.com.

Si vous rencontrez des difficultés pour cette partie, cette vidéo vous aidera certainement.

Configurer l'envoi de mail avec SendGrid

Pour gérer les envois de mail depuis votre application Rails, il y a une solution assez simple qui consiste à envoyer vos mails en passant par votre addresse Gmail personnelle et par le serveur SMTP de Google. Voir comment faire ici.

Cependant, Heroku nous propose d'utiliser l'add-on Sendgrid, qui se repose sur le service d'envoi de mail très abouti du même nom. Plus d'infos sur Sendgrid ici.

Comme d'habitude, l'installation d'un add-on Heroku peut se faire en ligne de commande comme cela :

$ heroku addons:add sendgrid:free
Adding sendgrid:free to hollow-summer-129...done.

C'est tout ! L'add-on se charge de configurer votre application pour envoyer des emails en passant par Sendgrid.

Pour être sûr que tout va fontionner, on peut vérifier que les variables d'environnement sont bien définies avec la commande suivante :

heroku config --long | grep SENDGRID
SENDGRID_DOMAIN   = heroku.com
SENDGRID_PASSWORD = #password#
SENDGRID_USERNAME = #username#@heroku.com

Remarque :

L'installation du plugin Sendgrid crée automatiquement un compte sur le site sendgrid.com

Vous pouvez vous connecter en indiquant respectivement comme 'username' et 'password' les valeurs récupérées par la commande précédente pour SENDGRID_USERNAME et SENDGRID_PASSWORD.

Vous arriverez sur une interface d'administration complète, qui vous permettra entre autre, d'avoir des statistiques sur les emails envoyés par votre application, ou même de savoir si les destinataires ont ouverts l'email et/ou cliqués sur un lien dans l'email (si vous avez choisis les options).

Fin

Voilà, on obtient en très peu de temps une application déployée, fonctionnelle, avec envoi de mail opérationnel et nom de domaine configuré.

Je suis très impressionné par le travail réalisé par l'équipe d'Heroku. C'est vraiment un travail de pro !

Ensuite il suffit de lancer la commande suivante :

xmllint fichier.xml --schema http://monsiteweb.com/schema.xsd

Il est également possible de valider le XML à partir d'un DTD avec l'option --dtdvalid

Le programme indique le message suivant s'il ne trouve aucune erreur :

fichier.xml validates

Dans le cas contraire, le programme indique les erreurs à corriger pour valider le XML.

Il est bon de noter de xmllint vérifie aussi que le XML est bien formé sans tenir compte d'un éventuel schéma ou d'un DTD.

Super, rapide, efficace. Très utile lorsqu'on souhaite valider de gros fichier XML.

Pour les petits fichiers et si il n'y aucun linux à portée de main, ce site internet est très bien aussi : http://www.xmlvalidation.com/

Visiblement le premier site proposant ce type de service web est apparu vers 2001. Personnellement j'ai entendu parler de ce système en 2010, en même temps que j'ai découvert Twitter. Effectivement le principe prend tout son sens lorsqu'on sait que les messages sur Twitter sont limités à 140 caractères.

Dans ce contexte où les caractères sont comptés, la course au nom de domaine le plus court (pour un service de réduction d'URL) est lancée. C'est pourquoi depuis quelques temps on voit fleurir à tous les coins de rue ce genre de service. On peut même constater que plusieurs sites populaires ont créés leur propre réducteurs d'URL

• tinyurl.com (le précurseur)
• bit.ly (un des plus utilisé)
• is.gd (idem)
• boi.re (pour les alcooliques anonymes de la Réunion)
• clica.li (un autre fournisseur péi)
• fb.me (Facebook)
• goo.gl (Google)
• t.co (Twitter)

Connaissez-vous vraiment votre fournisseur de réducteur d'URL ?

Tout comme on souhaite pouvoir faire confiance à notre fournisseur de messagerie, notre hébergeur de données etc, je pense qu'il faut également se poser la question si on peut faire confiance à notre réducteur d'URL. Eh oui, qui nous dit que celui-ci ne va pas cesser de fonctionner du jour au lendemain (parce qu'il faut dire qu'il n'y gagne pas grand chose dans l'histoire) ? Ou qu'il ne va pas réclamer un abonnement ou autre compensation financière sous peine de voir tous nos liens rediriger vers une erreur 404 ? Bon je vous l'accorde, ce cas de figure ne peut se présenter que si les liens sont associés à un compte (comme les liens goo.gl peuvent être rattachés à votre compte Google par exemple).

Je vous pose donc la question : à quel point connaissez-vous votre fournisseur de réducteur d'URL ? À quel point lui faites-vous confiance ?

La sur-utilisation des réducteurs d'URL

Récemment, j'ai constaté que de plus en plus d'internautes utilisent des URL courtes en dehors de Twitter : sur le statut Facebook, leur site web ou encore leur blog.
Personnellement je ne comprends pas l'intérêt d'utiliser une URL courte si on n'est pas limité en caractères, si ce n'est de :

• rendre invisible la vraie URL de la page cible, et donc de dissuader l'utilisateur de cliquer dessus (les victimes d'un Rickroll seront encore plus farouches);
• perdre le bénéfice du référencement des moteurs de recherche qui se basent sur les liens entre sites (en vrai je ne sais pas vraiment comment les moteurs de recherche se débrouillent dans cette pagaille d'URLs courtes) ;
• dépendre d'un site tiers dont vous ne savez rien... juste pour faire un lien vers une page !

Conclusion

N'existe-t-il pas un système d'encodage réversible qui permettrait de retrouver l'URL originale grâce à un petit algorithme ? L'algorithme pourrait soit être commun à tous les fournisseurs, soit être différent mais à la condition d'être divulgué par le fournisseur.

En attendant qu'un fournisseur propose ce genre de solution, je suggère de n'utiliser les réducteurs d'URL que dans les cas suivants :

• lorsque c'est nécessaire (Twitter);
• si votre lien redirige vers une information éphémère (Twitter);
• si vous savez pertinemment que vous n'aurez pas besoin de ce lien d'ici quelques jours (Twitter)...

C'est une bonne façon de faire de la pub je trouve... malheureusement les règles du concours indique qu'il faut être sur le territoire des USA, Angleterre ou Canada (hors Québec, allez savoir pourquoi...) pour prétendre à la récompense :s Il ne reste donc plus qu'à y jouer pour le plaisir.

La 2ème épreuve du concours consistait à fouiller dans le code source d'une page web, extraire un code binaire d'un ASCII Art qui y était caché, et convertir ce code binaire en chaine de caractère pour obtenir une URL. Sur cette URL, un petit puzzle à remettre en ordre pour obtenir la phrase secrète !

Je me suis intéressé plus particulièrement à la conversion d'un code binaire en chaine caractère. Voilà le code binaire à transformer :
01101000011101000111010001110000001110100010111100101111011001110110111101101111
001011100110011101101100001011110110101001010000010011110100100101101100

Même si la conversion n'aurait pas pris beaucoup de temps en passant par une table de correspondance (comme celle-là), j'ai voulu m'amuser à créer un petit script qui aurait fait le boulot à ma place. Et puis on ne sait jamais, ça pourrait servir plus tard...

En lançant mon petit script, on obtient le résultat suivant : http://goo.gl/jPOIl

J'ai écris le script en Ruby. Ça m'a pris environ 20 minutes pour arriver à un résultat. J'ai perdu un peu de temps à comprendre qu'il fallait d'abord découper la chaine de caractère en paquets de 8 bits (car 1 caractère ASCII est codé sur 8 bits). Ensuite il a fallu trouver les bonnes méthodes à utiliser (String#unpack et Array#pack),  et surtout comprendre comment elles fonctionnent.

Le script est disponible ici.

Pour naviguer sur internet ou récupérer ses emails en toute sécurité depuis n'importe où (gallerie commerciale, boulot, etc)

Comment faire ?

Pré-requis : On va dire que vous avez un serveur chez vous qui tourne 24h/24 et sur lequel vous avez les droits administrateurs. Le client indique la machine (un laptop, PDA, etc) que vous utiliser pour naviguer ou récupérer vos emails sur la fameuse connexion non sécurisée.

La mise en place se déroule en deux étapes :

Sur le serveur (Ubuntu/Debian)

Il faut installer le serveur ssh (le serveur se lance tout seul après l'installation) :
apt-get install ssh # ou openssh-server

Remarque : pensez à configurer votre box pour accepter les connexions entrantes sur le port 22 (ssh)

Sur le client (Ubuntu/Debian) :

Il faut installer le client ssh (le client se lance tout seul après l'installation) :
apt-get install ssh # ou openssh-client

La commande suivante permet de se connecter à votre serveur domain.no-ip.org et à mettre en place une redirection de port dynamique :
ssh -D 8080 -Nf domain.no-ip.org

-D 8080 =>  indique que toute les connections qui seront effectuées sur le port 8080 seront redirigées vers le canal sécurisé.
-N => indique de ne pas exécuter de commande distante. Cette option est nécessaire pour la redirection de port.
-f => demande à ssh de tourner en tâche de fond. Pour arrêter la redirection de port, il faut tuer le processus (ps aux |grep ssh)

Il reste maintenant à configurer votre navigateur pour qu'il passe par votre canal sécurisé.
Avec Firefox (3.6.*), Édition > Préférences  > Avancé > Réseau > Paramètres. Choisissez Configuration manuelle d'un proxy, puis dans SOCKS, mettez localhost:8080.

Avec Ubuntu, un outil permet de configurer un Proxy qui sera valable à l'ensemble du système.
Allez dans Système > Préférences > Réseau Proxy. Choisissez Configuration manuelle d'un proxy, puis dans SOCKS, mettez localhost:8080.

Si vous avez effectué la manipulation précédente avec Firefox, pensez à remettre l'option Utiliser les paramètres proxy du système

C'est tout, vous pouvez désormais surfer en toute sécurité !

TODO : Sur le client (Android)

Tester la configuration

Vous voulez tester que votre configuration fonctionne ?

1- Désactivez le proxy (SOCKS localhost:8080)
2- Rendez-vous sur www.monip.org (ou tout autre site qui vous renseigne votre IP)
3- Notez l'adresse IP qui vous est attribué
4- Activer le proxy (SOCKS localhost:8080)
5- Répétez l'opération 2
6- Constatez que votre adresse IP a changé. C'est en fait l'adresse IP affectée à votre box depuis chez vous.
7- C'est bon ça marche !

Je me dis que c'est peut-être parce que je ne veux pas perdre mon uptime... mais il faudra bien m'y faire !