녕의 학습 기록

지난 12월 27일은 우테코 7기 최종 발표날이었다. 말로는 기대 안한다고 하면서도 잔뜩 긴장한 채 3시가 되기만을 기다렸다.일부러 2시쯤 집을 나와 1시간 거리에 있는 카페로 향하였고, 카페에 앉아 노트북을 켜니 3시가 되었다. 슬슬 오픈채팅방에 합격 메일이 왔다는 소식이 여럿 들려왔지만 내게는 아직 메일이 오지 않았다. 새로고침을 계속 해봐도 메일이 오지 않아 합격 메일만 빨리 보내주는구나... 하고 절망하던 중.메일이 도착했고 될대로 되라하고 바로 클릭해봤다. "합격"......................!!!!!!!!!!그렇게 기쁜 마음에 카페에서 혼자 격하게 들썩였다. 그리고 자기소개서부터 최종 발표까지 2달간 스트레스를 받으며 고생했던게 생각나 급 울컥했지만 끝내 눈물은 나오지 않았다. 친구..

1차 합격지난 12월 9일, 우테코 7기의 1차 결과 발표가 있었다. 1차는 자기소개서 및 프리코스를 기반으로 추려진다. 우테코가 너무나도 간절하게 하고 싶어 자기소개서와 프리코스에 최선을 다한 나였기에 내심 기대를 많이 하고 있었다. 발표는 3시였는데 정말 더럽게 시간이 가지 않아 카페에서 그림판에 부적을 만들기도 했다. 그러다가 3시가 되었고, 머지않아 네이버 앱에 우테코 1차 결과 메일 알림이 왔다.너무 떨려서 한 3분동안은 확인하지 못하다가 에라 모르겠다 하고 클릭을 했고.눈에 들어온 '합격'이라는 단어에 순간의 기쁨을 참지 못하고 카페에서 소리를 지를 뻔 했다. 너무 기뻐서 주변인 2명 정도에게 전화를 해 이 소식을 알리고 난 후에야 매우 큰일났음을 깨달았다.프리코스가 끝나고 1차 결과가 나오기..

1주차에 대한 피드백 중 한가지는 'Git으로 관리할 자원을 고려하라'였다. 예를 들면 자바의 .class 파일은 git으로 관리할 필요가 없다.자바 코드만 있으면 .class 파일을 생성할 수 있기 때문이다. 나는 평소 개발할 때 어떤 파일을 git으로 관리할지는 .gitignore로 관리했었다.주로 민감한 파일이 github에 올라가지 않게끔 자동으로 생성된 .gitinore파일에 추가하는 방식이었다.그러나 자동으로 생성된 .gitignore에 대해서는 궁금증을 가지고 알아본 적이 없었다. 1주차 피드백이기도 하고, 알아두면 나중에 관련한 문제가 생겼을 때 도움이 될 거 같아 알아보았다. 우선 기존의 .gitignore파일이다 HELP.md.gradlebuild/!gradle/wrapper/gradl..

1주차의 공통 피드백에는 다음 링크와 함께 커밋 메세지를 의미있게 작성하라는 내용이 있었다.https://meetup.nhncloud.com/posts/106 링크 속 내용을 쭉 정독하고 가장 고민 된 부분은그래서 제목을 명령조로 사용할 것인가?였다. 영어 기준으로 좋은 커밋 메세지는 제목을 명령조로 작성한다고 한다.예를 들어 A메서드를 변경했으면 -> Change A method 이렇게 말이다. 근데 한국어로 작성하면 커밋 메세지의 제목이 'A메서드를 변경하라' 가 되어버린다.작성하면서도 이게 맞나하는 생각과 함께 나도 영어로 커밋 메세지를 작성해야하나 싶기도 했다.하지만 커밋 메세지를 작성하는 사람과 읽는 사람 모두가 한국인일 것이기 때문에 한국어를 사용하기로 했다. 그렇다면, 한국어로 커밋 메세지의..

1주차가 끝나고 코드리뷰를 하면서 다른 사람들의 기능목록을 봤는데많은 분들이 내가 생각했던 것 보다더 세세하게 적어서 놀랐었다.그래서 2주차가 시작되는 지금 과연 기능 목록을 얼마나 세세하게 적으면 좋을 지 다시 고민했다. 우테코 프리코스에서는 기능 목록의 기능 단위로 커밋할 것을 권장하고 있다.만약 이 기능이라는 것을 너무 큰 범위로 잡아버리면 하나의 커밋 내에 너무 많은 변경사항이 생길 것이고.너무 작은 범위로 잡아버리면 실제로 구현할 때 유연성이나 자유성이 많이 저하될 거라고 생각했다. 그렇다면 기능 목록의 기능을 어떻게 잡아야할까?정답은 없을 것이기에 나만의 기준을 내려야 한다. 1주차 계산기 미션을 한 문단으로 쭉 설명해보자.사용자로부터 문자열을 입력을 받는다. 그리고 계산기의 구분자로 입력을 ..