Ce qui a changé depuis 2000 :

• PHP n’est plus “le langage pour faire des formulaires de contact”
• Javascript enrichit visuellement la page (et plus seulement avec des alert)
• Les GIF animé ont disparu
• Linux a enfin une vraie distribution orientée utilisateur avec Ubuntu
• ASP, Perl, ColdFusion…
• Les smartphones (surtout depuis l’iPhone)
• La vitesse de connexion à Internet, permettant d’y faire passer la TV et le téléphone
• La sécurité des technologies Microsoft
• Les charlatans qui imaginaient se faire rapidement du fric avec une start-up
• La gestion de configuration, de Subversion à Git

Ce qui n’a pas changé depuis 2000 :

• Flash met le feu au CPU
• Java rame
• Internet Explorer 6 est la lie de l’humanité
• Les Design Pattern, à toujours avoir dans sa caisse à outils
• Google
• L’interprétation des pages par les navigateurs, obligeant à patcher pour chacun d’entre eux
• Les commerciaux qui ne comprennent toujours rien à la technique
• Les développeurs  vus comme des ours mal léchés
• Les charettes dans les agences Web
• Les protocoles utilisés sur Internet
• Il manque toujours un truc à MySQL
• L’open source est un laboratoire de bonnes idées
• La loi de Moore
• La loi de Murphy

La liste est bien entendu pas exhaustive et totalement subjective. Vous voyez d’autres changements (ou pas) pendant cette décennie ?

Le site à réaliser est un portage d’un ancien projet PHP vers Symfony 1.2 + Doctrine. Un point d’attention en particulier touche à la reprise des données existantes du site V1 tournant sous un antique MySQL 3.23 et un stockage MyISAM.

Le développement d’une pake task a été privilégiée au détriment de fixtures YAML :

• volume de données important (près de 500000 comptes utilisateurs à injecter dans des sfGuardUser, sans compter toutes les données dépendantes) qui aurait abouti à des fichiers YML longs à vérifier,
• changements profonds dans la structure de la base de données entre la V1 et la V2
• avoir le contrôle sur les données importées (notamment connaitre le nombre d’erreurs et leur nature)
• pouvoir tirer malgré tout parti de la puissance de Symfony (Validators, Doctrine…)

Quelques points sont cependant importants à vérifier.

1) Attention aux fuites mémoire avec les objets

L’import des données a donné lieu a de nombreuses boucles pour fabriquer les objets Doctrine. Ces derniers utilisent beaucoup de références circulaires, que PHP ne gère plus depuis la 5.2.5.
Ceci se résoud avec deux appels importants :

• utilisation de la méthode free d’un objet Doctrine qui libère les ressources allouées à l’objet, et se débarrasse des références circulaires
• utilisation de unset($obj) pour supprimer la variable complètement.

La 1ère version du script qui engloutissait la mémoire, passe désormais sous une barre satisfaisante de 128M. Une boucle de traitement sur une ancienne table donne ceci :

foreach ($results as $datav1) {
    $o = new ObjectV2();
    $s->name = $datav1['name'];
    $o->save();
    $o->free();
    unset($o);
}

2) Faire travailler au maximum MySQL plutôt que PHP

Nous avons trouvé des adresses emails folkloriques dans les comptes utilisateurs : des valeurs avec espaces et des formats d’adresses non-standard principalement, qui ont fait hurler sfValidatorEmail tout le long de l’import. La solution :

• requête de TRIM préalable pour “épurer” les adresses e-mail valides qui contenaient des espaces,
• utilisation de la clause RLIKE sur la requête de chargement des utilisateurs, pour contrôler en amont - plutôt que de faire subir à Symfony et PHP - la validation de comptes avec des adresses e-mail bidons

Le requête de filtrage avec RLIKE donne ceci :

$sql = 'SELECT t.* FROM MaTableV1 t WHERE t.email RLIKE \'^[[:alnum:][.period.][.hyphen.][.underscore.]]+@([[:alnum:][.hyphen.][.underscore.]]+[.period.])+.([[:alnum:][.hyphen.]]){2,4}$\'';
$q = $conn->query($sql);
 
foreach ($q1 as $key => $dataV1) {
    // Traitement des données
}

Sur le schéma de la base de données “V1″, il est également nécessaire de s’assurer que les optimisations basiques sont en place pour les requêtes d’import :

• présence de clés primaires
• présence d’index sur les “clés étrangères”
• présence d’index sur les champs utilisés dans les clauses WHERE, ORDER BY des requêtes d’import

A noter que la lecture des données de la V1 est effectuée directement à l’aide de PDO :

$conn = new PDO('mysql:dbname=' . $arguments['name'] . ';host=' . $arguments['host'], $arguments['username'], $arguments['password']);
...
$q = $conn->query($sql);

Les présentations étaient d’un bon niveau technique, les personnes dans la salle ayant déjà une licence développeur et avaient (sûrement) toutes déjà posté une appli sur l’App Store. Les “senior evangelists” d’Apple étaient déjà bien rôdés puisque Paris était leur dernière date.

Démarrage avec un speech d’une heure dont j’ai retenu quelques exemples de killer-apps, comme Tweetie pour sa fonction de rechargement des Tweets, Zipcar pour son appli de location d’autos, NationWide pour son système de déclaration d’accidents.

Les présentations techniques que j’ai suivi sont restées dans la ligne de conduite que je m’étais fixée, à savoir le besoin immédiat pour mon job. Je suis donc resté suivre Effective Apps Parties 1 et 2, qui ont notamment traité de sujets sur le stockage d’informations utilisateur. J’ai surtout eu un très bon tuto sur l’excellente couche d’abstraction pour faire du threading avec NSOperations et NSOperationsQueue.

L’après midi était lui consacré à Core Data, un système d’objets relationnels avec backend SQLite qui fait totalement abstration du SQL pour tout piloter en Objective-C avec XCode. Puis aux tests unitaires et débogage, avec l’utilisation de SenTesting, et aussi Instruments pour détecter aussi bien les problèmes de mémoire que les UIView transparents (source de perte de performance).

La journée a été très riche en infos et je repars au feu avec plein de bonnes idées et d’astuces pour mener à bien les projets !

Dans les deux cas, la procédure est la même :
- générer une demande de signature de certificat (CSR)
- signer le certificat avec OpenSSL
- intégrer le certificat dans la config de l’hôte virtuel

Dans le cas de IIS, le serveur génère une demande de certificat qu’on fera signer par OpenSSL. Dans le cas d’Apache, OpenSSL peut générer la demande et l’auto-signer.

IIS

Etape 1 : Aller dans les propriétés du site virtuel, puis dans l’onglet Sécurité de répertoire.

Cliquez sur le bouton Certificat serveur en bas de l’onglet.  Un assistant s’affiche.

Choisissez “Créer un certificat”, puis sur l’écran suivant “Préparer la demande mais ne pas l’envoyer maintenant”. Saisissez ensuite les informations administratives sur les écrans suivants et enfin l’emplacement où sera stockée votre demande (par défaut c:\certreq.txt).

Etape 2 : Installez une version Windows d’OpenSSL. Elle est disponible ici.

Etape 3 : Exécutez ensuite les commandes suivantes :

Génération de la clé :

openssl genrsa -des3 -out CA.key 1024

Génération du certificat racine

openssl req -new -key CA.key -x509 -days 1095 -out CA.crt

Signature de la demande générée par IIS (certreq.txt) dans un certificat (autosigne.cer) :

openssl x509 -req -days 365 -in c:/certreq.txt -CA CA.crt -CAkey CA.key
-CAcreateserial -out c:/autosigne.cer

Etape 4 : Intégrer le certificat auto-signé sur le site web. Retourner dans l’onglet Sécurité de répertoire sur le site virtuel d’IIS, cliquer à nouveau sur Certificat serveur. Sélectionnez Traiter la demande en attente, puis sélectionnez le fichier autosigne.cer. Le certificat SSL est installé.

Apache

Le fonctionnement est assez simple pour Apache.

Etape 1 : installation d’OpenSSL avec votre outil préférentiel sous Linux (yum, apt-get, emerge…). Note pour les utilisateurs de WampServer : OpenSSL est déjà intégré dans le dossier bin d’Apache.

Etape 2 : création du CSR avec OpenSSL et génération de la clé et du certificat serveur.

openssl req -new -x509 -nodes -out server.crt -keyout server.key

Placez les fichiers server.crt et server.key dans un dossier à part (par exemple dans un dossier /etc/ssl sous Linux, ou dans le dossier conf/ssl/ d’Apache Windows).

Etape 3 : intégration dans Apache.

Assurez vous d’avoir mod_ssl activé. Le cas échéant lancez la commande :

a2enmod mod_ssl
/etc/init.d/apache2 reload

ou activez-le depuis votre environnement WampServer ou EasyPHP.

Ensuite éditez le fichier de configuration Apache. Recherchez les directives SSLCertificateFile et SSLCertificateKeyFile (elles sont souvent en commentaire), et indiquez le chemin vers vos deux fichiers server.key et server.crt.

Au niveau du code

Précalculer le plus possible

Mise en “cache” dans des variables : par exemple l’accès à la propriété d’un objet enfouie sous plusieurs niveaux, ou un valeur utilisée dans la déclaration d’une boucle for.

// Pas bien
for (var n = 0; n < monObjet.maPropriete1.maPropriete2.valeur; n++) {
	// ...
}
 
// Bien
var len = monObjet.maPropriete1.maPropriete2.valeur;
 
for (var n = 0; n < len; n++) {
	// ...
}

Interdiction d’utiliser eval !

A l’instar de n’importe quel langage, la fonction eval est un gouffre à performances. L’éviter autant que possible. Il y a bien entendu des alternatives :

// Pas bien
eval("obj."+prop)
 
// Bien
obj[prop]

Concaténation de chaines

Utilisation d’un Array pour concaténer les chaines et liaison à l’aide de la méthode join(). Les développeurs de Microsoft le recommandent dans le doc en bas, à la manière d’un StringBuilder en .Net ou en Java :

var sb = new Array();
sb.push("
 
");
sb.push(monTexte);
sb.push(monTexte2);
sb.push("
 
");
 
var s = sb.join("");

Au niveau des fichiers

Minifier les Javascripts en production

But : optimiser le chargement du script pour l’interprétation (bande passante utilisée, temps d’interprétation par le moteur JS du navigateur). Il existe d’excellents outils pour effectuer cette tâche : YUICompressor, JSMinifier… Dans l’idéal, s’assurer que tout le JS est envoyé avec un seul appel HTTP.

Mettre les déclarations en bas de page

Le plus près possible de la fermeture de l’élément body (</body>). Cela permet d’exécuter le code à l’issue du chargement complet du HTML, évitant du coup un blocage en plein milieu du rendu de la page.

Bibliographie rapide

• IEBlog : IE+Javascript Performance Recommendations : Partie 1, Partie 2, et Partie 3
• JScript Blog : Performance optimization of arrays : Partie 1 et Partie 2

La raison est qu’OVH a pris le soin d’activer le suEXEC d’Apache, bloquant de fait mes fichiers qui avaient - à tort - des permissions trop élevées. Après quelques aller-retours sur la doc de suEXEC, et sur les forums d’OVH, j’ai finalement trouvé la solution : mettre des permissions 755 (rwxr-xr-x) sur les dossiers et 644 (rw- r– r–) sur les fichiers.

Je vous fais partager un petit script vite fait pour redéfinir correctement les permissions sur les 3 blogs hébergés sur mon espace :

#!/bin/sh
 
if [ ! -d /chemin/vers/www/$1 ]
then
        echo "Veuillez specifier un dossier valide"
        exit 0
fi
 
echo "Correction des permissions du dossier $1"
 
find /chemin/vers/www/$1 -type d -exec chmod u=rwx,go=rx {} \;
find /chemin/vers/www/$1 -type f -exec chmod u=rw,go=r {} \;
 
echo "OK effectue"

Enregistrez le script sous fix_suexec.sh, mettez lui les droits en exécution pour l’utilisateur propriétaire, puis lancez-le comme suit :

user@hebergement:~/# ./fix_suexec.sh mondossierweb

Je ne remercie pas OVH sur ce coup, pour faire des modifications aussi critiques sur son hébergement sans prendre la peine de prévenir ses utilisateurs.

Paybox

Paybox est édité par la société éponyme. Le module de paiement sécurisé est décliné en plusieurs moutures : version avec interface de paiement tierce, paiement envoyédepuis le site marchand, version pour mobile.

La plupart des grandes fonctionnalités sont présentes : modalités de paiements divers (en N fois, en différé, abonnement…), support des grandes cartes bancaires, interface multi-lingue. Par analogie avec se concurrents, ses 2 grands atouts résident dans son indépendance bancaire totale, et dans le support du m-Commerce avec une interface pour téléphones mobiles.

L’intégration technique du module consiste comme SIPS dans l’utilisation d’un module exécutable. La différence est qu’ici il qui va être utilisé comme relai direct vers l’interface de paiement. En pratique, on déclare ce fichier (avec une extension .cgi) comme action du formulaire, en lui passant une série de paramètres indiqués dans la documentation : langue de l’interface, montant à payer, n° de la commande, url de retour. Il s’occupe ensuite de rediriger l’utilisateur vers le paiement sécurisé et de notifier le site marchand lorsque le paiement a été fait ou refusé.

Les plus

• Support complet des modalités de paiements
• Indépendance vis-à-vis des banques
• Support du m-Commerce

Les moins

• Support limité des devises
• API pour interaction avec le site un peu bancale

Conclusion

Les 5 modules évoqués ont, malgré leurs similarité, des fonctionnalités spécifiques qui pourront pencher dans la balance, lors du choix technique à effectuer pour le paiement de votre site.

Afin d’avoir les idées claires, j’ai crée une grille comparative de ces modules, que vous trouverez ci-dessous.
Je suis volontairement resté sur les fonctionnalités “usuelles” des modules, afin de ne pas trop déséquilibrer la comparaison : Paypal fait par exemple compétition à part si on ajoute les fonctionnalités d’accès multi-utilisateur, paiement multi-boutiques, calcul de taxes etc.; on peut également citer la dépendance particulière à une banque qui peut influer sur votre choix…

Paypal est une interface de paiement multi-boutiques, à la fois pour le marchand et - c’est un de ses points forts - pour l’acheteur. Ce dernier a en effet le possibilité de créer un compte qu’il peut créditer selon ses besoins.

Les fonctionnalités offertes vont bien au-delà de la simple interface de paiement car on trouve un bouton d’achat immédiat plaçable dans le site, ou encore une fonctionnalité de panier intégrée dans l’interface de Paypal. Le panier peut en revanche tout à fait être géré par vos soins comme sur un site classique.

L’interface de Paypal est très élaborée et peut prendre en charge une phase plus grande de la partie paiement. Le paramétrage des informations concerne :

• Informations financières
• Remboursements
• Personnalisation des pages de paiement
• Notifications au site marchand
• Taxes : calcul automatique de TVA, de frais d’expédition et de livraison
• Devises autorisées, types de paiements autorisés
• Langues
• Accès multi-utilisateurs à la console de gestion

Côté technique, l’interfaçage réside dans l’utilisation de HTML et de variables cryptées à l’aide d’un certificat. Toutes les informations (URLs de retour, identifiant marchand…) y sont placées.
Les informations sont transmises à une URL de retour pour que votre site marchand valide ou invalide définitivement la transaction, à l’instar des modules que j’avais déjà présenté précédemment. Un environnement de test est disponible pour recetter proprement l’application.

Les plus

• Facile à intégrer
• Indépendance technologique : on peut même l’utiliser sur un site HTML !
• Multi-devises, multi-lingue… multi-tout !
• La documentation fournie
• Support des téléphones mobiles
• Des plugins pour la plupart des grands frameworks et CMS (Magento, osCommerce, Symfony…)

Les moins

• Les commissions sur les paiements

Petit historique

Simon Willison a eu en 2003 l’idée lumineuse d’utiliser la syntaxe des règles CSS pour récupérer des éléments du DOM. Il en résulte la première fonction nommée document.getElementsBySelector().
Les premiers sélecteurs arrivent fin 2005. On retient notamment CssQuery de Dean Edwards (auteur notamment de la mini-bibliothèque IE7 qui apportait un support CSS2 à IE6), et jSelect qui préfigure jQuery l’année suivante.
La démocratisation s’achève en 2006 et 2007 avec l’arrivée des frameworks JS/AJAX majeurs du marché, embarquant chacun leur sélecteur CSS.

Le succès tient en quelques é”vidences : des manipulations du DOM très efficaces avec très peu de lignes de code, surtout lorsque la bibliothèque offre des fonctionnalités de chaînage (comme jQuery).

En pratique

Voici quelques exemples de codes agissant sur cette page :

var liens = $$('.list-blogroll li a'); // Liens du blog rollvar titre = $$('#headerimg h1 a'); // Lien du titre
 
var liens = $$('.list-archives li a["title=mai 2008"]'); // Lien archive de mai 2008

La performance de ces sélecteurs est saisissante. Elle tient à quelques astuces d’implémentation, en particulier l’utilisation de XPath qui permet d’obtenir des résultats extrêmement rapides.

Pour le comparer, un test de performance (Slickspeed) est disponible sur le site de Mootools : http://mootools.net/slickspeed/ (à tester sur les différents navigateurs)

Implémentation native dans les navigateurs

Le W3C a très vite mis en chantier une API, réfléchissant dès le début 2006 à une implémentation native du sélecteur CSS dans les navigateurs.

Les résultats de ces travaux arrivent cette année dans les A-grade browsers :

• WebKit a sorti une implémentation en février 2008, Safari 3.1 devrait offrir le support
• Mozilla a une implémentation native dans Firefox 3.1 alpha
• Microsoft a d’ores et déjà une implémentation opérationnelle dans la Beta 1 d’Internet Explorer 8
• Opera sortira sa version des sélecteurs natifs pour Opera 10.

Les fonctions natives sont utilisables de la manière suivante

var el = document.querySelector("#headerimg");
var matches = document.querySelectorAll(".list-blogroll, .list-archives");

SPPlus est commercialisé par la Caisse d’Epargne. Hormis le cas particulier d’avoir un compte entreprise dans cette banque, il y a normalement peu de chances que vous soyez concerné par ce module.

Cependant, vous pourriez y trouver un bon intérêt car ce système de paiement offre des fonctionnalités assez intéressantes :

• support des grandes cartes du marché français (CB, Visa, Mastercard, Amex, Diner’s Card)
• support de quelques cartes de crédit à la consommation (Cofinoga, Aurore)
• paiement par chèque
• système de paiement multiple très poussé : paiement en N fois, abonnement, acomptes…

Le principe, à l’instar des deux modules évoqués précédemment, repose sur :

• une requête envoyée au serveur bancaire avec une clé de hachage (sceau),
• une communication après paiement directement entre le serveur bancaire et le site Internet
• une redirection de l’utilisateur vers une URL du site une fois le paiement effectué et la validation banque/site Internet terminée

Sur la partie technique, les informations du marchand (une clé et un code SIRET) servent d’informations pour les hachages envoyés au serveur et au retour pour le décryptage.

SPPlus est livré avec un kit PHP comportant une extension à installer. Après un rapide coup d’oeil sur le module en détails, on se rend compte qu’il se réduit à faire des hachages dans des fonctions natives, plutôt qu’en pur PHP (comme avec P@iement CIC par exemple). Attention donc si vous devez l’utiliser en environnement mutualisé, vous risquez d’avoir besoin de charger le module à la volée (si les permissions le permettent).
A noter : le kit existe également pour Java et C notamment. Ce qui donne une bonne indication sur la possibilité d’intégration pour des appareils mobiles.

Deux petits “plus” par rapport aux concurrents : la liste des IP des serveurs bancaires est connue et le script d’exemple fourni effectue un test sur $_SERVER['REMOTE_ADDR'] sur ces IP. Le test a une fiabilité relative, les variables $_SERVER étant toujours potentiellement piratables, il peut être judicieux de rajouter une petite sécurité supplémentaires en mettant une restriction à ces adresses dans un vrai pare-feu.

D’autre part, le site fournit des URLs pour effectuer quelques actions de paiement, ou traitement de paiement à distance, ce qui peut faciliter l’intégration dans une admin. Sur cette seconde fonctionnalité je suis extrêmement perplexe, car le script d’exemple laisse la clé directement dans le fichier PHP. Un pirate qui récupère le fichier à la main pour créer des paiements à sa guise… gloups. Assurez-vous dans tous les cas de mettre la clé en lieu sûr sur le serveur (non accessible par le web de préférence).

Les plus

• Paiement rapide à intégrer
• Documentation clean et efficace
• Les fonctionnalités de paiement en N fois / par abonnement
• La liste des IP des serveurs bancaires
• L’administration distante, pratique pour l’intégration du backoffice de paiement dans le site.

Les moins

• Le module PHP avec des fonctions de hachage dedans… est-ce vraiment nécessaire ?
• Clés marchand à sortir des scripts et à mettre dans un endroit plus sûr
• Réservé aux écureuils