우아한테크코스 4기

2월 8일에 있었던 OT가 끝나고, 본격적으로 우테코 생활이 시작되었다. 어제(이미 자정이 지나버려서 그저께가 되어버렸지만) 있었던 OT에서는 교육 소개, 코치진 소개, 우아한형제들 전사교육팀이 리드하는 아이스브레이킹 시간, 교육에 임하는 자세에 대한 포비의 한말씀이

오늘은 따로 강의나 팀 활동이 없는 날이어서, 아침에 게더타운을 이용한 데일리 미팅을 진행한 뒤에 연로그와 어제하던 페어 프로그래밍을 이어서 계속할 수 있었다. 어제 자동차 도메인인 Car 클래스에서 자기 자신의 이름과 위치를 나타내도록 출력할 때 쓰일 toString

화요일부터 시작한 우테코가 어느새 벌써 4일차. 오전에는 강의가 있고, 오후에는 페어 프로그래밍을 마무리하고 최종적으로 1차 PR을 마무리하는 시간이 있었다. 금요일에는 포수타(포비의 수다 타임...? 뭐 그런 이름이었던 것 같은데...)가 있다고 했지만, 첫 주는 페

우테코 첫 주말을 보내고, 벌써 월요일이 되었다. 짧은 주말은 꿀맛같은 휴식을 주면서도, 코드리뷰와 개인 공부로 헛되이 보낼 수는 없던 주말이었다.토요일에 이번 미션의 내 담당 리뷰어이신 제이로부터 자동차 경주 미션의 첫 번째 피드백을 받았다. Pull Requests

우아한테크코스 4기 Level 1 8일차 회고

우아한테크코스 4기 Level 1 9일차 회고

우아한테크코스 4기 Level 1 25일차 회고

우아한테크코스 4기 Level 1 27일차 회고

우아한테크코스 4기 Level 1 28일차 회고

짧은 우테코 생활을 돌아보며 대학 생활을 마무리하고 친구들이 모두 취업 전선에 뛰어들 무렵, 내 발걸음은 우아한테크코스로 향했다. 한 해라도 빨리 취업하는 것이 좋지 않겠냐는 주변의 이야기가 있었다. 하지만 스스로가 전혀 준비되지 않은 개발자라고 생각하던 나는 더

우아한테크코스 레벨 2 과정을 거치면서, 레벨 1 과정 만큼 열정적으로 개발을 공부하고 있지 않다는 생각이 들었습니다. 미션은 계속 주어지는데, 반복되는 미션을 통해 새로운 것을 배워나가는 즐거움이 크게 느껴지지 않았습니다. 슬럼프였다고나 할까요? 리프레시가 필요했습니

프로젝트의 작업들을 해야 할 작업, 진행중인 작업, 완료된 작업으로 구분해서 관리하는 것이 태스크 관리에 훨씬 도움이 된다는 생각이 들었다. 마침 GitHub에서는 GitHub Projects라는 프로젝트를 관리할 수 있는 기능을 제공하고 있다.GitHub Projec

오늘도 그저께와 마찬가지로 5인 페어를 진행했다. 1차 데모 데이까지의 스프린트가 끝나기 전 까지는 계속해서 5인 페어를 하면서 코딩 컨벤션에 적응하며 팀원들 간에 개발 속도를 맞춰가고, 1차 데모 데이 이후 부터는 기능 별로 나눠서 각자 개발을 진행하고 Pull Re

오전에는 UI / UX 특강 DAY 2 일정이 있어 페어를 진행하지 못했고 오후에 페어 프로그래밍을 할 수 있었다. 다만 오전의 UI / UX 특강을 통해 프로젝트에 변동 사항이 생겼는데, 기존에는 각종 개발자용 제품에 대한 리뷰와 평점에 중심을 두었다면 이제는 개발자

페이징을 할 때 size값 요청으로 너무 큰 값이 올 경우를 생각해보자. 지난번에 코린이 페이징 크기를 너무 큰 값으로 요청할 경우 페이징 과정에서 에러가 발생할 수 있다(정확히 어떤 에러인지는 모르겠다. 이 부분은 조금 더 찾아봐야 할 것 같다.)는 이야기를 했다.마

이전에 사이드 프로젝트를 하면서 배운 것 중 하나가 바로 Pull Request를 날릴 때 GitHub Actions 기능으로 빌드를 한 번 돌려보는 workflow를 작성하는 것이었다. 원래는 Pull Request 전에 빌드를 해 보고 성공하면 Pull Reques

프론트엔드 팀으로부터 페이지 조회의 응답 DTO의 필드명을 수정해 달라는 요청이 있었다. 기존에는의 형태였다면, keyboards로 보내준 리스트를 items로 보내달라는 요청이었다.거기에 추가로 백엔드끼리 논의한 결과, 리뷰 도메인에 추가한 createdAt 필드를

특정 제품(현재는 키보드만 있으므로 키보드)에 대해 리뷰를 작성하거나 조회할 때, 해당 제품은 반드시 DB에 저장되어있어야 함이 당연하다. 따라서 만약 DB에 없는 제품에 대해 리뷰를 작성하는 요청이 오면 예외를 반환해주어야한다. 그런데 우리 코드에는 해당 로직이 없었

스프린트 2의 첫날인 오늘은 앞으로 스프린트 2에서 진행해야 할 이슈들에 대한 회의를 진행하는데 많은 시간을 보냈다.생각보다 스프린트 2 일정은 빡빡하다고 생각했다. 2차 데모 요구사항이 생각한 것 보다 많이 나왔기 때문이다.기능에 대한 추가는 예상했지만, 스프린트 2

오전에 Git 브랜치 전략 특강이 있었다. 어제는 분명 우리끼리 정한 브랜치 전략을 컨펌 받는 느낌으로 특강을 듣자고 했었는데, 특강을 듣고 미션을 진행하고 나니 전략을 전면 수정할 필요가 있었다. Git 브랜치 전략 수정에 대한 회의를 하다 보니 하루가 다 지나갔다.

본격적인 스프린트 2 기능들을 개발하기에 앞서 스프린트 1에서 미처 하지 못하고 지나갔던 부분들을 마무리하고 지나가는 시간을 가졌다.도메인 로직이라고 볼 수 있는 규칙들, 예를 들면 리뷰의 평점은 1~5점이어야 한다. 라는 규칙은 도메인 단에서 이미 검증중이지만, 클라

F12 서비스는 개발자의 프로필을 중심으로 하기 때문에 개발자들이 가장 많이 사용하는 플랫폼인 GitHub의 프로필을 사용하려고 한다. 그래서 인증 방식으로 GitHub OAuth + JWT 방식을 사용하기로 했다. GitHub OAuth 인증 방식의 플로우는 다음과

인증 로직이 완성되었으니 인가 로직을 구현하는데 집중했다. 인가 로직은 이미 레벨 2 장바구니 미션에서 인터셉터와 리졸버를 통해 구현하는 것을 배웠기 때문에 해당 부분을 코드에 적용하느라 어렵지 않았다. 하지만 인터셉터를 특정 URL이 아닌 특정 메서드에 적용시키는 방

인증 인가 기능이 완료되었으므로 이제 인증 인가 기능을 활용할 차례다. 인증 인가 기능의 마지막에 리뷰 작성의 경우 반드시 유효한 토큰이 있어야만 작성할 수 있도록 설정했는데, 여기서 가져온 회원 정보로 리뷰와 연관관계를 맺어주는 작업을 진행했다.이 때 우리끼리 정한

현재까지 구현한 리뷰 기능은 C,R 기능만 있고 U,D 기능이 존재하지 않았기 때문에 리뷰의 수정, 삭제 기능을 추가했다. 수정과 삭제 모두 로그인한 회원 정보와 수정/삭제 하려는 리뷰를 findById로 찾아오고, Member에 정의해 놓은 isWrittenBy 메서

우리 서비스의 비즈니스 규칙으로 리뷰를 작성하면 그 리뷰의 대상인 장비가 작성자의 인벤토리에 자동으로 추가된다.를 정했다. 여기서 나와 블링의 의견이 갈렸는데, 나는 서비스 규칙으로는 리뷰를 작성하면 장비가 인벤토리에 추가되어야 하지만, API 설계적인 측면에서는 요청

스프린트 2 데모데이를 위한 배포 버전이 수요일을 끝으로 완료되어서, 수요일까지 미처 마무리하지 못한 자잘한 기능들을 구현은 하되 배포는 데모데이가 끝난 이후 진행하기로 했다.테스트 코드 실행 속도가 느린 점을 해결하기 위해 리팩토링동일 장비에 대해 한 회원이 여러 리

정신없고 피곤한 이틀이 지나가다 보니 개발일지가 밀렸다… 사실 별로 한 내용도 크게 없어서 쓸 내용도 없기는 하지만 우선은 이틀 동안 한 내용이라도 정리해야 할 것 같다.F12의 백엔드는 외부로 유출되어서는 안되는 여러 정보들을 사용한다. 첫째는 바로 GitHub OA

블링과 함께 프론트엔드 메인 서버의 nginx가 정적 파일을 뱉어내지 않는 오류를 해결했다. nginx 설정을 초기화 해보기도 하고, nginx를 아예 지우고 다시 설치해보기도 했는데, 정말 황당한 오류였다. nginx에 권한을 제대로 주지 않은 오류였다. 권한을 적절

오늘 진행한 일 코드 리뷰 개발팀(코린/티키, 클레이)이 작성한 코드에 대한 코드 리뷰를 진행했다. 개발팀을 둘로 나눠서 진행하고 워낙 많은 수정 사항이 있어서 코드 리뷰를 할 양이 많았다. 핵심적인 변경사항이 있었는데, 우선 사용자 검색 기능과 카테고리를 기반으로

어제부터 우리 팀을 괴롭혔던 REST Docs가 보이지 않는 이슈를 해결했다. 표면적인 이유는 Jenkins 빌드 시 workspace를 삭제하도록 변경한 이후로 REST Docs가 보이지 않는 것이 맞았다. 하지만 실제 원인은 다른 곳에 있었는데, 애초에 REST D

front-main, back-main, front-test, back-test 총 네 개의 EC2 인스턴스에 모두 HTTPS 적용을 완료했다. 가비아를 통해 구매한 도메인은 f12.app으로, 서브도메인을 활용하여 www.f12.app은 메인 프론트엔드에, prod.

이전까지는 백엔드 WAS가 띄워져 있는 EC2에 로컬로 h2 데이터베이스를 띄워놓고 사용중이었다. 인바운드 규칙에 보통 DB 포트로 사용하는 3306 포트가 제대로 열려있지 않기도 했었고, 데이터베이스 스키마가 계속 바뀌고 있는 상황이어서 MySQL을 올리고 나면 계속

원래는 오늘 매 스프린트마다 요구사항 중 하나인 스프린트마다 FE에서 BE를 관통하는 기능 중 최소 하나를 FE/BE 페어로 개발을 만족하기 위해서 제품 검색 기능에 대해 팀원 7명이 모두 참여하는 7명의 페어몹 프로그래밍이 있을 예정이었다. 하지만 어제 중부지방에 내

어제 하지 못했던 7인 몹 프로그래밍을 진행했다. 몹으로 진행하기로 한 핵심 기능은 제품 검색 기능이었는데, 백엔드 쪽에서는 인수 테스트 시나리오를 작성한 뒤 레포지토리 단부터 TDD로 올라오는 방식의 프로그래밍을 진행했다. if문으로 카테고리를 분기하고 있던 부분을

기존에는 예외가 터질 때 마다 예외 상황을 나타내는 메시지를 담은 response를 보내주었었다. 하지만 이렇게 하니까, 프론트엔드에서는 백엔드가 보내주는 메시지에 의존해서 개발을 할 수 밖에 없다는 문제가 있었다. (상태코드 + 에러 메시지 형태인데 상태 코드는 세분

초등학교 6년, 중학교 3년, 고등학교 3년, 그리고 대학교 4년. 16년이나 공부를 했지만 단 한 번도 올바른 방법으로 공부하고 있다고 생각해 본 적이 없다. 되돌아보면 내 학습은 능동적이지 않았고, 궁금한 것도 없어서 의욕적이지 않았다.대학 이전 12년의 공부의 목

대부분의 크루들이 그렇겠지만, 우아한테크코스에서 가장 기대했던 활동은 레벨 3 프로젝트였습니다. 우아한테크코스에 들어오기 전, 선배 크루들이 작성한 프로젝트를 보면서 나도 저렇게 잘 짜인 프로젝트를 만들 수 있을까? 라는 생각하며 두근거렸었거든요. 특히나 대학생 때까지

이번 주 개발일지를 쓰지 않았다. 레벨 3 막판이 되어 나태해진 것인지… (물론 그렇다고 작성해야 할 코드를 작성하지 않거나 해야 할 공부를 안하지는 않았다.) 그래도 레벨 3를 마무리하는 입장에서 이번 주 어떤 일들을 했고 어떤 이슈가 있었는지에 대해 남길 필요가 있

우아한테크코스에서는 팀 프로젝트를 진행중입니다. 그 중 이번 5차 데모 데이의 백엔드 요구 사항으로 다음과 같은 부분이 있었습니다.서비스에서 사용하는 쿼리를 정리하고, 각 쿼리에서 사용하는 인덱스 설정서비스에서 사용하는 모든 조회 쿼리와 테이블에 설정한 인덱스 공유인덱

레벨 4는 프로젝트가 주가 아니라는 생각에 레벨 4 초반에는 프로젝트보다는 개인 공부에 집중했었다. 백엔드 쪽 요구사항으로 인덱스와 스레드 설정이 주어졌었는데, 오히려 잘 모르다 보니 오래 고민하고 오래 테스트 해봐야 한다는 것을 몰라서 쉽게 끝낼 수 있을 거라고 착각

지난 시간에 인덱스를 활용하여 어떻게 하면 쿼리 성능을 개선할 수 있을지 MySQL 콘솔을 통해 실험해가며 알아보았습니다. 그를 통해 개선된 쿼리를 만들어 낼 수 있었죠. 하지만 저희 팀 서비스는 결국 스프링과 JPA를 사용한 웹 애플리케이션이고, 개선된 쿼리를 자바

우아한테크코스 마지막 미션인 레거시 코드 리팩토링하기 미션의 마지막 4단계 PR을 제출했습니다. 이번 미션은 우테코를 하면서 가장 많이 고민한 미션이 아니었나 싶은데요, 그동안 우테코에서 객체 지향 프로그래밍에 대해 많이 배웠다고 생각했는데, 이번 미션을 하면서 사실