MacOs 사용자 분들이시고 cat ~/.docker/config.json 의 결과에 credsStore 필드가 osxkeychain이고 auth 필드의 값이 비어있으신 경우 인증정보가 keychain으로 관리되고 있고 이걸 jib이 가져오지 못하고 있는 겁니다. 방법 1 (가장 추천합니다) jib 내부의 from과 to 블록의 image 선언 다음 credHelper { helper = "osxkeychain" } 해당 코드를 추가해 keychain에 접근할 수 있도록 해주면 좋습니다. + auth {}로 인증정보를 주입하는 방법으로도 대체 가능합니다. 방법 2 (문제 회피) java 25 이미지를 docker pull 받아 로컬에 두고 ./gradlew jibDockerBuild 하시면 됩니다. 나중에 redis를 받던데 그때로 같은 방법으로 해결하면 될 것같습니다. 방법 3 (keychain 필드깨서 강제로 base64쓰게 하기) credsStore 필드를 훼손시켜 강제로 auth에 암호화된 내용을 저장하도록 하는 것같습니다. 정말 추천하지 않으며, 위 방법이 모두 실패하면 시도해보세요.
안녕하세요 재민님! 좀 오래되긴 했지만, 2년 전쯤에 발표하신 (유튜브에도 자주 언급하신 ㅎㅎ) 개념과 격벽을 통해서 지속 성장 가능한 설계를 만드는 방법에 대해 여쭤보고 싶은 부분이 있어서 질문드립니다! Q1) 발표에서 개념을 코드로 느끼면서 잡아간다고 하셨는데, 이게 개인의 사고에 많이 의존하는 것 같아서요. 실제 팀에서는 한 사람이 발견한 개념(예: 대출 사례의 '연체' 분리 같은)을 팀원들과 어떻게 합의하고 공유하시나요? 코드 리뷰에서 자연스럽게 되는 건지, 별도의 논의 과정이 있는지 궁금합니다. 팀과 협업하는 관점에서는 설계가 결국 합의의 과정이기도 하다 보니, 이 방식이 팀 규모에서는 어떻게 작동하는지가 특히 궁금했습니다 ㅎㅎ Q2) 개발을 하다 보면 "설계"라는 과정을 많이 겪게 되는 것 같습니다. API 설계, ERD 설계, 시스템 아키텍처 설계 등등 참 많네요. 발표에서는 분석·설계 없이 바로 구현하면서 개념과 격벽을 잡아가라고 하셨는데, 실제로 새 기능이나 서비스를 시작하실 때 무엇부터 손대시는지 궁금합니다. 개념(도메인 클래스)부터 코드로 잡고 API나 DB 스키마는 나중에 따라오게 하시는 건지, 아니면 이런 것들 중 일부는 최소한으로 먼저 정해두고 시작하시는지, 재민님의 실제 작업 순서가 궁금합니다. 물론 절대적인 정답은 없고 케바케일 것 같긴 합니다. 예를 들면 프론트엔드나 타 팀이 의존하는지 등등에 따라 달라지겠지만요. 재민님만의 어떤 기준 같은게 있는지 궁금합니다. Q3) AI가 코드를 대신 짜주는 시대가 되다 보니, 회사에서도 코드를 잘 짜는 것 자체의 가치가 점점 낮아지는 분위기인데요. (물론 회사 KPI마다 다르겠지만 ㅎㅎ) 이런 시대에 개념과 격벽을 세우는 역량은 오히려 개발자의 마지막 차별점이 된다고 보시는지, 아니면 이 피드백 루프(구현하며 느끼고 개선하는)마저 AI가 돌게 될 거라고 보시는지, AI 시대에 이 방법론이 가지는 의미를 어떻게 보시는지 궁금합니다.
안녕하세요, 강사님 🙂 덕분에 코프링을 빠르게 배우고 있어 감사드립니다! 영상 8:20 경, JWT 설명 중 withSubject() 의 값으로 email 만 넣는다던가, name 만 넣어서 구현한다고 말씀주셨습니다. 고민을 해봤지만 여러 개의 Subject 를 만드는 이유가 궁금해서 질문드립니다. 상황 예시와 함께 답변해주시면 감사드립니다!!
안녕하세요! 페이징 처리 방식에 대해 궁금한 점이 있어 질문드립니다. 코드를 보니 요청값으로 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=20 offset=20, limit=20 offset=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를 다르게 준다고 알고있습니다. 컨트롤러 BoardCreateRequest BoardCreateResponse 서비스 BoardCreateDto BoardCreateResult 근데 api 하나 만들때마다 너무 많은 변환과 객체 생성이 이루어질거같은데 강사님은 실무에서 어떤 방법을 사용하시나요?!.. 궁금합니다
안녕하세요. 강의 잘 듣고 있습니다. 다름이 아니라 프로젝트 의존성 관계를 그래프로 그려주셨는데요. 그려주신 그래프가 맞는걸까요..? bank-mornitoring은 아무런 모듈을 의존하지 않고, 반대로 bank-monitoring을 의존하는 모듈은 bank-api, bank-event인데 그려주신 그래프와 관계가 좀 다른거 아닌가 싶어 여쭤봅니다!
안녕하세요. 제미니님 유튜브 부터 인프런까지 참여하며 굉장히 많은 인사이트를 얻고있어 무한한 감사 인사를 올립니다. 질문 강의를 수강하며 제미니님이 던져준 키워드를 어떻게 곱씹어야하지? 라는 생각을 하며 두 가지 정도 질문을 드리게 되었습니다. Q1. "저같은 경우는 뭐 컴포넌트 같은 걸 좀 쪼개서 만들고 싶은데, 일단은 여러분들이 좀 혼합된 걸 느끼게 하려고 제가 풀어 놨어요" - 결제 코드 느끼기 13:17 이렇게 제미니님이 생각했던 코드를 보고 싶은데, 이 코드는 신규 강의였던 " 레거시 다루기 " 에서 개선 작업을 하나요? 아니면 저희에게 열린 사고를 던져주고 넘어가는걸까요? Q2. "success 메서드에 트랜잭셔널을 사용하는 것도 할 말이 많은데 기본적인 로직에서는 문제는 없다." - 결제 코드 느끼기 13:58 이 내용에서도 혹시 개선하는 부분도 질문 1번과 같이 레거시 다루기 강의에서 개선 하시나요? 개인적으로 success 에서 트랜잭션 어노테이션을 빼고, 저장하는 로직을 한 군데 모아서 거기 사용할 것 같은데 제미니님은 어떻게 하시는지 궁금하네요!
안녕하세요. histories() 응답에 PointHistory.id가 포함되어 있던데, 이 값을 내려주신 의도가 궁금합니다. FE에서 이 id를 직접 활용해야 하는 지점이 있는지 궁금해서요. 예를 들어 포인트 이력 상세 조회나 특정 이력을 식별해야 하는 기능을 염두에 두신 걸까요? 현재로서는 다른 필드들만으로도 충분하지 않나 생각되어, id를 포함하신 이유가 궁금합니다!
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()를 보면 리뷰 저장 이후에 포인트를 지급하는 로직이 함께 들어가 있는데, 제 기준에서는 포인트 지급이 리뷰 작성의 핵심 기능이라기보다 부가 기능처럼 느껴졌습니다. 그래서 이런 부분은 서비스 내부에서 직접 호출하기보다 이벤트를 발행하고, 별도의 핸들러에서 처리하는 방식으로 분리해도 괜찮지 않을까 궁금했습니다. (다만 제가 이걸 정말 "부가적인 책임"으로 봐도 되는지 조금 헷갈리기도 합니다.) 만약 실무에서는 이런 부가적인 로직을 서비스 메서드 안에 함께 둘지, 아니면 이벤트/이벤트 핸들러 형태로 분리할지를 어떤 기준으로 판단하시는지 궁금합니다. 또는 이런 경우 이벤트 외에 다른 방식으로 설계하시는 경우도 있는지 궁금합니다.
