Neat stuff !
By the way I’m not lost for blogging. I’m in a middle of something that should spawn many blog posts in a not so distant future.
In the meantime, I do update my twitter quite often.
And I recommend you geeks to read Charles Stross. The man writes among the finest SF books I ever read.
Cid, notre nouveau responsable de la communication à Ohm Force, reprend en main le blog d’Ohm Force.
C’est ici, c’est enrichi très régulièrement, alors ajoutez-moi ça à votre NetNewsWire, Google Reader ou Netvibes.
Y a un concours de tutorial vidéo en ce moment, avec des tas de cadeaux (oui, des plugins Ohm Force bien sûr).
Je suis en train de faire migrer Ohm Force d’IRC à full Jabber.
Ca marche bien, mais il manque une fonctionnalité indispensable :
Que ca bippe le client quand dans une chatroom, on cite mon nickname.
Pour iChat, c’est facile avec AppleScript:
using terms from application "iChat"
on chat room message received theMessage from theBuddy for theChat
set theUser to "VOTRE NICKNAME"
if theMessage contains theUser then
say theUser
end if
end chat room message received
end using terms from
Tout ça dans le script editor, on enregistre dans le rep ~/Library/Scripts/iChat sous le nom de beep.scpt et ensuite on configure comme ça :
Pour Spark, j’ai du écrire un plugin. Rapide, j’ai passé plus de temps à trouver comment le compiler qu’à l’écrire.
J’ai pris le son bell.wav de Spark, et je l’ai embarqué dedans.
Pour le télécharger, c’est ici : beep.jar.zip
Il faut dézipper, et glisser la jar dans le répertoire plugins de Spark.
Sur Mac et Linux, cherchez dans le répertoire Spark à la racine de votre compte. Sur Windows … j’en sais rien.
C’est dans la même licence que Spark, et si vous voulez le code source, contactez-moi.
(oui, je dois toujours configurer mon serveur SVN pour l’accès public)
Une fonctionnalité qui complémente bien celle-ci est l’autocomplétion des nicknames. Mais c’est beaucoup plus de travail, donc c’est pour plus tard !
Pour l’instant, dites à vos amis de choisir des nicknames plus courts.
Ça y est, le serveur d’application Ohm Force est passé sous GlassFish 2.
Maintenant le serveur est organisé avec :
Avant le setup était globalement le même, mais avec Tomcat 6.
Plutôt agréable à utiliser. C’est une grosse machinerie qui se laisse manipuler assez facilement. Toutefois la doc est vraiment volumineuse, et rien que chercher les infos dedans va prendre du temps.
Au cours du “portage” depuis Tomcat, j’ai utilisé 2-3 trucs :
touch .reload
Ca force GlassFish à recharger la webapp, si c’est fait à la racine du répertoire de celle-ci. Il faut avoir configurer GlassFish pour autoriser l’autoriser.
C’est plus agréable au final que la méthode automatique de Tomcat. On a le droit de choisir quand ça arrive :)
Par contre ce redéploiement change la conf des webapp dans le domain.xml
asadmin set server.http-service.virtual-server.server.property.allowLinking=true
Permet d’utiliser des liens symboliques dans les webapps servies par le serveur virtuel server.
~/.asadminpasset~/.asadmintruststore
Ces fichiers stockent les identifiants pour administrer GlassFish via asadmin.
asadmin deploydir <i>rep</i>
Déploie ou redéploie la webapp dans le répertoire rep.
$GLASSFISH_ROOT/domains/domain1/config/domain.xml
Le fichier de configuration, celui modifié par l’interface d’admin. Evidemment, il faut redémarrer le serveur après une modification.
$GLASSFISH_ROOT/domains/domain1/lib/
Les jars placées ici sont accessibles dans tous les classloaders du domaine. Pour pouvoir utiliser les datasources avec PostgreSQL, on place la jar du driver dans le sous-repertoire ext/ (et pas databases/!)
GlassFish a tendance à cacher les fichiers des webapps $GLASSFISH_ROOT/domains/domain1/generated.
Faire un rsync entre deux serveurs pour synchroniser le répertoire de glassfish, c’est une mauvaise, très mauvaise idée. Les webapps ont récupéré la configuration de l’autre serveur, et les droits.
GlassFish semble vraiment plus solide que Tomcat. Il fait tourner les 3 webapp sans problème, alors que Tomcat ne supportait pas d’avoir l’appli jRuby on Rails, et crashait avec un vilain problème de mémoire.
L’interface d’admin … vraiment top. Quel changement ! J’utilisais Probe sur Tomcat, mais c’est pas aussi bien :)
Au démarrage, la présence de l’appli jRuby on Rails fait pomper au serveur 99% des ressources pendant plusieurs minutes. Je n’ai pas encore réussi à comprendre pourquoi … surtout qu’après on redescend à une charge tout à fait raisonnable. Mais j’aimerai comprendre …
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 !)
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)
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.
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 !
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.
Pour commencer, bonne année et meilleurs vœux pour cette nouvelle année !
Exercice obligatoire en cette période de l’année, une liste de résolutions. Avec un bilan en fin d’année 2008 (c’est ma première résolution, tiens, faire un bilan à la fin de l’année)
Peu de temps l’année passée pour fignoler MangerVite …
Toutefois une version iPhone me semble super indispensable, et j’ai envie de faire un peu de développement web pour cette plate-forme.
Parenthèse sur l’iPhone : pouvoir lire ses flux RSS dans le métro, priceless ! En bon utilisateur de NetNewsWire, j’apprécie l’intégration avec le version iPhone de NewsGator : mes flux sont synchronisés entre le téléphone et le MacBook Pro, et c’est bien pratique :)
Je vais continuer à travailler dessus. Un client développé avec Jiggy ? (oui, toujours pour iPhone, il est vrai que je suis assez emballé par ce téléphone).
Je vais aussi, mais c’est plus difficile, continuer de convertir du OhmMan à Jabber, pour finir par me débarrasser d’IRC. (let’s kill this beast !)
J’ai installé un ejabberd sur un serveur d’ohmforce, avec authentification LDAP, et remplissage automatique du roster avec la liste des OhmMen. Il me reste des problèmes d’encodage à régler avec la passerelle IRC, mais vu que j’ai corrigé le problème sur cestari.info, y a pas de raisons :)
Sur le protocole, il faut que je bosse sur pubsub, vu que j’ai pas réussi à faire tourner quoique ce soit d’intéressant (les exemples XMPP4R ne tournent pas avec ejabberd pre-2.0.0)
Evaluer GlassFish
Alfresco, en repository de documents avec workflow, multilingue et versionning, le tout accessible en ReST. Sexy beast. Il faut que je passe du temps dessus.
Grails et Groovy … je ne sais pas. J’étais assez emballé, jusqu’à ce que je m’y mette un peu. Le temps perdu par l’exécution des scripts (oui, il faut bien qu’elle démarre, cette JVM, et JRuby a le même problème) m’a bien refroidi, et je trouve la syntaxe de ruby tellement plus agréable …
Faut que je repasse un peu de temps dessus, pour affiner mod_rpc, et l’utiliser :)
Le site GForceSoftware nouveau est arrivé.
Il est hébergé sur le serveur d’Ohm Force dont j’ai la charge ; c’était une expérience intéressante, car je devait mixer une application à base de Servlets avec une application PHP, derrière le même domaine.
En frontal, il y a nginx, le serveur http russe léger et qui fonce.
Pendant 24 heures, il y avait un trou de sécurité flagrant, qui permettait de récupérer le code source des scripts php, à cause de svn. (je me suis tapé sur la tête quand je m’en suis rendu compte. Heureusement en analysant les logs, personne n’a eu l’idée de l’exploiter).
Le déploiement sur la production, c’est un checkout des scripts. C’est à dire que tous les répertoires ont un répertoire .svn qui contient les métadonnées sur les fichiers du répertoires ainsi qu’un cache contenant les fichiers originaux tels qu’ils sont stockés sur le repository svn.
Les fichiers originaux sont identifiés par une extension svn-base.
Or la configuration du serveur est d’envoyer le contenu tel quel pour une extension inconnue.
Du coup, on pouvait récupérer le code de la page d’index avec ce lien :
http://www.gforcesoftware.com/.svn/text-base/index.php.svn-base
Pas glop.
Donc pensez bien à ajouter la configuration suivante dans votre serveur web (ici pour nginx) :
location ~ .svn/ {
deny all;
}
C’est un des trucs qui me plaît le moins avec PHP, le fait que l’arborescence détermine l’URL, je préfère un MVC un peu plus abstrait comme avec les servlets ou avec Rails. On a beaucoup plus de souplesse, sans s’encombrer de rewrite rules trop complexes.
Vu que pour le MVC, toutes les URLs sont masqués derrière le contrôleur l’utilisateur ne sait même pas quel est l’arborescence système.
Sur le site Ohm Force, les JSP elles-même sont cachés dans le répertoire WEB-INF dont le contenu n’est pas publié.
On a reçu ça, il y a quelques jours sur jointeam@ohmforce.com de la part d’un ingénieur tout juste diplômé :
Je suis très intéressé par les stages de chef de projet, consultant ou d’ingénieur d’affaire. Néanmoins toutes autres propositions est la bienvenue.
D’habitude, on réponds poliment “non, merci”
Mais un élève ingénieur même pas diplômé qui veut faire chef de projet ou consultant en STAGE, ça sent un peu le pipo. Apprends à coder dans la vraie vie avant de viser ce genre de boulot.
Et dans le cas de “consultant”, comme le dit Steve Yegge ici, c’est un peu plus compliqué.
The problem with “consultant” is that it has two meanings. It can either mean “person who was hired on a contract basis to fill a coding need in the organization”, or it can mean “person hired to ‘consult’, aka ‘wank’, because the hiring organization is too clueless to solve their own problems and too incompetent to retain even one full-time staff member capable of helping them, so they turn to paid self-help.” When you see the word on a resume, it can be hard to distinguish which kind it is.
Du coup, concours informel pour savoir comment lui répondre.
Et c’est Lolo qui a proposé la meilleure réponse, et c’est celle qui a été choisie :
Source : Les LOLCats of course.
Plus tard : de la conf intéressante avec nginx + PHP + Tomcat.
Dans une organisation relativement décentralisée, l’utilisation de calendriers partagés permet un suivi, et une organisation facilitée.
L’année dernière, j’ai déployé à Ohm Force un intranet sous Plone. Avec, entre autres, une solution de calendrier partagé basée sur Calendaring.
Sauf que ça n’a jamais marché, en particulier avec une gestion des fuseaux horaire, et Calendaring pétait les calendriers locaux, en décalant les événements d’une heure à chaque mise à jour sur le calendrier local. Suffisant pour énerver n’importe quel utilisateur, et être sûr qu’il n’utiliserait jamais l’outil.
Personne du coup n’a utilisé l’outil, et le suivi est parti dans les limbes.
Franck, le bien aimé chef de projet à Ohm Force, m’a demandé si je pouvais remettre en place une solution.
J’ai regardé Google Calendars, qui est sympathique, et tout et tout, mais pas hébergé chez nous. Et nous, on aime pas trop les trucs pas hébergés chez nous.
J’ai repris le cahier des charges à la base. Et finalement, tout ce qu’il faut, c’est un serveur WebDAV.
Et un serveur WebDAV, sur un serveur qui fait déjà tourner Subversion et un serveur LDAP, ça s’installe en quelques lignes :
<Directory /var/www/dav>
Dav On
#Options Indexes FollowSymLinks
AllowOverride None
order allow,deny
allow from all
AuthName "LDAP"
AuthType Basic
<Limit GET PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Require valid-user
<IfModule mod_auth_ldap.c>
AuthLDAPURL ldap://localhost/ou=unit,dc=domain,dc=top
</IfModule>
</Limit>
</Directory>
Donc mon serveur webdav est accessible à sur l’url https://server/dav/. Oui, c’est du https, on est jamais trop prudent.
Ils y a deux clients principaux utilisés à Ohm Force :
Sunbird : le client de la mozilla foundation, qui s’améliore toujours.
iCal : le client de Mac OS X. Limité, mais l’interface utilisateur est sympa, (et je l’utilise depuis qu’il est sorti, je n’ai pas prévu d’en changer :)
un truc sous Linux dont le nom m’échappe.
Le cas iCal est intéressant car il ne fonctionne pas sur https.
De plus, iCal, dans sa version actuelle, (Leopard change apparamment tout ça), considère que le monde des calendriers est séparé en deux groupes :
Ceux qu’on publie (et à chaque modification, on écrase la version sur le webdav)
Ceux auxquels on est abonnés (ils sont en lecture seule sur le client).
La solution est stunnel, qui permet d’encrypter/décrypter des flux SSL.
Vous pouvez utiliser ces instructions de configuration, la partie “Access with login, Tiger (10.4)”
Il faut éditer le fichier /etc/stunnel.rulink.conf, en changeant l’url sécurisée vers le site de Rutgers U vers votre partage WebDAV.
Toutefois, la dernière fois que j’avais utilisé le binaire, il n’était pas compilé pour Intel, uniquement pour PPC. Ca tourne, mais c’est pas optimal.
J’ai crée un petit installeur qui permet d’installer le binaire. Le truc, c’est que le dev Mac n’est pas mon truc, et qu’il faut bricoler dans le terminal pour finaliser l’installation.
J’ai réalisé l’installeur pour Ohm Force, ce qui était facile, car le serveur de calendrier est le même pour tout le monde ; l’adresse du serveur est donc en dur.
Dans celui-ci, il faut modifier le fichier de conf après l’installation /etc/stunnel.ohmforce.com pour mettre la bonne URL, puis redémarrer le service avec sudo launchctl stop com.ohmforce.stunnel ; sudo launchctl start com.ohmforce.stunnel
Voilà l’image : HTTPS iCal.dmg.zip.
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.
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'))
Copier les jar dans lib/java de votre projet Rails
Créer un fichier config/war.rb avec pour chaque jar la ligne :
include_library 'postgresql', :version=>'8.0', :locations => 'lib/java'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>
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.]
A la demande de Franck, notre bon chef de projet d’Ohm Force, j’ai analysé les logs du site web pour voir la proportion d’utilisateurs utilisant des versions pirates.
Le résultat, bien qu’attendu dans ces proportions, est effrayant. 70% des gens qui visitent notre site en cliquant depuis un de nos produits les ont piratés.
Ca fait mal.
J’ai envie de rediriger les clés pirates détectées sur goatse.cx. (Mais je ne le ferai pas, parce qu’un faux positif arrivera forcément, et je ne veux pas prendre ce risque.)
On faisait hier l’analyse du triste état du marché du logiciel dans la musique.
Armand le musicien a toujours besoin de plus de matériel, qui lui ne se pirate pas. Donc il en achète des caisses. Du coup, le portefeuille du musicien est à plat lorsqu’il s’agit d’acheter le logiciel, mais c’est pas grave, lui il coûte rien.
Je ne suis pas le premier à le constater, les éditeurs dans le domaine de la MAO sortent de plus en plus de bundles hardware/software. L’intérêt du software ne s’exprime que si le hardware est présent. Du coup, on fait acheter …
Bref, les gars, nourrissez vos développeurs préférés, achetez leur logiciels, ils vous le rendront bien. Ohm Force, c’est 7 personnes qui veulent faire les meilleurs outils de création sonore. C’est pas des conneries, le petit dernier, l’Ohmicide:Melohman, a demandé 18 mois de développement.
Aux 30% restants, ceux qui payent leurs logiciels, qu’ils en soient remerciés, et qu’ils sachent que c’est pour eux qu’on travaille. Ouais, nous aussi on est people-ready.
Update : Franck dit que c’est un minimum, et qu’il s’attendrait à pire, genre 103%. Mais il est pessimiste.
Update 2 : J’ai posté un article similaire sur le blog d’Ohm Force.
[Cet article a été initialement publié le 1 juillet 2006]
Cette semaine, à Ohm Force, avec le retour de Raf, notre développeur Mac, la décision a enfin été prise. Le code des plugins Ohm Force va migrer de Concurrent Version System(le vénérable CVS) au moderne SVN. La conversion s’appuie sur l’outil bien pratique cvs2svn .
L’opération a été longue … le repository CVS fait 9,1Go, cvs2svn m’a généré un dump de 27Go et 10300 commits qu’il a fallu ensuite “rejouer” dans le repository SVN.
Il y a eu quelques soucis : il faut préciser l’encoding des message de commit (cvs2svn –encoding=latin1), et certains fichiers avec de l’accentuation ne sont pas passé dans la moulinette (silencieusement, en plus). Quelques fichier dans les repértoires Attic/ de CVS était corrompus, mais cela n’etait pas grave. Finalement, s’ils sont dans le grenier, c’est pour une bonne raison.
Il a bien fallu 10 heures pour tout convertir (oui, oui, nuit blanche …).
Installation de Trac, et bienvenue au 21e siècle les codeurs !
J’utilise la version 1.1.4 de SVN [UPDATE : depuis le serveur tourne en 1.3.2). Je vais migrer à la dernière version, tant pis pour Debian … En effet je suspecte une fuite mémoire dans certaines conditions. Un processus Apache qui fait 800Mo pendant un checkout, ce n’est pas raisonnable … Il y a quand même 2Go de SDRam ECC qui arrivent par le courrier.
UPDATE : Quelques remarques sur la conversion :
