out through the winter throat

out through the winter throat le blog de Anahkiasen.

Articles taggés avec ‘Webdesign’

Le Version control

Mercredi 23 mai 2012

“If you’re not on Github, you’re essentially unable to participate in the rich open-source community that has arisen around front-end development technologies.”

Quand je dis que ma manière de travailler a changé je ne parle pas seulement du résultat final de mon travail mais du processus en lui-même, le workflow. En quelques mots c’est tout ce qui, de l’idée originelle, conduit au résultat final — les étapes suivies, les logiciels et langages utilisés, les pratiques mises en œuvre… bref vous saisissez l’idée. Chacun a sa méthode, chacun a rodé ses étapes, et il est toujours utile de lire et d’étudier la manière dont les autres travaillent.
Beaucoup de choses ont changées depuis que je me suis mis au webdesign, j’ai beaucoup fait évoluer ma méthode personnelle, mais s’il y a une chose que je tiens à mettre en avant en particulier aujourd’hui c’est l’importance du versioning et de sites comme Github.

Le version control en gros c’est l’acte de scinder son travail en versions (et oui). Le terme est assez large, il peut aller du simple fait de créer des versions de son projet (v1, v2) au fait de marquer chaque changement au code comme un point d’encrage en tant que tel, via des technologies comme svn ou git. Je ne vais pas (trop) m’étendre sur ces deux technologies parce qu’il y aurait trop à dire, mais comme le site de Git a il y a peu fait peau neuve je me permets de vous glisser un lien.
Cette article est plus sur le principe du versioning que sur les fondamentaux techniques. Si vraiment vous ne voyez pas de quoi je parle, et ne voyez pas de raisons de lire cette article, faites-le quand même. Le versioning s’applique tant à la programmation qu’au travail graphique – garder un historique de ses images et de son travail en général est un atout énorme, et même si je parlerai principalement de mon cas et de code ici, il y a de grandes chances que cela s’applique à vous aussi.

Dans la poignée de webdesigners que je suis de près, j’étais à une époque tombé sur un article de Rebecca Murphey qui disait « If you’re not on Github, you’re essentially unable to participate in the rich open-source community that has arisen around front-end development technologies. » (Si vous n’êtes pas sur Github, vous êtes fondamentalement incapable de participer à cette riche communauté open-source qui s’est formée autour des technologies du développement front-end [1]). C’est une phrase qui m’a beaucoup marqué, surtout parce qu’à l’époque je ne la comprenais absolument pas.

[1] Rebecca fait ici référence à des technologies comme le HTML5, le CSS3, Javascript, Ruby, PHP, et j’en passe. Le front-end se définit comme tout ce qui se trouve entre l’utilisateur et le back-end (le code moteur), l’interface en quelque sorte.

Historique

Pendant longtemps j’ai laissé ça de côté - parce que je ne voyais pas trop à quoi il était fait allusion, et parce qu’avouons-le, pour qui n’y a jamais touché Git et SVN sont des mondes qui donnent mal à la tête. Faits de branches, de commits, de pull request, de merge et de revisions, et j’en passe. Chaque technologie y va de son petit terme à elle, parfois même pour parler de choses identiques, et quand arrive l’heure de se lancer on peut mettre un long moment avant de saisir réellement ce dont il s’agit.

Dans mon cas j’ai décidé de m’y frotter quand ma petite ébauche de framework a commencé à faire ses preuves, et qu’il devînt de plus en plus complexe de gérer différentes itérations du moteur sur plusieurs projets. De répercuter les bugfixes et améliorations, de savoir où chaque projet en était et ce qui avait changé depuis la dernière fois. Du coup à l’époque je me suis lancé dans SVN, un peu arbitrairement – j’ai placé mon moteur sur un hébergement SVN en ligne (à savoir Beanstalk) pour me faciliter la tâche. Et après quelques coups d’essais j’arrivais à gérer plusieurs versions du moteur sur plusieurs projets — déployer des modifications sur chacun sans me prendre la tête, gérer facilement conflits et historiques, etc.

J’ai toujours considéré que quand on apprend une technologie nouvelle il n’y a de meilleur maître que la pratique. Sans se lancer complètement à l’aveugle non plus, le fait de tenter de mettre en œuvre ses connaissances dans un petit projet, parfois même au fur et à mesure de l’apprentissage, aide beaucoup à comprendre l’ensemble. Ça m’avait aidé à l’époque du HTML, puis du PHP, et ainsi de suite jusqu’à aujourd’hui.
Pour moi, Cerberus - le nom de mon framework - était ma manière de tâter le terrain de manière concrète. Séparer mes modifications en versions et ainsi savoir où en était tel ou tel projet. J’avoue bien sûr que, travaillant seul, il m’est bien plus simple d’expérimenter avec les technologies du web que pour beaucoup de gens.

À mesure que je me familiarisais et rattrapais mon retard avec la scène du webdesign, que j’employais et suivais de nouveaux projets et technologies, j’ai appris à connaître GitHub. Pour ceux qui ne connaissent pas, c’est un site basé sur le principe des repositories : des sortes de “répertoires” symbolisant des projets. Tout s’articule autour des interactions possibles entre eux : les gérer, les héberger, discuter autour d’eux; laisser les utilisateurs disséquer, réparer voire améliorer votre code.
C’est la base de l’open-source : votre code est à la vue de tous, les utilisateurs peuvent venir commenter ou interagir sur chaque ligne. C’est un concept qui peut paraître terrifiant à première vue mais qui révèle bien vite plus de points positifs que négatifs.

Le version control pour tout, partout, tout le temps

Vous l’aurez compris, le principe est de créer une sorte de ligne de temps de votre code. Où chaque modification est distincte des autres, ce qui ouvre tout un monde de possibilités, la plus utile étant sans conteste celle de ramener à tout moment votre code à un instant T. Qui n’a jamais fait une grosse modification sur son code pour ensuite se rendre compte même après tests qu’elle cassait quelque chose d’inattendu ?

De là une fois qu’on y a goûté il est difficile de faire marche arrière, et bien vite je me suis retrouvé à héberger, non plus simplement le code moteur de mes sites sur Github, mais mes projets eux-mêmes.
Ça me donne entre autres une facilité de transport. En ce sens où l’état des fichiers sur le disque n’importe désormais plus - finies les galères avec Dropbox de conflits de fichiers, d’erreurs de copie, et j’en passe. Les commits (modifications faites au projet) sont enregistrés en ligne et je peux décider de télécharger de n’importe où n’importe quelle version de mon projet, de sa naissance à la fin. C’est un outil miraculeux, surtout lorsque l’on travaille à plusieurs ou sur plusieurs postes : chacun peut améliorer un code dans son coin, tout en ayant toujours la dernière version sur son poste. Et si conflit il y a, les fonctionnalités de merge (fusion) de git et svn sont assez malignes pour gérer tout ça. Imaginons par exemple que deux personnes travaillent sur un même fichier et envoient leurs changements en même temps, pour peu que ces changements soient à des endroits distincts du fichier, tout sera habilement combiné en arrière-plan.

On en devient vite accro, de la technologie elle-même certes mais de la communauté autour aussi. Pour tout vous dire, même cet article a été écrit en Markdown (un langage de formatage) sur Gist, la plateforme d’échange de bouts de texte et de code de Github, qui permet elle aussi de créer une instance du fichier à chaque modification, de discuter autour. Bref de faire tout ce qu’on peut en temps normal.

Être au plus près du travail des autres

L’autre point fort comme je l’ai dit c’est la facilité d’interaction et la proximité des développeurs. Quand je repense à il y a quelques années, je pense que jamais je ne me serais imaginé participer de si près au développement des projets qui me sont chers. Lointain est désormais le monde des boîtes à suggestions où on envoyait des emails désespérés en priant pour être pris en compte. La plupart des gros projets sont désormais sur Github. Même PHP - le langage lui-même - est depuis peu passé au Git.
Désormais quand il manque quelque chose dans un projet que j’aime, je ne reste plus les bras croisés - je fork le projet (fait de créer une version séparée), fais mes modifications, et fais un simple pull request pour que mes modifications soient ajoutées automatiquement au projet si le développeur les trouve à son goût. Tout ça parfois en quelques heures – jamais les choses n’avaient été aussi vite.

A contrario quand désormais je tombe sur des projets intéressants qui n’utilisent aucun système public de version control, je ressens toujours une certaine impuissance. Trouvé un bug dans le code ? Envoyez un email et attendez. Envie de suggérer une amélioration ? Passez par les (parfois inexistants) forums et croisez les doigts pour que quelqu’un les lise.
De manière moindre ça me fait aussi un peu ça quand je tombe sur des ancêtres (Sourceforce) ou concurrents (Google Code, qui utilise SVN) de Github.

Oser faire le premier pas

Si vous n’avez jamais touché ni à Github ni à Google Code, essayez. Tout le monde a au moins un projet qui gagnerait à utiliser ces technologies. Et rappelez vous que dans version control il y a control.
De nos jours les pages de démarrage de Github se sont faites moins effrayantes, vous serez guidé pas par pas et tout devrait bien se passer.
Si git et svn restent des technologies qui favorisent la ligne de commande, sachez par ailleurs que de nombreuses interfaces existent, de Mac à Linux. Une bonne poignée est répertoriée sur la page GUI du site git, à l’exception de Github for Windows qui vient d’être lancé.

Si vous êtes un débutant, Github for Mac et Github for Windows (dans un très léché style Metro) sauront se prouver intuitives et vous accompagner dans vos premiers pas.
Si vous êtes plus expérimenté et avez besoin d’accéder à des fonctions plus poussées, Smartgit sur Windows et SourceTree (gratuit) ou Tower (payant) sur Mac seront là pour vous. Au niveau du svn je n’ai testé que Versions sur Mac mais en ai été très satistait.

Ces logiciels répondent tous à une peur de la ligne de commande qui éloigne beaucoup de gens de ces technologies, et c’est une perte grave car se couper d’une communauté aussi passionnée, rassemblée autour de l’open-source et des possibilités offertes, c’est effectivement se priver d’énormément de choses.

Conclusion

Quelques mois plus tard je comprends enfin la phrase de Rebecca et s’il n’y a qu’une chose que je puisse dire c’est que je ne pourrais être plus d’accord.
Les simples technologies citées dans l’article précédent : LESS, SASS, Compass, CoffeeScript, ou d’autres comme jQuery, Ruby on Rails — toutes sont sur Github, ouvertes à discussion, à amélioration.
J’ai récemment vu le développeur d’un plugin pour Compass me laisser les clés du projet car je le développais plus activement que lui.

Le web et les technologies qui l’entourent n’ont jamais avancé aussi vite. Là où avant le HTML et le CSS par exemple étaient des technologies fixes mises à jour toutes les X années, sont désormais devenus des langages mouvants. Des standards en constante évolution par la communauté (ça sera le sujet d’un prochain article).
Si vous voulez commencer à garder le rythme, mon meilleur conseil est de suivre ce qui vous passionne au plus près, à la source. Mon meilleur conseil, c’est de commencer par .

Note

Mon prochain article se portera sur le Responsive Design. De ses premières ébauches à la (re)découverte des Media Queries, jusqu’à son actuelle forme où les designs adaptatifs ont dans la plupart des cas supplantés les versions mobiles et consorts.

Je discute aussi beaucoup avec des développeurs étrangers et dans l’optique de mieux m’ouvrir à tous j’ouvrirai bientôt un blog compagnon à celui-ci où des versions anglaises de mes articles sur le webdesign seront postées. Ne vous étonnez-donc pas si je lie alors chaque article vers un blog externe, celui-ci reste mon blog principal.

LessCSS : mon coup de cœur du moment

Mercredi 21 décembre 2011

Je ne parle pas beaucoup de webdesign et de programmation sur mon blog. Pendant longtemps la raison a été que je ne me sentais pas forcément à l’aise avec ce que je faisais - pas assez au point par rapport aux nombreux standarts du web et à la qualité de ce qui se faisait ailleurs. Depuis le travail en agence m’a fait énormément progresser : moi qui n’avait à l’origine que quelques lointaines connaissances en PHP, ai désormais codé mon propre framework pour les sites qu’on me demande de faire. Avec gestion des templates, mise en cache des pages, code orienté SEO avec URL Rewriting et consorts, gestion du multilingue, admin intégrée etc. Le tout en OOP et conforme aux standars actuels du web (xHTML/HTML5/CSS3 et des touches de jQuery).

Le tout est plus formaté à mes propres besoins qu’à un usage public mais reste que depuis mon entrée dans le monde du travail, j’ai énormément progressé, principalement parce que je suis curieux et que j’adore apprendre sans cesse de nouvelles choses. Ma découverte du moment ? LessCSS.
Il n’est pas rare que dès que quelqu’un découvre ou redécouvre quelque chose de nouveau en webdesign, tout le monde s’emballe du jour au lendemain (voir le cas des CSS Media Queries). LessCss est à l’origine une extension Ruby qui propose d’enrichir le langage CSS via un panel de fonctions qui jusque là manquaient cruellement - le but étant de rendre le langage CSS plus flexible et lisible. Malgré son énorme potentiel (tout comme SASS, une extension CSS du même genre), la contrainte du langage Ruby a fait que le tout est jusqu’à peu resté dans l’ombre. Ce qui a changé il y a peu justement ? C’est que LessCSS est désormais proposé comme une script Javascript. Ça veut dire que concrètement tout ce qu’il y a à modifier dans son code c’est ça :

<link rel=”stylesheet/less” type=”text/css” href=”styles.less”>
<script src=”less.js” type=”text/javascript”></script>

Il suffit de changer l’extension de sa feuille de style par .less et de joindre le fichier en ligne LessCSS, et c’est tout. On a une extension CSS portative, facile à intégrer, et universelle. Mais qu’apporte concrètement LESS pour ceux qui ne connaissent pas ? Pour peu que vous ayez un peu de connaissances en CSS, voici un exemple de code LESS que vous devriez comprendre et qui vous donnera un aperçu de ce qu’on peut faire :

// Fonctions
.box-shadow (@x: 0, @y: 0, @blur: 1px, @alpha)
{
	@val: @x @y @blur rgba(0, 0, 0, @alpha);

	box-shadow:         @val;
	-webkit-box-shadow: @val;
	-moz-box-shadow:    @val;
}

// Mixins
.gras
{
	font-weight: 900;
	text-decoration: underline;
}

// Blocs principaux
div
{
	@base: #f938ab;

  	.gras;
  	color:        saturate(@base, 5%);
  	border-color: lighten(@base, 30%);

	a
	{
		text-decoration: none;

		&:hover { color: red; }
		&:active { color: blue; }
	}
	p.introduction
	{
		background-color: @base - #333;
		.box-shadow(0, 0, 5px, 0.4);

		strong { .gras }
	}
}

#header        { color: black;
  .navigation  { font-size: 12px }
  .logo        { width: 300px;
    &:hover    { text-decoration: none }
  }
}

Création de fonctions, de variables, de mixins (des propriétés que l’on pré-créer et ensuite réattribuer), mathématiques des couleurs, nesting des propriétés, et j’en passe. Le joli petit site officiel détaille mieux la chose que moi (et avec de la coloration de code surtout), toujours est-il qu’une fois qu’on y a goûté il est dur de s’en passer. Les possibilités sont vraiment nombreuses, comme par exemple cette grille dynamique en LESS.

La cerise sur le gâteau c’est - pour les soucieux de l’infime temps de calcul de LESS - les nombreux compileurs gratuits et multiplateformes qu’il existe, comme LESS.app qui vous demande un dossier de projet et qui ensuite compile des fichiers .css propres et valides en réel à mesure que vous travaillez sur vos .less. On a donc là une extension de langage qui peut-être à la fois vu comme une aide au code ou/et comme une extension matérialisant vos rêves les plus fous de design dynamique.
Je ne sais pas ce que vous allez en penser, peut-être des gens plus experimentés se prononceront-ils sur des défauts majeurs m’ayant échappés, mais pour l’instant LESS c’est mon petit coup de cœur et je ne suis pas seul.