Nouveau site EmisFR en approche

24/05/2010 Comments off

Bonjour à tous et merci de me lire sur le blog d’EmisFR.

Vous ne l’aurez pas manqué le site EmisFR actuel est un peu passé et surtout nous avons retiré beaucoup de contenus qui n’étaient plus à jour, notamment suite à la refonte de nos offres pour ajouter davantage de services au meilleur prix en tout début 2010.

Nos clients habituels le savent déjà, mais nos futurs clients pas forcément, donc pour faire court : oui nos offres ont changé, non nous n’avons pas encore eu le temps de mettre à jour le site web (mais c’est promis ca arrive !) et oui nos offres 2010 méritent vraiment le détour, donc n’hésitez pas à nous les demander (contact@emisfr.com)

Evidemment, la rançon du succès c’est également de ne plus passer suffisamment de temps sur certains de nos outils dont le site web, n’ayant pas prévu il y a quelques mois que nos nouvelles offres séduiraient autant.

Nous gardons le cap bien entendu mais avec moins de temps pour faire ces choses « annexes à la production » et évidemment plus de temps consacré à nos clients.

Bon, malgré tout cela nous avons trouvé le temps de vous concocter un nouveau site EmisFR, qui je l’espère vous plaira et sera clair. Il exposera de façon plus explicite nos deux métiers d’aujourd’hui qui sont le développement sur mesure et l’infogérance et j’espère que vous y percevrez notre volonté de nous réimplanter durablement dans le tissu économique local (Nancy, Lorraine, Grand Est de la France), même si nous ne renions pas, bien entendu, nos clients Parisiens !

Le site EmisFR est en version béta à l’heure où j’écris ces quelques lignes, et après quelques projets que nous devons boucler rapidement nous devrions pouvoir mettre en ligne la version définitive avant fin mai (2010), en tout cas nous allons tout faire pour y arriver.

En attendant vous pouvez consulter notre site EmisFR actuel (qui sera automatiquement remplacé quand le nouveau sera prêt, bientôt) et nous contacter pour toutes vos demandes, n’hésitez pas sur ce point par téléphone au 03 83 32 25 75 ou par e-mail sur contact@emisfr.com , vous aurez une réponse rapide.

Smarty 2.6, 3.0beta and Dwoo Performances

25/03/2010 un commentaire

UPDATE : July 20, 2010
New tests on Smarty 3.0 : RC1, RC2 and RC3 shows same performances as Smarty 3.0b9, no major change. These Release Candidate fix some bug and security issue and give a better stability.

Smarty 2.6, 3.0beta and Dwoo Performances

The aim of this test is to evaluate which template engine is the more efficient in professionnal environment. I selected only Smarty and Dwoo. Smarty is the template engine which we use at Emisfr since 3 years, we know it and we have many application working with. Dwoo is a Smarty « fork » but with a great Oriented Objet improvement. Smarty 3.0 is currently in developpement and one of its aim is to bring Smarty totaly Object and support Objet inside template, Smarty 2.x is likely PHP4 oriented, functional not really object. There is some other template engines like Template Lite (it’s also a Smarty « fork »).

Test environment

dual core Athlon 4200+
3.3Gb RAM
Apache : 2.2.13
Mod_PHP : 5.2.11 + APC
Apache Bench : 2.3

Tested versions

Smarty 2.6.26 : current stable
Smarty 3.0b7 : previous beta, usefull to compare evalution between betas
Smarty 3.0b8 : current beta
Dwoo 1.1.1 : current stable

The tests

Display of a template with and without template engine cache. We are talking about Template engine cache, not APC. When template engine cache is enable, the template engine have not to re-generate PHP code from Template file (tpl).
We will have a look on Memory peak and display time.

Cache enabled
Optimized Site
Force compile
Only to get performances
but this configuration never use
in production
Force Compile Check
Developpment configuration
no cache
No Compile Check
Production Site
most common configuration
cache_lifetime=-1
caching=1
force_compile=false
cache_lifetime=0
caching=0
force_compile=true
cache_lifetime=0
caching=0
check_compile=true
cache_lifetime=0
caching=0
check_compile=false
KINDTEST s3b8_rps s3b8_tpr s3b7_rps s3b7_tpr s2_rps s2_tpr dwoo_rps dwoo_tpr
cache_enabled 167,98 29,77 186,67 26,79 247,05 20,24 187,85 26,62
force_compile 16,33 306,24 16,72 299,05 62,38 80,15 37,2 134,41
force_checkcompile 126,96 39,38 131,83 37,93 187,37 26,69 108,49 46,09
no_checkcompile 127,39 39,25 132,69 37,68 184,89 27,04 111,99 44,65
Libraries Size
Template Engine Size (ko) File count
Smarty 2.6.26 223Ko 69 files
Smarty 3.0b7 627,8Ko 177 files
Smarty 3.0b8 635,4Ko 103 files
Dwoo 1.1.2 396,2Ko 101 files

Next we will test performances with hight access to the test page. For theses tests I will use « ab » (apache bench) with the following parameters : 1000 requests, 5 concurrency. We shall study requests per second, time per request and failed requests.

Execution time for the test page

Execution time

Execution time

When the cache is enable the results are closed, Smarty 2.6 have an advantage over others. But all are above 50ms. Smarty 2.6 and Smarty 3.0beta are very closed, with less than 15ms, it’s the best score.

When force compile is enabled, we can see Dwoo and Smarty 2.6 are the better, above 60ms. But Smarty 3.0beta is 3times slower than Smarty 2.6 with an execution time higher than 110ms. Don’t forget Template Engine force compile option is never enabled in production, this is a test to know « who is the best ».
In « developpment » configuration, result are good, lower than 15ms for evryones, Smarty 2.6 keeps head with 8ms.
In « common production » (no compile check), results looks like « developpment ». The deferencies between them are insignifiant.

Memory print

Memory

Memory

Previously we see that Smarty 2.6 is the faster Template Engine, now what is there memory prints.
Dwoo and Smarty 2.6 are below than 1,7Mo is a good score.
But like execution time the more important is when the cache is enabled. The template engines are below than 850 Ko, Smarty 2.6.26 is about 590 Ko this is the better score Smarty 3.0beta and Dwoo are about 800Ko.

When a Template Engine is configured in « force compile » mode, the Engine have to compile the templates files each time. We can see Smarty 3.0beta consum 2 times more than Smarty 2.6 : 2,4 Mo. Dwoo is juste behind Smarty 2.6 with 1,5Ko

When force check compile is enabled all are above 760ko (the bests scores), why Smarty use less memory than « cache enabled » ? I have no response yet.

When force compile si disabled, results are exactly sames.

Request per seconde

Request per second

Request per second

To simulate a high traffic on the test page I use apache bench, first when force compile is enabled, the results are likely Execution time test above. We can see Smarty 2.6 is the faster Template Engine with about 60 request per second, Dwoo is behind with 40 request per second and Smarty 3.0beta lag behind with 20 requests per seconde (3 time slower than Smarty 2.6).
When the Template Engine Cache is enabled all performances are satisfactory with more than 160 request per second. Smarty 2.6 is still the better with 247 request per second. Dwoo and Smarty 3.0beta are closed with 180 request per second.
In « force check compile » results are good, with more than 125 request per second. But Smarty 2.6 is 30% Faster than Smarty 3.0b. There is no major differencies when « No check compile » is enabled.

Theses results are the reflection of the previous Execution time test

Time per request

Time per request

Time per request

To finish this study, we have a look to the average time per request. Like others tests, When force compile is enabled, Smarty 2.6 is still the faster, with 80ms per request, dwoo is behin with about 135ms per request, Smarty 3.0beta are in the dust with more than 290ms per request.
When cache is enabled all competitor are closed, with a good score below than 30ms per request, Smarty 2.6 takes head with less than 21ms per request.
In force check compile configuration, the results are good with less than 40ms for Smarty, but Smarty 2.6 is the better. When check compile is disabled, the results are close with « force check compile », no major differencies.

To conclude, Smarty 2.6.26 is the better, faster and lighter template engine. Dwoo is a good alternative but its performances are worst than Smarty 2.6.26 and it’s not totally compatible with current Emisfr Software. Smarty 3.0 is good, but is a consume some more memory, but it’s very good score for a beta. The results of Smarty 3.0b are very close with Smarty 2.6.26. The developpment team do a good job ! But, don’t forget Smarty 3.0 is beta, may be some improvement will come.
This test will be updated with Template Engine evolution and release.
Emisfr is using Smarty 2.6.x but hope switch to Smarty 3.0 when it will be released as stable.

Test Files :
Smarty Test Files Package

Follow discution about this test on Smarty forum

Performances de Smarty 2.6, 3.0beta et Dwoo

23/03/2010 un commentaire

MISE A JOUR : 22 juillet 2010
les tests des versions de smarty 3.0 : RC1, RC2 et RC3 montre les mêmes performances que smarty 3.0b9, aucune changement notable. Ces Release Candidate apporte essentiellement de la stabilité et corrige des problèmes de sécurité.

Performances de Smarty 2.6, 3.0beta et Dwoo

Le but de ce test est d’évaluer quel moteur de template est le plus adapté dans un environnement professionnel. Ici je m’intéresse exclusivement à Smarty et Dwoo. Smarty est le gestionnaire de template que nous utilisons depuis déjà 3 ans, avec lequel l’équipe Emisfr est à l’aise. Dwoo quant à lui est un « fork » de Smarty mais orienté Objet. Smarty 3.0 est la version en cours de développement et qui a pour but de passer Smarty en PHP Objet, Smarty 2.x étant encore assez orienté PHP4, cette version 3.0 est la réponse aux problématiques PHP5 et PHP Objet. D’autres moteurs de template existent, comme Template Lite, également dérivé de Smarty.

Environnement :

dual core Athlon 4200+
Ram : 3.3Go
Apache : 2.2.13
Mod_PHP : 5.2.11 + APC
Apache Bench : 2.3

Les versions testées seront les suivantes :

Smarty 2.6.26 : actuellement stable
Smarty 3.0b7 : version beta précédente, elle nous permettra de voir l’évolution d’une beta à l’autre
Smarty 3.0b8 : dernière version beta
Dwoo 1.1.1 : actuellement stable

Les tests :

Rendu d’une page sans le cache du moteur de template activé. On ne parle pas ici de APC ou autre, mais bien du moteur de cache du moteur de template. Son but est de transformer le code « tpl » en code PHP.
On ressortira la mémoire maximum consommée (memory peak), et également le temps de rendu de cette page.

Cache activé
Site a forte charge
Force compilation
jamais utilisé en production
juste pour avoir une idée
des performances
Vérification de la compilation
configuration en développement
Pas de vérification de la compilation
configuration en production
la plus utilisée
cache_lifetime=-1
caching=1
force_compile=false
cache_lifetime=0
caching=0
force_compile=true
cache_lifetime=0
caching=0
check_compile=true
cache_lifetime=0
caching=0
check_compile=false
KINDTEST s3b8_rps s3b8_tpr s3b7_rps s3b7_tpr s2_rps s2_tpr dwoo_fail dwoo_rps dwoo_tpr
cache_enabled 167,98 29,77 186,67 26,79 247,05 20,24 1 187,85 26,62
force_compile 16,33 306,24 16,72 299,05 62,38 80,15 569 37,2 134,41
force_checkcompile 126,96 39,38 131,83 37,93 187,37 26,69 866 108,49 46,09
no_checkcompile 127,39 39,25 132,69 37,68 184,89 27,04 121 111,99 44,65

Ensuite on testera la montée en charge des moteurs, toujours avec et sans cache. Le test est effectué avec « ab » (apache bench) dont les paramètres sont : 1000 requêtes, 5 requêtes concurrentes. On ressortira le nombre de requêtes servies par seconde, le nombre de requêtes ayant amené à une erreur (Fail), et le temps moyen pour une requête.

Analyse du temps d’exécution

Execution time

Execution time

Analysons le comportement des moteurs lorsque le cache est activé. On peut voir qu’à l’exeption de Dwoo, les moteurs sont en dessous de 15ms, avec un avantage pour Smarty 2.6 qui est à 9ms ce qui constitue le meilleur temps, mais suivis de très près par Smarty 3.0beta avec 13ms. La question qui se pose est pourquoi une fois compilé les pages PHP générées par Smarty 2.6 sont-elles plus rapides à charger. Pour avoir la réponse à cette question il faudra regarder dans le code source. On peut en déduire que c’est certainement le chargement du moteur en lui même qui est le plus long sur Dwoo et Smarty 3.0b.

Voyons quels sont les résultats lorsque l’on force la compilation. On peut voir que Dwoo et Smarty 2.6 sont les meilleurs avec respectivement 55ms et 27ms. Par contre les deux versions de Smarty 3.0b, sont trois fois plus lentes avec un temps supérieur à 100ms. On peut donc penser que l’équipe de Smarty n’a pas encore fait de phase d’optimisation sur la génération de template. Ces chiffres sont à relativiser, car la génération sans cache n’intervient qu’une seule fois : lors du premier accès à la page en question, ceci n’est donc pas problématique en soi, mais il faudra penser à ne pas forcer la compilation des templates (ce qui est normalement jamais le cas).

C’est danse les configuration « développement » et « production commune » que l’on obtien les meilleures temps avec moins de 15ms pour l’ensemble des participant. On peut alors se demander pourquoi avec le cache activé les performances ne sont pas les meilleures.

Taille des bibliothèques :
Smarty 2.6 : 74,7 Ko (2classes) + 44,1 (22 sysplugins) + 104.6Ko (45 plugins) = 223,4Ko (69 fichiers)
Smarty 3.0b7 : 19Ko (1 classe) + 511 Ko (134 sysplugins) + 97,8 Ko (42 plugins) = 627,8Ko (177 fichiers)
Smarty 3.0b8 : 26,6Ko (1 classe) + 511Ko (60 syspluigns) + 97,8Ko (42 plugins) = 635,4Ko (103 fichiers
Dwoo 1.1.1 : 42,5 (1 classe) + 223Ko (37 syspluigns) +130,7Ko (63 plugins) = 396,2Ko (101 fichiers)

On peut voir que Smarty 2.6 est la bibliothèque la plus légère. Et Smarty 3.0b la plus lourde (plus de 2 fois plus lourde). Dwoo est quand à lui 50% plus lourd que Smarty 2.6, cela explique certainement la différence de temps d’affichage d’un template compilé mais pas seulement. Le nombre de fichiers à lire est également important pour Dwoo est Smarty 3.0b, le temps d’accès au disque peut expliquer également cela. Il existe des versions « compilées » de Smarty et Dwoo (non utilisé pour ces tests) qui permettent le chargement d’un seul fichier, le temps d’accès disque ainsi que le parsing sont réduits. Cependant Smarty 2.6 restera plus rapide compte tenu de son faible poids.

Analysons maintenant l’empreinte mémoire de ces moteurs de template

Memory

Memory

Précédemment nous avons pu voir que l’avantage allait indéniablement à Smarty 2.6 qui s’avère être le plus rapide, voyons maintenant ce qu’il en est pour l’empreinte mémoire.

Quelle est la consommation de mémoire lorsque le cache est activé ? Lorsqu’une application est en production le cache est activé pour éviter de compiler les templates à chaque appel, cette valeur à donc une certaine importance.
Dans cette configuration, tous les moteurs sont en dessous de 850Ko, ce qui est un bon point, on remarquera que Smarty 2.6 est à 585Ko ce qui constitue le meilleure score. Dwoo et Smarty 3.0beta ont une consomation un peut supérieur à celle de Smarty 2.6 mais rien d’alarmant.

Lorsque le moteur de template est configuré sans cache, le moteur doit compiler entièrement le fichier template, pour cela il passe par plusieurs phases, comme l’analyse syntaxique, puis la transformation en code php à proprement parler. On peut voir que Smarty 3.0b consomme deux fois plus de mémoire que Smarty 2.6 avec 2,4Mo utilisés. L’explication est assez simple, lors de la compilation, le moteur analyse le code qui peut potentiellement utiliser des plugins, nous avons vu plus haut que Smarty 3.0b a une centaine de fichiers « plugins » et « sysplugins » qu’il doit charger pour compiler les templates ; ils représentent environ 600Ko, contre 140Ko pour Smarty 2.6 et 350Ko pour Dwoo. Intéressons nous maintenant aux bons élèves que sont Dwoo et Smarty 2.6. Dwoo est à 1,5Mo ce qui constitue un bon score, mais qui évidement s’il est revu à la baisse sera un atout. Smarty 2.6 est le moteur qui consomme le moins de mémoire avec 1,0 Mo. On peut expliquer cela par son faible poids, et des optimisations plus poussée.
Comme pour les tests sur le temps tout à l’heure, la consommation de mémoire lorsque le cache est désactivé n’est pas la valeur la plus importante car en production le cache est activé et on arrive dans cette situation uniquement lors du premier appel à la page.

En mode « développement » et « production commune », la consomation de mémoire est strictement identique. avec des valeurs en dessous de 760Ko. Comme toujours Smarty 2.6 est le plus légé avec 525Ko.

Dans cette première partie de tests nous avons pu voir que Smarty 2.6 est le meilleur moteur de template aussi bien en terme de consommation mémoire qu’en terme de rapidité de traitement, que le cache soit activé ou non. Dwoo est bien placé également. Smarty 3.0b a des résultats assez proches de ceux de son grand frère Smarty 2.6, mais il n’est malheureusement pas meilleur et a une consommation mémoire trop importante lorsque l’on force la compilation. Dwoo quant à lui a des résultats corrects et se situe entre Smarty 2.6 et Smarty 3.0.

Nombre de requêtes servies par seconde

Request per second

Request per second

Voyons maintenant comment ces moteurs supportent la charge. En environnement de production certains sites à forte charge peuvent recevoir des milliers de requêtes il est important de connaitre le comportement de ces moteurs de template dans ce cas précis.

Nous allons nous intéresser dans un premier temps au nombre de requêtes servies par seconde, tout d’abord lorsque la compilation est forcée. Les courbes reflètent les résultats que nous avons pu analyser précédemment sur le temps d’exécution. Encore une fois Smarty 2.6 est en tête avec environ 60 requêtes par secondes. Dwoo le talonne avec environ 40 requêtes par seconde suivi de Smarty 3.0b avec moins de 20 requêtes par seconde.
Lorsque le cache est activé, on obtient des performances satisfaisantes, avec plus de 165 requêtes par seconde pour l’ensemble des concurrents. Smarty 2.6 est encore une fois le meilleur élève avec près de 250 requêtes par seconde. Dwoo et Smarty 3.0 sont à peu près équivalents aux alentours de 180 requêtes par seconde.
En mode « développement » (force check compile), les performances sont satisfaisantes avec environ 130 requêtes par seconde pour Smarty 3.0beta, mais Smarty 2.6 tire son épingle du jeu avec plus de 185 requêtes par secondes. Les résultats sont similaires lors que la vérification de compilation est désactivée. On peut d’ailleur se demander si elle a vraiment un intérêt.

Ces résultats reflètent donc exactement les mesures relevées lors de l’étude des temps d’exécution.

Temps moyen de traitement pour une requête

Time per request

Time per request

Pour finir étudions le temps moyen nécessaire pour servir une requête.
Lorsque le la compilation est forcée, Smarty 2.6 est fidèle à lui même et prend la tête avec environ 80ms, il est suivi par Dwoo avec environ 135ms. Smarty 3.0b est largement à la traine avec plus de 290ms pour servir une requête soit près de 4 fois plus lent que son grand frère.
Lorsque le cache est activé les tendances sont bonnes avec un score inférieur à 30ms pour l’ensemble des concurrents. Smarty 2.6 est toujours en tête avec moins de 21ms pour générer une page, Smarty 3.0b et Dwoo sont à peu près équivalents avec 30ms environ.
Dans la configuration de « développement » avec la vérification de la compilation activé, les performances sont bonnes avec moins de 40ms pour l’ensemble des moteurs testé, Smarty 2.6 est toujours en tête. lorsque la vérification de la compilation est désactivé, les performances restent similaire à la configuration en « développement ».

Pour conclure, Smarty 2.6.26 est actuellement le meilleur moteur de template parmi ceux testés ici. Il est à la fois celui qui consomme le moins de mémoire et le plus rapide, que le cache soit activé ou non. Dwoo est une bonne alternative puisque ses performances talonnent très souvent Smarty 2.6. Smarty 3.0b est assez décevant en terme de consommation de mémoire lors de la compilation, mais mis à part celà, ses performances sont très bonnes et sont proches de celle de Smarty 2.6. N’oublions pas que c’est une version beta et que l’équipe de développement travaille activement, puisque l’on a droit à une nouvelle version beta toutes les trois à quatre semaines environ. Espérons qu’il feront une grosse passe d’optimisation en particulier sur la consommation mémoire. Ce test sera mis à jour au fil des évolutions de ces trois moteurs de template. A ce jour EmisFR continue d’utiliser Smarty 2.6.x en attendant de pouvoir passer sur Smarty 3.0. Dwoo est pour le moment écarté car non compatible avec les logiciels déjà produits, de plus le langage de template est un peu différent et étant donné que ses performances sont moins bonnes que celles de Smarty 2.6.x il présente peu d’intérêt de changer.

Test d’outils de e-commerce OpenSource

14/10/2009 2 commentaires

Le but de ce test est d’évaluer les différents outils de e-commerce présents sur le marché. On s’intéressera aux outils les plus aptes à répondre à des besoins de e-commerce professionnel, proposant un module de paiement et une interface traduite en français. Chaque logiciel à été testé en prenant en compte plusieurs approches : côté marchand, côté client, et côté développeur.


Freeway : un manque de pérennité

URL : http://www.openfreeway.org/
+ installation simple et bien faite
+ supporte la vente de services, il est possible par exemple de louer un cours de tennis à une heure précise, cela apparait sur un planning
– dernière version stable datant de septembre 2008
– version en développement inactive depuis novembre 2008
– peu utilisé

Freeway, est un logiciel de e-commerce écrit en PHP. Ce logiciel n’est plus actif depuis septembre 2008, il a donc été écarté malgré quelques fonctions intéressantes comme la « prise de rendez-vous », via un planning affichant les horaires disponibles. Il n’est cependant pas sérieux de proposer à des professionnels un logiciel qui n’est plus actif car cela signifie qu’il n’est pas possible de garantir que le logiciel sera mis à jour, et bénéficiera de patchs de sécurité. Enfin, ce logiciel est très peu utilisé, il est donc difficile de trouver des modules complémentaires.

VirtueMart : du site vitrine à la vente en ligne

URL : http://www.virtuemart.net/
+ Joomla
+ module de paiement Atos
+ traduction en Français
+ cache
– logiciel lié a Joomla dont le e-commerce n’est pas son métier
– sécurité

VirtueMart est un module pour Joomla ou Mambo. De part sa relation directe avec Joomla, cela en fait un outil moins attirant que ceux que nous verront plus loin, pour la simple et bonne raison que Joomla est à la base un CMS, et que VirtueMart transforme ce CMS en boutique en ligne, ce qui n’est pas son métier. VirtueMart dispose cependant de modules supplémentaires tel qu’un module de paiement Atos, mais aussi d’une traduction en français. Joomla disposant d’une fonction de Cache, VirtueMart en hérite. Cet outil est très ergonomique, on trouve rapidement ce que l’on cherche. Il conviendra pour une petite boutique en ligne, dont le site vitrine est déjà sous Joomla. Les utilisateurs de Joomla s’y retrouveront rapidement. Le développement est actif mais la dernière version date de janvier 2009. Enfin Joomla est régulièrement la cible d’attaques des pirates qui font suite à la découverte de failles de sécurité, il sera donc inévitable de se tenir au courant des dernières versions de Joomla afin de garantir la sécurité de la boutique.

Magento : la boutique qui monte mais en manque d’ergonomie

URL: http://www.magentocommerce.com/fr
+ système de cache
+ supporté par des grands nom (Samsung, 3M…)
+ bien programmé
+ communauté active
– modules de paiement Atos (beta)
– localisation en français imparfaite
– pas d’éditeur WYSIWYG
– ergonomie
– templates = mélange entre PHP et HTML

Magento, est un nouvel entrant sur le marché de la boutique en ligne. Il est déjà supporté par de grands noms, comme Samsung, 3M ou encore Nesspresso. Une large communauté est présente, et on trouvera rapidement une solution à un problème, en consultant les forums. Magento dispose d’un « Language Pack Français », mais celui-ci n’est pas maintenu officiellement, on trouvera donc quelques termes anglais après l’installation de celui-ci. Il dispose de plusieurs modules de paiement dont le module Atos mais en bêta, d’autres modules de paiement existent, certains d’entre eux sont payants.
Le système d’installation de module est très simple, mais directement lié au site de Magento, en effet pour installer un module il est nécessaire de copier/coller une « clef » et Magento s’occupe de télécharger le module et de l’installer, apparemment il y a une gestion des dépendances entre modules et le système avertit l’utilisateur lors de l’installation d’un module non stable (beta).
Magento dispose d’une option cache qui permettra d’accroitre les performances en limitant les accès à la base de données. L’interface graphique est plutôt attirante aussi bien du coté boutique que du coté arrière boutique (backoffice).
Par contre, l’ergonomie est à revoir, si certaines informations sont à portée de clic, d’autres demanderont à l’utilisateur de parcourir plusieurs menu et de vraiment chercher pour enfin trouver ce qu’il souhaite. Par exemple pour gérer les fournisseurs, il faudra aller dans l’édition des attributs de produits et choisir manufacturer, puis à l’intérieur, ajouter des fournisseurs.
Un système de personnalisation de l’interface graphique de la boutique est disponible au sein de la partie admin et permettra de préparer le pages « template ». Il faudra par contre que l’utilisateur revoit ses cours de HTML, car il n’y a pas d’éditeur wysiwyg. Les pages sont basées sur le classique « PHP-HTML » mix, qui n’est pas des plus simples, mais qui à le mérite de séparer en partie le code HTML du code PHP. Les webdesigners ne seront donc pas perdus. Il sera également possible de faire participer les visiteurs en proposant des sondages, le module étant installé par défaut. Un utilisateur de la communauté à développé un module de migration depuis osCommerce 2.2, mais il ne migre que les produits et catégories. La base de données est bien construite et possède des index. Le moteur utilisé est innoDB. Cet outil a donc de grandes qualités, même s’il y a encore des choses à améliorer, il pourra être proposé pour une utilisation professionnelle.

OsCommerce : Un dinosaure en peine de renouvèlement

URL : http://www.oscommerce.com/
+ installation rapide et simple (moins de 3minutes)
+ traduction en français
+ gestion du stock
+ cache
+ module de paiement Atos
+ quelques rapports
+ communauté
+ version 3.0 prometteuse
– thème graphique par défaut
– système d’installation des extensions
– qualité du code
– sécurité
– version proposée non stable

osCommerce, est le plus ancien outil de e-commerce, il a une large communauté autour de lui, et un nombre de modules impressionnant. Utilisé par plus de 12000 boutiques référencées, il pourrait être une valeur sure. Cependant le développement a un rythme assez lent, et les versions proposées pour la mise en production sont parfois des Release Candidate (des versions pas totalement finies). L’installation se fera en quelques minutes. L’interface graphique est ergonomique, et même les nouveaux venus trouveront rapidement leurs marques. Le thème graphique par défaut est vraiment horrible, mais des thèmes graphiques existent sous forme de contributions. Les nombreux modules pour osCommerce permettront de personnaliser la boutique, mais leur installation nécessitant bien souvent de modifier du code, il faudra avoir quelques notions de PHP. La version testée est une 2.2RC2a, le code est de type php3. Et c’est bien là tout le problème avec osCommerce. En effet le code spécifique php3 pose de très nombreux problèmes de sécurité et de maintien en production. De part son utilisation mondiale et ces problèmes de code, osCommerce connait souvent des découvertes de failles de sécurité qui sont alors exploitées. L’équipe de développement a tardé à prendre en compte ce problème avec la version 3.0 qui est en cours de préparation (en alpha5) et qui sera compatible PHP 5.2.x alors que PHP 5.2 est sorti en 2006… Le code de la version 3.0 est objet et on peut donc espérer que le passage à PHP 5.3 se fera en douceur. Dans l’état actuel des choses, il n’est pas recommandable d’utiliser la version 2.2, en particulier pour une nouvelle boutique, d’ici peu de temps cette version 2.2 sera complètement obsolète du fait de l’utilisation de fonctions supprimées, des register_globals et autre short_open_tags. L’équipe de développement de la version 3.0 prépare un script de migration, mais aucune date de sortie n’est encore prévue.

Prestashop : La boutique française bien pensée

URL: http://www.prestashop.com
+ installation en moins de 3minutes
+ traduction en Français disponible
+ jolis effets graphiques boutique et arrière boutique
+ sécurité (mot de passe + renommage du dossier admin et suppression du dossier install)
+ interface ergonomique
+ rapports et statistiques avancés agrémentés de graphiques
+ templates avec Smarty
– module de paiement Atos Payant (300euros)
– tous les modules complémentaires sont payant ou presque (compter 70 à 400euros)

Prestashop, est un nouvel arrivant sur la scène de la boutique électronique. Développé par des Français, l’outil regroupe déjà 30000 membres. Ce qui frappe avec Prestashop, c’est la qualité de la finition, l’interface graphique d’administration est agréable et ergonomique, elle est plaisante à utiliser. Les nouveaux utilisateurs trouveront ce qu’ils cherchent naturellement. Prestashop dispose de nombreux modules qui s’installent facilement via un système packages zip, le système s’occupe de télécharger, décompresser et installer le module. On trouvera par exemple le module de paiement Atos.
L’ensemble de l’application est parfaitement traduite en français (sauf dans la partie statistiques). L’équipe de développement à utilisé AJAX à bon escient ce qui est très agréable autant du coté client que du coté marchand. Le marchand appréciera les rapports agrémentés par des graphiques représentant les volumes de ventes, de visites, les articles les plus vendus et complété par un commentaire du graphique.
L’accent à été mis sur la sécurité, ainsi les mots de passe doivent contenir des lettres et des chiffres, et le dossier de la partie admin doit être renommé après l’installation.
Prestashop est basé des technologies éprouvées comme le système de template Smarty, qui ravira les webdesigners comme les développeurs, mais aussi des modules PEAR. Le code est de très bonne qualité avec un découpage par objet. On peut regretter qu’il n’y ait pas de système de cache autre que celui de Smarty qui cache ses templates, il aurait été intéressant de cacher également toute la partie boutique en HTML, de manière a ne pas reconstruire entièrement les pages. Cependant les performances semblent être au rendez-vous car les pages sont générées en général en moins de 1 seconde. La base de données a bien été pensée, des indexes sont présents et la taille des champs à été définie. C’est un outil parfaitement recommandable à des professionnels.

Nous l’avons vu qu’il existe des outils de plus ou moins bonne qualité suivant le type de boutique que l’on souhaite mettre en place. Les deux boutiques sortantes sont Magento et PrestaShop qui, développés récemment (depuis 2007-2008) ont su répondre aux problématiques web 2.0 et programmation Objet. Cela assure à ces projets une ergonomie, mais surtout une pérennité. La programmation objet permet à un projet d’être canalisé et rationnel, elle permet de centraliser les fonctions et donc de simplifier la tâche des développeurs. Il reste a savoir si ces solutions arriveront à s’imposer en particulier face à osCommerce qui détient près de la moitié du marché français, l’un des enjeux pourra donc être de proposer une procédure de migration depuis osCommerce, ce que pour le moment ni Magento, ni PrestaShop ne proposent. Il se pourrait même qu’EmisFR soit déjà sur le coup …

Part de marché pour les boutiques en ligne enregistré par e-komerco (source des données http://www.e-komerco.fr/ octobre 2009)

Part de marché pour les boutiques en ligne enregistré par e-komerco (source des données http://www.e-komerco.fr/ octobre 2009)

Cédric FERRY – EmisFR

Layer break for DVD+R DL with growisofs / dvd+rw-tools

I’ve started recently to play around with DVD+R DL because they start becoming cheaper and some applications really need them 🙂

I was very surprised that the current version of growisofs / dvd+rw-tools (7.1) advertises layer break position setting support but in reality I couldn’t get it to break where I want.

Looking at the code (especially from growisofs_mmc.cpp) I found very strange that the « -use-the-force-luke=break:NNNN » option wasn’t really used either in calculations or cuesheet sending.

Investigating a little bit more in the code I produced the following patch that I have sent upstream to get it included somehow in the next version.

It allows a user (who should be careful of what it does 🙂 ) to manually force a layer break position for DVD+R DL burning. (For those of you who haven’t had this problem yet please notice that : DVD-R DL (minus) DO NOT allow layer position to be changed, that said you should know what to do … only DVD+R DL (plus) allow that)

For this patch to work you have to specify « -dvd-compat » on the command line, otherwise the cuesheet sending code is not called (I didn’t understand exactly why…) and the layer break wouldn’t be set …

In any case the output of growisofs command should tell you where the layer break is going to be set.

I’ve tested it succesfully for a dozen of DL burns with or without layer break so it should be safe enough (the patch is not very intrusive anyways ; I also tested without the option to see if the normal behavior was preserved…)

Use it this way :

growisofs -dvd-compat [your other options here] -use-the-force-luke=break:XXXX [where XXXX is the layer break in sectors] -Z /dev/[your device]=[image.iso]

for example 🙂 :

growisofs -dvd-compat -use-the-force-luke=break:2084960 -use-the-force-luke=dao -Z /dev/sr0=/home/johndoe/m.iso

note the dao option usage that will close the session, otherwise the disc would remain « open » if it’s not full and depending on what you burn you’d really want to close the session trust me 🙂

Have an happy dual layer with positionned break burning !

Attachment : dvd+rw-tools-7.1-layerbreaksetup.patch

Note: use a command similar to apply (change to -p 1 depending on where you are) :

patch -p 0 < dvdrw-tools-7.1-layerbreaksetup.patch

Getting rid of Computrace on Dell Inspiron mini 10v (Inspiron 1011)

Today I just received my very small and not so shiny Dell Inspiron mini 10v (1011 model). I will possibly make a review later if there is enough popular demand 🙂

Playing with the BIOS I activated « Computrace » to see what it means, thinking that it was some sort of TPM module. What a mess !! I didn’t pay attention at all that this setting could not be changed later… or could it ? 🙂

Do the following at your own risk of course …

I grabbed a bootdisk (floppy image) with Dell utilities on it (especially ASSET.COM and EE-VALUE.EXE)

(Google is your friend, don’t even try to ask about any non-opensource download here…)

After some fight with those utilities I finally found how to change Service Tag and Asset Tag from my small laptop. I read posts on different forums that it should be enough to reset Computrace but it wasn’t …

So to change Service Tag use

ASSET /S /D (to delete and set it up again in the BIOS menu) or

ASSET /S NEWTAG

Depending on asset version it should work flawlessly, I tried ASSET_A209.EXE and it didn’t work for me (an old version did)

Use similar commands without /S to change Asset Tag.

But the trickiest part was to deactivate the damn Computrace module in BIOS.

This time we would use EE-VALUE that allows to set a value directly on the BIOS NVRAM (not sure about CMOS of NVRAM but anyways…) and looking at different values I finally found (using EE-VALUE /D to display contents) that there was a strange value at offset 0x50.

Using

EE-VALUE /W=50,FF

will reset it to default and then you will be able to select or disable it again.

If you have any doubt or if you have a different laptop check first with

EE-VALUE /D

and try to find any « 03 » (activated) or strange value around 0x50.

Very strong protection from Absolute Software guys ! It takes seconds to remove once your laptop has been stolen, very efficient …

I had this error for a long time before discovering I could do it directly with EE-VALUE so I put it here for indexing purposes :

SVCTAG.EXE version 3.3

I told you what I am. But what are you?

EE-CPB.exe: Error 0

Now, then I’m going back to my fresh Slackware 13.0 install again. Thanks for reading and I hope this will help people with Dell laptop to manage their « Computrace » settings like they want.

Dolby Digital ou DTS en HDMI ? Non répondent Sharp et Samsung !

Un petit coup de gueule une fois n’est pas coutume contre les fabricants de téléviseurs LCD, en particulier de TV HD avec entrées HDMI.

Après plusieurs échanges ressemblant à un dialogue de sourd et quelques tests chez des amis (merci Jérôme !) je viens de m’apercevoir que la plupart des téléviseurs du marché ne supportent pas de faire transiter le son HDMI vers la sortie optique numérique, un comble !!

Alors, me direz-vous quel intérêt de mettre tout en numérique, en particulier via le sacro-saint câble HDMI qui est censé remplacer tous nos anciens câbles et passer tout en numérique multi-canaux y compris le son ? Et bien Sharp et a priori Samsung répondent : aucun ! Je sens que je me suis bien fait entuber sur ce coup-là pour rester poli …

Petit résumé : j’achète un Acer Revo, un peu galère sous Linux mais le bestiau s’en sort bien surtout grâce à son NVIDIA Ion et le VDPAU, l’Atom lui est franchement à la ramasse, la compil du kernel m’a laissé le temps de boire une boisson, manger une pizza, regarder Nolife et revenir pour constater qu’il avait fait 50%du boulot à peine … Malgré tout cela, content de ce matériel qui ne contient qu’une sortie HDMI en guise de sortie numérique, le son passant dedans en numérique, je le relie à ma TV Sharp LCD 52X20E en pensant naturellement faire sortir le son par la sortie optique de là-dite télévision vers mon vieillissant ampli 5.1 (qui fait tout de même DD et DTS, c’est déjà bien). Mais oh! surprise! le son ne sort qu’en PCM stéréo…

Après quelques débats sur les mailings-lists côté ALSA (où il traine des gens très sympathiques !) on me file un coup de main pour au final constater que tout se passe bien côté ALSA et côté Revo mais c’est la TV qui boude et ne transmet pas le magique flux DD (ou DTS) vers mon ampli ; encore pire elle décode le flux et l’envoie en PCM stéréo comme si de rien n’était !!

J’ai donc acheté un boitier externe pour récupérer mon flux audio du HDMI et le sortir sur un optique (ou coaxial au choix) et tout cela parce que Monsieur Acer a un tout petit peu oublié de faire une sortie numérique audio séparée (mais comme le HDMI promet monts et merveilles on ne lui en veut pas trop) mais surtout que Sharp NE FAIT PAS SON BOULOT, car après avoir jetté quelques coups d’oeil dans le code GPL fourni sur leur site, il semble y avoir des bribes de code pour le faire ! (eh oui Monsieur Sharp utilise Linux dans ses télés mais ne sait apparemment pas bien le faire fonctionner ; j’ai plus que quelques notions côté Linux donc note pour M. Sharp : ne pas prendre tous ses consommateurs pour des blaireaux …)

Et la cerise sur le gâteau, ce pour quoi je m’épanche via ce post : un mail reçu ce jour du service technique (qui doit en avoir marre qu’on lui demande de faire marcher correctement ses produits achetés relativement cher, quelle demande inconvenante! …) me remballe directement avec un « Il n’est pas prévu de mise à jour pour un tel fonctionnement, ce n’est pas un souci de compatibilité […] Le rôle du téléviseur est surtout d’afficher une image, la sortie optique est dédiée pour le son de la TNT » ; comprenez, on a affiché des tas de logos Dolby Digital machin ++ etc. etc. partout et on est même pas foutus de faire sortir autre chose que du PCM stéréo sauf pour le DVB-T par la sortie optique… Car oui le DVB-T (appelé TNT chez nous) marche bien en DD ou DTS sur la sortie optique … un comble !

Enfin voilà, à quoi j’en suis réduit, si toi lecteur, tu souhaites acheter une TV LCD Sharp ou Samsung, pense déjà à rajouter à ton budget l’achat d’un nouvel ampli HDMI, ce qui gonfle assez largement le budget à l’heure actuelle ou à peut-être envisager une « vraie » marque avec une électronique bien programmée qui elle, renvoie le son numérique multicanaux via ses sorties numériques audio …

Je ne suis pas prêt de racheter du matériel Sharp !!! A bon entendeur …

SIP Fax detection with Asterisk 1.6.2.0

Here it goes again, still the same problems for detecting voice based fax calls on Asterisk 1.6.

I know that « we should use T38 » or « get a decent SIP provider » are all along the way but hey! I’m using Free with it’s freephonie service in France and we’re even getting multiple ADSL connections (from different companies that are in the same building) and bridged them together to an Asterisk server.

It’s very handy, we get SIP trunking for a very small fee : free 🙂 but in fact it’s in a whole package for 30€ per month : ADSL2+, Free telephony, HD TV (tax included)

So, I wanted to post about the recent « patch » I prepared after upgrading to Asterisk 1.6.2.0-beta2.

Why upgrade to a beta version ? Simple, since there was advertised Fax detection support for T38 (which should work, I didn’t test since I don’t have a decent provider with T38 support 😉 ).

Looking at the chan_sip.c code I figured out it was very easy to tweak the fax detection code to also do detection on SIP audio channels,but … I was plain wrong ! In fact it could have worked but it’s much more difficult than it seems. To make a long story short, I looked more deeply at the NV Faxdetect applications (from Justin Newman) and in fact they use a similar approach that the one I finally got through : use Asterisk DSP to actually do the detection and then branch on the dialplan to « fax » extension (code already done in 1.6.2 for T38 only).

Removing specific T38 tests I almost got through after spending 3 hours to finally get to a point that was very near NV Faxdetect : I first had to switch to slinear before using DSP (or it wouldn’t detect faxes at all, if someone knows why please tell me 🙂 ) and then switch back to alaw or ulaw (what came first) to get the call through.

Seing that I needed to patch chan_sip.c alot with very dirty hacks I finally decided to go back on app_nv_faxdetect.c and app_nv_backgrounddetect.c and simply patch them (with very little effort surprisingly) and got them to work perfectly with Asterisk 1.6.2.0-beta2 (the patch should certainly apply to later 1.6.2.x version relatively cleanly, just make sure to apply it on vanilla sources *before* ./configure and make menuselect ; issue a make distclean if you didn’t)

I remembered I used to leave some mails to Justin, asking me to wait for a new version to come out and many people on http://www.voip-info.org seemed to have tried to patch it (or at least asked to) and noone managed to get a working version for 1.6.x.

Here it goes, but I’m very surprised I had to change very little portions of code (nothing really important, only definition and variable name changes) and everything has been working very well here for more than 2 weeks, with more than a dozen faxes correctly detected.

If you need to, leave me a comment since I started to test at home (yes I also have an Asterisk box at home 😉 ) and I patched a version for Asterisk 1.6.1.0 that compiled and worked flawlessly.

Be sure to grab the patch attached here and enjoy your fax detection on voice part of SIP channels 🙂

asterisk-1620-beta2-faxdetect.diff

See you for other Asterisk weirdnesses, I have some more to post !!