Sean :: Dev

Spring Data JPA에서 Id의 @GeneratedValue 이슈 @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; 위의 코드로 익숙한 Entity에서 Id 부분, 우리는 GenerationType.AUTO가 DB 벤더에 알맞은 전략을 선택해주기 때문에 DB 종속성이 약해져 GenerationType.Identity(MySQL의 auto increment 역할)보다 적절하다고 알고있었다. 그러다 리팩토링을 진행하며, GenerationType.Identity 일땐 잘 작동하던게 GenerationType.AUTO로 바꾸니 에러가 나기 시작했다. 검색해보니 오늘도 jojoldu님에게 도움을 받을수있었다. https://jojo..

상황 19.12.10 우테코 레벨4 eat-together 프로젝트의 Article/Shop/Menu 관련 구현 중 발생한 이슈 Shop은 @OneToMany로 List를 갖고있다. Menu도 양방향으로 @ManyToOne Shop을 갖고있다. 가게 조회 기능을 구현하는 과정에서, 테스트에서 Shop을 리턴하니 List때문에 터졌다. 발생한 LazyInitializationException 예외를 검색해보니 관련 논의가 많았다. 참고자료 킹뽀대님 글 , 나중에 정독해보고 OSIV에 대해 고민해보자 feco.tistory.com - 3가지 해결방안 제시 bebong.tistory.com 문제 해결 application.properties에 #spring.jpa.open-in-view=false로 설정되있었..

12.10) 오늘 하루동안 eat-together 게시글 관련 기능 구현하며 경험한 것들 with 티버 ATDD 프로세스에 대해 문제 인식 ATDD를 하고싶어서 가장 큰 도메인 모델인 Article을 잡고 시작. 인수테스트를 통과시키기 위해 제일 먼저 테스트를 짜고 깡통 Controller를 만들었다. 여기까진 괜찮은데, Shop, Order, Menu, Item 등 관련된 도메인 모델들을 갑자기 한번에 만드려니 꼬이기 시작했다. 여기저기에서 문제가 많이 발생했는데, 특히 관계매핑 관련해선 더욱 힘들었다. 게다가 각 모델들을 객체지향적으로 만들고있다는 느낌은 안들었고, Article에 필요한대로 급하게 끼워넣으려 만드는 느낌이 들었다. 방향을 바꿔보기로 했다. Article을 잡았으면 깡통을 만들고 이제..

개발자라면 일반인에게 네이버만큼이나 평소 Github에 자주 들어간다. 모른다고 큰 문제가 되진 않지만, 몇 가지 팁을 알면 Github을 훨-씬! 편하게 이용할 수 있다. (개인적으로 옥토트리를 처음 알게됬을땐, 그동안의 내 자신에게 무척 미안해졌다 :p) Octotree Chrome 확장 프로그램 설치 Github 필수 확장 유틸, IDE처럼 트리 형태로 프로젝트 구조를 보여준다. 설치하면 생산성이 달라지는 것을 느낄 수 있다. Isometric Contributions Chrome 확장 프로그램 설치 Github 잔디밭을 입체 형태로 이쁘게 보여준다. 뒷부분이 조금 가려지긴 하는데 원래 형태로 나오도록 선택할 수 도 있다. 무엇보다, 이쁘니까..!! Git History https://github...

나의 첫 개발자 이력서 작성 배경 때는 19년 가을, 평생을 학생으로 살아오던 나도 드디어 '구직활동'이란 것을 슬슬 시작하게 되었다. Word를 이용해 표로 이뤄진 전통적인 이력서 템플릿보단, 예전에 보았던 개발자스러운 이력서를 만들기로 마음먹었다. 전부터 북마크 해온 링크들을 다시 뒤지고, 다른 개발자 분들의 이력서를 참고하며 나도 나만의 이력서를 완성해냈다. 참고로 대부분의 링크들은 주니어들의 성지인 junior-recruit-scheduler에 포함되어 있다. 이 글은 노션을 활용한 내 개발자 이력서 템플릿 예시와 첫 이력서 작성 후기 정도의 내용을 포함한다. '좋은 이력서란 무엇인가와 어떤 내용을 포함해야하는지'에 대한 내용은 글이 길어질것같아 일부러 생략했다. 이런 내용을 원한다면, 아래에 언..

예전에 미션 피드백을 받고 인지해 정리했던 내용을 포스팅 Collection.stream().forEach() vs Collection.forEach() 순서 Collection.forEach는 컬렉션의 iterator를 사용한다. 따라서 순서가 명확하다. 반면 Stream.forEach는 순서가 명확하지 않다. 순차스트림이라면 보통 순서대로 실행되지만 병렬스트림이라면 순서가 보장되지 않는다. Collection 수정과 Side Effect Collection.forEach는 iter동안 구조적으로 변경되어선 안된다. 순회하는 동안 요소가 추가/삭제되면 ConcurrentModification Execption이 발생한다. 동시에 컬렉션은 fail-fast하게 설계되었다. 즉 변경이 발생하면 바로 예외가..

Lv3 - 7~9주차 미션 : DI 구현 https://github.com/woowacourse/jwp-di 학습목표 DI 프레임워크 구현을 통해 DI 개념과 Spring 프레임워크 이해 AOP 개념 및 Spring AOP 적용 Transaction과 Spring Transaction 요구사항 step1 BeanFactory, BeanScanner 구현 이전의 MVC 미션 코드까진, 자바 Reflection을 활용해 @Controller를 찾아 인스턴스를 생성하고 URL 매핑을 자동화했다. 같은 방법으로 @Service, @Repository도 각 클래스에 대한 인스턴스 생성과 의존관계 설정을 어노테이션으로 자동화한다. 각 인스턴스간의 의존관계는 @Inject 어노테이션 사용 MVC모듈의 Controll..

Sync/Async, Blocking/Non-Blocking Multi Thread WAS vs Single Thread WAS 사전지식 : Process vs Thread 멀티 스레드로 잘 서비스하던 어느날, 갑자기 10k(1만명)를 동시에 서비스할 일이 생겼다. 일명 C10K Problem. 1만명 동접이 가능하려면 어떻게 해야할까? 자바의 대표 멀티 스레드 서버인 톰캣은 기본 max-thread가 200밖에 되지 않는다 ! 10k를 멀티 스레드로 구현할 경우, 가장 큰 문제는 Context-Switching 비용 -> Single Thread + Non-Blocking + Async 구조면 가능하지 않을까? 이들에 대해 알아보자. 애플리케이션 개발에서의 sync vs async 먼저, [애플리케이션..