Fulgurio

Make a better web

  • Là où Facebook a réussi

    par fulgurio

    fulgurio
    Aller à son site
    Voir ses articles

    Non, je ne parle pas de l’entrée en bourse qui est plutôt considérée comme un échec de la part des boursicoteurs, mais plutôt du standard que Facebook a réussi à mettre en place, encore moins du « poke » qui a mystérieusement disparu de la circulation.

    Connaissez vous OpenID ? Non ? Pas étonnant. Initié en 2007, ce service devait standardiser les inscriptions aux sites. Exit les formulaires d’inscription où l’on saisit toujours la même chose, il suffisait de créer un compte OpenID, et voilà que vous devriez pouvoir vous connecter automatiquement sur les autres sites, sans à avoir à vous inscrire et authentifier à chaque fois.

    Oui, mais non, car il faut bien sûr que les sites proposent l’authentification OpenID, et c’est de là que viendrait en partie le problème : peu de sites ont adopté ce standard (je parle bien de standard, OpenID est une association à but non lucratif), donc peu d’internautes ont entendu parler de ce service. Ajoutez à cela une autorisation quelque peu farfelue (il faut autoriser le site en question à utiliser OpenID), et voilà comment une bonne idée ne fonctionne pas.

    Aujourd’hui, un service d’authentification universelle s’est imposé comme LE standard, à savoir Facebook. Sur tous les sites récents, le formulaire d’inscription propose de se connecter avec son compte Facebook.

    Voici comment rendre internet dépendant du fameux réseau social …

  • B.A.-BA d’un développeur : le fichier de configuration

    par fulgurio

    fulgurio
    Aller à son site
    Voir ses articles

    Cet article peut paraître un peu stupide, je vous entends déjà « mais évidemment qu’il faut faire ça ». Oui, mais j’ai déjà été confronté plusieurs fois à ce genre d’erreur, et je pense qu’il est intéressant d’expliquer en quoi c’est une erreur.

    Dans la majorité de vos développements, vous avez à stocker des informations qui varient en fonction de votre environnement de travail. Par exemple, les accès à la base de données en environnement de production seront doivent être différents de l’environnement de développement.
    Ces informations sont stockées dans le code source, et doivent être ABSOLUMENT regroupées dans un seul et même fichier.

    Pourquoi ? Imaginons que chaque développeur mette dans son code ses propres paramètres. Cela fonctionne correctement sur son environnement de développement, mais pas sur les autres environnements. Il faut donc chercher les paramètres dans le code et les modifier afin de le faire fonctionner sur son environnement. Bref, on peut y passer du temps.

    Pire, lors du déploiement du site internet, vous ne serez sans doute pas la personne qui déploiera le site. La tierce personne devra donc être avertie de l’emplacement  de chaque paramètre. Ok, le déploiement n’a lieu qu’une seule fois, mais quid des évolutions ? On pourrait être amené à livrer une évolution, et lors du déploiement, impossible de rendre le site hors ligne pendant le paramétrage des nouveaux fichiers.

    La majorité des outils (si ce n’est pas tous) utilise un fichier de configuration où l’on retrouve tous ces paramètres. Il suffit donc de modifier un seul et unique fichier pour que le site soit fonctionnel dans un nouvel environnement, par exemplie config.php.

    Donc utilisez un unique fichier dans lequel vous mettrez tous vos paramètres ! Pensez aux autres développeurs qui utiliseront vote core ! 😉

    Pour aller plus loin, l’idéal est d’avoir un fichier de paramètre pour la production et un second fichier pour le développement, et d’avoir un script qui charge le bon fichier en fonction de l’environnement. Comme ça, pas de sueurs froides lors de l’écrasement de la totalité des fichiers. Ce sera le sujet du prochain article.

  • Livre pour développeurs PHP

    par fulgurio

    fulgurio
    Aller à son site
    Voir ses articles

    Aujourd’hui, je vais parler d’un livre que je conseille fortement aux développeurs PHP qui souhaitent améliorer leur façon de travailler. Certaines choses ne devraient pas (je l’espère) vous être inconnues, mais un simple rappel ne fait pas de mal.
    Pour information, c’est en lisant que m’est venue l’idée de réaliser un wiki pour les webmasters, car le livre fait référence à des outils qui ont évolué, et d’autres sont apparus. D’où l’intérêt d’avoir un document à jour, sous la forme d’un wiki.

    Ce livre, aux éditions PackT, s’intitule Expert PHP5 Tools, écrit par Dirk Merkel. Comme le nom l’indique, Dirk nous décrit les outils à utiliser lors des développements PHP.

    Je ne vais pas faire un copier / coller du titre des chapitres, mais de façon générale, ce sont des outils que tout développeur se doit d’utiliser aujourd’hui. J’ai encore du mal à comprendre comment certains développeurs peuvent travailler en langage objet avec un notepad, ou bien sans outils de versioning comme SVN ou GIT.

    Ici, pas de conseil de développement (en fait, un peu, en parlant de PHP_CodeSniffer), juste des outils, comme eclipse et phpDocumentor, avec leur qualité, et leur paramétrage.

    C’est un ouvrage que je conseille à tous, cela se lit vite. Pour les chefs de projet, c’est le genre de cadeau à offrir à vos développeurs 😉

    Note : ce livre est en anglais, mais en anglais technique, donc facilement compréhensible.

  • Nouvelle interface graphique

    par fulgurio

    fulgurio
    Aller à son site
    Voir ses articles

    Nouveau site, nouvelle charte graphique. A partir d’éléments fournis, l’agence Shalama a effectué une refonte en profondeur du thème, tout en conservant les couleurs de l’entreprise. La technologie HTML5, bien qu’encore en version « draft » par le W3C, amène ce petit « + ». Suivront bientôt de nouvelles pages.

    J’en profite aussi pour vous exposer le futur de cette rubrique. Il existe sur la toile de nombreux blogs techniques, partageant leurs découvertes. Certains sont excellents, certains sont « creux », voire pire, un vulgaire copier / coller. Non, ici, notre volonté est d’écrire un article par semaine, orienté technique / conseil, afin par la suite d’agrémenter une base de connaissance autour d’un wiki. Car à notre grand étonnement, il n’existe pas de wikipedia pour les webmasters.

    Voici notre point de vue : dans un blog, les articles sont écrits un jour J, à J+1, on retrouve un nouvel article (tout dépend de la fréquence de publication). Les moteurs de recherche nous permettent d’accéder à ces articles, sauf que les résultats ne sont pas forcément les plus adéquats : on peut se retrouver avec un article datant de plus d’un an, et une année, c’est énorme dans les technologies internet.
    Un wiki (de référence) par contre, offre un unique point d’entrée, avec des articles mis à jour par les internautes / webmasters.

    A l’avenir, au lieu de passer par votre moteur de recherche préféré aux 4 couleurs, vous irez d’abord sur ce wiki afin d’y trouver réponse. Si la réponse est absente, vous pourriez, pourquoi pas, l’ajouter par la suite.

    Telle est notre volonté. Pas d’appropriation du contenu, notre devise nous semble assez explicite : « Make a better web » (« Faire un internet meilleur »). Faisons le tous ensemble !