La distribution des logiciels Ohm Force

Ohm Force vend ses logiciels en ligne. Un business model facile à mettre en place quand on vend du logiciel, pas de stock, pas de contrat. Une bande d’ingénieurs et autres geeks est capable de mettre ça en place.

En plus le coût est très bas : la location d’un serveur, et le pourcentage que nous prend la banque pour traiter les paiements par carte de crédit.

La communication coûte aussi, mais on a toujours fait au moins cher, une newsletter, parfois de la pub et des groupbuys. Notre image et nos produits plaisent, et c’est pas pour rien qu’on est toujours là 7 ans plus tard ! (La communication, ça va changer bientôt avec l’arrivée d’un gars dont ce sera le boulot !)

Les distributeurs

Du coup, une idée qui revenait régulièrement dans les premières années d’Ohm Force était d’obtenir un contrat avec un distributeur qui prendrait en charge la communication, la force de vente, la fabrication du packaging et des DVD. On profite aussi de ses entrées dans les magasins de musique du monde. La contrepartie, c’est qu’Ohm Force ne touche que 25% du prix de vente, mais on compense avec le volume.

Voilà l’équation simplificatrice :

• en ligne : peu de ventes, beaucoup de sous par ventes

• en magasin, via le distributeur : beaucoup de ventes, peu de sous par ventes

La théorie est séduisante !

Mais c’est aussi faire un pacte avec le diable. Je simplifie encore un peu, mais passer par un distributeur, c’est signer un contrat standard réalisé par les avocats américains du distributeur. Le distributeur en question, c’est le plus gros du marché de la musique.

Le contrat contient un nombre de clauses terribles, avec en particulier l’interdiction, pour nous, sur le site web de faire de la concurrence avec les vendeurs de nos produits.

Donc pas d’offres promotionnelles sur notre site, on est obligé de vendre au même prix que les vendeurs retail. Avec une différence, ils vendent une boite, alors que nous on ne vend que du téléchargement.

Et il y a pire. Par contrat, on est obligé de vendre au MSRP (Manufacturer’s Suggested Retail Price), alors que les magasins peuvent descendre plus bas, au MAP (Minimum Advertising Price) et communiquer dessus. Et parmi les magasins, il n’y pas que les magasins de Pigalle, il y a aussi les revendeurs qui ont une présence en ligne.

Du coup, les plugins qui sont partis dans le circuit de distribution pouvaient être acheté en ligne moins cher ailleurs que chez nous.

Situation peu agréable, mais on va avoir du volume !

Ah non. Pas de volume. Ventes ridicules. Apparemment le distributeur a eu des problèmes avec SAP. Ce dernier disait qu’il n’y avait pas de stock, du coup les magasins ne pouvaient pas commander, alors que les boites s’entassaient dans les entrepôts. Ceci dit, on ne parle pas gros volume, la fabrication initiale était, si ma mémoire est bonne, que 1000 unités.

Et si on veut en sortir, c’est simple, le distributeur demande au développeur de racheter tous les invendus, (et tu pleures ton cash-flow)

La “Vente Download en Magasin”

Donc, pas de distributeur pour Ohm Force. La partie précédente ne s’appliquait pas directement à Ohm Force, mais à la société anglaise avec qui Ohm Force avait co-développé des instruments. Ohm Force touche des royalties.

Toutefois il est vrai qu’au bout de la chaîne, il y a le magasin, avec des vendeurs qui ont parfois très envie de vendre nos logiciels. On a déjà eu des requêtes de magasins qui achetaient sur notre site des plugins pour le compte d’un client.

L’idée nous est arrivée, il y deux ans. (oui, sur certains sujets, Ohm Force n’est pas très réactif)

On fait des DVD qui contiennent tous nos plugins, un joli présentoir, que le vendeur dispose dans son magasin.

Lorsque le client dans le magasin veut acheter nos plugins, il prend le DVD, et le vendeur se connecte sur une application web hébergée par Ohm Force, pour générer le numéro de série. Derrière on garde la trace de l’achat, et on envoie une facture regroupant toutes les ventes du mois.

Le vendeur peut régler directement sa facture avec sa carte de crédit sur l’application.

Les avantages

Le magasin n’a pas besoin de stock (sinon les DVD, mais ils sont dans une petite pochette carton). Il ne paye que ce qu’il a effectivement vendu, et n’a pas besoin de retourner les invendus, donc le cash-flow s’en trouve bien amélioré.

De notre côté, le contrat qu’on signe avec les vendeurs, est souple quant aux possibilités de promotions (des deux côtés d’ailleurs). Le coût de fabrication des DVD est minime, et on a un bon suivi des ventes.

Et pour finir, on enlève le middleman et sa part de 40% sera répartie entre nous et les magasins. Donc plus d’argent pour toutes les parties.

C’est du win/win !

Start small, scale later

L’application est depuis hier en phase de test. C’était mon travail dans le projet, j’aborderai dans un prochain post le côté technique – c’est une application JRuby on Rails hébergée sur un serveur GlassFish.

Nous avons quelques magasins qui sont très intéressés. Sur la côte Est des USA, sur la côte Ouest, et évidememnt, en France.

On va commencer en douceur, en commençant par la France, sur Paris, pour pouvoir discuter avec eux facilement et physiquement.

Est-ce que ça va marcher ?

Ohm Force y croit beaucoup !

PS : si vous avez un magasin de musique, et que ça vous intéresse, envoyez un mail sur contact@ohmforce.com avec VDM dans le sujet.

Je suis en train de tester NetBeans 6, en particulier pour mon développement Ruby on Rails.

Parmi les fonctionnalités les plus intéressantes (lire : celles qui me manquaient sur TextMate), on trouve

• l’intégration du debugger Ruby, qui fonctionne comme ça doit (un breakpoint dans la marge, l’exploration de la pile, les watchs et tout)

• la complétion ; plutôt intelligente pour une complétion de langage dynamique (donc plus dure à implémenter que pour Java)

• le support de Ruby on Rails : support du script generate (bon ok, c’était déjà dans TextMate, mais si je change, je ne vais pas revenir en arrière), templates RJS, RHTML etc.

• support Subversion natif. Comme ci-dessus, c’était déjà dans TextMate et dans Eclipse, mais je vais pas cracher dessus non plus …

J’avais testé une béta précédente qui ne m’avais pas autant impressionnée, mais là, respect, Sun.

Et pour finir, embarqué avec NetBeans, JRuby 1.0.1.

Maintenant, il va falloir voir à l’usage, et sur la longueur, le test des 3 minutes est réussi :)

Subtlety est une application web toute simple, et très pratique pour suivre des projets.

On donne l’url du repository subversion, et le site nous prépare un lien vers un flux RSS, qui poste les messages de commit et les fichiers modifiés par le commit.

J’ai perdu les commentaires … Je me prends des messages d’erreur à la publication. Faut que je fasse pointer mon blog vers quelque chose d’autre, mais je n’ai pas encore décidé quoi ? (Typo, Mephisto, WordPress, Blogger ?)

J’aime la possibilité de d’écrire mes posts sur un client plutôt lourd (pas de boite de dialogue, facilité d’insertion des images etc)

Une combo MarsEdit / qq chose qui tourne sur ma dédibox probablement …

EDIT : ce sera Mephisto

J’ai développé une application Rails pour Ohm Force en interne. Il est un peu trop tôt pour parler du contenu de cette application qui aura de toute manière une portée limitée – ce sera un extranet, qui devrait être en soi une expérience intéressante.

JRuby : Késako ?

Ruby est un langage de script plutôt populaire, et largement popularisé par Ruby On Rails, le framework qui rend le développement web amical. Il existe plusieurs interpréteurs Ruby. Le plus connu est l’implémentation de référence, celle qu’on appelle la MRI (Matz’s Ruby Interpreter ou Matz’s Reference Implementation) qui est développée principalement par Matz, l’inventeur de Ruby.

Depuis quelques temps, la machine virtuelle Java s’est enrichie d’autres langages que le Java. Le plus connu est probablement Groovy . Mais certains se sont mis en tête de développer une implémentation de Ruby sur la JVM. Ca a bien plu à Sun qui a embauché les devs principaux de JRuby.

JRuby : Pourquoi ?

• Parce qu’on peut le faire !

• Avec la popularité de Java en entreprise, cela permet très facilement de réutiliser des classes et des objets Java directement en Ruby.

• Les conteneurs d’application Java ont 7 ans d’existence, sont fiables et permettent une grosse montée en charge, ce que les techniques d’hébergement actuelles Rails ne permettent pas avec autant de souplesse.

JRuby : A Ohm Force ?

C’est pas un mystère pour ceux qui lisent ce blog, mais ca fait un moment que je suis à fond dans Ruby, et j’aimerai bien que mes développements futurs soient en Ruby. Actuellement à Ohm Force, on utilise Tomcat 5.5 pour le site web, avec un suite de Frameworks relativement standards : Struts, OJB, ACEGI, une pincée de Spring, Javamail. Il est évident que si on doit déployer une nouvelle application, si c’est une webapp avec des servlets et des JSP, on sait faire en interne.

L’appli est maintenant déployé sur le serveur de test en attendant une validation (qui finira bien par arriver ;) )

Et c’était facile ?

Oui et non.

Oui : pour le développement, c’est plutôt simple, une fois que JRuby est installé, il suffit de taper jruby plus ruby dans la console, et ca marche. Le démarrage est un peu plus long qu’avec la MRI, parce qu’il faut que la JVM démarre, mais une fois en route, les performances semble vraiment similaires.

Pour le déploiement par contre, j’ai eu plus de problèmes qui m’ont coûté 2 jours et quelques surprises.

La mémoire !

La JVM limite la mémoire disponible. Par défaut, le tas est à 64Mo, c’est très largement insuffisant pour l’intégration Rails sur Tomcat. Avec 256Mo, ca passe beaucoup mieux :) Donc JRuby coûte très cher avec Tomcat. J’avais 4 webapps qui tournaient sur 64Mo de RAM sur mon MacBook Pro, donc évidemment peu de trafic. En ajoutant mon appli sous JRuby, les besoins passent à 170Mo. Pour une utilisation mono-utilisateur …. Par contre, mon analyse me laisse à penser que plus de trafic et une application Rails beaucoup plus complexe n’augmentent pas significativement l’occupation mémoire.

Toutefois il faut être prudent dans le développement/portage d’applis sous JRuby. La MRI demande au système autant de mémoire que nécessaire, attaquant la swap si nécessaire. JRuby est complètement limité par la mémoire allouée à la JVM, et si ça dépasse, on se prend ça :

  java.lang.OutOfMemoryError : Java heap space.

Et ca fait tomber aussi les autres applis dans le même conteneur, vu qu’elles n’ont plus de mémoire non plus.

Le réglage de la JVM : Il faut passer les paramètres suivant à la JVM pour un tas de taille fixe de 256Mo : java -Xms256m -Xmx256m

L’intégration et Tomcat : GoldSpike

Il y a un plugin Rails qui s’appelle GoldSpike .
Ce plugin contient :

• Des tâches Rake pour construire un WAR

• 2 servlets qui servent les fichiers dans public/ et l’application Rails proprement dite.

L’utilisation est assez simple, mais plusieurs problèmes se sont présentés. GoldSpike embarque la jar deJRuby, sauf qu’il utilise la version 0.9.9. J’ai du aller modifier dans le code source la version de la Jar : Dans le fichier lib/war_config.rb à la ligne il faut mettre

 addjavalibrary(maven_library('org.jruby', 'jruby-complete', '1.0')) 
   

Ensuite pour ajouter les jar autres nécessaires à mon projet (le driver Postgres et une jar de classes internes à Ohm Force), il a fallu lire un peu de code source pour comprendre. La recette :

1. Copier les jar dans lib/java de votre projet Rails

2. Créer un fichier config/war.rb avec pour chaque jar la ligne :

   
   include_library 'postgresql', :version=>'8.0', :locations => 'lib/java'

3. rake war:standalone

L’archive est bien construite il faut l’envoyer sur le tomcat.

Finalement j’ai décompressé le war, et c’est ce que j’ai créé comme projet sur le subversion de boite. Plus simple de déployer, et ça me fait une arborescence qui marche à la fois avec Mongrel et sous Tomcat.

Une fois détectée par Tomcat, l’archive s’installe et jruby est lancé.

Mais c’est pas fini, il faut que je modifie le schéma de la base. Problème, je n’ai pas rake. Du coup je suis obligé d’installer JRuby sur le serveur avec un set de gem minimum pour que rake db:migrate fonctionne. Faudrait creuser quand même, je pense qu’on peut faire mieux :)

L’appli démarre !

C’est pas encore fini, sur mon MacBook Pro, il faut une dizaine de secondes pour que les interpréteurs ruby soient lancés et que Rails commence à accepter les requêtes.

Comment ça marche ? Ce paragraphe fait suite à une analyse très superficielle du code source des servlets GoldSpike .
Rails n’est pas du tout threadsafe. Vraiment pas. Donc ce que fait la servlet, c’est charger un certain nombre d’interpréteurs Ruby qui chargeront chacun une instance de l’application Rails. (D’où les problèmes de mémoire). Du coup chaque instance Rails est isolée.

Affiner la configuration de la webapp. Dans le fichier WEB-INF/web.xml, on peut passer des paramètres à la servlet pour indiquer le nombre d’instance de Rails il démarre :

 <servlet> 
  <servlet-name>rails</servlet-name> 
  <servlet-class>org.jruby.webapp.RailsServlet</servlet-class> 
    <init-param> 
        <param-name>jruby.pool.maxActive</param-name> 
        <param-value>4</param-value> 
    </init-param> 
        <init-param> 
        <param-name>jruby.pool.maxIdle</param-name> 
        <param-value>4</param-value> 
    </init-param> 
        <init-param> 
        <param-name>jruby.pool.minIdle</param-name> 
        <param-value>2</param-value> 
    </init-param> 
      <init-param> 
        <param-name>jruby.pool.timeBetweenEvictionRunsMillis 
            </param-name> 
        <param-value>10000</param-value> 
    </init-param> 
 </servlet> 
   

J’ai mis les valeurs par défaut. Le dernier paramètre correspond au temps entre deux invocations du thread destructeur d’instances.

ActiveRecord-JDBC

Pour se connecter à la base, JDBC est là ! Et la gem activerecord-jdbc permet de se connecter à une base de données directement ou via un pool de connexions managé par Tomcat.

Pour conclure

Jusque-là mes expériences ont été globalement positives. J’ai eu des petits soucis, mais comme à chaque fois lorsqu’on teste une nouvelle techno. J’attends évidemment les versions à venir de JRuby qui vont maintenant se focaliser sur la performance – JRuby est un interpréteur valide de Ruby 1.8.5. Pour le passage en production, je m’inquièterai juste de la consommation mémoire.

Pas de fuites toutefois. La JVM reste stable autour de 170Mo depuis 4 jours et 17h.

[MAJ : Je ne poste plus trop sur le sujet – ça marche bien et pas de problème.]