Ce blog — désormais archivé — est en lecture seule. Pour continuer à lire mes tribulations, rendez-vous sur le blog d'Akei, ma société.

Prendre un Café

L'espace d'expression de Nicolas Perriault

Aller au contenu | Aller au menu | Aller à la recherche

Keyword - bestpractices

Fil des billets

samedi 12 janvier 2008

Symfony, une redirection 302 et une exception sont dans un bateau

Par NiKo le samedi 12 janvier 2008, 20:56 - Dev - 10 commentaires

Ah la la. C'est assez rare pour être souligné, mais je viens de me battre avec Symfony pendant près de deux heures avec un problème assez déroutant de prime abord : lorsque dans une action vous faites quelque chose d'aussi anodin que ceci :

 php
  public function executeBar()
  {
    try
    {
      // Some stuff here, if successful redirect user to somewhere else
      $this->setFlash('notice', 'Action was successful');
      $this->redirect('@whatever_route');
    }
    catch (Exception $e)
    {
       $this->getRequest()->setError('errors', 'Something has failed somewhere, sorry dude');
       $this->logMessage('Big boo boo occured: '.$e->getMessage(), 'err');
       return sfView::SUCCESS;
    }
  }

Et bien dans ce cas là, la redirection s'opère MAIS l'ensemble du rendu sera tout de même produit et envoyé au navigateur [1] - ce qui peut s'avérer très couteux sur un site internet au final [2]. La raison en est très simple, la méthode redirect() de la classe sfActions met fin à l'execution par ce moyen que l'on peut qualifier de hardi :

 php
  public function redirect($url, $statusCode = 302)
  {
    $url = $this->getController()->genUrl($url, true);
    if (sfConfig::get('sf_logging_enabled'))
    {
      $this->getContext()->getLogger()->info('{sfAction} redirect to "'.$url.'"');
    }
    $this->getController()->redirect($url, 0, $statusCode);
    throw new sfStopException();
  }

Oui, vous avez bien lu, on interrompt le script en levant une exception, ici de type sfStopException. Le problème, c'est que dans mon exemple précédent, la méthode redirect() est appellée dans un bloc try { } catch { }, et donc l'exception levée est interceptée et l'action n'est au final pas stoppée. Vicieux, hein ?

Pour régler le problème, on peut par exemple toujours effectuer ses appels à la méthode redirect() en dehors d'un block try { } catch { } [3], ou encore tester le type de l'exception levée. Dans notre exemple, cette dernière solution ressemblerait à ça :

 php
  public function executeFoo()
  {
    try
    {
      // Some stuff here, if successful redirect user to somewhere else
      /// ...
      $this->setFlash('notice', 'Action was successful');
      $this->redirect('@whatever_route');
    }
    catch (sfStopException $e)
    {
      return sfView::HEADER_ONLY;
    }
    catch (Exception $e)
    {
      $this->getRequest()->setError('errors', 'Something has failed somewhere, sorry dude');
      $this->logMessage('Big boo boo occured: '.$e->getMessage(), 'err');
      return sfView::SUCCESS;
    }
  }

C'est pas super sexy, mais ça fonctionne, et ça a le mérite de m'inspirer deux morales à cette histoire :

  1. tester le type des exceptions que l'on catche, c'est bien
  2. lever une exception pour arrêter un script, c'est super cracra et mériterait éventuellement d'être patché ;)

Edit: Je m'exprime mal, c'est pas super cracra, c'est juste que ça introduit une petite complexité supplémentaire. Mais l'utilité de la chose est bien entendu totalement avérée si on a besoin d'effectuer des opérations particulières avant la fin du script ( ce qui est rarement le cas, enfin chez moi).

Notes

[1] Avec tout ce que ça comporte de requête SQL et de templates calculés pour rien

[2] Et oui bien sûr, faire un redirect() dans un bloc try catch c'est pas forcément le meilleur endroit, mais c'est teeeellement pratique :p

[3] Qui sera donc exécuté de toute façon si aucune exception n'est levée.

lundi 5 novembre 2007

A new Django freelance in town

Par NiKo le lundi 5 novembre 2007, 21:33 - Divers - 2 commentaires

Il est suffisamment rare de rencontrer un passionné du web comme David Larlet pour se priver du luxe de lui faire un peu de pub quand il décide de se mettre à son compte :)

Dont acte, si vous désirez confier la conception et la réalisation de votre projet web à un professionnel amoureux des standards et bonnes pratiques du web et prompt à s'impliquer à vos côtés dans toutes les phases de l'accompagnement de votre projet, je vous engage à prendre contact avec lui de ce pas.

jeudi 1 novembre 2007

Utiliser Symfony pour vos projets

Par NiKo le jeudi 1 novembre 2007, 10:26 - Dev - 29 commentaires

Suite à l'émergence des frameworks web, beaucoup d'équipes de développement ont décidé de leur utilisation sans toujours bien réaliser les tenants et aboutissants liés la démarche, croyant souvent avoir enfin trouvé une méthode miracle pour produire vite et bien. Il peut en résulter de sévères déconvenues, quel que soit le framework, le langage ou la plateforme retenus.

Concernant Symfony, il en va de même ; et si on peut bien entendu trouver énormément d'avantages à son utilisation sur un projet, il faut également bien avoir conscience des contraintes qu'un développement sur sa base implique, sous peine de se retrouver dans le mur assez rapidement.

Symfony n'est pas un CMS

Il est immédiatement tentant de retenir Symfony pour tout type de projet tellement il est agréable de développer sur sa base. Cependant, pourquoi systématiquement réinventer une roue qui tourne peut-être déjà fort bien ailleurs ? L'idée ici est de s'interroger sur la réelle nécessité de recourir à un développement spécifique ; en effet, même si coder en Symfony est très encadré, il n'empêche que la logique métier est entièrement à définir par l'équipe de développement [1]. Plus particulièrement concernant les problématique de gestion de contenus, le besoin métier sur le projet est-il suffisamment conséquent, ou un CMS comme Drupal, SPIP, ezPublish ou Joomla couvre t-il nativement l'ensemble du périmètre fonctionnel cible ? [2]

Un développement spécifique introduira le plus souvent beaucoup plus d'exigences, de compétences et de compléxité qu'une intégration basée sur un outil de gestion de contenus autonome existant (et digne de ce nom). L'idée est bel et bien de renoncer à se faire plaisir à tout prix pour se situer au plus près de la réalité du besoin.

Bien entendu, je me fais aussi ici l'avocat du diable. Pour avoir joué avec les principaux CMS PHP open source du marché et connaissant la propension naturelle d'un client à enrichir au gré de l'avancement projet le périmètre fonctionnel souhaité [3], je préfère allègrement à titre personnel me baser sur un framework comme Symfony afin de rester agile et parer à toute éventualité. Mais je sais aussi quelles sont mes compétences réelles sur le sujet, et dès qu'une équipe dont je ne cerne pas le niveau entre en ligne de compte, généralement les problèmes commencent. Ça tombe bien, c'est justement l'objet du prochain chapitre ;)

Symfony est exigeant

Non, Symfony ne transformera pas magiquement un mauvais développeur en bon développeur... même s'il peut y contribuer à terme ;)

Plus sérieusement, le but réel de l'utilisation d'un framework est bel est bien de vous rendre plus efficace et productif, certainement pas de vous compliquer la vie ou de vous faire perdre du temps.

Il faut bien prendre conscience que le temps de montée en compétence sur l'utilisation du framework - déjà naturellement exigeante - requière également pour certains une montée en compétence en programmation tout court. Et cette dernière, si elle peut se faire sur un projet, peut également allègrement le plomber. Un développeur débutant bidouilleur PHP mettra fatalement plus de temps qu'un codeur expérimenté à appréhender l'ensemble des possibilités introduites par PHP5, la programmation orientée objet, les motifs de conception, mais aussi le respect des bonnes pratiques notamment liées au travail collaboratif ou que sais-je encore.

Le risque à court terme est de voir le code du projet grevé dans sa qualité et sa maintenabilité. À moins bien entendu de prendre en compte en amont cette charge inhérente à la formation, mais on connait tous la réalité professionnelle et commerciale du milieu qui est le notre ;)

Symfony ne vous dispense pas d'organiser votre projet

Oui, Symfony fait la part belle aux conventions et prémâche énormément le travail redondant à tout projet de type web. La vie des (bons) développeurs est grandement facilitée, et on peut vraiment gagner rapidement beaucoup de temps. Mais une grave erreur serait de sous-estimer la charge liée à l'organisation et la gestion de la vie du projet.

Par exemple, ce n'est pas en mettant plus de développeurs sur un projet Symfony (ou autre d'ailleurs) que celui-ci sera développé plus vite. Au contraire, même ; tout codeur avec un tant soit peu d'expérience professionnelle a déjà rencontré ce type de cas de figure : on vend un projet de 100 jours de développement, on se fixe un retroplanning ambitieux avec une mise en ligne à 20 jours ouvrés, et on staffe donc arithmétiquement cinq développeurs à plein temps en pensant que le résultat sera totalement équivalent au travail qu'aurait fourni un unique développeur en 100 jours de développement pour concevoir l'intégralité du code de l'application résultante.

Bien entendu, c'est illusoire et généralement, le projet se termine sur des dépassements conséquents et le mécontentement du client [4]. Et pour cause, la déperdition d'énergie utilisée à la communication sur le projet est fonction du nombre d'acteurs présents sur ce dernier. Et on peut staffer trois chefs de projet à plein temps pour canaliser tout ça, c'est d'une part économiquement peu viable et d'autre part totalement inefficace, ces derniers devant perdre également beaucoup de temps à se synchroniser entre eux, puis avec les membres de l'équipe.

Moralité

Non, Symfony n'est pas le remède miracle aux lacunes organisationnelles des structures en charge de la réalisation d'un projet, mais bien un outil exigeant qu'il faut savoir appréhender de la bonne façon en prenant en compte le plus en amont possible ces problématiques. Le gain réel et indiscutable d'efficacité apporté par l'utilisation d'un framework comme Symfony est à ce prix ;)

Notes

[1] Je n'ose pas évoquer ici la notion d'architecte logiciel connaissant la réalité moyenne du monde PHP.

[2] Pour nuancer ce propos, de plus en plus de plugins Symfony tendent à apparaitre pour couvrir ce type de besoins fonctionnels.

[3] Le premier qui me parle du sacrosaint cahier des charges contractuel, je le mords.

[4] Sans parler de la charge de stress portée sur l'équipe, qui du coup va saloper le boulot pour livrer au plus vite.

mercredi 3 octobre 2007

Dégradabilité javascript et Ajax dans Symfony avec jQuery

Par NiKo le mercredi 3 octobre 2007, 11:31 - Dev - 16 commentaires

Pour un projet, je suis en train d'utiliser la librairie javascript jQuery dans Symfony, en lieu et place du couple prototype et scripaculous dont je vous avait déjà parlé.

L'idée est ici de ne pas avoir à utiliser les helpers fournis par Symfony (qui mettent en oeuvre exclusivement Scriptaculous) et ainsi d'éviter d'utiliser les deux librairies simultanément sur le projet, mais aussi de décoreller le code javascript des templates et de favoriser une meilleure dégradabilité de ce dernier.

Par exemple, au lieu d'utiliser la fonction link_to_remote() dans notre template, on peut tout à fait imaginer d'employer un bon vieux link_to() des familles et de lui appliquer une classe css qu'on va pouvoir cibler depuis jQuery afin d'effectuer un appel AJAX pointant vers l'url présente dans l'attribut href du lien. Avec un exemple, c'est un peu plus clair :

 php
<?php echo link_to('Mon lien', '@maroute?monparam=mavaleur', array('class' => 'ajax_link')) ?>

Dans un fichier javascript (jQuery doit bien entendu être chargé) :

 javascript
$(document).ready(function() {
  $('a.ajax_link').click(function()
    {
      $.ajax(
        {
          type: 'post',
          url: $(this).attr('href'),
          success: function(msg)
          {
            alert("Résultat: " + msg);
          }
        });
      return false;
    }
  );
});

Avantage supplémentaire, vous continuez à bénéficier du système de routing Symfony (pas d'urls en dur dans les fichiers javascripts externalisés.)

Là où Symfony va également nous aider, c'est au travers de sa gestion native de la décoration d'une vue en fonction du type d'appel HTTP : le framework va detecter si l'action a été appelée ou non depuis une requête XmlHttpRequest et, si c'est le cas, décorer la vue avec le layout global de l'application et donc présenter à vos utilisateur le résultat escompté, qu'ils aient activé javascript ou non pour surfer sur votre site.

Si vous désirez mettre à jour un élément de l'arbre DOM avec le contenu reçu d'une requête Ajax, voici une autre petite astuce ; on va utiliser une ancre dans l'url et s'en servir comme argument décrivant l'id DOM qu'on veut mettre à jour :

 php
<?php echo link_to('Mon lien', '@maroute?monparam=mavaleur#mon_div', array('class' => 'ajax_link')) ?>
<div id="mon_div" style="display:none"></div>

Et en javascript :

 javascript
$(document).ready(function() {
  $('a.ajax_link').click(function()
    {
      var href = $(this).attr('href');
      var target = href.substring(href.lastIndexOf('#'), href.length);
      $.ajax(
        {
          type: 'post',
          url: href,
          success: function(msg)
          {
            if ($(target))
            {
              $(target).html(msg).show('slow');
            }
          }
        }
      );
      return false;
    }
  );
});

Note : on aurait pu aussi détourner l'attribut target à cette fin mais ce dernier n'est pas valide en XHTML strict.

Bien entendu, ceci n'est qu'un microscopique aperçu de l'étendu des possibilités de jQuery et de son intégration possible avec Symfony (ou d'autre frameworks et langages, bien entendu.)

dimanche 19 août 2007

Présentation de Flex

Par NiKo le dimanche 19 août 2007, 13:04 - Dev - 8 commentaires - un rétrolien

Pour les besoins du boulot, j'ai du me mettre à Flex, le framework d'Adobe orienté RIA en Flash.

Je pensais que mon passé de flasheur m'aiderait à monter rapidement en compétence sur cette techno, ben non : c'est tout à fait autre chose que ce que je connaissais de l'IDE traditionnel, dont je m'étais arrêté à la version 8. Avec Flex on a affaire à un framework complet de génération d'interfaces riches basées sur l'emploi de composants décrits et paramétrés en XML et de la dernière mouture du langage ActionScript en version 3. Quelques exemples d'applications réalisées avec Flex sont disponibles, et pour certaines, ça en jette carrément.

Le langage MXML

La description des interfaces s'opère au moyen du langage MXML[1], basé sur XML un peu comme ce que proposent XUL ou XAML ou même XHTML (qui reste une implémentation particulière et standardisée d'XML). Deux types principaux de composants sont disponibles : les conteneurs (boîtes, panneaux, fenêtres, etc.) et les éléments de contrôle (champs texte, listes, datagrids, tree, etc.)

Le nombre de conteneurs et de contrôles est impressionnant, on se prend à rêver de la même richesse en HTML [2]. La plupart des composants sont visibles sur l'explorateur de composants Flex, sur le site d'Adobe. Et le meilleur reste sans doute à venir quand on voit le catalogue de composants supplémentaires open source comme ceux du projet FlexLib...

Le format généré après compilation d'un ensemble de fichiers MXML constituant une application Flex est le SWF, le format natif d'Adobe Flash, lisible par tout bon Flash Player 9 qui se respecte, implanté sur plus de 80% du parc machines desktop mondial d'après les dernières statistiques disponibles sur le site d'Adobe.

Voila un exemple de code MXML décrivant l'interface d'une application simpliste :

 xml
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
   <mx:Panel title="Dire bonjour" x="10" y="10" layout="absolute" width="303">
      <mx:TextInput id="firstname" x="10" y="10"/>
      <mx:Button label="Dire bonjour" click="result.text='Bonjour, '+firstname.text" x="178" y="10"/>
      <mx:Label id="result" x="10" y="40" width="265"/>
   </mx:Panel>
</mx:Application>

Le code est assez parlant, mais voici quelques éléments significatifs :

  • Le conteneur principal de l'application déclare l'espace de noms mx, ce qui nous permettra d'utiliser les composants natifs de Flex
  • L'application déclare un conteneur sous la forme d'un Panel contenant trois contrôles :
    • un InputText, champs de saisie textuelle
    • un Button, un bouton d'action
    • un Label, un champs de texte potentiellement dynamique
  • Chaque élément peut se voir nanti d'un attribut id qui doit être unique si renseigné ; il permet de référencer facilement un élément de l'arbre DOM
  • La gestion des évènements peut se faire directement en MXML : ici, quand on clique sur le bouton, le contenu texte du label est modifié en fonction de la valeur textuelle du champs de saisie.

Style et mise en forme

Dans l'exemple précédent, on voit que les styles sont appliqués sous forme d'attributs XML. C'est une solution pratique à court terme mais qui peut rapidement s'avérer problématique à maintenir dès que votre application grossit. Aussi, pour séparer la couche de présentation de la description des contenus, tout comme en HTML, Flex permet l'utilisation de feuilles de styles CSS embarquées ou externalisées. Beaucoup de propriétés CSS ont du être créées ou adaptées aux spécificités du balisage MXML et des composants proposés, mais le résultat est une grande souplesse d'utilisation et une large palette de mise en forme disponible. Pour preuve, un petit tour du côté de l'explorateur de styles Flex s'impose.

Le langage ActionScript 3

ActionScript 3 est l'évolution logique des précédentes versions, étendant le périmètre fonctionnel et accentuant son caractère professionnel, notamment dans l'implémentation objet, les types natifs et l'organisation en packages des différents objets de programmation.

Composants personnalisés

Une des grandes forces de Flex à mes yeux est la simplicité avec laquelle on peut créer ses propres composants en héritant de composants basiques préexistants et de les manipuler via son propre espace de noms. Par exemple, la création d'un composant dérivé d'un formulaire présentant un champs de login/mot de passe donne à peu près ceci :

 xml
<?xml version="1.0" encoding="utf-8"?>
<mx:Form xmlns:mx="http://www.adobe.com/2006/mxml" width="280" height="105">
   <mx:FormItem label="Login">
      <mx:TextInput id="username"/>
   </mx:FormItem>
   <mx:FormItem label="Mot de passe">
      <mx:TextInput id="password" displayAsPassword="true"/>
   </mx:FormItem>
   <mx:FormItem>
      <mx:Button label="Connexion"/>
   </mx:FormItem>
</mx:Form>

Si on nomme notre fichier de composant LoginForm.mxml et qu'on le stocke dans le répertoire ./components de notre projet Flex, on va pouvoir l'utiliser de la façon suivante dans une application :

 xml
<?xml version="1.0" encoding="utf-8"?>
<mx:Application 
   xmlns:mx="http://www.adobe.com/2006/mxml" 
   xmlns:niko="components.*"
   layout="absolute">
   <mx:Panel title="Connexion">
      <niko:LoginForm id="loginform"/>
   </mx:Panel>
</mx:Application>

On a déclaré un nouvel espace de noms, ici niko (mais on aurait pu mettre ce qu'on veut) pointant vers les fichiers sous le répertoire components du projet. Simple, non ? En tout cas, cela devient un jeu d'enfant de produire des composants réutilisables.

Le nerf de la guerre, l'accès aux données distantes

Flex propose trois modes d'accès aux données distantes, par le biais de trois composants :

  • L'objet HTTPService, comme son nom l'indique, permet d'effectuer des requêtes HTTP sur une url et d'en récupérer la réponse. Un objet bien pratique quand on veut s'interfacer avec une architecture REST, par exemple.
  • L'objet WebService permet de s'interfacer avec un webservice au format WSDL via SOAP. Quand on dispose de tels service, c'est un plaisir de se baser dessus depuis Flex puisqu'on a qu'à réferencer les méthodes à utiliser et les déclencher depuis leur référence.
  • Mais l'objet de loin le plus intéressant à mes yeux est RemoteObject, implémentation du protocole RPC dans Flex, pendant Flash/ActionScript du RMI en Java. Comme je fais peu de Java, j'ai tendance à plutôt utiliser AMFPHP[3] pour publier mes services en utilisant PHP. Un très bon tuto de mise en oeuvre du couple AMFPHP/Flex se chargera d'illustrer le concept plus efficacement que je ne le fais ici.

FlexBuilder

Adobe propose un IDE dédié à la réalisation d'applications Flex, FlexBuilder. Cet outil, basé sur le célebrissime Eclipse, permet de disposer d'un environnement complet de développement comprenant entre autres un éditeur de code (MXML en mode source/wysiwyg, ActionScript, CSS, etc.), un débogueur avancé à la Java, un gestionnaire de projets, la compilation automatique et surtout un accès à l'immense catalogue des plugins Eclipse. D'ailleurs, FlexBuilder est également disponible sous la forme d'un plugin à installer sur une instance d'Eclipse existante : de quoi travailler sur vos projets Flex/PHP de façon centralisée, par exemple.

Inconvénient majeur de cet outil, il est payant. Et coûte relativement cher, puisque proposé aux alentours de 500€. Néanmoins, le SDK de Flex étant gratuit, vous pouvez tout à fait vous passer de FlexBuilder et compiler vos applications à la main. Une bonne nouvelle ne venant jamais seule, Adobe a décidé de publier la prochaine mouture du framework sous licence libre [4], aussi nous devrions voir fleurir des alternatives à FlexBuilder et assister à un taux d'adoption plus conséquent de la technologie.

Organisation du code, frameworks

Au vu de l'étendue fonctionnelle de Flex et des différents formats de fichiers mis en oeuvre ainsi que de leurs interactions potentielles, il est clair que maintenir la moindre petite application peut vite relever du cauchemar les développements avançant. Pour faire face à cette problématique, Adobe propose un surframework du nom de Cairngorm mettant en oeuvre les bonnes pratiques d'architecture logicielle en implémentant le motif de conception MVC bien connu des utilisateurs de frameworks de développement rapide orientés web.

Même si le projet semble extrêmement intéressant, je n'ai pas encore pour l'heure pu jouer avec.

Conclusion

Pour l'heure et après avoir pas mal galéré tâtonné avec l'outil au début, je dois reconnaître maintenant et avec un peu de recul que c'est assez efficace. C'est relativement déstabilisant pour quelqu'un qui comme moi avait l'habitude de l'IDE Flash Authoring classique, mais au final FlexBuilder semble beaucoup plus sérieux pour tout ce qui concerne la programmation et l'organisation des fichiers (Eclipse oblige.) Même le templating y gagne à mon sens, mais par contre impossible de faire de la création graphique avancée directement dans FlexBuilder, l'outil n'est clairement pas l'ami des infographistes de vocation.

Pour enfoncer le clou, j'ai pu comparer l'utilisation de Flex et de XUL, ayant enchaîné deux projets coup sur coup les mettant en oeuvre. L'excellente documentation de Flex et la richesse des outils gravitant autour de la techno font que pour l'heure Flex me semble l'un des meilleurs choix pour développer une RIA, si l'on écarte le couple HTML/Ajax qui garde une toujours une place de choix dans mon arsenal webdeuzéroesque ;)

Notes

[1] Je ne sais pas à quoi correspond la lettre M de l'acronyme, Macromedia sans doute.

[2] En attendant HTML5, les antiflash pourront aller zieuter du côté d'extjs ou de YUI.

[3] Attention à bien utiliser la dernière version 1.9 beta compatible avec Flex2

[4] Sous licence MPL plus précisément.

mardi 17 juillet 2007

De l'art de reprendre un contenu sur internet

Par NiKo le mardi 17 juillet 2007, 20:31 - Divers - 21 commentaires

Suite à ma récente mésaventure[1] heureusement bien terminée avec un blogueur qui avait repris un contenu issu de ce blog sans en créditer la source, voici rapidement quelques enseignements que l'on peut tirer de cette histoire :

  1. La reprise de contenus préexistants doit faire l'objet d'une citation de la source originelle.
  2. La licence du contenu repris doit être respectée. Pour mémoire, sur ce blog la licence retenue est la Creative Commons BY-SA-NC :
    • Citation de l'auteur original
    • Partage à l'identique
    • Pas d'utilisation à des fins commerciales (les sites gavés de pubs sont donc exclus)
  3. Si aucune licence n'est stipulée, le droit commun du pays où est hébergée la ressource s'applique par défaut (en France, c'est le code de la propriété intellectuelle.)
  4. Le leeching, c'est mal, surtout à l'heure où de nombreux services d'hébergement gratuits existent. Donc gaffe aux copier-coller, d'autant plus qu'on peut se confronter tôt ou tard à de désagréables suprises...
  5. Toujours laisser une adresse mail ou un formulaire de contact sur son blog histoire d'être facilement joignable en cas de souci. Se reposer sur les informations contenues dans les bases de données du NIC reste à mes yeux super gonflé. De plus ce type de mise en place facilite la tâche à l'éditeur échaudé et lui évite de faire un billet pour interpeler le fautif.
  6. Si vous êtes pris en faute, il est suicidaire d'essayer de faire semblant de rien, par exemple en effaçant sciemment les tentatives de dialogue en commentaires. Ça ne marchera de toutes façons pas et ne fera qu'amplifier les conséquences potentielles du problème.

Mais surtout, car c'est fréquemment la source du mal :

  • Il est illusoire de penser publier quelque chose sur internet sans restriction d'accès et de penser être le seul à pouvoir le consulter[2].

Vous ne pouvez jamais présupposer qu'un contenu publié sur votre site ne sera pas indexé par tel ou tel bot à la mode, ou que son url ne sera jamais déduite par quelques petits malins n'ayant que ça à faire. Le blogueur dont je parlais était par exemple très surpris d'apprendre que Technorati indexait très bien tous les billets de son blog soit disant privatif et non-référencé...

De plus, il n'est pas toujours évident de distinguer les intentions derrière une reprise de contenu : bloc-note personnel, amateurisme naïf ou méconnaissance des conditions de licence ? Afficher la couleur de vos intentions peut-être une bonne idée, dans tous les cas.

Note en passant, si vous désirez publier pour vous et vous seul, il existe quelques solutions techniques bien connues pour limiter voire empêcher l'accès à une ressource sur internet :

  • Les fameux fichiers .htaccess et autres règles Apache (des équivalents existent pour la plupart des logiciels serveurs HTTP),
  • L'authentification utilisateur via login/password,
  • L'hébergement sur un réseau local ou privé,
  • etc.

Pour balayer devant ma propre porte, en tant qu'éditeur de contenus je vois aussi quelques bonnes pratiques à appliquer :

  1. Mettre en place une page dédiée à la description de la licence et aux conditions de réutilisation des contenus,
  2. Se méfier de la puissance de feu de ses propres lecteurs quand ils décident de prendre faits et cause pour vous,
  3. S'acharner à contacter l'auteur d'une réutilisation pour vérifier ses intentions et éviter les erreurs judiciaires,
  4. Prendre des vacances, vite.

Notes

[1] Le billet a été supprimé afin de ne pas nuire au blogueur en question, celui-ci étant de bonne foi et ayant bien réagi.

[2] Des preuves de ce que j'avance existent.

samedi 7 juillet 2007

Go PHP 5

Par NiKo le samedi 7 juillet 2007, 20:26 - Dev - 6 commentaires

Je relaie ici cette chouette initiative d'un groupement de projets open source pour inciter à l'adoption et au déploiement de php5 en lieu et place de l'antique et moins performant php4 : Go PHP 5 !

Php4 nous a rendu de fiers services, mais il est plus que temps de reconnaître que cette version est maintenant largement dépassée et que le maintien de son utilisation ne sert pas l'essor du langage sur des projets de grande envergure... d'autant que la fin du support officiel de php4 est annoncée pour cette année.

Le pire c'est que php6 et ses alléchantes petites révolutions vont arriver l'année prochaine, je sens qu'on est pas sorti de l'auberge :/

Edit : La mort de php4 officiellement annoncée sur php.net. Le vendredi 13 lui a porté malchance ^^

jeudi 31 mai 2007

Google Gears : vous pouvez vous deconnecter

Par NiKo le jeudi 31 mai 2007, 17:38 - Divers - 7 commentaires - un rétrolien

Note : ce billet est une reprise de l'article que j'ai publié sur le blog de Clever-Age, Google Gears : vous pouvez vous déconnecter.

Edit : Article publié sur ZDNet, la gloire ^^

Google a annoncé aujourd’hui à l’occasion du Google Developer Day le lancement de sa réponse technique concrète aux problèmes de la consultation et de la synchronisation de données web en mode déconnecté : Google Gears.

Cette réponse prend la forme d’une extension pour navigateur web (Firefox sur Windows, Mac et Linux, Internet Exporer sur Windows [1]) comprenant un serveur local, une base de données et un gestionnaire de transactions permettant de transformer le navigateur en solution client-serveur local afin de régler l’épineux problème du travail en mode déconnecté avec les applications web modernes.

En effet, si les applications en ligne se sont considérablement enrichies et sophistiquées ces dernières années, au point de devenir de plus en plus indispensables à certains d’entre nous, elles subissent cependant pour la plupart d’entre elles d’une limitation importante : la nécessité d’être en permanence connecté à internet pour fonctionner. Nombreux sont les cas d’impossibilité de se connecter au réseau des réseaux : zone de couverture, problèmes matériels, d’infrastructure, etc.

Bien sûr, certains se sont déjà - et parfois depuis longtemps - penchés sur la question. C’est le cas de Mozilla avec l’ajout dans la version 2 de Firefox d’une base de données SQLite ou du projet Zimbra permettant la sauvegarde de ressources locales. Mais l’une des solutions les plus avancées semblait se situer du côté du Dojo Offline Toolkit, un projet open source proposant des fonctionnalités de stockage d’interfaces, de données et d’applications en local et des fonctionnalités de synchronisation.

Google Gears se base sur cette dernière solution, embarquant le Dojo Offline Toolkit et une base de données SQLite au sein même de son extension. L’extension est open source (sous licence new BSD) et peut à ce titre être redistribuée dans une application embarquant le runtime ou utiliser une installation existante de l’extension. La disponibilité du code est également une bonne garantie quand à la transparence, au taux d’adoption, à la sécurité et l’évolutivité du produit [2]

Une des premières mises en oeuvre intéressantes de Gears se situe depuis ce matin dans Google Reader, l’agrégateur en ligne de Google : les utilisateurs ont pu remarquer la présence d’un nouveau bouton permettant de récupérer en local les 2000 derniers éléments non-lus afin de pouvoir les consulter hors-ligne.

Synchronisation de données en local dans Google Reader

Évidemment, ceci n’est qu’un début et Google ajoutera progressivement ce type de fonctionnalités à ses applications en ligne phares comme GMail, Calendar, Docs, etc...

Google Gears ne sera cependant pas limité au monde de Google, mais sera utilisable par tout éditeur de site Web concerné par ce type de problématiques. Imaginons par exemple l’application d’un constructeur automobile permettant de configurer son véhicule : l’utilisateur télécharge alors de façon transparente le catalogue des éléments disponibles et peut ensuite prendre tranquillement l’avion, utiliser l’application pendant le vol en configurant sa future voiture. Une fois rendu à destination, il synchronise sa simulation une fois reconnecté à internet et envoie les données au serveur web du constructeur.

Plus directement utile ? Le téléchargement en local des données cartographiques et des points d’intérêt de votre futur périple au bout du monde, hors-zone de couverture internet ? Vous y êtes ?

Alors, tout est au mieux dans le meilleur des mondes ? Peut-être pas, si l’on considère cette initiative de Google sous l’angle de la standardisation : en effet, Google et les équipes de développement Dojo proposent aujourd’hui une solution qui est basée sur un effort de réflexion qui a été initié auprès d’un nombre restreint de participants ; quid si demain Microsoft publie sa propre interprétation du problème ? Allons-nous à nouveau assister à un affrontement des deux géants, avec tout ce que cela implique en terme de problèmes d’interopérabilité ? Le fait qu’Adobe semble vouloir intégrer Gears dans Appolo et que Mozilla et Opéra soient de la partie risque de complexifier encore un peu plus le problème pour l’éditeur de Redmond.

Reste que le sujet est à surveiller de près, car les enjeux sont énormes à l’heure où les applications web tendent à empiéter de plus en plus sur le territoire des applications client-lourd traditionnelles.

[1] Le support de Safari et d’Opéra est d’ores et déjà annoncé.

[2] Déjà une mise à jour depuis le lancement ce matin même !

- page 2 de 4 -