- 이쓔스, 스타트업 털어주마: #텍톡 "아마존은 왜 손바닥으로 결제하는 아마존 원(Amazon One) 개발했을까"
- 데이터홀릭: Ep(79) 데이터뉴스_카카오도 네이버도 짓는 데이터센터 이야기
DDD 관련 새로 출간 된 책이라 가볍게 전체적으로 훑어봄. 에릭 에반스, 반버논의 DDD 보다는 훨씬 쉽게 쓰였고, 최범균님의 DDD 스타트는 코드를 중심으로 설명했다면 이 책은 코드는 적지만 이론을 정말 친절히 씀. 편견인지 모르지만 일본에서 출간되는 기술 서적은 정말 읽기 쉽고 친절함.
DDD 입문자가 반버논의 도메인주도설계핵심(얇은 버전)과 함께 보면 좋을 것 같음.
기존에는 메시징 기반 프로그래밍시 AWS에서 제공하는 SNS, SQS 를 통해 점대점, 팬아웃 등의 시나리오를 대응했음. 이제 RabbitMQ 를 사용하기 앞서 AMQP 프로토콜에 대해 살펴봄.
Advanced Message Queuing Protocol 의 약자. 클라이언트 응용 프로그램이 메시징 미들웨어 중개자가 통신할 수 있게 하는 (네트워크 기반의) 메시징 프로토콜. RabbitMQ 는 AMQP 0.9.1 버전에 맞춰 구현 됨.
필요에 의해 JpaSpecificationExecutor 인터페이스를 확장 구현하기 전에 Specifications 의 등장 배경에 대해 조금 리서치.
Spring Data JPA 는 데이터 접근 계층을 쉽게 구현할 수 있게 해줌. 미리 약속 된 규칙에 맞춰 인터페이스의 시그니처만 만들면 쿼리는 내부적으로 자동 생성 (Query Creation). 반면, 이 규칙으로 인해 쿼리 메서드는 계속해서 증가하고 좀 더 복잡한 쿼리를 만들어내기 위한 유연성은 떨어지는 단점이 있음.
이를 극복하기 위해 객체지향 쿼리 빌더라고도 하는 Criteria 를 사용할 수도. JPQL을 자바 코드를 작성함으로써 컴파일 타임에 오류를 잡을 수 있어 안전. 하지만 Criteria 로 작성된 쿼리는 가독성이 떨어지고 재사용이 어려움.
이에 이 글은 몇가지 대안을 제시해줌.
- Specifications: 에릭에반스의 DDD 에서 소개 된 개념을 바탕으로 Specification 인터페이스를 통해 재사용 가능한 Predicate 를 정의 가능하게 해줌. 복잡한 Predicate 를 and, or 등 다양하게 조합하여 Specification 에 담고, JpaSpecificationExecutor 에는 Specification 를 인자로 받는 기본적인 인터페이스가 정의되어 있음. 예컨대 findAll(Specification spec) 같은 것들.
- Querydsl: Querydsl 은 별개의 오픈소스 프로젝트로 Criteria 와 마찬가지로 별도의 메타 객체를 (Q클래스) 생성하여 사용하지만 Criteria 보다 더 다양한 API 를 제공하고 JPA, 하이버네이트, JDBC 등 다양하게 지원.
DIY Data Visualization in JavaScript while Stanning BTS - Chloe Noh - JSConf Korea
'정신적 충만' 을 위해 자신이 좋아하는 기술, 아티스트 즉, 덕업일치로 시작한 개인 프로젝트 이야기. 내가 좋아하는 것들만 할 수 있는 개인프로젝트 너무 재밌을 것 같다!
최범균님의 CQRS 간단한 요약! 목소리도 좋으시고 설명도 좋으심
커리어 중 꼭 한번 경험 해보고 싶은 역할 조직. 경험해보지 못한 것에 대한 동경이 있긴 하지만 한편으로는 책임의 무게가 두렵기도 함.
- 좋은 부분이 있을 때 구체적으로 적극적으로 칭찬한다
- 부족한 부분 역시 정확하게 피드백
라이브커머스를 홈쇼핑 정도로 생각했었고 티비도, 홈쇼핑도 관심 없기에 흥미 있는 분야는 아니었음. 하지만 네이버, 카카오, 쿠팡, 우아한형제들이 해당 산업에 뛰어 드는 것을 보고 블루 오션인가? 하던 차에 올라온 팟캐스트.
방송을 들어 보니 홈쇼핑 = 라이브커머스 라기 보다는 인터넷 방송에서 좀 더 특화 된 형태라고 볼 수 있는 듯. 중국의 라이브커머스 시장 규모는 163조원이라고. 국내 이커머스 시장 규모가 130조, 라이브 커머스는 3조.
기술적으로도 재밌는 도전 요소가 많을 듯. 유명 인플루언서가 매력적인 제품을 판매한다면 단시간에 많은 트래픽과 트랜잭션을 처리해야할테고 특히 주문 처리 절차의 경우 트랜잭션이 꽤나 복잡할텐데 재밌을 듯.
처음 TDD 를 접하고 가장 좋았던 건 빠른 피드백 루프이고 설계에 대해 도움이 된다고 생각했기 때문. 하지만 TDD 자체가 설계에 크게 도움이 되지는 않았음. 또한 연차가 어느 정도 쌓이다 보니 반복적인 부분에 대한 테스트 코드와 개발 중 요건이 변했을 때 줄줄이 깨져 버리는 테스트들이 비용이라고 느껴 지기 시작. 그래서 어느 순간부터 필요하다고 생각하는 부분만 테스트를 추가하거나 (테스트 라스트..) 빠른 피드백이 필요한 부분, 예컨대 복잡한 알고리즘을 짜야 할때만 국소적으로 적용하고 있음.
어찌됐건 TDD 가 주는 빠른 피드백과 실패-성공-개선의 빠른 사이클은 개발을 즐겁게 함. 영상을 보고 나니 다시 습관을 들여 볼까 싶기도. TDD 의 진정한 가치는 무엇일까? 책을 다시 꺼내봐야겠음.
나는 회사에서 심심한 상황이 제일 싫고, 너무 쉽거나 익숙한 일보다는 내가 성장할 수 있도록 어느 정도 도전적인 일들을 하는 것을 좋아함. 이는 어느 정도의 스트레스와 압박도 동반하지만 그게 나쁜건 아니라고 생각.
그렇지만 맨날 초과근무를 하거나 집으로 업무를 가져오고 싶지는 않음. 이제까지 이를 워라밸을 중요시한다고 표현했는데 그렇다고 퇴근 후 휴식을 취하거나 다른 취미 생활을 하지 않음. 주로 개인적인 공부 또는 업무와 관련 된 공부. 그래서 이게 적당한 표현인가? 항상 고민 했는데 이 글의 2번이 적절한 표현. "일에 지배당하지 않으려 한다" (내가 일을 잘한다는 뜻은 X). 이 외에도 조직 안에서 일을 하며 자신의 논리를 주장할 때, 이는 조직의 논리 위에 있어야 한다는 점 등이 인상 깊은 글.
미디엄에 특히 "XX 를 하기 위한 XX 가지 습관" 류의 글이 많은데, 왠지 이 글에서 말하는 내용은 와 닿음. 아.. 알고리즘 풀이 좀 해야 하는데...
몰랐던 책이 많음. 아마 번역되지 않아서 인 듯. 이 중 읽은 책은 오직 2권. 번역되면 좋겠다!!
모던 자바 인 액션이 워낙 괜찮아서 자바 8+ 에 대해 쓰인 책은 잘 안 찾아 봤는데 국내 저자 분이 쓰셨길래 한번 살펴봄. 부록으로 포함 된 제네릭에 대한 내용이 좋았음. 또한, 책을 보고 나서 간단한 학습 테스트는 앞으로 테스트 코드 보다는 JShell 을 활용해야 겠다는 생각도.
자바8에서는 워낙 큰 변화가 있다 보니 미만 버전에서 8 로 버전업은 많이 이야기 되었으나, 8 이후 버전에 대해서는 상대적으로 관심이 덜 한 듯 함. 나 역시 마찬가지. 나중에 ZGC 에 대해 좀 더 살펴봐야겠다.
GitGuardian 은 개인 사용자의 경우 무료. 추가 해 두면 실수를 감지하기 좋을 듯. (GitGuardian 은 믿을만 한건지..)
2분 10초부터 이야기 하는 역할의 크기와 테스트에 대한 이야기는 요즘 많이 하는 고민. 역할의 크기는 작을수록 테스트하기 쉬움. 반면, 단 한가지 역할만 가지도록 한다면 모듈 (또는 클래스) 은 엄청나게 많아질 것 임. 역할 역시 적절하게 추상화 하고 적절하게 묶어줘야 함. 하지만 이는 앞으로의 변화의 방향도 어느 정도 예상이 필요한데 요구사항은 언제 어떤 식으로 변할지 모름. 따라서 역할의 크기를 어느 정도 작게 부여 할 것 인가는 항상 고민 됨.
if kakao 2020 카카에페이 세션의 마지막에 포함 된 영상. 처음 본 지는 좀 됐으나 다시 봐도 감동.
기술은 놓게 만드는 것: 번거로움을, 수고로움을, 어려움을, 불편함을. 이전 회사 곳곳에 붙어 있던 말이기도 함. "만드는 사람이 수고로우면 쓰는 사람이 편하고 만드는 사람이 편하면 쓰는 사람이 수고롭다"