오타인거죠?

쌤수님 감사합니다 🙂다음 패치에 반영할게요^^!

타임리프 3.X 버전 rendering, serializer 에러 해결 방법

안녕하세요. 이재현님공유해주셔서 감사합니다 🙂그런데 제가 최신 버전을 코드로 확인해보니 문제가 없더라구요. (3.1.3 버전)올려주신 메뉴얼의 경우에 특정 패키지에 대한 부분이어서 이 내용과는 관련성이 없어보이더라구요.혹시 문제가 발생했던 전체 코드를 압축해서 올려주시면 제가 면밀히 살펴보겠습니다 🙂 실제 동작하는 전체 프로젝트를ZIP파일로 압축해서 구글 드라이브로 공유해서 링크를 남겨주세요.구글 드라이브 업로드 방법은 다음을 참고해주세요.https://bit.ly/3fX6ygx감사합니다.

서비스 운영 중 잘못된 테이블 설계 발견시 수정 시점에 대한 질문

안녕하세요. yahohoho님앞으로의 유지보수와 개발 관점에서보면 정리를 하고 가면 좋겠지만, 실무에서는 다양한 고민이 함께 필요합니다. 현실적인 조언을 몇 가지 드리겠습니다.1. 비즈니스는 멈추면 안 됩니다.기획팀과 회사는 '깔끔한 코드'보다 '비즈니스의 성장'을 원합니다. 엔지니어의 욕심으로 몇 주간 신규 기능을 멈추고 리팩토링만 한다면, 비즈니스 타이밍을 놓칠 수 있습니다. "기술 부채 청산"은 서비스를 계속 운영하면서 이자 갚듯이 조금씩 해나가는 것이지, 파산 신청하듯이 모든 걸 멈추고 하는 게 아닙니다. 2. 식별 관계, 불편하지만 당장 서비스가 망하진 않습니다.과거의 레거시인 식별 관계(Identifying Relationship)가 개발 유연성을 떨어뜨리고 코드를 지저분하게 만드는 것은 사실입니다. 하지만 이것이 당장 서비스의 치명적인 버그를 유발하거나 데이터 정합성을 깨뜨리는 것은 아닙니다. '불편함'과 '위험함'을 구분해야 합니다. 지금은 '불편함'을 안고 가는 것이 맞습니다. 3. 동료가 오면 그때가 기회입니다.데이터 마이그레이션은 정말 무섭고 떨리는 작업입니다. 혼자서 판단하고 실행하다가 실수하면 돌이킬 수 없습니다. 곧 합류할 동료분이 오시면, 가장 먼저 해야 할 일은 리팩토링이 아니라 '업무 파악'과 '적응'입니다. 신규 기능을 함께 개발하면서 호흡을 맞추고, 그분이 시스템에 익숙해졌을 때 함께 전략을 짜서 가장 아픈 부분부터 하나씩 비식별 관계로 풀어내시길 바랍니다. 물론 시스템이 매우 작아서 금방 리펙토링이 가능한 수준이라면 정리하고 가면 되고, 그렇지 않고, 비즈니스를 일시 중단해야 할 정도로 오랜 작업이라면 말씀드린 방향이 맞다 생각합니다. 감사합니다.

findValue의 파라메터까지 래퍼클래스 배열인 이유가 있을까요?

안녕하세요. 학생30492님 🙂생각하신 것 처럼 파라미터를 기본형 배열로 사용해도 같은 결과를 볼 수 있습니다.이것은 어떤 특별한 이유가 있는 것은 아니고, 이해를 쉽게 돕기 위해 전체적으로 래퍼형을 사용했습니다.감사합니다.

new T()가 안 되는 니유

안녕하세요. alstjs님만약 자바가 new T()를 허용하고, 내부적으로 new Object()로 바꾼 뒤 자동 캐스팅을 한다고 가정해 보겠습니다. 코드 작성(예시)class EraserBox { public T create() { // 제네릭 소거(Erasure)로 인해 T는 런타임에 Object로 취급됨 // 만약 자바가 이걸 허용해서 아래처럼 컴파일 된다면: return (T) new Object(); } } 사용하는 곳EraserBox dogBox = new EraserBox(); // 질문자님의 제안: 컴파일러가 앞에 (Dog)를 붙여준다. Dog myDog = (Dog) dogBox.create(); 자바의 대원칙: 자식 클래스(Dog)는 부모 클래스(Object)를 담을 수 없습니다. "모든 개는 사물이지만, 모든 사물이 개는 아니기 때문"입니다. 감사합니다.

스프링 빈에 등록이 안되는거 같은데 어떻게 하면 좋을까요?ㅠㅠ

안녕하세요. 동균님main에서 시작하셔야 하는데, test 폴더에서 시작하신 것 같아요 🙂main/resources/templates 하위에 저장해주세요.감사합니다.

provider 사용하는 이유

안녕하세요. yne325님매번 새로운 객체가 필요하다고 가정하겠습니다.싱글톤 빈이 생성될 때 의존성 주입을 받으면서 프로토타입 빈이 딱 한 번 생성되어 주입됩니다.이후 싱글톤 빈을 계속 사용할 때마다, 안에 있는 프로토타입 빈은 계속 같은 녀석이 사용됩니다. (이미 주입이 끝났으니까요.)결과: 프로토타입(매번 새로운 객체)의 의도와 다르게 동작합니다. 해결책 (Provider 사용)싱글톤 빈은 프로토타입 빈 자체가 아니라, "프로토타입 빈을 찾아주는 Provider"를 주입받습니다.provider.getObject()를 호출할 때마다 스프링 컨테이너에 "새로운 거 하나 줘!"라고 요청하게 됩니다 (DL: Dependency Lookup).결과: 사용할 때마다 항상 새로운 프로토타입 빈이 생성됩니다. 핵심은 항상 새로운 객체가 필요할 때, 이런 해결 방안이 필요하다는 것입니다.감사합니다.

BeanCreationException

안녕하세요. 박준혁님아마도 추정하기에는 count가 0이면 removeStock()에서 예외가 발생할 것 같습니다. // OrderItem.java 내부 (추정)public static OrderItem createOrderItem(Item item, int orderPrice, int count) { OrderItem orderItem = new OrderItem(); orderItem.setItem(item); // ... 생략 item.removeStock(count); // return orderItem;} 해당 부분을 확인해주세요 🙂감사합니다.

계층 구조 모델링 기타 방법들

안녕하세요. bebe님과거에는 MySQL에서 CTE가 지원되지 않았는데요.이렇게 되면 한 번에 전체 트리를 조회하기가 쉽지 않았습니다.해당 문제를 해결하기 위해 다양한 방법들이 나오게 되었습니다.CTE를 지원하는 현 시점에는 강의에서 말씀드린 것 처럼 인접 리스트와 폐쇠 테이블이면 대부분의 상황을 커버하실 수 있을거에요.감사합니다 🙂

섹션 9의 퀴즈가 영어로 출력되요.

네오스카이님 감사합니다.저도 영어로 나오네요.인프랩에 바로 문의해보겠습니다 🙂