Comment les concepteurs doivent-ils apprendre à coder ? Git, HTML/CSS, Principes d'ingénierie (Partie 2)

Littéralement, les tomes ont été écrits sur le contrôle de version. Néanmoins, je commencerai par partager une brève explication et d'autres contenus d'introduction pour aiguiser votre appétit pour une étude plus approfondie.

Le contrôle de version (à ne pas confondre avec l'historique des versions ) est essentiellement un moyen pour les personnes de collaborer dans leur propre environnement sur un seul projet, avec une seule source principale de vérité (souvent appelée la branche "maître").

Je vais passer en revue aujourd'hui le strict minimum que vous devez connaître pour télécharger un projet, apporter une modification, puis l'envoyer au maître.

Il existe de nombreux types de logiciels de contrôle de version et de nombreux outils pour gérer et héberger votre code source (vous avez peut-être entendu parler de GitLab ou de Bitbucket). Git et GitHub sont l'une des paires les plus courantes, mes exemples feront référence à GitHub mais les principes s'appliqueront à la plupart des autres gestionnaires de code source.

A part :

• Pour une introduction plus complète et technique, voir l'article de Tobias Gunther.
• Si vous préférez une approche plus pratique, GitHub propose un excellent guide étape par étape.

Votre première contribution

Avant de suivre ces étapes, vous devez configurer quelques éléments :

1. Un compte GitHub,
2. Node et NPM installés sur votre ordinateur,
3. Une tolérance élevée à la douleur ou un seuil bas pour demander de l'aide aux autres.

Étape 1 : Fork (Obtenez une copie du code sur votre compte GitHub)

Sur GitHub, vous allez forker (fork = créer une copie du code dans votre compte ; dans l'illustration suivante, les lignes bleues, orange, rouges et vertes montrent des fourches) le dépôt (dépôt) en question.

Pour ce faire, accédez au référentiel dans GitHub et cliquez sur le bouton "Fork", actuellement dans le coin supérieur droit d'un référentiel. Ce sera "l'origine" - votre fork sur votre compte GitHub.

Par exemple, la navigation vers https://github.com/yourGitHubUsername/liferay.design devrait afficher votre fork du référentiel Liferay.Design.

Étape 2 : Cloner (télécharger le code sur votre ordinateur)

Dans votre terminal, accédez à l'endroit où vous souhaitez stocker le code. Personnellement, j'ai un dossier /github dans mon dossier /user - cela me permet de l'organiser plus facilement de cette façon. Si vous souhaitez le faire, voici les étapes — après avoir tapé ces commandes dans votre fenêtre de terminal, appuyez sur la touche ↵ pour exécuter :

 cd ~/ ## you'll usually start in your root directory, but just in case you don't this will take you there mkdir github ## this creates a "github" folder — on OSX it will now be located at users/your-username/github cd github ## this command navigates you inside the github folder

Maintenant que vous êtes dans le dossier /github , vous allez cloner (télécharger une copie du code sur votre ordinateur) le dépôt.

 clone https://github.com/yourGitHubUsername/liferay.design

Une fois que vous avez entré cette commande, vous verrez un tas d'activités dans le terminal — quelque chose comme ceci :

 Cloning into 'liferay.design'... remote: Enumerating objects: 380, done. remote: Total 380 (delta 0), reused 0 (delta 0), pack-reused 380 Receiving objects: 100% (380/380), 789.24 KiB | 2.78 MiB/s, done. Resolving deltas: 100% (189/189), done.

Étape 3 : Installer (le faire fonctionner sur votre machine)

Naviguez dans le dossier /project . Dans ce cas, nous entrerons cd liferay.design . La plupart des projets incluront un fichier README.md dans le dossier /root , c'est généralement le point de départ pour l'installation et l'exécution du projet. Pour nos besoins, pour installer, entrez npm install . Une fois installé, entrez npm run dev .

Toutes nos félicitations! Vous avez maintenant le site disponible sur votre ordinateur local - généralement, les projets vous indiqueront où il s'exécute. Dans ce cas, ouvrez un navigateur et accédez à localhost:7777 .

Étape 4 : valider (apporter des modifications et les enregistrer)

Un commit est une collection de modifications que vous apportez ; J'ai entendu dire qu'il s'agissait de sauvegarder votre progression dans un jeu. Il existe de nombreuses opinions sur la façon dont les commits doivent être structurés : la mienne est que vous devez créer un commit lorsque vous avez réalisé une chose, et si vous supprimiez le commit, cela ne casserait pas complètement le projet (dans des limites raisonnables).

Si vous n'arrivez pas à un dépôt avec un changement d'avis, un bon endroit où aller est l'onglet "Problèmes". C'est là que vous pouvez voir ce qui doit être fait dans le projet.

Si vous avez une idée de changement, allez-y et faites-le. Une fois que vous avez enregistré le(s) fichier(s), voici les étapes nécessaires pour créer un commit :

 git status ## this will print out a list of files that you've made changes in git add path/to/folder/or/file.ext ## this will add the file or folder to the commit git commit -m 'Summarize the changes you've made' ## this command creates a commit and a commit message

Astuce : La meilleure recommandation que j'aie jamais vue pour les messages de validation provient de "How To Write A Git Commit Message" de Chris Breams. Une ligne d'objet de commit Git correctement formée doit toujours pouvoir compléter la phrase suivante : "Si appliqué, ce commit sera [votre ligne d'objet ici]." Pour plus d'informations sur les commits, consultez "Why I Create Atomic Commits In Git" par Clarice Bouwer.

Étape 5 : Poussez (Envoyez vos modifications à votre origine)

Une fois que vous avez apporté des modifications sur votre ordinateur, avant qu'elles ne puissent être fusionnées dans la branche principale (ajoutée au projet), elles doivent être déplacées de votre référentiel local vers votre référentiel distant. Pour ce faire, entrez git push origin dans la ligne de commande.

Étape 6 : Pull Request (Demandez à ce que vos modifications soient fusionnées en amont)

Maintenant que vos modifications sont passées de vos doigts à votre ordinateur, à votre référentiel distant, il est maintenant temps de demander qu'elles soient fusionnées dans le projet via une demande d'extraction (PR).

Pour ce faire, le moyen le plus simple consiste à accéder à la page de votre dépôt dans GitHub. Il y aura un petit message juste au-dessus de la fenêtre du fichier qui dit "Cette branche est X commits ahead repo-name:branch" puis des options pour "Pull request" ou "Comparer".

Cliquer sur l'option "Pull request" ici vous amènera à une page où vous pourrez comparer les modifications et un bouton qui dit "Créer une pull request" vous amènera ensuite à la page "Ouvrir une pull request" où vous ajouterez un titre et inclure un commentaire. Être bref, mais suffisamment détaillé dans le commentaire, aidera les mainteneurs du projet à comprendre les changements que vous proposez.

Il existe des outils CLI comme Node GH (GitHub a également récemment publié une version bêta de leur outil CLI) qui vous permettent d'initier et de gérer des demandes d'extraction dans le terminal. À ce stade, vous préférerez peut-être utiliser l'interface Web, et c'est tant mieux ! Moi aussi.

Étape bonus : à distance (lier tous les dépôts)

À ce stade, nous avons trois références de référentiel :

1. upstream : le dépôt principal que vous suivez, souvent c'est le dépôt que vous avez forké ;
2. origin : le nom par défaut de la télécommande que vous clonez ;
3. local : le code qui se trouve actuellement sur votre ordinateur.

Jusqu'à présent, vous avez #2 et #3 - mais #1 est important car c'est la source principale. Garder ces trois choses en ligne les unes avec les autres aidera l'historique de validation à rester propre. Cela aide les mainteneurs de projet car cela élimine (ou au moins minimise) les conflits de fusion lorsque vous envoyez des demandes d'extraction (PR) et cela vous aide à obtenir le dernier code et à maintenir à jour vos référentiels locaux et d'origine.

Définir une télécommande en amont

Pour suivre la télécommande en amont, dans votre terminal, entrez ce qui suit :

 git remote add upstream https://github.com/liferay-design/liferay.design

Maintenant, vérifiez les télécommandes dont vous disposez — entrez git remote -v dans votre terminal, vous devriez voir quelque chose comme :

 origin https://github.com/yourGitHubUsername/liferay.design (fetch) origin https://github.com/yourGitHubUsername/liferay.design (push) upstream https://github.com/liferay-design/liferay.design (fetch) upstream https://github.com/liferay-design/liferay.design (push)

Cela vous permettra d'obtenir rapidement la dernière version de ce qui est en amont - si vous n'avez pas travaillé dans un dépôt depuis longtemps et que vous n'avez pas de modifications locales que vous souhaitez conserver, c'est une commande pratique que j'utilise :

 git pull upstream master && git reset --hard upstream/master

L'aide de GitHub est une excellente ressource pour cela et pour de nombreuses autres questions que vous pourriez avoir.

HTML et CSS : commencer par la sémantique

Sur le Web, il existe une quantité infinie de ressources pour apprendre le HTML et le CSS. Aux fins de cet article, je partage ce que je recommanderais en fonction de les erreurs que j'ai faites comment j'ai appris à écrire HTML et CSS.

Qu'est-ce que le HTML et le CSS ?

Avant d'aller plus loin, définissons HTML et CSS.

HTML signifie langage de balisage hypertexte.

Hypertexte :

"L'hypertexte est un texte affiché sur un écran d'ordinateur ou d'autres appareils électroniques avec des références (hyperliens) à d'autres textes auxquels le lecteur peut accéder immédiatement."

— « Hypertexte » sur Wikipédia

Langage de balisage:

"... un système pour annoter un document d'une manière qui se distingue syntaxiquement du texte."

— "Langage de balisage" sur Wikipédia

Au cas où vous ne sauriez pas non plus ce que beaucoup de ces mots signifient - en bref, HTML est la combinaison de références (liens) entre des documents sur le Web et de balises que vous utilisez pour donner une structure à ces documents.

Pour une introduction approfondie au HTML et au CSS, je recommande fortement les premières étapes d'introduction au HTML et au CSS, toutes deux sur les documents Web du Mozilla Developer Network (MDN) . Cela, ainsi que les excellents articles fournis par des sites Web tels que CSS Tricks, 24 Ways et d'innombrables autres, contiennent essentiellement tout ce que vous aurez besoin de référencer en ce qui concerne HTML/CSS.

Il y a deux parties principales dans un document HTML : le <head> et le <body> . - Le <head> contient des éléments qui ne sont pas affichés par le navigateur - des métadonnées et des liens vers des feuilles de style et des scripts importés. - Le <body> contient le contenu réel qui sera rendu par le navigateur. Pour restituer le contenu, le navigateur lit le code HTML, fournit une couche de base de styles en fonction des types de balises utilisées, ajoute des couches supplémentaires de styles fournies par le site Web lui-même (les styles sont inclus/référencés à partir du <head> , ou sont en ligne), et c'est ce que nous voyons à la fin. (Remarque : il y a souvent aussi la couche supplémentaire de JavaScript, mais cela sort du cadre de cet article.)

CSS signifie Cascading Style Sheets - il est utilisé pour étendre le code HTML en facilitant la personnalisation des documents. Une feuille de style est un document qui indique au code HTML à quoi doivent ressembler les éléments (et comment ils doivent être positionnés) en définissant des règles basées sur des balises, des classes, des identifiants et d'autres sélecteurs. La mise en cascade fait référence à la méthode permettant de déterminer quelles règles d'une feuille sont prioritaires dans le cas inévitable d'un conflit de règles.

"'Cascading' signifie que les styles peuvent tomber (ou cascader) d'une feuille de style à une autre, permettant d'utiliser plusieurs feuilles de style sur un document HTML."

— Cascade — Conception maximale

CSS a souvent une mauvaise réputation - dans les sites avec beaucoup de feuilles de style, il peut rapidement devenir difficile à manier, surtout s'il n'y a pas de méthodes documentées et cohérentes utilisées (plus sur cela plus tard) - mais si vous l'utilisez de manière organisée et en suivant tout les meilleures pratiques, CSS peut être votre meilleur ami. Surtout avec les capacités de mise en page qui sont maintenant disponibles dans la plupart des navigateurs modernes, CSS n'est plus aussi nécessaire pour pirater et combattre qu'autrefois.

Rachel Andrew a écrit un excellent guide, How To Learn CSS — et l'une des meilleures choses à savoir avant de commencer est que :

"Vous n'avez pas besoin de vous engager à mémoriser chaque propriété et valeur CSS."

—Rachel Andrew

Au lieu de cela, il est bien plus vital d'apprendre les principes de base - les sélecteurs, l'héritage, le modèle de boîte et, surtout, comment déboguer votre code CSS (indice : vous aurez besoin des outils de développement du navigateur).

Ne vous inquiétez pas de la mémorisation de la syntaxe de la propriété background , et ne vous inquiétez pas si vous oubliez comment aligner exactement les éléments dans Flexbox (le CSS Tricks Guide to Flexbox est probablement l'une de mes 10 pages les plus visitées, jamais ! ); Google et Stack Overflow sont vos amis en matière de propriétés et de valeurs CSS.

Certains éditeurs de code ont même une saisie semi-automatique intégrée, vous n'avez même pas besoin de chercher sur le Web pour pouvoir comprendre toutes les propriétés possibles d'une bordure, par exemple.

L'une de mes nouvelles fonctionnalités préférées dans Firefox 70 est l'indicateur de règles CSS inactives. Cela vous fera gagner des heures à essayer de comprendre pourquoi un style n'est pas appliqué.

Sémantique

Commençons par le code sémantique . La sémantique fait référence à la signification des mots, le code sémantique fait référence à l'idée qu'il y a un sens au balisage dans une langue donnée.

Il existe de nombreuses raisons pour lesquelles la sémantique est importante. Si je pouvais résumer cela, je dirais que si vous apprenez et utilisez le code sémantique, cela vous facilitera la vie car vous obtiendrez beaucoup de choses gratuitement - et qui n'aime pas les choses gratuites ?

Pour une introduction plus complète au code sémantique, consultez le bref article de blog de Paul Boag sur le sujet.

La sémantique vous offre de nombreux avantages :

1. Styles par défaut
   Par exemple, l'utilisation d'une balise de titre <h1> pour le titre de votre document le fera ressortir du reste du contenu du document, un peu comme le ferait un titre.
2. Contenu accessible
   Votre code sera accessible par défaut, ce qui signifie qu'il fonctionnera avec les lecteurs d'écran et sera plus facile à naviguer avec un clavier.
3. Avantages du référencement
   Le balisage sémantique est plus facile à lire pour une machine, ce qui le rend plus accessible aux moteurs de recherche.
4. Avantages en termes de performances
   Clean HTML est la base d'un site performant. Et un HTML propre conduira probablement à un CSS plus propre, ce qui signifie moins de code dans l'ensemble, ce qui rendra votre site ou votre application plus rapide.

Remarque : Pour un examen plus approfondi de la sémantique et du HTML, Heydon Pickering a écrit "Sémantique structurelle : l'importance des éléments de sectionnement HTML5", que je recommande vivement de lire.

Principes et paradigmes d'ingénierie : les bases

Abstraction

Il y a des tonnes d'applications, de tangentes et de niveaux que nous pourrions explorer sur le concept d'abstraction - trop pour cet article qui est destiné à vous donner une brève introduction aux concepts afin que vous en soyez conscient au fur et à mesure que vous continuez à apprendre.

L'abstraction est un paradigme d'ingénierie fondamental avec une grande variété d'applications - pour les besoins de cet article, l'abstraction sépare la forme de la fonction. Nous l'appliquerons dans trois domaines : les jetons, les composants et le principe Ne vous répétez pas.

Jetons

Si vous avez utilisé un outil de conception moderne pendant un certain temps, vous avez probablement rencontré l'idée d'un token . Même Photoshop et Illustrator ont maintenant cette idée de styles partagés dans une bibliothèque centralisée - au lieu de coder en dur des valeurs dans une conception, vous utilisez un jeton. Si vous connaissez le concept des variables CSS ou SASS, vous connaissez déjà les jetons.

Une couche d'abstraction avec des jetons consiste à attribuer un nom à une couleur - par exemple, $blue-00 peut être mappé sur une valeur hexadécimale (ou une valeur HSL, ou tout ce que vous voulez) - disons #0B5FFF . Maintenant, au lieu d'utiliser la valeur hexadécimale dans vos feuilles de style, vous utilisez la valeur du jeton - de cette façon, si vous décidez que blue-00 est en fait #0B36CE , vous n'avez qu'à le changer à un seul endroit. C'est un joli concept.

Si vous prenez ce même paradigme d'abstraction et allez un peu plus loin, vous pouvez créer un jeton - et assigner une variable à une valeur fonctionnelle. Ceci est particulièrement utile si vous avez un système robuste et que vous souhaitez avoir différents thèmes au sein du système. Un exemple fonctionnel de ceci serait d'assigner une variable comme $primary-color et de la mapper à $blue-00 - vous pouvez donc maintenant créer un balisage et au lieu de faire référence au bleu, vous faites référence à une variable fonctionnelle. Si jamais vous souhaitez utiliser le même balisage, mais avec un style (thème) différent, il vous suffit de mapper $primary-color sur une nouvelle couleur, et votre balisage n'a pas du tout besoin de changer ! La magie!

Composants

Au cours des 3-4 dernières années, l'idée de composants et de composants est devenue plus pertinente et accessible aux concepteurs. Le concept de symboles (initié par Macromedia/Adobe Fireworks, développé plus tard par Sketch, puis porté au niveau supérieur par Figma et Framer), est désormais plus largement disponible dans la plupart des outils de conception (Adobe XD, InVision Studio, Webflow et de nombreux les autres). La composition, plus encore que les jetons, peut séparer la forme de quelque chose de sa fonction, ce qui contribue à améliorer à la fois la forme et la fonction.

L'un des premiers exemples les plus notables est le composant d'objet multimédia de Nicole Sullivan. À première vue, vous ne réalisez peut-être pas qu'une page entière est essentiellement composée d'un seul composant, rendu de différentes manières. De cette façon, nous pouvons réutiliser le même balisage (formulaire), en le modifiant légèrement en passant des options ou des paramètres et des styles - et lui faire fournir une variété de valeurs (fonction).

Ne vous répétez pas

DRY (Don't Repeat Yourself) est l'un de mes principes préférés - créer des choses qui peuvent être réutilisées encore et encore est l'une des petites victoires que vous pouvez avoir lors du codage.

Bien que vous ne puissiez souvent pas (et sans doute ne devriez pas) vous efforcer d'appliquer le principe DRY 100 % du temps, à chaque fois - il est au moins avantageux d'en être conscient afin que, pendant que vous travaillez, vous puissiez réfléchir à la façon dont vous peut rendre tout ce sur quoi vous travaillez plus réutilisable.

Une note sur la règle de trois : un corollaire du principe DRY est la règle de trois — essentiellement, une fois que vous réutilisez (copiez/collez) quelque chose trois fois, vous devez le réécrire dans un composant réutilisable. Comme le code du pirate, il s'agit plus d'une ligne directrice que d'une règle stricte et rapide, et peut varier d'un composant à l'autre et d'un projet à l'autre.

Méthodologies CSS et de style : atomique ou BEM

Il existe de nombreuses façons différentes d'organiser et d'écrire du code CSS - Atomic et BEM ne sont que deux des nombreuses que vous êtes susceptible de rencontrer. Vous n'avez pas à en "choisir" un seul, ni à les suivre exactement. La plupart des équipes avec lesquelles j'ai travaillé ont généralement leur propre mélange unique, basé sur le projet ou la technologie. Il est utile de les connaître afin qu'au fil du temps, vous puissiez apprendre quelle approche adopter en fonction de la situation.

Toutes ces approches vont au-delà du "simple" CSS et du style, et peuvent souvent influencer les outils que vous utilisez, la façon dont vous organisez vos fichiers et potentiellement le balisage.

CSS atomique

À ne pas confondre avec Atomic Web Design - le CSS atomique (peut-être plus justement appelé «fonctionnel») est une méthodologie qui favorise essentiellement l'utilisation de petites classes à usage unique pour définir des fonctions visuelles. Quelques bibliothèques notables :

1. CSS atomique par Steve Carlson ;
2. Tachyons d'Adam Morse;
3. CSS Tailwind par Adam Wathan.

Ce que j'aime dans cette méthode, c'est qu'elle vous permet de styliser et de thématiser rapidement les choses - l'un des plus gros inconvénients est que votre balisage peut devenir assez encombré, assez rapidement.

Consultez l'article de John Polacek sur les astuces CSS pour une introduction complète à Atomic CSS.

BEM

La philosophie BEM est un excellent précurseur de nombreux frameworks JavaScript modernes tels que Angular, React et Vue.

"BEM (Block, Element, Modifier) ​​est une approche basée sur les composants pour le développement Web."

— BEM : Démarrage rapide

Fondamentalement, tout ce qui peut être réutilisé est un bloc. Les blocs sont composés d'éléments, quelque chose qui ne peut pas être utilisé en dehors d'un bloc, et potentiellement d'autres blocs. Les modificateurs sont des éléments qui décrivent l'état de quelque chose ou son apparence ou son comportement.

Personnellement, j'aime la théorie et la philosophie de BEM. Ce que je n'aime pas, c'est la façon dont les choses sont nommées. Beaucoup trop de traits de soulignement, de traits d'union, et cela peut sembler inutilement répétitif ( .menu , .menu__item , etc.).

Lecture recommandée : BEM For Beginners écrit par Inna Belaya

Merci, Suivant (.js)

Après avoir suffisamment maîtrisé ces sujets, ne vous inquiétez pas, il reste encore beaucoup à apprendre. Quelques suggestions:

1. Programmation fonctionnelle et orientée objet
   Nous l'avons abordé légèrement, mais il y a beaucoup plus à apprendre au-delà du CSS.
2. Langages et frameworks de haut niveau
   Typescript, Ruby, React, Vue sont les prochaines choses que vous aborderez une fois que vous aurez une bonne maîtrise du HTML et du CSS.
3. Interroger les langages et utiliser les données
   En savoir plus sur les API GraphQL, MySQL et REST fera passer votre capacité de codage au niveau supérieur.

Conclusion : les concepteurs qui codent != les ingénieurs logiciels

J'espère que cet article vous a montré qu'apprendre à coder n'est pas aussi difficile que vous ne le pensiez peut-être auparavant. Cela peut prendre beaucoup de temps, mais la quantité de ressources disponibles sur Internet est stupéfiante, et elles ne diminuent pas, bien au contraire !

Un point important sur lequel je tiens à souligner est que le « codage » n'est pas la même chose que le « génie logiciel » - être capable de bifurquer un référentiel et de copier/coller du code à partir de Stack Overflow peut vous mener loin, et bien que la plupart, si tous les ingénieurs en logiciel que je connais n'ont pas fait cela - vous devez utiliser vos nouvelles compétences avec sagesse et humilité. Pour tout ce que vous pouvez maintenant accéder avec quelques prouesses en ingénierie, il y a bien plus que vous ne savez pas. Bien que vous puissiez penser qu'une fonctionnalité ou un style est facile à réaliser parce que - "Hé, je l'ai fait fonctionner dans devtools!" ou "Je l'ai fait fonctionner dans Codepen." - il existe de nombreux processus d'ingénierie, dépendances et méthodes que vous ne connaissez probablement pas.

Tout cela pour dire — n'oubliez pas que nous sommes toujours des designers. Notre fonction principale est d'ajouter de la valeur commerciale en comprenant les problèmes des clients ou des utilisateurs et en les synthétisant avec notre connaissance des modèles de conception, des méthodes et des processus. Oui, être un "designer qui écrit du code" peut être très utile et augmentera votre capacité à ajouter cette valeur - mais nous devons toujours laisser les ingénieurs prendre les décisions d'ingénierie.

Quelque chose ne va pas ?

Il y a de fortes chances que quelque chose dans ce post soit obscur, obtus et/ou obsolète et j'aimerais avoir l'opportunité de l'améliorer ! S'il vous plaît laissez un commentaire ci-dessous, DM moi, ou @mentionnez-moi sur Twitter afin que je puisse m'améliorer.

Lectures complémentaires

1. Coding Bootcamps vs diplômes en informatique : ce que veulent les employeurs et autres perspectives (Kyle Thayer)
2. Comment commencer à utiliser Sketch And Framer X (par Martina Perez, Smashing Magazine )
3. Introduction aux commandes Linux (par Paul Tero, Smashing Magazine )
4. Devenez un utilisateur avancé de la ligne de commande avec Oh My ZSH et Z (par Wes Bos, Smashing Magazine )
5. Une liste des commandes communes cmd.exe et Unix que vous pouvez utiliser dans PowerShell ( Microsoft Docs )
6. expressions-régulières.info (par Jan Goyvaerts)
7. regexone.com (apprenez les expressions régulières avec des exercices interactifs simples)
8. Redimensionnement par lots à l'aide de la ligne de commande et d'ImageMagick (par Vlad Gerasimov, Smashing Magazine )
9. Raccourcis et astuces pour améliorer votre productivité avec Sublime Text (par Jai Pandya, Smashing Magazine )
10. Le code Visual Studio peut-il faire cela ? (par Burke Holland, Smashing Magazine )
11. Pourquoi l'historique des versions n'est pas un contrôle de version (par Josh Brewer)
12. Contrôle de version moderne avec Git (par Tobias Gunther, Smashing Magazine )
13. "Hello World" (un guide étape par étape GitHub)
14. Comment installer Node.js et NPM sur un Mac (par Dave McFarland)
15. Comment installer Node.js et NPM sur Windows (par Dejan Tucakov)
16. Pourquoi je crée des commits atomiques dans Git (par Clarice Bouwer)
17. Comment écrire un message de validation Git (par Chris Breams)
18. Code sémantique : Quoi ? Pourquoi? Comment? (par Paul Boag)
19. Sémantique structurelle : l'importance des éléments de sectionnement HTML5 (par Heydon Pickering, Smashing Magazine )
20. Concevoir pour la performance : Chapitre 4. Optimiser le balisage et les styles (par Lara C. Hogan, O'Reilly Media )
21. L'objet média enregistre des centaines de lignes de code (par Nicole Sullivan)
22. Définissons exactement ce qu'est le CSS atomique (par John Polacek, CSS Tricks )
23. BEM pour les débutants : pourquoi vous avez besoin de BEM (par Inna Belaya, Smashing Magazine )
24. Javascript pour les chats : une introduction pour les nouveaux programmeurs
25. Roadmap.sh : Développeur Frontend
26. Programmation fonctionnelle vs OOPS : Expliquez comme si j'avais cinq ans
27. Pourquoi, comment et quand utiliser le HTML sémantique et ARIA (par Adam Silver, CSS Tricks )
28. Sémantique HTML (un livre électronique de Smashing Magazine )
29. Les Fondamentaux - HTML + CSS (sur Syntax.fm )
30. Cascade et héritage ( westciv.com )
31. Astuces CSS (par Chris Coyier)
32. Premiers pas avec la mise en page CSS (par Rachel Andrew, Smashing Magazine )
33. Introduction au HTML (docs Web MDN)
34. Premiers pas CSS (docs Web MDN)
35. Premiers pas JavaScript (docs Web MDN)
36. 24 façons (par Drew McLellan)