우테코

https://github.com/injoon2019/java-baseball-precourse/tree/injoon2019사실 숫자 야구를 구현하는 것 자체는 그리 어렵지 않다. 단순히 구현을 하고 끝낸다면 내가 배울 수 있는 것은 작을 것이다. 하지만 여기

기다리던 우테코가 시작되었다. 최종 합격을 한 후 공부를 하기보다는 푹 쉬고 읽어볼 책들을 정리하는 정도만 했다. 처음 공고했던 인원보다는 적은 인원들이 선발되었다. 다들 열정이 가득해보였다. 매 미션마다 저장소로 이동해서 포크후 포크된 레포에 간다. 다른 모든 브랜치

결론부터 말하자면 컨트롤러에서 테스트하고 싶은 부분이 있으면 해당 부분을 도메인 레벨로 내려서 테스트해보는 걸 도전해보시는 걸 권장합니다. 나중에 외부 라이브러리에 의존하게 되고, 테스트하기 불가능하거나 어려운 부분이 있다면 행위 검증이라도 해야겠지만 레벨1 미션을 하

https://homoefficio.github.io/2016/06/26/for-loop-%EB%A5%BC-Stream-forEach-%EB%A1%9C-%EB%B0%94%EA%BE%B8%EC%A7%80-%EB%A7%90%EC%95%84%EC%95%BC-%ED%

Random 객체를 사용하도록 변경하였습니다. 질문이 하나 생겼는데 랜덤 객체는 굳이 여러개가 생성될 필요 없을 것 같아 static으로 만들었습니다. 또한 변경되지 않을 것 같아 final을 붙였구요. 그러면 static final이 붙는데 이것도 상수 취급을 하는건

깃허브에서 코드를 보다보면 마지막 줄에 이런 식으로 표시가 되어있는 것을 볼 수 있다. 마지막 행에 공백 줄이 들어가지 않았기 때문이다. 애초에 Posix에서 명세를 그렇게 만들었다.행의 끝(terminating)은 개행(EOL, end-of-line)텍스트 파일은 행

constructor chaining에 대해서 알아볼까요? 0으로 초기화는 한 군데서만 해주면 좋을 것 같아요. 중복 코드는 최대한 제거해주세요! 정의 Constructor chaining은 생성자들을 연속적으로 부르는 것이다. this() 키워드를 사용해서 같은

이펙티브 자바 아이템 1를 참고해보면 좋을 거 같아요 :) 생성자 대신 정적 팩토리 메서드 여기서 말하는 디자인 패턴의 팩토리 메서드와 다른 것이다. public을 이용한 생성자 대신 static 팩토리 메서드를 제공하는 것이다. 정적 팩토리 메서드란 객체 생성의

정적 팩토리 메서드 잘 만들어주셨습니다 👍이제 position을 직접 초기화 해주는 부분은 없어도 되지 않을까요? 😁직접 초기화라고 말씀하신 부분이 private int position = 0; 이 부분 맞을까요?위에서 말씀하신(https://github.

여기에 남기는 코멘트는 아니고 Cars>이 메서드는 도메인 객체인 Cars의 메서드임에도 불구하고 테스트가 불가능한 구조인 것 같아요.Cars에서 랜덤을 분리한다면 테스트가 가능한 구조를 만들 수 있을 거 같은데 한 번 도전해보시는 것도 좋을 거 같네요 :)이 부분 이

MVC 패턴은 잘 정리된 블로그나 영상들이 너무 많다. 그래서 미션을 진행하면서 놓쳤던 부분들만 간단하게 정리를 한다. InputView에서 차 이름들을 반환할 때 split을 해서 List<String>을 넘겨줘도 괜찮아보여요. 네! 이 부분에 대해 그렇지 않

IllegalArgumentException은 어떨 때 사용하는 예외일까요?프리코스 과정에서는 IllegalArgumentException을 반환하라고 했었다. 그래서 습관적으로 예외를 반환해야 하는 상황에서는 IllegalArgumentException을 썼다. 새

Car 객체들을 모두 생성하고 new Cars(cars)와 같이 생성하면 Cars 객체를 불변 객체로 만들 수 있지 않을까요?네 맞네요! 일급 컬렉션을 쓰는 이유에서 불변 객체 장점을 놓쳤네요. 감사합니다!일급컬렉션을 써야하는 이유에 대해서는 위의 블로그에서 정리가 잘

자동차 경주 미션이 진행되었고, 오늘 머지가 돼서 끝이났다. 나의 미션 리뷰어는 범블비였는데 많은 부분에 대해 이야기를 나누고 학습할 수 있었다. 상태 검증과 행위 검증스트림은 항상 좋을까?이것도 상수인가?Posix new lineChaining Constructors

발표자 - 웨지 (3기)자신에게 잘 맞는 학습방법이 중요하다. 꼭 스터디를 할 필요는 없다. 일정 숫자 이상의 사람이 모여 함께 공부하는 것함께 하는 활동이 필요하다.기대할 수 있는 것동기 부여학습 효율 상승공부한 것에 대해 말해보기.상호보완한가지 주제에 대해 학습하고

이번 주는 페어가 새로 맺어졌고 차리와 승팡과 함께 하게됐다.차리와 승팡은 지난 미션 때도 같은 페어였고, 이번에는 나까지 하여 세 명이서 하게됐다. 최대한 같은 페어는 피하도록 되어있을텐데 아마 세명이라서 다른 페어 객체(?)라고 인식을 한듯하다. 세 명이서 페어 프

lottoRanks를 생성하고, lottoRanks값을 하나씩 추가하고 있는 구조인데요.명령형으로 코드를 작성하면 lottoRanks가 가변변수가 되고, 사이드이펙트가 생길 수 있는 여지가 생기는데요.이 부분을 선언적으로 작성해보는걸 추천드려요.리뷰어의 리뷰였는데 선언

스터디를 하다가 다중상속 이야기가 나왔다. 자바의 클래스에서 다중상속은 허용되어 있지 않고, 파이썬과 C++에서는 허용되어있다. 하지만 자바에서도 인터페이스에서는 다중상속이 허용되어있다. 다중상속이 무엇이고, 왜 어디서는 허용되고 어디서는 허용되지 않는 것일까다중상속은

모던 자바 인 액션 첫 장을 읽어보면 마치 스트림을 써야하는 이유가 멀티코어 컴퓨터의 보급화와 병렬성을 이용하기 위함인 것처럼 전개하고 있다. 하지만 stream에서 디폴트는 parallel이 아니고, 이펙티브 자바에서도 스트림 병렬화는 주의해서 사용해라(아이템 48)

명령형 vs 선언형이번 미션을 진행하면서 많은 피드백을 받았고 인상 깊었던 부분은 선언형 프로그래밍이다. 이때까지 내가 코드를 작성하던 방식이 명령형인지 인지조차 못하고 있었는데 이번 기회를 통해서 선언형이 어떤 것인지, 어떤 장점이 있는지 알게되었다. 아직 선언형 프

3기 웨지, 카일다른 코치나 크루에게 배울 점이 많다. 조직에는 세 가지의 사람이 있다.Giver: 주는게 익숙한 사람Taker: 받는게 더 익숙한 사람Matcher: 받은 만큼 주는 사람Giver는 성과에서 최하위인 사람도 있고, 최상위인 사람도 있었다. 아마 얼마나

시간이 참 빨리간다. 일주일에 한번 회고를 쓰는데 지난 회고를 쓴지 얼마 안돼서 또 쓴다는 생각이 든다. 어느새 겨울도 지나가서 춥지 않고, 부산 친구들의 프사에는 꽃을 배경으로 한 사진들이 올라온다.이번 페어 프로그래밍은 쿼리치와 함께 했다. 지하철로 4 정거장 밖에

합계를 내는데 만약 합계가 21이 넘으면 ace가 있는지 탐색해서 ace를 11대신 1로 계산을 하고자했다. 하지만 아래와 같은 문구가 떴다.Variable used in lambda expression should be final or effectively final

이번 한 주도 빠르게 지나갔다. 전체적으로 만족스러운 한 주였다. 지난 주에 하루 한 잔만 커피를 마시자고 계획을 세웠는데 잘 지켰다. 덕분에 밤 늦게 잠 못드는 경우가 없었고, 전체적으로 컨디션이 괜찮았다. 또 최소한으로 해야할 것들을 계획했는데 잘 지켰다. 브라운과

이펙티브 자바에서 아이템 7. 다 쓴 객체 참조를 해제하라를 공부하다가 WeakHashMap이 나왔다. 찾아보다가 참조에도 종류가 있다는 걸 알게 되었다.strong -> soft -> weak -> phantom 순이다.일반적으로 흔히 써왔던 것들이 강한 참조다.위의

레벨 1에서 가장 어렵다는 체스 미션 시작 주였다.스터디들이 진행이 되고, 글쓰기 미션도 추가되었다. 그 와중에 회식도 있었기 때문에 정말 정신 없이 한 주가 지나갔다.정말 찐하게 페어 프로그래밍을 한 주였다. 이번 페어는 같은 조인 후디였다. 마감 기간이 평소보다 3

글쓰기 미션으로 시작하는 한 주였다. 이번 주 초반에는 체스 미션 리뷰를 기다리며 글쓰기 미션을 하였고 다른 크루들의 글을 읽어보는 시간들을 가졌다. 정말 다양한 배경을 가지고 우테코를 들어오게 되었고, 비슷한 고민과 상황을 마주하고 있다는 것이 인상깊었다. 또 어떤

스트림을 다루다보면 리스트로 반환하기 위해 collect(Collectors.toList())를 많이 쓴다. 이펙티브 자바에도 아이템 47. 반환 타입으로는 스트림보다 컬렉션이 낫다가 있다. 모던자바인액션 6장을 읽다보면 초반부에 collect, collector, c

테스트를 돌리는데 이슈들이 있었다. 1\. GameDao에서 테스트를 돌리는데 어떨 때는 성공을하고 어떨 때는 실패를 하는 문제가 있었다. BoardDao에서 테스트를 돌리는데 체스 말을 움직이므로 매 테스트를 돌린 후 DB에서 되돌리는 작업을 해줘야 한다. conne

날이 어느새 따뜻함을 넘어서고 있다. 이번 주는 레벨 1의 마지막 주였다. 진행하던 스터디들도 아예 끝나거나 시즌이 끝나는 식으로 마무리 되었다. 정신없이 시간을 보내고 있었는데 잠시 쉼표를 찍으며 그동안 걸어왔던 길을 잠시 되돌아보는 시간을 가질 수 있을 것 같다.

이펙티브자바 아이템 18. 상속보다는 컴포지션을 사용하라에서 유명한 예시가 나온다. HashSetAbstractSetAbstractCollection위 코드를 실행하면 languages에서 getAddCount를 했을 때 일반적으로는 3이 나올 것을 기대한다. 하지만

결국 나도 걸렸다. 수요일 밤에 평소보다 조금 더 피곤하다고 느껴서 일찍 잤다. 다음 날 아침 일어나는데 두통이 약간 있었다. 그날 데일리 조원들을 만나는 날이었지만 혹시나해서 못 갈 것 같다고 말을하고 검사를 했는데 양성이었다. 백신을 3차까지 맞고 걸린건 조금 억울

우테코를 진행하면서 와! 소리가 나올만큼 좋은 것들이 있다. 오늘 진행한 레벨로그도 그 중 하나다. 크루 6명과 코치 한 분이 한 조를 이뤘고 한 명의 인터뷰이에게 3명의 인터뷰어 그리고 2명의 옵저버가 레벨1동안 학습한 내용에 대해 질문하는 모의 면접 시간을 가졌다.

우테코 첫 방학이 끝났다. 코로나에 걸려서 생각했던 것보다 놀지는 못했지만 잠도 많이 자고 맛있는 것도 많이 먹었다. 개학하고도 격리 기간이 겹쳐 이번주는 온라인으로 진행했다. 새로운 조에 예전에 페어했던 크루, 보이는 라디오 같은 조, 스터디 같이 했던 크루등이 있어

어떤 객체가 예정된 작업을 정상적으로 수행하기 위해 다른 객체를 필요로 하는 경우 두 객체 사이에 의존성이 존재한다. -오브젝트-위 ChessGameController에서 생략된 코드에서 ChessGameService 객체를 사용하고 있다. ChessGameContro

스프링 프레임워크를 사용하며 의존 관계 주입 방법이 여러가지가 있는 것을 알았다. 왜 스프링은 이렇게 여러 가지 방법들을 만들어놨고, 각각 어떠한 차이가 있는지 궁금했다. setter 수정자 메서드를 이용해서 의존관계를 주입 또는 변경하는 방법이다. 하지만 일반 자바

스프링 프레임워크를 사용하는 이유가 객체의 생성과 조립을 편하게 해준다는 것을 알았다. 또 강의를 통해 스프링에서 컨테이너에 빈들이 관리된다는 것도 알았다. 하지만 빈이 뭐냐고 스스로 명확하게 답할 수 없어 조금 더 공부를 해보기로 했다. 스프링 공식 문서(https&

전반적으로 쫓기는듯한 느낌이 드는 한 주였다. 이전에는 뭔가가 궁금하면 찾아보고 블로그를 정리해가며 소화하는 시간이 충분했는데 이번에는 그저 미션을 따라가기 급급했다. 생활 패턴은 해오던대로 거의 비슷했으니 스프링으로 넘어오면서 학습해야할 학습 내용이 확 늘어나서 그랬

RestAssured는 REST 기반의 서비스에서 테스트를 도와주는 자바 라이브러리다. 간단하게 gradle/Maven으로 추가할 수 있으며 버전은 링크 참고. Rest Assured 는 HTTP와 JSON을 기반으로 테스트하므로 언어에 독립적이다. 따라서 테스트하고자

코로나 이슈가 생겨서 페어를 시작하는 첫 날에 일주일 간 온라인으로 전환되었다. 사실 오프라인으로 전환되면서 이런 일이 없을 수는 없다고 생각했어서 갑작스럽지는 않았다. 오랜만에 다시 재택으로 하고 중간에 어린이날로 휴일까지 있어서 휴식한다는 느낌도 났다.어린이날에 예

미션을 하면서 주어진 기본 뼈대 코드에는 간단한 데이터베이스 설정 같은 것들이 되어있었다. 그래서 별 생각 없이 사용하다가 나중에 내가 바꿔야 하는 상황이 되니 어떻게 설정이 되어있는지, 어떻게 바꿔야하는지 몰라서 학습의 필요성을 느꼈다. 스프링 부트에서는 다양한 외부

체스 미션을 하면서 처음에는 단순히 FakeDao 인터페이스를 구현해서 실제 Dao를 사용하지 않고 테스트를 했다. 하지만 테이블이 복잡해지면서 FakeDao를 만드는 것도 부담이 되었다. 또한 Dao를 테스트 할 때 실제 DB를 이용해서 테스트하는 것도 부적절하다고

이번 미션을 하면서 한 실수 중 가장 큰 것은 도메인 로직에 집중하지 않았던 것이다. 1, 2 단계에서 도메인 로직이 크게 존재하지 않아서 스프링쪽 코드에 집중을 했다. 그러다가 3단계를 시작하다보니 이번에도 API 문서를 가장 먼저 켜고 컨트롤러 부분을 먼저 만들기

이번주에는 정말 많은 일들이 있어서 재밌었다. 레벨2 들어와서 네오와 첫 면담도 있었고, 레벨2조 회식도 있었다. 미션 일정에 쫓기다가 미션 일정이 다행이 늦춰져서 한숨을 돌리기도 했다. 또 잠실에 사는 백엔드 크루들과 프론트엔드 만나서 교류하는 시간도 가졌다. 레벨

이번 미션을 하면서 페어의 코드를 이어서 작업을 했다. 그러면서 또 많이 배웠다. 이때까지 사실 테스트 코드를 깔끔하게 유지하려는 노력을 많이 하지 않았다. 그래서 프로덕션 코드를 유지보수하는 것보다 테스트 코드를 유지보수하는게 더 노력이 많이 들어서 테스트를 작성하기

이번 주는 지하철 경로 조회 페어 프로그래밍이 있었다. 처음으로 데일리 조에서 페어를 했다. 평소에도 종종 개발 이야기를 나눴는데 실제로 같이 개발을 하며 의견들을 나누니 훨씬 재밌었다. 또 서로 생활 패턴을 아니 시간 조율을 하는데도 어렵지 않아 좋았다. Spring

사실 지난 미션까지만해도 @Controller, @Service, @Repository를 제외하고는 직접 빈으로 뭔가를 등록해준 적이 없었다. 하지만 이번 미션을 하면서 내가 만든 클래스를 빈으로 등록해서 사용하면 좋을 것 같은 일이 생겼다. FarePolicyImpl

학습 배경 미션이 콘솔 프로그램에서 웹을 이용하는 것으로 바뀌면서 조금씩 통제하지 못하는 것들이 생겨났다. 특히 스프링 프레임워크, DB가 대표적인 것들이었다. 그리고 이런 것들을 완벽히 통제하지 못하면서 테스트 코드가 돌아가는 순서에 따라서 실패하는 일들이 생겼다.

지하철 경로 조회 미션 페어 하며 배운 것2단계를 진행하며 Line 객체에 extraFare라는 필드를 추가하게 되었다. 기존 생성자를 그대로 두고, extraFare만 받는 생성자를 따로 만들고 extraFare를 생성자에서 받지 않으면 기본적으로 0으로 설정하게 해

지하철 미션이 드디어 끝나고 레벨2 마지막 미션이 시작됐다. 마지막 미션은 프론트와 협업도 있었다. 여러 명의 일정을 맞추다보니 본격적인 미션은 월요일부터 이야기해서 시작하기로 했다. 이번 미션의 페어는 더즈가 되었다. 더즈와는 레벨로그 말하기 때 만났었고 한번 페어를

이번 미션에서는 더즈와 페어와 하면서 테스트 코드 방식에 대해 많이 배우고 생각해봤다. 기존에는 항상 도메인부터 테스트 코드를 작성하는 것으로 시작했는데, 이번에는 더즈의 제안대로 하향식으로 테스트 코드를 작성해보았다. 처음에는 테스트 코드가 전부 대역에 의존하고 있어

케이의 블로그를 참고해서 개발환경과 배포 환경을 분리해봤다. 하지만 이렇게 분리하고 나니 테스트가 거의 다 깨졌다. 처음에는 테스트 쪽에 application.yml을 생성하면 된다고 생각했는데 그렇지 않았다. 그래서 테스트코드 설정들을 보다가 @ActiveProfil

레벨 2가 끝나고 방학식을 했다. 이번 주는 식중독에 걸려서 고생을 좀 했다. 같은 식당에서 같이 먹었던 루키, 어썸오도 똑같은 증상이 있어서 셋이서 나란히 죽 먹는게 아픈 와중에서도 웃겼다. 날이 더워져서 이제 음식 조심해서 먹어야겠다.레벨2는 레벨1에 비해 훨씬 빨

벌써 방학이 일주일 지나갔다. 평소에도 잠을 부족하게 잔건 아니지만 잠도 조금 더 자고, 운동도 여유롭게 하면서 방학을 보내고 있다. 또 레벨1 브라운조에서 청평으로 MT도 갔다왔다. 평소에 미루던 약속을 방학 때 다 만나려니 오히려 더 정신이 없는 것 같기도하다. 단

시작하기 전에는 길다고 생각했던 방학이 벌써 끝났다. 이번 주에는 약속들이 많아서 한 주가 더 빨리 지나갔다. 레벨2 네오조에서 에어비엔비를 잡아서 같이 맛있는 것도 먹고 밤에 이야기도 정말 많이 했다. 승팡이 가락시장에서 회를 떠와서 직접 가져왔는데 진짜 맛있게 잘

레벨 3 첫 주가 끝났다. 레벨로그, 이틀에 걸친 UX 특강까지 하고나니 정신없이 지나갔다. 처음 팀원이 발표되었을 때 명단을 보고 좋다고 생각했는데, 처음 한 주를 보내고 나니 더 좋다는 생각이 들었다. 그리고 한주 한주가 지날 때마다 더 그렇지 않을까 기대된다. 장

학습 배경 레벨로그 말하기 때 빈으로 등록하는 방법들에 대해 질문 받은 뒤, @Controller, @Service, @Repository를 @Component로 대체하면 어떻게 되냐는 질문을 받았다. 레이어드 아키텍처에서 각각의 계층이 하는 역할이 분리되어 있기 때

첫 번째 스프린트가 끝이났다. 스프린트를 시작할 때 계획했던 기능들에 대해 다 구현을 했다. 처음에는 첫 스프린트의 기능을 너무 적게 잡은게 아닌가 생각이 들었었다. 하지만 몹 프로그래밍을 하다보니 처음 컨벤션을 정할 때 각자의 생각을 나눌 시간이 많이 필요했다. 약간

여러 개의 엔티티가 있는데 공통적으로 객체가 생성된 시간을 저장할 필요가 있다. 현재 두 가지 문제가 있는 것이다. 각 엔티티마다 LocalDateTime createdAt을 붙여야 한다. 각 엔티티가 생성될 때 LocalDateTime createdAt = Local

사용법 구글 이메일을 이용해서 메일을 보내자. 5월 30일부터 기존의 보안 단계로는 연결이 되지 않는다. [2022 년 5월 30일부터 적용된 구글 보안 정책](https://support.google.com/mail/thread/166604101/smtp-%EC%8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

이제 마지막 스프린트가 시작됐다. 여섯 번째 스프린트는 요구 사항이 바로 나오지 않아 요구 사항을 기다리면서 리팩토링 위주로 프로젝트가 진행됐다. 또 코어타임을 2시 ~ 6시로 잡아서 그 외 시간에는 개인적으로 하고 싶은 공부를 하거나, 프로젝트에서 해보고 싶었던 부분

팀에서 무중단 배포를 하기로 했다. 하나의 인스턴스에서 포트번호만 바꾸면서 할 수도 있고, 두 개 이상의 다른 인스턴스를 돌리는 상황에서 무중단 배포를 할 수도 있다. 현재 EC2 성능이 그렇게 좋지도 않고, 더 많은 부하에 대비하기 위해 두 개의 인스턴스를 운영하기로

마지막 스프린트의 역할과 팀을 나눴다. 마지막 스프린트에서 크리스, 이스트와 페어로 무중단 배포를 맡기로 했다. 중간중간 리팩토링과 버그도 잡아가며 셋이서 재밌게 하고있다. 이번주는 연휴 때문에 화요일부터 시작했고, 형 결혼식을 포함해서 일들이 있어서 일주일이 후딱 지

이번주는 개인적으로는 테코톡 준비를 하고 팀에서는 무중단 배포를 했다. 레벨2 네오와의 면담 때 DB 관련 스터디를 열고 학습을해서 테코톡 때 DB 관련 주제로 발표를 하기로 했는데 말했던대로 다 해서 뿌듯했다. 사실 이번 테코톡 준비를 하면서 이런 저런 일들이 예상치

마지막 데모데이를 위한 한 주였다. 레벨 4 초반에는 나를 포함해서 뭔가 팀이 프로젝트에 집중하지 못한다는 느낌을 받았다. 그래서 레벨 3 때 그 재밌는 느낌이 나지 않았다. 레벨 4 중반부터 새로운 기능들이 생기고 다시 사용자가 늘면서 점점 몰입을 할 수 있었다. 데

예상보다 조금 빠르게 우테코를 떠나게 됐다. 우테코 과정을 되돌아보고 잘했던 것과 못했던 것들을 짚어보면 새로운 시작에도 도움이 될 것 같다. 딱 작년 이맘때 쯤 우테코에 지원을 했고 우테코에 합격하고 나서도 갈지 말지 되게 고민을 많이 했다. 취업을 목적으로 하던 공