Login  
 
0 vote

Par Cpag le 29/12/2014 à 13:21 Voir l'article

In this article, I explain how to install openSUSE 13.2 with full disk encryption.

My configuration

/dev/sda1 512MB ext2 mounted on /boot
/dev/sda2 [remaining space] LUKS container (named "cryptroot")
	LVM (named "lvmroot")
		rootvol	15GB BTRFS mounted on /
			var
		homevol	[remaining space] BTRFS mounted on /home

I do not use swap, but a swap partition could be easily created as a LVM volume.

Prepare the bootable images

We need Gparted live on a CD and openSUSE on a DVD.

Step 1: Partition with Gparted live

Boot on the Gparted live CD.

Using Gparted, make the partitions /dev/sda1 (512 Mb) and /dev/sda2 (remaining space).

Open a terminal, then create the LUKS container (and give the passphrase):

sudo cryptsetup luksFormat /dev/sda2
sudo cryptsetup luksOpen /dev/sda2 cryptroot

Then, create the LVM container on the LUKS container:

sudo pvcreate /dev/mapper/cryptroot
sudo vgcreate lvmroot /dev/mapper/cryptroot

Finally, create the volumes in the LVM container:

sudo lvcreate -L 15G lvmroot -n rootvol
sudo lvcreate -l +100%FREE lvmroot -n homevol

We didn’t format the volumes here. It will be done during the installation of openSUSE.

Step 2: Install openSUSE

Boot on the openSUSE DVD.

The installation process automatically detects the LUKS container and proposes to enter the passphrase.

On the “Partition” step, the suggested configuration is to remove the LUKS container and create a fresh partition. This is not our case. So, click on Create the partitions configuration → Custom partitioning (expert):

  • The partition /dev/sda1: format as ext2, mount at startup as /boot.
  • The volumes rootvol and homevol: format as BTRFS, mount at startup as / and /home. For my SSD, I use the following mount options: noatime,ssd,autodefrag,compress=lzo,discard,space_cache. In the volume rootvol, I replaced all the default subvolumes by a single subvolume var.
 
0 vote

Par Cpag le 30/09/2013 à 22:20 Voir l'article

J’ai récemment lu un article traduit qui prête à WordPress cinq faiblesses imaginaires.

J’ai pratiqué Joomla! en 2009 et 2010, à l’époque en version 1.5, avant de passer à WordPress. Les deux CMS suivent un chemin différent et il me semble que le lecteur qui n’aurait pas pratiqué les deux gagnerait à se faire une idée des différences bien réelles.

Joomla est un CMS généraliste centré sur son panneau d’administration. WordPress est un moteur de blog doté d’une API ouverte. Et cela change tout.

Prenons une opération simple. Nous souhaitons ordonner la liste d’articles d’une rubrique par ordre alphabétique. Sous Joomla, cela consiste à se connecter au panneau d’administration et à cliquer au bon endroit dans l’IHM. Joomla en effet stocke en base l’ordonnancement des rubriques au même titre qu’une ribambelle d’options servant à paramétrer le site.

Voyons l’opération équivalente dans WordPress. Aucun bouton n’existe pour cela dans le panneau d’administration. La procédure habituelle demande des connaissances en PHP. Voici comment faire. Dans le thème du site, dupliquer le fichier de template category.php et renommer la copie en suffixant par l’identifiant de la catégorie, par exemple : category-123.php. Puis éditer la copie. Afin d’ordonner sur le titre en alphabétique, insérer la ligne suivante juste après l’appel à get_header() dans le code PHP :

query_posts("$query_string&orderby=title&order=asc");

On comprend que Joomla et WordPress ne s’adressent tout simplement pas au même public. Joomla est préféré par les experts cliqueurs ou les utilisateurs finaux qui souhaitent, sans investir trop de temps dans la technique, construire eux-même leur site. WordPress en dehors du blog n’est utilisable que par des développeurs.

Je suis intégrateur et développeur Web. Je préfère WordPress car :

  1. En tant que développeur, programmer vaut mieux que cliquer. Je travaille plus finement et plus rapidement avec WordPress ;
  2. Le panneau d’administration de WordPress est apprécié de mes utilisateurs finaux. Celui de Joomla leur faisait peur.

Et voilà deux bonnes raisons de choisir WordPress plutôt que Joomla Ce sont de vraies raisons. Je ne résiste pas à reprendre les cinq mauvaises raisons de l’article cité plus haut. L’article prétend que :

  1. Joomla aurait plus d’extensions et plus de fonctionnalités, citons Joomla contre ce mensonge : 11 713 extensions WordPress, 6 745 pour Joomla. WordPress fait du commerce en ligne ni plus ni moins que Joomla. Le point est pour WordPress.
  2. Le panneau d’administration de Joomla fait plus de choses que celui de WordPress. Cet argument a déjà eu sa réponse ici et en ce qui concerne l’ergonomie pour un utilisateur final qui ne ferait pas lui-même son site Web, le point est pour WordPress.
  3. Sur la rapidité de l’entraide j’aimerais juste que l’auteur essaie pour voir, quant à moi je n’ai jamais eu besoin d’autre chose que l’aide en ligne. Ce point n’existe pas.
  4. Ici l’auteur cite une véritable différence entre Joomla et WordPress. WordPress n’a pas de version majeure alors que Joomla les collectionne. Les plugins et les thèmes de Joomla sont alors régulièrement bons pour la poubelle tandis que les évolutions de WordPress se passent en douceur. Le point est pour WordPress.
  5. Sur le temps qu’il faut pour concevoir un site Web avec Joomla, mais de qui parle-t-on ? Un intégrateur est aussi un développeur Web, il ira donc plus vite avec WordPress. Un utilisateur final souhaitant se débrouiller seul ne pourra tout simplement pas faire autre chose que du blog avec WordPress. S’il s’agit de rapidité de travail pour le professionnel, le point est pour WordPress.

Cela nous fait quatre à zéro pour WordPress.

L’objet de cet article était de réagir alors je m’arrête là. Mais des faiblesses de WordPress, il en existe pourtant : un code PHP procédural à l’ancienne, des performances douteuses, une configuration des URLs limitée, un mécanisme d’upload trop orienté blog… Et surtout l’impossibilité de configurer les groupes d’utilisateurs et les droits d’accès, ce qui est à mon avis le défaut le plus bloquant pour les projets de grandes tailles.

 
0 vote

Par Cpag le 13/09/2013 à 19:28 Voir l'article

La fausse route des ORM

Les mapping objets-relationnels sont une erreur. La conception du schéma d’une base de données obéit à des règles différentes de celles de la programmation à objets. Mieux vaut concevoir ses objets avec une approche « métier », je veux dire que les objets devraient être conçus en fonction de ce que le logiciel doit faire et non pas en fonction des règles de normalisation suivies par la base de données.

C’est un peu comme si la boutique devait coupler ses étalages avec les rayons de l’entrepôt. Mais les étalages sont gouvernés par le marketing alors que les entrepôts sont organisés par la logistique. Entre le responsable du marketing et celui de la logistique, qui gagnera ? Lorsque Hibernate ou EclipseLink génère la structure de la base de données au travers d’un code DDL, c’est le marketing qui gère les entrepôts. C’est l’assurance d’une logistique lente et inefficace.

Si l’ORM est une factorisation automatisée du code source, elle est surtout la factorisation du développeur paresseux et elle est loin d’être la plus élégante.

SQL versus ORM : une inversion des bonnes pratiques

Un mapping objet sert à naviguer d’objet en objet. Je sais qu’il est possible de faire autrement mais l’ORM sert à cela. Chaque objet est chargé avec l’intégralité d’une ligne d’une table. Et peu importe que telle colonne ne soit pas utilisée par telle partie du programme, l’objet du mapping chargera toutes les colonnes.

Par comparaison, le SQL sert à sélectionner les valeurs des cellules à utiliser et uniquement celles-là. Le SQL correspond bien au besoin du programmeur car il est rare d’utiliser simultanément toutes les colonnes d’une table dans une même portion du programme.

Certes les ORM proposent tous une solution palliative, une sorte de sous-dialecte SQL avec lequel il devient possible d’extraire des valeurs sans passer par les objets. Il s’agit ici d’une inversion des bonnes pratiques. Bien utiliser un ORM c’est d’abord utiliser les objets du mapping, puis éventuellement pratiquer le sous-dialecte SQL dans les cas qui le justifient. Bien utiliser le SQL c’est, toujours, en une fois, charger les données dont on a besoin, toutes les données dont on a besoin et seulement les données dont on a besoin.

L’élégance et la performance sont les fils conducteurs du SQL. L’ORM n’a que faire de l’élégance et se passerait bien des catastrophes en performance que lui inflige la réalité.

Le débat du SQL versus les ORM porte alors non pas sur ce qu’on peut faire – en vérité on peut faire des objets et des tableaux avec un ORM autant qu’avec du SQL – mais quelles sont les bonnes pratiques en matière de bases de données.

Le cas de PHP

Au-delà des considérations générales, l’utilisation systématique d’objets en PHP a un impact négatif sur les performances. Selon moi cela suffit à changer de perspective par rapport à d’autres langages : on ne devrait pas coder en PHP comme on code en Java. Le cœur de PHP est le tableau associatif PHP. Et ça tombe bien car il est dans la nature du SQL de ramener des tableaux. Alors pour la simplicité, l’élégance et la performance, restons-en à l’essentiel. Le couple « requête SQL – tableau PHP » est le meilleur choix partout où il s’avère suffisant.

 
0 vote

Par Cpag le 13/02/2013 à 14:26 Voir l'article

Nota. – Cet article est aussi une réaction à la remarque de Philippe Scoffoni : « Je défends régulièrement l’idée que les logiciels libres ne devraient pas être portés par des entreprises. »

Brevets et droits d’auteur

Les brevets et les droits d’auteurs sont des interdictions de dupliquer des créations numériques, ceci dans le but de donner à ces dernières des propriétés économiques similaires aux créations du monde physique.

Une création numérique est par nature dupliquable. Les brevets et les droits d’auteurs vont donc contre la nature des choses. Parions que leur usage déclinera.

Les trois niveaux d’accès aux produits numériques

Dans le contexte légal actuel, les interdictions de copies sont le cas normal. Aussi, protéger des créations numériques contre ces interdictions implique de mentionner explicitement que la copie est libre. C’est ainsi que le secteur logiciel a vu apparaitre les « logiciels libres ».

L’appellation « logiciel libre » inclut trois libertés : la liberté de copier et d’utiliser le logiciel, la liberté de regarder le code source (avant compilation en code machine), c’est-à-dire de voir comment le logiciel est fait, puis la liberté de réutiliser ce code source pour fabriquer une variante ou un nouveau logiciel.

À mon sens seule la liberté de copier est véritablement inhérente aux produits numériques. Le code source est au logiciel ce que la recette de cuisine est au biscuit : sauf s’il a un intérêt à la publier, le créateur conservera secrète sa recette et vendra les biscuits. Le concurrent tentera éventuellement de reconstituer la recette en analysant le biscuit, l’opération est difficile et parfois même moralement condamnable, mais il est heureux qu’il ne soit pas possible de la rendre illégale. Dans le secteur du logiciel, l’opération équivalente se fait au moyen d’un désassembleur et est tout aussi difficile, éventuellement moralement condamnable, et… malheureusement illégale.

Attardons-nous sur les deux autres libertés : celle de regarder le code source (la recette de fabrication) et celle de modifier ce code source pour créer un nouveau produit. Ces deux libertés sont couplées car il n’y aurait pas grand sens à faire l’effort de comprendre la fabrication sans en tirer un profit quelconque. Et cela est également vrai en dehors du secteur logiciel : l’écrivain publie au format PDF ou epub et conserve pour lui le fichier originel du traitement de texte, le graphiste publie un fichier image et non pas le fichier Photoshop, etc.

Aussi on peut distinguer trois niveaux d’accès aux créations numériques :

  1. les produits numériques dont le code source (les fichiers de travail) est gardé secret (mais ils restent copiables et utilisables) ;
  2. les produits numériques dont le code source est publié et réutilisable (en plus d’être copiables et utilisables) ;
  3. l’interdiction de copie par des artifices juridiques contre nature.

J’ai mis l’interdiction de copie en dernier car elle est vouée à l’obsolescence. Seules les deux premières options sont naturelles, mais alors les anciens modèles économiques hérités du monde physique ne fonctionnent plus.

Les créateurs individuels dans l’économie numérique

Un modèle qui reste largement à développer est le don de charité. En France le mot « charité » est souvent employé à tort dans le sens de « pitié ». Si on lui donne son véritable sens, à savoir, l’« amour », le véritable amour désintéressé envers autrui, et cela inclut la reconnaissance en vérité, il est crédible que la rémunération puisse fonctionner. Qui ne paierait pas une bière ou un café au bon gars qui a fabriqué tel outil « dont je me sers chaque jour » ou telle œuvre musicale « que j’apprécie tant » ? Il y a certainement un créneau économique pour la charité.

À titre personnel j’attends l’organisme qui se chargera de simplifier le paiement des dons et de gérer la distribution vers les créateurs, je lui confierai la rémunération de mes propres travaux.

Mais, pour de multiples bonnes raisons, la rémunération par charité s’applique à des individus plus qu’à des entreprises.

Les entreprises à but lucratif dans l’économie numérique

Le mode de rémunération d’un producteur numérique n’est pas celui d’un producteur industriel. Le produit industriel a par nature un cout de duplication et l’industriel est précisément focalisé sur sa diminution pour vendre plus d’exemplaires ou avec plus de marge. Le produit logiciel est au contraire multipliable sans frais et son producteur est alors focalisé sur l’amélioration du produit plus que sur la logistique.

Vendre un produit numérique

Si les biscuits industriels devenaient multipliables sans cout, le producteur de biscuits n’en vendrait qu’un puisque ses clients se chargeraient ensuite de le dupliquer. L’éditeur d’un logiciel est dans cette situation folle du producteur de « biscuits multipliables » et plutôt que de vendre les biscuits il ferait mieux de vendre des « abonnements à des améliorations de biscuits ».

Plaçons-nous dans le cas où le client est lui-même une entreprise. Puisque la duplication n’a aucune valeur ajoutée c’est l’amélioration qui en a. Un client rechignera toujours à payer trente exemplaires du même logiciel pour ses trente employés. Il est prêt en revanche à payer pour utiliser « le même produit mais en mieux ». On pourrait penser que, si le produit est dupliquable, le client sera tenté de se fournir chez son voisin et ainsi ne rien payer. Mais quelle garantie d’authenticité (et donc de sécurité) aurait-il alors ? Et qu’en serait-il du retard ou de l’incertitude sur les mises à jour ? Même pour les besoins les plus communs, si une entreprise utilise un logiciel développé à l’extérieur de l’entreprise, c’est précisément qu’elle ne souhaite pas gérer en interne la création ou l’évolution de ce logiciel. Un éditeur de logiciel pourrait alors, par contrat, interdire à ses clients de copier le logiciel en dehors du cadre de l’entreprise. Dans la plupart des cas cette condition serait respectée puisque le client : 1. trouve un intérêt à conserver de bons rapports avec son fournisseur dans la mesure où il a besoin des mises à jour, 2. ne trouve pas d’intérêt à diffuser le logiciel en externe, cela n’ayant pas de rapport avec son activité.

La vente d’abonnements de mises à jour est peut-être plus difficilement applicable aux particuliers. Quoique avec une offre et des tarifs adaptés, qui sait ?

Ce mode de rémunération est plus logique avec un code source conservé secret. En effet, les concurrents plus que les clients et les partenaires verraient un intérêt à regarder et réutiliser le code source.

Vendre un service sur le Web

Dans le cas d’un service mis à disposition sur le Web (« en ligne »), seule une petite partie du logiciel est récupérée par le client. Aussi la copie du produit complet est impossible. La vente d’un service sur le Web obéit donc plutôt aux règles de l’économie traditionnelle.

Certes, il se trouve que les utilisateurs du Web refusent de payer. La cause est ici dans les habitudes liées à Internet – car Internet est rempli de bénévoles et c’est ce qui le rend fantastique – et non pas dans la nature numérique des choses.

Un mot ici sur les publicités. Une manière répandue de se rémunérer sur un service gratuit est de s’appuyer sur l’économie des biens physiques en utilisant les biens numériques comme panneaux publicitaires. C’est notamment ainsi que se financent certaines messageries numériques gratuites et de nombreux sites Web. J’avoue que je crois assez peu à une généralisation de ce système sur le long terme. Le Web ne restera pas une annexe de l’économie des biens physiques.

L’aboutissement du logiciel est le logiciel libre

Une image. La production à but lucratif d’un logiciel ressemble à une échappée dans une course cycliste : 1. Le producteur crée un logiciel en avance dans son domaine, il le diffuse en conservant secret le code source. 2. Le producteur innove sans cesse pour vendre et se maintenir devant la concurrence. 3. Au fur et à mesure que la qualité des logiciels concurrents se rapprochent, le choix devient, libérer le code source ou devenir un acteur marginal.

Au passage, dès la première étape le producteur peut trouver un intérêt à libérer certaines briques de son produit, cela lui permet de mutualiser le développement de ces briques avec d’autres acteurs. Par exemple Cassandra fut libéré par Facebook et passé sous le contrôle de la fondation Apache, avant d’être adopté par Twitter.

Et voilà comment au bout du compte le logiciel libre est l’avenir du logiciel.

 
0 vote

Par Cpag le 12/02/2013 à 09:05 Voir l'article

Cela fait longtemps que Aptana (ou Eclipse avec le plugin PDT) présente des lacunes gênantes en tant que IDE pour PHP et ce n’est pas la première fois que je tente un passage à NetBeans. Cette fois-ci est la bonne, principalement parce que j’ai retrouvé des équivalents de tous les raccourcis clavier d’Aptana qui m’étaient nécessaires. Il y a un an certains n’existaient pas, ou bien avais-je mal cherché ?

Pour ceux que ça intéresserait, voici un comparatif des fonctionnalités qui me sont essentielles sur les dernières versions d’Aptana et de NetBeans : Aptana 3.3.1 et NetBeans pour PHP 7.2.1.

Les fonctionnalités communes

Les deux IDE reconnaissent la syntaxe des balises HTML 5 et des propriétés CSS 3. Les deux disposent de la panoplie standard des raccourcis clavier pour éditeurs de code source : CTRL HAUT et BAS (défilement de l’éditeur), CTRL GAUCHE et DROITE (équivalent des boutons « précédent » et « suivant » dans un navigateur), CTRL ESPACE (pour forcer les propositions d’auto-complétion), etc.

Certaines fonctionnalités similaires sont accessibles différemment :

Action Aptana / Eclipse NetBeans
Rechercher la sélection CTRL K CTRL F3
Aller à la déclaration F3 CTRL B
Supprimer une ligne CTRL D CTRL E
Aller au numéro de ligne CTRL L CTRL G
Ouvrir un fichier CTRL T ou MAJ CTRL R ALT MAJ O
La synchronisation du fichier sélectionné dans la fenêtre Projets avec celui édité. Bouton dans la fenêtre Projets Menu contextuel de l’éditeur

NB. Sur les deux plateformes les raccourcis sont configurables.

À l’avantage de NetBeans

Des fonctionnalités de NetBeans que Aptana et Eclipse n’implémentent pas :

  • La syntaxe PHP 5.4 est reconnue (Aptana étant resté bloqué sur PHP 5.3).
  • Les commentaires PHPDoc sont accessibles au survol des méthodes lorsqu’on presse la touche CTRL. Sous Aptana, seules les fonctions standards sont documentées.
  • NetBeans vient avec une fonctionnalité de refactoring pour PHP.
  • Le débogage en PHP est un gros atout (que je n’utilise pas).
  • L’IDE est globalement plus léger : plus réactif, plus rapide à charger. Il consomme moins de mémoire vive, il tient sur moins d’espace disque qu’Aptana ou Eclipse.

Toujours à l’avantage de NetBeans, des bogues ou défauts de Aptana/Eclipse :

  • Sous Eclipse et Aptana, un bogue empêche de commenter/décommenter plusieurs lignes à la fois sur les claviers azerty.
  • Sous Aptana, l’outil de marquage automatique des occurrences d’une variable, méthode ou classe ne fonctionne pas lorsque le curseur est positionné sur la déclaration d’une propriété dans une classe.
  • Sous Aptana, dans la fenêtre « Outline » (équivalent de « Properties »), les éléments listés sont repliés par défaut et cette fenêtre est par conséquent sous-utilisée.

À l’avantage d’Aptana/Eclipse

Des fonctionnalités propres à Aptana et Eclipse :

  • Le paramétrage de la recherche multi-fichiers est plus complet.
  • Le mécanisme de recherche dans les préférences est fantastique.
  • L’éditeur CSS d’Aptana est opérationnel sur les fichiers LESS CSS. Il râle beaucoup mais l’auto-complétion CSS reste fonctionnelle.

Toujours à l’avantage d’Aptana/Eclipse, des bogues ou défauts de NetBeans :

  • Sous NetBeans, dans la fenêtre « Properties » (équivalent de « Outline »), impossible d’afficher les membres par ordre d’apparition dans le code.
  • J’ai trouvé un cas où l’auto-complétion des membres d’une classe n’est pas accessible dans NetBeans : lorsqu’une instance est déclarée dans un autre fichier et rapatriée en global (je sais que c’est une horreur mais…).
  • Dans la fenêtre « Action Items » de NetBeans, impossible de n’afficher que les erreurs PHP et pas celles JavaScript par exemple. D’une manière générale cette fenêtre est moins utilisable que la combinaison de fenêtres « Tasks » et « Problems » de Aptana/Eclipse.
  • Il manque à la fenêtre « Search Results » de NetBeans une barre de défilement horizontale.

Alors NetBeans, sans regret

En ce qui me concerne, les défauts de NetBeans sont moins handicapants que ceux d’Aptana ou d’Eclipse. Le seul problème important que j’ai sous NetBeans est l’éditeur de CSS inutilisable sur une syntaxe LESS CSS. Il existe un plugin pour la coloration mais aucune solution pour l’auto-complétion des propriétés CSS. À noter : l’équipe de NetBeans plancherait sur l’intégration de la syntaxe SASS ou LESS.

 
0 vote

Par Cpag le 04/11/2012 à 14:49 Voir l'article

Java vs PHP, la différence qui change tout

En Java, chaque concept, même le plus insignifiant, mérite presque toujours une classe. Le nombre d’objets instanciés a peu d’impact sur les performances. Les programmes Java sont certes souvent un peu longs à démarrer, le temps de charger la machine virtuelle mais aussi de créer et de configurer le labyrinthe d’objets interconnectés qui forme le programme. Mais une fois le programme initialisé, il est réactif et stable. Java est particulièrement adapté aux traitements côté serveur. J’ai connu des démons écrits en Java turbinant un an durant sans un redémarrage et sans dire un mot. Java rejoint par endroit la stabilité des AS/400.

Un programme PHP est relancé à chaque requête HTTP reçue. Il n’est pas, comme en Java, chargé en mémoire et en attente des évènements. Il n’existe aucune manière de conserver un objet en mémoire pour le réutiliser d’une requête HTTP à l’autre. Les programmes PHP sont sans cesse réinterprétés et relancés, parfois plusieurs dizaines de fois par secondes.

Aussi la question de la performance du chargement des programmes PHP est cruciale. Les développeurs du langage PHP ont le souci permanent de la performance. Toutes les nouveautés sont orientées, courbées, pliées dans le sens de la performance, ce qui donne parfois des choses étonnantes comme la manière « file system » de penser les namespaces. Mais les créateurs du langage ne développent pas à notre place et, en définitive, si l’on ne fait pas l’effort de penser à notre tour dans le sens de la performance, la vélocité de l’écosystème PHP sera vaine.

Or l’instanciation des objets prend du temps. Nous devons créer nos objets PHP avec parcimonie…

Le couteau suisse de PHP : les tableaux associatifs

Faudrait-il pour autant revenir à un mode de raisonnement procédural ? Non. À tout le moins, pas au sens des langages procéduraux. Car PHP est malgré tout un langage à Objets.

PHP offre un outil optimisé, les tableaux associatifs, afin d’éviter la POO dans les petits détails. PHP incite à utiliser les tableaux associatifs là où en Java nous créerions des classes garnies de setters et de getters.

Prenons un exemple. Nous souhaitons représenter un point coloré. La manière Java d’écrire cela ressemblera à :

// On crée la classe…
 
public class ColoredPoint {
	private int x, y;
	private String colorCode;
 
	public ColoredPoint(int x, int y, String colorCode) {
		this.x = x;
		this.y = y;
		this.colorCode = colorCode;
	}

	public String getColorCode() {
		return this.colorCode;
	}

	public String getX() {
		return this.x;
	}

	public String getY() {
		return this.y;
	}
}
 
// … puis on l'utilise :
 
ColoredPoint cp = new ColoredPoint(10, 12, "99FF99");

En PHP nous écrirons plutôt :

$cp = array('x' => 10, 'y' => 12, 'color-code' => '99FF99');

Le code Java est intéressant à moyen terme. Le programme est compilé une seule fois, puis chargé également une seule fois, aussi les temps de compilation et de chargement ne comptent pas. Ensuite le programme attend les évènements (requêtes HTTP ou autres) et instancie des objets. N’en doutons pas, au bout de quelques dizaines ou centaines de réponses aux évènements, et quelques milliers d’instanciations plus tard, les appels aux getters se révèleront plus rapides qu’une recherche dans un tableau associatif.

Un programme PHP équivalent n’atteindra pas le millier d’instanciations. Il manipulera les quelques dizaines d’éléments nécessaires au traitement de la requête HTTP et rendra la main au bout de quelques microsecondes. Il sera recompilé et relancé une demi-seconde plus tard et pour un résultat similaire. Pas d’inertie en PHP.

Avec l’inertie, Java gagne. Mais est-ce bien certain ? Tout dépend des traitements. Les API Java mettent en jeu une foule d’objets et sont lentes. La complexe API de calcul d’un SHA1 en Java restera toujours plus lente que la fonction bien optimisée de PHP dédiée à cette tâche. En outre il arrive souvent que le temps des traitements soit insignifiant devant celui des I/O. Au final, en Java, nous avons la possibilité de stocker en RAM des choses prêtes à resservir là où PHP est condamné à toujours réitérer ses efforts sans plus d’organisation, et cela est un atout de Java pour qui sait s’en servir.

Pour revenir à notre code PHP, sa concision joue en faveur d’une compilation et d’un chargement plus rapide. Et la création d’un tableau PHP est plus performante que l’instanciation d’une classe.

Mais, me direz-vous, notre « point coloré » fera forcément l’objet de traitements. Si l’on utilise un tableau, on ne peut pas lui adjoindre de méthodes pour ces traitements.

Exact ! D’où la question qui suit.

En PHP, jusqu’où aller dans la POO ?

Le langage PHP pose la question de jusqu’à quel niveau de précision on reste dans l’orienté objet. Un arbitrage doit être fait : cet objet qu’on hésite à créer, l’utilisera-t-on partout dans le programme ou juste pour un traitement particulier ? A-t-on besoin d’une dizaine de méthodes ou de juste les getters et une fonction de traitement ?

En Java on arbitre presque toujours en faveur d’une classe. On va loin dans les détails insignifiants, on va jusqu’à créer des petites classes privées pour les besoin internes d’une classe. En Java tout ce qui n’est pas un type primitif mérite une classe.

En PHP, au contraire, mieux vaut un tableau qu’un petit objet.

En ce qui me concerne voici une règle que je suis : lorsque j’hésite, j’utilise par défaut un tableau associatif. Dès que le code pour manipuler ce tableau devient plus complexe que s’il s’agissait d’un objet, je recode avec une classe.

Un peu plus sur les tableaux PHP, le principe du copy-on-write

Les tableaux en PHP sont implémentés selon le principe du copy-on-write ou copie sur écriture. Le paramètre n’est copié que si on y accède en écriture. Et c’est pourquoi il serait contreproductif, dans un but d’optimisation, de passer par référence un tableau à une fonction.

Un exemple :

function test(array $a) {
	echo $a[0]; // on utilise la tableau en lecture
	// jusqu'ici le $a original n'est pas dupliqué
	$a[1] = 'haricot'; // duplication du $a original et modification de la copie
}
 
$a = array('ananas', 'banane', 'tomate');
test($a);

Ou bien un autre exemple, plus simple encore :

$a = array('ananas', 'banane', 'tomate');
$b = $a;
// ici $b et $a pointent sur le même tableau.
$b[1] = 'haricot'; // copie sur écriture
// ici $b et $a pointent sur deux tableaux différents.

Les tableaux PHP sont toujours passés par référence, et l’opérateur & sert en fait à désactiver la copie sur écriture. Le copy-on-write rend la manipulation des tableaux PHP similaire à celle des objets constants clonables (à l’instar des String de Java).

PHP est un langage à Objets : créons des objets. PHP fournit des tableaux polyvalents et optimisés : dans les méthodes de nos objets, évitons d’instancier trop de petits objets et utilisons des tableaux.

 
0 vote

Par Cpag le 12/10/2012 à 21:17 Voir l'article

La méthode GET d’un formulaire HTML ou d’un envoi en Ajax n’est pas juste une manière de passer des paramètres dans l’URL. GET est une « méthode » (au sens d’une « fonction » d’un langage de programmation) du protocole HTTP. Par exemple l’URL www.monsite.com/ma-page?lang=fr peut être utilisée par une requête HTTP de type GET ou POST. S’il y a un paramètre, alors en GET il sera ajouté dans l’URL ce qui donnera : www.monsite.com/ma-page?lang=fr&mon-param=ma-valeur. En POST l’URL est utilisée telle qu’elle est et les paramètres sont envoyés à côté.

Le protocole HTTP

La RFC 2616 du W3C définit les méthodes du protocole HTTP, dont notamment les quatre suivantes pleinement exploitées en architecture REST : GET (lecture), POST (tout type d’écriture), PUT (écriture à un endroit donné à la manière d’une valeur dans un tableau associatif) et DELETE (suppression). La syntaxe des formulaires HTML n’autorise que GET et POST et dans cet article nous nous en contenterons également. Toutefois, notons que les quatre méthodes restent utilisables en Ajax (JavaScript) sur les navigateurs modernes.

GET est « safe », c’est-à-dire qu’une requête HTTP GET n’a pas de conséquence significative autre que le chargement d’une ressource. GET est en outre « idempotent » ce qui signifie que plusieurs requêtes HTTP GET identiques lancées à la suite provoquent le même effet (retournent le même contenu Web) qu’une seule. Le navigateur peut donc mettre en cache la réponse à une requête GET. GET est idéale pour les accès en lecture. Et c’est en GET que le navigateur accède au serveur lorsqu’on saisie une URL dans la barre d’adresse.

POST est au contraire non « idempotent » et non « safe » ce qui en fait la méthode la plus généraliste du protocole HTTP. On peut alors en faire ce qu’on veut sans contrevenir à la norme. On l’utilisera pour tous les accès en écriture : les ajouts, modifications et suppressions. Le résultat d’une requête POST n’est pas mis en cache par le navigateur (inutile puisqu’elle n’est pas « idempotent »).

Coté navigateur, bien choisir entre GET et POST

Pour les accès en écriture, la méthode POST doit être utilisée. C’est obligatoire. Celui qui modifie le contenu de son site Web à coups de requêtes GET est en dehors de la norme HTTP et cela a des conséquences. Si par exemple on voulait faire deux ajouts identiques en GET, le navigateur pourrait décider de mettre en cache la réponse et la resservir plutôt que de lancer deux fois l’ajout : absurde.

Pour les accès en lecture, GET doit être préféré.

Coté serveur, bien gérer POST

En PHP, si une ressource Web existe, le langage la rend par défaut accessible à la fois en HTTP GET et en HTTP POST. Ainsi, en réponse à une requête HTTP GET ou POST sans paramètres, une page PHP fournira le même document. Nous devons comprendre que c’est un choix de PHP et non pas une manière générale de faire. Par exemple en Java on reçoit les requêtes HTTP GET et POST dans deux méthodes différentes et on choisit explicitement de faire ou non le même traitement.

Le double accès par défaut des ressources PHP ne pose pas de problème particulier. La plupart des accès se feront de toute manière en GET pour la lecture des pages du site.

En écriture cependant, suite à la réception en POST des données saisies dans un formulaire HTML, un programme PHP ne devrait pas renvoyer un document Web. En effet, ce dernier ne serait pas mis en cache, ce qui pose un problème de performance, et puis le navigateur risquerait de relancer la requête POST si l’utilisateur jouait des boutons « Précédent » et « Suivant ». La RFC du W3C recommande de retourner un statut de réponse HTTP 200 (OK), 204 (Pas de contenu), 201 (Créé) ou 303 (Voir aussi). Les premiers statuts de réponse seront exploitables en Ajax. Le dernier redirigera le navigateur vers une URL à charger en GET.

Dans le cas où l’envoi en POST d’un formulaire HTML créerait ou une nouvelle page Web (cas d’un nouvel article dans un blog) ou modifierait une page existante (cas de l’ajout d’un commentaire sous l’article), le programme PHP ne devrait pas afficher la page directement. Il devrait renvoyer le code 303 accompagné de l’URL de la page à (re)charger.

En PHP, à la suite du traitement réussi des données envoyées, on écrira ceci :

header("Location: the/url/to/load", true, 303);
exit;
 
0 vote

Par Cpag le 10/10/2012 à 12:43 Voir l'article

Sur une connexion béninoise, j’ai réduit mon temps de déploiement d’un site Web de quatre heures à trente minutes.

Trois problèmes, une solution…

Lors de l’upload d’un site Web, les connexions à bas débits posent plusieurs problèmes et le premier est l’intégrité des fichiers. Je prends l’exemple d’un projet à base de WordPress classique : plus de mille trois cents fichiers et dossiers. En les transférant directement par un logiciel client FTP sur une connexion un peu faible, le risque que l’un des fichiers n’arrive pas entier est élevé.

Les problèmes suivants sont la bande passante et le temps de transfert. Transférer des centaines de petits fichiers demande de nombreuses commandes FTP. Les transférer en une seule opération est moins couteux en bande passante et en temps. Le site est en outre composé de nombreux fichiers textuels qui gagneraient à être compressés le temps de l’upload.

Nous allons donc compresser tout le site Web avant de le transférer.

Il nous faudra ensuite le décompresser sur le serveur distant. En hébergement mutualisé nos n’avons pas accès au shell distant via SSH. Notre seul outil est le langage PHP. Utilisons-le.

PHP donne accès au shell du serveur au travers des commandes exec, passthru et system. La dernière affiche la sortie de la commande et donc les éventuels messages d’erreurs, c’est elle que nous utiliserons. Certains hébergeurs proposent aussi un module ZipArchive. Nous avons donc l’embarras du choix.

La procédure à suivre

  1. Compresser le site Web en un seul fichier « deploy.tar.bz2 » ou « deploy.tar.gz ».
  2. Depuis le client FTP (par exemple FileZilla), sur l’hébergement distant, créer un dossier caché .tmp1234 (pour une plus grande sécurité, remplacer « tmp1234 » par un code de votre choix). Puis y transférer le fichier compressé ainsi que le fichier PHP chargé de la décompression. Je donne plus bas les codes PHP pour les différents formats.
  3. Depuis un navigateur, charger la page PHP de décompression. Par exemple : www.votre-site-web.com/.tmp1234/uncompress-tarbz2.php.
  4. Depuis le client FTP, rafraichir l’affichage du contenu du dossier caché. Le site Web décompressé s’y trouve. Le déplacer à la racine ou au bon endroit dans le site via un glisser-déplacer sur le dossier parent ...
  5. Depuis le client FTP toujours, supprimer le dossier caché et son contenu (le fichier compressé et la PHP de décompression).

Codes PHP de décompression

Vous choisirez le fichier PHP qu’il vous faut selon le format de compression.

Décompresser le format .tar.bz2

Le contenu du fichier uncompress-tarbz2.php :

<?php
$res = system('tar -xjf deploy.tar.bz2');
echo $res === false ? 'failed' : 'ok';

Décompresser le format .tar.gz

Le contenu du fichier uncompress-targz.php :

<?php
$res = system('tar -xzf deploy.tar.gz');
echo $res === false ? 'failed' : 'ok';

Décompresser le format .zip par le module PHP

Le contenu du fichier uncompress-zip.php ne fonctionnera pas sur tous les hébergeurs. Il s’appuie sur le module ZipArchive de PHP :

<?php
$zip = new ZipArchive();
$res = $zip->open('deploy.zip');
if ($res === true) {
	$zip->extractTo('./');
	$zip->close();
	echo 'ok';
} else
	echo 'failed';

Décompresser le format .zip par la commande Shell

Si l’utilitaire unzip est installé chez l’hébergeur, on peut tenter de décompresser les fichiers .zip par le shell. Voici le contenu de uncompress-zip-alt.php :

<?php
$res = system('unzip deploy.zip');
echo $res === false ? 'failed' : 'ok';
 
0 vote

Par Cpag le 20/09/2012 à 13:46 Voir l'article

Avertissement. Je laisse cet article en ligne pour l’historique mais il utilise une définition erronée de la notion de pixel. Ce que je pensais être les pixels sont en fait des “points physiques” (pixel device) c’est-à-dire PAS les pixels que l’on manipule en CSS. Le pixel en CSS est le 96ème d’un pouce observé à un bras de distance. Les écrans classiques font 96 dpi et donc dessus un pixel CSS équivaut à un point d’écran mais cela n’est plus vrai sur les écrans à haute résolution. Cela signifie qu’on peut faire du design adaptatif en pixels.

Pourquoi ne faut-il plus utiliser les pixels dans les règles CSS pour écrans (le média screen) ?

C’est parce que… la taille du pixel devient trop variable d’un écran à l’autre. La finesse de l’affichage des écrans s’accroit sans cesse. Les résolutions sont de plus en plus hautes même sur des écrans de téléphones de tailles réduites. La très classique résolution de 1024×768 pixels sur des écrans d’ordinateur de quatorze ou quinze pouces sera bientôt rejointe par celle des smartphones qui tiennent dans la poche. Gageons que celle des écrans d’ordinateurs s’envolera à son tour. Avec les écrans Retina Apple a lancé la course à la finesse, et il est bien possible que dans les prochaines années les écrans multiplient plusieurs fois leur nombre de pixels.

Aussi, une largeur en pixels ne permet plus d’avoir une idée de la taille affichée. Par exemple sur les écrans d’ordinateurs actuels une barre latérale large de trois cents pixels est affichée sur six ou sept centimètres et peut contenir une quarantaine de caractères. Sur les prochaines générations d’écrans, les mêmes trois cent pixels pourraient bien ne faire que deux centimètres de largeur et n’afficher que quelques caractères.

Je parle de positionnement en CSS mais il est évident que les tailles de caractères doivent encore moins être définies en pixels, la lisibilité des textes du site en dépend. Cela explique pourquoi le reset CSS de Eric Meyer définit une taille de police par défaut à 100%, c’est-à-dire qu’elle est laissée au choix du navigateur et des préférences de l’utilisateur.

Deux unités sont à privilégier en positionnement CSS : le pourcentage (%) et le cadratin (em).

Relativement à la largeur des blocs : le pourcentage (« % »)

Le pourcentage est l’unité privilégiée par Ethan Marcotte pour faire du responsive Web design, c’est-à-dire du design proportionnel ou encore « fluide ». Un design avec des largeurs proportionnelles est « élastique ». Il s’adapte à la largeur de l’écran, que celui-ci fasse trois ou vingt-trois pouces, et sans se soucier du nombre de pixels.

Relativement à la taille du texte : le cadratin (« em »)

La dimension d’un cadratin (la largeur d’un espace de texte, ou encore de la lettre « M ») est par nature lisible par l’œil humain. Et donc en travaillant en em on indexe le design sur les capacités de l’œil humain. Les blocs positionnés conserveront une largeur cohérente pour l’humain quelle que soit la finesse de la résolution ou la largeur de l’écran. Une barre latérale de 18.75em aura une largeur sensiblement équivalente sur les écrans de tablettes, de smartphones, d’ordinateurs etc. d’aujourd’hui et de demain.

Par rapport à nos habitudes sur les écrans d’ordinateurs classiques, la règle de conversion à suivre est simple : 16 pixels font 1 em.

L’unité em est utilisée pour les hauteurs dans les designs responsive (fluides). C’est également l’unité « à tout faire » des designs non proportionnels et en particulier des grilles frameless. Au passage, en ce qui concerne les grilles des designs, je recommande chaudement au lecteur l’unité em plutôt que les pourcentages.

L’unité em a en outre l’avantage d’être facile à manipuler pour l’impression (le média print). Elle est en effet indexée sur le point (pt). Par exemple si la taille du texte est 12pt alors le cadratin mesure douze points. Une mise en page réalisée pour écran sera donc réutilisable sur imprimante.

Pixels malgré tout ?

Il m’arrive encore d’utiliser les pixels sur écran dans un cas particulier : les images non vectorielles. Ces images ont en effet une taille optimale d’affichage en pixels et il est parfois justifié, pour les règles CSS qui les concernent (les décalages pour les images de background notamment), de travailler en pixels.

 
0 vote

Par Cpag le 12/09/2012 à 15:24 Voir l'article

Raphaël Goetter a publié dimanche une charge contre l’usage systématique de la sémantique en CSS. L’argument qui m’intéresse est qu’une classe CSS sémantique ne serait pas réutilisable. On imagine mal en effet comment une classe .sticky-video pourrait servir à positionner un bloc autre que celui des vidéos mises en avant. Mais de quelle réutilisabilité parle-t-on ?

Je prendrai dans cet article deux domaines de l’habillage des pages Web : le titrage et le positionnement.

Le titrage d’abord. L’article de Nicole Sullivan sur les éléments de titre est convainquant. L’auteur suggère d’utiliser des classes réutilisables .h1, .h2, .h3 etc. afin d’habiller les titres. Si un design prévoit cinq types d’habillage des titres, on comprend bien que cela ait du sens de marquer en HTML les éléments de titres par des classes CSS réutilisables, plutôt que d’utiliser en CSS des sélecteurs complexes et nombreux. Et puis ces classes aideront à décliner les titres de manière homogène selon les médias par media queries.

Venons-en au positionnement en CSS.

En positionnement CSS, le raisonnement de Nicole S. ne donnerait pas des classes du type .left ou .span3 comme fournies par les frameworks CSS Knacss et Bootstrap. L’équivalent de telles classes en titrage ressemblerait plutôt à .titre-encadré-bleu à la place de .h2. Pour positionner à la manière des titrages de Nicole S., il faudrait plutôt utiliser des classes génériques telles que .pos-type-1, .pos-type-2 etc. Ainsi si le designer définissait des types de positionnement et s’y tenait, cela aiderait certainement à les décliner de manière homogène selon les médias. Cela dit par expérience le design ne se prête pas facilement à une homogénéisation du positionnement des blocs.

Pour résumer, il me semble que la pratique des classes CSS réutilisables se justifie dès que l’on peut définir des types homogènes (de titrage, de positionnement etc.). L’apparence est alors déclinable selon les médias. Mais en aucun cas le nommage de ces classes CSS ne devrait dépendre de l’une de ces déclinaisons !

Et donc en dehors des types homogènes, un nommage sémantique reste à mon avis une bonne pratique. Car enfin à quoi sert la sémantique ? La sémantique en CSS ne sert-elle pas précisément à rendre le code CSS plus facile à maintenir et à décliner sur différents médias ?

En vérité ce sont les classes « techniques » de Knacss et Bootstrap qui ne sont pas réutilisables. Si par exemple le nom d’une classe implique une mise en page sur trois colonnes pour des écrans de quinze pouces, comment passer à sept colonnes sur les écrans plus larges ?

Certes, le langage CSS est de bas niveau et force effectivement à la répétition et au copier-coller. Les préprocesseurs CSS (dont LESS) répondent élégamment au problème de la réutilisation sans pour autant s’assoir sur la sémantique.

Un bémol toutefois, quoique très spécifique. Il me semble que des classes « techniques » en CSS se justifieraient dans le cas d’une affectation en dynamique sur des éléments HTML, en JavaScript. On peut en effet gérer l’apparence dynamiquement par JavaScript, selon la largeur du navigateur, comme le fait Facebook.