├── .gitignore ├── README.md ├── _config.yml ├── 개발_환경 ├── CLion.md ├── Git │ ├── branch.md │ ├── commit.md │ ├── files.md │ └── index.md ├── GitHub │ └── index.md ├── IntelliJ.md ├── Visual_Studio.md ├── atom.md ├── index.md ├── notepad++.md ├── vim.md └── vscode.md ├── 기초_용어_및_개념 ├── index.md ├── markup_language │ ├── html.md │ ├── index.md │ └── markdown.md ├── network │ ├── dns.md │ ├── https.md │ ├── index.md │ ├── ip_address.md │ └── osi_layers.md └── 미분류 │ ├── gpg_key.md │ ├── index.md │ ├── ssh_key.md │ └── x86_64.md ├── 유틸리티_프로그램 ├── 1password.md ├── Discord.md ├── FileZilla.md ├── Firefox.md ├── IRC.md ├── Keybase.md ├── Putty.md ├── Slack.md ├── cmder.md ├── fish.md ├── index.md └── zsh.md ├── 컴퓨터_사용 ├── index.md ├── macOS │ ├── commands.md │ ├── directory.md │ ├── distributions.md │ ├── package_manager.md │ └── shell.md ├── 리눅스 │ ├── bash.md │ ├── commands.md │ ├── directory.md │ ├── distributions.md │ └── package_manager.md └── 윈도우 │ ├── commands.md │ ├── directory.md │ ├── powershell.md │ ├── program_install.md │ └── shortcuts.md └── 프로그래밍_언어 ├── C#.md ├── C++ ├── index.md └── 메모리_관리.md ├── C.md ├── Java.md ├── Python.md ├── Rust.md └── index.md /.gitignore: -------------------------------------------------------------------------------- 1 | # Created by https://www.gitignore.io/api/macos,linux,windows 2 | # Edit at https://www.gitignore.io/?templates=macos,linux,windows 3 | 4 | ### Linux ### 5 | *~ 6 | 7 | # temporary files which can be created if a process still has a handle open of a deleted file 8 | .fuse_hidden* 9 | 10 | # KDE directory preferences 11 | .directory 12 | 13 | # Linux trash folder which might appear on any partition or disk 14 | .Trash-* 15 | 16 | # .nfs files are created when an open file is removed but is still being accessed 17 | .nfs* 18 | 19 | ### macOS ### 20 | # General 21 | .DS_Store 22 | .AppleDouble 23 | .LSOverride 24 | 25 | # Icon must end with two \r 26 | Icon 27 | 28 | # Thumbnails 29 | ._* 30 | 31 | # Files that might appear in the root of a volume 32 | .DocumentRevisions-V100 33 | .fseventsd 34 | .Spotlight-V100 35 | .TemporaryItems 36 | .Trashes 37 | .VolumeIcon.icns 38 | .com.apple.timemachine.donotpresent 39 | 40 | # Directories potentially created on remote AFP share 41 | .AppleDB 42 | .AppleDesktop 43 | Network Trash Folder 44 | Temporary Items 45 | .apdisk 46 | 47 | ### Windows ### 48 | # Windows thumbnail cache files 49 | Thumbs.db 50 | ehthumbs.db 51 | ehthumbs_vista.db 52 | 53 | # Dump file 54 | *.stackdump 55 | 56 | # Folder config file 57 | [Dd]esktop.ini 58 | 59 | # Recycle Bin used on file shares 60 | $RECYCLE.BIN/ 61 | 62 | # Windows Installer files 63 | *.cab 64 | *.msi 65 | *.msix 66 | *.msm 67 | *.msp 68 | 69 | # Windows shortcuts 70 | *.lnk 71 | 72 | # End of https://www.gitignore.io/api/macos,linux,windows 73 | 74 | ### IDE ### 75 | .idea -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # HowToSNUCSE 2 | 고인물들은 무엇을 아는가 3 | [![license](https://badgen.net/badge/license/CC-BY-SA-4.0/blue)](https://creativecommons.org/licenses/by-sa/4.0/deed.ko) 4 | 5 | ## 이것은 무엇인가요? 6 | 컴공에는, 컴퓨터를 아주 잘 아는 사람도 있고, 프로그래밍을 처음 해보는 사람도 있습니다. 7 | 이 둘 간에는, 대체로 정보의 격차가 심하다는것을 근 1년간 많이 느꼈습니다. 8 | Make로 편하게 컴파일하는 방법, 리눅스 사용의 기초 지식, 텍스트 에디터와 IDE의 차이 등이 그것인데요. 9 | 문제는, 수업에서는 이것들을 **당연히 아는 것** 이라고 가정하고 나갈 때가 많습니다! 10 | 필연적으로 모르는 사람은 어러 번 헤메게 되고, 아는 사람은 금방 끝내고 할 일을 하죠. 11 | 그래서, 저는 **컴공이라면 당연히 알아야 할, 또는 알면 아주 편한 지식들**, 그러나 **수업에서 가르쳐주지는 않는** 것들에 대해서 정리를 해 보기로 했습니다. 12 | 13 | ## 분류 14 | - [프로그래밍 언어](프로그래밍_언어/index.md) 15 | - [개발 환경](개발_환경/index.md) 16 | - [기초 용어 및 개념](기초_용어_및_개념/index.md) 17 | 18 | ## 이용하기 19 | ### 주의사항 20 | 이 문서를 작성하는 사람들도 모든 걸 아는 만능 인간은 아닙니다. 틀린 정보가 있을 수도 있습니다. 21 | 서울대학교 컴퓨터공학부에 한정된 정보가 다수 있습니다. 외부인이 읽으실 때는 정보의 차이에 유의하며 읽어주세요. 22 | 23 | ### 라이선스 및 배포 24 | [**CC BY-SA 4.0**](https://creativecommons.org/licenses/by-sa/4.0/deed.ko)을 사용합니다. 25 | 다른 학교의 문서로 만드실 수 있습니다. 다만 저작자 표시와, 동일조건 변경을 지켜주세요. 26 | 27 | ### 기여 28 | 맘에 안 드는 부분이 있거나, 추가하고 싶으신 내용이 있다면, 언제든 이슈와 풀리퀘를 남겨주시기 바랍니다! 29 | 30 | ## Manager 31 | - [integraldx](https://github.com/integraldx) 32 | - [nevivurn](https://github.com/nevivurn) 33 | - [gratus907](https://github.com/gratus907) 34 | - [creeper00](https://github.com/creeper00) 35 | - [coffeetea99](https://github.com/coffeetea99) 36 | 37 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | theme: jekyll-theme-slate -------------------------------------------------------------------------------- /개발_환경/CLion.md: -------------------------------------------------------------------------------- 1 | ## CLion 2 | ### CLion IDE 3 | 4 | CLion은 JAVA언어용 IDE인 IntelliJ IDEA로 널리 알려진 Jetbrains 사에서 개발한 C/C++용 통합 개발 환경(IDE) 입니다. C와 C++ (C11과 C++17은 부분적으로 지원), JavaScript, Objective-C, Swift 등을 기본적으로 지원합니다. 5 | 교육용 라이센스를 이용해 재학 기간 동안 무료로 사용할 수 있습니다. [Clion 설치 페이지](https://www.jetbrains.com/clion/) 에서 설치할 때 학생 계정을 입력하면 됩니다. 6 | 최초 설치 시 컴파일러를 비롯한 툴체인을 설정해야 하며, gcc, Clang, MSVC 컴파일러를 연결할 수 있습니다. 7 | 8 | 9 | --- 10 | 11 | ### 장점 12 | CLion은 상당히 많은 기능을 갖춘 IDE로, 원하는 Code Highlighting Style을 자유롭게 지정할 수 있으며 Integer Overflow, Infinite Loop 등 자주 일어나는 실수도 잘 잡아주는 편입니다. Git관련된 기능도 잘 갖추어져 있습니다. 13 | 가장 큰 장점으로, Windows, macOS, Linux에 모두 설치가 가능하며 거의 동일한 환경을 제공받을 수 있습니다. C/C++ 전문 IDE 중 하나인 Visual Studio에 비해 갖는 가장 큰 장점이라고 할 수 있겠죠. 14 | 또한, 플러그인을 이용하여 기능을 더 확장해서 쓸 수 있습니다. 대표적으로 Verilog support를 설치하면 Verilog 언어에 대한 Code Highlight가 가능하며, R, Rust 관련 플러그인 등 언어별 플러그인이나 단축키 설정 관련 플러그인 등을 통해 개인에게 더 특화된 개발 환경을 사용할 수 있습니다. 단축키 관련 설정의 경우 vim 단축키 플러그인, Emacs 단축키 플러그인 등으로 다른 에디터를 사용하던 사람도 같은 단축키를 그대로 적용할 수 있습니다. 15 | IDE 개발을 지속해왔고, 지속하고 있는 기업의 제품이기 때문에 TroubleShooting을 비롯한 지원을 받기가 비교적 용이하다는 장점도 있습니다. 16 | 17 | --- 18 | ### 단점 19 | Dev-C++, Code::Blocks에 비해서는 무거운 편입니다. Visual Studio에 비해서는 훨씬 가볍지만, 그만큼 기능의 다양성은 떨어집니다. 20 | 또한, 다른 곳에서 프로젝트 전체를 내려받아 추가로 작업하는 경우에는 CMake를 직접 작업해야 합니다. 21 | -------------------------------------------------------------------------------- /개발_환경/Git/branch.md: -------------------------------------------------------------------------------- 1 | # Branch 2 | 브랜치는, 이름 그대로 나뭇가지와 같은 역할을 합니다. 3 | 4 | ## 이해하기 5 | `git init`을 하고 나서, `master` 브랜치에 계속 커밋을 쌓아왔다고 합시다. 6 | ``` 7 | 0000011 <- master 8 | | 9 | 0000010 10 | | 11 | … 12 | ``` 13 | 이 시점에서, `master`로부터 `branch1` 브랜치를 새로 만들어보면, 구조가 다음과 같이 나타납니다. 14 | ``` 15 | 0000011 <- master, branch1 16 | | 17 | 0000010 18 | | 19 | … 20 | ``` 21 | 아직 `branch1`에 커밋을 하나도 쌓지 않았으므로, `master`브랜치와 차이가 없습니다. 22 | 이제, `branch1`에 커밋을 쌓아봅시다. 23 | ``` 24 | 0000012 <- branch1 25 | | 26 | 0000011 <- master 27 | | 28 | 0000010 29 | | 30 | … 31 | ``` 32 | 새로 쌓은 커밋 `0000012`를, `branch1`은 가리키고 있지만, `master`는 가리키고 있지 않는 모습을 볼 수 있습니다. 33 | 이번엔 `master`에 쌓아 보면, 34 | ``` 35 | 0000012 <- branch1 0000013 <- master 36 | | / 37 | 0000011 ──────────── 38 | | 39 | 0000010 40 | | 41 | … 42 | ``` 43 | 새로 쌓은 커밋 `0000013`을, `master`는 가리키고 있지만, `branch1`은 가리키고 있지 않습니다. 44 | 이 둘은 커밋 `0000011` 로부터 분기되어, 각각 다른 커밋 히스토리를 가집니다. 45 | 이 모양이 마치 나뭇가지와 같아서 **branch**라는 이름이 붙여집니다. 46 | 47 | ### Merge 48 | 이제 `branch1`에 있는 내용과 `master`에 있는 내용을 합쳐봅시다. 49 | 머지에는 방향이 존재합니다. `branch1`에서 `master`로 머지할 수도 있고, `master`에서 `branch1`으로 머지할 수도 있습니다. 50 | 일반적으로, 파생 브랜치(이 경우 `branch1`)에서 주 브랜치(대부분의 경우 `master`)로 머지가 진행됩니다. 51 | `branch1`에서 `master`로 머지해봅시다. 52 | ``` 53 | 0000014 <- master 54 | | \_____________ 55 | 0000013 0000012 <- branch1 56 | | / 57 | 0000011 ──────────── 58 | | 59 | … 60 | ``` 61 | `master`브랜치에 새로운 커밋 `0000014`가 쌓였습니다. 62 | 이 커밋을 **머지 커밋** 이라고 부릅니다. 63 | `branch1`은 그대로 있습니다. 이제 이 브랜치는 계속 커밋을 쌓을 수도 있고, 삭제해버릴 수도 있습니다. 64 | 65 | 머지 커밋이 발생하지 않는 경우도 있습니다. 66 | 주 브랜치에 아무런 커밋이 없는 경우가 그렇습니다. 67 | 다음 상황을 가정해봅시다. 68 | ``` 69 | 0000012 <- branch1 70 | | 71 | 0000011 <- master 72 | | 73 | 0000010 74 | | 75 | … 76 | ``` 77 | 이 상황에서 `branch1`로부터 `master`로 머지를 진행하면, *합칠* 내용이 존재하지 않기 때문에, fast-forward 머지가 진행됩니다. 78 | fast-forward 머지가 발생한 이후의 상황은 다음과 같습니다. 79 | ``` 80 | 0000012 <- master, branch1 81 | | 82 | 0000011 83 | | 84 | 0000010 85 | | 86 | … 87 | ``` 88 | 단순히 `master` 브랜치가 가리키는 커밋을 `branch1`이 가리키는 커밋과 동일하게 만들어줍니다. 89 | 이 과정에서 새로운 커밋은 발생하지 않습니다. -------------------------------------------------------------------------------- /개발_환경/Git/commit.md: -------------------------------------------------------------------------------- 1 | # Commit 2 | Commit은, 어떠한 한 시점에서의 git repository의 상태, 또는 그러한 상태를 남기는 것을 말합니다. 3 | Git을 다룰 때 가장 핵심이 되는 개념이므로, 확실하게 알아두는 것이 유리합니다. 4 | 5 | 각 커밋에는, *커밋 해시* 라는 고유번호가 붙게 됩니다. 6 | 이 문서를 작성하는 시점에서 가장 최근의 커밋 해시는 `b83a75c`입니다. 7 | 실제로는 훨씬 더 길지만, 편의를 위해 축약해서 부르는 것이 대부분입니다. 8 | 많은 경우에, 각 커밋은 이 커밋 해시로 구분합니다. 9 | 커밋 해시는 `git log --oneline`를 실행함으로써 확인할 수 있습니다. 10 | 11 | 우리가 `git commit` 을 실행할 때, git은 현재 staged 상태에 있는(index에 등록되어있는) 파일들을 따로 저장해두게 됩니다. Staged 상태에 있지 않았던 파일들은, 이전 커밋에서 가져올 수 있도록 만들어집니다. 따라서, 커밋들은 각각 이전 커밋들을 가리키게 만들어집니다. 12 | 13 | 예를 들어, 커밋 `aaaaaaa` 에서 `a.txt`, `b.txt` 라는 파일을 새로 등록했다고 합시다. 14 | 이 커밋에서는 새로 등록된 파일들의 내용들을 저장해놓게 됩니다. 15 | 다음에, 커밋 `aaaaaab` 에서 `b.txt`의 내용을 수정했다고 합시다. 16 | `b.txt`는 수정되어 stage 된 이후 커밋되었을 것이므로 커밋 `aaaaaab`에서는 새로운 `b.txt`의 내용을 가지고 있습니다. 17 | 그러나, `a.txt`의 내용은 수정되지 않았으므로, 따로 저장해놓고 있을 필요가 없습니다. 18 | 대신, 커밋 `aaaaaab`는 커밋 `aaaaaaa`의 `a.txt`의 내용을 가져와 사용할 수 있습니다. 19 | 이런 방식을 통해, 실제로 파일 전부를 저장해놓고 있지 않더라도 각 커밋에 대해서 그 당시의 폴더와 파일들을 완벽하게 복원해낼 수 있습니다. 20 | 21 | ``` 22 | ┌───────┐ 23 | │aaaaaaa│ - a.txt, b.txt 24 | └───────┘ ^ 25 | │ │ 26 | ┌───────┐ │ 27 | │aaaaaab│ - _____, b.txt 28 | └───────┘ 29 | │ 30 | … 31 | ``` 32 | 이런 식으로, 연결 리스트 처럼 부모 커밋들을 끝없이 가리키고 있는 형태가 git repository에서 가장 기본적인 형태가 됩니다. 33 | 이후 branch나 rebase를 통해 이 형태가 여러 다양한 형태로 변경될 수 있습니다. -------------------------------------------------------------------------------- /개발_환경/Git/files.md: -------------------------------------------------------------------------------- 1 | # 파일의 상태 2 | Git Repository 안의 파일들은 모두 어떠한 상태를 가지게 됩니다. 3 | 그 목록은 다음과 같습니다. 4 | - Untracked 5 | - Unmodified 6 | - Modified 7 | - Staged 8 | 9 | ## Untracked 10 | Untracked 파일들은 git의 관리를 받지 않는 파일들을 말합니다. 11 | 이 파일들은 .gitignore에 의해 무시된 파일일수도 있고, 그저 새로 만들고 커밋되지 않은 파일일수도 있습니다. 12 | 이 파일들은 `git add ` 명령을 통해 **Staged** 상태로 넘어갈 수 있습니다. 13 | 14 | ## Unmodified 15 | Unmodified 파일들은 git의 관리를 받고 있지만, 가장 마지막 커밋으로부터 아무런 수정사항도 가해지지 않은 파일을 말합니다. 16 | 만약 이 파일을 수정하게 된다면, 자동으로 **Modified** 상태로 넘어가게 됩니다. 17 | 또는, `git rm ` 명령을 통해 더 이상 git의 관리를 받지 않도록 **Untracked** 상태로 만들 수도 있습니다. 18 | 19 | ## Modified 20 | Modified 파일들은 git의 관리를 받고 있고, 가장 마지막 커밋 이후로 어떠한 수정사항이 가해진 파일을 말합니다. 21 | 이런 파일들은 `git add ` 명렁을 통해 **Staged** 상태로 넘어갈 수 있습니다. 22 | 또는, 만약 가한 수정사항을 이전으로 되돌리고 싶다면, `git checkout -- `명렁을 통해 **Unmodified** 상태로 되돌릴 수 있습니다. 23 | 24 | ## Staged 25 | Staged 파일들은 `git add ` 명령 등을 통해 index에 추가되어있는 파일들을 말합니다. 26 | 이 파일들은 `git commit` 명령을 통해 index에 들어있는 정보를 토대로 새 커밋을 작성함으로써 **Unmodified** 상태가 될 수 있습니다. 27 | 또는, `git reset HEAD ` 명령을 통해 **Modified** 상태로 되돌릴 수 있습니다. -------------------------------------------------------------------------------- /개발_환경/Git/index.md: -------------------------------------------------------------------------------- 1 | # Git 2 | [공식 사이트](https://git-scm.com/) 3 | 4 | Git은, 개발중인 프로그램의 소스코드를 관리하고, 더 나아가 팀원들과 공유하기 위한 분산형 버전 관리 시스템(Distributed Version Control System)입니다. 5 | 이를 사용하면 소스코드 분할을 이용한 팀원 간의 협업이 더욱 원활해지고, 작업 기록을 명시적으로 남길 수 있으며, 작업 도중에 있는 코드를 프로덕션 코드(실제 서비스에 사용될 코드)와 분리할 수 있습니다. 6 | 7 | ## 설치하기 8 | - 윈도우 / 맥: 공식 사이트에서 설치 파일을 제공합니다 9 | - 리눅스: 사용하는 배포판의 패키지 매니저에 포함되어 있습니다. 10 | 11 | ## 간단한 기초 사용법 12 | `※ 터미널 사용을 가정합니다. Github Desktop, GitKraken과 같은 클라이언트들에 대한 사용법은 다른 문서들을 참고해주세요.※` 13 | `※ 아래 스크린샷은 접근성을 위해 Windows의 cmd를 사용하였지만, 일반적으로는 다른 터미널을 사용하는 것을 추천합니다.※` 14 | ### add와 commit 15 | 1. 새로운 폴더를 만들고, 폴더 안으로 이동 후 `git init`을 실행합니다. 16 | - 이를 실행하고 나면, 새로운 폴더는 git repository가 됩니다. 17 | - 현재 폴더에 `.git`이라는 하위 폴더가 새로 생길 것입니다(숨김 파일, 폴더 및 드라이브를 표시하도록 해야 보입니다). 이 하위 폴더가 있다는 것이 현재 폴더가 git repository라는 표시입니다. 18 | 19 | ![1](https://user-images.githubusercontent.com/42795430/67016402-189bca80-f133-11e9-9a80-7dac1fb53425.png) 20 | ![2](https://user-images.githubusercontent.com/42795430/67016450-2cdfc780-f133-11e9-945e-6c5e00fc10b3.png) 21 | 22 | 2. `git status` 를 실행해 보면 현재 상태가 나타납니다. 23 | ![3](https://user-images.githubusercontent.com/42795430/67016495-3a954d00-f133-11e9-9a14-c8dda88dd4ab.png) 24 | 1. `On branch master` : 현재 `master` 브랜치에 있다는 뜻 25 | 2. `No commits yet` : 아직 아무런 커밋이 없다는 뜻 26 | 3. `nothing to commit` : 커밋할 파일이 없다는 뜻 27 | 28 | 3. 새로운 파일 `hello.c`를 생성해봅시다(굳이 소스 코드일 필요는 없습니다. 아무 파일이나 만들면 됩니다). 이후 `git status`를 실행하면 정보가 바뀝니다. 29 | ![4](https://user-images.githubusercontent.com/42795430/67016593-66183780-f133-11e9-89eb-e0fbd9999672.png) 30 | ![5](https://user-images.githubusercontent.com/42795430/67016643-7b8d6180-f133-11e9-9026-d596cde4f0e0.png) 31 | 1. `Untracked files, hello.c` : git 리포지토리에 등록되지 않은 파일 `hello.c`가 존재한다는 뜻 32 | 33 | 34 | 4. 이제 `git add hello.c`를 실행하면, `hello.c`가 커밋을 위해 *스테이지*됩니다. `git status`로 확인해볼 수 있습니다. 35 | ![6](https://user-images.githubusercontent.com/42795430/67016833-ceffaf80-f133-11e9-8c65-af543a17416a.png) 36 | 37 | 5. `git commit`을 실행하면, 현재 *스테이지*된 파일들이 *커밋*됩니다. 38 | 1. 사용자 정보가 설정되지 않았다면, `git config`를 하라는 메세지가 나옵니다. 메세지에 나온 명령어대로 자신의 이메일과 이름을 입력하면 됩니다. 39 | 2. 명령어 실행 후, *커밋 메세지*를 수정하는 창이 나타납니다(보통 vim입니다. 따로 설정을 거치지 않았다면 한글이 입력되지 않을 수 있습니다.). a키를 눌러 메세지를 작성하거나 수정할 수 있습니다. 메세지를 작성하고 esc 키를 누른 다음, 아래쪽 커맨드 부분에 `:wq`을 입력하고 enter를 누르면 메세지 수정 창이 종료되고 커밋이 완료됩니다. 40 | 3. 커밋 메세지를 짧게 한 줄로 나타내고 싶을 땐, `git commit` 대신에 `git commit -m "(커밋 메세지)"`를 실행하면 커밋 메세지 수정 창을 생략할 수 있습니다. 41 | 42 | ![7](https://user-images.githubusercontent.com/42795430/67016908-e9398d80-f133-11e9-9da2-cb08e6a4a9ac.png) 43 | ![8](https://user-images.githubusercontent.com/42795430/67016931-efc80500-f133-11e9-87c3-109fc2695d0d.png) 44 | 45 | 6. 커밋이 완료되고 나면, `git log`를 통해 커밋 로그를 확인할 수 있습니다. 46 | ![9](https://user-images.githubusercontent.com/42795430/67017179-52b99c00-f134-11e9-9aca-e78cff839482.png) 47 | 48 | ### branch와 merge 49 | 1. `git branch new-branch` 를 통해 **현재 존재하는 브랜치로부터** 새 브랜치 `new-branch`를 만들 수 있습니다. 지금은 `master`로부터 만들어졌을 것입니다. 50 | 2. `git checkout new-branch` 를 통해 브랜치를 넘어갈 수 있습니다. `git status`로 현재 어느 브랜치에 있는지 체크할 수 있습니다. 51 | 3. 위에 적힌 방식대로, `new-branch`에서 몇개의 파일을 추가하고 커밋해봅시다. 52 | 4. 추가된 파일들은, `new-branch`에는 존재하지만, `master`에는 존재하지 않습니다. 53 | 5. 이제 `git checkout master` 를 통해 `master` 브랜치로 돌아와봅시다. 만든 파일이 사라집니다. 54 | 6. `merge`를 통해 `new-branch`에 있는 수정사항들("커밋"들)을 반영할 수 있습니다. `master`브랜치 위에서 `git merge new-branch`를 실행합니다. 55 | 7. 폴더를 확인해보면, 만든 파일들이 다시 생겨난 것을 볼 수 있습니다. `new-branch`에 있던 수정사항들이 `master`에 반영되었기 때문입니다. 56 | 8. `git log` 를 실행하여, 반영한 수정사항들을 볼 수 있습니다. 57 | 58 | ## Git의 이해를 위한 세부 사항들 59 | - [.gitconfig](gitconfig.md) 60 | - [파일의 상태](files.md) 61 | - [커밋](commit.md) 62 | - [브랜치](branch.md) -------------------------------------------------------------------------------- /개발_환경/GitHub/index.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/integraldx/HowToSNUCSE/6312f59330b6cbccffd4a8707b58c4b2d4abef43/개발_환경/GitHub/index.md -------------------------------------------------------------------------------- /개발_환경/IntelliJ.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/integraldx/HowToSNUCSE/6312f59330b6cbccffd4a8707b58c4b2d4abef43/개발_환경/IntelliJ.md -------------------------------------------------------------------------------- /개발_환경/Visual_Studio.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/integraldx/HowToSNUCSE/6312f59330b6cbccffd4a8707b58c4b2d4abef43/개발_환경/Visual_Studio.md -------------------------------------------------------------------------------- /개발_환경/atom.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/integraldx/HowToSNUCSE/6312f59330b6cbccffd4a8707b58c4b2d4abef43/개발_환경/atom.md -------------------------------------------------------------------------------- /개발_환경/index.md: -------------------------------------------------------------------------------- 1 | # 개발 환경 2 | 프로그래밍을 영원히 메모장에서 할 수는 없습니다. 생각만 해도 끔찍하네요. 3 | 개발자들은 기본적으로 귀찮음을 싫어하는 종족이기 때문에, 유용하게 사용할 수 있는 프로그램을 만들기 마련입니다. 4 | 당연히, 여러분들도 사용할 수 있어요. 사용해야 합니다. 5 | 여러 프로그램들을 여러분의 입맛에 설치하고 나면, 그 컴퓨터가 바로 여러분의 **개발 환경** 이 됩니다. 6 | 여기서는 여러분의 개발 환경의 일부가 되어줄 수 있는 프로그램들을 정리해 놓았습니다. 7 | *※리눅스 사용법이나 커맨드 라인 사용법 같은 내용들은 [컴퓨터 사용](/컴퓨터_사용/index.md) 에 정리해 놓았어요.* 8 | 9 | ## IDE와 텍스트 에디터 10 | 코드를 편집하기 전에 여러분이 먼저 알아야 할 사실은, **IDE와 텍스트 에디터는 다르다는 사실입니다!** 11 | ### 텍스트 에디터 12 | **텍스트 에디터**는, 단순히 코드 파일만을 수정하는 프로그램입니다. 메모장이랑 같은 역할을 하죠. 13 | 그러나, 개발자들이 쓰는 텍스트 에디터는 메모장보다 **훨씬, 훨씬 더** 많은 기능들을 제공합니다. 14 | 대체로 가볍고, 빠르고, 무료입니다. 그리고 플러그인을 통해 IDE만큼의 기능을 제공할 수도 있습니다. 15 | 그러나 컴파일러가 포함되어있지 않아서, 따로 설치하고 실행해주거나 플러그인에 연결해줘야 하는 단점이 있습니다. 16 | #### 목록 17 | - [vscode](vscode.md) 18 | - [atom](atom.md) 19 | - [vim](vim.md) 20 | - [notepad++](notepad++.md) 21 | 22 | ### IDE 23 | **IDE**는 Integrated Development Enviornment의 약자로, 텍스트 에디터와 컴파일러가 합쳐진듯한 동작을 합니다. 24 | IDE를 설치하면서 컴파일러도 같이 설치가 되기 때문에, IDE 안에서 실행과 디버깅까지 함께 됩니다. 25 | 그리고, 한 언어에 특화된 경우가 많기 때문에 특수하고 큰 개발에 유리합니다. 26 | 단점으로는, 상당히 무겁고(무겁다는 말은 실행이 느리고 용량이 크다는 것을 의미합니다.), 유료인 경우도 꽤 있습니다. 27 | 마이너한 언어의 경우 개발된 IDE가 존재하지 않기도 합니다. 28 | #### 목록 29 | - [Visual Studio](Visual_Studio.md) 30 | - [IntelliJ](IntelliJ.md) 31 | - [CLion](CLion.md) 32 | 33 | ## 컴파일 및 빌드 34 | 여러분이 작성한 코드는, 컴파일, 또는 빌드라는 작업을 통해 하나의 프로그램 또는 라이브러리가 됩니다. 35 | 간단한 코드라면, 단순한 `gcc main.c` 같은 명령으로 충분히 원하는 결과가 나오겠죠. 36 | 그러나, 커다란 프로그램의 경우에는 컴파일이 녹록치 않습니다. 아래는 실제로 제가 그래픽스 과제 컴파일을 위해 실행하는 명령입니다. 37 | `g++ main.cpp SceneManager.cpp Model.cpp Object.cpp Camera.cpp Util.cpp Pod.cpp -lglut -lGLU -lGL -o main` 38 | 이런 긴 명령을 매번 테스트 할 때마다 칠 수는 없죠. 그래서 개발자들은 **어떻게 컴파일할지**를 지정해주는 프로그램들을 사용합니다. 39 | ### 목록 40 | - [make](make.md) 41 | - [cmake](cmake.md) 42 | - [Visual Studio](Visual_Studio.md) [1] 43 | 44 | 45 | [1]: 비주얼 스튜디오는 자체 솔루션(.sln)포맷을 이용해 컴파일을 관리합니다. 46 | 47 | ## 버전 관리 48 | 소프트웨어 개발은, 먼저 프로토타입을 만들고, 여기에 살을 붙여가는 방식으로 보통 진행됩니다. 49 | 이런 개발을 원활하게 하기 위해서, 많은 개발자들이 **버전 관리 프로그램**을 프로젝트와 함께 사용합니다. 50 | 버전 관리 도구로 git, svn 등이 있고 대기업의 경우 자체 프로그램을 사용하기도 합니다. 51 | git을 사용하는 방법은 아주 중요하니, 하위 문서에서 자세히 알아봅시다! 52 | - [Git](Git/index.md) 53 | - [GitHub](GitHub/index.md) 54 | -------------------------------------------------------------------------------- /개발_환경/notepad++.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/integraldx/HowToSNUCSE/6312f59330b6cbccffd4a8707b58c4b2d4abef43/개발_환경/notepad++.md -------------------------------------------------------------------------------- /개발_환경/vim.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/integraldx/HowToSNUCSE/6312f59330b6cbccffd4a8707b58c4b2d4abef43/개발_환경/vim.md -------------------------------------------------------------------------------- /개발_환경/vscode.md: -------------------------------------------------------------------------------- 1 | # VSCode 2 | [공식 홈페이지](https://code.visualstudio.com/) 3 | VSCode는, Microsoft 사에서 개발한 텍스트 에디터입니다. 4 | 웹개발을 타겟으로 하여 개발되었지만, 플러그인 기능을 이용하여 C, Java등의 코드를 작성할 때도 사용됩니다. 5 | Electron 프레임워크를 사용합니다. 6 | 7 | ## 설치 절차 8 | - 윈도우, 맥: 설치 프로그램을 제공합니다. 9 | - 리눅스: 대체로 패키지 매니저에 등록되어있습니다. 10 | 11 | ## 특징 12 | - 플러그인(추가 기능을 말합니다.) 커뮤니티가 상당히 활성화되어 있는 편입니다. 원하는 플러그인을 설치하여 커스터마이징하는것이 자유롭습니다. 13 | - MIT 라이선스가 적용된 오픈소스 프로젝트입니다. GitHub에서 코드를 보고 수정할 수 있습니다. 14 | - 윈도우, 리눅스, 맥 모두에서 사용 가능합니다. 15 | - Git 플러그인이 기본으로 지원됩니다. 내부 익스플로러 상에서 파일들의 Git Status를 볼 수 있고, Conflict Resolve도 편하게 할 수 있습니다. 16 | - 에디터의 설정이 json파일로 저장됩니다. 원하는 설정 후, 이 파일의 import/export를 통해 설정을 백업하거나 복구하는것이 가능합니다. 17 | 18 | ## HowTo 19 | [공식 튜토리얼 문서](https://code.visualstudio.com/docs) 20 | - 먼저 작업하고자 하는 폴더를 열고, 그 안에 있는 파일들을 VSCode 내에서 수정하는 방식으로 작업합니다. 21 | - 단일 파일만 열어 편집할 수도 있습니다. 대신 폴더와 연동되는(Git 등) 플러그인들이 제대로 작동하지 않을 수 있습니다. 22 | - 컴파일 및 실행은 내장 터미널에서 할 수도 있고, 디버거를 연결하여 할 수도 있고, Task를 설정하여 실행할 수도 있습니다. 23 | - 파일 확장자로부터 VSCode가 언어를 추론하고, 그에 맞는 언어 플러그인이 작동합니다. 만약 언어 플러그인이 설치되어있지 않은 경우, 추천 플러그인을 표시해 줍니다. 24 | 25 | ## Notes 26 | - File/Preferences/Settings에서 각종 기본 설정들과 플러그인 설정들을 수정할 수 있습니다. 27 | - 하단 표시줄에서 간단한 상태 등을 볼 수 있습니다. 클릭하여 조작이 가능합니다. 28 | - Ctrl + ` 을 이용하여 터미널을 열고 닫을 수 있습니다. 29 | - File/Preferences/Color Theme에서 테마를 변경할 수 있습니다. 마음에 맞는 테마가 존재하지 않을 경우, 플러그인을 설치하여 추가할 수 있습니다. 30 | - Vim, emacs, notepad++ 등과 비슷한 환경을 사용하려 할 경우 Keymap 플러그인을 설치하여 사용할 수 있습니다. 31 | - 윈도우의 경우, 설정 파일들은 %HOMEPATH%\\.vscode 폴더에 저장됩니다. 32 | - 폴더에 종속적인 설정들은, 폴더\\.vscode에 저장됩니다. 이 안에 tasks.json, launch.json 등의 파일이 들어갑니다. -------------------------------------------------------------------------------- /기초_용어_및_개념/index.md: -------------------------------------------------------------------------------- 1 | # 기초 지식 2 | 개발 능력을 기르는 것은 관련 지식을 아는 것을 기반으로 합니다. 3 | 여기는 **"이 정도는 알아줘야 하지 않나"** 싶은 지식들을 적어 놓았습니다. 4 | 5 | ## 목록 6 | - 📁[네트워크](network/index.md) 7 | - 📁[마크업 언어](markup_language/index.md) 8 | - 📁[미분류](미분류/index.md) 9 | -------------------------------------------------------------------------------- /기초_용어_및_개념/markup_language/html.md: -------------------------------------------------------------------------------- 1 | # HTML 2 | HTML은 웹 브라우저에서 웹 페이지를 어떻게 표시할지를 규정하는 마크업 언어로, HyperText Markup Language의 줄임말입니다. 3 | 4 | ## 간단한 튜토리얼 5 | HTML을 이해하기 전에 아래 활동을 해 봅시다. 6 | 7 | 새로운 파일을 만들고 그 파일의 이름과 확장자를 index.html이라고 이름을 붙입시다. 그러면 이 파일의 아이콘이 자신이 기본적으로 사용하는 브라우저의 아이콘으로 바뀔 것입니다. 8 | 이제 index.html을 편집할 건데, 더블클릭 하는 대신 [텍스트 에디터](/개발_환경/index.md)로 열어 봅시다. 우클릭 한 다음 적당한 연결 프로그램을 선택하면 됩니다. 9 | 텍스트 에디터로 파일을 열었다면 아래 내용을 그대로 적습니다. 10 | 11 | ``` 12 | 13 | 14 | 15 | title example 16 | 17 | 18 |

h1 example

19 |

h3 example

20 | 21 | 22 | ``` 23 | 다 적었다면 파일을 저장한 다음 닫고, index.html을 더블클릭으로 열어 봅시다. 그러면 웹 브라우저가 열리면서 아래와 같은 페이지가 나타날 것입니다. 24 | 25 | ![image](https://user-images.githubusercontent.com/42795430/72005264-8b2ec900-3290-11ea-96db-11c0b16fd101.png) 26 | 27 | h1 example/h3 example 대신에 다른 문자를 적고 페이지를 새로고침하면 그 문자가 그대로 표시됩니다. 이를 통해 브라우저는 **HTML 코드를 해석해서 시각적으로 표시**한다는 것을 알 수 있습니다. 28 | 29 | ## HTML과 웹 브라우저와의 관계 30 | 31 | HTML은 웹 브라우저가 작동하는 방식과 밀접한 관련이 있습니다. 컴퓨터 간에 통신을 할 때 모든 정보는 0과 1을 기반으로 하는 문자열로 전송됩니다. 그렇다면 문자열이 어떤 과정을 거쳐 시각적인 웹 페이지로 표시되는 걸까요? 예를 들어 [www.google.com](www.google.com)에 들어가면 로고와 검색창, 로그인 버튼은 어떻게 표시되는 걸까요? 32 | 그 해답이 바로 HTML입니다. 브라우저의 주소창에 www.google.com이라고 적어 넣으면, 브라우저는 www.google.com에 해당하는 주소에 연락을 보내 HTML 코드를 받아 옵니다. 이 HTML 코드를 해석하고 시각적으로 표시하는데, 이것이 바로 우리가 보는 웹 페이지입니다. 웹 브라우저에서 f12 버튼을 누르면 개발자 도구 창이 뜨는데, 여기서 Elements(요소) 탭을 클릭하면 볼 수 있는 HTML 코드가 바로 그러한 과정으로 받아 온 코드입니다. 33 | 34 | ## 간단한 문법 35 | 36 | *참고: 이해를 위해 일부 단어가 부정확하게 사용되었을 수 있습니다. 37 | 38 | HTML 문서는 element들로 이루어져 있으며, 하나의 element는 start tag에서 시작해 end tag로 종료합니다. 39 | ``` 40 |
content1
41 | ``` 42 | 위 예시의 경우, 이 전체가 하나의 HTML element이며, `
`은 start tag, `
`은 end tag, `content1`은 content라고 합니다. 43 | 이 element는 `id`라는 attribute를 갖고, 그 attribute의 값은 `'example'`입니다. 44 | 프로그래밍 언어로 비유하자면, 위의 element는 div라는 타입의 한 객체이며 id라는 필드의 값으로 'example'을 갖는 것과 같습니다. 45 | 하나의 element는 content로 다른 element들을 가질 수 있습니다. 예를 들어 다음과 같은 HTML 코드를 작성할 수 있습니다. 46 | ``` 47 |
49 | Hello 50 |
51 | 54 | 55 | ``` 56 | 이처럼 HTML 코드는 마치 tree와 같은 구조를 가지게 됩니다. 이에 관해선 [DOM](https://en.wikipedia.org/wiki/Document_Object_Model)이라는 용어도 있지만, 여기서는 깊게 살펴보지 않겠습니다. 57 | 웹 브라우저마다 지원하는 태그에 약간씩 차이가 있을 수 있지만 대체로 비슷한 태그를 지원하며 이들만 가지고도 웹 페이지를 만들 수 있습니다. 때문에 생소한 HTML 태그가 웹 브라우저에서 작동하지 않는다면 브라우저 호환성을 의심해 볼 수 있습니다. 58 | 59 | ## HTML과 Javascript와의 관계 60 | 61 | HTML은 무엇을 보여 줄 지를 정의할 뿐 프로그래밍 언어가 아니기 때문에, HTML만 가지고 할 수 있는 작업은 극히 적습니다. 예를 들어, 어떤 `