2021.9.27

시간이 너무 빨리 흐른다..

오늘 캡스톤 수업 교수님께서 너희는 곧 사회로 떠밀려나가질 것이다라고 말씀하셨는데 

두려운 마음이 든다 ㅠㅠ 

 

오늘은 정보처리기사 실기 준비를 위해서 수제비를 이용해 공부를 했다.

전체적으로 한번 훑어본 상태이고, 3주 정도 남은 기간 동안 계속해서 용어를 외우고 프로그래밍 단원을 마스터할 예정이다! (꼭 붙고 말 것이다!!)

 

오늘은 1단원 요구 사항 확인을 공부했다.

배운 공부를 나열해보고 싶은데 분량이 너무 많아서... ㅠㅠ 내일은 2단원을 공부할 예정이다 

어느 정도 암기가 됐다 싶을 때 수제비 카페에 가서 데일리 문제 1단원 범위를 다 풀어보고 뭘 모르는지 확인했다.

 

그리고 노드 js를 공부하면서 리액트도 함께 공부할 예정이다. 백엔드 쪽으로 심도 깊게 공부할 예정이지만

프론트도 어느 정도는 알아야 한다고 생각한다. 자바스크립트의 꽃은 프론트니까? 

 

백엔드를 희망하는데 왜 노드를 배우냐고 묻는 분들이 있을 텐데 

졸업 프로젝트를 노드로 해서 그렇다.. ㅎㅎ 큰 이유는 없다.

한 언어를 잘하게 되면 다른 언어로 전환하는데 어려움이 덜하다고 해서 일단 한 언어라도 열심히 파볼 생각이다!

둘 다 객체지향 언어니까 체제 전환하는데 어려움이 덜할 것으로 예상한다.

 

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

HTTP에서 기본적으로 쓰이는 GET과 POST를 졸프 하면서 주구장창 쓰면서 문득 GET과 POST의 정확한 차이점은 무엇이고, 어느 상황에 쓰여야 할까?라는 의문이 들었다. 그래서 알아보았다.

 

간략하게 정리하자면 GET은 SELECT와 비슷한 성향을 갖고 있다. 즉, GET은 어떤 값을 가져와서 보여주는 역할이지 

서버의 값이나 데이터를 바꿀 수는 없다. POST는 GET과 달리 서버의 값이나 데이터를 바꿀 수 있다.

글쓰기를 하거나 수정하면 DB에 저장되는데 이때 POST를 사용한다.

 

GET과 POST를 사용함에 주의해야 할 점은 또 있다. 그것은 바로 URL 

POST은 내부적으로 처리되기 때문에 URL을 남기지 않지만 GET은 URL을 남긴다. 이를 이용해 링크를 선언할 수 있는 것이다.

 

또 GET은 주소 뒤에 /? 값으로 고유주소가 생긴다. (내가 알기론 이를 querystring이라고 한다.)

POST는 뒤에 숨겨져서 BODY에 보내진다.

POST는 form을 이용해 submit하는 형태이다

 

또 GET과 POST의 차이점은 용량에 있다

 

공부 참고 링크 : https://blog.outsider.ne.kr/312

GET과 POST의 차이 :: Outsider's Dev Story

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

a태그는 해당하는 링크(라우터로 연결돼있음)로 이동할 때 사용해주고

button태그는 링크 이동이 아닌 어떤 function을 할때 사용해주는 것이다. 

class="btn"은 css에서 선언해주기 위해 html안에 선언해준것이다.

 

채팅방에 방 제목을 검색하면 해당하는 방만 출력되도록 해주는 기능을 추가할 예정인데

search.html을 만들고 사용자가 검색을 하면 route에서 search.html로 화면을 이동해주고 해당하는 쿼리값만 출력되록 설정해볼 예정이다. 

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ졸업프로젝트를 진행하는데 있어서 git협업을 사용해보려고 한다.

master는 local저장소를 의미하고

origin/master는 원격 저장소 즉, git저장소를 의미한다.

fetch를 이용하게 되면 원격저장소에 있는 파일을 불러오고 지역저장소에 있는 파일에는 영향을 주지 않는 것을 의미한다.

origin/master를 마우스 우클릭해서 병합하게 되면 내 저장소에 있는 파일이 원격저장소 버전으로 업데이트 된다.

sourcetree에서 공동으로 작업하는 파일을 수정하게 될 때, pull을 꼭 이용해야한다. 그래야만 

버전 병합과정에서 오류가 안나고, 추가 수정을 해야할 상황을 줄일 수 있고, 팀원들간의 소통도 증진 시킬 수 있다.

그렇다면 내가 말하는 pull은 뭐길래?

pull은 공동 작업자중 누군가가 수정한 파일의 버전이 내 버전보다 상위에 있을텐데 그 버전을 pull을통해 받아와서

내 파일로 적용시킬 수 있는 기능이다.

fetch와 pull을 적절하게 잘 사용해서 팀원들과 협업을 하고 프로젝트를 완만하게 통합할 수 있었으면 좋겠다. 

fetch를 이용해서 파일의 수정사항을 확인하고 merge한다음에 수정하는 방법으로 하는게 가장 좋아보인다.

 

그리고 git의 꽃! branch기능!!

test branch를 만들어서 막~수정하고 오류 없애고 기능 추가하고, 다시 마스터로 가서 현재 버전을 test버전으로 병합 을 눌러주면 master버전이 test버전에서 수정했던 것처럼 짜자잔~바뀌기 때문에, 수정사항에 있어서 risk를 줄일 수 있다는 큰 장점!! branch는 삭제안하고 있다가 나중에 그 test순간으로 돌아가고 싶으면 다시 돌아가서 또 수정하고 병합할 수 있는 아주 좋은 기능

 

test라는 branch를 만들지 않았다면 ? 수정하고 병합하는 과정을 자유롭게 하지 못했을것이다!

 

pull request란?

pull request를 통해서 내가 누군가의 오픈소스를 이용했을 때 pull은 자유롭지만, push는 제약사항이 크기 때문에 

내것을 pull 해가세요라고 제안 그니까 request하는 것이다.  누구한테? 원격저장소한테 

이를 통해서 권한이 없는 사람도 권한이 있는 사람이 제안을 허락할 때 push할 수 있게 되는 것이다.

 

이를 혼자서 실험하는 방법은 새로운 계정을 만들어서 2개의 계정으로 실험해보거나

new organization을 통해 테스트 해보는 방법이 있다.

 

다른 계정이 있다고 가정했을 때

Fork를 통해 원격저장소를 복사할 수 있다.(그 원격저장소를 origin으로 설정한다.)

이 저장된 원격저장소를 내가 수정해서 commit 하고 push하게 되면 Fork된 저장소에 올라가게 된다.

 

Compare를 클릭해서 이전 버전과 현재 버전의 차이점을 확인해볼 수 있다.

create pull request를 클릭해서 저장소 주인에게 pull request를 할 수 있다.

저장소 주인은 pull request를 확인해서 merge pull request와 confirm merge 수정 버전과 내 버전을 병합할 수 있게 된다.