Archive pour la catégorie ‘Développement’

Développement web durable ?

Ca fait plusieurs fois ces derniers temps que j’ai l’occasion de me demander « mais pour combien de temps ces gens développent-ils leur site internet ???« . Et chaque fois, l’horizon est de 3 à 5 ans. Le web évolue vite, donc il faut refaire régulièrement. Ils en ont conscience, c’est normal, c’est une dépense lourde, mais Internet est un impératif, ça permet d’avoir une bonne vitrine et de soigner son image, il faut dépenser.

Je ne suis pas totalement contre cette idée. Le web évolue vite. Il faut donc faire évoluer les sites en même temps. Mais en revanche, une grosse refonte de profondeur est-elle vraiment nécessaire si le projet est bien pensé au départ ? A mon gout, le seul risque, c’est le changement radical de technologie (genre ASP => PHP => ROR), pour le reste, des améliorations régulières suffisent amplement.

Sauf quand un site n’est pas prévu pour durer : de très gros développements Flash, absence de séparation entre le fond et la forme, code incompréhensible pondu par une machine sans intelligence, aucune orientation objet dans le développement (ou pensé à peu près comme tel), etc…

Ce qui m’étonne le plus, c’est que l’on soit encore actuellement dans une démarche de vendre ce type de produits. Qu’à-t-on à y gagner ? Refaire le travail tous les 3 ans ? Les changements de chartes graphiques, les évolutions régulières, les nouveaux services, devraient fournir largement autant de travail… et surtout, surtout, permettre d’aboutir à un résultat plus concluant puisque pas repris régulièrement à zéro !

Ah ! Si 2008 pouvait correspondre avec une prise de conscience de l’intérêt d’un développement propre et de celui du respect des standards, ce serait une bonne année
à tous ! (Ben quoi ? Je ne vous l’avais pas encore souhaité !)


Migrations et redirections…

Suite à une petite demande d’Alain, voici une explication du comment je suis passé plus ou moins en douceur d’une ancienne URL à la nouvelle. Pour faire de la redirection, il existe plusieurs méthodes plus ou moins propres en fonction de ce que l’on veut faire ou au contraire éviter de faire.

Méthode 1 :
Je prends une page HTML vierge et entre les balises head, je place une balise meta du genre :
<http-equiv="refresh" content="0; url=http://www.monsite.com/index.html">

Cette méthode fonctionne mais ne concerne qu’une seule page. C’est en fait un simple rafraichissement vers une nouvelle adresse.

Méthode 2 :
La même en couleur, en utilisant le javascript avec une commande du type :
window.location.replace("http://www.monsite.com/index.html");

L’avantage de cette méthode, c’est qu’elle permet de renvoyer une URL calculée… côté client. Les gros inconvénients, c’est que justement, tout se passe côté client, que c’est pas top au niveau accessibilité et que javascript est désactivé sur environ 5% du parc. Bagatelle, les moteurs de recherche ne pourront pas voir la redirection non plus.
Je profite du sujet pour signaler aux petits malicieux qui sont en train de se dire « je vais truffer une page de mots clés et renvoyer les vrais internautes vers une autre », attention, vous jouez avec le feu ! Si un moteur s’aperçoit de la supercherie, c’est le bannissement définitif.

Méthode 3 :
On peut aussi envisager un renvoi vers une URL différente via les scripts serveurs.

En php, on aura quelque chose du genre :
header("HTTP/1.1 301 Moved Permanently");
header ("Location: http://www.monsite.com");
exit();

En ASP, ça donnerait :
Response.Status="301 Moved Permanently"
Response.AddHeader "Location", "http://www.monsite.com"
Response.End

Le gros avantage d’une telle méthode, c’est que l’on voit apparaître le Moved Permanently qui permet de signaler aux moteurs de recherche qu’il faut mettre à jour le lien vers la nouvelle adresse. L’inconvénient, c’est qu’il faut traiter chaque page, ou écrire un script un peu sophistiqué.

La méthode ultime
(selon ce que l’on veut faire) :
Sur un serveur Apache, vous avez en standard, la possibilité d’utiliser des fichiers .htaccess. Le .htaccess permet entre autre de sécuriser des dossiers, de faire de la réécriture d’URL, mais en fait, en regardant bien, il sait faire un tas d’autres choses (page d’erreur personnalisée, etc). C’est parmi ces diverses utilisations possibles que l’on trouve le RedirectPermanent, qui renvoi un code 301 au navigateur.

L’écriture est assez simpliste :
RedirectPermanent / http://www.monsite.com/

Là, en une ligne bien placée, on redirige un fichier, un dossier, ou tout un domaine en faisant suivre son référencement. La ligne rêvée pour la grosse feignasse que je suis !

Pour finir, pour mon blog, comme je passais de la version 1 à la beta 2, il ne me manquait plus que le petit plugin de Pep pour rediriger automatiquement les URL modifiées entre les deux versions et le tour était joué.


Quanta+ Versus Eclipse

Eclipse Au moment ou le Zend Framework se mettait en place, une annonce avait été faite sur un partenariat avec Eclipse pour la création d’un module PHP. Bien entendu, comme le Zend Framework, j’avais suivi ça de près. Et j’avais tenté une ou deux fois de me servir d’Eclipse avec le module PHP. On va dire que ce n’était pas encore très au point.

Il y a une petite semaine, j’ai réitéré l’expérience, et là, miracle !! Eclipse fonctionne parfaitement bien avec PHP. Du coup, pour tout avouer, j’ai un peu lâché Quanta+ que je considérais jusque là comme l’éditeur de loin le plus pratique pour bosser.

Les avantages d’Eclipse sur Quanta+ sont pléthore :

  • Versions multi-plates-formes, ce qui me permet de bosser au bureau sous Windows et à la maison sur Linux,
  • Autocomplétion plus performante sur les différentes fonctions et classes,
  • Un catalogue de toutes les fonctions et toutes les classes d’un projet, sans parler des fonctions natives PHP5,
  • Synchronisation (dans les deux sens) très simple avec un FTP ou un SVN,
  • Possibilité de mettre des marqueurs à côté des lignes (ce qui manquait cruellement à Quanta+),
  • Intégration de Tidy pour un code plus propre,
  • Un historique plus vaste ne se limitant pas à la version précédente du fichier,
  • Eclipse est beaucoup plus léger sur les gros projets.
  • etc.

Pour mes besoins, je n’ai installé que la version dédiée à PHP d’Eclipse. Plus légère, elle n’embarque que les modules nécessaires au PHP. Je n’ai pas encore tout parcouru, mais pour l’instant, Eclipse m’a véritablement séduit. Seule petite ombre au tableau peut-être, la gestion des commentaire est moins bien finie que dans Quanta+. Simple oubli ou question de jeunesse, il ne fait aucun doute que ce sera réglé dans les futures version.

Et vous ? C’est quoi votre éditeur favoris ?


Le web 2 ? C’est vous !

Aller, un peu de suivisme…

Une excellente vidéo de Michael Wesh, découverte chez Eric, via un Tristan en vrac

Comme quoi, on lit tous la même chose ! Y’en a pas un qui finira par nous faire une revue de presse commune, histoire qu’on arrête un peu de surfer comme des fous ?

Le web 2 c’est vous !


Les standards du web : non !

Interdit de W3C
Imaginez : Une belle page, entièrement en strict, avec un minimum de balises et un CSS tout beau tout propre.
Tout passe au vert dans les validateurs du W3C.
J’ai pensé accessibilité tout au long de ma petite création, je sais qu’elle sera lue par Jaws avec une certaine élégance.
Bref, cette page est l’archétype fantasmée du W3C. Je suis fier comme un coq, elle est belle ma page !
Je soumets au Big Boss, qui me dit « Changez 2 mots et on envoi ! ». Chose rare…

Oui, vous avez bien lu : « et on envoi »… et c’est là que tout s’effondre ! C’est là que l’on fait une magnifique plongée 10 ans en arrière… à l’heure où le W3C fêtait ses 2 ans et où tout le monde l’ignorait du haut de son berceau ! Cette page est une newsletter. Une newsletter est lue par des lecteurs de mails. Les lecteurs de mails ne sont pas tous basés sur des moteurs de navigateur, les lecteurs de mails sont de temps en temps des webmails qui font sauter la moitié des balises pour éviter les conflits…
Bref, mon mail passe bien dans Outlook, mais se transforme en horreur dans hotmail, résultats à chier dans gmail, idem dans évolution, j’en passe et des meilleurs…

La solution ? Coder comme un goret ! C’est le seul moyen (ou presque) pour qu’un mail passe bien partout ! Surtout, la règle d’or, si une chose respecte les standards, elle ne passera pas !!! Il faut de la soupe de balises ! Bien grasse ! C’est de saison ! La soupe, c’est bon, mangez en !!

Et bien vous me croirez si vous voulez, mais poser des tableaux partout, des fonts à ne plus savoir qu’en faire, ne pas utiliser le moindre style après des mois et des mois de standards… ça relève d’un exercice assez technique. Surtout, oubliez tout logiciel libre, c’est de la merde, ils ne savent pas faire la soupe ! Heureusement, un vieux Microsoft traînait dans le coin… un coup de FrontPage 2000 et… Houuu ! La jolie page… :-S

Mais bon, ça a marché ! Bien partie, bien arrivée.

Et vous ? Je suis sûr que vous avez trouvé des solutions plus intelligentes pour vos newsletters, parce que là… je ne suis quand même pas très fier…
C’est quoi les solutions ?