mySQL & miniconda 를 초기 설치를 하였는데, 분명 하라는 대로 정확히 따라했는데 에러도 나고 permission 이 없다고 하고 많이 힘들었다.
신기했던건, 예전 프로그램 설치 방식 처럼 .exe 파일을 설치하고 그걸 실행시켜서 다운 받는게 아니라 Terminal 에서 명령어를 입력해서 설치했다. 설치밖에 안했지만 터미널 쓰는 개발자가 된 느낌
아나콘다 안쓰고 미니콘다를 쓰는 이유는 아나콘다엔 우리가 다 쓰지않는 팩키지기능들이 너무 많이 들어있어서 프로그램이 너무 무겁다고 했다.
관계형 데이터 복습 Intro to Django📝
어제 Intro to Django 세션을 복습하자면 모델링을 배웠는데, 
장고가 작동되는 플로우인데 일단 이런식으로 구동된다는것을 머리속에 넣고 넘어가자
위 사진은 주인 한명에 강아지 여러마리 (한마리 잇수도있다) 를 가지고 있는 다이어그램이다. 관계를 간단히 설명해주는 관계도라고도 한다.
위 사진은 관계도중의 일부분을 테이블로 표현한 사진이다. 오너라는 테이블이 하나의 클래스라고 보면 된다.
dogs 테이블을 보자 -> 주인 owner_id를 보면 FK 라고 되어있고 선이 오너 테이블로 가있다, FK는 Foreign Key 인데 PK(Primary Key)에 종속된다는 의미이다. PK 는 무조건 한개 일수 밖에 없다 (Unique하다는 뜻이다)
위 사진처럼 주인이 1명 개가 2마리 이런식을 " 1 대 다" 관계라고 하는데,
1은 여러가지 dog를 가질수 있지만 dog는 여러 주인을 가질수 없다
서로 겹칠수도 있는데 이럴 때 "다 대 다" 를 쓴다 (한자 많을 다). 다대다를 할 때는 중간다리에 테이블이 하나 있어야한다. 그 중간테이블이 있어야 컴퓨터가 "아 얘는 얘랑이고 이쪽은 이쪽이랑 연결이구나" 라고 알 수 있다.
어제 세션이 끝나고 과제를 받았는데,
음식점에 가서 category, product, ingredient 의 관계도 모델링을 간단히 작성하고 한줄씩 설명을 쓰는 것이였다.
raw data가 너무 많아서 줄여야했다.
물리적,
과제 한것,
다시 python🧮
Exceptions
기본 키워드
출처: https://www.youtube.com/watch?v=VS9gXAe_CbQ
의도치 않은 에러가 일어나는 경우를 예외 상황입니다. 예를들어
short_list = [1, 2, 3]
이때 short_list[3] 을 하면 [3]는 short_list에 없기 때문에
생길 수 있는 exception입니다.
특히, 유저의 input을 기반으로 어떠한 연산을 하게 될때 exception이 발생될 가능성이 높습니다. 왜냐하면 유저가 어떠한 형태의 data를 input으로 입력할지 항상 알 수 없기 때문입니다.
Exception이 발생하면, 발생한 코드 위치에서 다음 코드들이 실행되지 않고 곧바로 프로그램이 종료를 하게 됩니다.
하지만 exception이 발생해도 해당 프로세스가 종료하지 않고 대신에 다른 로직을 실행하게 한 후 프로그램을 계속 실행하게 할 수 있습니다.
이러한 것을 exception handling이라고 합니다.
예를 들어, user가 잘못된 값을 input으로 입력해서 exception이 일어났다고 해도, 종료하지 말고 유저에게 메세지를 리턴하도록 할 수 있는 것입니다. Exception handling은 try except 구문을 사용해서 실행합니다.
예를 들어, 앞서 보았단 코드 예제의 경우 만일 IndexError가 났을 경우 프로그램을 종료하는 대신 에러 메세지를 출력하고 -1을 리턴하기 위해서는 다음처럼할 수 있습니다.
except 뒤에 에러코드들은 에러가 떴을 때 그 에러코드를 가져와도 되고,
구글에서 "파이썬 내장예외" 라고 검색하면 나옵니다.
에러코드중에 Exception 오브젝트를 사용하고 싶으면 맨 아래 쪽에 써야한다
안그러면 Exception블록에서 다 막힙니다. (우선순위가 높다는 뜻) (그리고 모든 에러를 표현할수있음)
출처: https://www.youtube.com/watch?v=VS9gXAe_CbQ
위 이미지 설명: 실행을 시키면
인풋1 or 인풋2에 "a 넣으면 숫자를 입력하세요"
잇풋2에 0을 넣으면 "0으로 숫자를 나눌 수 없습니다 ㅠㅠ"
그 외에 에러 : "또 다른 에러가 발생했습니다"
그리고 While True 문이기 때문에 else: 까지 가지 않으면 에러 발생했다는 말이 나오고 또 인풋을 입력하라는 문구가 나온다.
정상적으로 했다면 else: break 가 있기 때문에 아래 사진 처럼 나온다.
finaly 아래 코드는 에러가 발생하던 안하던 실행된다.
시각적으로 보여주기 위해서 맨 위에 attempt = 0 이라는 변수를 넣고
매번 finally는 실행되기 때문에 attempt +=1 해주고 {총 attempt}번 실행됬다는 것을 프린트 해준다.
진짜 위 유튜브에 깔끔하게 설명 잘 되어있다. 미래의 내가 exception 에러 핸들링이 헷갈릴 때 다시와서 복습 잘하길 바란다.
Assignment
왼쪽 상단의 divison 함수를 수정하여서 exception이 발생하는 경우 -1을 리턴하도록 해주세요.
def division(num1, num2):
try:
return num1 / num2
except Exception:
return -1
#여기 리턴 왜 없어도 되는거지
#else:
#return num1 / num2
Class inherit 클래스 상속 복습📝
출처: 생활코딩
여기 자전거라는 객체가 있는데, 
자전거 객체에 스탠드를 추가해서 분위기 있는 자전거 객체를 만든
기존에 있었던 객체에 새로운 기능을 추가해서 새로운 객체를 만드는것
그것이 상속
기존의 기능을 상속하면서 새로운 기능을 추가하는 행위
또 여기다 브레이크를 추가한다. 록은 자전거를 추가한다.
객체를 상속해서 새로운 객체를 만든다.
다시 한번 정리:
새로운 기능을 추가해서 새로운 객체를 만들어내는 행위 = 상속
Git & GitHub 개념 세션⚔️
오늘 알고 지나가야할 것
✔️ Git 개념 이해
✔️ GitHub 이 무엇인지 이해
✔️ Git 사용
✔️ GitHub 사용을 통한 협업
Git의 공식 명칭은 분산 버전 관리 시스템 (VCS) 입니다.
쉽게 말해, 프로젝트 파일의 변경 사항을 추적하는 시스템입니다. 이를 통해 개발자들은 프로젝트의 변경 사항을 기록하고, 특정 시점의 버전으로 언제든 돌아갈 수 있습니다. 이런 버전 관리 시스템은 많은 사람들이 효율적으로 함께 작업하고, 프로젝트를 중심으로 협업할 때 사용할 수 있습니다. 각 개발자가 자신만의 프로젝트 버전을 본인 컴퓨터에 갖게됩니다. 나중에 이러한 개별 버전의 프로젝트를 병합하여 기준이 되는 버전의 프로젝트에 적용 할 수 있게 됩니다.
Git은 개인 혹은 팀 간의 프로젝트를 관리하는 데 가장 널리 사용되고 있는 툴입니다. 따라서 Git을 다룰 줄 아는 것은 요즘 모든 개발자들에게 가장 중요한 기술 중 하나입니다.
Repositories (저장소)📦
Git repository는 Git으로 관리하는 프로젝트 저장소입니다. (쉽게 말해 폴더)
Git repository 에는 크게 두 가지 종류가 있습니다.
- Local repository - 본인의 컴퓨터에 저장된 로컬 버전의 프로젝트 저장소
- Remote repository - 로컬 repository 와는 반대로 내 컴퓨터가 아닌 외부 (일반적으로 원격 서버) 버전의 프로젝트 저장소. 팀에서 작업 할 때 특히 유용합니다. 이 곳에서 프로젝트 코드를 공유할 수 있고, 다른 사람의 코드를 확인할 수도 있습니다. 또, 로컬 버전의 프로젝트와 병합하고, 변경 사항을 적용 할 수 있는 곳입니다.
3. Initializing a repository🗓
새 저장소(repository) 를 만들고 Git으로 프로젝트 관리를 시작하려면 터미널에서 프로젝트 폴더로 이동 후 다음 명령어를 입력해주세요.
git init
이 명령어는 프로젝트 폴더 내에 숨겨진 .git 디렉토리를 생성합니다. 이제 Git은 현재 저장소에 대한 모든 변경사항을 추적/관리하게 됩니다.
4. Staging and committing code🗄
Git에서 commit 이란, 프로젝트의 현재 상태를 나타내는 체크포인트 또는 스냅샷으로 생각할 수 있습니다.
쉽게 말해, 현재 버전의 코드를 커밋에 저장한다고 생각하시면 됩니다.
커밋 히스토리에 필요한만큼 커밋을 생성 할 수 있으며, 커밋 간 앞뒤로 이동하여 프로젝트 코드의 다른 변경사항을 확인할 수 있습니다.
이를 통해 프로젝트의 진행 상황을 효율적으로 관리할 수 있게 됩니다.
일반적으로 커밋을 남기는 시점은 특정 내용, 기능을 추가한 후 또는 수정 사항을 적용한 후 정도로 들 수 있습니다.
!! 코드를 커밋하려면 우선 코드를 staging area에 추가해야 합니다.
4.1. Checking the status (상태 확인)
git status
위 명령어는 Git으로 작업 할 때 굉장히 자주 사용되는 명령어입니다. 어떤 파일이 변경되었는지, 어떤 파일이 추가되었는지 등을 전부 보여줍니다.
git status 명령어를 통해 Git 으로 관리(추적)되고 있지 않던 파일(들)이 있다면 해당 파일들을 staging area 로 추가해줄 수 있습니다.
모든 파일이 Git으로 관리되고 있는 시점에서는, git status 명령어를 통해 모든 변경사항을 확인할 수 있고, 커밋을 남기기 위해 staging area 로 추가해줘야 합니다.
4.2. Staging files (Staging area에 파일 추가하기)
프로젝트 폴더에서, git add 라는 명령어를 통해 우리가 원하는 파일들을 staging area 로 추가해줄 수 있습니다.
아래와 같이 특정 파일만 추가할 수 있습니다.
두 번째 줄은 여러 파일들을 추가하고 싶다면
마지막 줄은 아래와 같이 모든 파일을 한번에 추가하고 싶다면
git add file.py
git add file.py file2.py file.py
git add .
위 명령어는 프로젝트 폴더 내의 모든 파일과 폴더를 staging area 에 추가하고 커밋을 남길 수 있게 해줍니다.
4.3. Making commits (커밋 남기기)
커밋은 특정 시간의 코드 스냅샷의 형태로 해당 repository의 커밋 기록에 남게됩니다. git add 명령어를 사용하여 모든 파일을 staging area에 추가 해주었다면 이제 커밋을 남길 준비가 되었습니다.
아래 명령어를 통해 staging area에 있는 파일들을 커밋할 수 있습니다.
git commit -m "Commit message"
식별을 위해 큰 따옴표안에 커밋 메세지를 작성해야 합니다.
변경 사항을 설명하는 짧은 summary 여야 합니다.
위 명령어를 실행하면, 터미널에 방금 남긴 커밋에 대한 세부 내용이 보여지게 됩니다.
4.4 Commit history
프로젝트의 모든 커밋 내역을 보려면 다음 명령어를 입력합니다.
git log
git log 명령어를 통해 보여지는 log는 각 커밋에 대한 자세한 정보를 담고 있습니다. (작성자, hash 값, 날짜와 시간, 그리고 커밋 메세지)
만약 특정 커밋 시점의 코드로 되돌리고 싶다면, 아래 명령어를 사용할 수 있습니다.
commit-hash 를 git log 에서 보이는 커밋의 실제 hash 값으로 대체해주세요.
4.5. Ignoring files
staging area 에 추가하고 싶지 않거나, git 에서 관리하지 않아도 되는 파일이 있다면, .gitignore 파일을 프로젝트 폴더에 생성해주시면 됩니다.
.gitignore 파일 안에, 해당하는 파일명과 폴더명을 나열하면 됩니다. (각 파일, 폴더가 새로운 줄에 입력되어야 합니다.)
Branchs🧬
브랜치란 독립적으로 어떤 작업을 진행하기 위한 개념입니다.
필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있습니다.
여러 명이서 동시에 작업을 할 때에 다른 사람의 작업에 영향을 주거나 받지 않도록, 먼저 메인 브랜치에서 자신의 작업 전용 브랜치를 만듭니다. 그리고 각자 작업을 진행한 후, 작업이 끝난 사람은 메인 브랜치에 자신의 브랜치의 변경 사항을 적용합니다.
이렇게 함으로써 다른 사람의 작업에 영향을 받지 않고 독립적으로 특정 작업을 수행하고 그 결과를 하나로 모아 나가게 됩니다. 이러한 방식으로 작업할 경우 '작업 단위', 즉 브랜치로 그 작업의 기록을 중간 중간에 남기게 되므로 문제가 발생했을 경우 원인이 되는 작업을 찾아내거나 그에 따른 대책을 세우기 쉬워집니다.
저장소를 처음 만들면, Git은 바로 'master'라는 이름의 브랜치를 만들어 둡니다. 이 새로운 저장소에 새로운 파일을 추가 한다거나 추가한 파일의 내용을 변경하여 그 내용을 저장(커밋, Commit)하는 것은 모두 'master' 라는 이름의 브랜치를 통해 처리할 수 있는 일이 됩니다.
'master'가 아닌 또 다른 새로운 브랜치를 만들어서 '이제부터 이 브랜치를 사용할거야!'라고 선언(체크아웃, checkout)하지 않는 이상, 이 때의 모든 작업은 'master' 브랜치에서 이루어 집니다.
5.1. Creating a new branch (브랜치 생성하기)
새로운 브랜치 생성 명령어
새로 만들어진 브랜치는 현재 프로젝트의 코드를 그대로 반영하여 생성됩니다.
5.2. Changing branches (브랜치 전환하기)
다른 브랜치로 이동하는 명령어
원하는 브랜치로 이동하면, 해당 브랜치 안에 있는 마지막 커밋 내용이 작업 트리에 펼쳐집니다. 브랜치가 전환 되었으므로 이후에 남기는 커밋은 전환한 브랜치에 추가됩니다. 해당 브랜치에만 영향을 주게 되는 것이죠. 그런 다음 다른 브랜치로 이동하여 작업 할 수 있으며, 이전 브랜치의 변경 사항 및 커밋의 영향을 받지 않습니다.
브랜치 생성과 동시에 생성된 브랜치로 이동하고 싶다면 기존 checkout 명령어에 -b 라는 flag 를 추가해주면 됩니다.
5.3. Merging branches (브랜치 병합하기)
A 라는 브랜치에서 작업한 내용을 B 라는 브랜치에 적용하고 싶을 때, 브랜치 A 와 브랜치 B 를 병합(merge) 할 수 있습니다. 예를 들어, 특정 브랜치에서 새로운 기능을 완벽하게 구현하고 테스트까지 완료한 시점이면, 기준이 되는 master 브랜치에 구현내용을 적용시킬 때 merge 를 사용합니다.
5.4. Deleting a branch (브랜치 삭제하기)
Introduction to Github📡
1. What is Github?
Git repository 를 위한 호스팅 플랫폼.
Git 인터넷 필요 없음!
Github 인터넷 필요함
Git 은 로컬에서 버전 관리하는거고 그걸 github 에 (원격 클라우드 기반) 올려서 공유하는 것임
모든 프로젝트 파일들과 코드의 히스토리를 관리할 수 있게 해주고, public 혹은 private 하게 협업할 수 있게 해줍니다.
2. Using GitHub🏰
Common Workflow: 내 로컬 Repository를 GitHub 에 push 하기
- 로컬에서 add / commit 한다. (터미널에서)
- Github 으로 이동 후 새 repository를 생성한다.
- (터미널 에서)나의 로컬 repository 를 GitHub repository 와 연결한다. (remote 추가)
- 새 remote 를 이용하여 코드를 Push 한다.
Repository 생성하기
repository 에 코드 push 하기
create 을 하면 이 페이지로 오게 되는데
로컬환경에 이미 Git repository 가 있다면 아래 ...or push an existing repository from the command line 부분에 나와있는 순서대로 진행하면 됩니다.
git remote add origin 명령어는 내 컴퓨터에 있는 로컬 repository 와 방금 만든 GitHub repository 를 연결해줍니다. 쉽게 설명하면, 로컬 Git repository 에게 이름이 origin 이라는 어떤 URL을 알려주는 것과 같습니다. 이름이 꼭 origin 이어야 하지는 않지만 보통 remote 주소가 한개라면 origin 이라고 지어주게 됩니다.
git push 명령어는 로컬 Git repository 의 코드를 GitHub repository 로 업로드 해줍니다.
git remote add origin https://github.com/<your-username>/<your-repo-name>.git
git push -u origin mastergit push 명령어를 실행하면 GitHub 유저네임과 비밀번호를 입력하라는 prompt 가 뜨게 됩니다.
repository 가 성공적으로 push 되었다면, 전에 만든 GitHub repo 페이지로 가서 새로고침하면 로컬에서 push 한 코드가 해당 remote repository 로 업로드 된 것을 확인할 수 있습니다.
repository 에 변경사항 남기기✏️
로컬 Git repo를 GitHub remote repo 와 연결 후 push 까지 했다고 로컬에서 작업한 내용들이 자동으로 remote 에 반영되는 것은 아닙니다. 그래서 변경사항이 있으면 다시 push 를 해줘야 GitHub repo 가 업데이트 됩니다.
예를 들어,
console.log("안녕하세요, 위코더 여러분!");위와 같이 콘솔로그문을 이미 가지고 있는 js 파일에 추가해주거나, 해당 내용을 담고 있는 새로운 js 파일을 생성해줍니다. 저장 후 커밋을 위해 add 후 커밋메세지를 남겨줍니다.
git add .
git commit -m "Change greeting"커밋을 한 뒤, 아래 명령어를 입력해서 업데이트 된 로컬 repo를 GitHub repo로 push 해줍니다.
git push origin master요즘 트렌드🕶
마스터가 인종차별적 단어라는 화두가 뜨면서 모든 마스터를 메인으로 바꿔주고 있는 추세이다. 아래 사진에 가운데 줄 git branch -M main을 치면 마스터 브랜치가 메인브랜치로 이름이 바뀌는 것을 볼 수 있다.
아래 노션에 가면
https://www.notion.so/Django-Project-initial-settings-515916b82a234229a88cd197fa087a63#819d37cd5dd74a94b2d90aa3b364a37f
1. project 초기 세팅 연습 후 확인을 위한 repository clone 받기
$ git clone https://github.com/wecode-bootcamp-korea/backend-exercises.git
$ cd backend-exerciese
-
branch 생성
$ git branch feature/"이름"
$ git checkout feature/"이름" -
"이름"으로 django project 생성
$ django-admin startproject "이름"
$ cd "이름"
그리고
gitignore 설정이 나온다.
