초보 개발자

5주차에는 tf를 사용해서 모델을 만든 뒤 그걸 이용한 페이지를 만드는 것이 과제였다. 아래의 url을 통해서 결과물을 확인할 수 있다. taehyeki/project2: tf를 사용하여 강아지상 고양이상을 판별하여 주는 기능입니다. (github.com) GitHub - taehyeki/project2: tf를 사용하여 강아지상 고양이상을 판별하여 주는 기능입니다. tf를 사용하여 강아지상 고양이상을 판별하여 주는 기능입니다. Contribute to taehyeki/project2 development by creating an account on GitHub. github.com 과제를 진행하면서 blob에 대한 것을 활용하였는데, js에서 buffer와 blob에 대해 좀 더 공부를 해보아야겠다.

정규표현식 옵션 /abc/gi 와 같은 정규식이 있다고 할 때 / /

힙은 데이터에서 최대값과 최소값을 빠르게 찾기 위해 고안된 완전 이진트리이다. 항상 최대의 값들이 필요한 연산이 있다면 힙을 사용하면된다, 힙은 항상 큰 값이 상위에 있고 작은 값이 하위 레벨에 있도록 하는 자료구조이다. 다시 말하면 부모 노드의 값이 자식 노드의 값보다 항상 커야 한다. 그러면 가장 큰 값은 모든 자식보다 커야하기 때문에 가장 위로 갈 것이다. 따라서 최대의 값들을 빨리 구할 수 있다, 맥스 힙의 원소 제거 최대 힙에서 원소를 삭제하는 방법은 최댓값, 루트 노드를 삭제하는 것이다. 스택과 같이 맨 위에 있는 원소만 제거할 수 있고, 다른 위치의 노드를 삭제할 수는 없다. 또한 맥스 힙에 원소를 추가했던 것과 마찬가지로 원소를 삭제할 때도 힙의 규칙이 지켜져야한다. 아래와 같은 방법으로 ..

stash는 숨겨두거나 넣어둔 다는 뜻으로 프로젝트의 변경사항을 임시적으로 보관해둘 때 사용한다. 예를 들어 다른 branch로 체크아웃 하는 경우 현재 branch의 변경사항이 사라지게 된다. 아직 작업 중이라 commit하지 않고 변경사항만 보관해두고 싶을 수도 있다. commit대신 stash를 사용한다. 기존 파일을 수정하면 변경된 사항이 있다고 소스트리에서 알려줄 것이다. 근데 여기서 main 브랜치에서 무언가를 작업해야하는 상황이어서 main브랜치로 체크아웃을 해버리면 다른 브랜치의 수정 내용이 사라지기때문에 이렇게 해주면 변경된 사항이 있다는 메시지가 사라지게되고 귀신같이 파일역시 수정 전 상황으로 돌아갔다. 파일의 작업내용 자체를 어딘가에 보관해버린것이다. main브랜치에서 하던일을 마저하..

대부분의 되돌리기 작업을 하면 협업하는 다른 사람에게도 영향을 미칠 수 있다. 기본적으로 나만 작업하는 특정branch 하나에만 적용한다라고 생각하자. amend 작업하다가 commit 메시지에 오타가 났다거나 수정하고싶을 때가 있을 것이다. 이 때 최신의 commit을 수정하는 것을 amend라고 한다. amend로는 가장 최신의 commit만 고칠 수 있다는 것을 꼭 기억해두자. 그 전의 commit은 못고침 먼저 브랜치를 하나 만들어주고 파일을 2개 수정해보자. 그런 뒤 2개가 아닌 하나만 커밋을 해버렸다. 그럼 소스트리에서는 아래와 같을 것이다. 이를 수정해주기 위하여 소스트리의 파일상태로 가서 커밋을 정정해주자. 커밋 메시지도 변경할 수 있다. 변경후 history를 보면 아래와 같이 잘 수정이..

내가 주인이 아닌 다른 repo에 PR하려면 어떻게 해야할까?? 바로 fork(프로젝트 복사)가 필요하다. repo의 사용권한이 다른사람에게 있을 때 예를 들면 많은 사람들이 참여하는 오픈소스처럼, 내가 소유하고 있는 repo가 아니더라도 프로젝트를 제안할 때는 일단 프로젝트의 내용을 내 공간으로 가져와야 한다. 먼저 fork할 repo에 가서 fork버튼을 눌러주자 그럼 repo주소가 이렇게 바뀌는 것을 확인할 수가 있다. 이제 이걸 내 컴퓨터에 클론 해 온 다음에 거기서 작업을하고 푸쉬를 한 뒤 pr을 날려보자. 왜냐하면 우리는 저 repo에 작업권한이 없기 때문이다. 주소를 복사해 온 뒤 소스트리에 가서 주소를 복사하여 클론해보자. 그리고 브랜치를 생성하여 작업을 해보자. 작업을 한 뒤 커밋 후 푸..

merge를 할 때 경우에 따라 작업한 내용을 리뷰하고 최종적으로 프로젝트에 반영한다. 이걸 PR후 merge라고 한다. PR(Pull Request)느 내 작업내역을 바로 merge하지 않고 참여하고 있는 프로젝트 내 작업(branch)을 merge해달라고 요청(Request)을 먼저 보내는 것이다. 작업한 내용에 대해 코드리뷰를 하거나 토론하면서 개선시킬 수 있는 기회가 생기는 것이다. 프로젝트 기준에 맞지 않는다면 PR은 거부될 수도 있다. 이렇게 리뷰한 후 작업내역을 최종 반영하면 프로젝트 퀄리티가 더 높아질 것이다. 또 기본적으로 프로젝트 품질을 관리해야 하는 회사에서 작업하거나, 여러 사람들이 참여하는 오픈소스에서는 PR후 merge하는 과정을 거치게 된다. 먼저 같은 repo안에서 기본 브랜..

원격 repo는 로컬 repo가 연결되어있다고 했다. 하지만 사실 이 연결은 로컬 repo의 브랜치와 원격 repo의 브랜치가 연결된 것과 같다. 따로 설정을 해주지 않는다면 기본적으로 로컬 repo의 브랜치명과 같게 원격 repo의 브랜치 명이 생성이 되어 tracking을 한다. commit history에 보여지는 orgin/main 혹은 origin/master이름표는 원격 repo의 main 혹은 master 브랜치라는 뜻이다. 원격 repo를 연결할 때 origin이라고 적어주었기 때문에 앞에 origin이 붙는다. origin/HEAD는 현재 어떤 것을 가리키고 있는지이다. 그림으로 나타내면 아래와 같다. pull과 push는 결국 특정 branch에 있는 commit을 여기와 연결되어 있는..