기다리고 기다리던 우테코 프리코스의 1차 결과가 나왔다.운이 좋게도 우테코 프리코스에 1차 합격을 하게 되어서 최종 코딩테스트를 치게 되었다..🥹 사실 4주 차 과제를 만족스럽게 하지 못했고 자소서에 인턴을 하고 있다고 솔직하게 써놔서 불합격 스택이 엄청나게 쌓인 상태였기 때문에 당연히 떨어질 줄 알았다. 그래서 메일이 왔다고 했을 때 열어보는 것이 조금 두려웠다. 하지만 인턴 기간 중에 죽어라 과제를 하던 내 모습이 생각나서 떨어져도 만족스러웠다..라고 생각하며 메일을 열어봤는데 다행히도 1차 합격을 할 수 있었다..ㅠㅠ 경쟁률은 프론트 기준으로 1주 차 과제를 할 때 PR이 450개 정도였는데, 최종 코딩테스트를 본 사람이 85명이니까 1:5.x 정도였던 것 같다. 내가 왜 붙었을까 곰곰이 생각해..

3주 차는 가장 급했지만, 그래도 여태까지 작성한 코드들 중 가장 좋은 코드를 짰다. 이렇게 될 수 있었던 이유는 힘들었지만 내가 우테코 과정을 재밌게 즐기면서 잘 노력했기 때문이라고 생각한다.이번 주차는 특히 당연한 걸 당연하지 않게 생각하는 것에서 큰 성과를 이루었다고 생각한다.물론 아쉬운 점도 존재하긴 하지만 4주 차도 잘 준비해서 유종의 미를 맺었으면 좋겠다.(3주 차는 4주 차 과제가 너무 어려워 시간이 필요해 블로그를 빠르게 작성하려고 한다.. 블로그도 나중에 리팩토링,,,)목표설정이번 주차의 목표는 퇴고였다.새로운 것을 잘하기 보단, 기존에 잘하고 있던 것이나 피드백으로 주어진 것들을 잘 지키며 하고 있는지를 중점으로 생각하며 코드를 작성했던 것 같다.우테코에선 매번 새로운 것을 배우다 보니..

우테코 2주 차도 어느덧 끝이 났다.  주 차를 거듭하면 생각의 깊이가 점점 깊어지는 듯한 느낌을 받는다.이전 주 차에서의 부족함을 발판 삼아 더 좋은 코드를 짜려고 하니 고민해야 할 것들이 점점 늘어나는 것 같다. 1주 차때 나는 많은 실수들을 했기 때문에, 2주 차에서는 최대한 1주 차에서 느꼈던 아쉬움을 해소하기 위해 노력했다.1주 차에서 가장 아쉬웠던 점은 요구사항을 꼼꼼하게 반영하지 못했다는 점이 많이 아쉽게 다가왔다. 결론적으로 얘기하면 2주 차에서는 요구사항에 관한 점은 잘 지킨 것 같다! 다만 조금의 실수를 곁들인..ㅋㅋㅋㅠㅠ 이번의 실수는 놓쳤다기 보단 몰라서 하지 못한 실수들이 많았지만 그래도 분명 몰랐던 것들은 아니었는데 생각이 짧았던 것 같다.이번 회고를 통해 3주 차에서도 2주 차..

1주 차를 요약하자면 잘해보려고 이것저것 해보다가 말아먹은 상황인 것 같다.기본기가 바탕이 되고 확장을 해야 한다는 말이 정말 뼈저리게 와닿았다.다만, 실수를 해보니 많은 것을 깨달았고 이를 반면교사 삼아서 2주 차에선 더욱 노력해보려고 한다.목표 설정프리코스 미션을 처음 받았을때 느낀 점은 생각보다 제작해야 하는 기능이 어렵지 않았다는 것이었다. 그래서 주어진 학습 목표에 우선 충실하고자 하였다. 나의 1주 차 목표는 우테코에서 제공하는 가이드에 대해서 잘 인지를 하고, 구조적으로 역할이 잘 분리된 근거 있는 코드를 짜는 것이었다. 그래서 아래와 같이 단계를 세웠다. 요구사항 파악하기진행 순서도 및 구현할 기능 목록 작성해보기근거 있는 코드 작성하기리뷰 및 회고하기요구사항 파악하기그냥 미션만 잘 수행하..

우테코 프리코스를 본격적으로 수행하기에 앞서 요구사항을 읽어보니 다음과 같은 조건이 있었다.AngularJS Git Commit Message Conventions을 참고해 커밋 메시지를 작성한다. Git Commit Message ConventionsGit Commit Message Conventions. GitHub Gist: instantly share code, notes, and snippets.gist.github.com 그래서 영어는 잼병이지만.. 다음 커밋 방법에 대해서 우선 천천히 읽어보며 정리를 해보려고 한다. 목표스크립트로 CHANGELOG.md를 작성 할 수 있다.git bisect 으로 중요도가 떨어지는 commit을 무시 할 수 있다.commit 기록을 확인(browsing)할 ..

프리코스 가이드 (기본은 지키자)기본적인 수행 과정미션 repo를 포크해서 내 repo로 옮기기내 pc에 clone 생성하기이때 기능 구현을 위한 branch 생성이때 git checkout -b "본인 아이디" 로 브랜치 생성기능 구현하기기능 구현 후 add, commit내 repo에 push 하기 (push는 이전의 내가 사용한 닉네임 브랜치로 하기)github 서비스에서 PR 보내기pr은 내 repo의 닉네임 브랜치 -> woowacourse repo의 main 브랜치로 보내기우아한테크코스 지원 플랫폼에 접속하여 프리코스 과제를 제출하기테스트 및 자세한건 해당 링크 에서 확인주의사항기능 구현을 모두 정상적으로 했더라도 요구 사항에 명시된 출력값 형식을 지키지 않을 경우 0점으로 처리.기능 구현을 완..

오늘 아침 5시부터 잘 돌아가고 있던 서비스의 api가 동작하지 않는 일이 일어났다.그래서 해당 기업의 대표님 한테서 연락이 와있어서 출근하기 전 빠르게 원인을 알아보려고 했는데, 내 웨일 브라우저에서는 에러가 발생하지 않았다.  웹 빌더의 배포과정에서 에러가 난걸까? 하고 여러가지 계정을 통해 확인해보았지만 에러는 발생하지 않았다.그래서 회사에서 차분히 대표님의 브라우저나 계정을 확인해보고 테스트 해 보았는데 try-catch로 예외 처리를 해둔 에러문구가 발생했다.(정말 예외 처리의 중요성을 다시한번..ㅠㅠ) 크롬 브라우저에서 아래와 같은 에러가 발생하고 있었는데 구글링을 잠깐 해보니 SSL이 만료되어서 발생하는 에러인 것 같았다.GET "https://api~~" NET::ERR_CERT_DATE_..

웹 에이전시를 다니다 보니 클라이언트의 요구사항과 재정에 따라 프로젝트의 기술스택을 정하는 것이 효율적인 개발에 있어 중요하다고 생각하게 되었다. 회사를 운영하는 관점에서는 더욱 중요하겠지만, 개인적인 프로젝트를 할 때에도 빠른 배포가 목적이라면 기획자의 요구사항에 가장 적합한 기술스택을 선정해 진행하는 것이 옳다고 생각한다. 이전에는 Nuxt.js를 쓰면 CSR, SSR, SEO 다 대응 가능하니까 무조건적으로 좋은 기술을 쓰는게 좋지 않은가? 라고 생각했었다. 하지만 다양한 기술을 지원한다는 것은 그것들을 핸들링 하기 위한 배경지식이 마련되어 있어야 한다는 것을 느꼈다. 배경지식 없이 일단 진행하기엔 차후 에러를 일으킬 가능성과 삽질을 하게될 가능성이 높아지기 때문이다. 이러한 부분은 개발 속도와 단..