Archive pour la catégorie ‘Développement’

Guide à destination de nos amis graphistes… vu par un développeur

Publié le 19 December 2011, par Babozor

Oui ami graphiste, tu es beau svelte et musclé, tu manie la tablette graphique comme personne et tout ta famille te surnommes “photoshop”… mais voilà, parfois quand tu nous transmets tes jolis PSD et ben ça va pas.
Voici donc un petit guide pour calmer la guerre Dev VS Graphiste et te permettre de connaître les attentes des devs, les trucs qui vraiment nous énervent ou juste nous font perdre un temps infini.

Vilain psd

Design Général
Tu es plein de bonnes idées et c’est tout à ton honneur, mais autant cela semble un concept original et novateur, autant à mettre en place c’est juste un cauchemard…

Pleins de typos pas système
Oui certes cette police rend très bien sur tous les titres de tes créas, cette variante de “stencil” lui donne un air très martial, mais tu dois aussi prendre en compte que ce n’est pas un police système, donc il faudra soit créer physiquement les images et les inclure dans le site web, ou alors tenter de faire monter cette police de caractères dans les navigateurs nouvelle génération. Dans les deux cas une galère qui pourrait sans doute être évitée avec un peu de créativité et sans tomber dans la facilité d’une police bien funky mais qui n’est pas un standard

Des designs ronds
Peu importe la spécialité, si quelqu’un a déjà monté une page web, il te dira que la pire des chienlit est de tenter de monter un design bourré de courbes et de ronds. C’est certes esthétiquement très plaisant, mais vraiment galère à mettre en place. Si vraiment c’est “indispensable” penses à le rendre un minimum flexible, en le collant plus ou moins en image de fond, ou un truc du genre (ou même tentes simplement de laisser tomber cette idée lamantable)

Des câlages bizarres
Le langage utilisé sur le web est interprété, c’est à dire que le moteur de rendu le lit ligne après ligne et le rend au fur et à mesure. Cela rend le câlage de certains éléments dynamiques en hauteur pour le moins compliqué. Penses donc soit à limiter ou à fixer la taille en hauteur, soit à en discuter directement avec un dev si tu a un doute sur la faisabilité de ton design.

Ne pas penser et designer dans le sens inverse
C’est plus ou moins le même thème, mais par exemple faire un slider en jquery de haut en bas nécessite 2 includes et un appel… ultra simple. Tenter de faire ce même slider de bas en haut complique beaucoup les choses… donc penses-y au moment où tu design l’espace et les mouvements.

Les images en fond d’écran “fullsize”
C’est certes très joli (je connais quelques exemples qui rendent super bien) mais cela pose pleins de problématiques qui parfois peuvent emmener des tas d’emmerdes, en fonction de la taille du navigateur, de la hauteur du contenu, etc… et passer d’un dev trivial à un dev chaud avec plein de code javascript bizarre qui risque de ralentir de façon considérable le projet

Mettre le design dans son contexte
C’est très souvent oublié par beaucoup de graphistes, on nous rend un projet, une page, mais qui n’est pas remis dans son contexte. Quand le navigateur est très grand (1600 pixels de large par exemple) comment viens se câler le design de 990 pixels de large? Centré, câlé à gauche, à droite? Avec une marge sur le côté, en haut? Pensez-y…

Les PSD
Tel un gros orc bourrin ton arme favorite est le PSD de 40 Mo, voici donc quelques tips pour ne pas te faire haïr par les devs avec qui tu risque de travailler

Anti aliasing

un PSD fourre-tout
On y trouve tout et surtout n’importe quoi, des calques non utilisés ou vides, qui ont tendance à nous embrouiller lors des tentatives de découpage et d’export… j’ai déjà vu plusieurs version de design sur le même PSD, bref un galère pour savoir quoi garder et quoi mettre à la poubelle

les calques pas nommés ou avec des nommages inutiles
Je pense qu’on a tous vécu ça, un PSD de 30 Mo, avec 200 calques, aucun groupe et surtout des claques qui s’appellent de façon très originale “calque 1″, “calque 2″, etc.. Allez retrouver le bon morceau du design à exporter avec ça.
Comme pour les dev qui mettent des variables “prout” dans leur code, le mieux (même pour toi ami graphiste) pour s’y retrouver est encore de tenter de nommer les calques de façon correcte et compréhensible par tous.

des groupes de groupes de groupes, de groupes…
Grouper les calques c’est bien, en faire trop, ça ne sert pas à grand chose et cela à même tendance à compliquer le tout. Si un groupe a un seul calque, ce n’est plus un groupe (puisque la définition d’un groupe c’est que y’a plusieurs éléments à l’intérieur), donc tentez là aussi de grouper les calques sous un même thématique. Pas besoin de grouper comme des psychopathes, si les calques sont bien nommés ils parleront d’eux même.

Le web c’est 72 dpi pas 300
je sais que ça peut paraître bizarre, mais il m’arrive encore de temps en temps de recevoir des fichiers conçus en centimètres ou en pouces avec un définition print pour un montage web. Cela peut paraître anodin et vous allez me dire “Oh arrêtes de faire ta chochote t’a juste à le redimensionner”… certes, mais toutes les tailles des typos, les espacements, etc… s’en trouvent chamboulés, et puis c’est le travail du graphiste de nous remettre un fichier exploitable.

Penser à l’antialiasing
Le Gaming OldSchool j’adore ça, j’aime aussi beaucoup l’art 8bit, mais sorti de son contexte c’est moyen. Faites donc attention à l’antialiasing, sinon toutes vos polices, dégradés, ombres ou courbes risquent de rendre super moche, voir juste inexploitables.

Fournir les polices manquantes (ou pas système)
Si vous utilisez des polices non systèmes (qui ne sont pas inclus dans les principalement plateformes) ou exotiques, vous avez deux choix: rasteriser toutes les polices (si les textes ne changent pas) ou nous fournir des fichiers exploitables pour pouvoir utiliser correctement vos PSD. Si ce n’est pas le cas, vous courrez le risque de voir vos polices substituées par des polices système et donc votre design être dégradé.

Penser au découpage et à l’export
Vous savez utiliser des fonctions super funky de masquage de calque sur Photoshop c’est très bien, mais moi je sais pas l’utiliser, et ce que j’ai besoin c’est de pouvoir exporter votre travail en optimisant le temps passé dessus. Pensez donc qu’il peut y avoir deux versions de votre fichier: celui sur lequel vous travaillez (avec vos masques et tous vos trucs bizarres de graphistes) et la version pour export, plus simple et beaucoup plus basique.

Non mon but n’est pas ici de relancer la sacro-sainte guéguerre Dev contre Graphiste, mais justement de donner des clefs aux uns et aux autres pour comprendre pourquoi les graphistes râlent sur les Dev qui eux même râlent sur les Graphistes (et les Chefs de projet, les marketteux et globalement tout le monde)

Quelques conseils pour finir:
– n’hésitez pas à poser des questions à votre dev préféré: il n’y a aucune honte à poser des questions, aucune question n’est idiote, surtout si ça vous fait économiser du temps (ainsi qu’au dev) donc n’hésitez pas. Est ce que c’est faisable, chiant à monter, est ce que tu es capable de le faire, est ce que ça va pas nous mettre hors-budget? Just ask (damn it!)
– nettoyez vos PSD: rien n’est plus insupportable pour un dev que de devoir passer une demi journée à nettoyer le PSD qu’un graphiste viens de lui remettre (c’est d’autant plus désagréable quand il s’aperçoit que ce n’est pas la version finalisée du projet). L’état de votre PSD est très caractéristique de l’estime que vous avez de lui… faites un peu le ménage et il vous en sera très reconnaissant.
– demandez ce que le dev a besoin: sans tomber non plus dans l’exagération, vous pouvez échanger un peu sur les préférences sur le nommage des calques ou les éléments à exporter, cela facilitera la vie à tout le monde.

Voilà j’espère que nos joyeux amis graphistes ne se seront pas offusqués, et je suis sûr que pleins de dev ont des histoires de psd horribles à raconter, donc je vous laisses les commentaires pour le faire.

OpenData Paris – Paris libère partiellement ses données (enfin…!)

Publié le 6 February 2011, par Babozor

A souligner une très bonne initiative de la ville de Paris qui a décidé de libérer une partie de ses données… et de les ouvrir dans un licence ouvert à tous sur ParisData

Ouvrir les données publiques, un mouvement nécessaire
Cela fais maintenant quelques années qu’on sens un frétillement dans ce domaine, un changement de politique. Pendant des années, les villes, gouvernements et organismes territoriaux gardaient précieusement leurs données, interdisant de les reproduire, les revendant à prix d’or aux entreprises qui pouvaient se les offrir. Ce temps est plus ou moins révolu (il reste encore pas mal de poches de résistance) avec les initiatives comme celle du Guardian’s en Angleterre sur FreeOurData, qui demandait la libération des données produites et mises à jour par le contribuable, ou encore les efforts de la communauté de Rennes (cf Hugues Aubain et sa présentation au Lift10 à Marseilles) qui donne accès à tous les infos des transports urbains.
Paris s’y mets enfin et c’est très bien…

parisdata_siteweb.jpg

Premier pas pour la ville de Paris
Il y a certes pour l’instant peu de données, des données assez génériques, mais des données fondatrices:
– fichier vecto des trottoirs
– données géographiques
– relief naturel
– mobilier urbain
– alignement d’arbres
– équipement de proximités
– nomenclature des voies
Tout pour vous faire une cartographie précise et libre de la ville de Paris en somme

Vous y trouverez aussi quelques données beaucoup plus précises et spécifiques, comme:
– statistiques de prêt dans les bibliothèques
– arrêts municipaux d’insalubrité
– liste des établissements scolaires
– statistiques des actes d’états civils
– liste des bureaux de vote
– liste des prénoms enregistrés
etc…

Des données super intéressantes
Il y a certes peu d’informations, mais elles sont intéressantes à plus d’un titre. La première est que vous avez toutes les informations de base pour vous recréer sans service tiers (que ce soit google maps, mappy ou un autre) la cartographie extrêmement précise et détaillée de la ville de Paris. Vous avez aussi accès à des données intéressantes, mais surtout il sont sous une licence qui plaira à plus d’un. En effet la licence (un résumé est lisible ici) vous permet de partager, créer et adapter les données, du moment que vous mentionnez la paternité, que vous gardez les données ouvertes et que vous les partagez dans des conditions identiques. Cela ressemble fort à un GPL pour les data (dérivée apparement de la licence ODbL) et cela permet aux particuliers et/ou enthousiastes de s’amuser avec, et protège le collectif des utilisations commerciales.

opendata_paris_trottoirs.jpg
un exemple des données dispo: le fichier complet vecto des trottoirs de Paris

Des mashups et mix passionnants en prévision
J’avoues j’ai joué un peu avec les données (surtout les données des trottoirs et les prénoms par année de naissance) et c’est pour le moins touffu… beaucoup d’informations, parfois mal organisées mais qui ont le mérite d’exister.
Rien qu’en regardant le titre des différentes données disponibles, je peux voir les applications possibles, les mashups délirants que cela va permettre et ça c’est très bien… cela permettra de redonner la main à tous ceux qui le veulent pour moudre un peu toutes ces données.

En conclusion
Très bonne initiative, même si le nombre de données reste aujourd’hui limitées… on attends que d’autres organismes (comme la RATP ou la SNCF) suivent le mouvement et libèrent enfin leurs données. Un potentiel d’innovation et de partage juste démentiel, moi j’adore. Je suivrais l’évolution de tout ça de très prêt.

Passage de TravailleursDuWeb en WordPress 3.0.1 – histoire d’une migration (un peu) prise de tête

Publié le 7 November 2010, par Babozor

A part quelques erreurs présentes de façon temporaires (et tout de suite remontées via Twitter et corrigées au plus vite) je suis passé le week end dernier de la version 2.3 (avec toutes les failles qu’on lui connaît) à la dernière version (la 3.0.1) de wordpress

wp_ajour.jpg

Pourquoi avoir tant attendu?
La dernière mise à jour datait de plusieurs années (un an et demi je penses au moins) et j’avoues que mes expériences de migration de blogs sous WordPress (avant la 2.5 en tout cas) m’avaient laissées de mauvais souvenir, plantage général, thème inutilisable… et donc j’ai toujours repoussé la mise à jour fatidique qui ne manquerais pas de mettre à mal mon blog.
Mais bon au vu de toutes les failles critiques présentes dans la 2.3, je me suis dit qu’il était grand temps de faire un peu de ménage et de mettre à jour la bête.

Backuper et préparer
La première chose à faire est donc de backuper tout, d’abord votre base de données… ensuite vos plugins et contenus (aussi bien vos thèmes que vos images) dans le répertoire wp-content, et quelques fichiers ici et là (en particulier le config.php histoire de pas perdre votre connexion à la base de données)
Je désactive tous les plugins et c’est parti… (cette étape est très importante)

Jouer un peu au bourrin
Tout est backupé, c’est parti pour l’écrasage de fichier… en gros je copie tous les fichiers du zip trouvable sur wordpress.org, sauf le répertoire wp-content (qui contient tous les plugins, le thème de mon wordpress, etc…) et j’attends sagement que le transfert se termine.
Comme je l’ai dit plus haut il est important de désactiver les plugins et TOUS les plugins, pas juste ceux qui semblent plus ou moins inutiles.
Moi j’avais décidé de garder Akismet actif (celui qui lutte contre les commentaires de spam) ce qui a causé à mon install quelques erreurs. J’ai été obligé de passer via MySQL pour le désactiver (un article de référence btw à lire ici) et tout roule plus ou moins (après un update de la base de données pour la remettre au niveau de la nouvelle release).

Réparer
Maintenant que vous avez de nouveau accès au BackOffice de WordPress, vous ré-activez vos plugins et vous regarder les erreurs sur le front, vous nettoyez les différentes erreurs (soit de plugins qui ne marchent plus, soit de ceux désactivés) et vous êtes bon

Hop c’est reparti…
En conclusion, un petit flip, une petite heure d’indisponibilité, mais un blog remis au niveau (et que je vais tenter de garder plus ou moins à jour)

Pourquoi avoir updaté mon wordpress?
Voilà pourquoi:

C’est bon vous êtes calmé? plus d’infos ici et

Guerre des navigateurs, pour les développeurs, en 12 ans rien n’a changé…

Publié le 19 October 2010, par Babozor

Cela fait maintenant un peu plus de 12 ans que je suis développeur web, une grosse décennie, et ce qui me navrais à l’époque est malheureusement toujours d’actualité.

Nestcape contre Internet Explorer
Au tout début de ma carrière de développeur web, je travaillais pour une agence web spécialisée dans les technologies microsoft (ouais je sais le côté obscur est toujours le plus tentant surtout au début), on développais en ASP sous SQL Server (pour ceux qui se souviennent avec les extensions FrontPage et ce genre de crottes) et à cette époque notre bête noire était Netscape… pleins de trucs ne marchaient pas dessus, et sur beaucoup de pages et de fonctionnalités on devait faire un développement spécifique pour ce navigateur.

Internet Explorer contre les autres
Je vous passes les détailles de ces douzes dernières années, mais aujourd’hui la situation n’a paradoxalement pas bougé des masses… on a toujours d’un côté Internet Explorer qui s’entête avec son moteur merdique et de l’autre Mozilla, Webkit et Opéra qui respectent globalement les standards. Toujours la même situation (plus ou moins inversée si on considère la situation particulière dans laquelle je me trouvais), on développe ça marche nickel et puis on test sous IE et là le double dev commence.

Des différences dans le CSS d’un navigateur à un autre
Je ne parlerais pas ici des propriétés pas pris en compte par tel ou tel navigateur, mais de l’écart qui commence à se former entre les différents navigateurs au sein même du groupe qui respecte les standards du web. Certaines propriétés comme border-radius nécessitent un préfixe -moz pour un code spécifique pour Mozilla, alors que d’autres le sont pour -webkit et d’après mon expérience ça n’augure rien de bon au contraire…
(je ne parlerais pas du fait que la plupart de ces propriétés ne sont pas présentes dans IE, c’est censé être prévu dans la version 9, wait and see)

Le problème de persistance des navigateurs
Outre ces combats inter-navigateurs, le principal problème est que la nouvelle version d’IE même si elle est censé respecter beaucoup mieux les standards ne se payera pas une part significative de présence en remplacement de la précédente avant des années… pour exemple la part des utilisateurs d’IE6 semble s’effriter mais est toujours belle et bien présente (quand on sais à quel point ce navigateur est merdique, il a de quoi se faire des sueurs froides en pensant au pourcentage de présence d’IE7 et 8 dans les années à venir).

La solution? Respecter les normes et bannir les vieilles versions d’IE
Pour ma part j’ai trouvé une solution qui n’en est pas vraiment une.
La première partie est de tenter de respecter au plus près les standards et normes du web, cela permettra à votre code d’être beaucoup plus portable d’un navigateur à un autre, d’un OS à l’autre.
La deuxième partie est d’annoncer clairement les conditions de support des différents navigateurs, pour ma part c’est Mozilla, Webkit (donc Safari et/ou Chrome) Opera et IE7 et supérieur, avec les précisions suivantes: support complet pour IE8, partiel pour IE7 et pas de support pour IE6. En gros si ta mère à son travail regarde ton site sous IE6 et bien c’est dommage pour elle.

A quand une vraie harmonisation des navigateurs web?
Même si beaucoup d’efforts ont été faits (et pour ça je me dois de baisser bien bas mon chapeau à Mozilla qui pousse toujours les autres dans la bonne direction) pour des moteurs de navigateurs plus rapides, mais surtout plus respectueux des standards, certains (que je pointes du doigt: cf Microsoft Internet Explorer qui sont obligés de faire de la pub à la téloche pour redorer leur blason) restent à la traîne et continuent à jouer les poils à gratter pour nous autres pauvres développeurs web.

Et vous c’est quoi vos expériences de galère de développement Cross-Browser?

Ma première fois

Publié le 20 April 2010, par mere-teresa

De nombreuses personnes m’ont déjà entendu dire que je continuerais à faire de l’informatique jusqu’à ce que je vois un projet sortir en temps et en heure. C’est une blague récurrente, qui reflète, malheureusement le manque de soin apporté à l’évaluation des risques, des ressources et des spécifications dans les projets de développement web.

Pour faire écho à l’article de Damien Mathieu, j’ai déjà rencontré de très bons chefs de projet. Mon expérience de consultante-formatrice m’a amenée dans des entreprises privées aussi bien que dans des établissements publics, au contact d’équipe variées. J’ai toujours constaté une certaine fatalité envers le retard dans les projets web.

Et pour la première fois, lors d’une mission, nous livrons des features au rythme prévu. Parfois, cette date a été ré-ajustée au fil du développement, parfois la feature B devance en produit livrable la feature A et se retrouve livrée plus tôt. Tout va bien, me direz vous, alors plutôt que de pointer encore et encore les erreurs des projets, les erreurs des développeurs, je vous propose d’examiner les conditions de cette réussite.

Maîtrise des développements

Pour une fois, ma mission de développement se déroule chez un éditeur de logiciels, et pas dans une SSII ou web agency. Les contraintes sont différentes : ajouter des nouveautés permet de continuer à faire évoluer le site web. Et maintenir l’existant permet de gagner la confiance des utilisateurs. Le besoin de qualité est important pour un code pérenne et maintenable, cette qualité est plus importante que le besoin de livrer rapidement. Les dates limites existent néanmoins et permettent de border les tâches, et de découper les features en tâches.

Direction du projet

Les projet ont deux têtes pensantes : un lead développeur, une chef de projet (commune aux projets). Et en plus, un directeur technique est disponible, pour les points plus critiques ou les choix techniques d’évolution du projet (modification du système de traduction, par exemple). Les technologies les plus performantes sont envisagées pour remplacer les technologies classiques. Cela donne du dynamisme au projet, et attire des développeurs de qualité dans l’entreprise.
Malgré un recrutement soutenu, les développeurs sont bien intégrés aux équipes par des formations aux outils, et comme habituellement, des tâches autonomes et indépendantes des autres du projet à réaliser. Le temps de midi est également mis à profit pour la convivialité.

Des horaires souples

Pour mes besoins personnels, je préfère arriver tôt et repartir tôt. D’autres collègues préfèrent arriver plus tard (après 10h) et j’imagine qu’ils partent plus tard. La pause déjeuner n’est pas non plus chronométrée. Nous sommes managés à la tâche plutôt qu’au créneau horaire, et responsabilisés sur notre tâche. Les dates de planning nous ont permis de déterminer un rythme à tenir pour la sortie de notre feature.

Rencontres fréquentes

Malgré l’open space, dont on sait qu’il est moins bon pour la productivité que les bureaux individuels, les développeurs s’isolent pour se concentrer. Les rencontres sont donc provoquées par un stand-up quotidien, qui a lieu après la pause déjeuner. Parfois, les développeurs d’un même projet — qu’on croirait connectés — se retrouvent à échanger, parfois c’est une simple énumération de ce sur quoi chacun travaille.
Même si nous travaillons sur des logiciels différents, nous avons des fonctionnalités communes, pour résoudre les mêmes problèmes, nous communiquons entre les projets. Les solutions éprouvées sont alors dépistées, ainsi que les impasses.

Challenge technique

En plus d’utiliser des technologies de pointe, toutes les deux semaines, une journée consacrée à la technique est organisée, les développeurs comme l’infra se retrouvent à mettre en place des nouveautés techniques dans l’application, à faire des tests sur les futurs produits techniques, à réparer de petits agacements dans le code ou la configuration qui ralentissent tout le monde.
Cette journée de technique pure, sans but de plaire aux commanditaires (ou actionnaires) des logiciels est toujours un jour agréable. Nous passons en production des nouveautés qui ont été testées précédemment, ou des ajustements qui augmentent le confort de développement.

Convivialité

La pause repas ayant déjà été évoquée, j’ajouterais les outils d’Instant Messaging, la mise à disposition de consoles de jeux (et canapés), le café à volonté, ainsi que la présence d’un outil de “Perles” qui recueille les propos les plus amusants, sortis de leur contexte, évidemment. Ces différents outils renforcent les liens inter-personnels et la confiance entre les développeurs.

Pour terminer, les développeurs sont considérés comme essentiels à la production de valeur dans l’entreprise. Le fait qu’ils soient nombreux les rend majoritaires par rapports aux autres services (marketing, RH ou comptabilité). La direction des projets fournit le matériel nécessaire au confort de chaque développeur (écrans, lampes, etc.) et les responsabilise sur leur code et le code de leur projet.
Sans utiliser de l’eXtrême Programming ou du Scrum, quelques pratiques issues des méthodes agiles améliorent le confort des développeurs et la qualité des produits.

billet invité rédigé par Sarah Haïm-Lubczanski