현재 수강 진도를 함께 알려주세요! "1주차 3강까지 완료" 또는 "2주차 실습 중"처럼 어디까지 들으셨는지 적어주시면 맞춤형 답변을 드릴 수 있어요 📚 구체적인 상황과 함께 질문해주세요! "AI가 안 된다"보다는 "Cursor에서 이런 프롬프트를 입력했는데 이런 에러가 나와요"처럼 상세하게 적어주시면 더 정확한 답변을 드릴 수 있어요 🎯 스크린샷이나 코드를 첨부해주세요. 에러 화면, 현재 진행 상황을 보여주시면 문제 해결이 10배 빨라집니다! 마크다운 코드 블록(```)을 활용하면 더 깔끔하게 정리할 수 있어요 📸 커뮤니티 검색을 먼저 해보세요. 같은 문제로 고민하신 분들이 이미 해결책을 찾았을 수도 있어요. 검색 후 못 찾으시면 언제든 새로 질문해주세요! 🔍 서로 도우며 함께 성장해요. 나도 모르는 건 "저도 궁금해요!"라고 댓글 달아주시고, 아는 건 적극적으로 공유해주세요. 가르치면서 더 잘하게 됩니다 💪 바이브코딩 관련 질문은 환영, 기술 세부사항은 GPT 활용! 프롬프트 작성법, AI 도구 사용법은 여기서, 복잡한 코딩 문법은 ChatGPT에게 물어보시는 게 더 빨라요 🤖 진도나 과제 관련 문의는 1:1 문의를 이용해주세요. 개인적인 학습 계획, 환불, 수강 기간 연장 등은 따로 문의해주시면 더 자세히 상담드릴게요 📞 실패 사례도 공유해주세요! "이렇게 했더니 망했어요" 같은 경험담도 다른 수강생들에게 큰 도움이 됩니다. 실패도 소중한 학습 자료예요 💡 💬 좋은 질문 예시 [진도] 1주차 3강 Lovable [질문] 클라우드로 넘어갈 때 새로 회원가입 후 계속 퍼즐을 하라고 하는데 맞을까요? (사진 첨부)
안녕하세요, PRD.md -> ROADMAP.md -> Shrimp 로 작업 쪼개기 후 MVP 만든 후에, 기능을 새로 추가할때마다 똑같은 프로세스 ( PRD.md -> ROADMAP.md -> Shrimp ) 를 반복해야 하나요? 아니면 그냥 클로드에 바로 해당 기능을 추가해달라고 하는게 좋을까요?
안녕하세요. 클로드 코드 강의를 지속적으로 수강하면서 관련 의문점들이 몇 가지 생겨 질문드립니다. 우선적으로 프론트엔드를 기반으로 에이전트 및 커맨드를 생성하고 있는 것으로 강의를 들으면서 받아들여지고 있습니다. 하지만 풀스택 개발자나 혹은 백엔드 개발자, 프론트 작업을 많이 수행하지 않는 사람들은 어떤 식으로 작업을 만들고 진행하는 지에 대해서도 추가적으로 참고 자료나 강의 영상이 있으면 좋을 것 같습니다. 또한 저는 pro 버전을 사용하고 있어 토큰의 부담이 있어 sonnet 모델이 아닌 haiku 모델을 사용하고 있습니다. 차이점에 대한 영상은 보았지만 실제 모델별 코드의 품질 차이를 영상으로 확인할 수 있으면 좋을 것 같습니다. 특히 대형 프로젝트 (프론트, 백엔드, AI가 결합된 경우 각 영역을 담당하는 사람이 다를 경우 건드리면 안된다는 규정을 많이 두는데 이러할 경우 권장 모델 및 서브에이전트, 컨택스트 관리, 커맨드 설정 등 어떤 식으로 해야 되는지) 마지막으로 현재 프로젝트 내에 생성하는 것과 모든 프로젝트 내에서 커맨드와 서브에이전트를 사용하고자 할 때 실제 작성하는 md 파일의 차이점을 실제 눈으로 확인할 수 있으면 좋을 것 같습니다. 이러한 의문점이 발생하게 된 계기는 실제 프론트엔드 지식이 React 정도이고 현재 짐코딩님의 React 강의를 듣고 있는 상황에서 Next.js로 만들다 보니 이해가 잘 되지 않는 점도 있고 실제 목표는 풀스택, 백엔드, 보안 쪽으로 취업하는 것이 목표이기 때문에 이러한 방식으로 활용한다는 점은 좋지만 막상 적용하고자 하니 어떤 식으로 작성해야 될 지 막막한 점이 있어 질문 및 가능하다면 강의 요청을 남기는 것입니다!
"섹션 9 퀴즈"의 1번 문제, "Claude Code 설정 파일의 올바른 우선순위 순서는 무엇인가요?" 의 정답이 1번, 기업>사용자>프로젝트으로 나오는데, 이 반대가 아닌지 확인하여 주세요. * 공식문서에서 발췌 범위가 상호작용하는 방식 동일한 설정이 여러 범위에서 구성되면 더 구체적인 범위가 우선합니다: Managed (최고) - 아무것도 재정의할 수 없음 명령줄 인수 - 임시 세션 재정의 Local - 프로젝트 및 사용자 설정 재정의 Project - 사용자 설정 재정의 User (최저) - 다른 것이 설정을 지정하지 않을 때 적용 예를 들어, 사용자 설정에서 권한이 허용되지만 프로젝트 설정에서 거부되면 프로젝트 설정이 우선하고 권한이 차단됩니다.
안녕하세요, 좋은 강의 항상 감사드립니다. runpod 방법으로 바뀐뒤 적용 후 학습을 해보는 과정에서 incredibles detect 실습과정에서 에러가 났다가 해결하여 제보드립니다. numpy 2.2.6버전으로 template에 깔려있어서 numpy .1.x 기준으로 컴파일된 다른 패키지가 서로 충돌이 일어나서 epoch 학습이 시작되지 않는 에러가 있었습니다. 전 깔끔하게 numpy를 삭제하고 다운그레이드한 뒤 해결하였습니다. # 수정전 # Runpod의 경우 GDrive 연결하지 않고 /workspace/ultra_workdir에 저장. !mkdir "/workspace/ultra_workdir" # 주피터 노트북에서 참조할 수 있도록 /workspace를 /content/workspace 디렉토리로 soft link 적용. !ln -s /workspace /content/workspace # 수정 후 !mkdir "/workspace/ultra_workdir" !ln -s /workspace /content/workspace !conda uninstall numpy --force -y !conda install numpy=1.26.4 -y
Next.js 완벽 마스터 (v15): 노션 기반 개발자 블로그 만들기 (with 커서AI)
Rehype-sanitize를 사용하면 어떻게 설정을 하든, <u>에 대한 허용을 설정하든, '밑줄'을 긋는 서식에 대한 결과가 제대로 이루어지지 않습니다. 항상 생략되어 밑줄쳐둔 부분은 삭제되는 결과를 낳습니다. 그래서 드는 생각이, 어차피 제 노션에서 쓴 글을 받아서 작성하는데, 텍스트로 html코드를 이상하게 적어둘것도 아니므로, 굳이 sanitize가 있을 필요가 있나 하는 의문이 듭니다.
사용자가 캘린더를 보유했는지 여부로 확인할 것 같습니다. 이유는 추후 서비스 확장할 때 조금 더 수월할 것 같다는 생각이 들었습니다. 프로젝트를 시작하면서부터 아래와 같은 생각을 했습니다. - "누구나 호스트가 되면 안될까?" - "호스트 역시도 커피챗을 신청할 수 있게 하고 싶다." 그래서 위와 같이 서비스 정책을 확장할 때를 대비해서 (마이그레이션 비용을 줄이는 방향으로) is_host로 검사하는 것이 아닌 일단 캘린더 보유 여부로 호스트인지 아닌지 확인하자라고 판단했습니다.
두 요소를 모두 사용 하나, 각각 다른 용도로 쓸 것입니다. is_host 용도: 호스트 전용 엔드포인트 접근 통제 및 UI 메뉴 노출, 권한 기반 라우팅 호스트를 위한 endpoint API 에 대한 이용 허가 여부를 결정하는 호스트의 access token 생성 및 엔드포인트 함수 내의 조건문을 위해 필요한 모델 필드라고 생각합니다. 예상되는 우려점은 호스트 유저가 더이상 host가 되지 않을 때, host를 위한 API의 이용 허가를 거부 해야하기 때문에 is_host 필드값의 확실한 업데이트가 필요합니다. 사용자 캘린더 보유 여부 용도: 실제 예약 생성/동기화가 필요한 시점에 필수 체크, 호스트의 온보딩 플로우의 완료조건 게스트의 성공적인 Booking 을 위해서는 실제 캘린더에 대한 접근이 필요하기 때문에, 호스트는 게스트가 Booking 하기 위해서는 캘린더를 무조건 보유해야 합니다. 예상되는 우려점은 호스트의 캘린더는 호스트가 Booking을 받을 준비가 되있다면 항상 존재 해야하며, 실제 올바른 호스트에 매핑이 되어야합니다. 만약 캘린더가 존재 하지않거나, 호스트 캘린더 ID 에 대한 검증이 제대로 동작 하지 않는다면, 게스트의 Booking 이 실패로 이어지거나 다른 호스트 캘린더에 등록이 될 수 있습니다.
중복 예약을 데이터베이스의 고유값 제약으로 예방하는 방법 조건은 1)동일 일자와 동일 타임 슬롯인 경우 중복으로 간주 2)약속(부킹)이 취소되어 attendance_status 모델 필드값이 cancellled인 경우 예약 가능 위를 구현하기 위해 데이터베이스에게 아래 정보가 고유해야 한다는 특별한 규칙을 알려줄 수 있습니다. 1)누가 예약하는지 2)언제 예약하는지 3)어느 시간대에 예약하는지 위의 세가지가 모두 같으면 중복 예약이라고 판단 합니다. 취소된 재예약은 가능하게 하기 위해 고유성 규칙에 한가지 예외를 부여합니다. 호스트, 날짜, 시간 슬롯의 조합은 고유해야 한다. 예외적으로 예약상태가 "취소됨"이라면 그 예약은 위의 고유성 규칙을 무시해 달라고 합니다. 새로운 예약 생성 시: 데이터베이스는 예약하려는 호스트, 날짜, 시간슬롯 정보를 보고, 현재 '취소됨' 상태가 아닌 다른 예약이 이미 있는지 찾아봅니다. 만약 '취소됨' 상태가 아닌 다른 예약이 이미 같은 자리에 있다면, 데이터베이스는 "안돼! 이미 예약된 자리야!"라고 하며 새로운 예약을 저장하지 못하게 합니다. 만약 같은 자리에 '취소됨' 상태가 아닌 예약이 없다면, 데이터베이스는 새로운 예약을 성공적으로 저장합니다. 예약 취소 시: 어떤 예약이 '취소됨(cancelled)' 상태로 변경되면, 데이터베이스의 이 "특별한 규칙"은 그 취소된 예약을 더 이상 고유성 검사 대상에서 제외 합니다. 이제 그 자리는 "비어있는" 것처럼 간주되므로, 다른 사람이 같은 호스트, 날짜, 시간슬롯 정로 새로운 예약을 만들 수 있게 됩니다.
