In che modo i designer dovrebbero imparare a programmare? Git, HTML/CSS, Principi di ingegneria (Parte 2)

Letteralmente, i tomi sono stati scritti sul controllo della versione. Tuttavia, inizierò condividendo una breve spiegazione e altri contenuti introduttivi per stuzzicare il tuo appetito per ulteriori studi.

Il controllo della versione (da non confondere con la cronologia delle versioni ) è fondamentalmente un modo per le persone di collaborare nei propri ambienti su un singolo progetto, con un'unica fonte di verità principale (spesso chiamata ramo "master").

Esaminerò oggi è il minimo indispensabile che devi sapere per scaricare un progetto, apportare una modifica e quindi inviarlo al master.

Esistono molti tipi di software di controllo della versione e molti strumenti per la gestione e l'hosting del codice sorgente (potresti aver sentito parlare di GitLab o Bitbucket). Git e GitHub sono una delle coppie più comuni, i miei esempi faranno riferimento a GitHub ma i principi si applicheranno alla maggior parte degli altri gestori di codice sorgente.

A parte :

• Per un'introduzione più completa e tecnica, vedere l'articolo di Tobias Gunther.
• Se preferisci un approccio più pratico, GitHub ha un'eccellente guida passo passo.

Il tuo primo contributo

Prima di eseguire questi passaggi, avrai bisogno di alcune cose impostate:

1. Un account GitHub,
2. Nodo e NPM installati sul tuo computer,
3. Un'elevata tolleranza al dolore o una soglia bassa per chiedere aiuto agli altri.

Passaggio 1: fork (ottenere una copia del codice sul tuo account GitHub)

Su GitHub, esegui il fork (fork = crea una copia del codice nel tuo account; nell'illustrazione seguente, le linee blu, arancione, rossa e verde mostrano i fork) del repository (repo) in questione.

Puoi farlo andando al repository in GitHub e facendo clic sul pulsante "Fork", attualmente nell'angolo in alto a destra di un repository. Questa sarà l '"origine": il tuo fork sul tuo account GitHub.

Ad esempio, la navigazione su https://github.com/yourGitHubUsername/liferay.design dovrebbe mostrare il fork del repository Liferay.Design.

Passaggio 2: clona (scarica il codice sul tuo computer)

Nel tuo terminale, vai al punto in cui desideri memorizzare il codice. Personalmente, ho una cartella /github nella mia cartella /user : mi è più facile organizzarla in questo modo. Se desideri farlo, ecco i passaggi: dopo aver digitato questi comandi nella finestra del terminale, premi il tasto ↵ per eseguire:

 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

Ora che sei nella cartella /github , clonerai (scarica una copia del codice sul tuo computer) il repository.

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

Una volta inserito questo comando, vedrai un sacco di attività nel terminale, qualcosa del genere:

 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.

Passaggio 3: installa (fai funzionare sul tuo computer)

Naviga nella cartella /project . In questo caso, inseriremo cd liferay.design . La maggior parte dei progetti includerà un file README.md nella cartella /root , questo è in genere il punto di partenza per l'installazione e l'esecuzione del progetto. Per i nostri scopi, per installare, immettere npm install . Una volta installato, inserisci npm run dev .

Congratulazioni! Ora hai il sito disponibile sul tuo computer locale: in genere i progetti ti diranno dove è in esecuzione. In questo caso, apri un browser e vai su localhost:7777 .

Passaggio 4: conferma (apporta alcune modifiche e salvale)

Un commit è una raccolta di modifiche apportate; Ho sentito che è stato descritto come salvare i tuoi progressi in un gioco. Ci sono molte opinioni su come dovrebbero essere strutturati i commit: la mia è che dovresti creare un commit quando hai ottenuto una cosa, e se dovessi rimuovere il commit, non interromperebbe completamente il progetto (entro limiti ragionevoli).

Se non stai arrivando a un repository con un cambiamento in mente, un buon posto dove andare è la scheda "Problemi". Qui è dove puoi vedere cosa deve essere fatto nel progetto.

Se hai un'idea per qualche cambiamento, vai avanti e falla. Dopo aver salvato i file, ecco i passaggi necessari per creare 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

Suggerimento : la migliore raccomandazione che abbia mai visto per i messaggi di commit è da "Come scrivere un messaggio di commit Git" di Chris Breams. Una riga dell'oggetto del commit Git correttamente formata dovrebbe sempre essere in grado di completare la seguente frase: "Se applicata, questo commit sarà [la riga dell'oggetto qui]." Per ulteriori informazioni sui commit, controlla "Why I Create Atomic Commits In Git" di Clarice Bouwer.

Passaggio 5: push (invia le modifiche alla tua origine)

Dopo aver apportato alcune modifiche al tuo computer, prima che possano essere unite nel ramo principale (aggiunto al progetto), devono essere spostate dal tuo repository locale al tuo repository remoto. Per fare ciò, inserisci git push origin nella riga di comando.

Passaggio 6: richiesta pull (richiedi che le modifiche vengano unite nell'upstream)

Ora che le modifiche sono passate dalle dita al computer, al repository remoto, è giunto il momento di chiedere che vengano unite al progetto tramite una richiesta pull (PR).

Il modo più semplice per farlo è andare alla pagina del tuo repository in GitHub. Ci sarà un piccolo messaggio proprio sopra la finestra del file che dice "Questo ramo è X commit in anticipo repo-name: branch" e quindi le opzioni "Pull request" o "Confronta".

Facendo clic sull'opzione "Richiesta pull" qui ti porterà a una pagina in cui puoi confrontare le modifiche e un pulsante che dice "Crea richiesta pull" ti porterà alla pagina "Apri una richiesta pull" dove aggiungerai un titolo e includi un commento. Essere brevi, ma sufficientemente dettagliati nel commento, aiuterà i manutentori del progetto a comprendere le modifiche proposte.

Esistono strumenti CLI come Node GH (GitHub ha anche recentemente rilasciato una versione beta del loro strumento CLI) che consentono di avviare e gestire richieste pull nel terminale. A questo punto potresti preferire usare l'interfaccia web, ed è fantastico! Anche io.

Bonus Step: Remoto (collega tutti i repository)

A questo punto, abbiamo tre riferimenti al repository:

1. upstream : il repository principale che stai monitorando, spesso è il repository che hai forkato;
2. origin : il nome predefinito del telecomando che cloni;
3. local : il codice che è attualmente sul tuo computer.

Finora, hai il numero 2 e il numero 3, ma il numero 1 è importante perché è la fonte primaria. Mantenere queste tre cose in linea l'una con l'altra aiuterà la cronologia dei commit a rimanere pulita. Questo aiuta i manutentori del progetto in quanto elimina (o almeno riduce al minimo) i conflitti di unione quando invii richieste pull (PR) e ti aiuta a ottenere il codice più recente e mantenere aggiornati i repository locali e di origine.

Imposta un telecomando a monte

Per tracciare il telecomando a monte, nel tuo terminale inserisci quanto segue:

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

Ora controlla per vedere quali telecomandi hai a disposizione: inserisci git remote -v nel tuo terminale, dovresti vedere qualcosa come:

 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)

Ciò ti consentirà di ottenere rapidamente l'ultima versione di ciò che è a monte: se non lavori in un repository da molto tempo e non hai modifiche locali che desideri mantenere, questo è un comando utile che uso :

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

GitHub Help è un'ottima risorsa per questa e molte altre domande che potresti avere.

HTML e CSS: a partire dalla semantica

Sul web c'è una scorta infinita di risorse per l'apprendimento di HTML e CSS. Ai fini di questo articolo, sto condividendo ciò su cui consiglierei in base gli errori che ho fatto come ho imparato a scrivere HTML e CSS.

Cosa sono HTML e CSS?

Prima di andare oltre, definiamo HTML e CSS.

HTML sta per HyperText Markup Language.

Ipertesto:

"L'ipertesto è testo visualizzato sul display di un computer o altri dispositivi elettronici con riferimenti (collegamenti ipertestuali) ad altro testo a cui il lettore può accedere immediatamente."

— "Ipertesto" su Wikipedia

Linguaggio con marcatori:

"... un sistema per annotare un documento in modo sintatticamente distinguibile dal testo."

— "Lingua di marcatura" su Wikipedia

Nel caso in cui anche tu non sappia cosa significano molte di queste parole, in breve, HTML è la combinazione di riferimenti (collegamenti) tra documenti sul Web e tag che usi per dare struttura a quei documenti.

Per un'introduzione completa all'HTML e ai CSS, consiglio vivamente i primi passi dell'Introduzione all'HTML e ai CSS, entrambi sui documenti web di Mozilla Developer Network (MDN) . Che, insieme agli eccellenti articoli forniti da siti Web come CSS Tricks, 24 Ways e innumerevoli altri, contengono praticamente tutto ciò di cui avrai bisogno per fare riferimento per quanto riguarda HTML/CSS.

Ci sono due parti principali di un documento HTML : <head> e <body> . - Il <head> contiene elementi che non vengono visualizzati dal browser: metadati e collegamenti a fogli di stile e script importati. - Il <body> contiene il contenuto effettivo che verrà visualizzato dal browser. Per rendere il contenuto, il browser legge l'HTML, fornisce un livello base di stili a seconda dei tipi di tag utilizzati, aggiunge livelli aggiuntivi di stili forniti dal sito web stesso (gli stili sono inclusi/riferiti dal <head> , oppure sono in linea), ed è quello che vediamo alla fine. (Nota: spesso c'è anche il livello aggiuntivo di JavaScript, ma non rientra nell'ambito di questo articolo.)

CSS sta per Cascading Style Sheets: viene utilizzato per estendere l'HTML rendendo più semplice dare ai documenti un aspetto personalizzato. Un foglio di stile è un documento che dice all'HTML come dovrebbero apparire gli elementi (e come dovrebbero essere posizionati) impostando regole basate su tag, classi, ID e altri selettori. La cascata si riferisce al metodo per determinare quali regole in un foglio hanno la priorità nell'inevitabile caso di un conflitto di regole.

"'Cascading' significa che gli stili possono cadere (o sovrapporsi) da un foglio di stile all'altro, consentendo l'utilizzo di più fogli di stile su un documento HTML."

— Cascata — Max Design

I CSS hanno spesso una cattiva reputazione - nei siti con molti fogli di stile possono diventare rapidamente ingombranti, specialmente se non vengono utilizzati metodi documentati e coerenti (ne parleremo più avanti) - ma se lo usi in modo organizzato e seguendo tutto le migliori pratiche, CSS può essere il tuo migliore amico. Soprattutto con le capacità di layout che sono ora disponibili nella maggior parte dei browser moderni, CSS non è così necessario per hackerare e combattere come una volta.

Rachel Andrew ha scritto un'ottima guida, How To Learn CSS, e una delle cose migliori da sapere prima di iniziare è che:

"Non è necessario impegnarsi a memorizzare ogni proprietà e valore CSS."

— Rachele Andrea

Invece, è molto più importante imparare i fondamenti : selettori, ereditarietà, il modello box e, soprattutto, come eseguire il debug del codice CSS (suggerimento: avrai bisogno degli strumenti di sviluppo del browser).

Non preoccuparti di memorizzare la sintassi per la proprietà background e non preoccuparti se dimentichi come allineare esattamente le cose in Flexbox (la CSS Tricks Guide to Flexbox è forse una delle mie prime 10 pagine più visitate di sempre! ); Google e Stack Overflow sono tuoi amici quando si tratta di proprietà e valori CSS.

Alcuni editor di codice hanno anche il completamento automatico integrato, quindi non è nemmeno necessario cercare sul Web per poter capire tutte le possibili proprietà di un confine, ad esempio.

Una delle mie nuove funzionalità preferite in Firefox 70 è l'indicatore delle regole CSS inattive. Ti farà risparmiare ore di tempo cercando di capire perché uno stile non viene applicato.

Semantica

Cominciamo con il codice semantico . La semantica si riferisce ai significati delle parole, il codice semantico si riferisce all'idea che ci sia un significato nel markup in una determinata lingua.

Ci sono molte ragioni per cui la semantica è importante. Se potessi riassumere questo, direi che se impari e usi il codice semantico, ti semplificherà la vita perché otterrai molte cose gratuitamente - e a chi non piacciono le cose gratuite?

Per un'introduzione più completa al codice semantico, vedere il breve post sul blog di Paul Boag sull'argomento.

La semantica ti offre molti vantaggi:

1. Stili predefiniti
   Ad esempio, l'utilizzo di un tag titolo <h1> per il titolo del documento lo farà risaltare dal resto del contenuto del documento, proprio come farebbe un titolo.
2. Contenuti accessibili
   Il tuo codice sarà accessibile per impostazione predefinita, il che significa che funzionerà con le utilità per la lettura dello schermo e sarà più facile navigare con una tastiera.
3. Vantaggi SEO
   Il markup semantico è più facile da leggere per una macchina, il che lo rende più accessibile ai motori di ricerca.
4. Vantaggi in termini di prestazioni
   Clean HTML è la base per un sito ad alte prestazioni. E l'HTML pulito probabilmente porterà anche a CSS più puliti, il che significa meno codice in generale, rendendo il tuo sito o la tua app più veloci.

Nota: per uno sguardo più approfondito alla semantica e all'HTML, Heydon Pickering ha scritto "Structural Semantics: The Importance Of HTML5 Sectioning Elements" che consiglio vivamente di leggere.

Principi e paradigmi ingegneristici: le basi

Astrazione

Ci sono tonnellate di applicazioni, tangenti e livelli che potremmo esplorare sul concetto di astrazione, troppi per questo articolo che ha lo scopo di darti una breve introduzione ai concetti in modo che tu ne sia consapevole mentre continui ad imparare.

L'astrazione è un paradigma ingegneristico fondamentale con un'ampia varietà di applicazioni: ai fini di questo articolo, l'astrazione separa la forma dalla funzione. Lo applicheremo in tre aree: token, componenti e principio di non ripetere te stesso.

Token

Se hai utilizzato uno strumento di progettazione moderno per un certo periodo di tempo, probabilmente ti sei imbattuto nell'idea di un token . Anche Photoshop e Illustrator ora hanno questa idea di stili condivisi in una libreria centralizzata: invece di codificare i valori in un progetto, usi un token. Se hai familiarità con il concetto di variabili CSS o SASS, hai già familiarità con i token.

Un livello di astrazione con i token consiste nell'assegnare un nome a un colore, ad esempio $blue-00 può essere mappato su un valore esadecimale (o un valore HSL, o qualunque cosa tu voglia), diciamo #0B5FFF . Ora, invece di usare il valore esadecimale nei tuoi fogli di stile, usi il valore del token, in questo modo se decidi che blue-00 è in realtà #0B36CE , devi solo cambiarlo in un unico posto. Questo è un bel concetto.

Se prendi questo stesso paradigma di astrazione e vai un livello oltre, puoi token-ception - e assegnare una variabile a un valore funzionale. Ciò è particolarmente utile se si dispone di un sistema robusto e si desidera avere temi diversi all'interno del sistema. Un esempio funzionale di questo sarebbe assegnare una variabile come $primary-color e mapparla a $blue-00 , quindi ora puoi creare markup e invece di fare riferimento al blu, stai facendo riferimento a una variabile funzionale. Se vuoi usare lo stesso markup, ma con uno stile (tema) diverso, devi solo mappare $primary-color su un nuovo colore e il tuo markup non deve cambiare affatto! Magia!

Componenti

Negli ultimi 3-4 anni, l'idea di componenti e componentizzazione è diventata più rilevante e accessibile ai progettisti. Il concetto di simboli (preparato da Macromedia/Adobe Fireworks, successivamente ampliato da Sketch e poi portato al livello successivo da Figma e Framer), è ora più ampiamente disponibile nella maggior parte degli strumenti di progettazione (Adobe XD, InVision Studio, Webflow e molti altri altri). La componentizzazione, ancor più dei token, può separare la forma di qualcosa dalla funzione di esso, il che aiuta a migliorare sia la forma che la funzione.

Uno dei primi esempi più notevoli è il componente dell'oggetto multimediale di Nicole Sullivan. A prima vista potresti non renderti conto che un'intera pagina è essenzialmente composta da un unico componente, reso in modi diversi. In questo modo, possiamo riutilizzare lo stesso markup (modulo), modificandolo leggermente passando opzioni o parametri e stili, e fare in modo che fornisca una varietà di valori (funzioni).

Non ripetere te stesso

DRY (Don't Repeat Yourself) è uno dei miei principi preferiti: creare cose che possono essere riutilizzate più e più volte è una delle piccole vittorie che puoi ottenere durante la codifica.

Anche se spesso non puoi (e probabilmente non dovresti) sforzarti di applicare il principio DRY il 100% delle volte, ogni volta - è almeno utile esserne consapevoli in modo che mentre lavori, puoi considerare come può rendere tutto ciò su cui stai lavorando più riutilizzabile.

Una nota sulla regola del tre: un corollario al principio DRY è la regola del tre — essenzialmente, una volta riutilizzato (copia/incolla) qualcosa tre volte, dovresti riscriverlo in un componente riutilizzabile. Come il Codice dei pirati, è più una linea guida che una regola ferrea e può variare da componente a componente e da progetto a progetto.

CSS e metodologie di styling: atomico vs. BEM

Esistono molti modi diversi per organizzare e scrivere codice CSS: Atomic e BEM sono solo due dei tanti che probabilmente incontrerai. Non devi “sceglierne uno” né seguirli esattamente. La maggior parte dei team con cui ho lavorato di solito ha la propria miscela unica, basata sul progetto o sulla tecnologia. È utile conoscerli in modo che nel tempo tu possa imparare quale approccio adottare a seconda della situazione.

Tutti questi approcci vanno oltre il "solo" CSS e lo stile e spesso possono influenzare gli strumenti che usi, il modo in cui organizzi i tuoi file e potenzialmente il markup.

CSS atomico

Da non confondere con Atomic Web Design: i CSS atomici (forse più giustamente indicati come "funzionali") sono una metodologia che essenzialmente favorisce l'utilizzo di classi piccole e univalenti per definire funzioni visive. Alcune biblioteche degne di nota:

1. CSS atomico di Steve Carlson;
2. Tachioni di Adam Morse;
3. Tailwind CSS di Adam Wathan.

Quello che mi piace di questo metodo è che ti permette di dare uno stile e un tema rapidamente alle cose: uno dei maggiori svantaggi è che il tuo markup può diventare piuttosto disordinato, abbastanza velocemente.

Consulta l'articolo di John Polacek sui trucchi CSS per un'introduzione completa all'Atomic CSS.

BEM

La filosofia BEM è un ottimo precursore di molti dei moderni framework JavaScript come Angular, React e Vue.

"BEM (Block, Element, Modifier) ​​è un approccio allo sviluppo web basato su componenti."

— BEM: avvio rapido

Fondamentalmente, tutto ciò che può essere riutilizzato è un blocco. I blocchi sono costituiti da elementi, qualcosa che non può essere utilizzato al di fuori di un blocco e potenzialmente altri blocchi. I modificatori sono cose che descrivono lo stato di qualcosa o il modo in cui appare o si comporta.

Personalmente, mi piace la teoria e la filosofia del BEM. Quello che non mi piace è il modo in cui le cose sono nominate. Troppi trattini bassi, trattini e può sembrare inutilmente ripetitivo ( .menu__item .menu ecc.).

Bibliografia consigliata : BEM For Beginners scritto da Inna Belaya

Grazie, Avanti (.js)

Dopo aver padroneggiato a sufficienza questi argomenti, non preoccuparti, c'è ancora molto da imparare. Alcuni suggerimenti:

1. Programmazione funzionale e orientata agli oggetti
   L'abbiamo toccato leggermente, ma c'è molto altro da imparare oltre i CSS.
2. Linguaggi e framework di livello superiore
   Typescript, Ruby, React, Vue sono le prossime cose che affronterai una volta che avrai una buona conoscenza di HTML e CSS.
3. Interrogazione di linguaggi e utilizzo dei dati
   L'apprendimento di GraphQL, MySQL e API REST porterà le tue capacità di codifica a un livello superiore.

Conclusione: progettisti che codificano! = Ingegneri del software

Si spera che questo articolo ti abbia mostrato che imparare a programmare non è così difficile come potresti aver pensato in precedenza. Può richiedere molto tempo, ma la quantità di risorse disponibili su Internet è sbalorditiva e non stanno diminuendo, anzi!

Un punto significativo che voglio sottolineare è che "codifica" non è la stessa cosa di "ingegneria del software": essere in grado di eseguire il fork di un repository e copiare/incollare il codice da Stack Overflow può farti fare molta strada, e mentre la maggior parte, se non tutti, gli ingegneri del software che conosco lo hanno fatto: devi usare le tue nuove abilità con saggezza e umiltà. Per tutto ciò a cui ora puoi accedere con una certa abilità ingegneristica, c'è molto di più che non sai. Anche se potresti pensare che una funzionalità o uno stile sia facile da realizzare perché: "Ehi, l'ho fatto funzionare in devtools!" o "L'ho fatto funzionare in Codepen". — ci sono molti processi ingegneristici, dipendenze e metodi che probabilmente non sai di non conoscere.

Tutto questo per dire: non dimenticare che siamo ancora designer. La nostra funzione principale è aggiungere valore aziendale attraverso l'obiettivo di comprendere i problemi dei clienti o degli utenti e di sintetizzarli con la nostra conoscenza di modelli, metodi e processi di progettazione. Sì, essere un "progettista che scrive codice" può essere molto utile e amplierà la tua capacità di aggiungere questo valore, ma dobbiamo comunque lasciare che gli ingegneri prendano le decisioni ingegneristiche.

Qualcosa che non va?

Ci sono buone probabilità che qualcosa in questo post fosse oscuro, ottuso e/o obsoleto e mi piacerebbe avere l'opportunità di migliorarlo! Si prega di lasciare un commento qui sotto, DM me o @menzionami su Twitter così posso migliorare.

Ulteriori letture

1. Bootcamp di codifica e lauree in informatica: cosa vogliono i datori di lavoro e altre prospettive (Kyle Thayer)
2. Come iniziare a utilizzare Sketch e Framer X (di Martina Perez, Smashing Magazine )
3. Introduzione ai comandi di Linux (di Paul Tero, Smashing Magazine )
4. Diventa un utente esperto della riga di comando con Oh My ZSH e Z (di Wes Bos, Smashing Magazine )
5. Un elenco dei comandi comuni cmd.exe e Unix che puoi usare in PowerShell ( Microsoft Docs )
6. regular-expressions.info (di Jan Goyvaerts)
7. regexone.com (impara le espressioni regolari con semplici esercizi interattivi)
8. Ridimensionamento batch utilizzando Command Line e ImageMagick (di Vlad Gerasimov, Smashing Magazine )
9. Scorciatoie e suggerimenti per migliorare la tua produttività con un testo sublime (di Jai Pandya, Smashing Magazine )
10. Il codice di Visual Studio può farlo? (di Burke Holland, Smashing Magazine )
11. Perché la cronologia delle versioni non è il controllo della versione (di Josh Brewer)
12. Controllo della versione moderna con Git (di Tobias Gunther, Smashing Magazine )
13. "Hello World" (una guida passo passo su GitHub)
14. Come installare Node.js e NPM su un Mac (di Dave McFarland)
15. Come installare Node.js e NPM su Windows (di Dejan Tucakov)
16. Perché creo commit atomici in Git (di Clarice Bouwer)
17. Come scrivere un messaggio Git Commit (di Chris Breams)
18. Codice semantico: cosa? Come mai? Come? (di Paolo Boag)
19. Semantica strutturale: l'importanza degli elementi di sezionamento HTML5 (di Heydon Pickering, Smashing Magazine )
20. Progettare per le prestazioni: Capitolo 4. Ottimizzazione del markup e degli stili (di Lara C. Hogan, O'Reilly Media )
21. L'oggetto multimediale salva centinaia di righe di codice (di Nicole Sullivan)
22. Definiamo esattamente cos'è Atomic CSS (di John Polacek, CSS Tricks )
23. BEM per principianti: perché hai bisogno di BEM (di Inna Belaya, Smashing Magazine )
24. Javascript per gatti: un'introduzione per i nuovi programmatori
25. Roadmap.sh: sviluppatore frontend
26. Programmazione funzionale vs OOPS: spiega come se avessi cinque anni
27. Perché, come e quando utilizzare HTML semantico e ARIA (di Adam Silver, CSS Tricks )
28. HTML Semantics (un eBook di Smashing Magazine )
29. I Fondamenti - HTML + CSS (su Syntax.fm )
30. Cascata ed eredità ( westciv.com )
31. Trucchi CSS (di Chris Coyier)
32. Guida introduttiva al layout CSS (di Rachel Andrew, Smashing Magazine )
33. Introduzione all'HTML (documenti Web MDN)
34. Primi passi CSS (documenti web MDN)
35. JavaScript First Steps (documenti Web MDN)
36. 24 modi (di Drew McLellan)