피로그래밍 12기 5주차 활동 정리(20.01.28~20.02.01)

화요일(01.28)

Python으로 크롤링하기 by 신한결 선배님

 

-requests

기본적으로 requests 모듈의 get함수를 이용해 html을 크롤링해온다.

 

-beautifulsoup

 

뷰티풀수프 라이브러리를 활용하여 저장해둔 html에서 특정 부분(selecter를 이용)을 select한다.

selector중 nth_child의 경우 크롤링이 잘 안되는 경우가 있으므로 해당 선택자는 제외하는 방향(넘기고 자손선택자 사용 등)으로 크롤링한다.

크롤링 이후에 확인해보면 빈 리스트가 나오는 경우가 많은데, 이 때는 선택자가 잘못된 것이므로 선택자를 정확히 꼼꼼하게 검토해야한다.

 

-selenium

 

라이브러리 사용시 웹 브라우저를 켜주고, 조작해준다. 만약 웹 사이트에 내에 프로그램이 돌아가고 있다던지, 로그인 후에 어떤 정보를 가져와야한다던지 그런 동적인 경우에 selenium을 이용할 수 있다.

 

 

-장고 프로젝트 생성시에

pip freeze > requirements.txt  # 현재 깔려있는 pip list와 버전을 requirements.txt에 적어서 파일로 만든다.

pip install -r requirements.txt  # 존재하는 requirements.txt 파일에서 pip list를 받아와 리스트를 설치한다.

pip install <라이브러리명1> <라이브러리명2> 이런식으로 여러 라이브러리를 띄어쓰기로 한번에 설치할수도 있다.

 

requirements를 만드는 방법은 자주 쓰는 것이 좋을 것 같다. 피로그래밍 12기에서 현재 사용하고 있는 django 버전은 2.2.9인데, 현재 3.0.2가 최신인 상태이기 때문에 깔려있는 패키지와 버전관리를 위해서 requirements의 사용을 일상화하자.

 

-crawling.py

크롤링 함수를 view에서 바로 구현하면 복잡하기 때문에 따로 python파일로 만들어서 import하여 사용하는것이 좋다. 단, crawling.py 파일을 바로 실행시킬수는 없다. setting에서 view.py가 아닌 다른 파일이 db에 접근하는 것을 금지하기 때문.(이 세팅은 조정가능하다)

 

 

목요일 (01.31)

Database와 django by 황재석 선배님 

 

-DB도메인 지식 공부의 필요성

ORM은 SQL을 작성할 필요 없이 DB를 사용할 수 있도록 만들어진 것이지만, DB를 좀 더 제대로 이해하고 사용하면 관리와 확장이 쉽다. DB 지식에 대해서 조금 더 공부하자.

 

-Table과 Column, Row(Record)

DB는 테이블의 모임으로 이루어져있다.

테이블은 DB에 저장하기 위해 첫 단계로 만드는 형식으로, 테이블 내에 여러개의 행(row,record)가 존재한다. 각 행은 django에서 하나의 인스턴스에 해당하며, 열(column, 조건을 걸 수 있다)을 이용하여 행을 구분할 수 있다. 

 

-Django에서 makemigrations, migrate를 하면 생기는 일

DB는 테이블의 모임이다. 테이블은 DB에 저장하기 위해 첫단계로 만드는 것으로, django의 model과 매핑된다.

 

django에서 model을 만들고 makemigrations를 하면 해당 모델에 알맞은 테이블을 만들어주는 SQL문을 생성한다. migrate를 하면 SQL문을 실행해 DB에 테이블을 만들고 저장시킨다.

 

-SQL

RDBMS(관계형 데이터베이스 관리 시스템)의 데이터를 관리하기 위해 특수 목적의 프로그래밍 언어

• Data Definition Language(데이터 정의 언어) —> 테이블 생성/삭제/변경
• Data Manipulation Language(데이터 조작 언어) —> 테이블 내에서 데이터(레코드)를 검색/삽입/수정/삭제

python을 사용하는 Django와 SQL을 사용하는 DB는 서로 호환이 불가능하므로 해당 데이터를 호환하도록 만들어주는 것이 ORM 프로그래밍이다.

 

-Primary Key(PK,기본 키)

테이블 내에서 특정 레코드를 식별하기 위해 사용하는 식별자. 레코드마다 고유한 값을 가져야 Primary Key가 될 수 있다.

 

-Foreign Key(FK,외래 키)

관계형 데이터베이스에서 두 테이블이 관계(1:1, 1:N, N:M)을 맺고 싶을 때 Foreign Key를 사용한다. RDB에서는 데이터의 중복을 없애는 정규화가 중요한 개념중 하나로 하므로 FK를 이용해 각 테이블간의 데이터중복을 적당한 수준으로 없애는 것이 좋다.

 

최대한 많은 테이블을 FK로 연결하여 중복을 다 없애면 테이블로 여러번 참조하는 과정에서 속도가 느려질 수 있고, 그렇다고 중복을 너무 많이 허용하면 DB의 용량을 낭비하는 결과이므로 정규화에도 정교한 설계와 균형이 필요하다. 이처럼 다양한 부분을 고려해야하는 설계 때문에 DB를 설계하는게 어려운 일이라고 하는 것 같다.

 

FK는 참조되는 테이블의 PK에 대응하게 설정되어 테이블 간에 참조관계를 형성한다. FK를 선언한 테이블은 참조하는 테이블이 되고, 다른 테이블에서 FK로 설정된 PK를 가지고 있는 테이블은 참조되는 테이블이 된다.

 

사실 DB시스템 수업을 1학년 2학기에 들었었는데, 개인적으로는 DB관련 개념이 정말 중요한 개념이고 서비스 구성의 기본이라는 생각이 들었다. 비록 몇시간 안되는 짧은 수업이어서 많은 내용들을 배우지는 못했지만 FK나 PK에 대한 감을 잡을 수 있었고, MySQL로 테이블이 어떻게 구성되는지를 WorkBench에서 시각적으로 확인할 수 있어서 좋았다. FK와 PK개념은 나중에 따로 더 공부를 해서 명확히 해두는게 좋을 것 같다.

#남은 궁금증 --> FK=PK가 될수는 없을까?

 

 

토요일(02.01)

Git 개념 팀 실습하기(merge/rebase/pull request/head)

 

-Head

내가 지금 어느 브랜치에 들어가 있느냐를 가리키는 개념이다.

만들어진 브랜치에 대해서

 

git checkout <들어가고 싶은 브랜치명>

 

위의 명령어로 원하는 브랜치로 이동할 수 있는데, 예를들어 Alpaca 브랜치에 들어갔을 경우 HEAD는 Alpaca 브랜치를 가리키게 된다.

 

-Merge

서로 다른 두개의 브랜치를 병합시키는 명령어이다.

각기 다른 브랜치이므로 아마 브랜치의 내용물도 다를 것이다. Merge는 두 브랜치를 합치면서 공통 파일들은 그대로 두고, 서로 다른 파일들을 모아 통합시켜준다. 이 과정에서 만약 같은 파일의 내용물이 다르다던가 하여 함부로 병합할 수 없을 경우 conflict를 낸다.

 

Merge를 하면 메인 브랜치에 사이드 브랜치가 통합되는 형태로 커밋그래프가 그려지는데, 따라서 Master 브랜치로 다른 브랜치의 내용을 병합하고 싶을 경우 Master 브랜치를 메인 브랜치의 위치에 두어야한다.

 

git checkout master -->마스터 브랜치로 HEAD를 이동

git merge Alpaca --> HEAD가 있는 마스터 브랜치에 Alpaca 브랜치의 내용을 병합시킨다.

 

-Pull Request

협업관리 툴로서 Git repo에는 레포 주인을 제외하고도 여러명의 contributor를 두거나 레포 외부의 회원으로부터 코드의 수정을 제안받을 수 있다. Git repo는 권한이 있는 사람들만 해당 레포에 push하여 내용물을 바꿀 수 있게 만들어져있다. 그렇지 않으면 잘 만들어놓은 프로그램에 예상하지 못한 누군가가 잘못된 코드를 보내 망쳐버리거나, 또는 함부로 원래의 코드를 지워버릴 위험성이 있다.

 

따라서 git에서는 Pull Request라는 요청을 보내 '내가 쓴 코드가 해당 레포에 추가되거나 내용물을 수정해도 되는지, 그럴 가치가 있는지'를 권한이 있는 유저들(레포의 주인을 포함한 여러명의 contributor)에게 묻는다.

 

해당 레포에 대해 push하면 레포의 페이지에 Pull Request를 요청하는 버튼이 뜨고, 해당 버튼을 클릭해 어떤 내용을 추가하거나 수정하고자 하는지 설명한 뒤 신청할 수 있다. 권한이 있는 유저는 생성된 Pull Request에 대해 git에서 자체적으로 제공하는 코드 비교를 통해 어떤 부분이 달라졌고 어떤 부분이 추가되었는지를 시각적으로 바로 확인할 수 있고, 이에 대해 confirm하여 Pull Request를 받아들일 것인지 아닌지를 결정할 수 있다.

 

-Rebase

Rebase에 대해서는 이전에 적어둔 부분(피로그래밍 12기 1주차 활동 정리)을 참조한다.

https://aalphaca.tistory.com/12

 

 

 

이번 주는 6주~8주사이에 어떤 프로젝트를 진행할 것인지 발표와 선정이 주가 되었어서 배운 내용이 많지 않다.

나는 활동기록공유사이트인 LOG SHARE 프로젝트에서 활동하게 되었다. 다음 주차부터는 해당 프로젝트를 하면서 기술적으로 무엇을 어떻게 구현했는지, 그리고 어떤 어려운 점이 있었는지에 대해서 포스팅하고자한다.