퍼널 분석을 통한 Foodie Express의 비즈니스 인사이트를 도출하는 레포트를 작성하였습니다. 아래의 노션 링크 첨부하여 드립니다. 감사합니다. https://app.notion.com/p/6-1-3a96c0de4db680fda4d5f30c3ecc0b43?source=copy_link
안녕하세요 영한님 마스터패스 구매하고 모든 강의를 재밌게 수강하고 있는 백엔드 개발자 취업준비생입니다. 강의를 듣다가 궁금한 점이 생겨 질문남깁니다! 답변해주시면 너무 감사하겠습니다. is_deleted 와 같은 컬럼을 사용하는 soft delete 방식은 실제 삭제 시점을 알 수 없기 때문에 주로 사용하진 않고, deleted_at을 컬럼으로 두고 삭제 여부/시점을 모두 판별할 수 있게 한다고 하셨는데, 그렇다면 뒤에 설명해주신 상태 기반 관리를 통해서 ProductStatus나 OrderStatus를 관리할 경우, deleted_at이나 다른 시점을 컬럼으로 두면 나쁜 설계라고 하셨습니다. 그렇다면 결국 ProductStatus와 같은 상태를 가진 것들은 삭제 시점이나 특정 시점을 알 수 없는건 마찬가지 아닌가요? 만약 삭제 시점이나 회원의 탈퇴 시점같은 것들을 관리해야 한다면 어떻게 해야할까요? 이러한 해결 방법으로써 이력 테이블 등의 방법이 있을 것 같은데 취준생의 개인 프로젝트로 사용하기에 규모가 너무 커지지 않을까 걱정됩니다. 실제 사례를 예시로 들어보자면 UserStatus 상태값입니다. 이를 테이블의 한 컬럼으로 두고 내부에는 ACTIVE(정상), SUSPENDED(임시정지), BANNED(영구정지), WITHDRAWN(탈퇴) 등의 여러 상태를 가집니다. 이때 만약 withdrawn_at 컬럼이 존재하지 않고 상태값만으로 관리하면 탈퇴 시점이 언제인지 등을 확인할 수 없게 됩니다. 이 경우에는 withdrawn_at 컬럼을 상태값과 함께 두는 것보다 이력 테이블을 사용하는게 더 나은 설계이자, 개인 소규모 프로젝트에서도 해당되는 사항인지 궁금합니다. 작은 조언이라도 해주시면 감사하겠습니다! -- 에이전트 인프런 에이전트에 같은 내용으로 질문을 남겨봤는데 withdrawn_at 컬럼을 상태 컬럼과 함께 사용하는 것이 효율적이고 합리적인 설계라고 합니다. 실제로 이력 테이블은 개인 프로젝트 규모정도에서는 사용하기에 관리 복잡도가 증가할 가능성이 있다고 합니다. 이에 대해 어떻게 생각하시는지도 궁금합니다.
안녕하세요 영한님! 강의 재밌게 잘 듣고있습니다. 아직 섹션3까지 들었는데 MySQL 아키텍처 설명을 너무 잘해주셔서 너무 재밌게 들었습니다! 개인적으로 실무에서 PostgreSQL을 사용하고 있는데 혹시 PostgreSQL 아키텍처 강의도 업데이트 예정이 있으신지 궁금합니다!
1. 현재 학습 진도 섹션 3 15강 수강 2. 어려움을 겪는 부분 아직 섹션3 15강밖에 수강하지 않았지만 예전에 배포했을때 설정 문제로 과금이 나간적이있어서 강의는 계속 들으면서 로컬에서 해보고 개인 프로젝트에 적용해보는것이 좋을까요? 아니면 둘 다 하는것이 좋을까요??
for 문에서 초기화 -> 조검검사->참이면 처리->증감->조건검사->조건 감사-> 아닌가요? intc=0; for(I=1; I>3; i++) { c++; } printf("c=%d",c); 정답: ? 답변이 어려운 질문 좋은 질문 예시 3강 12분 35초에서 설명하신 반복문 조건식이 이해되지 않습니다. 왜 i < 10으로 작성하나요? 5강 08분 10초에서 나온 코드 실행 결과가 제 환경에서는 다르게 나옵니다. 아래는 제가 작성한 코드입니다. 정확한 강의 위치와 질문 내용을 함께 남겨주시면 더 빠르고 정확하게 답변드릴 수 있습니다.
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) 예 [질문 내용] 오류인 부분이라 신고합니다. 76강 2분 33초 부분에서 transaction 설명을 위해 계좌에서 이체되는 부분 말씀 하실 때 A고객이 1만원 이체하여 잔금이 줄어 4만원인 부분을 작성하시고 연이어 B고객 부분을 말씀하실 때 이체를 받았으니 1만원이 되어야 한다고 하며 10000원으로 적으셨습니다. 하지만 내용 상 30000원이 되어야 하는 부분으로 보입니다.
[질문 내용] SumTask의 run()메서드 안 for문에서 result += i;를 하지 않고 지역변수인 sum을 사용하여 마지막에 result = sum을 하신 이유가 지역변수(sum)는 스택영역, 멤버변수(result)는 힙 영역에 관리되어, 매번 메인 메모리에 있는 result의 값을 변경하는 것이 아닌 cpu 코어의 캐시 메모리를 사용하는 것이 더 빨라서일까요?
안녕하세요. 리텐션 과제 제출합니다. 실무 기반의 문제라 그런지 역시 난이도가 있네요. 고민을 많이 해보게 되었습니다. 리텐션 유저 기준은 게임 업계 기준으로 정의하고 문제를 풀었습니다. (플랫폼에 따라서 기준도 다르고 하지만) 보시고 피드백 있으시면 말씀을 부탁드리겠습니다. https://app.notion.com/p/2b00de0d9a16809f94f5e378ee375b2f?source=copy_link
해당 리텐션 연습과제를 아래의 노션 링크에 담아 제출합니다. 2번과 3번과제는 너무 어려워서 AI의 도움을 받아 수행하였습니다. 많이 고민하는 계기가 되었고, 덕분에 노션도 처음 사용해보았습니다. 부족한 점은 없는지 피드백 주시면 감사하겠습니다. https://app.notion.com/p/3-13-3986c0de4db68063b1b9efa55c1d4b4f?source=copy_link
안녕하세요. 강의를 수강해주셔서 감사합니다. 질문 작성 시 아래 내용을 함께 작성해주시면 보다 정확하고 빠르게 답변드릴 수 있습니다. 현재 진행 중인 섹션 또는 강의명 발생한 에러 내용 관련 코드 콘솔 에러 메시지 기대한 결과와 실제 결과 특히 개발 관련 질문은 코드와 에러 로그를 함께 첨부해주셔야 원인 파악이 훨씬 수월합니다. 또한 이 강의는 실무형 프로젝트 기반 강의이기 때문에, 구현 방식이나 설계 방향이 상황에 따라 달라질 수 있습니다. 질문 전에는: 강의 내용을 다시 한번 확인해보시고 기존 질문/답변에 유사한 내용이 있는지도 함께 확인 부탁드립니다. 수강생분들과 함께 좋은 학습 환경을 만들 수 있도록 서로 존중하는 분위기에서 이용 부탁드립니다. 감사합니다.
헥사고날 아키텍처와 DDD를 적용할 때, 화면에 강하게 연관된 조회 데이터를 어떻게 다루는 게 좋은지 궁금합니다. 예를 들어 채팅방 목록 화면에서 각 채팅방마다 다음 정보를 한 번에 보여줘야 한다고 가정하겠습니다 . ex) 채팅방 이름, 마지막 채팅 내용, 읽지 않은 채팅 개수 이 정보를 구하려면 room, chat, read_status 같은 여러 테이블을 함께 조회해야 하고 , N+1 문제를 피하려면 Querydsl 이나 JDBC 등을 사용해서 한 번의 쿼리로 조회하는 방식이 필요해 보입니다 . 이 경우 제 생각에는 기존 포트와 분리해서 , 조회 전용 port 와 query repository interface 를 application 계층에 두고 , adapter 계층에서 Querydsl/JDBC/MyBatis 등으로 구현하는 것이 해결책 같습니다. 이런 식으로 cqrs패턴을 적용하는 것이 유일한 해결책인가요? 혹시 더 나은 방법이 있는지 궁금하여 질문남깁니다. (강의 너무 잘 보고 있습니다)
member 테이블에서 회원의 가입일은 비즈니스 시간이라고 생각했는데, 이 컬럼은 왜 created_at 으로 시스템의 시간만을 의미하도록 되어 있는지 궁금합니다. ordered_at, paid_at 과 같이 가입일 컬럼이 따로 존재해야 하는게 아닌지 궁금합니다! 강의자료에 예시로 적어주신 것처럼 비즈니스 시간이 데이터베이스 수준에서 마이그레이션을 해야한다면 회원가입일을 보존할 수 없지 않을까요?