diff --git a/1-getting-started-lessons/1-intro-to-programming-languages/translations/README.ko.md b/1-getting-started-lessons/1-intro-to-programming-languages/translations/README.ko.md new file mode 100644 index 00000000..afc23138 --- /dev/null +++ b/1-getting-started-lessons/1-intro-to-programming-languages/translations/README.ko.md @@ -0,0 +1,192 @@ +# 프로그래밍 언어 및 도구 소개 + +이 강의에서는 프로그래밍 언어의 기초를 다룹니다. 여기에서 다루는 주제는 오늘 날 많은 최신 프로그래밍 언어에 적용됩니다. 'Tools of the Trade' 세션에서는 개발자에게 도움이 되는 유용한 소프트웨어에 대해 알아보겠습니다. + +![Intro Programming](webdev101-programming.png) +> 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 + +[![Tools of the Trade](https://img.youtube.com/vi/69WJeXGBdxg/0.jpg)](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) diff --git a/1-getting-started-lessons/2-github-basics/translations/README.ko.md b/1-getting-started-lessons/2-github-basics/translations/README.ko.md new file mode 100644 index 00000000..b36d184c --- /dev/null +++ b/1-getting-started-lessons/2-github-basics/translations/README.ko.md @@ -0,0 +1,294 @@ +# GitHub 소개 + +이 강의에서는 코드 변경점을 호스팅하고 관리하는 플랫폼인 GitHub의 기본 사항을 다룹니다. + +![Intro to GitHub](images/webdev101-github.png) +> 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 ..." to update what will be committed) + (use "git checkout -- ..." 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 + +훌륭한 Git 커밋 제목 줄은 다음 문장을 완성합니다: +적용되면, 이 커밋은 이 됩니다. + +제목에 대해서는 명령문 또는 현재 시제를 사용하십시오 : "변경됨" 또는 "변경점"이 아닌 "변경". +제목과 마찬가지로 본문(선택 사항)에서도 명령문, 현재 시제를 사용합니다. 본문은 변화에 대한 동기를 포함하고 이를 이전 변경점과 대조해야 합니다. '어떻게'가 아니라 '왜'를 설명하고 있습니다. + +✅ 몇 분 동안 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/). + +![Copy a repo locally](images/clone_repo.png) + +코드를 복사하는 방법에는 여러 가지가 있습니다. 한 가지 방법은 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) 완료하기 \ No newline at end of file diff --git a/1-getting-started-lessons/3-accessibility/translations/README.ko.md b/1-getting-started-lessons/3-accessibility/translations/README.ko.md new file mode 100644 index 00000000..d01004fb --- /dev/null +++ b/1-getting-started-lessons/3-accessibility/translations/README.ko.md @@ -0,0 +1,220 @@ +# 접근 가능한 웹 페이지 생성하기 + +![All About Accessibility](webdev101-a11y.png) +> 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)으로 텍스트를 강조하는 것은 본질적으로 스크린 리더에 중요하다고 알리지 않습니다. 단어는 키워드이기 때문에 굵게 표시되었거나 첫 번째 단어 혹은 디자이너가 굵게 표시해야한다고 결정했기 때문입니다. + +특정 구문을 강조 표시해야 하는 경우에는, `` 또는 `` 요소를 사용하세요. 이는 스크린 리더에 해당 항목이 중요함을 나타냅니다. + +### 올바른 HTML 사용하기 + +CSS와 JavaScript를 사용하면 많은 요소가 모든 유형를 제어할 수 있는 것처럼 보일 수 있습니다. `` 은`