paymentCreator 쪽을 보니 사용자가 결제를 진행하지 않고 결제창을 닫았다가 다시 열거나 새로고침 하면 db unique 단에서 에러가 날 것 같더라구요. creator 로직에서 조회를 먼저하고 있으면 반환 없으면 생성하는 방식으로 분기문을 둔다. db unique를 타게하고 try catch 등으로 처리한다. 가독성이나 복잡도 측면에서 각각의 장단점이 있을 것 같습니다! 또한 결제창을 닫고 쿠폰이나 포인트 사용을 변경하고 다시 여는 경우도 있을 것 같은데 주문에 대해서 결제가 유니크 하나로 제한해두신 이유도 궁금합니다 이런 경우가 payment 생성 말고도 다양한 로직에서 자주 나오는 상황일 것 같은데 제미니님은 주로 어떤 스타일로 개발하시는지 궁금합니다!
INSERT INTO users (name, email, age, city) SELECT '새 사용자', 'test메일', 25, 'seoul' WHERE NOT EXISTS ( SELECT 1 FROM users WHERE email = 'test메일' ); 이 쿼리를 처음에 설명해 주실 때 두 개의 프로세스가 동시에 데이터를 확인하고 삽입하려 할 때 경쟁상태가 발생할 수 있다라고 하셨다가 뒤에 이 방식은 사실상 경쟁상태에 무관하다고 정정해주셨는데 그럼 두 개의 프로세스가 동시에 데이터를 확인하고 삽입하려 했을때 무관하다는 의미인가요?? 왜 무관한지 잘 모르겠습니다.
안녕하세요 재민님! 강의를 들으면서 코드베이스를 보니, 조회 메서드에는 대부분 @Transactional(readOnly=true) 을 걸지 않으시더라고요. (물론 findById() 같은 건 Spring Data JPA 내부에 알아서 걸려있긴 하지만요) 예를 들어서, fun findByCategory(categoryId: Long, offsetLimit: OffsetLimit): Page<Product> { val categories = productCategoryRepository.findByCategoryIdAndStatus(categoryId, EntityStatus.ACTIVE, offsetLimit.toPageable()) val products = productRepository.findAllById(categories.content.map { it.productId }) .map { Product( id = it.id, name = it.name, thumbnailUrl = it.thumbnailUrl, description = it.description, shortDescription = it.shortDescription, price = Price( costPrice = it.costPrice, salesPrice = it.salesPrice, discountedPrice = it.discountedPrice, ), ) } return Page(products, categories.hasNext()) } productCategory를 조회하는 시점의 스냅샷과 product를 조회하는 스냅샷이 위 케이스에선 일치하지 않아도 별 문제가 생기지 않겠지만, 때로는 정합성과 같은 이유로 같은 시점의 스냅샷을 유지해야 하는 경우도 있을 것 같다는 생각이 들었습니다! 물론 이는 @Transactional 뿐만 아니라 DB 격리수준까지 엮인 문제라, 단순히 @Transcational 의 판단 기준으로만 보기는 어렵지만, 조회 시점에 @Transactional(readOnly=true) 를 사용하는 것에 대한 재민님만의 기준이 있는지 궁금합니다!
환경 macOS (Apple Silicon) Docker Desktop 4.93.0, Kubernetes v1.36.1 (kubeadm 모드) 증상 setup-mac.sh 실행 후 bash verify.sh 를 돌리면 1~3단계는 통과합니다. 4단계(Jenkins 컨테이너 내부에서 K8s 접속)만 아래 에러로 실패했습니다. The connection to the server 127.0.0.1:6443 was refused - did you specify the right host or port? 원인 호스트의 ~/.kube/config 에 클러스터 주소가 https://127.0.0.1:6443 으로 저장되어 있었습니다. 이 파일이 그대로 Jenkins 컨테이너에 마운트됩니다. 컨테이너 안에서 127.0.0.1 은 호스트가 아니라 컨테이너 자기 자신이라서 접속이 거부됩니다. 교안의 docker-compose.yml ( extra_hosts: kubernetes.docker.internal:host-gateway )은 kubeconfig 주소가 kubernetes.docker.internal 이라고 전제하고 있습니다. 그런데 제 Mac은 /etc/hosts 에 kubernetes.docker.internal 항목이 없었고, Docker Desktop이 kubeconfig에 127.0.0.1 을 쓰고 있었습니다. Docker 공식 문서에도 Mac에서는 kubernetes.docker.internal 이 127.0.0.1 로 해석되도록 등록하는 것이 사용자 책임이라고 되어 있습니다. Windows에는 자동 등록 설정이 있지만 Mac에는 없습니다. https://docs.docker.com/desktop/setup/install/mac-permission-requirements/ 해결 /etc/hosts 에 이름을 등록했습니다. sudo sh -c 'echo "127.0.0.1 kubernetes.docker.internal" >> /etc/hosts' kubeconfig 클러스터 주소를 바꿨습니다. kubectl config set-cluster docker-desktop --server=https://kubernetes.docker.internal:6443 bash verify.sh 를 다시 실행하니 4단계까지 모두 통과했습니다. Jenkins 컨테이너 재시작은 필요 없었습니다.
이거 6버전으로 읽고 있다가 문득 이상해서 질문남긴다. RunIdIncrementer <- 이거 지금 5랑 6랑 동작.. 완전 다른거 같은데 맞냐..? (완전 다르다기 보다, 스프링 배치 리드의 이슈에서는 너네가 잘못 쓰고 있던거다 라고 하긴하던데) 전에는 같은 파라미터로 재시작할때도 사용가능했는데, 이제는 이거 안바꾸고 버전업하면 "하위고과" 확정이다.
9월 8일 세션 진행한 거는 없었을까요? 그날 다른 행사 운영자로 참여하느라 20시에 세션이 있었던 것 같았는데 뭔가 놓친 느낌이 들어서요... 만약 9월 8일날 세션이 없었다면 다행이고, 있었다면 대략 어느 내용이었는지, 어떻게 진도를 나아가야 할지 살짝이라도 알려주시면 감사드리겠습니다.
안녕하세요. 미션1을 수행하려고 하는데 진행 방법이 막연합니다. 내려받은 git소스는 이미 헥사고날아키텍쳐로 구성이 되어있는 상태인거같은데 어떤 소스, 혹은 브랜치를 기준으로 클린아키텍쳐로 리팩터링해서 제출하여야 할까요? 아니면 주문, 상품, 결제 시스템을 처음부터 설계해서 클린아키텍쳐로 작성하라는게 미션의 취지인가요? (이 경우 각 도메인별 요구 기능도 임의로 가정해서 작성해야 하나요?)
현재 Controller 클래스는 온전히 순수하지 않다(9강 11:51)고 말씀해주셨는데 온전히 순수한 Controller 클래스는 어떤 형태여야 하는지가 궁금합니다. 제가 봤을때는 지금 Controller 가 프레젠테이션 레벨의 productAssembler 를 호출해서 포맷팅만 바꿔서 내려주고 있기 때문에 로직적인 부분이 클래스에 없어서 순수해보이는데요. 혹시 productAssembler 에서 isUnique 를 계산해주고 있어서 순수하지 않다고 표현하신 걸까요?? 어디서 타협을 하셨다는건지 잘 이해가 되지 않아서 설명해주시면 감사하겠습니다!
안녕하세요! 6번 강의의 24:15 부분 즈음부터 설명하시는 장치 의존성에 대해 궁금한 점이 있어서 질문드리려고 합니다. 강의를 들으면 마치 "장치 의존성을 해결하기 위해 React.js와 같은 CSR 방식이 등장하였다."라고 이해하게 되는데, 그런 의도로 말씀하신게 맞는지 궁금합니다. 만약 그러한 의도로 말씀하신 것이 맞다면, 제가 알고 있는 내용과 많이 다른 것 같아 혼란스러워 질문을 작성하게 되었습니다. 제가 기존에 알고 있던 지식으로는, 다양한 화면의 장치에 대응하기 위해(즉, 장치 의존성을 해결하기 위해) "반응형 웹 디자인"이 등장한 것으로 알고 있는데요. HTML은 어떤 장치에서 받든 해당 파일을 구동하는 장치(구체적으로는 프로그램)에서 사용할 수 있게 결국 파싱이 되니까(Ex. DOM 생성) 장치에 의존하지 않는 것 아닌가요? 화면의 크기마다 달라지는 UI를 제어하기 위한 방법으로는 CSS에서의 반응형 웹 디자인으로 알고 있었는데요.. React.js와 같은 CSR이 등장하게 된 배경은 다양한 화면에 맞게 알맞은 UI를 보여주려고 한다기보다는, 웹 서버로 보내는 요청을 획기적으로 줄여(클라이언트의 브라우저에서 JS를 이용해 직접 index.html에서 필요한 요소(컴포넌트)를 리렌더링하므로) 웹 서버가 SSR 방식으로 설계되었을 때보다 더 적은 부하를 맡게 되고, 클라이언트 입장에서는 부드러운 화면전환을 경험할 수 있게 하기 위함으로 알고 있는데요. CSR 방식 자체가 장치 의존성을 해결할 수 있는 것이라면 그 이유가 무엇인지 궁금합니다!
"AI 딸깍의 시대" 원리로 돌파하는 Node.js와 CS Part 2 - 스트림 아키텍처와 하드웨어 통제기
안녕하세요 강의 잘듣고있습니다! 풀스택 개발자를 목표로 하고있고, 원리를 배우는게 너무 즐겁고 큰 도움이 되고있습니다. 그런데 당장 nestjs 및 리액트 등으로 웹서비스 개발업무도 할예정인데 nestjs 는 어떻게 공부를하면좋을까요? T 자형 인재가 되고싶습니다! 그리고 강의듣는 순서도 궁금합니다!! 현재 NODE 듣고있고, 유닉스도 결제했습니다..! NESTJS 도 공부빨리해야하는 상황이네요..
