mirror of
https://github.com/microsoft/Web-Dev-For-Beginners.git
synced 2025-08-19 13:02:08 +02:00
folder names
This commit is contained in:
Jen Looper
18
1-getting-started-lessons/1-intro-to-programming-languages/.github/post-lecture-quiz.md
vendored
Normal file
18
1-getting-started-lessons/1-intro-to-programming-languages/.github/post-lecture-quiz.md
vendored
Normal file
@@ -0,0 +1,18 @@
|
||||
*Complete this quiz along with your submission by checking one answer per question.*
|
||||
|
||||
1. What language would you most likely use to create a website?
|
||||
|
||||
- [ ] Machine Code
|
||||
- [ ] JavaScript
|
||||
- [ ] Bash
|
||||
|
||||
1. Development environments are unique to each developer
|
||||
|
||||
- [ ] True
|
||||
- [ ] False
|
||||
|
||||
1. A what will a developer do to fix buggy code?
|
||||
|
||||
- [ ] Syntax highlighting
|
||||
- [ ] Debugging
|
||||
- [ ] Code formatting
|
||||
18
1-getting-started-lessons/1-intro-to-programming-languages/.github/pre-lecture-quiz.md
vendored
Normal file
18
1-getting-started-lessons/1-intro-to-programming-languages/.github/pre-lecture-quiz.md
vendored
Normal file
@@ -0,0 +1,18 @@
|
||||
*Complete this quiz in class*
|
||||
|
||||
1. A program be created without the creator writing any code
|
||||
|
||||
- [ ] True
|
||||
- [ ] False
|
||||
|
||||
1. Low level languages are a popular choice for:
|
||||
|
||||
- [ ] Websites
|
||||
- [ ] Hardware
|
||||
- [ ] Video game software
|
||||
|
||||
1. Which one of these tools would most most likely be in a web developer's environment?
|
||||
|
||||
- [ ] Hardware, like a Raspberry Pi
|
||||
- [ ] Browser DevTools
|
||||
- [ ] Operating system documentation
|
||||
@@ -0,0 +1,190 @@
|
||||
# Introduction to Programming Languages and Tools of the Trade
|
||||
|
||||
This lesson covers the basics of programming languages. The topics covered here apply to most modern programming languages today. In the 'Tools of the Trade' section, you'll learn about useful software that helps you as a developer.
|
||||
|
||||
|
||||
> Sketchnote by [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## [Pre-lecture quiz](.github/pre-lecture-quiz.md)
|
||||
|
||||
### Introduction
|
||||
|
||||
In this lesson, we'll cover:
|
||||
|
||||
- What is programming?
|
||||
- Types of programming languages
|
||||
- Basic elements of a program
|
||||
- Useful software and tooling for the professional developer
|
||||
|
||||
## What is Programming?
|
||||
|
||||
Programming (also known as coding) is the process of writing instructions to a device, such as a computer or mobile device. We write these instructions with a programming language, which is then interpreted by the device. These sets of instructions may be referred to by various names, but *program*, *computer program*, *application (app)*, and *executable* are a few popular names.
|
||||
|
||||
A *program* can be anything that is written with code; websites, games, and phone apps are programs. While it's possible to create a program without writing code, the underlying logic is interpreted to the device and that logic was most likely written with code. A program that is *running* or *executing code* is carrying out instructions. The device that you're currently reading this lesson with is running a program to print it to your screen.
|
||||
|
||||
✅ Do a little research: who is considered to have been the world's first computer programmer?
|
||||
|
||||
## Programming Languages
|
||||
|
||||
Programming languages serve a main purpose: for developers to build instructions to send to a device. Devices only can understand binary (1s and 0s), and for *most* developers that's not a very efficient way to communicate. Programming languages are a vehicle for communication between humans and computers.
|
||||
|
||||
Programming languages come in different formats and may serve different purposes. For example, JavaScript is primarily used for web applications, while Bash is primarily used for operating systems.
|
||||
|
||||
*Low level languages* typically require fewer steps than *high level languages* for a device to interpret instructions. However, what makes high level languages popular is its readability and support. JavaScript is considered a high level language.
|
||||
|
||||
The following code illustrates the difference between a high level language with JavaScript and low level language with ARM assembly code.
|
||||
|
||||
```javascript
|
||||
let number = 10
|
||||
let n1 = 0, n2 = 1, nextTerm;
|
||||
|
||||
for (let i = 1; i <= number; i++) {
|
||||
console.log(n1);
|
||||
nextTerm = n1 + n2;
|
||||
n1 = n2;
|
||||
n2 = nextTerm;
|
||||
}
|
||||
```
|
||||
|
||||
```c
|
||||
area ascen,code,readonly
|
||||
entry
|
||||
code32
|
||||
adr r0,thumb+1
|
||||
bx r0
|
||||
code16
|
||||
thumb
|
||||
mov r0,#00
|
||||
sub r0,r0,#01
|
||||
mov r1,#01
|
||||
mov r4,#10
|
||||
ldr r2,=0x40000000
|
||||
back add r0,r1
|
||||
str r0,[r2]
|
||||
add r2,#04
|
||||
mov r3,r0
|
||||
mov r0,r1
|
||||
mov r1,r3
|
||||
sub r4,#01
|
||||
cmp r4,#00
|
||||
bne back
|
||||
end
|
||||
```
|
||||
|
||||
Believe it or not, *they're both doing the same thing*: printing a Fibonacci sequence up to 10.
|
||||
|
||||
✅ A Fibonacci sequence is [defined](https://en.wikipedia.org/wiki/Fibonacci_number) as a set of numbers such that each number is the sum of the two preceding ones, starting from 0 and 1.
|
||||
|
||||
## Elements of a program
|
||||
|
||||
A single instruction in a program is called a *statement* and will usually have a character or line spacing that marks where the instruction ends, or *terminates*. How a program terminates varies with each language.
|
||||
|
||||
Most programs rely on using data from a user or elsewhere, where statements may rely on data to carry out instructions. Data can change how a program behaves, so programming languages come with a way to temporarily store data that can be used later. This data is called *variables*. Variables are statements that instruct a device to save data in its memory. Variables in programs are similar to ones in algebra, where they have a unique name and their value may change over time.
|
||||
|
||||
There's a chance that some statements will not be executed by a device. This is usually by design when written by the developer or by accident when an unexpected error occurs. This type of control of an application makes it more robust and maintainable. Typically these changes in control happen when certain decisions are met. A common statement in modern programming languages to control how a program is run is the `if..else` statement.
|
||||
|
||||
✅ You'll learn more about this type of statement in subsequent lessons
|
||||
|
||||
## Tools of the Trade
|
||||
|
||||
[](https://youtube.com/watch?v=69WJeXGBdxg "Tools of the Trade")
|
||||
|
||||
In this section, you'll learn about some software that you might find very useful as you start your professional development journey.
|
||||
|
||||
A **development environment** is a unique set of tools and features that a developer will use often when writing software. Some of these tools have been customized for a developer specific needs, and may change over time if a developer changes priorities in work or personal projects, or when they use a different programming language. Development environments are as unique as the developers who use them.
|
||||
|
||||
### Editors
|
||||
|
||||
One of the most crucial tools for software development is the editor. Editors are where you write your code and sometimes where you will run your code.
|
||||
|
||||
Developers rely on editors for a few additional reasons:
|
||||
|
||||
- *Debugging* Discovering bugs and errors by stepping through code, line by line. Some editors have debugging capabilities, or can be customized and added for specific programming languages.
|
||||
- *Syntax highlighting* Adds colors and text formatting to code, makes it easier to read. Most editors allow customized syntax highlighting.
|
||||
- *Extensions and Integrations* Additions that are specialized for developers, by developers, for access to additional tools that aren't built into the base editor. For example, many developers also need a way to document their code and explain how it works and will install a spell check extension to check for typos. Most of these additions are intended for use within a specific editor, and most editors come with a way to search for available extensions.
|
||||
- *Customization* Most editors are extremely customizable, and each developer will have their own unique development environment that suits their needs. Many also allow developers to create their own extension.
|
||||
|
||||
#### Popular Editors and Web Development Extensions
|
||||
|
||||
- [Visual Studio Code](https://code.visualstudio.com/)
|
||||
- [Code Spell Checker](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker)
|
||||
- [Live Share](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare-pack)
|
||||
- [Prettier - Code formatter](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode)
|
||||
- [Atom](https://atom.io/)
|
||||
- [spell-check](https://atom.io/packages/spell-check)
|
||||
- [teletype](https://atom.io/packages/teletype)
|
||||
- [atom-beautify](https://atom.io/packages/atom-beautify)
|
||||
|
||||
### Browsers
|
||||
|
||||
Another crucial tool is the browser. Web developers rely on the browser to observe how their code runs on the web, it's also used to view visual elements of a web page that are written in the editor, like HTML.
|
||||
|
||||
Many browsers come with *developer tools* (DevTools) that contain a set of helpful features and information to assist developers to collect and capture important insights about their application. For example: If a web page has errors, it's sometimes helpful to know when they occurred. DevTools in a browser can be configured to capture this information.
|
||||
|
||||
#### Popular Browsers and DevTools
|
||||
|
||||
- [Edge](https://docs.microsoft.com/microsoft-edge/devtools-guide-chromium)
|
||||
- [Chrome](https://developers.google.com/web/tools/chrome-devtools/)
|
||||
- [Firefox](https://developer.mozilla.org/docs/Tools)
|
||||
|
||||
### Command Line Tools
|
||||
|
||||
Some developers prefer a less graphical view for their daily tasks and rely on the command line to achieve this. Developing code requires a significant amount of typing, and some developers prefer to not disrupt their flow on the keyboard and will use keyboard shortcuts to swap between desktop windows, work on different files, and use tools. Most tasks can be completed with a mouse, but one benefit of using the command line is that a lot can be done with command line tools without the need of swapping between the mouse and keyboard. Another benefit of the command line is that they're configurable and you can save your custom configuration, change it later, and also import it to new development machines. Because development environments are so unique to each developer, some will avoid using the command line, some will rely on it entirely, and some prefer a mix of the two.
|
||||
|
||||
### Popular Command Line Options
|
||||
|
||||
Options for the command line will differ based on the operating system you use.
|
||||
|
||||
*💻 = comes preinstalled on the operating system.*
|
||||
|
||||
#### Windows
|
||||
|
||||
- [Powershell](https://docs.microsoft.com/powershell/scripting/overview?view=powershell-7) 💻
|
||||
- [Command Line](https://docs.microsoft.com/windows-server/administration/windows-commands/windows-commands) (also known as CMD) 💻
|
||||
- [Windows Terminal](https://docs.microsoft.com/windows/terminal/)
|
||||
- [mintty](https://mintty.github.io/)
|
||||
|
||||
#### MacOS
|
||||
|
||||
- [Terminal](https://support.apple.com/guide/terminal/open-or-quit-terminal-apd5265185d-f365-44cb-8b09-71a064a42125/mac) 💻
|
||||
- [iTerm](https://iterm2.com/)
|
||||
- [Powershell](https://docs.microsoft.com/powershell/scripting/install/installing-powershell-core-on-macos?view=powershell-7)
|
||||
|
||||
#### Linux
|
||||
|
||||
- [Bash](https://www.gnu.org/software/bash/manual/html_node/index.html) 💻
|
||||
- [KDE Konsole](https://docs.kde.org/trunk5/en/applications/konsole/index.html)
|
||||
- [Powershell](https://docs.microsoft.com/powershell/scripting/install/installing-powershell-core-on-linux?view=powershell-7)
|
||||
|
||||
#### Popular Command Line Tools
|
||||
|
||||
- [Git](https://git-scm.com/) (💻 on most operating sytems)
|
||||
- [NPM](https://www.npmjs.com/)
|
||||
- [Yarn](https://classic.yarnpkg.com/en/docs/cli/)
|
||||
|
||||
### Documentation
|
||||
|
||||
When a developer wants to learn something new, they'll most likely turn to documentation to learn how to use it. Developers rely on documentation often to guide them through how to use tools and languages properly, and also to gain deeper knowledge of how it works.
|
||||
|
||||
#### Popular Documentation on Web Development
|
||||
|
||||
- [Mozilla Developer Network](https://developer.mozilla.org/docs/Web)
|
||||
- [Frontend Masters](https://frontendmasters.com/learn/)
|
||||
|
||||
✅ Do some research: Now that you know the basics of a web developer's environment, compare and contrast it with a web designer's environment.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Challenge
|
||||
|
||||
Compare some programming languages. What are some of the unique traits of JavaScript vs. Java? How about COBOL vs. Go?
|
||||
|
||||
## [Post-lecture quiz](.github/post-lecture-quiz.md)
|
||||
|
||||
## Review & Self Study
|
||||
|
||||
Study a bit on the different languages available to the programmer. Try to write a line in one language, and then redo it in two others. What do you learn?
|
||||
|
||||
## Assignment
|
||||
|
||||
[Reading the Docs](assignment.md)
|
||||
@@ -0,0 +1,12 @@
|
||||
# Reading the Docs
|
||||
|
||||
## Instructions
|
||||
|
||||
There are many tools that a web developer may need that are on the [MDN documentation for client-side tooling](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Overview). Select 3 tools not covered in the lesson, explain why a web developer would use it, and search for a tool that falls under this category and share its documentation. Do not use the same tool example on MDN docs.
|
||||
|
||||
## Rubric
|
||||
|
||||
Exemplary | Adequate | Needs Improvement
|
||||
--- | --- | -- |
|
||||
|Explained why web developer would use tool| Explained how, but not why developer would use tool| Did not mention how or why a developer would use tool |
|
||||
|Provided a similar tool with docs link| Provided a similar tool without docs link | Did not mention a similar tool or used same tool on MDN |
|
||||
@@ -0,0 +1,178 @@
|
||||
# Introducción a lenguajes de programación y herramientas del oficio
|
||||
|
||||
Esta lección cubre los conceptos básicos de los lenguajes de programación. Los temas que se tratan aquí se aplican a la mayoría de los lenguajes de programación modernos en la actualidad. En la sección 'Herramientas del oficio', aprenderá sobre software útil que lo ayuda como desarrollador.
|
||||
|
||||
## [Pre-lecture quiz](.github/pre-lecture-quiz.md)
|
||||
|
||||
### Introducción
|
||||
|
||||
En esta lección, cubriremos:
|
||||
|
||||
- ¿Qué es la programación?
|
||||
- Tipos de lenguajes de programación
|
||||
- Elementos básicos de un programa
|
||||
- Software y herramientas útiles para el desarrollador profesional.
|
||||
|
||||
## ¿Qué es la programación?
|
||||
|
||||
La programación (también conocida como codificación) es el proceso de escribir instrucciones en un dispositivo, como una computadora o un dispositivo móvil. Escribimos estas instrucciones con un lenguaje de programación, que luego es interpretado por el dispositivo. Estos conjuntos de instrucciones pueden tener varios nombres, pero *programa*, *programa de computadora*, *aplicación (aplicación)* y *ejecutable* son algunos nombres populares.
|
||||
|
||||
Un *programa* puede ser cualquier cosa que esté escrita con código; Los sitios web, los juegos y las aplicaciones de teléfono son programas. Si bien es posible crear un programa sin escribir código, la lógica subyacente se interpreta al dispositivo y esa lógica probablemente se escribió con código. Un programa que está *ejecutándose* o *ejecutando código* está ejecutando instrucciones. El dispositivo con el que estás leyendo esta lección está ejecutando un programa para imprimirlo en tu pantalla.
|
||||
|
||||
✅ Investigue un poco: ¿quién se considera el primer programador de computadoras del mundo?
|
||||
|
||||
## Lenguajes de programación
|
||||
|
||||
Los lenguajes de programación tienen un propósito principal: que los desarrolladores creen instrucciones para enviarlas a un dispositivo. Los dispositivos solo pueden entender binarios (1 y 0), y para *la mayoría* de los desarrolladores esa no es una forma muy eficiente de comunicarse. Los lenguajes de programación son un vehículo para la comunicación entre humanos y computadoras.
|
||||
|
||||
Los lenguajes de programación vienen en diferentes formatos y pueden tener diferentes propósitos. Por ejemplo, JavaScript se usa principalmente para aplicaciones web, mientras que Bash se usa principalmente para sistemas operativos.
|
||||
|
||||
*Los idiomas de bajo nivel* normalmente requieren menos pasos que los *idiomas de alto nivel* para que un dispositivo interprete las instrucciones. Sin embargo, lo que hace que los lenguajes de alto nivel sean populares es su legibilidad y soporte. JavaScript se considera un lenguaje de alto nivel.
|
||||
|
||||
El siguiente código ilustra la diferencia entre un lenguaje de alto nivel con JavaScript y un lenguaje de bajo nivel con código ensamblador ARM.
|
||||
|
||||
```javascript
|
||||
let number = 10
|
||||
let n1 = 0, n2 = 1, nextTerm;
|
||||
|
||||
for (let i = 1; i <= number; i++) {
|
||||
console.log(n1);
|
||||
nextTerm = n1 + n2;
|
||||
n1 = n2;
|
||||
n2 = nextTerm;
|
||||
}
|
||||
```
|
||||
|
||||
```c
|
||||
area ascen,code,readonly
|
||||
entry
|
||||
code32
|
||||
adr r0,thumb+1
|
||||
bx r0
|
||||
code16
|
||||
thumb
|
||||
mov r0,#00
|
||||
sub r0,r0,#01
|
||||
mov r1,#01
|
||||
mov r4,#10
|
||||
ldr r2,=0x40000000
|
||||
back add r0,r1
|
||||
str r0,[r2]
|
||||
add r2,#04
|
||||
mov r3,r0
|
||||
mov r0,r1
|
||||
mov r1,r3
|
||||
sub r4,#01
|
||||
cmp r4,#00
|
||||
bne back
|
||||
end
|
||||
```
|
||||
|
||||
Lo crea o no, *ambos hacen lo mismo*: imprimir una secuencia de Fibonacci hasta 10.
|
||||
|
||||
✅ Una secuencia de Fibonacci se [define](https://en.wikipedia.org/wiki/Fibonacci_number) como un conjunto de números de modo que cada número es la suma de los dos precedentes, comenzando por 0 y 1.
|
||||
|
||||
## Elementos de un programa
|
||||
|
||||
Una sola instrucción en un programa se llama *instrucción* y generalmente tendrá un carácter o un espacio entre líneas que marca dónde termina la instrucción, o *termina*. La forma en que termina un programa varía con cada idioma.
|
||||
|
||||
La mayoría de los programas se basan en el uso de datos de un usuario o de otros lugares, donde las declaraciones pueden basarse en datos para llevar a cabo instrucciones. Los datos pueden cambiar la forma en que se comporta un programa, por lo que los lenguajes de programación vienen con una forma de almacenar temporalmente datos que se pueden usar más adelante. Estos datos se denominan* variables*. Las variables son declaraciones que indican a un dispositivo que guarde datos en su memoria. Las variables en los programas son similares a las del álgebra, donde tienen un nombre único y su valor puede cambiar con el tiempo.
|
||||
|
||||
Existe la posibilidad de que un dispositivo no ejecute algunas declaraciones. Esto suele ser por diseño cuando lo escribe el desarrollador o por accidente cuando ocurre un error inesperado. Este tipo de control de una aplicación la hace más robusta y fácil de mantener. Por lo general, estos cambios en el control ocurren cuando se cumplen ciertas decisiones. Una declaración común en los lenguajes de programación modernos para controlar cómo se ejecuta un programa es la declaración `if..else`.
|
||||
|
||||
✅ Aprenderá más sobre este tipo de afirmaciones en lecciones posteriores.
|
||||
|
||||
## Herramientas del oficio
|
||||
|
||||
En esta sección, aprenderá sobre algún software que puede resultarle muy útil al comenzar su viaje de desarrollo profesional.
|
||||
|
||||
Un **entorno de desarrollo** es un conjunto único de herramientas y características que un desarrollador utilizará a menudo al escribir software. Algunas de estas herramientas se han personalizado para las necesidades específicas de un desarrollador y pueden cambiar con el tiempo si un desarrollador cambia las prioridades en el trabajo o proyectos personales, o cuando usa un lenguaje de programación diferente. Los entornos de desarrollo son tan únicos como los desarrolladores que los utilizan.
|
||||
|
||||
### Editores
|
||||
|
||||
Una de las herramientas más importantes para el desarrollo de software es el editor. Los editores son el lugar donde escribe su código y, a veces, donde ejecutará su código.
|
||||
|
||||
Los desarrolladores confían en los editores por algunas razones adicionales:
|
||||
|
||||
- *Depuración* Descubrimiento de errores y errores al recorrer el código, línea por línea. Algunos editores tienen capacidades de depuración o se pueden personalizar y agregar para lenguajes de programación específicos.
|
||||
- *Resaltado de sintaxis* Agrega colores y formato de texto al código, lo hace más fácil de leer. La mayoría de los editores permiten el resaltado de sintaxis personalizado.
|
||||
- *Extensiones e integraciones del navegador* Adiciones especializadas para desarrolladores, por desarrolladores, para acceder a herramientas adicionales que no están integradas en el editor base. Por ejemplo, muchos desarrolladores también necesitan una forma de documentar su código y explicar cómo funciona, e instalarán una extensión de revisión ortográfica para verificar si hay errores tipográficos. La mayoría de estas adiciones están diseñadas para su uso dentro de un editor específico, y la mayoría de los editores vienen con una forma de buscar extensiones disponibles.
|
||||
- *Personalización* La mayoría de los editores son extremadamente personalizables, y cada desarrollador tendrá su propio entorno de desarrollo único que se adapta a sus necesidades. Muchos también permiten a los desarrolladores crear su propia extensión.
|
||||
|
||||
|
||||
#### Editores populares y extensiones de desarrollo web
|
||||
|
||||
- [Código de Visual Studio](https://code.visualstudio.com/)
|
||||
- [Corrector ortográfico de código](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker)
|
||||
- [Live Share](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare-pack)
|
||||
- [Más bonito - Formateador de código](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode)
|
||||
- [Átomo](https://atom.io/)
|
||||
- [revisión ortográfica](https://atom.io/packages/spell-check)
|
||||
- [teletipo](https://atom.io/packages/teletype)
|
||||
- [atom-beautify](https://atom.io/packages/atom-beautify)
|
||||
|
||||
### Navegadores
|
||||
|
||||
Otra herramienta fundamental es el navegador. Los desarrolladores web confían en el navegador para observar cómo se ejecuta su código en la web, también se usa para ver elementos visuales de una página web que están escritos en el editor, como HTML.
|
||||
|
||||
Muchos navegadores vienen con *herramientas para desarrolladores* (DevTools) que contienen un conjunto de características e información útiles para ayudar a los desarrolladores a recopilar y capturar información importante sobre su aplicación. Por ejemplo: si una página web tiene errores, a veces es útil saber cuándo ocurrieron. DevTools en un navegador se puede configurar para capturar esta información.
|
||||
|
||||
#### Navegadores y herramientas de desarrollo populares
|
||||
|
||||
- [Edge](https://docs.microsoft.com/microsoft-edge/devtools-guide-chromium)
|
||||
- [Chrome](https://developers.google.com/web/tools/chrome-devtools/)
|
||||
- [Firefox](https://developer.mozilla.org/docs/Tools)
|
||||
|
||||
### Herramientas de línea de comandos
|
||||
|
||||
Algunos desarrolladores prefieren una vista menos gráfica para sus tareas diarias y confían en la línea de comandos para lograrlo. El desarrollo de código requiere una gran cantidad de escritura, y algunos desarrolladores prefieren no interrumpir su flujo en el teclado y usarán atajos de teclado para cambiar entre ventanas de escritorio, trabajar en diferentes archivos y usar herramientas. La mayoría de las tareas se pueden completar con un mouse, pero una de las ventajas de utilizar la línea de comandos es que se pueden hacer muchas cosas con las herramientas de la línea de comandos sin necesidad de cambiar entre el mouse y el teclado. Otro beneficio de la línea de comandos es que son configurables y puede guardar su configuración personalizada, cambiarla más tarde y también importarla a nuevas máquinas de desarrollo. Debido a que los entornos de desarrollo son tan exclusivos para cada desarrollador, algunos evitarán usar la línea de comandos, algunos dependerán de ella por completo y algunos prefieren una combinación de ambos.
|
||||
|
||||
### Opciones de línea de comandos populares
|
||||
|
||||
Las opciones para la línea de comando variarán según el sistema operativo que utilice.
|
||||
|
||||
*💻 = viene preinstalado en el sistema operativo.*
|
||||
|
||||
#### Windows
|
||||
|
||||
- [Powershell](https://docs.microsoft.com/powershell/scripting/overview?view=powershell-7) 💻
|
||||
- [Command Line](https://docs.microsoft.com/windows-server/administration/windows-commands/windows-commands) (also known as CMD) 💻
|
||||
- [Windows Terminal](https://docs.microsoft.com/windows/terminal/)
|
||||
- [mintty](https://mintty.github.io/)
|
||||
|
||||
#### MacOS
|
||||
|
||||
- [Terminal](https://support.apple.com/guide/terminal/open-or-quit-terminal-apd5265185d-f365-44cb-8b09-71a064a42125/mac) 💻
|
||||
- [iTerm](https://iterm2.com/)
|
||||
- [Powershell](https://docs.microsoft.com/powershell/scripting/install/installing-powershell-core-on-macos?view=powershell-7)
|
||||
|
||||
#### Linux
|
||||
|
||||
- [Bash](https://www.gnu.org/software/bash/manual/html_node/index.html) 💻
|
||||
- [KDE Konsole](https://docs.kde.org/trunk5/en/applications/konsole/index.html)
|
||||
- [Powershell](https://docs.microsoft.com/powershell/scripting/install/installing-powershell-core-on-linux?view=powershell-7)
|
||||
|
||||
#### Popular Command Line Tools
|
||||
|
||||
- [Git](https://git-scm.com/) (💻 en la mayoría de los sistemas operativos)
|
||||
- [NPM](https://www.npmjs.com/)
|
||||
- [Yarn](https://classic.yarnpkg.com/en/docs/cli/)
|
||||
|
||||
### Documentación
|
||||
|
||||
Cuando un desarrollador quiere aprender algo nuevo, lo más probable es que recurra a la documentación para aprender a usarla. Los desarrolladores a menudo confían en la documentación para guiarlos a través de cómo usar las herramientas y los lenguajes correctamente, y también para obtener un conocimiento más profundo de cómo funciona.
|
||||
|
||||
#### Documentación popular sobre desarrollo web
|
||||
|
||||
- [Mozilla Developer Network](https://developer.mozilla.org/docs/Web)
|
||||
- [Frontend Masters](https://frontendmasters.com/learn/)
|
||||
|
||||
✅ Investiga un poco: ahora que conoces los conceptos básicos del entorno de un desarrollador web, compáralo y contrasta con el entorno de un diseñador web.
|
||||
|
||||
🚀 Desafío: Compara algunos lenguajes de programación. ¿Cuáles son algunos de los rasgos únicos de JavaScript frente a Java? ¿Qué hay de COBOL vs. Go?
|
||||
|
||||
## [Post-lecture prueba](.github/post-lecture-quiz.md)
|
||||
|
||||
## Revisión y autoestudio
|
||||
|
||||
**Asignación**: [Asignación](assignment.md)
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 1.9 MiB |
19
1-getting-started-lessons/2-github-basics/.github/post-lecture-quiz.md
vendored
Normal file
19
1-getting-started-lessons/2-github-basics/.github/post-lecture-quiz.md
vendored
Normal file
@@ -0,0 +1,19 @@
|
||||
*Complete this quiz by checking one answer per question.*
|
||||
|
||||
1. A place to compare and discuss the differences introduced on a branch with reviews, comments, integrated tests, and more is:
|
||||
|
||||
- [ ] GitHub
|
||||
- [ ] A Pull Request
|
||||
- [ ] A feature branch
|
||||
|
||||
2. How would you get all the commits from a remote branch?
|
||||
|
||||
- [ ] `git fetch`
|
||||
- [ ] `git pull`
|
||||
- [ ] `git commits -r`
|
||||
|
||||
3. How do you switch to a branch?
|
||||
|
||||
- [ ] `git switch [branch-name]`
|
||||
- [ ] `git checkout [branch-name]`
|
||||
- [ ] `git load [branch-name]`
|
||||
13
1-getting-started-lessons/2-github-basics/.github/pre-lecture-quiz.md
vendored
Normal file
13
1-getting-started-lessons/2-github-basics/.github/pre-lecture-quiz.md
vendored
Normal file
@@ -0,0 +1,13 @@
|
||||
*Complete this quiz in class*
|
||||
|
||||
1. How do you create a Git repo?
|
||||
|
||||
- [ ] git create
|
||||
- [ ] git start
|
||||
- [ ] git init
|
||||
|
||||
2. What does `git add` do?
|
||||
|
||||
- [ ] Commits your code
|
||||
- [ ] Adds your files to a staging area for tracking
|
||||
- [ ] Adds your files to GitHub
|
||||
292
1-getting-started-lessons/2-github-basics/README.md
Normal file
292
1-getting-started-lessons/2-github-basics/README.md
Normal file
@@ -0,0 +1,292 @@
|
||||
# Introduction to GitHub
|
||||
|
||||
This lesson covers the basics of GitHub, a platform to host and manage changes to your code.
|
||||
|
||||
|
||||
> Sketchnote by [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
|
||||
## [Pre-lecture quiz](.github/pre-lecture-quiz.md)
|
||||
|
||||
### Introduction
|
||||
|
||||
In this lesson, we'll cover:
|
||||
|
||||
- tracking the work you do on your machine
|
||||
- working on projects with others
|
||||
- how to contribute to open source software
|
||||
|
||||
### Prerequisites
|
||||
|
||||
Before you begin, you'll need to check if Git is installed. In the terminal type:
|
||||
`git --version`
|
||||
|
||||
If Git is not installed, [download Git](https://git-scm.com/downloads). Then, setup your local Git profile in the terminal:
|
||||
`git config --global user.name "your-name"`
|
||||
`git config --global user.email "your-email"`
|
||||
|
||||
To check if Git is already configured you can type:
|
||||
`git config --list`
|
||||
|
||||
You'll also need a GitHub account, a code editor (like Visual Studio Code), and you'll need to open your terminal (or: command prompt).
|
||||
|
||||
Navigate to [github.com](https://github.com/) and create an account if you haven't already, or log in and fill out your profile.
|
||||
|
||||
✅ GitHub isn't the only code repository in the world; there are others, but GitHub is the best known
|
||||
|
||||
### Preparation
|
||||
|
||||
You'll need both a folder with a code project on your local machine (laptop or PC), and a public repository on GitHub, which will serve as an example for how to contribute to the projects of others.
|
||||
|
||||
---
|
||||
|
||||
## Code management
|
||||
|
||||
Let's say you have a folder locally with some code project and you want to start tracking your progress using git - the version control system. Some people compare using git to writing a love letter to your future self. Reading your commit messages days or weeks or months later you'll be able to recall why you made a decision, or "rollback" a change - that is, when you write good "commit messages".
|
||||
|
||||
### Task: Make a repository and commit code
|
||||
|
||||
1. **Create repository on GitHub**. On GitHub.com, in the repositories tab, or from the navigation bar top-right, find the **new repo** button.
|
||||
|
||||
1. Give your repository (folder) a name
|
||||
1. Select **create repository**.
|
||||
|
||||
1. **Navigate to your working folder**. In your terminal, switch to the folder (also known as the directory) you want to start tracking. Type:
|
||||
|
||||
```bash
|
||||
cd [name of your folder]
|
||||
```
|
||||
|
||||
1. **Initialize a git repository**. In your project type:
|
||||
|
||||
```bash
|
||||
git init
|
||||
```
|
||||
|
||||
1. **Check status**. To check the status if your repository type:
|
||||
|
||||
```bash
|
||||
git status
|
||||
```
|
||||
|
||||
the output can look something like this:
|
||||
|
||||
```output
|
||||
Changes not staged for commit:
|
||||
(use "git add <file>..." to update what will be committed)
|
||||
(use "git checkout -- <file>..." to discard changes in working directory)
|
||||
|
||||
modified: file.txt
|
||||
modified: file2.txt
|
||||
```
|
||||
|
||||
Typically a `git status` command tells you things like what files are ready to be _saved_ to the repo or has changes on it that you might want to persist.
|
||||
|
||||
1. **Add files to tracking**
|
||||
|
||||
```bash
|
||||
git add .
|
||||
```
|
||||
|
||||
The `git add` plus `.` argument indicates that all your files & changes for tracking.
|
||||
|
||||
1. **Persisting your work**. At this point you've added the files to a so called _staging area_. A place where Git is tracking your files. To make the change permanent you need to _commit_ the files. To do so you create a _commit_ with the `git commit` command. A _commit_ represents a saving point in the history of your repo. Type the following to create a _commit_:
|
||||
|
||||
```bash
|
||||
git commit -m "first commit"
|
||||
```
|
||||
|
||||
This commits all of your files, adding the message "first commit". For future commit messages you will want to be more descriptive in your description to convey what type of change you've made.
|
||||
|
||||
1. **Connect your local Git repo with GitHub**. A Git repo is good on your machine but at some point you want to have backup of your files somewhere and also invite other people to work with you on your repo. One such great place to do so is GitHub. Remember we've already created a repo on GitHub so the only thing we need to do is to connect our local Git repo with GitHub. The command `git remote add` will do just that. Type the following command:
|
||||
|
||||
> Note, before you type the command go to your GitHub repo page to find the repository URL. You will use it in the below command. Replace `repository_name` with your GitHub URL.
|
||||
|
||||
```bash
|
||||
git remote add origin https://github.com/username/repository_name.git
|
||||
```
|
||||
|
||||
This creates a _remote_, or connection, named "origin" pointing at the GitHub repository you created earlier.
|
||||
|
||||
1. **Send local files to GitHub**. So far you've created a _connection_ between the local repo and the GitHub repo. Let's send these files to GitHub with the following command `git push`, like so:
|
||||
|
||||
```bash
|
||||
git push -u origin main
|
||||
```
|
||||
|
||||
This sends your commits in your "main" branch to GitHub.
|
||||
|
||||
1. **To add more changes**. If you want to continue making changes and pushing them to GitHub you’ll just need to use the following three commands:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "type your commit message here"
|
||||
git push
|
||||
```
|
||||
|
||||
> Tip, You might also want to adopt a `.gitignore` file to prevent files you don't want to track from showing up on GitHub - like that notes file you store in the same folder but has no place on a public repository. You can find templates for `.gitignore` files at [.gitignore templates](github.com/github/gitignore).
|
||||
|
||||
#### Commit messages
|
||||
|
||||
A great Git commit subject line completes the following sentence:
|
||||
If applied, this commit will <your subject line here>
|
||||
|
||||
For the subject use the imperative, present tense: "change" not "changed" nor "changes".
|
||||
As in the subject, in the body (optional) also use the imperative, present tense. The body should include the motivation for the change and contrast this with previous behavior. You're explaining the `why`, not the `how`.
|
||||
|
||||
✅ Take a few minutes to surf around GitHub. Can you find a really great commit message? Can you find a really minimal one? What information do you think is the most important and useful to convey in a commit message?
|
||||
|
||||
### Task: Collaborate
|
||||
|
||||
The main reason for putting things on GitHub was to make it possible to collaborate with other developers.
|
||||
|
||||
## Working on projects with others
|
||||
|
||||
In your repository, navigate to `Insights > Community` to see how your project compares to recommended community standards.
|
||||
|
||||
Here are some things that can improve your GitHub repo:
|
||||
- **Description**. Did you add a description for your project?
|
||||
- **README**. Did you add a README? GitHub provides guidance for writing a [README](https://docs.github.com/articles/about-readmes/).
|
||||
- **Contributing guideline**. Does your project have [contributing guidelines](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/),
|
||||
- **Code of Conduct**. a [Code of Conduct](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/),
|
||||
- **License**. Perhaps most importantly, a [license](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
|
||||
|
||||
|
||||
All these resources will benefit onboarding new team members. And those are typically the kind of things new contributors look at before even looking at your code, to find out if your project is the right place for them to be spending their time.
|
||||
|
||||
✅ README files, although they take time to prepare, are often neglected by busy maintainers. Can you find an example of a particularly descriptive one? Note: there are some [tools to help create good READMEs](https://www.makeareadme.com/) that you might like to try.
|
||||
|
||||
### Task: Merge some code
|
||||
|
||||
Contributing docs help people contribute to the project. It explains what types of contributions you're looking for and how the process works. Contributors will need to go through a series of steps to be able to contribute to your repo on GitHub:
|
||||
|
||||
|
||||
1. **Forking your repo** You will probably want people to _fork_ your project. Forking means creating a replica of your repository on their GitHub profile.
|
||||
1. **Clone**. From there they will clone the project to their local machine.
|
||||
1. **Create a branch**. You will want to ask them to create a _branch_ for their work.
|
||||
1. **Focus their change on one area**. Ask contributors to concentrate their contributions on one thing at a time - that way the chances that you can _merge_ in their work is higher. Imagine they write a bug fix, add a new feature, and update several tests - what if you want to, or can only implement 2 out of 3, or 1 out of 3 changes?
|
||||
|
||||
✅ Imagine a situation where branches are particularly critical to writing and shipping good code. What use cases can you think of?
|
||||
|
||||
> Note, be the change you want to see in the world, and create branches for your own work as well. Any commits you make will be made on the branch you’re currently “checked out” to. Use `git status` to see which branch that is.
|
||||
|
||||
Let's go through a contributor workflow. Assume the contributor has already _forked_ and _cloned_ the repo so they have a Git repo ready to be worked on, on their local machine:
|
||||
|
||||
1. **Create a branch**. Use the command `git branch` to create a branch that will contain the changes they mean to contribute:
|
||||
|
||||
```bash
|
||||
git branch [branch-name]
|
||||
```
|
||||
|
||||
1. **Switch to working branch**. Switch to the specified branch and update the working directory with `git checkout`:
|
||||
|
||||
```bash
|
||||
git checkout [branch-name]
|
||||
```
|
||||
|
||||
1. **Do work**. At this point you want to add your changes. Don't forget to tell Git about it with the following commands:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "my changes"
|
||||
```
|
||||
|
||||
Ensure you give your commit a good name, for your sake as well as the maintainer of the repo you are helping on.
|
||||
|
||||
1. **Combine your work with the `main` branch**. At some point you are done working and you want to combine your work with that of the `main` branch. The `main` branch might have changed meanwhile so make sure you first update it to the latest with the following commands:
|
||||
|
||||
```bash
|
||||
git checkout main
|
||||
git pull
|
||||
```
|
||||
|
||||
At this point you want to make sure that any _conflicts_, situations where Git can't easily _combine_ the changes happens in your working branch. Therefore run the following commands:
|
||||
|
||||
```bash
|
||||
git checkout [branch_name]
|
||||
git merge main
|
||||
```
|
||||
|
||||
This will bring in all changes from `main` into your branch and hopefully you can just continue. If not, VS Code will tell you where Git is _confused_ and you just alter the affected files to say which content is the most accurate.
|
||||
|
||||
1. **Send your work to GitHub**. Sending your work to GitHub means two things. Pushing your branch to your repo and then open up a PR, Pull Request.
|
||||
|
||||
```bash
|
||||
git push --set-upstream origin [branch-name]
|
||||
```
|
||||
|
||||
The above command creates the branch on your forked repo.
|
||||
|
||||
1. **Open a PR**. Next, you want to open up a PR. You do that by navigating to the forked repo on GitHub. You will see an indication on GitHub where it asks whether you want to create a new PR, you click that and you are taken to an interface where you can change commit message title, give it a more suitable description. Now the maintainer of the repo you forked will see this PR and _fingers crossed_ they will appreciate and _merge_ your PR. You are now a contributor, yay :)
|
||||
|
||||
1. **Clean up**. It's considered good practice to _clean up_ after you. You want to clean up both your local branch and the branch you pushed to GitHub. First let's delete it locally with the following command:
|
||||
|
||||
```bash
|
||||
git branch -d [branch-name]
|
||||
```
|
||||
|
||||
Ensure you go the GitHub page for the forked repo next and remove the remote branch you just pushed to it.
|
||||
|
||||
`Pull request` seems like a silly term because really you want to push your changes to the project. But the maintainer (project owner) or core team needs to consider your changes before merging it with the project's "main" branch, so you're really requesting a change decision from a maintainer.
|
||||
|
||||
A pull request is the place to compare and discuss the differences introduced on a branch with reviews, comments, integrated tests, and more. A good pull request follows roughly the same rules as a commit message. You can add a reference to an issue in the issue tracker, when your work for instance fixes an issue. This is done using a `#` followed by the number of your issue. For example `#97`.
|
||||
|
||||
🤞Fingers crossed that all checks pass and the project owner(s) merge your changes into the project🤞
|
||||
|
||||
Update your current local working branch with all new commits from the corresponding remote branch on GitHub:
|
||||
|
||||
`git pull`
|
||||
|
||||
## How to contribute to open source
|
||||
|
||||
First, let's find a repository - or: repo - on GitHub of interest to you and to which you'd like to contribute a change. You will want to copy the contents of to our machine.
|
||||
|
||||
✅ A good way to find 'beginner-friendly' repos is to [search by the tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
|
||||
|
||||
|
||||
|
||||
There are several ways of copying code. One way is to "clone" the contents of the repository, using HTTPS, SSH, or using the GitHub CLI (Command Line Interface).
|
||||
|
||||
Open your terminal and clone the repository like so:
|
||||
`git clone https://github.com/ProjectURL`
|
||||
|
||||
To work on the project, switch to the right folder:
|
||||
`cd ProjectURL`
|
||||
|
||||
You can also open the entire project using [Codespaces](https://github.com/features/codespaces), GitHub's embedded code editor / cloud development environment, or [GitHub Desktop](https://desktop.github.com/).
|
||||
|
||||
Lastly, you can download the code in a zipped folder.
|
||||
|
||||
### A few more interesting things about GitHub
|
||||
|
||||
You can star, watching, and/or "fork" any public repository on GitHub. You can find your starred repositories in the top-right drop-down menu. It's like bookmarking, but for code.
|
||||
|
||||
Projects have an issue tracker, mostly on GitHub in the "Issues" tab unless indicated otherwise, where people discuss issues related to the project. And the Pull Requests tab is where people discuss and review changes that are in progress.
|
||||
|
||||
Projects might also have discussion in forums, mailing lists, or chat channels like Slack, Discord or IRC.
|
||||
|
||||
✅ Take a look around your new GitHub repo and try a few things, like editing settings, adding information to your repo, and creating a project (like a Kanban board). There's a lot you can do!
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Challenge
|
||||
|
||||
Pair with a friend to work on each other's code. Create a project collaboratively, fork code, create branches, and merge changes.
|
||||
|
||||
## [Post-lecture quiz](.github/post-lecture-quiz.md)
|
||||
|
||||
## Review & Self Study
|
||||
|
||||
Read more about [contributing to open source software](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
|
||||
|
||||
[Git cheatsheet](https://training.github.com/downloads/github-git-cheat-sheet/).
|
||||
|
||||
Practice, practice, practice. GitHub has great learning paths available via [lab.github.com](https://lab.github.com/):
|
||||
|
||||
- [First Week on GitHub](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
|
||||
You'll also find more advanced labs.
|
||||
|
||||
## Assignment
|
||||
|
||||
Complete [the First Week on GitHub training lab](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
BIN
1-getting-started-lessons/2-github-basics/images/clone_repo.png
Normal file
BIN
1-getting-started-lessons/2-github-basics/images/clone_repo.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 36 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.6 MiB |
@@ -0,0 +1,283 @@
|
||||
# Introducción a GitHub
|
||||
|
||||
Esta lección cubre los conceptos básicos de GitHub, una plataforma para alojar y administrar cambios en su código.
|
||||
|
||||
## [Pre-lecture prueba](.github/pre-lecture-quiz.md)
|
||||
|
||||
### Introducción
|
||||
|
||||
En esta lección, cubriremos:
|
||||
|
||||
- seguimiento del trabajo que realiza en su máquina
|
||||
- trabajar en proyectos con otros
|
||||
- cómo contribuir al software de código abierto
|
||||
|
||||
### Prerrequisitos
|
||||
|
||||
Antes de comenzar, deberá verificar si Git está instalado. En el tipo de terminal:
|
||||
`git --version`
|
||||
|
||||
Si Git no está instalado, [descargar Git](https://git-scm.com/downloads). Luego, configure su perfil de Git local en la terminal:
|
||||
`git config --global user.name "tu-nombre"`
|
||||
`git config --global user.email "tu-email"`
|
||||
|
||||
Para comprobar si Git ya está configurado, puede escribir:
|
||||
`git config --list`
|
||||
|
||||
También necesitará una cuenta de GitHub, un editor de código (como Visual Studio Code) y deberá abrir su terminal (o: símbolo del sistema).
|
||||
|
||||
Vaya a [github.com](https://github.com/) y cree una cuenta si aún no lo ha hecho, o inicie sesión y complete su perfil.
|
||||
|
||||
✅ GitHub no es el único repositorio de código del mundo; hay otros, pero GitHub es el más conocido.
|
||||
|
||||
### Preparación
|
||||
|
||||
Necesitará una carpeta con un proyecto de código en su máquina local (computadora portátil o PC) y un repositorio público en GitHub, que le servirá como ejemplo de cómo contribuir a los proyectos de otros.
|
||||
|
||||
---
|
||||
|
||||
## Gestión de código
|
||||
|
||||
Digamos que tiene una carpeta localmente con algún proyecto de código y desea comenzar a rastrear su progreso usando git, el sistema de control de versiones. Algunas personas comparan el uso de git con escribir una carta de amor a su yo futuro. Al leer sus mensajes de confirmación días, semanas o meses después, podrá recordar por qué tomó una decisión o "revertir" un cambio, es decir, cuando escribe buenos "mensajes de confirmación".
|
||||
|
||||
### Tarea: hacer un repositorio y enviar código
|
||||
|
||||
1. **Crear repositorio en GitHub**. En GitHub.com, en la pestaña de repositorios, o en la barra de navegación superior derecha, busque el botón **nuevo repositorio**.
|
||||
|
||||
1. Dale un nombre a tu repositorio (carpeta)
|
||||
1. Seleccione **crear repositorio**.
|
||||
|
||||
1. **Navegue a su carpeta de trabajo**. En su terminal, cambie a la carpeta (también conocida como directorio) que desea comenzar a rastrear. Tipo:
|
||||
|
||||
```bash
|
||||
cd [nombre de tu carpeta]
|
||||
```
|
||||
|
||||
1. **Inicializar un repositorio de git**. En su tipo de proyecto:
|
||||
|
||||
```bash
|
||||
git init
|
||||
```
|
||||
|
||||
1. **Comprobar estado**. Para comprobar el estado de su tipo de repositorio:
|
||||
|
||||
```bash
|
||||
git status
|
||||
```
|
||||
|
||||
la salida puede verse así:
|
||||
|
||||
```output
|
||||
Changes not staged for commit:
|
||||
(use "git add <file>..." to update what will be committed)
|
||||
(use "git checkout -- <file>..." to discard changes in working directory)
|
||||
|
||||
modified: file.txt
|
||||
modified: file2.txt
|
||||
```
|
||||
|
||||
Por lo general, un comando `git status` le dice cosas como qué archivos están listos para ser guardados en el repositorio o tiene cambios que es posible que desee conservar.
|
||||
|
||||
1. **Agregar archivos al seguimiento**
|
||||
|
||||
```bash
|
||||
git add .
|
||||
```
|
||||
|
||||
El argumento `git add` más `.` indica que todos sus archivos y cambios para el seguimiento.
|
||||
|
||||
1. **Persistir en tu trabajo**. En este punto, ha agregado los archivos a lo que se denomina _área de preparación_. Un lugar donde Git rastrea sus archivos. Para que el cambio sea permanente, debe _commitir_ los archivos. Para hacerlo, crea un _commit_ con el comando `git commit`. Un _commit_ representa un punto de ahorro en el historial de su repositorio. Escriba lo siguiente para crear un _commit_:
|
||||
|
||||
```bash
|
||||
git commit -m "first commit"
|
||||
```
|
||||
|
||||
Esto confirma todos sus archivos, agregando el mensaje "primer compromiso". Para futuros mensajes de confirmación, querrá ser más descriptivo en su descripción para transmitir qué tipo de cambio ha realizado.
|
||||
|
||||
1. **Conecte su repositorio de Git local con GitHub**. Un repositorio de Git es bueno en su máquina, pero en algún momento desea tener una copia de seguridad de sus archivos en algún lugar y también invitar a otras personas a trabajar con usted en su repositorio. Un gran lugar para hacerlo es GitHub. Recuerde que ya hemos creado un repositorio en GitHub, por lo que lo único que debemos hacer es conectar nuestro repositorio de Git local con GitHub. El comando `git remote add` hará precisamente eso. Escriba el siguiente comando:
|
||||
|
||||
|
||||
> Tenga en cuenta que antes de escribir el comando, vaya a la página de su repositorio de GitHub para encontrar la URL del repositorio. Lo usará en el siguiente comando. Reemplaza `repository_name` con tu URL de GitHub.
|
||||
|
||||
|
||||
```bash
|
||||
git remote add origin https://github.com/username/repository_name.git
|
||||
```
|
||||
|
||||
Esto crea un _remote_, o conexión, llamado "origin" que apunta al repositorio de GitHub que creó anteriormente.
|
||||
|
||||
1. **Envía archivos locales a GitHub**. Hasta ahora ha creado una _conexión_ entre el repositorio local y el repositorio de GitHub. Enviemos estos archivos a GitHub con el siguiente comando `git push`, así:
|
||||
|
||||
|
||||
```bash
|
||||
git push -u origin main
|
||||
```
|
||||
|
||||
Esto envía sus confirmaciones en su rama "principal" a GitHub.
|
||||
|
||||
1. **Para agregar más cambios**. Si desea continuar haciendo cambios y enviarlos a GitHub, solo necesitará usar los siguientes tres comandos:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "escribe tu mensaje de confirmación aquí"
|
||||
git push
|
||||
```
|
||||
|
||||
> Sugerencia: es posible que también desee adoptar un archivo `.gitignore` para evitar que los archivos que no desea rastrear aparezcan en GitHub, como el archivo de notas que almacena en la misma carpeta pero no tiene lugar para escribir su mensaje de confirmación aquí repositorio público. Puede encontrar plantillas para archivos `.gitignore` en [.gitignore templates](github.com/github/gitignore).
|
||||
|
||||
|
||||
#### Confirmar mensajes
|
||||
|
||||
Una gran línea de asunto de confirmación de Git completa la siguiente oración:
|
||||
Si se aplica, esta confirmación será <su línea de asunto aquí>
|
||||
|
||||
Para el sujeto use el imperativo, tiempo presente: "cambiar" no "cambiar" ni "cambiar".
|
||||
Como en el sujeto, en el cuerpo (opcional) también use el imperativo, presente. El cuerpo debe incluir la motivación para el cambio y contrastarla con la conducta anterior. Estás explicando el "por qué", no el "cómo".
|
||||
|
||||
✅ Tómate unos minutos para navegar por GitHub. ¿Puedes encontrar un mensaje de compromiso realmente bueno? ¿Puedes encontrar uno realmente mínimo? ¿Qué información crees que es la más importante y útil de transmitir en un mensaje de compromiso?
|
||||
|
||||
### Tarea: Colaborar
|
||||
|
||||
La razón principal para poner cosas en GitHub fue hacer posible la colaboración con otros desarrolladores.
|
||||
|
||||
## Trabajando en proyectos con otros
|
||||
|
||||
En su repositorio, vaya a `Insights > Community` para ver cómo se compara su proyecto con los estándares comunitarios recomendados.
|
||||
|
||||
Aquí hay algunas cosas que pueden mejorar su repositorio de GitHub:
|
||||
- **Descripción**. ¿Agregaste una descripción para tu proyecto?
|
||||
- **README**. ¿Agregaste un archivo README? GitHub proporciona una guía para escribir un [README](https://docs.github.com/articles/about-readmes/).
|
||||
- **Pauta de contribución**. ¿Su proyecto tiene [pautas de contribución](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/),
|
||||
- **Código de Conducta**. un [Código de conducta](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/),
|
||||
- **Licencia**. Quizás lo más importante, una [licencia](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
|
||||
|
||||
Todos estos recursos beneficiarán la incorporación de nuevos miembros del equipo. Y esos son típicamente el tipo de cosas que los nuevos colaboradores miran antes incluso de mirar su código, para descubrir si su proyecto es el lugar adecuado para que ellos pasen su tiempo.
|
||||
|
||||
✅ Los archivos README, aunque requieren tiempo para prepararse, a menudo son descuidados por los ocupados mantenedores. ¿Puede encontrar un ejemplo de uno particularmente descriptivo? Nota: hay algunas [herramientas para ayudar a crear buenos archivos READMEs](https://www.makeareadme.com/) que le gustaría probar.
|
||||
|
||||
|
||||
### Tarea: Fusionar código
|
||||
|
||||
Los documentos que contribuyen ayudan a las personas a contribuir al proyecto. Explica qué tipos de contribuciones está buscando y cómo funciona el proceso. Los colaboradores deberán seguir una serie de pasos para poder contribuir a su repositorio en GitHub:
|
||||
|
||||
1. **Bifurcando su repositorio** Probablemente querrá que la gente _bifurque_ su proyecto. Bifurcar significa crear una réplica de su repositorio en su perfil de GitHub.
|
||||
1. **Clonar**. Desde allí, clonarán el proyecto en su máquina local.
|
||||
1. **Crea una rama**. Querrá pedirles que creen una _ rama_ para su trabajo.
|
||||
1. **Concentre su cambio en un área**. Pida a los colaboradores que concentren sus contribuciones en una cosa a la vez; de esa manera, las posibilidades de que pueda _fusionar_ en su trabajo son mayores. Imagine que escriben una corrección de errores, agregan una nueva función y actualizan varias pruebas; ¿qué sucede si lo desea o solo puede implementar 2 de 3 o 1 de 3 cambios?
|
||||
|
||||
✅ Imagine una situación en la que las sucursales son particularmente críticas para escribir y enviar un buen código. ¿En qué casos de uso se te ocurren?
|
||||
|
||||
> Tenga en cuenta que sea el cambio que desea ver en el mundo y cree también sucursales para su propio trabajo. Todas las confirmaciones que realice se realizarán en la sucursal en la que está actualmente "registrado". Use `git status` para ver qué rama es esa.
|
||||
|
||||
Repasemos el flujo de trabajo de un colaborador. Suponga que el colaborador ya ha _bifurcado_ y _clonado_ el repositorio para que tenga un repositorio de Git listo para trabajar en su máquina local:
|
||||
|
||||
1. **Crea una rama**. Use el comando `git branch` para crear una rama que contendrá los cambios que pretenden contribuir:
|
||||
|
||||
```bash
|
||||
git branch [branch-name]
|
||||
```
|
||||
|
||||
1. **Cambiar a rama de trabajo**. Cambie a la rama especificada y actualice el directorio de trabajo con `git checkout`:
|
||||
|
||||
```bash
|
||||
git checkout [branch-name]
|
||||
```
|
||||
|
||||
1. **Trabaja**. En este punto, desea agregar sus cambios. No olvide informarle a Git con los siguientes comandos:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "mis cambios"
|
||||
```
|
||||
|
||||
Asegúrese de darle un buen nombre a su compromiso, por su bien y por el mantenedor del repositorio en el que está ayudando.
|
||||
|
||||
1. **Combine su trabajo con la rama `principal`**. En algún momento ha terminado de trabajar y desea combinar su trabajo con el de la rama `principal`. La rama `main` podría haber cambiado mientras tanto, así que asegúrese de actualizarla primero a la última con los siguientes comandos:
|
||||
|
||||
```bash
|
||||
git checkout main
|
||||
git pull
|
||||
```
|
||||
|
||||
En este punto, querrá asegurarse de que cualquier _conflicto_, situaciones en las que Git no pueda _combinarse_ fácilmente los cambios, ocurra en su rama de trabajo. Por lo tanto, ejecute los siguientes comandos:
|
||||
|
||||
```bash
|
||||
git checkout [branch_name]
|
||||
git merge main
|
||||
```
|
||||
|
||||
Esto traerá todos los cambios de `main` a su rama y es de esperar que pueda continuar. De lo contrario, VS Code le dirá dónde está _confundido_ Git y simplemente modificará los archivos afectados para decir qué contenido es el más preciso.
|
||||
|
||||
1. **Envíe su trabajo a GitHub**. Enviar tu trabajo a GitHub significa dos cosas. Empujar su sucursal a su repositorio y luego abrir un PR, Pull Request.
|
||||
|
||||
```bash
|
||||
git push --set-upstream origin [branch-name]
|
||||
```
|
||||
|
||||
El comando anterior crea la rama en su repositorio bifurcado.
|
||||
|
||||
1. **Abra una PR**. A continuación, desea abrir un PR. Para hacerlo, navegue al repositorio bifurcado en GitHub. Verá una indicación en GitHub donde le preguntará si desea crear un nuevo PR, haga clic en eso y lo llevará a una interfaz donde puede cambiar el título del mensaje de confirmación, asígnele una descripción más adecuada. Ahora, el mantenedor del repositorio que bifurcó verá este PR y _dedos cruzados_ apreciarán y _ fusionar_ su PR. Ahora eres un colaborador, yay :)
|
||||
|
||||
1. **Limpiar**. Se considera una buena práctica _limpiar_ después de ti. Desea limpiar tanto su sucursal local como la sucursal que envió a GitHub. Primero eliminémoslo localmente con el siguiente comando:
|
||||
|
||||
```bash
|
||||
git branch -d [branch-name]
|
||||
```
|
||||
|
||||
Asegúrese de ir a la página de GitHub para el repositorio bifurcado a continuación y elimine la rama remota que acaba de ingresar.
|
||||
|
||||
`Solicitud de extracción` parece un término tonto porque realmente desea impulsar los cambios al proyecto. Pero el mantenedor (propietario del proyecto) o el equipo central debe considerar sus cambios antes de fusionarlo con la rama "principal" del proyecto, por lo que realmente está solicitando una decisión de cambio a un mantenedor.
|
||||
|
||||
Una solicitud de extracción es el lugar para comparar y discutir las diferencias introducidas en una rama con revisiones, comentarios, pruebas integradas y más. Una buena solicitud de extracción sigue aproximadamente las mismas reglas que un mensaje de confirmación. Puede agregar una referencia a un problema en el rastreador de problemas, cuando su trabajo, por ejemplo, soluciona un problema. Esto se hace usando un '#' seguido del número de su problema. Por ejemplo, `#97`.
|
||||
|
||||
🤞 Cruce los dedos para que todos los controles pasen y los propietarios del proyecto combinen sus cambios en el proyecto🤞
|
||||
|
||||
Actualice su rama de trabajo local actual con todas las nuevas confirmaciones de la rama remota correspondiente en GitHub:
|
||||
|
||||
`git pull`
|
||||
|
||||
## Cómo contribuir al código abierto
|
||||
|
||||
Primero, busquemos un repositorio (o: repositorio) en GitHub que le interese y al que le gustaría contribuir con un cambio. Querrá copiar el contenido de a nuestra máquina.
|
||||
|
||||
✅ Una buena forma de encontrar repositorios 'aptos para principiantes' es [buscar por la etiqueta `buena-primera-edición`](https://github.blog/2020-01-22-browse-good-first-issues-para-empezar-a-contribuir-al-código-abierto/).
|
||||
|
||||
Hay varias formas de copiar código. Una forma es "clonar" el contenido del repositorio, usando HTTPS, SSH o usando GitHub CLI (Interfaz de línea de comandos).
|
||||
|
||||
Abra su terminal y clone el repositorio así:
|
||||
`git clone https://github.com/ProjectURL`
|
||||
|
||||
Para trabajar en el proyecto, cambie a la carpeta correcta:
|
||||
`cd ProjectURL`
|
||||
|
||||
También puede abrir todo el proyecto utilizando [Codespaces](https://github.com/features/codespaces), el entorno de desarrollo en la nube / editor de código integrado de GitHub o [GitHub Desktop](https://desktop.github.com/).
|
||||
|
||||
Por último, puede descargar el código en una carpeta comprimida.
|
||||
|
||||
### Algunas cosas más interesantes sobre GitHub
|
||||
|
||||
Puede destacar, ver y / o "fork" cualquier repositorio público en GitHub. Puede encontrar sus repositorios destacados en el menú desplegable de la parte superior derecha. Es como marcar como favorito, pero por código.
|
||||
|
||||
Los proyectos tienen un rastreador de problemas, principalmente en GitHub en la pestaña "Issues" a menos que se indique lo contrario, donde las personas debaten los problemas relacionados con el proyecto. Y la pestaña Solicitudes de extracción es donde las personas debaten y revisan los cambios que están en curso.
|
||||
|
||||
Los proyectos también pueden tener discusiones en foros, listas de correo o canales de chat como Slack, Discord o IRC.
|
||||
|
||||
✅ Eche un vistazo a su nuevo repositorio de GitHub y pruebe algunas cosas, como editar la configuración, agregar información a su repositorio y crear un proyecto (como un tablero Kanban). ¡Hay muchas cosas que puedes hacer!
|
||||
|
||||
🚀 Desafío: empareje con un amigo para trabajar en el código del otro. Cree un proyecto de forma colaborativa, bifurque el código, cree ramas y combine los cambios.
|
||||
|
||||
## [Post-lecture prueba](.github/post-lecture-quiz.md)
|
||||
|
||||
## Revisión y autoestudio
|
||||
|
||||
Obtenga más información sobre [contribución al software de código abierto](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
|
||||
|
||||
[Hoja de referencia de Git](https://training.github.com/downloads/github-git-cheat-sheet/).
|
||||
|
||||
Práctica práctica práctica. GitHub tiene excelentes rutas de aprendizaje disponibles a través de [lab.github.com](https://lab.github.com/):
|
||||
|
||||
- [Primera semana en GitHub](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
|
||||
También encontrará laboratorios más avanzados.
|
||||
|
||||
**Tarea**: Completa [la primera semana en el laboratorio de capacitación de GitHub](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
17
1-getting-started-lessons/3-accessibility/.github/post-lecture-quiz.md
vendored
Normal file
17
1-getting-started-lessons/3-accessibility/.github/post-lecture-quiz.md
vendored
Normal file
@@ -0,0 +1,17 @@
|
||||
*Complete this quiz by checking one answer per question.*
|
||||
|
||||
1. Lighthouse only checks for accessibility problems
|
||||
|
||||
- [ ] true
|
||||
- [ ] false
|
||||
|
||||
2. Color-safe palettes help people with
|
||||
|
||||
- [ ] color-blindness
|
||||
- [ ] visual impairments
|
||||
- [ ] both the above
|
||||
|
||||
3. Descriptive links are vital for accessible web sites
|
||||
|
||||
- [ ] true
|
||||
- [ ] false
|
||||
17
1-getting-started-lessons/3-accessibility/.github/pre-lecture-quiz.md
vendored
Normal file
17
1-getting-started-lessons/3-accessibility/.github/pre-lecture-quiz.md
vendored
Normal file
@@ -0,0 +1,17 @@
|
||||
*Complete this quiz in class*
|
||||
|
||||
1. An accessible web site can be checked in which browser tool
|
||||
|
||||
- [ ] Lighthouse
|
||||
- [ ] Deckhouse
|
||||
- [ ] Cleanhouse
|
||||
|
||||
2. You need a physical screen reader to test accessibility for visually-impaired users
|
||||
|
||||
- [ ] true
|
||||
- [ ] false
|
||||
|
||||
3. Accessibility is only important on government web sites
|
||||
|
||||
- [ ] true
|
||||
- [ ] false
|
||||
218
1-getting-started-lessons/3-accessibility/README.md
Normal file
218
1-getting-started-lessons/3-accessibility/README.md
Normal file
@@ -0,0 +1,218 @@
|
||||
# Creating Accessible Webpages
|
||||
|
||||
|
||||
> Sketchnote by [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## [Pre-lecture quiz](.github/pre-lecture-quiz.md)
|
||||
|
||||
> The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.
|
||||
>
|
||||
> \- Sir Timothy Berners-Lee, W3C Director and inventor of the World Wide Web
|
||||
|
||||
This quote perfectly highlights the importance of creating accessible websites. An application that can't be accessed by all is by definition exclusionary. As web developers we should always have accessibility in mind. By having this focus from the beginning you will be well on your way to ensure everyone can access the pages you create. In this lesson, you'll learn about the tools that can help you ensure that your web assets are accessible and how to build with accessibility in mind.
|
||||
|
||||
## Tools to use
|
||||
|
||||
### Screen readers
|
||||
|
||||
One of the best-known accessibility tools are screen readers.
|
||||
|
||||
[Screen readers](https://en.wikipedia.org/wiki/Screen_reader) are commonly used clients for those with vision impairments. As we spend time ensuring a browser properly conveys the information we wish to share, we must also ensure a screen reader does the same.
|
||||
|
||||
At its most basic, a screen reader will read a page from top to bottom audibly. If your page is all text, the reader will convey the information in a similar fashion to a browser. Of course, web pages are rarely purely text; they will contain links, graphics, color, and other visual components. Care must be taken to ensure that this information is read correctly by a screen reader.
|
||||
|
||||
Every web developer should familiarize themselves with a screen reader. As highlighted above, it's the client your users will utilize. Much in the same way you're familiar with how a browser operates, you should learn how a screen reader operates. Fortunately screen readers are built into most operating systems, and many browsers contain extensions to emulate a screen reader.
|
||||
|
||||
✅ Try a screen reader browser extension or tool. One that works on Windows only is [JAWS](https://webaim.org/articles/jaws/). Browsers also have built-in tools that can be used for this purpose; check out [these accessibility-focused Edge browser tools](https://support.microsoft.com/en-us/help/4000734/microsoft-edge-accessibility-features).
|
||||
|
||||
### Contrast checkers
|
||||
|
||||
Colors on web sites need to be carefully chosen to answer the needs of color-blind users or people who have difficulty seeing low-contrast colors.
|
||||
|
||||
✅ Test a web site you enjoy using for color usage with a browser extension such as [WCAG's color checker](https://microsoftedge.microsoft.com/addons/detail/wcag-color-contrast-check/idahaggnlnekelhgplklhfpchbfdmkjp?hl=en-US). What do you learn?
|
||||
|
||||
### Lighthouse
|
||||
|
||||
In the developer tool area of your browser, you'll find the Lighthouse tool. This tool is important to get a first view of the accessibility (as well as other analysis) of a web site. While it's important not to rely exclusively on Lighthouse, a 100% score is very helpful as a baseline.
|
||||
|
||||
✅ Find Lighthouse in your browser's developer tool panel and run an analysis on any site. what do you discover?
|
||||
|
||||
## Designing for accessibility
|
||||
|
||||
Accessibility is a relatively large topic. To help you out, there are numerous resources available.
|
||||
|
||||
- [Accessible U - University of Minnesota](https://accessibility.umn.edu/your-role/web-developers)
|
||||
|
||||
While we won't be able to cover every aspect of creating accessible sites, below are some of the core tenets you will want to implement. Designing an accessible page from the start is **always** easier than going back to an existing page to make it accessible.
|
||||
|
||||
## Good display principles
|
||||
|
||||
### Color safe palettes
|
||||
|
||||
People see the world in different ways, and this includes colors. When selecting a color scheme for your site, you should ensure it's accessible to all. One great [tool for generating color palettes is Color Safe](http://colorsafe.co/).
|
||||
|
||||
✅ Identify a web site that is very problematic in its use of color. Why?
|
||||
|
||||
### Properly highlight text
|
||||
|
||||
Highlighting text by color, [font weight](https://developer.mozilla.org/docs/Web/CSS/font-weight), or other [text decoration](https://developer.mozilla.org/docs/Web/CSS/text-decoration) does not inherently inform a screen reader of its importance. A word could be bold because it's a key word, or because its the first word and the designer decided it should be bold.
|
||||
|
||||
When a particular phrase needs to be highlighted, use the `<strong>` or `<em>` elements. These will indicate to a screen reader that those items are important.
|
||||
|
||||
### Use the correct HTML
|
||||
|
||||
With CSS and JavaScript it's possible to many any element look like any type of control. `<span>` could be used to create a `<button>`, and `<b>` could become a hyperlink. While this might be considered easier to style, it's baffling to a screen reader. Use the appropriate HTML when creating controls on a page. If you want a hyperlink, use `<a>`. Using the right HTML for the right control is called making use of Semantic HTML.
|
||||
|
||||
✅ Go to any web site and see if the designers and developers are using HTML properly. Can you find a button that should be a link? Hint: right click and choose 'View Page Source' in your browser to look at underlying code.
|
||||
|
||||
### Use good visual clues
|
||||
|
||||
CSS offers complete control over the look of any element on a page. You can create text boxes without an outline or hyperlinks without an underline. Unfortunately removing those clues can make it more challenging for someone who depends on them to be able to recognize the type of control.
|
||||
|
||||
## The importance of link text
|
||||
|
||||
Hyperlinks are core to navigating the web. As a result, ensuring a screen reader can properly read links allows all users to navigate your site.
|
||||
|
||||
### Screen readers and links
|
||||
|
||||
As you would expect, screen readers read link text in the same way they'd read any other text on the page. With this in mind, the text demonstrated below might feel perfectly acceptable.
|
||||
|
||||
> The little penguin, sometimes known as the fairy penguin, is the smallest penguin in the world. [Click here](https://en.wikipedia.org/wiki/Little_penguin) for more information.
|
||||
|
||||
> The little penguin, sometimes known as the fairy penguin, is the smallest penguin in the world. Visit https://en.wikipedia.org/wiki/Little_penguin for more information.
|
||||
|
||||
> **NOTE** As you're about to read, you should **never** create links which look like the above.
|
||||
|
||||
Remember, screen readers are a different interface from browsers with a different set of features.
|
||||
|
||||
### The problem with using the URL
|
||||
|
||||
Screen readers read the text. If a URL appears in the text, the screen reader will read the URL. Generally speaking, the URL does not convey meaningful information, and can sound annoying. You may have experienced this if your phone has ever audibly read a text message with a URL.
|
||||
|
||||
### The problem with "click here"
|
||||
|
||||
Screen readers also have the ability to read only the hyperlinks on a page, much in the same way a sighted person would scan a page for links. If the link text is always "click here", all the user will hear is "click here, click here, click here, click here, click here, ..." All links are now indistinguishable from one another.
|
||||
|
||||
### Good link text
|
||||
|
||||
Good link text briefly describes what's on the other side of the link. In the above example talking about little penguins, the link is to the Wikipedia page about the species. The phrase *little penguins* would make for perfect link text as it makes it clear what someone will learn about if they click the link - little penguins.
|
||||
|
||||
> The [little penguin](https://en.wikipedia.org/wiki/Little_penguin), sometimes known as the fairy penguin, is the smallest penguin in the world.
|
||||
|
||||
✅ Surf the web for a few minutes to find pages that use obscure linking strategies. Compare them with other, better-linked sites. What do you learn?
|
||||
|
||||
#### Search engine notes
|
||||
|
||||
As an added bonus for ensuring your site is accessible to all, you'll help search engines navigate your site as well. Search engines use link text to learn the topics of pages. So using good link text helps everyone!
|
||||
|
||||
### ARIA
|
||||
|
||||
Imagine the following page:
|
||||
|
||||
| Product | Description | Order |
|
||||
| ------------ | ------------------ | ------------ |
|
||||
| Widget | [Description]('#') | [Order]('#') |
|
||||
| Super widget | [Description]('#') | [Order]('#') |
|
||||
|
||||
In this example, duplicating the text of description and order make sense for someone using a browser. However, someone using a screen reader would only hear the words *description* and *order* repeated without context.
|
||||
|
||||
To support these types of scenarios, HTML supports a set of attributes known as [Accessible Rich Internet Applications (ARIA)](https://developer.mozilla.org/docs/Web/Accessibility/ARIA). These attributes allow you to provide additional information to screen readers.
|
||||
|
||||
> **NOTE**: Like many aspects of HTML, browser and screen reader support may vary. However, most mainline clients support ARIA attributes.
|
||||
|
||||
You can use `aria-label` to describe the link when the format of the page doesn't allow you to. The description for widget could be set as
|
||||
|
||||
``` html
|
||||
<a href="#" aria-label="Widget description">description</a>
|
||||
```
|
||||
|
||||
✅ In general, using Semantic markup as described above supersedes the use of ARIA, but sometimes there is no semantic equivalent for various HTML widgets. A good example is a Progressbar. There's no HTML equivalent for a progress bar, so you identify the generic `<div>` for this element with a proper role and aria values. The [MDN documentation on ARIA](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA) contains more useful information.
|
||||
|
||||
```html
|
||||
<div id="percent-loaded" role="progressbar" aria-valuenow="75" aria-valuemin="0" aria-valuemax="100">
|
||||
</div>
|
||||
```
|
||||
|
||||
## Images
|
||||
|
||||
It goes without saying screen readers are unable to automatically read what's in an image. Ensuring images are accessible doesn't take much work - it's what the `alt` attribute is all about. All images should have an `alt` to describe what they are.
|
||||
|
||||
✅ As you might expect, search engines are also unable to understand what's in an image. They also use alt text. So once again, ensuring your page is accessible provides additional bonuses!
|
||||
|
||||
## The keyboard
|
||||
|
||||
Some users are unable to use a mouse or trackpad, instead relying on keyboard interactions to tab from one element to the next. It's important for your web site to present your content in logical order so a keyboard can access each element as the user moves down a document. If you build your web pages with semantic markup and use CSS to style their visual layout, your site should be keyboard-navigable, but it's important to test this aspect manually. Learn more about [keyboard navigation strategies](https://webaim.org/techniques/keyboard/).
|
||||
|
||||
✅ Go to any web site and try to navigate through it using only your tab key. What works, what doesn't work? Why?
|
||||
|
||||
## Summary
|
||||
|
||||
A web accessible to some is not a truly 'world-wide web'. The best way to ensure the sites you create are accessible is to incorporate accessibility best practices from the start. While there are extra steps involved, incorporating these skills into your workflow now will mean all pages you create will be accessible.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Challenge
|
||||
|
||||
Take this HTML and rewrite it to be as accessible as possible, given the strategies you learned.
|
||||
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>
|
||||
Example
|
||||
</title>
|
||||
<link href='../assets/style.css' rel='stylesheet' type='text/css'>
|
||||
</head>
|
||||
<body>
|
||||
<div class="site-header">
|
||||
<p class="site-title">Turtle Ipsum</p>
|
||||
<p class="site-subtitle">The World's Premier Turtle Fan Club</p>
|
||||
</div>
|
||||
<div class="main-nav">
|
||||
<p class="nav-header">Resources</p>
|
||||
<div class="nav-list">
|
||||
<p class="nav-item nav-item-bull"><a href="https://www.youtube.com/watch?v=CMNry4PE93Y">"I like turtles"</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="https://en.wikipedia.org/wiki/Turtle">Basic Turtle Info</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="https://en.wikipedia.org/wiki/Turtles_(chocolate)">Chocolate Turtles</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="main-content">
|
||||
<div>
|
||||
<p class="page-title">Welcome to Turtle Ipsum.
|
||||
<a href="">Click here</a> to learn more.
|
||||
</p>
|
||||
<p class="article-text">
|
||||
Turtle ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="footer">
|
||||
<div class="footer-section">
|
||||
<span class="button">Sign up for turtle news</span>
|
||||
</div><div class="footer-section">
|
||||
<p class="nav-header footer-title">
|
||||
Internal Pages
|
||||
</p>
|
||||
<div class="nav-list">
|
||||
<p class="nav-item nav-item-bull"><a href="../">Index</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="../semantic">Semantic Example</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<p class="footer-copyright">© 2016 Instrument</span>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
## [Post-lecture quiz](.github/post-lecture-quiz.md)
|
||||
|
||||
## Review & Self Study
|
||||
|
||||
Many governments have laws regarding accessibility requirements. Read up on your home country's accessibility laws. What is covered, and what isn't? An example is [this government web site](https://accessibility.blog.gov.uk/).
|
||||
|
||||
## Assignment
|
||||
|
||||
[Analyze a non-accessible web site](assignment.md)
|
||||
|
||||
Credits: [Turtle Ipsum](https://github.com/Instrument/semantic-html-sample) by Instrument
|
||||
11
1-getting-started-lessons/3-accessibility/assignment.md
Normal file
11
1-getting-started-lessons/3-accessibility/assignment.md
Normal file
@@ -0,0 +1,11 @@
|
||||
# Analyze a non-accessible web site
|
||||
|
||||
## Instructions
|
||||
|
||||
Identify a web site that you believe is NOT accessible, and create an action plan to improve its accessibility. Your first task would be to identify this site, detail the ways that you think it is inaccessible without using analytic tools, and then put it through a Lighthouse analysis. Take the results of this analysis and outline a detailed plan with a minimum of ten points showing how the site could be improved.
|
||||
|
||||
## Rubric
|
||||
|
||||
| Criteria | Exemplary | Adequate | Needs Improvement |
|
||||
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | --------------------------- |
|
||||
| student report | includes paragraphs on how the site is inadequate, the Lighthouse report captured as a pdf, a list of ten points to improve, with details on how to improve it | missing 20% of the required | missing 50% of the required |
|
||||
@@ -0,0 +1,215 @@
|
||||
# Creación de páginas web accesibles
|
||||
|
||||
|
||||
> Sketchnote por [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## [Pre-lecture prueba](.github/pre-lecture-quiz.md)
|
||||
|
||||
> El poder de la Web está en su universalidad. El acceso de todas las personas independientemente de su discapacidad es un aspecto fundamental.
|
||||
>
|
||||
> \- Sir Timothy Berners-Lee, director del W3C e inventor de la World Wide Web
|
||||
|
||||
Esta cita destaca perfectamente la importancia de crear sitios web accesibles. Una aplicación a la que no pueden acceder todos es, por definición, excluyente. Como desarrolladores web, siempre debemos tener en cuenta la accesibilidad. Al tener este enfoque desde el principio, estará bien encaminado para garantizar que todos puedan acceder a las páginas que crea. En esta lección, aprenderá sobre las herramientas que pueden ayudarlo a asegurarse de que sus activos web sean accesibles y cómo construir teniendo en cuenta la accesibilidad.
|
||||
|
||||
## Herramientas para usar
|
||||
|
||||
### Lectoras de pantalla
|
||||
|
||||
Una de las herramientas de accesibilidad más conocidas son los lectores de pantalla.
|
||||
|
||||
[Lectores de pantalla](https://en.wikipedia.org/wiki/Screen_reader) son clientes de uso común para personas con problemas de visión. A medida que dedicamos tiempo a asegurarnos de que un navegador transmita correctamente la información que deseamos compartir, también debemos asegurarnos de que un lector de pantalla haga lo mismo.
|
||||
|
||||
En su forma más básica, un lector de pantalla leerá una página de arriba a abajo de forma audible. Si su página es todo texto, el lector transmitirá la información de manera similar a un navegador. Por supuesto, las páginas web rara vez son puramente texto; contendrán enlaces, gráficos, color y otros componentes visuales. Se debe tener cuidado para garantizar que un lector de pantalla lea correctamente esta información.
|
||||
|
||||
Todo desarrollador web debería familiarizarse con un lector de pantalla. Como se destacó anteriormente, es el cliente que utilizarán sus usuarios. De la misma manera que está familiarizado con el funcionamiento de un navegador, debe aprender cómo funciona un lector de pantalla. Afortunadamente, los lectores de pantalla están integrados en la mayoría de los sistemas operativos y muchos navegadores contienen extensiones para emular un lector de pantalla.
|
||||
|
||||
✅ Prueba una extensión o herramienta de navegador de lector de pantalla. Uno que solo funciona en Windows es [JAWS](https://webaim.org/articles/jaws/). Los navegadores también tienen herramientas integradas que se pueden utilizar para este propósito; Consulte estas [herramientas de navegador Edge centradas en la accesibilidad](https://support.microsoft.com/en-us/help/4000734/microsoft-edge-accessibility-features).
|
||||
|
||||
### Damas de contraste
|
||||
|
||||
Los colores en los sitios web deben elegirse cuidadosamente para responder a las necesidades de los usuarios daltónicos o de las personas que tienen dificultades para ver colores de bajo contraste.
|
||||
|
||||
✅ Pruebe un sitio web que le guste usar para el uso del color con una extensión de navegador como
|
||||
[WCAG's color checker](https://microsoftedge.microsoft.com/addons/detail/wcag-color-contrast-check/idahaggnlnekelhgplklhfpchbfdmkjp?hl=en-US). ¿Qué aprendes?
|
||||
|
||||
### Lighthouse
|
||||
|
||||
En el área de herramientas para desarrolladores de su navegador, encontrará la herramienta Lighthouse. Esta herramienta es importante para obtener una primera visión de la accesibilidad (así como otros análisis) de un sitio web. Si bien es importante no depender exclusivamente de Lighthouse, una puntuación del 100% es muy útil como referencia.
|
||||
|
||||
✅ Busque Lighthouse en el panel de herramientas de desarrollo de su navegador y ejecute un análisis en cualquier sitio. ¿Qué descubres?
|
||||
|
||||
## Diseñar para la accesibilidad
|
||||
|
||||
La accesibilidad es un tema relativamente extenso. Para ayudarlo, existen numerosos recursos disponibles.
|
||||
|
||||
- [Accessible U - University of Minnesota](https://accessibility.umn.edu/your-role/web-developers)
|
||||
|
||||
Si bien no podremos cubrir todos los aspectos de la creación de sitios accesibles, a continuación se muestran algunos de los principios básicos que querrá implementar. Diseñar una página accesible desde el principio es ** siempre ** más fácil que volver a una página existente para hacerla accesible.
|
||||
|
||||
## Buenos principios de visualización
|
||||
|
||||
### Paletas de colores seguros
|
||||
|
||||
La gente ve el mundo de diferentes formas, y esto incluye los colores. Al seleccionar un esquema de color para su sitio, debe asegurarse de que sea accesible para todos. Uno genial [herramienta para generar paletas de colores es Color Safe](http://colorsafe.co/).
|
||||
|
||||
✅ Identifique un sitio web que sea muy problemático en el uso del color. ¿Por qué?
|
||||
|
||||
### Resaltar correctamente el texto
|
||||
|
||||
Resaltar texto por color, [peso de fuente](https://developer.mozilla.org/docs/Web/CSS/font-weight) u otra [decoración de texto](https://developer.mozilla.org/docs/Web/CSS/text-decoration) no informa inherentemente a un lector de pantalla de su importancia. Una palabra puede ser en negrita porque es una palabra clave o porque es la primera palabra y el diseñador decidió que debería ser en negrita.
|
||||
|
||||
Cuando sea necesario resaltar una frase en particular, utilice los elementos `<strong>` o `<em>`. Estos le indicarán a un lector de pantalla que esos elementos son importantes.
|
||||
|
||||
### Usa el HTML correcto
|
||||
|
||||
Con CSS y JavaScript es posible que muchos elementos se parezcan a cualquier tipo de control. `<span>` podría usarse para crear un `<button>`, y `<b>` podría convertirse en un hipervínculo. Si bien esto podría considerarse más fácil de diseñar, es desconcertante para un lector de pantalla. Utilice el HTML apropiado al crear controles en una página. Si desea un hipervínculo, use `<a>`. Usar el HTML correcto para el control correcto se llama hacer uso de HTML semántico.
|
||||
|
||||
✅ Vaya a cualquier sitio web y vea si los diseñadores y desarrolladores están usando HTML correctamente. ¿Puedes encontrar un botón que debería ser un enlace? Sugerencia: haga clic derecho y elija 'View Page Source' en su navegador para ver el código subyacente.
|
||||
|
||||
### Usa buenas pistas visuales
|
||||
|
||||
CSS ofrece un control completo sobre el aspecto de cualquier elemento de una página. Puede crear cuadros de texto sin contorno o hipervínculos sin subrayado. Desafortunadamente, eliminar esas pistas puede hacer que sea más difícil para alguien que depende de ellas poder reconocer el tipo de control.
|
||||
|
||||
## La importancia del texto del enlace
|
||||
|
||||
Los hipervínculos son fundamentales para navegar por la web. Como resultado, garantizar que un lector de pantalla pueda leer correctamente los enlaces permite a todos los usuarios navegar por su sitio.
|
||||
|
||||
### Lectores de pantalla y enlaces
|
||||
|
||||
Como era de esperar, los lectores de pantalla leen el texto del enlace de la misma forma que leerían cualquier otro texto de la página. Teniendo esto en cuenta, el texto que se muestra a continuación puede parecer perfectamente aceptable.
|
||||
|
||||
> El pequeño pingüino, a veces conocido como el pingüino de hadas, es el pingüino más pequeño del mundo. [Haga clic aquí](https://en.wikipedia.org/wiki/Little_penguin) para obtener más información.
|
||||
|
||||
> El pequeño pingüino, a veces conocido como el pingüino de hadas, es el pingüino más pequeño del mundo. Visite https://en.wikipedia.org/wiki/Little_penguin para obtener más información.
|
||||
|
||||
> ** NOTA ** Mientras estás a punto de leer, ** nunca ** debes crear enlaces que se parezcan al anterior.
|
||||
|
||||
Recuerde, los lectores de pantalla son una interfaz diferente de los navegadores con un conjunto diferente de características.
|
||||
|
||||
### El problema con el uso de la URL
|
||||
|
||||
Los lectores de pantalla leen el texto. Si aparece una URL en el texto, el lector de pantalla leerá la URL. En términos generales, la URL no transmite información significativa y puede sonar molesta. Es posible que haya experimentado esto si su teléfono alguna vez leyó de manera audible un mensaje de texto con una URL.
|
||||
|
||||
### El problema con "haga clic aquí"
|
||||
|
||||
Los lectores de pantalla también tienen la capacidad de leer solo los hipervínculos en una página, de la misma manera que una persona con visión escanea una página en busca de enlaces. Si el texto del vínculo es siempre "haga clic aquí", todo lo que el usuario oirá es "haga clic aquí, haga clic aquí, haga clic aquí, haga clic aquí, haga clic aquí, ..." Todos los enlaces ahora son indistinguibles entre sí.
|
||||
|
||||
### Buen texto de enlace
|
||||
|
||||
Un buen texto de enlace describe brevemente lo que está al otro lado del enlace. En el ejemplo anterior, hablando de pequeños pingüinos, el enlace es a la página de Wikipedia sobre la especie. La frase *pequeños pingüinos* sería un texto de enlace perfecto, ya que deja en claro lo que alguien aprenderá si hace clic en el enlace: pequeños pingüinos.
|
||||
|
||||
> El [pingüino pequeño](https://en.wikipedia.org/wiki/Little_penguin), a veces conocido como el pingüino de hadas, es el pingüino más pequeño del mundo.
|
||||
|
||||
✅ Navegue por la web durante unos minutos para encontrar páginas que utilicen estrategias de enlace poco conocidas. Compárelos con otros sitios mejor vinculados. ¿Qué aprendes?
|
||||
|
||||
#### Notas del motor de búsqueda
|
||||
|
||||
Como una ventaja adicional para garantizar que su sitio sea accesible para todos, también ayudará a los motores de búsqueda a navegar por su sitio. Los motores de búsqueda utilizan el texto del enlace para conocer los temas de las páginas. ¡Así que usar un buen texto de enlace ayuda a todos!
|
||||
|
||||
### ARIA
|
||||
|
||||
Imagina la siguiente página:
|
||||
|
||||
| Producto | Descripción | Orden |
|
||||
| ------------ | ------------------ | ------------ |
|
||||
| Widget | [Descripción]('#') | [Orden]('#') |
|
||||
| Super widget | [Descripción]('#') | [Orden]('#') |
|
||||
|
||||
En este ejemplo, duplicar el texto de descripción y orden tiene sentido para alguien que usa un navegador. Sin embargo, alguien que use un lector de pantalla solo escuchará las palabras * descripción * y * orden * repetidas sin contexto.
|
||||
|
||||
Para admitir este tipo de escenarios, HTML admite un conjunto de atributos conocidos como [Aplicaciones de Internet enriquecidas accesibles (ARIA)](https://developer.mozilla.org/docs/Web/Accessibility/ARIA). Estos atributos le permiten proporcionar información adicional a los lectores de pantalla.
|
||||
|
||||
> **NOTA**: Al igual que muchos aspectos de HTML, la compatibilidad con el navegador y el lector de pantalla puede variar. Sin embargo, la mayoría de los clientes de la línea principal admiten atributos ARIA.
|
||||
|
||||
Puedes usar `aria-label` para describir el enlace cuando el formato de la página no te lo permite. La descripción del widget podría establecerse como
|
||||
|
||||
``` html
|
||||
<a href="#" aria-label="Widget description">descripción</a>
|
||||
```
|
||||
|
||||
✅ En general, el uso de marcado semántico como se describe arriba reemplaza el uso de ARIA, pero a veces no existe un equivalente semántico para varios widgets HTML. Un buen ejemplo es una barra de progreso. No hay un equivalente HTML para una barra de progreso, por lo que identifica el `<div>` genérico para este elemento con un rol y valores de aria adecuados. La [documentación de MDN sobre ARIA](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA) contiene más información útil.
|
||||
|
||||
```html
|
||||
<div id="percent-loaded" role="progressbar" aria-valuenow="75" aria-valuemin="0" aria-valuemax="100">
|
||||
</div>
|
||||
```
|
||||
|
||||
## Imagenes
|
||||
|
||||
No hace falta decir que los lectores de pantalla no pueden leer automáticamente lo que hay en una imagen. Asegurarse de que las imágenes sean accesibles no requiere mucho trabajo; de eso se trata el atributo ʻalt`. Todas las imágenes deben tener un ʻalt` para describir lo que son.
|
||||
|
||||
✅ Como era de esperar, los motores de búsqueda tampoco pueden comprender qué hay en una imagen. También usan texto alternativo. Una vez más, ¡asegurarse de que su página sea accesible proporciona bonificaciones adicionales!
|
||||
|
||||
## El teclado
|
||||
|
||||
Algunos usuarios no pueden usar un mouse o trackpad, sino que dependen de las interacciones del teclado para pasar de un elemento al siguiente. Es importante que su sitio web presente su contenido en un orden lógico para que un teclado pueda acceder a cada elemento a medida que el usuario avanza por un documento. Si construye sus páginas web con marcado semántico y usa CSS para diseñar su diseño visual, su sitio debe ser navegable por teclado, pero es importante probar este aspecto manualmente. Obtenga más información sobre las [estrategias de navegación por teclado](https://webaim.org/techniques/keyboard/).
|
||||
|
||||
✅ Vaya a cualquier sitio web e intente navegar por él utilizando solo la tecla de tabulación. ¿Qué funciona, qué no funciona? ¿Por qué?
|
||||
|
||||
## Resumen
|
||||
|
||||
Una web accesible para algunos no es una verdadera "red mundial". La mejor manera de garantizar que los sitios que cree sean accesibles es incorporar las mejores prácticas de accesibilidad desde el principio. Si bien hay pasos adicionales involucrados, incorporar estas habilidades en su flujo de trabajo ahora significará que todas las páginas que cree serán accesibles.
|
||||
|
||||
🚀 Desafío: tome este HTML y vuelva a escribirlo para que sea lo más accesible posible, dados los temas que aprendió.
|
||||
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>
|
||||
Example
|
||||
</title>
|
||||
<link href='../assets/style.css' rel='stylesheet' type='text/css'>
|
||||
</head>
|
||||
<body>
|
||||
<div class="site-header">
|
||||
<p class="site-title">Turtle Ipsum</p>
|
||||
<p class="site-subtitle">The World's Premier Turtle Fan Club</p>
|
||||
</div>
|
||||
<div class="main-nav">
|
||||
<p class="nav-header">Resources</p>
|
||||
<div class="nav-list">
|
||||
<p class="nav-item nav-item-bull"><a href="https://www.youtube.com/watch?v=CMNry4PE93Y">"I like turtles"</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="https://en.wikipedia.org/wiki/Turtle">Basic Turtle Info</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="https://en.wikipedia.org/wiki/Turtles_(chocolate)">Chocolate Turtles</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="main-content">
|
||||
<div>
|
||||
<p class="page-title">Welcome to Turtle Ipsum.
|
||||
<a href="">Click here</a> to learn more.
|
||||
</p>
|
||||
<p class="article-text">
|
||||
Turtle ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="footer">
|
||||
<div class="footer-section">
|
||||
<span class="button">Sign up for turtle news</span>
|
||||
</div><div class="footer-section">
|
||||
<p class="nav-header footer-title">
|
||||
Internal Pages
|
||||
</p>
|
||||
<div class="nav-list">
|
||||
<p class="nav-item nav-item-bull"><a href="../">Index</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="../semantic">Semantic Example</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<p class="footer-copyright">© 2016 Instrument</span>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
## [Post-lecture prueba](.github/post-lecture-quiz.md)
|
||||
|
||||
## Revisión y autoestudio
|
||||
|
||||
Muchos gobiernos tienen leyes sobre los requisitos de accesibilidad. Lea sobre las leyes de accesibilidad de su país de origen. ¿Qué está cubierto y qué no? Un ejemplo es [este sitio web del gobierno](https://accessibility.blog.gov.uk/).
|
||||
|
||||
** Tarea **: [Analizar un sitio web no accesible](assignment.md)
|
||||
|
||||
Credits: [Turtle Ipsum](https://github.com/Instrument/semantic-html-sample) por Instrument
|
||||
|
||||
> Autor: Christopher Harrison
|
||||
@@ -0,0 +1,12 @@
|
||||
# Analizar un sitio web no accesible
|
||||
|
||||
## Instrucciones
|
||||
|
||||
Identifique un sitio web que crea que NO es accesible y cree un plan de acción para mejorar su accesibilidad. Su primera tarea sería identificar este sitio, detallar las formas en que cree que es inaccesible sin usar herramientas analíticas y luego someterlo a un análisis Lighthouse. Tome los resultados de este análisis y describa un plan detallado con un mínimo de diez puntos que muestre cómo se podría mejorar el sitio.
|
||||
|
||||
## Rúbrica
|
||||
|
||||
| Criterios | Ejemplar | Adecuada | Necesita mejorar |
|
||||
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | --------------------------- |
|
||||
| informe del estudiante | incluye párrafos sobre cómo el sitio es inadecuado, el informe Lighthouse capturado como un pdf, una lista de diez puntos para mejorar, con detalles sobre cómo mejorarlo | falta el 20% de lo requerido | falta el 50% de lo requerido
|
||||
|
|
||||
BIN
1-getting-started-lessons/3-accessibility/webdev101-a11y.png
Normal file
BIN
1-getting-started-lessons/3-accessibility/webdev101-a11y.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 2.0 MiB |
21
1-getting-started-lessons/LICENSE
Normal file
21
1-getting-started-lessons/LICENSE
Normal file
@@ -0,0 +1,21 @@
|
||||
MIT License
|
||||
|
||||
Copyright (c) 2020 WebDev-For-Beginners
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
17
1-getting-started-lessons/README.md
Normal file
17
1-getting-started-lessons/README.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# Getting Started with Web Development
|
||||
|
||||
In this section of the curriculum, you will be introduced to non project-based concepts important to becoming a professional developer.
|
||||
|
||||
### Topics
|
||||
|
||||
1. [Introduction to Programming Languages and Tools of the Trade](1-intro-to-programming-languages/README.md)
|
||||
2. [Basics of GitHub](2-github-basics/README.md)
|
||||
3. [Basics of Accessibility](3-accessibility/README.md)
|
||||
|
||||
### Credits
|
||||
|
||||
Basics of Accessibility was written with ♥️ by [Christopher Harrison](https://twitter.com/geektrainer)
|
||||
|
||||
Introduction to GitHub was written with ♥️ by [Floor Drees](https://twitter.com/floordrees)
|
||||
|
||||
Introduction to Programming Languages and Tools of the Trade was written with ♥️ by [Jasmine Greenaway](https://twitter.com/paladique)
|
||||
Reference in New Issue
Block a user