Keep 이번주는 근로를 되게 열심히해서 그런지 뭔가 배운게 많은 것 같다. 저번에 글을 썼던 docker로 공통환경을 배포하는 과정에서도 flyway-migrate문제나 db가 뜨기 전에 app이 먼저 떠버려서 계속 빌드가 실패하는 문제를 해결한다던가 조금 더 코드적인 부분으로는 OSIV관련한 코드들에 대해서 토론한 부분도 있었다. 개인적으로 OSIV를 몇 명이 모여서 같이 파보는 과정은 정말 만족스러웠다. 시간을 많이 쓰긴 했어도 다른 크루가 따로 정리해서 오려주기도 했고, 나 뿐만 아니라 다른 크루들도 다 만족했다. 이런 과정이 팀이고 협업이 아닐까? 꽤 만족스러운 한 주의 근로였기 때문에 앞으로는 더 열심히 하려고 한다. (원래도 열심히 했었다.) 그리고 운동할 때는 보통 노래를 들으며 운동하지 ..
서론 개발을 하다가 문득 궁금한게 생겼다. CustomException이 발생하면 내가 설정한대로 예외가 터져줬지만, 그렇지 않은 예외들이 발생하면 모두 INTERNAL-SERVER-ERROR를 띄워줬다. 이게 맞는걸까? 우리는 보통 애플리케이션에 커스텀 예외(Custom Exception)을 선언하고 각각의 도메인에 맞게 사용한다. 예를 들면 ApplicationException이 RuntimeException을 상속받고 해당 Exception이 터지면 커스텀 해놓은 상태코드를 반환하고 그렇지 않는다면 그에 맞는 상태코드를 반환해야 할 것이다. 예를 들면 JPA를 사용해서 개발하다가 DataIntegrityViolationException 이런 예외를 한 번쯤 만나본적 있을 것이다. 이 예외는 일반적으..
요즘 어떠한 서비스를 만드려고 하면 대부분 팀 단위로 진행할텐데요. 팀 단위로 프로젝트 진행 시 백엔드 배포 환경 구축이 안되었을 때 프론트엔드 개발자들이 API를 어떻게 테스트 해볼 수 있을까요? 프론트엔드를 담당하시는 분들은 대개 VSC를 사용하고 IntelliJ가 노트북에 설치되어 있지 않을 확률도 높습니다. 물론 VSC에서도 스프링부트가 잘 동작할테지만, IntelliJ가 익숙하니까요. 그럼 프론트엔드 개발자들이 맨날 IntelliJ에 들어가서 DB 설정을 하고, 서버를 키고 API를 테스트 해봐야하는 걸까요? 그렇지 않습니다. 요즘엔 도커에서 좋은 기능도 많이 제공해주더라구요. 이번 포스팅에서는 "공통 환경 설정"이라는 주제를 가지고 포스팅하려고 합니다. 현업에서는 어떻게 할지 모르지만 우선 제..
Keep 학교에서 만들고 운영하다가 온 서비스(교내 서비스)를 방치했었다. 이번년도에는 신입생들도 들어오고 그에 의해 사용자 수도 많아졌다. 그래서인지 예상하지 못한 문제들이 많이 생겨서 트러블 슈팅하는데 많은 시간을 쏟았다. 그런데 문득 이런 생각이 들었다. "나는 이제 그 학교 학생도 아닌데 왜 내가 유지 보수 해야하지?" 이에 대해 깊이 있는 고민을 해봤다. 현재 의 나에게만 적용되는게 아니라 성공할 사람이 가져야 하는 일종의 "마인드 셋"인 것 같기 때문이었다. 이 물음표의 결과는 아래 몇가지로 추려볼 수 있을 것 같다. 내가 만든 서비스여서 실제 사용자가 몇 명도 아니고 100명 가까이 되는 수여서 포트폴리오에 멈춰있는 서비스가 아니라 실제 운영되는 서비스를 쓰고 싶어서 지속적인 트러블 슈팅으로..
스프링 프레임워크에서는 객체간의 낮은 결합도를 제공하기 위해 DI(Dependency Injection)을 제공한다. 이 기능은 외부에서 생성된 객체를 인터페이스를 통해서 넘겨받기도 하고, 런타임에 의존관계가 결정되기 때문에 유연한 구조를 가진다. 의존성 주입의 종류 Field Injection 변수에 @Autowired 어노테이션을 붙이게 되면 스프링 프레임워크에서 해당 객체를 자동으로 스프링 빈으로 등록한다. @Service @AllArgsConstructor @Transactional(readOnly = true) public class MissionService { @Autowired private SessionService sessionService; } 하지만 인텔리제이에서는 필드에 @Aut..
Keep 이번 주 처음으로 일일 Todo를 써봤다. Todo를 쓰게 된 이유는 할 건 많은데, 막상 뭘 해야 할지 고민하는데 너무 많은 시간을 쏟는 것 같아 그날 할 일을 Todo 형식으로 정리하면 고민할 시간을 줄일 수 있을 것 같았다. 실제로도 Todo를 작성하면서 버리는 시간 없이 캠퍼스에 있는 시간동안 공부의 밀도를 높게 가져갈 수 있었다. 그래서 매일 Todo를 작성하도록 노력해야겠다. Problem 축구 보는 시간을 좀 줄여야 겠다. 오늘 글 쓰는데 10분 20분 걸릴 거 축구 보면서 쓰니까 2시간 30분 걸렸다. 그리고 항상 11시에 캠퍼스에서 퇴실하기 때문에 집에오면 진짜 바로 자야 하는 시간이다. 이젠 헬스장에 샤워실이 고쳐졌기 때문에 아침에 운동 갔다가 밤에는 바로 자야지. 인스타도 적..
다들 스프링 프레임워크를 잘 사용하고 있는 와중 동작 원리에 대해 고민해본적이 있는가? 우리가 흔히 사용하고 많은 도움을 주는 프레임워크의 동작 원리 정도는 알아두자. Spring Framework란? 자바 플랫폼을 위한 오픈소스 어플리케이션 프레임워크로서 엔터프라이즈급 어플리케이션을 개발하기 위한 모든 기능을 종합적으로 제공하는 경량화된 솔루션이다. 엔터프라이즈급 개발이란 뜻대로만 풀이하면 기업을 대상으로 하는 개발이라는 뜻이다. 일반적인 프레임워크의 경우 과도한 엔지니어링 기술을 탑재하여 무겁고 고가의 WAS를 갖추어야만 동작했지만 스프링 프레임워크는 엔터프라이즈 개발에서 필요로 하는 기술을 포함하고 있지만 가볍고 단순히 환경에서 사용할 수 있다. Spring Framework 특징 아래에는 Spri..
이번주부터 주간 회고록을 작성하려고 한다. 주간 회고록을 써야겠다고 느낀 이유가 뭘까? 우선 일주일 동안 내가 뭘 했는지를 검증하는 시간이며, 아쉽거나 부족한 부분에 대해서 메타인지를 하기 위해서다. 메타인지를 해야만 다음주의 내가 일주일을 더 잘 보낼 것 같다. 주간 회고록을 꾸준히 쓰는 게 쉽지는 않겠지만, 회고를 쓰는 이유와 필요성이 계속 느껴지기에 더 이상 미루지 않고 작성한다. 무엇을 시작해야 하는가? 내가 무엇을 시작해야 할까? 지금 나는 우아한테크코스(이하 우테코)의 크루다. 하루종일 코드를 보며 다른 사람들과 이야기, 페어 프로그래밍 또는 전공 책을 읽는다. 이렇게 평일과 일요일을 보내고 토요일은 무조건 하루를 쉰다. 쉰다는 건 사람마다 다르다. 내가 좋아하는 것을 하는 게 쉬는 것일 수도..
이번 글에서는 Mockito에 관련해서 글을 써보려 합니다. Spring이 적용된 Mockito가 아닌 JUnit으로만 사용할 수 있는 수준의 문법을 정리합니다. Mockito Test Framwork가 처음 사용하는 분들에게 불친절하다고 생각합니다. 저도 그래서 다른 크루들과 함께 공부했고 이에 대한 코드는 다음 레파지토리에 정리해두었습니다. https://github.com/wonyongChoi05/mockito-study GitHub - wonyongChoi05/mockito-study: 우아한테크코스 프롤로그 Mockito + JUnit을 이용한 테스트 작성 방식 우아한테크코스 프롤로그 Mockito + JUnit을 이용한 테스트 작성 방식 문서화. Contribute to wonyongChoi0..
우테코 1레벨 마지막 미션인 체스를 진행하면서 배운 DTO에 대해서 글을 써보려 합니다. 리뷰어와 약 하루동안 16,000자의 대화가 오갔으며, 이번 글에서는 이를 기반으로 토론한 내용을 기반으로 작성합니다. 그리고 체스라는 게임의 룰을 이해한 상태로 글을 읽으면 이해가 더 잘될 것 같습니다. 😁 😁 사건의 발단 체스라는 게임은 각 기물마다 다른 움직임 전략을 가지고 있습니다. 이를 객체지향으로 구현하는 방법은 여러가지가 있을 것입니다. 가장 대표적인 방법은 상속을 사용하는 방법일텐데요. 이는 하나의 Piece 부모 객체를 가지고 나머지 기물들이 Piece를 상속(Inheritance)받아 자신의 전략에 알맞은 전략을 따로 구현하는 방법입니다. 그리고 다른 방법으로는 전략 패턴(Strategy Patte..