Oui évidemment.

Et nous de répondre « Merci Captain Obvious ».

Cependant et pas seulement pour remplir quelques lignes de plus sur ce blog, il s’avère que tant question comme réponse peuvent dans les faits se révéler un tantinet plus complexe.

Depuis que je pratique le code et après les quelques lignes écrites par mes nombreux confrères que j’ai pu lire, certains profils se dégagent clairement dans la grande caste des commentateurs de fichiers sources que nous sommes.

Le prolixe

Sans surprise, le prolixe commente beaucoup, son style est souvent irréprochable et son art de trouver le « mot juste », celui de Flaubert, frôle souvent la perfection.

Le pointilleux

Le pointilleux commente tout et peut se targuer que dans toute sa carrière, pas un seul malheureux octet de fichier source n’ait été couvert par l’un des ses commentaires avisés.

L’obscur

Contrairement au pointilleux, l’obscur ne commente rien ou presque, trouvant que ce qu’il a fait s’avère être très clair quoiqu’un peu alambiqué. Oui l’obscur est un être paradoxal.

Bon nous avons vu ce qu’il ne fallait pas faire, voyons maintenant a partir de quelques conseils simples comment améliorer nos commentaires.

1. Évitez d’avoir à commenter

Dans un monde idéal on ne devrait pas avoir à commenter. Dans un monde idéal votre code devrait couler telle une tranquille rivière le long de son lit.

Alors certes nous ne sommes pas dans un monde idéal, mais cette vérité concerne plutôt le point 2, ici nous allons tout faire pour nous approcher de l’idéal.

Donnez à vos variables des noms significatifs. Evidemment ne sombrons pas dans la caricature avec des $variableServantPourIncrementerMaBoucle à la place d’un $i adopté par tous, mais plutôt qu’un énigmatique $tab ne vous privez pas d’un $listModelCar immédiatement plus parlant.

2. Commentez pour expliquer

Malgré tout et comme dit plus haut, nous ne sommes pas dans un monde idéal Une fois ce terrible constat fait, il nous reste deux choses à faire en premier lieu, s’engager dans une oeuvre humanitaire et commenter notre code.

Il peut arriver que vous écriviez votre code et qu’en le relisant rapidement vous arriviez à la conclusion suivante : « On y comprend rien »

Alors après avoir suivi le premier conseil et essayé de simplifier et clarifier votre code, commentez pour expliquer. Commentez en indiquant pourquoi vous avez choisi cette solution, pourquoi cette voie vous a semblé meilleure à suivre. Prenez du recul et essayez d’imaginer ce qui vous aurait fait gagné du temps en arrivant sur ce bout de code que vous venez d’écrire.

3. Commentez pour mettre en lumière

Parfois, une partie de votre code peut paraître anodine mais est en réalité très importante. Dans ce cas n’hésitez pas à indiquer en commentaire l’importance de ce petit bout de code. Défendez-le contre le risque d’altération si vous pensez cela nécessaire.

Exemple

4. Ne commentez surtout pas comme ça

Il y a une chose horrible, une chose qui provoque la mort d’un chaton quelque part sur Terre à chaque fois que cela se produit.

Oui vous tuez un chaton à chaque fois que vous commentez du code ! Vous ne pourrez plus dire que vous ne saviez pas. Le fait de commenter du code à cette particularité horrible de mettre le développeur qui passe derrière vous dans une situation très inconfortable. « Pourquoi ce code a-t-il été commenté ? », « Faut-il le conserver ? », « Peut-on l’effacer ? »

Vous utilisez sans doute un gestionnaire de révisions, qu’il s’agisse de Git ou Subversion ou n’importe lequel d’autre, il est cent fois, mille fois plus adapté à garder trace de votre code que ces pauvres commentaires.

Conclusion

Nous avons vu tout cela un peu rapidement mais vous avez compris l’idée, efforcez-vous d’être clair, concis et évitez les redondances. Pour ne garder qu’un conseil commentez comme vous codez. Ne commentez pas pour rien et apportez le plus grand soin aux commentaires que vous aurez à produire.

C’est vrai Git est à la mode. Sans doute en partie grâce à son support n°1 Github mais aussi parce que pouvoir versionner seul dans son coin sans à avoir à se soucier d’un serveur n’a jamais été aussi simple ou parce que sa gestion des branches est aussi succulente qu’un petit chocolat fourré aux amandes.

Moi-même j’utilise Git pour tous mes projets perso, que ce soit en développement ou pas d’ailleurs.

On en vient à se poser la question « Qui peut donc encore utiliser Subversion aujourd’hui ? » :troll respotted:

Alors loin de moi l’idée de refaire ici la guéguerre¹ car que vous le vouliez ou non la réponse à la question posée est : Énormément de monde.

Subversion, SVN de son petit nom est encore très largement implanté car historique et très bien supporté par la plupart des systèmes et IDE existants. Il est donc bon de connaitre quelques petits trucs et astuces, le concernant au cas ou vous auriez à traiter avec la bête.

C’est l’objet de ce post ^^

 Bonnes pratiques

Avant de commencer voici 3 bonnes pratiques qui pourraient s’appliquer d’ailleurs à bon nombre de gestionnaire de révisions et pas seulement SVN. Elles vous permettront de travailler intelligemment.

• Commitez souvent
  Il est important de commiter souvent. Bien sur vous prendrez le soin de ne pas casser le build, mais il faut garder aussi peu de valeur que possible dans votre répertoire de travail.
• Commitez « intelligent »
  Essayez de grouper les modifications qui « s’emboitent » logiquement. Ne mettez pas dans le même commit votre correction d’indentation et l’ajout d’une fonctionnalité.
• Essayez d’être le plus descriptif possible dans le commentaire de vos commits
  Ce sera utile pour les autres développeurs (ou vous même 6 mois plus tard) pour identifier clairement un commit.

Astuces

L’utilisation de Subversion peut être encore faciliter par de menues modifications, il est aussi bon de rappeler comment revenir à êtat antérieur si vous avez par exemple provoqué un bug² ou si le client a changé d’avis³

Avoir un ignore global

Dans svn vous pouvez éditer projet par projet les fichiers que vous souhaitez ignorer via la propriété svn:ignore.Cependant, il peut être utile de définir une fois pour toutes que les fichiers .properties et .pyc bordel on en veut pas !!!

Pour faire cela sans s’énerver, c’est très simple. Il suffit d’éditer le fichier config. Balancez depuis votre répertoire personnel un petit

vim .subversion/config

Cherchez la ligne global-ignores et indiquez tous les patterns des fichiers que vous ne voudrez jamais versionner.

Si vous utilisez Windows et l’excellent TortoiseSVN, il suffit de faire un clic-droit TortoiseSVN > Settings et vous avez sur General (la 1ere page) le global ignore pattern que vous pouvez éditer.

Utiliser Vim pour vos diffs

Le diff par défaut de SVN est assez difficile à lire dans un terminal. En revanche l’excellent Vim propose un outil très pratique vimdiff

Creez où vous le souhaitez le fichier suivant (que vous pouvez trouver dans la doc SVN diffwrap.sh)

#!/bin/sh

# Vous pouvez ici configurer votre editeur favori
DIFF="/usr/bin/vimdiff"

# Subversion nous fourni les fichiers à comparer en 6e et 7e arguments
LEFT=${6}
RIGHT=${7}

#On envoie la commande
$DIFF $LEFT $RIGHT

# La commande doit renvoyer 0 si les fichiers sont identiques et 1 s'il sont différents

Ensuite ouvrez à nouveau le fichier .subversion/config et éditez le section helpers comme suit :

[helpers]
diff-cmd = /home/jk/bin/diffwrap.sh

Il vous suffit dorénavant d’un petit svn diff pour profiter de vimdiff

Faire un rollback

De manière assez étonnante, le client à donc changé d’avis et il vous faut revenir en arrière. Admettons que nous en somme à la revision 7 et que vous souhaitez éffacer les modifications faites depuis la revision 4 du fichier colours.css vous lancerez la commande suivante :

svn merge -r HEAD:4 http://serveur.org/repo/css/colours.css .

Cela permet de mettre le fichier dans votre copie de travail sans toutes les modifications effectuées entre les révisions 7 et 4. Il ne vous reste plus qu’à vérifier et commiter.

Bouger un dêpot

Il peut arriver pour une raison ou une autre d’avoir à bouger un dêpot (suite à un changement de serveur par exemple) pour se faire on va procéder en 2 étapes. D’abord faire un dump du dêpot actuel⁴ puis le charger sur le nouveau serveur.

svnadmin dump /chemin/actuel/du/depot > depot.dump //voici pour le dump
svnadmin load /chemin/du/nouveau/depot < depot.dump

Et nous voila rendu

Savoir quels fichiers vont être mis à jour

Il peut aussi être très utile de savoir avant un update quels sont les fichiers qui vont être effectivement mis à jour. Cela se fait très simplement via la commande :

svn st -u

Conclusion

Nous avons donc vu ici quelques bonnes pratiques et quelques petites astuces qui vous permettront de mieux utiliser ce très bon outil qu’est subversion. C’est toujours bon à prendre

1. il suffit de taper svn vs git dans votre moteur de recherche favori
2. c’est rare je sais
3. alors ça ça n’arrive carrément jamais … -_-
4. oui comme pour une base de données

Après avoir¹ répondu, quelque chose m’a frappé. Non ce n’était pas l’interrogateur insatisfait², mais bien l’idée que, peut être, d’autres personnes avaient besoin d’un petit rappel à propos de nos amies les interfaces.

Définition

Si l’on prend notre gros robert le Larousse, il nous apprend ceci :

Plan ou surface de discontinuité formant une frontière commune à deux domaines aux propriétés différentes et unis par des rapports d’échanges et d’interaction réciproques.

Les concepts à retenir de cette définition somme toute générale sont frontière commune et rapports d’échanges.

Si l’on se rapproche un peu de l’informatique et toujours dans le Larousse

Jonction entre deux matériels ou logiciels leur permettant d’échanger des informations par l’adoption de règles communes ; module matériel ou logiciel permettant la communication d’un système avec l’extérieur

En code

Du code, du code, du code !

En réalité pas tout de suite Ce qu’il faut avant tout comprendre avec les interfaces, c’est qu’il s’agit d’un contrat (quasiment moral ^^) apporté par votre code. Vous pouvez être certain qu’une classe qui implémente votre interface disposera des méthodes que cette dernière aura défini.

Exemple en PHP

Une interface se déclare comme une classe à l’exception du fait que l’on utilise le mot-clé interface plutot que class.
Ensuite on déclare tout ce que l’on souhaite pour définir notre interface, cela peut-être évidemment les méthodes mais on peut tout aussi bien déclarer des constantes de la même manière que si on les avait déclarées dans une classe.

<?php

interface MonInterface {
    public function maMethodeInterface($arg);
}

class MaClasse implements MonInterface {
    public function maMethodeClasse(){
        echo 'ma Classe';
    }
  
    public function maMethodeInterface($arg){
        //implementation
    }
}

Et que se passe-t-il si la classe n’implémente pas la méthode de l’interface ? >> Erreur fatale.

Oui mais

Qu’est-ce qui m’empêche de créer ma classe avec la méthode qui m’intéresse directement sans passer par une interface ?

A vrai dire rien. Cependant l’interface plus qu’une perte de temps au moment de l’écriture, garantit la cohérence et l’interopérabilité de votre code.

Petite illustration

Prenons le cas d’un projet auquel j’ai participé très récemment.
Celui-ci avait vu plusieurs développeurs se succéder et les interfaces y avaient été peu mises à contribution.

Le principe est de suivre une course de bateaux, on avait sur une première carte des bateaux et sur une autre des balises GPS. Le problème portait justement sur ces positions GPS qui étaient récupérées différemment selon que l’on traitait une balise ou un bateau.

<?php

class Balise {
	
	/**
	 * @return array($lat, $lng)
	 */
	public function getLatLng(){
		//@implementation
	}
}

class Bateau {
	
	/**
	 * @return float latitude
	 */
	public function getLatitude(){
		//@implementation
	}
	
	/**
	 * @return float longitude
	 */
	public function getLongitude(){
		//@implementation
	}
}

Autres avantages

Les interfaces permettent aussi de régler le problème d’héritage multiple. En effet en PHP comme en Java, il n’est pas possible pour une classe d’hériter de plusieurs autres classes tandis qu’une classe peut implémenter un nombre quelconque d’interfaces.
D’autre part, un code basé sur des interfaces sera plus facilement testable puisque l’on pourra aisément substituer les objets attendus par des Mocks.

Pour conclure

En développement comme dans bien d’autres domaines, abstraire et prendre du recul est une chose primordiale pour faire mieux et limiter les risque d’erreurs. Utiliser des interfaces vous aidera à prendre ce recul et à mieux penser votre code.
Utiliser des interfaces vous permettra aussi de rendre votre code « futur-proof » en assurant une modularité certaine et en respectant le principe ouvert/fermé de SOLID dont on a déjà parlé.

1. brillamment ^^
2. puisque je vous dis que j’ai été brillant :O

Je viens de passer une bonne vingtaine de minutes à essayer d’installer PEAR. Histoire que ce soit un peu plus rapide pour vous voici la démarche

Step Up 1

Avec WampServer 2, les sympathiques gens d’Alter Way nous ont sucré le go-pear qui permettait l’installation de PEAR. Il y a sans doute une bonne raison à cela mais pour nous ça signifie la nécessité de le télécharger à la mano.

On se rend donc à l’adresse  http://pear.php.net/go-pear et on dépose le fichier go-pear.php obtenu dans votre dossier Wamp¹

Step up 2

Ouvrez maintenant un terminal et lancez la commande

php go-pear.php

Vérifiez que tout soit correct et appuyez sur Entrer.

Step up 3

Chez moi je tombais sur une erreur pas cool :

SECURITY ERROR : Will not write to C:\\Users\\Loulou\\patati\\patata\\pear\\cache\\blablabla
Possible symlink attack
install failed

En fait j’avais² une précédente version mal néttoyée. Faites votre Léon et dégagez tous les fichiers C:\\Users\\Loulou\\patati\\patata\\pear\\cache\\*

Step up 4

Il n’y en a pas vraiment, lancez un petit

pear install PHP_VotreModule

histoire d’être bien sur que tout fonctionne et on devrait être ok.

C’était pourtant pas si compliqué !!!

1. d:\wamp chez moi
2. évidemment

En effet sans, on se retrouve irrémédiablement avec des fichiers dont les X premières lignes sont remplies de « require_once ‘../lib/MaClasse.php' » qui ne s’avère pas toujours facilement maintenable et surtout, surtout très embêtantes à écrire¹

Heureusement PHP langage très souple s’il en est² propose une manière simple et relativement efficace de nous affranchir de toutes ces lignes si fatigantes à rédiger.

On utilisera donc une classe Autoloader que vous pouvez cloner via le repo git disponible à l’adresse https://github.com/jonathankowalski/autoload.git

L’autoload est souvent source de discordes, déjà il faut bien comprendre que quelque soit la méthode, un autoloading sera toujours couteux ou plutôt plus couteux³ que pas d’autoloading.

A partir de là, s’oppose en général deux théories chez les Adam Smith et autres Karl Marx de l’autoloading. D’une part le chargement dit statique et d’autre part un chargement plus dynamique.

Chargement Statique

Il se base sur des conventions fortes. Typiquement c’est que propose le Zend Loader. On admettra que le nom d’une classe indique son emplacement sur le disque.

Par exemple la classe ‘Controllers_Index’ sera dans située dans le fichier Index.php du dossier Controllers.

C’est la méthode que je privilégie car elle me parait plus « sure ». J’entends par là qu’elle force le bon sens histoire d’avoir une arborescence qui soit un minimum compréhensible. Bien sûr rien ne vous empêchera d’appeler un dossier Service et d’y fourrer des controllers mais dans ce cas je crains que personne ne puisse rien pour vous⁴

Si cela fonctionne avec le nom de la classe, cela marche aussi avec les namespaces simplement à la place d’une classe appelée Controllers_Index on aura une class Index dans le namespace Controllers (soit Controllers\\Index) mais le principe reste le même au niveau de l’arborescence.

Limites

Oui ce modèle a certaines limites. D’abord cela nous force à l’équation 1 fichier = 1 classe. Ce n’est pas fondamentalement mauvais mais en fonction du nombre de classes et donc de fichiers ça peut devenir difficilement lisible et on peut imaginer un impact certain sur les performances (à benchmarker tout de même).

Ensuite et surtout du fait de la convention et de l’équation sus-citée, il faut avoir penser à ce système dès le départ du projet. Dans le cas contraire il vous faudra un gros refacto pour remettre tous les fichiers aux normes et étant prouvé que les développeurs sont de gros fainéants autant dire que ce ne sera jamais fait ^^

Chargement dynamique

Pour répondre aux limites du chargement statique, on peut procéder par chargement dynamique. La méthode est simple, on va ici parser nos fichiers en quête de classes afin de déterminer le chemin des fichiers les hébergeant.

Vous comprendrez bien que pour le coup à moins d’avoir un seul fichier contenant toutes vos classes (et encore) cette méthode s’avère extrêmement coûteuse et il est impensable de l’utiliser sans mise en cache. En revanche ici pas ou peu de problème de convention et vous pourrez mettre autant de classes que nécessaire dans vos fichiers.

Du code !

On parle, on parle mais pas une seule ligne de code, ça commence à angoisser. Voici donc la classe qui me sert d’autoloader quand nécessaire voir sur GitHub.

Elle se charge toute seule de s’enregistrer via spl_autoload et vous n’aurez pas à choisir entre chargement statique et dynamique⁵

Le principe est de d’abord voir si vous utiliser le chargement statique.

Dans le cas contraire on parcourt tous les dossiers que vous aurez pris soin d’indiquer à la recherche de vos classes (grâce aux méthodes addDirectory ou addEntireDirectory qui est recursif).

La mise en cache se fait ici via un fichier JSON, c’est pas trop mal mais pas forcément le plus optimal, on peut tout à fait imaginer un gestionnaire qui utilise memcache qui sera encore plus rapide ou MySQL juste pour rigoler. Quoiqu’il en soit il vous suffira d’implémenter l’interface AutoloadCacheManager et d’injecter votre gestionnaire de cache dans l’Autoloader via la méthode setCacheManager.

Fin

Voilà n’hésitez pas à m’indiquer les problèmes que vous pouvez rencontrer si vous aussi utilisez cette classe. Have fun !

1. et ça on n’aime pas :p
2. :p comme le décrit le dénommé Amaury ici
3. relativité toussa toussa
4. et puis dans le fond l’autoload marchera quand même ^^
5. oui vous pouvez faire les deux :p

Mais qu’est-ce qu’un TED me direz-vous ? Il s’agit d’une petite conférence/présentation très courte (environ 15min) concernant à peu près tout et n’importe quoi du moment que vous avez envie d’en parler.

Ça peut être très intéressant et je vous encourage à vous rendre sur le site officiel du TED pour approfondir un peu plus le sujet.

Aujourd’hui c’est mon tour de présenter un petit sujet et j’ai choisi, une fois n’est pas coutume, Javascript et son drôle de modèle objet par prototype.

Javascript le mal aimé

Si j’ai choisi de parler de javascript et de prototype c’est que ce langage est encore trop souvent le vilain petit canard de l’arsenal du développeur web.

Mal connu, souvent codé par dessus la jambe quand on y pense, le javascript bien que rempli de défaut a aussi de nombreux avantages (le fait d’être accepté par de nombreux clients, l’interactivité qu’il permet…).

Il est aussi et surtout au centre du web actuel. Comment imaginer un site un tant soit peu important ou une application web sans ajax ? sans forme d’interactivité ?

Javascript est aussi au centre de technologies d’avenir comme nodejs.

Javascript est objectivement unique

Javascript est un langage tout objet, comme peut l’être le Python. En revanche son modèle objet est assez déroutant pour un développeur Java ou PHP.

En effet ici pas de classes ! En javascript tout est porté par l’objet tant son état que son comportement.

On retrouvera tout de même une ou deux similitudes avec ce que l’on connait dans d’autres langages notamment via l’utilisation d’un constructeur d’objet et du mot clé new

Pourquoi Prototype ?

C’est vrai, après tout pourquoi nous embêter avec cette propriété prototype tandis que l’on peut utiliser facilement notre constructeur d’objet ?

La réponse tient en un mot : performances.

En effet comme dit plus avant, l’état et le comportement est porté par l’objet, pour chacun de vos guitaristes, toutes vos méthodes seront dupliquées.
De quoi bien alourdir vos applications

Avec la propriété prototype au contraire les méthodes seront partagées par chacun de vos objets.

Comment qu’on fait pour ?

Maintenant que nous sommes convaincu mettons en place.

Rien de complexe, on garde notre constructeur d’objet et on déplace tout ce qui est méthode dans sa propriété prototype.

Héritage

Puisque toutes nos méthodes sont dans le prototype de mon objet, afin d’hériter je vais simplement affecter au prototype de mon objet fils un objet généré depuis le prototype de mon objet père.

Il me suffit ensuite de surcharger les méthodes que je souhaite spécialiser.

Je parle d’héritage mais c’est ici un peu abus de langage, il s’agit simplement de copier le prototype qui nous intéresse puis d’écraser les méthodes que l’on souhaite modifier. Cependant le résultat est bien celui que l’on attend avec notamment dans notre exemple Jimmy qui est bien tant une instance de Guitariste que de Rockeur !

Quelques précisions

Pour conclure, j’aimerais simplement préciser deux points. D’abord la chaine de prototype. Il est important de comprendre que javascript, et cela de manière générale, effectue ses recherches en partant du contexte le plus précis possible pour finir au plus général possible. Ainsi dans notre exemple, il va d’abord rechercher la méthode tune dans l’objet lui-même et ne la trouvant pas va regarder dans le prototype de l’objet.

D’autre part, j’aimerais revenir sur la méthode create d’Object que j’utilise pour initialiser le prototype de mon Rockeur. Cette méthode fait partie de javascript 1.9.3 elle n’est donc malheureusement pas implémentée par tous les navigateurs (notamment ie8)
Pas de panique Douglas Crockford en livre une version tout a fait utilisable

Ended

Voilà pour le sujet de mon petit TED, en plus de ceci, vous pourrez trouver mes « slides » ici

Concernant le déroulé du TED en lui-même, le partage s’avère toujours aussi agréable, je regrette simplement de n’avoir le temps de proposer plus de sujets à discuter, mais la vie est histoire de choix…

Fort heureusement PHP nous donne toutes les armes pour nous passer du vilain.

Le principe ouvert/fermé

Qu’est-ce que cela signifie ? Il est le O de SOLID². C’est simple comme son nom l’indique, vos classes se doivent d’être à la fois ouvertes et fermées.
Ouvertes dans le sens ou leurs fonctionnalités doivent pouvoir être étendues via l’adjonction de nouvelles classes héritant de celle-ci³.

Fermées car le code source de vos classes devrait être figé, fermé à la modification.

Prenons une fabrique de voiture comme celle-ci :

Bon déjà nous avons éviter le piège d’avoir une seule classe Voiture dans laquelle on aurait un switch comme celui-ci dans chaque méthode getConsommation, getVitesseMax etc.

Ah, une note en passant, j’ai mis des break après mes return non pas pour rester dans l’univers automobile mais sinon mon IDE gère mal l’indentation⁴.

Bref revenons à nos moutons, nous avons un seul switch dans notre fabrique ce qui est un moindre mal, cependant vous comprendrez aisément que cette classe n’est pas fermé. Si demain, nous décidons de créer des monospaces, il faudra venir modifier notre fabrique afin de rajouter un case.

Réflexion et Reflection

Connaissez-vous Reflection ? Cette API venue avec PHP5 nous permet d’introspecter notre code. Elle va nous permettre de modifier notre fabrique.

Que faisons-nous ici ? D’abord nous récupérons le nom de notre classe depuis le modèle passé en paramètre⁵.

Ensuite nous allons instancier une ReflectionClass avec ce nom. Si PHP ne trouve pas la classe demandée il va lancer une ReflectionException que nous allons attraper pour lancer notre propre exception ModeleInconnuException.

Conclusion

Voilà notre fabrique désormais fermée. Si vous décidez demain d’ajouter les modèles coupeSport et cabriolet, il suffira d’ajouter les classes idoines et vous pourrez les fabriquer sans avoir à toucher à votre fabrique.

On pourrait encore un peu plus utiliser PHP et ses méthodes magiques pour créer une API automatique du type createCitadine ou create4x4 mais dans un premier temps c’est déjà pas mal, on verra ça dans un autre article.

Nous avons vaincu le switch !

See you

1. POO
2. que nous verrons plus en detail dans un article prochain
3. ou pas
4. quand je vous disais que le switch est plein de défaut
5. Nous avons donc tout de même une contrainte au niveau du nom de nos classes mais c’est pas plus mal

Nous nous intéresserons ici à l’une des plus intéressantes à mon goût l’interface Storage et ses implémentations localStorage et sessionStorage. Pour cela on utilisera le plugin jquery storage écrit par votre serviteur.

Les implémentations de Storage vont vous permettre de pouvoir enregistrer des données directement sur la machine de l’utilisateur de manière plus sécurisée et avec un volume plus important que ces bons vieux cookies².

Afin de manipuler tout ça on utilisera un petit plugin jquery que l’on va essayer de découvrir ici.

Pourquoi un plugin ?

Un plugin va nous permettre de manipuler le storage avec une API unifiée, en masquant aussi certaines opérations un peu fastidieuses telles que la sérialisation de certaines données. On va aussi bénéficier d’un fallback vers les cookies si le navigateur de votre utilisateur s’avère obsolète³.

Et puis surtout vous pourrez venir râler sur quelqu’un si ça ne marche pas :p

Installation

Afin de récupérer le plugin jquery.storage clonez le repo git disponible à l’adresse :

https://github.com/jonathankowalski/jquery.Storage.git

Si vous n’avez pas Git vous pouvez aussi télécharger directement le zip jquery.storage et le désarchiver où il vous semblera bon.

Ensuite c’est de l’installation de plugin jquery classique :

<script type="text/javascript" src="jquery.min.js"></script>
<script type="text/javascript" src="/dir/to/plugins/jquery.storage.min.js"></script>

l’API

On gardera les données sous la forme de paires clé/valeur. On pourra agir sur trois contextes que vous pourrez préciser par « local », « session » et « cookie ». Assez classiquement l’API expose tous les aspects du CRUD :

Créer des données et les mettre à jour

On utilisera pour cela les fonctions set :

$.storage.set(key, value, context);
$.storage.setLocal(key, value);
$.storage.setSession(key, value);
$.storage.setCookie(key, value);

//examples
$.storage.setLocal("drink","coffee");
$.storage.setLocal("json",{"mode":"complex"}); //fonctionne aussi

Comme vous vous en doutez les méthodes setLocal, setSession, setCookie ne sont que des raccourcis vers la méthode set. Si ces méthodes vous permettent de créer des entrées dans les différents Storage elles vous permettront aussi de mettre à jour ces données.

Récupérer des données

On utilisera pour cela les fonctions get :

$.storage.get(key, default, context);
$.storage.getFromLocal(key, default);
$.storage.getFromSession(key, default);
$.storage.getFromCookie(key, default);

//examples
$.storage.getFromLocal('drink'); //Renverra la donnée identifiée par drink ou null si elle n'existe pas
$.storage.getFromLocal('drink', 'coffee'); //Renverra la donnée identifiée par drink ou coffee si elle n'existe pas

Plusieurs choses sont à noter ici, d’abord si vous fournissez une valeur par défaut et que la donnée n’existe pas, elle sera créée.

D’autre part, vous pouvez utiliser get sans context, dans ce cas, jquery.storage va explorer les différents Storage⁴ et vous renvoyer la première valeur qu’il trouve.

Supprimer des données

On peut d’une part effacer une donnée :

A noter que vous pouvez aussi appeler remove sans context, dans ce cas jquery.storage supprimera la donnée dans tous les Storage.

Vous pouvez aussi flusher toutes les données d’un context en particulier ou de tous les contexts à la fois.

Plus encore

Si vous avez des questions n’hésitez pas, sachez aussi que vous pouvez très facilement ajouter des « Storages »⁵ il suffit que votre objet respecte l’interface Storage et il faut ensuite l’ajouter au contextDefines, comme je l’ai fait pour les cookies.

Have fun !

1. parait-il
2. quelques ko pour les cookies contre plusieurs Mo pour localStorage
3. suivez mon regard
4. dans l’ordre Session, Local et Cookie
5. pour du cache par exemple ou que sais-je encore

3 applications cela peut sembler peu. N’y voyez pas là une marque criante de fainéantise, cependant je ne souhaitais pas virer dans la course à l’armement et vous présenter les 69 web apps qui tuent que j’aurais re-pompées sur tel ou tel autre bon gros site à destination des web-quelquechose. Non, il s’agit là vraiment³ de mon expérience personnelle.

Enfin trêve de blabla, trêve de blabla comme dirait Dany Boon⁴

Pixlr

En premier lieu j’évoquerais Pixlr.

Quand on travaille sur le web, on a sans cesse besoin de retoucher des images, ne serait-ce que pour les recadrer ou corriger des petits défauts. Comme nous ne sommes pas tous multimilliardaires⁵ que Paint s’avère tout de même assez vite limité et que Gimp est bien trop compliqué⁶, Pixlr s’est offert une place de choix dans mes onglets épinglés. Bien sur ne vous attendez pas à trouver là l’équivalent exact du logiciel d’Adobe⁷ mais bon, on retrouve une gestion des calques, quelques filtres intéressant et même des lignes de forces lors des cadrages-débordements, redimensionnements.

Ça s’ouvre vite et ça fait ce qu’on attend de lui. http://pixlr.com

Toggl

La retouche d’image n’est clairement pas mon métier et il est clair que bien qu’usité Pixlr n’est pas l’adresse que je fréquente le plus assidument.

Toggl l’est un peu plus.
Notre temps est précieux. De cette affirmation en découle une autre, la productivité est importante. Puisque l’on travaille⁸ il est important de pouvoir mesurer le temps passé sur notre travail et ainsi profiler notre efficacité. Toggl est parfait pour ça. Enregistrez-vous avec votre compte Google et voilà. Vous avez accès à un outil simple vous permettant de tracker les minutes heures passées sur chacune de vos tâches, en retirer des rapports et des statistiques. Toggl est le rêve incarné des managers et des personnes souhaitant maitriser le temps.⁹

Et en plus, Toggl fournit des applications desktop et mobiles vous permettant une maîtrise et une visibilité en toutes circonstances. A noter que certaines fonctionnalités sont payantes mais il est fort probable que la version gratuite vous soit déjà agréable. http://www.toggl.com

WorkFlowy

A Londres et à New-York on dit « Last but not least ».

WorkFlowy est sans doute la quintessence des applications web. Saint-Exupéry disait que la perfection était atteinte non pas quand il n’y avait plus rien à ajouter mais quand il n’y avait plus rien à enlever. WorkFlowy n’est sans doute pas parfait mais il n’y a pas grand chose à en enlever.
L’organisation est la sainte mère du professionnel et WorkFlowy va vous permettre de rester organisé de la manière la plus simple qui soit. J’avoue être quelque peu dithyrambique mais quand une application est à la fois aussi simple et utile il est important de le souligner.

WorkFlowy va donc vous permettre de créer des listes afin de vous organiser¹⁰. Deux défauts quand même pour finir, 1) l’application ne fonctionne pas sur mon Windows Phone, mais bon qui dit WP dit aussi Internet Explorer donc disons que l’on peut comprendre… et 2) quand vous utiliserez WorkFlowy vous ne verrez plus le monde que sous forme de liste.¹¹  http://workflowy.com

Fertig

Voilà 3 applications utiles, gratuites et qui me permettent de gagner un peu de temps ou de sommeil en fonction. Comme dit en introduction il s’agit là d’un retour personnel, subjectif et partial, n’hésitez pas à me faire part de vos expériences et d’applications encore meilleures que celles présentées ici.

Vive le partage.

1. avec WordPress
2. et j’exagère à peine
3. et comme souvent
4. oui j’ai aussi de l’humour
5. pour rappel Toshop vaut la bagatelle de 955€
6. don’t feed the troll
7. qui a clairement encore quelques belles années devant lui
8. et qu’on aime ça sinon changez :p
9. rien que ça !
10. puisque je vous dis que c’est simple !
11. cependant on s’y fait très bien :p

Toujours est-il que pour cette reprise je souhaitais répondre à mon ami H. M. qui se renseignait récemment sur la nature et l’emploi des références en PHP.

Qu’est-ce qu’une référence ?

Une analogie commune qui s’avère aussi être une erreur² et de les comparer aux pointeurs C. En réalité ce sont deux choses très différentes. Les références en PHP sont des alias vers un même contenu.

Ainsi $beta et $alpha pointent sur le même contenu qui est en l’occurrence 1337. Aucune des deux variables n’a de précédence par rapport à l’autre elles référencent simplement le même contenu. Le manuel php évoque une similitude avec les fichiers sous Unix que je trouve assez parlante.

$a = 5; $b = $a; copie de variable

Ici dans le cas d’une copie de variables on voit que $a et $b ont un contenu similaire mais n’ont d’autre lien que celui fait par notre oeil humain, une modification de $a n’affectera en rien $b (et vice et versa).

$a = 5; $b =& $a; reference.

Ici on comprend tout de suite que $a et $b ont le même contenu, ce sont simplement deux noms différents pour identifier le même contenu. Ainsi modifier $b modifiera aussi $a (et vice et versa).

En revanche, supprimer $b n’affectera pas $a, on ne fait que casser le lien entre $b et le contenu 5 mais en aucun cas celui de $a. C’est là ou la distinction avec les pointeurs C est la plus parlante car en C en libérant $b, $a n’existerait plus.

Encore un peu plus de références

On a vu comment assigner une référence, mais il existe d’autres moyens de manipuler celles-ci.

Passage par référence

On peut avoir envie qu’une fonction modifie directement une variable sans passer par le retour de cette fonction. Dans ce cas on peut indiquer à une fonction que notre variable est passée par référence.

Un exemple classique est une fonction incrementer

Cette manière nous permet de passer outre les portées et de modifier une variable directement dans une fonction un peu comme si elle était globale³.

Retourner une référence

En plus de passer des arguments par référence, vous pouvez aussi faire en sorte qu’une fonction retourne une référence.

On remarquera ici que vous devez utiliser le & à la déclaration de votre fonction/méthode et lors de l’assignation.

Faut-il utiliser les références ?

Bonne question. Pour moi elle revient à poser sa consœur « Doit-on nommer de plusieurs manières différentes la même chose ? ». En particulier concernant l’assignation par référence et le fait de retourner des références⁴, la réponse est la même, clairement non.
Le passage par référence peut à la rigueur se comprendre incrementer($a); étant plus compréhensible que $a = incrementer($a);⁵ mais dans des cas plus « complexes » il serait encore préférable d’avoir un objet implémentant une méthode incrementer et donc de passer par $this qui s’avère déjà être une référence $a->incrementer();

1. très très heureux
2. ou de manière plus tatillonne une inexactitude
3. d’ailleurs il est à noter que le mot-clé global crée en fait une référence
4. qui sont deux concepts assez similaires
5. dans ce cas la fonction va-t-elle incrémenter de $a ou de 1 ?