스프린트 5도 끝났다. 팀 회고 때도 나온 얘기지만 해야하는 것들의 종류가 많다보니 각각에서 아쉬움이 많이 생긴다. 이번 스프린트 때는 미션에 시간을 거의 투자하지 못했다. 그렇다고 해서 다른 것에 아예 시간을 집중해서 많이 투자할 수 없으니 학습적 만족도가 많이 떨어

환경을 어떻게 설정하고 테스트해야할지 감이 잘 오지 않아서 실험을 여러번 다시했다. 그리고 아직도 완전히 정답을 찾은 것 같지는 않지만 나름대로 이유를 세우면서 테스트를 해보려했다. 1\. Nginx에 부하테스트 vs WAS에 부하테스트처음에는 Nginx 인스턴스에 부

부하테스트 툴을 선정하는데 JMeter, nGrinder, k6 중에서 고려를 했다.k6의 경우 결과 시각화를 하려면 유료로 서비스를 쓰거나 CLI로 쓰고 그라파나와 결합을 해야했다. 또 자바스크립트로 테스트를 작성해야해서 거부감을 갖는 팀원도 있었다. JMeter는

참고 - MySQL 과 JPA에서 페이징위 글 마지막 부분에서 나왔듯 offset 방식은 데이터가 커지면 그만큼 느려진다. 그래서 찾아보면서 알게된 해결책들을 정리한다. 문자 그대로 offset을 쓰지 않는 방식이다. 즉, 페이지 번호를 이용해서 한번에 자유롭게 특정

이번 학습 및 테스트 강의 - 인프라 및 DB 인덱스, 트랜잭션, Nginx 강의 - Servlet & Servlet Container 어노테이션 [프로메테우스, 그라파나를 이용한 모니터](https://velog.io/@injoon2019/%ED%94%84%E

강의 - Thread 활용하기이번 미션은 이때까지 진행한 미션 중 가장 집중을 못했던 것 같다. 다른 일들이 있어 미션을 늦게 시작했고, 그렇게 한번 밀리니 점점 좋은 코드나 테스트 코드 작성 보다는 구현에 급급했던 것 같다. 또 이번 미션에서 무엇을 얻어갈지 명확히

현재 속닥속닥 프로젝트에는 무한 스크롤이 구현되어 있다. 일정 크기의 페이지만큼 게시글 목록을 배열로 주고, 사용자가 스크롤을 내려서 그 글을 다보면 프론트에서 다음 페이징에 대한 요청을 날린다. MySQL에서 페이징 쿼리를 작성할 때 항상 limit과 offset 계

레벨 4가 시작됐다. 레벨이 올라가면서 점점 더 바빠지고 있었는데 이번 레벨 역시 마찬가지일 것 같다. 레벨 4는 팀 프로젝트, 개인 미션, 스터디, 테코톡 등이 다 겹칠 것 같다. 방학 때부터 하던 고민이 레벨4 첫 주에 정점을 찍었다. 원래 이런 스트레스를 잘 받지

우테코에서 마지막 방학이었다. 레벨4와 5는 중간에 쉬는 것 없이 13주간 이어진다고 한다. 그래서 이번 방학은 잘 쉬고 잘 노는 것에 초점을 맞췄다. 지금까지 세 번의 방학이 있었는데 그 중 제일 재밌는 방학이었다. 스프링 DB 접근 기술 2편강의 절반정도는 사실 J

레벨 3 마지막 스프린트가 끝났다. 두번째 스프린트, 세번째 스프린트가 정말 바빴던 것에 비해서 그렇게 바쁘지는 않았다. 조시랑 페어하면서 앞에서 놓쳤던 인프라들을 살펴보고, 조금씩 정리를 하는 시간들을 주로 가졌다. 레벨 3는 정말 재밌었다. 레벨 1보다 2가 더 재

스프린트 1, 2, 3때 인프라 쪽을 전혀 다루지 않다가 4에 들어서 인프라를 다루게 되었다. 앞서 인프라를 담당했던 팀원들에게 간단하게 인수인계를 받았는데 막상 해보려하니 생각하지 못했던 부분에서 막히는 경우가 있었다. 이번에도 소나큐브를 실행시키려는데 명령어를 잘친

팀에서 매 스프린트마다 번갈아가며 인프라를 맡고 있다. 이번 스프린트에는 나와 조시가 인프라를 맡기로 했고, 그간 인프라를 하지 않아서 놓쳤던 부분들을 따라가고 있다. 이번 주에 대댓글 기능이 구현되어서 그 기능을 출시했다. 사용자 입장에서는 아주 큰 기능이 아닐 수

CS 스터디에서 프로세스와 스레드 차이에 대해 발표를 했다. 그리고 언제 멀티스레드를 써야할까라는 질문에 엔터프라이즈 환경에서 대규모 요청이 오는 프로젝트라면 성능을 위해 멀티스레드를 사용할 것 같습니다라고 답을 했다. 하지만 답을 하고 나서 스스로 찜찜한 부분이 있었

익명 커뮤니티를 만드는 서비스 특성상 비밀번호는 물론이고 아이디까지 암호화해서 저장해야 한다. 이 암호화를 어디서 어떻게 해줘야할지에 대해 팀에서 토론이 있었다. 토론이 재밌었고 생각하지 못했던 부분들이 있어서 기록으로 남긴다. 현재는 이런 방식으로 회원가입 요청이 오

시간이 정말 빠르다. 어느새 세 번째 스프린트가 끝이났다. 이번 스프린트는 레벨3 들어서 가장 정신이 없던 스프린트였다. 스프린트2가 끝나고 회고할 때 개인공부 시간을 늘려보겠다고 했는데 거의 매일 11시쯤 집에가서 개인 공부를 많이 못했던 것 같다. 특히 이번주에는

세 번째 스프린트가 시작됐다. 이번 스프린트에서는 기능들을 나누어서 각자 원하는 부분을 맡아서 구현하고 코드리뷰를 하기로 했다. 몹과 페어 프로그래밍은 다 같이 의견 얘기하고 듣는 재미가 있었다면 각자 기능을 구현하는 것은 속도감과 코드리뷰 하는 재미가 있었다. RES

회원가입을 할 때 이메일을 통해서 인증을 하고 있다. 하지만 SMTP는 외부서비스이며 실제로 굉장히 느리다. 처음 브라우저에서 버튼을 눌렀을 때 2~3 초동안 반응이 없었고 짧다면 짧은 순간이지만 고객의 입장에서는 충분히 불편할 수 있는 순간이었다. 그래서 1차적으로

두 번째 스프린트가 끝났다. 처음에는 스프린트 목표가 조금 많지 않나라는 생각이 팀내에서 있었음에도 불구하고 결국 기간내에 구현을 해냈다. 이번 스프린트의 첫 주차까지도 백엔드는 몹 프로그래밍을 진행해서 속도가 조금 느린편이었는데 결국 다 해내서 팀원들이 참 대단하다는

이메일로 사용자가 인증코드 발송 요청을 보내면 적합한 회원인지 검증을하고, 인증 번호를 발송해준다. 인증 번호를 보낼 때 사용자가 여러 번 클릭해서 요청을 할 수도 있으므로 이전의 인증 번호를 삭제하고 다시 생성해서 DB에 저장후 보내준다. 하지만 실제로 삭제되지 않고

두 번째 스프린트가 시작됐다. 첫번째 스프린트와 마찬가지로 이번 스트린트에 들어가야할 기능이 무엇인지 이야기하고 같이 디자인을 하는 것으로 시작했다. 백엔드는 회원가입/로그인 기능이 익명 커뮤니티라는 프로젝트 특성상 중요하고 모두 하고 싶어해서 다같이 몹프로그래밍으로