mirror of
https://github.com/microsoft/Web-Dev-For-Beginners.git
synced 2025-08-21 14:01:34 +02:00
Merge pull request #39 from minwook-shin/ko_translation
[WIP] Add korean translations
This commit is contained in:
Jen Looper
GitHub
@@ -0,0 +1,192 @@
|
||||
# 프로그래밍 언어 및 도구 소개
|
||||
|
||||
이 강의에서는 프로그래밍 언어의 기초를 다룹니다. 여기에서 다루는 주제는 오늘 날 많은 최신 프로그래밍 언어에 적용됩니다. 'Tools of the Trade' 세션에서는 개발자에게 도움이 되는 유용한 소프트웨어에 대해 알아보겠습니다.
|
||||
|
||||
|
||||
> Sketchnote by [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## 강의 전 퀴즈
|
||||
[Pre-lecture quiz](.github/pre-lecture-quiz.md)
|
||||
|
||||
## 소개
|
||||
|
||||
이 강의에서 다음 내용을 다룹니다.
|
||||
|
||||
- 프로그래밍이란?
|
||||
- 프로그래밍 언어의 타입
|
||||
- 프로그램의 기본 요소
|
||||
- 전문적인 개발자를 위한 유용한 소프트웨어와 도구
|
||||
|
||||
## 프로그래밍이란?
|
||||
|
||||
프로그래밍(코딩)은 컴퓨터 또는 모바일에 명령을 내리는 프로세스입니다. 프로그래밍 언어로 명령어를 작성한 후 장치에서 해석합니다. 이러한 명령어 세트는 다양한 이름으로 참조 될 수 있지만 *program*, *computer program*, *application (app)*, 그리고 *executable* 로도 인기있는 이름입니다.
|
||||
|
||||
*program*은 코드로 작성된 모든 것이 될 수 있습니다; 웹 사이트, 게임과 전화 앱도 프로그램입니다. 코드를 작성하지 않고 프로그램을 만들 수는 있지만, 기본 로직은 장치로 해석되며 코드로 작성되었을 가능성이 높습니다. *running* 또는 *executing code* 프로그램이 명령을 수행하고 있습니다. 현재 이 강의를 읽고있는 장치는 화면에 출력하는 프로그램을 실행하고 있습니다.
|
||||
|
||||
✅ 약간의 조사를 해보세요: 세계 최초의 컴퓨터 프로그래머는 누구일까요?
|
||||
|
||||
## 프로그래밍 언어
|
||||
|
||||
프로그래밍 언어는 개발자가 기기에 보낼 명령어를 빌드할 때 사용됩니다. 장치는 바이너리(0과 1)만 이해할 수 있으며, *대부분* 개발자에게는 매우 효율적인 통신 방법이 아닙니다. 프로그래밍 언어는 인간과 컴퓨터의 소통을 위한 방법입니다.
|
||||
|
||||
프로그래밍 언어는 각자 다른 형식으로 제공되며 다른 용도로 사용될 수 있습니다. 예를 들어 JavaScript는 주로 웹 애플리케이션에 사용되지만, Bash는 주로 운영체제에서 사용됩니다.
|
||||
|
||||
*저레벨 언어*는 일반적으로 기기에서 명령을 해석할 때 *고수준 언어*보다 적은 단계로 할 수 있습니다. 그러나 고수준 언어가 인기있는 이유는 가독성과 지원입니다. JavaScript는 고수준 언어로 간주됩니다.
|
||||
|
||||
다음 코드는 JavaScript를 사용하는 고수준 언어와 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
|
||||
```
|
||||
|
||||
안 믿어도 되지만, *두 언어는 같은 일을 하고 있습니다* : 피보나치 수열을 최대 10개까지 출력합니다.
|
||||
|
||||
✅ 피보나치 수열은 각 숫자가 0과 1에서 시작하는 앞의 두 숫자의 합이되는 숫자의 집합으로 [정의](https://en.wikipedia.org/wiki/Fibonacci_number)됩니다.
|
||||
|
||||
## 프로그램의 요소
|
||||
|
||||
프로그램의 단일 명령어를 *statement*라고 불리며, 일반적으로 명령어가 끝나거나 *terminates*되는 위치를 표시하는 문자 또는 줄 간격이 있습니다. 프로그램 종료 방법은 언어마다 다릅니다.
|
||||
|
||||
대부분의 프로그램은 명령을 수행하기 위해 명령문을 데이터에 의존 할 수 있는 사용자 또는 다른 곳의 데이터 사용에 의존합니다. 데이터는 프로그램의 작동 방식을 변경할 수 있으므로 프로그래밍 언어에서 나중에 사용할 수 있는 데이터를 임시 저장하도록 제공합니다. 이 데이터를 *변수*라고 불립니다. 변수는 메모리에 데이터를 저장하도록 장치에 지시하는 명령입니다. 프로그램의 변수는 고유 이름을 가지며, 시간이 지남에 따라 값이 변경 될 수 있는 대수학의 변수와 유사합니다.
|
||||
|
||||
일부 구문이 장치에서 실행되지 않을 가능성이 있습니다. 이는 일반적으로 개발자가 코드 작성할 때 의도적으로 설계되었거나, 오류가 발생할 때 우연히 발생합니다. 이러한 유형의 애플리케이션 제어는 더 강력하게 유지될 수 있도록 합니다. 일반적으로 제어를 변경하려면 특정 조건이 충족되는 순간에 발생합니다. 프로그램 실행 방법을 제어하는 최신 프로그래밍 언어의 일반적인 구문은`if..else` 구문입니다.
|
||||
|
||||
✅ 이후 강의에서 이러한 구문의 타입에 대해 자세히 알아볼 것입니다.
|
||||
|
||||
## Tools of the Trade
|
||||
|
||||
[](https://youtube.com/watch?v=69WJeXGBdxg "Tools of the Trade")
|
||||
|
||||
이 세션에서는 전문적인 개발 여정을 떠날 때 매우 유용할 수 있는 일부 소프트웨어에 대해 알아봅니다.
|
||||
|
||||
**개발 환경**은 개발자가 소프트웨어를 작성할 때 자주 사용하는 도구 및 기능 집합입니다. 이러한 도구 중 일부는 개발자의 특정 요구에 맞게 변경되었으며, 개발자가 작업 또는 개인 프로젝트에서 우선 순위를 변경하거나 다른 프로그래밍 언어를 사용할 때 시간이 지남에 따라 변경 될 수 있습니다. 개발 환경은 이를 사용하는 개발자만큼 독특합니다.
|
||||
|
||||
### 에디터
|
||||
|
||||
소프트웨어 개발을 위한 가장 중요한 도구 중 하나는 에디터입니다. 에디터는 코드를 작성하고 때로는 코드를 실행하는 곳입니다.
|
||||
|
||||
개발자는 몇 가지 추가 이유로 에디터에 의존합니다.
|
||||
|
||||
- *디버깅* 코드를 한 줄씩 단계별로 실행하여 버그와 오류를 발견합니다. 일부 에디터에는 디버깅 기능이 있거나, 특정 프로그래밍 언어에 맞게 변경하거나 추가할 수 있습니다.
|
||||
- *Syntax highlighting* 코드에 색상 및 텍스트 서식을 추가하여 읽기 쉽게 만듭니다. 대부분 에디터에는 Syntax highlighting을 허용합니다.
|
||||
- *확장 및 통합* 기본 에디터에는 없는 추가 도구에 접근하기 위해 개발자를 위한 전문화된 추가 기능입니다. 예를 들어, 많은 개발자는 코드를 문서화하고 작동 방식을 설명하는 방법이 필요하며 오타를 확인하기 위해 맞춤법 검사 확장 프로그램을 설치합니다. 이러한 추가 기능의 대부분은 특정 에디터 내에서 사용하기 위한 것이며, 대부분의 에디터는 사용 가능한 확장 검색을 제공합니다.
|
||||
- *커스터마이즈* 대부분의 에디터는 커스터마이즈가 가능하며 각 개발자는 자신이 필요한 개발 환경을 가지게 됩니다. 또한 많은 개발자가 자신의 확장을 만들 수 있습니다.
|
||||
|
||||
#### 인기있는 에디터와 웹 개발 확장
|
||||
|
||||
- [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)
|
||||
|
||||
### 브라우저
|
||||
|
||||
또 다른 중요 도구는 브라우저입니다. 웹 개발자는 웹에서 코드가 어떻게 실행되는지 보기 위해 브라우저에 의존하며, HTML과 같은 에디터에서 작성된 웹 페이지의 시각적 요소를 보는데도 사용됩니다.
|
||||
|
||||
많은 브라우저에는 개발자가 애플리케이션에 대한 중요한 인사이트를 수집하고 잡아내는 것에 도움이 되는 유용한 기능 및 정보가 포함된 *개발자 도구* (DevTools)가 함께 제공됩니다. 예시: 웹 페이지에 오류가 있는 경우, 오류가 발생한 시기를 아는 것이 도움될 때가 있습니다. 이 정보를 잡을 수 있도록 브라우저의 DevTools를 구성 할 수 있습니다.
|
||||
|
||||
#### 인기있는 브라우저와 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 도구
|
||||
|
||||
일부 개발자는 일상적인 작업에 그래픽 작업을 덜 하기 위해 Command Line에 의존합니다. 코드를 개발하려면 상당한 양의 코드 타이핑이 필요하며, 일부 개발자는 키보드의 흐름을 방해하지 않는 것을 선호하므로 키보드 단축키를 사용하여 데스크톱 창을 전환하여 다른 파일에서 작업하거나, 도구를 사용합니다. 대부분 작업은 마우스로 완료할 수 있지만, Command Line을 사용하는 한 가지 이점은 마우스와 키보드를 서로 바꾸지 않고도 Command Line 도구로 많은 작업을 수행할 수 있다는 것입니다. Command Line의 또 다른 이점은 사용자 지정 구성을 저장하고, 나중에 변경하거나 새 컴퓨터로 개발 할 때 그대로 가져올 수도 있다는 것입니다. 개발 환경은 각 개발자마다 다르기 때문에 일부는 Command Line 사용을 피하고 일부는 전적으로 의존하며 일부는 두 가지를 혼용하여 사용하는 것을 선호합니다.
|
||||
|
||||
### 인기 있는 Command Line 옵션
|
||||
|
||||
command line 옵션은 사용하는 운영체제에 따라 다릅니다.
|
||||
|
||||
*💻 = 운영체제에 사전 설치되어 있습니다.*
|
||||
|
||||
#### 윈도우즈
|
||||
|
||||
- [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/)
|
||||
|
||||
#### 맥OS
|
||||
|
||||
- [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)
|
||||
|
||||
#### 리눅스
|
||||
|
||||
- [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)
|
||||
|
||||
#### 인기있는 Command Line 도구
|
||||
|
||||
- [Git](https://git-scm.com/) (💻 on most operating sytems)
|
||||
- [NPM](https://www.npmjs.com/)
|
||||
- [Yarn](https://classic.yarnpkg.com/en/docs/cli/)
|
||||
|
||||
### 문서
|
||||
|
||||
개발자가 새로운 것을 배우고 싶거나, 방식을 알기 위해 문서를 찾을 가능성이 높습니다. 개발자는 종종 문서에 의존하여 도구와 언어를 올바르게 사용하는 방법을 안내하고, 작동 방식에 대한 더 깊은 지식을 얻습니다.
|
||||
|
||||
#### 웹 개발의 인기있는 문서
|
||||
|
||||
- [Mozilla Developer Network](https://developer.mozilla.org/docs/Web)
|
||||
- [Frontend Masters](https://frontendmasters.com/learn/)
|
||||
|
||||
✅ 약간의 조사를 해보세요: 이제 웹 개발자 환경의 기본 사항을 알았으므로, 웹 디자이너 환경과 비교하고 대조하십시오.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 도전
|
||||
|
||||
일부 프로그래밍 언어를 비교하십시오. JavaScript와 자바의 특징은 무엇입니까? COBOL과 Go는 어떻습니까?
|
||||
|
||||
## 강의 후 퀴즈
|
||||
[Post-lecture quiz](.github/post-lecture-quiz.md)
|
||||
|
||||
## 리뷰 & 자기주도 학습
|
||||
|
||||
프로그래머가 사용할 수 있는 다른 언어에 대해 조금 공부하십시오. 한 언어로 한 줄을 쓴 다음, 다른 언어로 다시 실행하십시오. 무엇을 배우나요?
|
||||
|
||||
## 과제
|
||||
|
||||
[Reading the Docs](assignment.md)
|
||||
@@ -0,0 +1,294 @@
|
||||
# GitHub 소개
|
||||
|
||||
이 강의에서는 코드 변경점을 호스팅하고 관리하는 플랫폼인 GitHub의 기본 사항을 다룹니다.
|
||||
|
||||
|
||||
> Sketchnote by [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## 강의 전 퀴즈
|
||||
[Pre-lecture quiz](.github/pre-lecture-quiz.md)
|
||||
|
||||
## 소개
|
||||
|
||||
이 강의에서는 다룹니다:
|
||||
|
||||
- 기계에서 수행하는 작업 추적
|
||||
- 다른 사람들과 프로젝트 작업
|
||||
- 오픈소스 소프트웨어에 기여하는 방법
|
||||
|
||||
### 작업 필요
|
||||
|
||||
시작하기 전에 Git이 설치되어 있는지 확인해야합니다. 터미널에서 작업:
|
||||
`git --version`
|
||||
|
||||
만약 Git이 설치되어 있지 않다면, [Git 내려받습니다](https://git-scm.com/downloads). 그리고, 터미널에서 로컬 Git 프로필을 설정합니다:
|
||||
* `git config --global user.name "your-name"`
|
||||
* `git config --global user.email "your-email"`
|
||||
|
||||
Git이 이미 구성되어 있는지 확인하려면 다음을 입력합니다:
|
||||
`git config --list`
|
||||
|
||||
GitHub 계정, (Visual Studio Code와 같은) 코드 에디터가 필요하며, 터미널(혹은: command prompt)을 열어야 합니다.
|
||||
|
||||
아직 계정이 없는 경우에는 [github.com](https://github.com/)으로 이동하여 계정을 생성하거나, 로그인하여 프로필을 작성합니다.
|
||||
|
||||
✅ GitHub는 유일한 코드 저장소가 아닙니다. 다른 곳들도 있지만 GitHub가 가장 잘 알려져 있습니다.
|
||||
|
||||
### 준비
|
||||
|
||||
로컬 장치(노트북 또는 PC)에 코드 프로젝트 폴더와 다른 프로젝트에 기여하는 방법의 예시가 될 GitHub 공개 저장소가 모두 필요합니다.
|
||||
|
||||
---
|
||||
|
||||
## 코드 관리
|
||||
|
||||
일부 코드 프로젝트에 포함된 폴더가 로컬에 있고 버전 제어 시스템인 git을 사용하여 진행 상황을 추적하려고 한다고 가정해보겠습니다. 어떤 사람들은 git을 사용하여 미래의 자신에게 연애 편지를 쓰는 것과 비교합니다. 며칠, 몇 주 또는 몇 달 후에 커밋 메시지를 읽으면 그 때 결정을 한 이유를 기억하거나 변경점을 "롤백"할 수 있습니다. 즉, 좋은 "커밋 메시지"를 작성할 때입니다.
|
||||
|
||||
### 작업: 저장소 만들고 코드 커밋하기
|
||||
|
||||
1. **GitHub에 저장소 만들기**. GitHub.com에서 repositories 탭을 보거나, 우측 상단 네비케이션 바에서 **new repo** 버튼을 찾습니다.
|
||||
|
||||
1. 저장소(폴더)에 이름을 지정합니다
|
||||
1. **create repository** 선택합니다.
|
||||
|
||||
1. **작업 폴더로 이동하기**. 터미널에서 추적을 시작할 폴더(디렉토리)로 이동하기 위해 입력합니다:
|
||||
|
||||
```bash
|
||||
cd [name of your folder]
|
||||
```
|
||||
|
||||
1. **git 저장소 초기화하기**. 프로젝트에서 입력합니다:
|
||||
|
||||
```bash
|
||||
git init
|
||||
```
|
||||
|
||||
1. **상태 확인하기**. 상태를 확인하려면 저장소에서 입력합니다:
|
||||
|
||||
```bash
|
||||
git status
|
||||
```
|
||||
|
||||
다음과 같이 출력될 수 있습니다:
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
일반적으로 `git status` 명령은 어떤 파일이 저장소에 _저장_ 될 준비가 되었는 지 또는 유지하고 싶은 변경점이 있는 지 등을 알려줍니다.
|
||||
|
||||
1. **추적할 파일 추가하기**
|
||||
|
||||
```bash
|
||||
git add .
|
||||
```
|
||||
|
||||
`git add`와 같이 있는 `.` 인수는 모든 파일 및 변경점을 나타냅니다.
|
||||
|
||||
1. **작업 지속하기**. Git이 파일을 추적하는 곳에 _staging area_ 라는 파일을 추가했습니다. 영구적으로 변경하려면 파일을 _commit_ 해야합니다. 그렇게 하려면`git commit` 명령으로 _commit_ 을 생성합니다. _commit_ 은 저장소 기록의 저장 시점을 나타냅니다. 다음을 입력하여 _commit_ 을 생성합니다:
|
||||
|
||||
```bash
|
||||
git commit -m "first commit"
|
||||
```
|
||||
|
||||
이렇게하면 모든 파일이 커밋되고, "first commit" 메시지가 추가됩니다. 향후 커밋 메시지의 경우 변경점을 전달하기 위해 설명을 구체적으로 작성해야합니다.
|
||||
|
||||
1. **GitHub와 로컬 Git 저장소 연결하기**. Git 저장소는 장치에 존재하기에 좋지만, 어느 시점에서 파일을 어딘가에 백업하고 다른 사람이 저장소에서 함께 작업하도록 초대하고 싶습니다. 그렇게 하기에 좋은 곳 중 하나는 GitHub입니다. 이미 GitHub에 저장소를 만들었으므로 로컬 Git 저장소를 GitHub에 연결할 뿐입니다. `git remote add` 명령을 수행합니다. 다음 명령을 입력합니다:
|
||||
|
||||
> Note, 명령을 입력하기 전에 GitHub 저장소 페이지로 이동하여 저장소 URL을 찾아두십시오. 아래 명령에서 사용됩니다. `repository_name`을 GitHub URL로 바꿉니다.
|
||||
|
||||
```bash
|
||||
git remote add origin https://github.com/username/repository_name.git
|
||||
```
|
||||
|
||||
이렇게 이전에 만든 GitHub 저장소를 가리키는 "origin"이라는 _remote_ 또는 커넥션이 생성됩니다.
|
||||
|
||||
1. **GitHub로 로컬 파일 보내기**. 지금까지 로컬 저장소와 GitHub 저장소 사이에 _connection_ 을 생성했습니다. 다음과 같이 `git push` 명령을 사용하여 이러한 파일을 GitHub로 보냅니다:
|
||||
|
||||
```bash
|
||||
git push -u origin main
|
||||
```
|
||||
|
||||
"main" 브랜치는 GitHub로 커밋이 보내집니다.
|
||||
|
||||
1. **더 많은 변경점 추가하기**. 계속 작업하여 GitHub로 푸시하려면 다음 세 가지 명령을 사용하면됩니다:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "type your commit message here"
|
||||
git push
|
||||
```
|
||||
|
||||
> Tip, 추적하고 싶지 않은 파일이 GitHub에 표시되는 것을 방지하기 위해 `.gitignore` 파일을 채용할 수 있습니다. 동일한 폴더에 저장하지만 공개 저장소에는 존재하지 않는 노트 파일과 같습니다. `.gitignore` 파일의 템플릿은 [.gitignore templates](github.com/github/gitignore)에서 찾을 수 있습니다.
|
||||
|
||||
#### 커밋 메시지
|
||||
|
||||
A great Git commit subject line completes the following sentence:
|
||||
If applied, this commit will <your subject line here>
|
||||
|
||||
훌륭한 Git 커밋 제목 줄은 다음 문장을 완성합니다:
|
||||
적용되면, 이 커밋은 <your subject line here>이 됩니다.
|
||||
|
||||
제목에 대해서는 명령문 또는 현재 시제를 사용하십시오 : "변경됨" 또는 "변경점"이 아닌 "변경".
|
||||
제목과 마찬가지로 본문(선택 사항)에서도 명령문, 현재 시제를 사용합니다. 본문은 변화에 대한 동기를 포함하고 이를 이전 변경점과 대조해야 합니다. '어떻게'가 아니라 '왜'를 설명하고 있습니다.
|
||||
|
||||
✅ 몇 분 동안 GitHub를 둘러보세요. 정말 훌륭한 커밋 메시지를 찾을 수 있습니까? 정말 최소한의 것을 찾을 수 있습니까? 커밋 메시지에서 전달하는 데 가장 중요하고 유용한 정보는 무엇이라고 생각하십니까?
|
||||
|
||||
### 작업: 협업하기
|
||||
|
||||
GitHub에 코드를 올리는 주 이유는 다른 개발자와 협력할 수 있도록 하기 위함입니다.
|
||||
|
||||
## 다른 사람들과 함께 프로젝트 작업하기
|
||||
|
||||
저장소에서, `Insights> Community`로 이동하여 프로젝트에 권장되는 커뮤니티 표준과 어떻게 비교되는지 확인합니다.
|
||||
|
||||
다음은 GitHub 저장소를 개선 할 수있는 몇 가지 사항입니다:
|
||||
- **설명**. 프로젝트에 설명을 추가했습니까?
|
||||
- **README**. README를 추가했습니까? GitHub는 [README](https://docs.github.com/articles/about-readmes/) 작성에 대한 지침을 제공합니다.
|
||||
- **기여 가이드**. [기여 가이드](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/),
|
||||
- **Code of Conduct**. [Code of Conduct](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/),
|
||||
- **라이선스**. 아마도, 가장 중요한 [라이선스](https://docs.github.com/articles/adding-a-license-to-a-repository/)도 가지고 있습니까?
|
||||
|
||||
이러한 모든 리소스는 새로운 팀원을 온보딩하는 데 도움이 됩니다. 그리고 일반적으로 새로운 기여자들이 여러분의 프로젝트가 시간을 보내기에 적합한 장소인지 확인하기 위해 코드를 보기 전 살펴 보는 것입니다.
|
||||
|
||||
✅ README 파일은 준비하는 데 시간이 걸리지만 바쁜 관리자들은 종종 무시합니다. 특히 설명적인 예를 찾을 수 있습니까? Note: 몇 가지 [tools to help create good READMEs](https://www.makeareadme.com/)를 시도해 볼 수 있습니다.
|
||||
|
||||
### 작업: 코드 병합하기
|
||||
|
||||
문서를 제공하면 사람들이 프로젝트에 기여하는 데 도움이 됩니다. 찾고있는 기여 유형과 프로세스 작동 방식을 설명합니다. 기여자는 GitHub의 저장소에 기여할 수 있도록 일련의 단계를 거쳐야합니다:
|
||||
|
||||
1. **저장소 포크하기** 아마도 사람들이 당신의 프로젝트를 _fork_ 하기를 원할 것입니다. 포크는 자신의 GitHub 프로필에 저장소 복제본을 만드는 걸 의미합니다.
|
||||
1. **복제하기**. 프로젝트를 로컬 컴퓨터에 복제합니다.
|
||||
1. **브랜치 생성하기**. 작업을 위해 _branch_ 를 만들도록 요청하고 싶을 것입니다.
|
||||
1. **한 영역에 변화를 집중하기**. 기여자에게 한 번에 한 가지만 집중하도록 요청하세요 - 그러면 작업에 _병합_ 할 수 있는 가능성이 더 높아집니다. 그들이 버그 수정을 작성하고, 새로운 기능을 추가하고, 여러 테스트를 추가한다고 상상해보십시오. 원한다면 3개 중 2개 또는 3개 중 1개만 구현할 수 있습니까?
|
||||
|
||||
✅ 좋은 코드를 작성하고 전달하는 데 branches가 중요한 상황을 상상해보십시오. 어떤 사용 사례를 생각할 수 있습니까?
|
||||
|
||||
> Note, 모두가 보고싶은 변경점이나, 자신의 작업만을 위한 브랜치를 만들 수도 있습니다. 모든 커밋은 현재 "체크 아웃"된 브랜치에서 이루어집니다. `git status`를 사용하여 어떤 브랜치인지 확인하십시오.
|
||||
|
||||
기여자 워크플로우를 살펴봅니다. 기여자가 이미 저장소를 _forked_ 하거나 _cloned_ 했기 때문에 로컬 머신에서 작업할 준비가 된 Git 저장소가 있다고 가정합니다.
|
||||
|
||||
1. **브랜치 생성하기**. `git branch` 명령을 사용하여 기여하려는 변경 사항을 포함하는 브랜치를 만듭니다:
|
||||
|
||||
```bash
|
||||
git branch [branch-name]
|
||||
```
|
||||
|
||||
1. **작업 브랜치 변경하기**. 지정된 브랜치로 전환하고 `git checkout`으로 작업 디렉토리를 업데이트합니다:
|
||||
|
||||
```bash
|
||||
git checkout [branch-name]
|
||||
```
|
||||
|
||||
1. **일하기**. 이 시점에서 변경 사항을 추가하려고 합니다. 다음 명령을 사용하여 Git에 알리는 것을 잊지 마시기 바랍니다:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "my changes"
|
||||
```
|
||||
|
||||
도와주고 있는 저장소의 관리자뿐만 아니라 당신을 위해서, 커밋에 좋은 이름을 부여해야 합니다.
|
||||
|
||||
1. **`main` 브랜치에서 작업하기**. 어느 시점에서 작업을 마치고 `main` 브랜치의 작업과 병합하려고 합니다. 그동안 `main` 브랜치가 변경되었을 수 있으므로, 먼저 다음 명령을 사용하여 최신 버전으로 업데이트해야합니다:
|
||||
|
||||
```bash
|
||||
git checkout main
|
||||
git pull
|
||||
```
|
||||
|
||||
이 시점에서 Git이 변경 사항을 쉽게 _결합_ 할 수 없는 _충돌_ 상황이 작업 브랜치에서 발생하는지 확인하려고합니다. 따라서 다음 명령을 실행합니다:
|
||||
|
||||
```bash
|
||||
git checkout [branch_name]
|
||||
git merge main
|
||||
```
|
||||
|
||||
이렇게하면 `main` 에서 브랜치로 모든 변경점을 가져올 수 있으며 계속 진행할 수 있습니다. 그렇지 않은 경우에는 VS Code는 Git이 _혼란스러운_ 위치를 알려주고 영향받는 파일을 변경하여 가장 정확한 곳을 알려주면 됩니다.
|
||||
|
||||
1. **GitHub로 작업 보내기**. 작업을 GitHub에 보내는 것은 두 가지를 의미합니다. 브랜치를 저장소로 푸시 한 다음 PR, Pull Request를 엽니다.
|
||||
|
||||
```bash
|
||||
git push --set-upstream origin [branch-name]
|
||||
```
|
||||
|
||||
위의 명령은 포크된 저장소에 브랜치를 만듭니다.
|
||||
|
||||
1. **PR 열기**. 다음으로, PR을 열고 싶습니다. GitHub의 포크된 저장소로 이동하면 됩니다. GitHub에서 새 PR을 만들 것인지 묻는 표시가 표시되고 이를 클릭하면 커밋 메시지 제목을 변경할 수 있는 인터페이스로 이동하게 되며 더 적절한 설명을 작성할 수 있습니다. 이제 포크한 저장소의 관리자는 이 PR을 보고 _행운을 빌며_ 감사하고 _병합_ PR을 수행합니다. 당신은 이제 기여자입니다, yay :)
|
||||
|
||||
1. **정라하기**. 나중에 _정리_ 하는 것은 좋은 습관으로 간주됩니다. 로컬 브랜치와 GitHub에 푸시한 브랜치를 모두 정리하려고 합니다. 먼저 다음 명령을 사용하여 로컬에서 삭제하겠습니다:
|
||||
|
||||
```bash
|
||||
git branch -d [branch-name]
|
||||
```
|
||||
|
||||
포크된 저장소의 GitHub 페이지로 이동하여 방금 푸시한 원격 브랜치를 제거합니다.
|
||||
|
||||
변경점을 프로젝트에 푸시하고 싶기 때문에 `Pull request`는 어리석은 용어처럼 보입니다. 그러나 관리자(프로젝트 소유자) 또는 핵심 팀은 변경점을 프로젝트의 "main" 브랜치와 병합하기 전에 고려해야 하므로 실제로 유지 관리자에게 결정을 요청하는 것입니다.
|
||||
|
||||
pull request는 리뷰, 코멘트, 통합 테스트 등을 통해 브랜치에 도입된 차이점을 비교하고 논의하는 곳입니다. 좋은 pull request는 커밋 메시지와 거의 동일한 규칙을 따릅니다. 예를 들어 작업에서 문제를 해결할 때 이슈 트래커에서 이슈에 대한 참조를 추가할 수 있습니다. 이 작업은 `#` 다음에 이슈 번호를 사용하여 수행됩니다. 예를 들어 `#97` 처럼 말입니다.
|
||||
|
||||
🤞 모든 검사가 통과되고 프로젝트 소유자가 변경 사항을 프로젝트에 병합한다는 손가락이 교차했습니다 🤞
|
||||
|
||||
현재 로컬 작업 브랜치를 GitHub의 원격 브랜치의 커밋으로 모두 업데이트합니다:
|
||||
|
||||
`git pull`
|
||||
|
||||
## 오픈소스에 기여하는 방법
|
||||
|
||||
먼저, GitHub에서 관심있고 변경 사항을 기여할 저장소를 찾아 보겠습니다. 그 곳의 내용을 자신의 장치에 복사하고 싶을 것입니다.
|
||||
|
||||
✅ '입문-친화적'인 저장소를 찾는 좋은 방법은 ['good-first-issue 태그로 검새'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
|
||||
|
||||
|
||||
|
||||
코드를 복사하는 방법에는 여러 가지가 있습니다. 한 가지 방법은 HTTPS, SSH 또는 GitHub CLI (Command Line 인터페이스)를 사용하여 저장소의 내용을 "복제"하는 것입니다.
|
||||
|
||||
터미널을 열고 다음과 같이 저장소를 복제합니다:
|
||||
`git clone https://github.com/ProjectURL`
|
||||
|
||||
프로젝트에서 작업하려면 올바른 폴더로 전환합니다:
|
||||
`cd ProjectURL`
|
||||
|
||||
[Codespaces](https://github.com/features/codespaces), GitHub의 내장 코드 에디터 / 클라우드 개발 환경 또는 [GitHub Desktop](https://desktop.github.com/)을 사용하여 전체 프로젝트를 열 수 있습니다.
|
||||
|
||||
마지막으로 압축된 폴더로 코드를 내려받을 수 있습니다.
|
||||
|
||||
### GitHub에 대한 몇 가지 흥미로운 사항
|
||||
|
||||
GitHub의 모든 공개 저장소에 스타 표시, 워치 및/또는 "포크" 할 수 있습니다. 우측 상단 드롭다운 메뉴에서 스타 표시한 저장소를 찾을 수 있습니다. 북마크와 비슷하지만 코드를 위한 것 입니다.
|
||||
|
||||
프로젝트에는 달리 명시되지 않는 한 대부분 GitHub에 "이슈" 탭의 이슈 트레커가 있습니다. 그리고 Pull Requests 탭은 사람들이 진행중인 변경 사항을 논의하고 검토하는 곳입니다.
|
||||
|
||||
프로젝트는 포럼, 메일링 리스트 또는 Slack, Discord 또는 IRC와 같은 채팅 채널에서 토론 할 수도 있습니다.
|
||||
|
||||
✅ 새로운 GitHub 리포지토리를 둘러보고 설정 편집, 저장소 정보 추가, (Kanban 보드와 같은) 프로젝트 생성을 비롯한 몇 가지 작업을 시도해보시기 바랍니다. 할 수 있는 일이 많이 있습니다!
|
||||
|
||||
---
|
||||
|
||||
## 🚀 도전
|
||||
|
||||
친구와 페어링하여 서로의 코드를 작업하세요. 공동으로 프로젝트를 만들고, 코드를 포크하고, 브랜치를 만들고, 변경 사항을 병합합니다.
|
||||
|
||||
## 강의 후 퀴즈
|
||||
[Post-lecture quiz](.github/post-lecture-quiz.md)
|
||||
|
||||
## 리뷰 & 자기주도 학습
|
||||
|
||||
[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에는 [lab.github.com](https://lab.github.com/)을 통해 사용할 수 있는 훌륭한 학습 경로가 있습니다:
|
||||
|
||||
- [First Week on GitHub](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
|
||||
더 많은 고급 실습도 찾을 수 있습니다.
|
||||
|
||||
## 과제
|
||||
|
||||
[the First Week on GitHub training lab](https://lab.github.com/githubtraining/first-week-on-github) 완료하기
|
||||
@@ -0,0 +1,220 @@
|
||||
# 접근 가능한 웹 페이지 생성하기
|
||||
|
||||
|
||||
> Sketchnote by [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## 강의 전 퀴즈
|
||||
[Pre-lecture quiz](.github/pre-lecture-quiz.md)
|
||||
|
||||
> 웹의 힘은 보편성에 있습니다. 장애에 관계없이 모든 사람이 접근하는 것은 필수 요소입니다.
|
||||
>
|
||||
> \- Sir Timothy Berners-Lee, W3C Director and inventor of the World Wide Web
|
||||
|
||||
이 인용문은 접근 가능한 웹 사이트를 만든다는 것의 중요성을 완벽하게 강조합니다. 모든 사람이 접근할 수 없는 애플리케이션은 정의에 따라 제외됩니다. 웹 개발자로서 우리는 항상 접근성을 염두에 두어야합니다. 처음부터 이 곳에 초점을 두면 모든 사람이 자신이 만든 페이지에 접근할 수 있도록 하는 데 도움이 됩니다. 이 강의에서는 웹 어셋에 접근할 수 있는지 확인하는 데 도움이 되는 도구와 접근성을 염두에 두고 빌드하는 방법에 대해 알아 봅니다.
|
||||
|
||||
## 사용 도구
|
||||
|
||||
### 스크린 리더
|
||||
|
||||
가장 잘 알려진 접근성 도구 중 하나는 스크린 리더입니다.
|
||||
|
||||
[스크린 리더](https://en.wikipedia.org/wiki/Screen_reader)는 시각 장애가 있는 사람들을 위해 일반적으로 사용되는 클라이언트입니다. 브라우저에서 공유하려는 정보를 올바르게 전달하는지 확인하는 데 시간을 할애 할 때 스크린 리더도 동일한 작업을 수행하도록 해야합니다.
|
||||
|
||||
가장 기본적인 스크린 리더는 페이지를 위에서 아래로 소리내며 읽습니다. 페이지가 모두 텍스트인 경우 리더는 브라우저와 유사한 방식으로 정보를 전달합니다. 물론 웹 페이지는 문자 그대로가 아닌 텍스트가 있습니다. 여기에는 링크, 그래픽, 색상 및 기타 시각적 구성 요소가 포함됩니다. 스크린 리더가 정보를 올바르게 읽을 수 있도록 주의를 기울여야 합니다.
|
||||
|
||||
모든 웹 개발자는 스크린 리더에 익숙해야합니다. 위에서 강조한 것처럼 사용자가 활용할 클라이언트입니다. 브라우저가 작동하는 방식에 익숙한 것과 마찬가지로 스크린 리더가 작동하는 방식을 배워야합니다. 다행히 스크린 리더는 대부분의 운영체제에 내장되어 있으며, 많은 브라우저에는 스크린 리더를 모방하는 확장이 포함되어 있습니다.
|
||||
|
||||
✅ 스크린 리더 브라우저 확장이나 도구를 시도해보세요.[JAWS](https://webaim.org/articles/jaws/)는 윈도우에서만 작동합니다. 브라우저에는 이러한 목적으로 사용할 수 있는 내장 도구도 있습니다; [these accessibility-focused Edge browser tools](https://support.microsoft.com/en-us/help/4000734/microsoft-edge-accessibility-features) 확인합니다.
|
||||
|
||||
### Contrast checkers
|
||||
|
||||
웹 사이트의 색상은 색맹 혹은 저대비 색상을 보기 어려운 사람들의 요구에 맞게 신중하게 선택해야 합니다.
|
||||
|
||||
✅ [WCAG's color checker](https://microsoftedge.microsoft.com/addons/detail/wcag-color-contrast-check/idahaggnlnekelhgplklhfpchbfdmkjp?hl=en-US)와 같은 브라우저 확장 프로그램을 사용하여 어떤 색상을 쓰는 지 웹 사이트를 테스트합니다. 무엇을 배울 수 있나요?
|
||||
|
||||
### Lighthouse
|
||||
|
||||
브라우저의 개발자 도구에서 Lighthouse 도구를 찾을 수 있습니다. 이 도구는 웹 사이트의 접근성(기타 분석)을 처음으로 파악하는 데 중요합니다. Lighthouse에만 의존하지 않는 것은 중요하지만, 100점을 기준으로 보면 매우 유용합니다.
|
||||
|
||||
✅ 브라우저의 개발자 도구 패널에서 Lighthouse를 찾아 모든 사이트에서 분석을 실행하세요. 무엇을 발견했나요?
|
||||
|
||||
## 접근성을 위한 디자인
|
||||
|
||||
접근성은 비교적 큰 주제입니다. 도움을 주기 위한 다양한 리소스들이 있습니다.
|
||||
|
||||
- [Accessible U - University of Minnesota](https://accessibility.umn.edu/your-role/web-developers)
|
||||
|
||||
접근 가능한 사이트를 만드는 모든 사항을 다룰 수 없지만, 이는 구현하려는 핵심 원칙 중 일부입니다. 처음부터 접근 가능한 페이지를 기획하는 것은 접근할 수 있도록 기존 페이지로 돌아가는 것보다 **항상** 쉽습니다.
|
||||
|
||||
## 좋은 디스플레이 원칙
|
||||
|
||||
### 색상 안전 팔레트
|
||||
|
||||
사람들은 세상을 다른 방식으로 봅니다. 여기에는 색상도 포함됩니다. 사이트에 대한 색상 스키마를 선택할 때 모든 사람이 접근할 수 있는지 확인해야 합니다. [색상 팔레트를 생성하는 한 가지 훌륭한 도구는 Color Safe](http://colorsafe.co/)입니다.
|
||||
|
||||
✅ 색상을 사용할 때 매우 문제가 있는 웹 사이트를 식별하십시오. 왜 해야될까요?
|
||||
|
||||
### 텍스트를 적절하게 강조하기
|
||||
|
||||
색상, [font weight](https://developer.mozilla.org/docs/Web/CSS/font-weight) 또는 기타 [text decoration](https://developer.mozilla.org/docs/Web/CSS/text-decoration)으로 텍스트를 강조하는 것은 본질적으로 스크린 리더에 중요하다고 알리지 않습니다. 단어는 키워드이기 때문에 굵게 표시되었거나 첫 번째 단어 혹은 디자이너가 굵게 표시해야한다고 결정했기 때문입니다.
|
||||
|
||||
특정 구문을 강조 표시해야 하는 경우에는, `<strong>` 또는 `<em>` 요소를 사용하세요. 이는 스크린 리더에 해당 항목이 중요함을 나타냅니다.
|
||||
|
||||
### 올바른 HTML 사용하기
|
||||
|
||||
CSS와 JavaScript를 사용하면 많은 요소가 모든 유형를 제어할 수 있는 것처럼 보일 수 있습니다. `<span>` 은`<button>` 을 만드는 데 사용할 수 있으며, `<b>` 는 하이퍼 링크가 될 수 있습니다. 스타일링이 더 쉽다고 생각될 수 있지만, 스크린 리더에게는 당황스럽습니다. 페이지에 컨트롤을 만들 때는 적절한 HTML을 사용하십시오. 하이퍼 링크를 원하면 `<a>` 를 사용하세요. 올바른 제어를 위해 올바른 HTML을 사용하는 것은 Semantic HTML이라고 의미합니다.
|
||||
|
||||
✅ 웹 사이트로 이동하여 디자이너와 개발자가 HTML을 올바르게 사용하고 있는지 확인하십시오. 링크의 역할을 하는 버튼을 찾을 수 있나요? Hint: 기반 코드를 보려면 브라우저에서 마우스 우측 버튼을 클릭하고 'View Page Source'를 선택하십시오.
|
||||
|
||||
### 좋은 시각적 단서를 사용하기
|
||||
|
||||
CSS는 페이지에 있는 모든 요소의 형태를 완벽하게 제어합니다. 윤곽선없이 텍스트 상자를 만들거나 밑줄없이 하이퍼 링크를 만들 수 있습니다. 불행히도 이러한 단서를 제거하면 그 단서를 의존하는 사람이 제어 유형을 인식하는 것이 더 어려워질 수 있습니다.
|
||||
|
||||
## 링크 텍스트의 중요성
|
||||
|
||||
하이퍼 링크는 웹 탐색의 핵심 기능입니다. 결과적으로 스크린 리더가 링크를 제대로 읽을 수 있도록 한다면 모든 사용자가 사이트를 탐색할 수 있습니다.
|
||||
|
||||
### 스크린 리더 및 링크
|
||||
|
||||
예상대로 스크린 리더는 페이지 내부의 다른 텍스트를 읽는 것과 같은 방식으로 링크 텍스트를 읽습니다. 이를 염두하고 아래 설명된 텍스트는 완벽하게 수용 가능하다고 느낄 수 있습니다.
|
||||
|
||||
> 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** 읽으려고 한다면, 위와 같은 링크는 **절대** 만들지 않아야 합니다.
|
||||
|
||||
다시 말하지만, 스크린 리더는 브라우저마다 기능이 다른 인터페이스입니다.
|
||||
|
||||
### URL 사용 문제점
|
||||
|
||||
스크린 리더는 텍스트를 읽습니다. 텍스트에 URL이 표시되면, 스크린 리더가 URL을 읽습니다. 일반적으로 URL은 의미있는 정보를 전달하지 않으며, 불편하게 들릴 수 있습니다. 스마트폰에서 URL이 포함된 문자 메시지를 음성으로 읽은 적이 있다면 이 문제를 경험했을 수 있습니다.
|
||||
|
||||
### "click here"의 문제점
|
||||
|
||||
스크린 리더는 또한 시력이 있는 사람이 페이지에서 링크를 찾는 것과 동일한 방식으로 페이지의 하이퍼 링크만 읽을 수 있습니다. 링크 텍스트가 항상 "click here"인 경우 사용자는 "click here, click here, click here, click here, click here, ..." 라는 소리를 들을 수 있습니다. 이는 모든 링크를 서로 구별할 수 없습니다.
|
||||
|
||||
### 좋은 링크 텍스트
|
||||
|
||||
좋은 링크 텍스트는 링크의 다른 측면에 있는 내용을 간략하게 설명합니다. 작은 펭귄에 대해 이야기하는 예시에서 링크는 종에 대한 Wikipedia 페이지로 연결됩니다. *little penguins* 라는 문구는 누군가가 링크를 클릭하면 무엇을 배울 수 있는지를 명확하게 해주기 때문에 완벽한 링크 텍스트가 됩니다.-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.
|
||||
|
||||
✅ 모호한 연결 전략을 사용하는 페이지를 찾으려면 몇 분 동안 웹을 검색하십시오. 연결이 더 좋은 다른 사이트와 비교하십시오. 무엇을 배울 수 있나요?
|
||||
|
||||
#### 검색 엔진 노트
|
||||
|
||||
모든 사람이 사이트에 접근할 수 있도록 하면 추가 보너스로 검색 엔진이 사이트를 탐색하는데도 도움이 됩니다. 검색 엔진은 링크 텍스트를 사용하여 페이지 주제를 학습합니다. 따라서 좋은 링크 텍스트를 사용하면 모두에게 도움이 됩니다!
|
||||
|
||||
### ARIA
|
||||
|
||||
다음 페이지를 상상해보시기 바랍니다:
|
||||
|
||||
| Product | Description | Order |
|
||||
| ------------ | ------------------ | ------------ |
|
||||
| Widget | [Description]('#') | [Order]('#') |
|
||||
| Super widget | [Description]('#') | [Order]('#') |
|
||||
|
||||
이 예시에서는 설명 텍스트와 순서를 복사하는 것이 브라우저를 사용하는 사람에게 의미가 있습니다. 그러나 스크린 리더를 사용하는 사람은 문맥없이 반복되는 *설명* 및 *순서* 라는 단어만 듣게됩니다.
|
||||
|
||||
이러한 유형의 시나리오를 지원하기 위해 HTML은 [Accessible Rich Internet Applications (ARIA)](https://developer.mozilla.org/docs/Web/Accessibility/ARIA)라는 속성 집합을 지원합니다. 이러한 속성을 사용하면 스크린 리더에 추가 정보를 제공할 수 있습니다.
|
||||
|
||||
> **NOTE**: HTML의 여러 측면과 마찬가지로, 브라우저 및 스크린 리더 지원은 다를 수 있습니다. 그러나 대부분의 주요 클라이언트는 ARIA 속성을 지원합니다.
|
||||
|
||||
페이지 형식이 허용하지 않는 경우에는 `aria-label`을 사용하여 링크에 설명할 수 있습니다. 위젯에 대한 설명은 다음과 같이 설정할 수 있습니다
|
||||
|
||||
``` html
|
||||
<a href="#" aria-label="Widget description">description</a>
|
||||
```
|
||||
|
||||
✅ 일반적으로, 위에서 설명한 시맨틱 마크업을 사용하는 것은 ARIA의 사용을 대체하지만, 때때로 다양한 HTML 위젯에 해당하는 시맨틱이 없습니다. 좋은 예는 Progressbar입니다. 진행률 표시줄에 해당하는 HTML이 없으므로 적절한 역할 및 aria 값을 사용하여 일반 `<div>`를 식별합니다. [AMDN documentation on ARIA](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA)에 더 유용한 정보가 포함되어 있습니다.
|
||||
|
||||
```html
|
||||
<div id="percent-loaded" role="progressbar" aria-valuenow="75" aria-valuemin="0" aria-valuemax="100">
|
||||
</div>
|
||||
```
|
||||
|
||||
## 이미지
|
||||
|
||||
스크린 리더는 이미지에 있는 내용을 자동으로 읽을 수 없습니다. 이미지에 접근할 수 있는지 확인하는 데 많은 작업이 필요하지 않습니다. 바로 `alt` 속성이 끝입니다. 모든 이미지에는 이미지를 설명하는 `alt`가 있어야합니다.
|
||||
|
||||
✅ 예상대로, 검색 엔진은 이미지의 내용을 이해할 수 없습니다. 그래서 대체 텍스트를 사용합니다. 다시 한 번, 페이지에 접근할 수 있는지 확인하면 추가 보너스가 제공됩니다!
|
||||
|
||||
## 키보드
|
||||
|
||||
일부 사용자는 마우스 또는 트랙패드를 사용할 수 없으며, 대신 키보드로 의존하여 한 요소에서 다음 요소로 이동합니다. 사용자가 문서를 아래로 이동할 때 키보드가 각 요소에 접근할 수 있도록 웹 사이트에서 콘텐츠를 논리적 순서로 표시하는 것이 중요합니다. 시맨틱 마크업으로 웹 페이지를 만들고 CSS를 사용하여 시각적 레이아웃 스타일을 지정하는 경우, 사이트에서 키보드로 탐색할 수 있어야 하지만, 이 사항은 수동으로 테스트하는 것이 중요합니다. [keyboard navigation strategies](https://webaim.org/techniques/keyboard/)에 대해 자세히 알아보세요.
|
||||
|
||||
✅ 웹 사이트로 이동하여 탭 키만 사용하여 탐색해보십시오. 작동하는 것과 작동하지 않는 것은 무엇입니까? 왜 그럴까요?
|
||||
|
||||
## 요약
|
||||
|
||||
일부가 접근할 수 있는 웹은 진정한 'world-wide web'이 아닙니다. 만든 사이트에 접근할 수 있도록 하는 가장 좋은 방법은 처음부터 접근성 모범 사례를 통합하는 것입니다. 추가 단계가 포함되어 있지만 이러한 기술을 워크 플로우에 통합하면 만드는 모든 페이지에 접근할 수 있습니다.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 도전
|
||||
|
||||
이 HTML을 가져와서 학습한 내용에 따라 가능한 하나의 접근을 할 수 있도록 다시 작성하십시오.
|
||||
|
||||
```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)
|
||||
|
||||
## 리뷰 & 자기주도 학습
|
||||
|
||||
많은 정부 기관에는 접근성 요구사항에 관한 법률이 있습니다. 자신의 나라에 해당하는 접근성 법률을 읽어보십시오. 보장되거나 안되는 항목은 무엇입니까? [this government web site](https://accessibility.blog.gov.uk/) 예시 입니다.
|
||||
|
||||
## 과제
|
||||
|
||||
[Analyze a non-accessible web site](assignment.md)
|
||||
|
||||
크레딧: [Turtle Ipsum](https://github.com/Instrument/semantic-html-sample) by Instrument
|
||||
17
1-getting-started-lessons/translations/README.ko.md
Normal file
17
1-getting-started-lessons/translations/README.ko.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# 웹 개발 시작하기
|
||||
|
||||
커리큘럼의 해당 세션에서는 프로젝트 기반이 아닌 전문 개발자가 되는 데 중요한 개념을 소개합니다.
|
||||
|
||||
### 토픽
|
||||
|
||||
1. [프로그래밍 언어 및 도구 소개](1-intro-to-programming-languages/README.md)
|
||||
2. [GitHub의 기초](2-github-basics/README.md)
|
||||
3. [접근성의 기초](3-accessibility/README.md)
|
||||
|
||||
### 크레딧
|
||||
|
||||
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