https://www.yes24.com/product/goods/126845564
감상 2025-05-24 69페이지에는 MyBatis와 같은 라이브러리를 사용해서 DB 쿼리 결과를 객체로 매핑하는 방식이 오랫동안 훌륭한 해결책으로 잘 동작하다가 개발자들이 그 방식을 지루하게 여겨서 Hibernate와 같은 ORM이 등장하게 되었다고 설명한다. 그런데 Hibernate는 MyBatis의 전신인 iBatis와 같은 해인 2001년에 시작되었다. Hibernate의 창시자 Gavin King은 EJB 2 Entity Bean이 실용적이지 않아서 Hibernate를 만들게 되었다고 하는데 EJB 2의 출시도 2001년이기도하다. EJB 1.0 Entity Bean은 1999년에 출시되었다.
내가 실무에서 Hibernate 처음 본 것이 2005년으로 기억하고 iBatis를 만나기 전이였다.
https://www.amazon.com/Professional-Java-Development-Spring-Framework/dp/0764574833/
감상 2025.01.27 Spring framework의 초창기와 구현 원리를 알려주는 책이다. 요즘 시대에는 실용서는 아니지만 역사서로서의 의미는 있다.
https://www.amazon.com/Expert-Development-without-Johnson-Paperback/dp/B011YTQ5C2
감상 책에서도 로드존슨은 마틴파울러 책의 분산 컴퓨팅의 제1법칙을 인용하면서, 대부분의 J2EE Application, 특히 Web application에서는 분산 아키텍쳐에서 얻는 이득이 없다고 이야기합니다. Logical layering이 Physical layering보다 중요하며, 깨끗한 관심사의 분리를 경량 프레임웍을 통해서도 이룰 수 있음을 이야기하고 있습니다. (309,317,318쪽)
EJB에서도 Local Session Bean이 증가한 사례를 이야기하고, Remote EJB는 필요해지는 시점에 도입할 수 있으므로 미래에 있을 가상의 요구사항(phantom requirement)을 가정하는 것은 위험하다고 이야기합니다. (335쪽)
인상 깊은 단락 p311 In general, we believe that unrecoverable exceptions should normally be unchecked.
https://www.amazon.com/Expert-One-One-Design-Development/dp/0764543857/
감상 로드 존슨은 이 책에서 분산 아키텍쳐가 성능과 개발,debug, deploy, 유지보수가 어렵고 객체지향 디자인을 적용하는 것에 제약이 됨을 이야기하고 있습니다. 그리고 그의 경험으로는 분산 Application의 deployment flexibility 잇점은 과장되었다고 말합니다. 또, Business적 요구가 없는데도 분산 아키텍처가 된다면 프로젝트의 life-cycle 동안 자원의 낭비가 되고 버그의 온상지가 될 것이라고 주장했습니다. (18,19,33쪽)
인상 깊은 단락 p78 Chapter 3 Testing J2EE Applications
In particular, it’s important to view the writing of a failing test as an achievement, not a problem.
인상 깊은 단락 Kindle판 기존
Location 502 Batch processing, for this book’s purposes, is defined as the processing of a finite amount of data without interaction or interruption.
Location 506 A ComputerWorld survey1 in 2012 stated that over 53% of those enterprises surveyed used COBOL for new business development.
Location 1,186 The worst part about maintaining batch processes is that when they break, it’s typically at 2:00 a.
인상 깊은 단락 2ed
p76 scale cube
참고 http://theartofscalability.com/ https://microservices.io/articles/scalecube.html 요약 x축 : 애플리케이션을 복제해서 수평적으로 확장 y축 : 서로 다른 기능들을 분리 Z축 : 데이터 파티셔닝 또는 샤딩 p188 https://github.com/Nilhcem/FakeSMTP 를 이용한 테스트 환경 구성
https://github.com/benelog/devnote/blob/master/smtp.adoc 에 관련 도구들을 정리했다.
p218 공유 데이터 모델, 공유 스키마, 공유 테이블은 좋지 못한 방법이며, 마이크로서비스 개발을 재앙으로 이끌 수도 있다. 처음에는 좋은 수도 있지만, 복잡한 마이크로서비스를 개발하다 보면 데이터 모델 사이에 계속 관계를 추가하고, 조인 쿼리를 만들어내게 된다.
스프링을 이용한 RESTful 웹 서비스: 구축하기 실전 예제로 배우는 REST 방식의 스프링 웹 서비스
인상 깊은 단락 p194 http://goessner.net/articles/JsonPath/ https://github.com/FasterXML/jackson-module-jaxb-annotations/wiki
인상적인 단락 p5 단위테스트를 ‘다른 단위에 종속되지 않는 하나의 단위에 대한 테스트’
p71 개발자 입장에서 무언가를 잘못 수정할 때마다 바로바로 알려주는 누군가가 곁에 있어주는 것만큼 마음 든든한 일도 없다. 단위 테스트는 잘못된 부분을 찾기 위해 어플리케이션을 디버깅할 필요성을 줄여준다. 기능 테스트가 버그가 존재하는 유즈케이스를 골라주는 수준이라면, 단위 테스트는 어떤 메서드가 어떤 이유로 실패했는지도 이야기해준다. 즉 문제를 찾아 몇시간씩 헤매던 일에서 해방된다.
p99 숨겨진 종속성과 전역상태를 피하라 싱글톤은 애플리케이션에 전역 상태를 만들어낸다는 명백한 취약점이 존재한다.
감상 Java의 기초를 테스트코드로 설명한 Agile Java를 보고, 프레임웍도 그렇게 설명했으면 좋겠다고 생각했었는데,Toby님의 책이 그러한듯하다. testability, 좋은 설계 같은 핵심은 시간이 지나도 빛이 바래지 않을 것이고, 최신버전은 오히려 부차적 것일지도
감상2 (2012/11/25 추가) 아래는 일민형의 부탁으로 토비의 스프링 3.1에 들어간 추천사
토비님의 블로그를 통해 이 책의 집필 소식을 알게 되었고, 출판을 오랫동안 기다렸었다. 마지막까지 인쇄 사고로 배송이 지연되는애 태우는 일정 끝에 책을 받아들고는 비싼 전자기기를 산 기분보다 더 뿌듯했었다. 책을 받은 다음날부터 무거운 책을 출퇴근길에 들고 다니면서 완독을 했었다.