CDC 쉘 스크립트 설명 하시면서 실무에서는 사용하지 않는 방법이라고 하셨는데 보통 실무에서는 이런 쉘스크립트 대신에 어떤 방식으로 진행을 하나요?

안녕하세요! 페이징 처리 방식에 대해 궁금한 점이 있어 질문드립니다.코드를 보니 요청값으로 offset과 limit을 받고 이를 Pageable로 변환하고 있습니다.data class OffsetLimit( val offset: Int, val limit: Int,) { fun toPageable(): Pageable { return PageRequest.of(offset / limit, limit) }}그런데 이 방식은 offset이 limit의 배수가 아닌 경우 의도하는 바와 다르게 동작할 수 있을 거 같다는 생각이 들었습니다.예를 들어 offset=15, limit=10인 경우 15번째 데이터부터 10개인 15~19번째 데이터를 조회하는 것이 자연스럽다고 생각했습니다.그런데 현재 구현에서는 offset/limit 계산으로 인해 PageRequest.of(1,10)이 되고 결과적으로 10~19번째 데이터가 조회될 거 같습니다. 제가 이해한 내용이 맞을까요?? 그렇다면 이 방식은 더보기나 무한 스크롤처럼 offset이 항상 limit의 배수로 증가한다는 제약이 있을 때만 안전하게 사용할 수 있는 방식인지 궁금합니다.예를 들어 클라이언트가 항상 아래처럼 요청한다고 정해져 있다면 문제가 없다고 봐도 될까요?offset=0, limit=20offset=20, limit=20offset=40, limit=20또 이런 제약이 있다면 limit을 request로 받기보다 서버에서 고정값으로 관리하는 것이 더 나은지도 궁금합니다.마지막으로 어떤 API에서는 offset,limit을 받고 또 어떤 API에서는 page,size를 받는 경우가 있는데 실무에서는 각각 어떤 기준으로 선택하는지도 알고 싶습니다.취준 준비하면서 제미니님의 강의 도움 많이 받고 있습니다!! 감사합니다 ^^<정리>PageRequest.of(offset/limit,limit) 방식은 offset이 limit의 배수일 때만 안전한 방식인가요?더보기/ 무한 스크롤에서는 offset,limit을 사용하는 게 더 자연스러운가요??limit이 정책적으로 정해져 있다면 request로 받지 않고 서버에서 고정하는 게 더 좋을까요?offset/limit 방식과 page/size 방식은 어떤 기준으로 선택하면 좋을까요??

강의에서는 BoardDto로 요청을 다 받고 있는데 요청값은 CRUD마다 다를거라고 생각하는데Request 객체의 변경이 Service 계층에 영향을 미칠 수 있기 때문에 컨트롤러랑 서비스 DTO를 다르게 준다고 알고있습니다.컨트롤러BoardCreateRequestBoardCreateResponse서비스BoardCreateDtoBoardCreateResult근데 api 하나 만들때마다 너무 많은 변환과 객체 생성이 이루어질거같은데 강사님은 실무에서 어떤 방법을 사용하시나요?!..궁금합니다

안녕하세요. 강의 잘 듣고 있습니다.다름이 아니라 프로젝트 의존성 관계를 그래프로 그려주셨는데요. 그려주신 그래프가 맞는걸까요..?bank-mornitoring은 아무런 모듈을 의존하지 않고, 반대로 bank-monitoring을 의존하는 모듈은 bank-api, bank-event인데 그려주신 그래프와 관계가 좀 다른거 아닌가 싶어 여쭤봅니다!

4:56초 쯤 서비스에 어떤 기준에 따라 나누신 컴포넌트를 순차적으로 호출하고 있는데요.저는 이것과 거의 같은 이유로 usecase를 두고 있었습니다. 하지만, usecase 사용은 목적에 맞지 않거나 과도한 것이고 서비스만 두는 것이 좋을까요?

안녕하세요. 제미니님 유튜브 부터 인프런까지 참여하며 굉장히 많은 인사이트를 얻고있어 무한한 감사 인사를 올립니다. 질문강의를 수강하며 제미니님이 던져준 키워드를 어떻게 곱씹어야하지? 라는 생각을 하며 두 가지 정도 질문을 드리게 되었습니다. Q1. "저같은 경우는 뭐 컴포넌트 같은 걸 좀 쪼개서 만들고 싶은데, 일단은 여러분들이 좀 혼합된 걸 느끼게 하려고 제가 풀어 놨어요" - 결제 코드 느끼기 13:17이렇게 제미니님이 생각했던 코드를 보고 싶은데, 이 코드는 신규 강의였던 "레거시 다루기" 에서 개선 작업을 하나요? 아니면 저희에게 열린 사고를 던져주고 넘어가는걸까요? Q2. "success 메서드에 트랜잭셔널을 사용하는 것도 할 말이 많은데 기본적인 로직에서는 문제는 없다." - 결제 코드 느끼기 13:58이 내용에서도 혹시 개선하는 부분도 질문 1번과 같이 레거시 다루기 강의에서 개선 하시나요?개인적으로 success 에서 트랜잭션 어노테이션을 빼고, 저장하는 로직을 한 군데 모아서 거기 사용할 것 같은데 제미니님은 어떻게 하시는지 궁금하네요!

섹션 2 강의 4 5 6 전부 검은 화면으로 나옵니다. 나머지 강의들은 제대로 영상이 틀어지고요. Inflearn 에서 제공해주는 영상 FAQ의 조치를 다따라 해봤는데도 되지않습니다.

안녕하세요.histories() 응답에 PointHistory.id가 포함되어 있던데, 이 값을 내려주신 의도가 궁금합니다.FE에서 이 id를 직접 활용해야 하는 지점이 있는지 궁금해서요.예를 들어 포인트 이력 상세 조회나 특정 이력을 식별해야 하는 기능을 염두에 두신 걸까요?현재로서는 다른 필드들만으로도 충분하지 않나 생각되어, id를 포함하신 이유가 궁금합니다!

authService를 주입받을때 get을 사용해서 eager로 가져오는 것으로 보이는데 by inject<>으로 lazy로 가져오는 것이랑 어떤 차이가 있는지 알고 싶습니다. 또 실무에서는 보통 어느 상황에서 eager혹은 lazy를 사용하는지 알고 싶습니다.

타입스크립트도 듣고 싶습니다.혹시 이전 할인 가격으로 구매할 수 있을까요? ㅠ

Spring boot java를 사용하고있고, 현재 1. Spring Actuator 셋팅중입니다.actuator에서 health 외의 다른 URL은 404 Notfound 에러가 발생합니다.application.yml을 사용하여 include에서도 "*"로 전체허용 해놨는데도 안되네요  

@Query( """ SELECT new io.dodn.commerce.storage.db.core.SettlementTargetSummary( settlement.merchantId, settlement.settlementDate, SUM(settlement.targetAmount), COUNT(settlement.id), COUNT(DISTINCT settlement.orderId) ) FROM SettlementTargetEntity settlement WHERE settlement.settlementDate = :settlementDate GROUP BY settlement.merchantId, settlement.settlementDate """, ) fun findSummary(settlementDate: LocalDate): List<SettlementTargetSummary>이부분에서 where절에서 이미 settlementDate를 필터링하고 있는데 group by에서 settlementDate가 필요한 이유가 따로 있을까요? 어차피 parameter로 넘어온 settlementDate만 조회가 되는 로직이라 Group By에서는 필요가 없어보여 질문 남깁니다.

addReview()를 보면 리뷰 저장 이후에 포인트를 지급하는 로직이 함께 들어가 있는데, 제 기준에서는 포인트 지급이 리뷰 작성의 핵심 기능이라기보다 부가 기능처럼 느껴졌습니다.그래서 이런 부분은 서비스 내부에서 직접 호출하기보다 이벤트를 발행하고, 별도의 핸들러에서 처리하는 방식으로 분리해도 괜찮지 않을까 궁금했습니다.(다만 제가 이걸 정말 "부가적인 책임"으로 봐도 되는지 조금 헷갈리기도 합니다.)만약 실무에서는 이런 부가적인 로직을 서비스 메서드 안에 함께 둘지, 아니면 이벤트/이벤트 핸들러 형태로 분리할지를 어떤 기준으로 판단하시는지 궁금합니다.또는 이런 경우 이벤트 외에 다른 방식으로 설계하시는 경우도 있는지 궁금합니다.

Bold체 및 검은색 배경 설정과 흰색 글꼴 적용이 되지 않습니다. <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto" xmlns:tools="http://schemas.android.com/tools" android:id="@+id/main" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical" android:background="#008000" tools:context=".MainActivity"> <LinearLayout android:layout_width="match_parent" android:layout_height="200dp" android:layout_marginTop="100dp"> <TextView android:layout_width="match_parent" android:layout_height="wrap_content" android:textSize="30sp" android:textColor="@color/black" android:gravity="center" android:layout_margin="20dp" android:textStyle="bold" android:text="인생은 주사위 한방에 가는거 아니겠습니까?"/> </LinearLayout> <LinearLayout android:layout_width="match_parent" android:layout_height="200dp" android:weightSum="2"> <ImageView android:src="@drawable/dice_1" android:layout_width="120dp" android:layout_height="120dp" android:layout_weight="1"/> <ImageView android:src="@drawable/dice_2" android:layout_width="120dp" android:layout_height="120dp" android:layout_weight="1"/> </LinearLayout> <Button android:text="인생 고고" android:layout_width="match_parent" android:layout_height="50dp" android:background="@color/black" android:textColor="@color/white" android:layout_margin="50dp"/> </LinearLayout>

자바에서 클래스 필드 타입을 참조타입과 원시타입의 차이를 공부하던 중에둘의 차이가 null 값이 필요하냐 필요하지 않냐로 배웠습니다..그런데 엔티티 pk의 경우에는jpa에서 새 객체와 저장된객체를 구분할 때 null 을 본다고 들었습니다.그래서 참조형 Long을 쓰는 구나 라고 생각을 정리했어요!! 헌데 코틀린으로 쓰신 코드에서는 Long타입을 선언하시고 0으로 초기화해주시는 이유가 궁금합니다!코틀린에서는 nullable하게 할순있지만 기본적으로 null이 불가능하다고 들었긴한데.. 조금 헷갈립니다!언어적인 부분에서 jpa가 다르게 동작하는것인지 아니면 제가 좀 미숙하게 이해한건지 궁금합니다!

제미니님 이커머스 강의와 프로젝트 코드들을 참고하면서 게시판을 만들어보고 있는 중입니다!현재는 게시물 정보만 페이징 방식으로 구현해놓았습니다.근데 게시글 목록을 보여줄 때 한 게시글 당조회수, 좋아요수, 댓글 수, 유저닉네임 등.. 표시가 되야해서 좀 헷갈립니다.  한 API에서 전부 조합해서 내려준다고하면페이징된 게시글 10개를 먼저 조회하고조회한 게시글의 ID를 기반으로 조회수와 좋아요를 따로 조회한 뒤에 같이 내려주는 방식이 좋을까요?  

지금 클로드 데스크탑연동에 계속 실패하고 있습니다. 설정파일을 건들면 클로드가 아예 실행되지 않고있고있어요...윈도우 10 환경에서 인텔리제이 2025.2.6.1사용중이고, npx, npm 등 필요한것들은 설치완료했습니다. 우선 변경된 설정처럼 아예 목록에 표시되지 않고있는데, 윈도우버전 사용자들도 연동하는 가이드내용을 좀 상세하게 알려주실수있을까요?

제미니님 안녕하세요. 강의를 통해 각 개념 간의 응집성을 높이고, 불필요한 의존성을 줄여 격벽을 세우는 설계를 깊이 있게 연습하고 있습니다.강의에서 배운 원칙을 적용하여 '리뷰'나 '찜' 같은 개념들이 '상품' 개념을 단방향으로 참조하도록 구조를 잡고 있습니다. 하지만 실제 상품 목록 조회 기능을 구현하다 보니, 설계의 일관성을 유지하기 어려운 상황을 마주하게 되어 조언을 구하고자 합니다.개념 간 의존성의 역전: 목록 화면에서 '리뷰 수'나 '찜 수'를 함께 보여주거나, 이를 기준으로 상품을 정렬해야 하는 요구사항이 생겼습니다. 이 경우 상품 개념이 본래 몰라야 할 하위 개념(리뷰, 찜 등)의 상태를 알아야만 하는 상황이 발생합니다.API 구성의 어려움: 상세 페이지는 API를 잘게 나누어 클라이언트에서 합성함으로써 개념 간의 독립성을 지킬 수 있지만, 목록의 경우 수십 개의 상품에 대해 매번 각각의 리뷰 수 API를 호출하여 클라이언트가 매핑하는 방식은 어딘가 어색하고 성능과 구현 효율 면에서 의문이 듭니다.결국 조회를 위해 상품이 다시 리뷰나 찜을 알게 되면, 처음 설계한 개념 간의 단방향 참조 구조가 깨지거나 서로를 참조하는 순환 참조가 발생할 것 같아 우려됩니다.이처럼 개념 간의 격벽을 유지하려는 설계 원칙과, 여러 개념의 데이터가 한꺼번에 필요한 조회 요구사항이 충돌할 때 어떤 식으로 접근하는 것이 현명할까요? 원칙을 고수하며 우회할 방법이 있을지, 혹은 이런 조회 상황에서는 설계적 타협이 필요한 것인지 견해를 듣고 싶습니다.

강의에선 컨테이너 이미지를 DockerHub에 등록해서 사용하셨고,리버스 프록시를 위해 EC2에 Nginx를 띄워서 사용하셨는데요! AWS 인프라를 활용하는 환경이라면 AWS ALB나 AWS ECR을 쓰고, Terraform 같은 IaC 기술을 활용하면 인프라 구축에 필요한 비용을 많이 줄일 수 있을 것 같다는 생각이 들었습니다. 그럼에도 Docker Hub나 Nginx 인프라를 추가하여 사용한다면 어떤 장점이 있는지 궁금합니다.실무에선 주로 인프라 구성을 어떻게 하는지도 궁금합니다!

수업노트에 뭐라고 작성하신건가요? 파일이 깨진건지 핵심 문장이 안보여요