안녕하세요, 선생님! 강의 들으면서 Service 및 Cache Handler 구성간 Create/Update <-> Delete 간의 Return Record 여부 차이에 대해 질문드리고자 합니다. 서비스도 그렇고, 핸들러도 그렇고, Return type이 Create/Update는 전달받은 Record를 Entity Context에 적용한 객체인데, delete의 경우 void로 운용하시는 것을 보고 어떤 차이점이 있는지 궁금하여 질문드리게 되었습니다. create, update 모두 반영 이후의 내역을 바로 반환하여 보여준다는 의미로 생각하였는데, delete를 보면 그런 것 같지는 않아서 따로 다른 의미가 있는지(실무에서 이렇게 많이 사용한다던가), 별 의미가 없는지 구체적으로 문의드리고자 합니다. 감사합니다.
카카오 데브톡 응답에 따르면 프론트/백엔드 분할 책임 방식이 지양한다고 합니다. 오히려 백에서 로그인 구현을 일임하는 것을 권장합니다. https://devtalk.kakao.com/t/oauth/136448 해당 블로그에서도 책임을 프론트와 백엔드가 나누어 가지는 방식 이 잘못되었다고 합니다. https://cafe.naver.com/xxxjjhhh/296 카카오 로그인 REST API에서도 백에서 인가 코드를 받습니다. https://developers.kakao.com/docs/ko/kakaologin/rest-api#before-you-begin-process 어떤 방식이 맞는지 헷갈립니다.
저는 review image reordering을 염두에 두고 sequence를 계속 가져가는 방향으로 결정했습니다. 제미니님은 실무에서 이렇게 염두에 두고 구현이 조금 더 복잡해지더라도 이런 특정 필드나 기능을 가져가는것을 오버엔지니어링이라고 생각하여 피하시는 편인가요? 어떤 기준으로 결정하시는지 궁금합니다.
image only query를 설명해주실때 stable pagination 때문에 조인을 사용하신다고 이해했습니다. 저는 다른방식으로 구현해보았는데 제미니님의 의견이 궁금합니다. 코드를 보면 나중에 image를 fetch 또 하게 되는데 이렇게되면 image only query를 ReviewImageEntity에 reviewId, status 인덱스를 걸고 SELECT review FROM ReviewEntity review WHERE review.targetType = :targetType AND review.targetId = :targetId AND review.status = :status AND EXISTS ( SELECT image.id FROM ReviewImageEntity image WHERE image.reviewId = review.id AND image.status = :status 이렇게 구현하는 방식이 데이터량이 많아진다면 효율적이지 않을까 싶어서 구현해봤습니다.
The 10x AI-Native Developer: 회사에서 AI로 압도적 성과를 내는 법
좋은 강의 잘 듣고 있습니다. 프롬프트, 스킬, sub-agent와 같이 여러가지 방식으로 claude code를 잘 활용하는 방법들이 있는데요, 이것을 사용하는 기준들이 있는지 궁금합니다. 즉, 어떨때는 프롬프트를 쓰고, 어떨때는 sub-agent보다는 스킬을 만들다와 같은 어떤 기준들이 있을까요?
안녕하세요. 도메인 모델을 설명하는 부분에서 관계와 규칙을 온라인 서점 운영 예시로 간단히 언급해주셨습니다. 강의를 들으면서 실제 업무 도메인에 관계와 규칙을 구분지으며 간단히 개인 실습을 해보았는데요. 적다보니 어느샌가 관계에 규칙이 섞이기도 하더라고요. 문득 이런 생각이 들었습니다. '관계와 규칙의 차이는 무엇인가?' 관계와 규칙을 명확하게 구분지으려면 어떤 기준을 갖고 생각해야할까요? 관계는, DB 모델에 워낙 익숙하다보니 하나의 OO은 여러 OOO을 갖는다. 이쪽으로 먼저 생각이 흐르기도 하고요. 예시로 들어주신 것을 보면 관계는, '비즈니스에서 관계'라는 생각이 듭니다. 규칙은 데이터를 변경할 때 필요한 조건이라고 생각하면 될까요? 토비님 의견이 궁금합니다.
retryCount가 전역에서 작동하는것이 좀 수상하네요. 각 메세지의 retryCount를 세어야 할 것 같은데 저렇게 두면 혹시 메세지들이 들어오면 숫자가 마구 이랬다 저랬다 할 가능성은 없나요? 이를테면 메세지 두세개가 들어왔는데 첫번째는 실패 두번째 메세지 실패 세번째 성공 이런 경우 첫번째 메세지가 성공할때까지 sync하게 작동하여 완전 처리될때까지 두번째 메세지는 아예 실행되지 않는것인가요? 아니면 평행하게 동시에 실행되는거라 저 코드가 좀 잘못된 건가요?
안녕하세요! 기존 PostRepository를 사용하다가 JPA 도입으로 JpaPostRepository가 새로 생겼는데, JpaPostRepository 클래스에 재구현을 하기 위해 default 메서드를 추가했는데 그 방법이 아닌 PostRepositoryImpl 와 같은 구현체를 만들어서 구현해도 무방할까요? 실무에서는 어떤 방식이 더 자주 사용 되는지 궁금합니다.
안녕하세요. 강의 잘 보고 있습니다. 여기서 페이지네이션 구현을 values 데이터값을 가져와서 Java단 코드내에서 stream을 사용하여 페이징 처리를 하고 있는데, 만약 데이터를 DB에서 가져온 데이터라면 쿼리에서 페이징 처리(limit, offset)를 하는게 더 효율적일까요?
형 나 지금 너무 재밌어서 잘 따라하던중 별거 아닌거에서 막혀서 좀 힘들어 형이 알려준 json 파라미터 넘기는 방법으로 해도 안되고 gpt 찾아서 진행 한거도 다 안돼는데 윈도우 환경에서 좀 힘든걸까 ?? 다른 수강생분이 올려준거도 봤는데 답변에 달아준 방법도 동작하지 않아 @Bean public JsonJobParametersConverter jobParametersConverter() { return new JsonJobParametersConverter(); } @Bean @StepScope public Tasklet terminatorTasklet( @Value("#{jobParameters['infiltrationTargets']}") String infiltrationTargets ) { return (contribution, chunkContext) -> { String[] targets = infiltrationTargets.split(","); log.info("⚡ 침투 작전 개시"); log.info("첫 번째 타겟: {} 침투 시작", targets[0]); log.info("마지막 타겟: {} 에서 집결", targets[1]); log.info("🎯 임무 전달 완료"); return RepeatStatus.FINISHED; }; }
안녕하세요! 좋은 강의 잘 듣고 있습니다. CompletableFuture.runAsync() 에 커스텀 Executor 를 따로 넘기는 코드를 보면서 궁금한 점이 생겼습니다. 동기 방식은 어차피 요청 스레드에서 직접 처리되니까 별도 스레드풀 설정이 의미 없는 거라 비동기에서만 설정하는 건가요? 아니면 동기에서도 풀을 따로 구성하는 케이스가 있는지 궁금합니다. 그리고 Java 21부터는 Executors.newVirtualThreadPerTaskExecutor() 가 기존 플랫폼 스레드풀을 대체하는 권장 방식인지도 여쭤보고 싶습니다. Virtual Thread는 풀링 없이 매 작업마다 새로 생성하는 방식이라고 이해했는데, 실무에서 전환할 때 주의할 포인트가 있다면 함께 말씀해 주시면 감사하겠습니다!
8분 29초에서 /logoutProc 를 겟방식으로 호출했고 로그아웃은 성공했습니다. 로그아웃 성공후 /logoutSuccess 로 이동해야 하고 해당 url 은 permitAll() 입니다. 그런데 왜 로그인화면이 표시되는지 궁금합니다. 강의를 조금 더 보다보니, 궁금증은 해결됐습니다. 그런데 여전히 궁금한 점은 해당 소스에 맨 아래 permitAll() 의 역할입니다. 실제 아무일도 안하는건지 궁금합니다.
안녕하세요. 잡이 어떻게 스텝에서 사용하는 컨텍스트 값까지 가지고 있는지 잘 이해가 되지 않아 질문드립니다. 분명 JobExecutionContext 에 넣은 것이 아니라 StepExecutionContext 에 값을 저장했는데, 확인해보니 JobExecutionContext 에도 동일하게 저장된 것처럼 보여서 헷갈렸습니다. 제가 이해한 바로는 JobExecutionContext 와 StepExecutionContext 는 서로 다른 영역이고, JobExecutionContext 는 step 간 공유용, StepExecutionContext 는 해당 step 전용으로 알고 있습니다. 그런데 왜 StepExecutionContext 에 넣은 값이 JobExecutionContext 에도 같은 형태로 보이는지 잘 모르겠습니다.
안녕하세요. 제미니님 유튜브 부터 인프런까지 참여하며 굉장히 많은 인사이트를 얻고있어 무한한 감사 인사를 올립니다. 질문 강의를 수강하며 제미니님이 던져준 키워드를 어떻게 곱씹어야하지? 라는 생각을 하며 두 가지 정도 질문을 드리게 되었습니다. Q1. "저같은 경우는 뭐 컴포넌트 같은 걸 좀 쪼개서 만들고 싶은데, 일단은 여러분들이 좀 혼합된 걸 느끼게 하려고 제가 풀어 놨어요" - 결제 코드 느끼기 13:17 이렇게 제미니님이 생각했던 코드를 보고 싶은데, 이 코드는 신규 강의였던 " 레거시 다루기 " 에서 개선 작업을 하나요? 아니면 저희에게 열린 사고를 던져주고 넘어가는걸까요? Q2. "success 메서드에 트랜잭셔널을 사용하는 것도 할 말이 많은데 기본적인 로직에서는 문제는 없다." - 결제 코드 느끼기 13:58 이 내용에서도 혹시 개선하는 부분도 질문 1번과 같이 레거시 다루기 강의에서 개선 하시나요? 개인적으로 success 에서 트랜잭션 어노테이션을 빼고, 저장하는 로직을 한 군데 모아서 거기 사용할 것 같은데 제미니님은 어떻게 하시는지 궁금하네요!
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 여기에 질문 내용을 남겨주세요. 이렇게 오류가 떠서 jdk oracle을 다운 받고 sdk도 설정하고 IVM도 설정했습니다. 자바 스프링 버전은 최신 버전인 4.0.5 대신 강의 자료에서 3.x인 최신버전을 선택하라길래 3.5.13.을 선택했습니다. 무슨 문제일까요?
