안녕하세요. 올려주신 강좌 너무 유익하게 잘 보고 있습니다. 감사합니다. 섹션 12. GCS (Google Cloud Storage) BIgQuery에서 사용할 데이터를 업로드 하기 에서 수업 노트에 올라와있는 구글 드라이브에 액세스 권한이 필요하여 다운로드가 안됩니다. (아파트거래, 시군구코드 csv 파일 입니다) 익명 액세스에 대해서 read 권한을 부여해주시면 감사하겠습니다
안녕하세요. docker-compose down시 계속 permission denined가 뜹니다. 우선 저는 가상머신 os:ubuntu에서 프로젝트를 진행중이며, sudo 붙여서 종료 시도, sudo docker kill 로도 강제 종료를 시도했지만 permission denined이라 다 실패하였습니다. 최후의 수단으로 docker설치 삭제 후, 재설치도 해보았지만 안타깝게도 실패하였습니다. 하여 container를 종료하려고 할 때마다 가상머신 종료하고 다시 들어가야하는 매우 불편하고도 불운한 상황에 처해있습니다. groups를 통해 docker가 있는 것도 확인하였습니다. 도저히 왜 안되는지 모르겠습니다. 도움이 절실합니다... 감사합니다.ㅠ
공유해주신 API Gateway 아키텍처를 보면 Order 서비스가 Product 서비스에게 해당 상품 수량 어느정도인지 요청시 Order 서비스는 유레카에게 Product 서비스 위치를 질의 한다. 유레카에 등록된 Product 서비스 위치 정보를 Order 서비스에게 응답한다. Order 서비스는 Product 서비스에게 실질적으로 상품 수량 GET 요청 한다. 제가 알고 있는 일반적으로 (MAS X) 모놀리식 구조에서 Feign Client 를 사용시 유레카를 사용 하지 않는 상황에서 특정 서버에게 요청시 곧바로 해당 서버에게 요청을 했었는데요. (3 Way Handshake 생략) 그런데 @FeignClient(name = "product-service", url="http://product-service") public interface ProductFeign { } 이렇게 FeignClient 어노테이션에서 name 을 특정 서버 어플리케이션 이름으로 지정하게 된다면 알아서 유레카에게 질의하고 응답 받아서 Product 서비스에게 요청해서 총 HTTP 요청이 2번 일어 난다고 보면 되는건가요? 일단 비지니스 로직단에서는 HTTP 요청이 2번 일어난다(유레카 서버에게 호출 하고 그 다음 실질적은 요청하고자 하는 서버에게 다시 요청) 라고 로직상에서는 안보여서요. 이부분은 내부 로직(Feign client 라이브러리 내부 로직?? 이라고 해야 할까요?..)에서 처리된거라서 눈에 안보이는 부분인지 알고 싶습니다.
안녕하세요. 프로젝트를 진행 하기위한 팀원 모집합니다. 프로젝트 주제 : 뉴스 서치 플랫폼 프로젝트 목표 : 기획부터 배포까지 경험 + 경쟁력 있는 포트폴리오 예상 일정 : 주 1회 온라인 / 월 1회 오프라인 예상 커리큘럼 간략히 : 예상 모집인원 : 현재 인원 : 기획/디자이너 1 프론트엔드1 백엔드3 모집 인원 : 프론트엔드 1 프로젝트 소개와 개설 이유 : 현재 저는 주니어 개발자로 재직중이며 시작한지 몇달 안되었고 이전에도 팀프로젝트는 물론 개인 프로젝트도 진행해보지 않아 어떤 툴을 써야할지 뭐가 필요한지 전무한 수준입니다. 그리고 회사에서는 이미 구축이 되어있어 기능 개발 이외에 경험을 하지못하여 전체적인 프로젝트 관련 지식이나 이해도가 부족하여 직접 해보며 성장해 나아가기 위해 프로젝트 진행을 하게되었습니다. 막상 혼자 처음 시작할려니 어려움이 있어 여러 사람을 모아 함께 고민하며 진행해 나아가고 싶습니다. 실력이 부족한만큼 프로젝트를 진행해보며 개발이 어떻게 되는지 배포는 어떻게 하는지 경험을 쌓기 위한 프로젝트라고 생각해 주시면 감사하겠습니다. 프로젝트 관련 주의사항 : 초보자도 상관없고 실력이 있으신 분도 상관없습니다. 기준을 정하고 구하는 것이 아니니 실력 차이가 많이 날수 있습니다. (기획을 못따라갈 수도 있고 디자인이 마음에 안들 수도 있고 개발이 더딜 수 있습니다.) 부족하면 더 열심히하고 실력이 좋은 사람은 이끌어줄 수 있는 사람을 원합니다. 프로젝트에 지원할 수 있는 방법을 남겨주세요. (이메일, 카카오 오픈채팅방, 구글폼 등) : 지원 및 문의 사항은 오픈 채팅방으로 연락주세요. https://open.kakao.com/o/sdClaIwh
1) 해당 공정의 VDD 값이란 : VDD(BGR)=4V, VDD(AMP)=3.3V 등 VDD 조건이 달라, 어떤 전압을 기준으로 설계해야 할지 혼란스러워 질문드립니다!. tsmc 180nm의 정확한 공정 매뉴얼을 찾아보려 했지만 정확하게 알 수가 없네요ㅠㅠ 또한 정확한 공정 규격을 알아야 소자 손상없이 올바른 동작이 가능한것으로 알고 있습니다. → 제가 알아본 정격 전압은 1.8V이긴합니다 2) 저전압 설계에서의 VDD : BGR 과제에서 VDD=4V를 사용하여 낮은 기준전압을 생성했습니다. 기 경우, "저전압 설계'라는 것은 공급전압과 무관한게 맞는지 혼란스러워 질문드립니다 ! (제가 이해하고 있는 저전력/저전압 설계는 다음과 같습니다) (저전력 설계 : Power=VI를 낮춘 설계. 즉, VDD뿐만아니라 Current까지 작으면 좋음) (저전압 설계 : 낮은 VDD를 사용)
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 안녕하세요. 궁금증이 생겨서 질문을 드립니다. requset scope가 웹 스코프 에서 중요한 역할을 한다는것을 어느 정도 인지가 되는 상황이지만, 여러 번을 들어도 "모르겠다"라는 는 말이 저절로 나옵니다... 그래서 일단은 그냥 넘어 갈려고 합니다. 여기서 질문입니다. requset Scope를 더욱더 활용하거나 공부하는 강의가, 다음 강의 및 다른 강의에서 있나요? 추가1 만약에 없다면 어떤 것을 들어야(해야지) 이해 할수 있을까요? 답변 부탁드립니다.
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] Fork/Join 공용 풀(및 병렬 스트림)을 I/O 대기 작업에 사용하면 스레드 병목으로 요청이 밀려서 그 해결책으로 로직 전용 스레드 풀을 만들었잖아요. ExecutorService logicPool = Executors.newFixedThreadPool(400); 다른 해결책으로 다음과 같이 공용이 아닌 그냥 Fork/Join 풀을 써도 되나요? 공용이 아니니깐 스레드 병목 현상도 없으니깐요. ForkJoinPool logicPool = new ForkJoinPool(400); 아니면 이것도 여전히 안 좋나요?
안녕하십니까? 강사님 강의를 열심히 듣고 있는 중입니다. 363강 Step #29 - Timer를 실습하던중 의문점이 생겨서 문의 드립니다. 30초에 타이머가 일시정지하게끔 하거나 중지시키게 하면 항상 2-3초의 오차가 발생합니다. 이게 소스상의 문제인지 아님 다른 문제인지 알수가 없어서 문의 드립니다.
[리뉴얼] 처음하는 파이썬 머신러닝 부트캠프 (쉽게! 실제 캐글 문제 풀며 정리하기) [데이터분석/과학 Part2]
안녕하세요, 선생님. 좋은 강의 항상 감사히 잘 듣고 있습니다. train 데이터와 test 데이터를 미리 파일로 나누어 작업하시는 것을 보았는데, 실제 회사에서도 이렇게 작업하는지 궁금합니다. 보통 어느 단계에서 train과 test 데이터를 나누는 것이 맞는지도 알고 싶습니다. 예를 들어, 결측값이나 이상치 처리, NaN 값을 처리한 후에 데이터를 나누는 것이 맞는지, 아니면 처음부터 비율(예: 8:2)로 나누고 시작하는 것이 맞는지 궁금합니다. 답변해 주실 수 있을까요?
editor가 랜더링 되지 않으면 vm option을 추가해야 합니다. Help > Edit Custom VM Options... -Dide.browser.jcef.out-of-process.enabled=false 해당 옵션 설정에 대한 Copliot 설명 ➡ JCEF 브라우저를 IDE 프로세스 내(in-process)에서 실행하겠다 는 의미입니다. 기본적으로 JetBrains IDE는 JCEF 브라우저를 별도의 프로세스(out-of-process) 로 실행해서 안정성과 보안성을 높이려고 해요. 하지만 이 옵션을 false 로 설정하면: 브라우저가 IDE와 같은 프로세스에서 실행 됩니다. 일부 환경에서는 성능 향상 이나 디버깅 편의성 을 위해 이렇게 설정하기도 해요. 반면, 브라우저 충돌 시 IDE 전체가 영향을 받을 수 있는 위험 도 있어요.
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 여기에 질문 내용을 남겨주세요. com.helloshop이라 쓰면 그냥 패키지 하나로 뜨고 그 밑에 product를 만들어도 helloshop패키지 이름이 바뀝니다. 뭐가 문제일ㄲ?ㅏ요
createGlobalStyle이 컴포넌트 형태로 적용되다보니 마치 현재 컴포넌트 하위만 적용될 것 같은 느낌이 있는데요 실제 영향범위는 class 수정이므로 페이지 전체에 영향을 끼치다보니 개인적으로 비직관성이 느껴집니다 createGlobalStyle을 실제로 사용하신 경험이 있는지와 사용하셨다면 _app 외에 다른 위치에서도 쓰셨는지 궁금합니다
안녕하세요. 카프카 클러스터 규모를 추산하던 중 감당 가능한 토픽/파티션 수가 궁금하여 질문드립니다. 예를 들어, Replication Factor를 3으로 가정할 때 레플리카 개수가 대략 10,000개가 나옵니다 (3,000 파티션 × replication factor 3) 파티션 10개인 토픽 100개: 1,000개 파티션 20개인 토픽 100개: 2,000개 총 파티션: 3,000개 RF가 3일 때 전체 클러스터 레플리카 수: 9,000개 추후 토픽 추가에 따라 레플리카 수가 최대 18,000개까지 늘어날 수 있음 토픽과 파티션 규모가 이 정도라면 카프카 클러스터를 적절한 단위(도메인)로 나눠야 할지, 아니면 한 클러스터에서 충분히 운용 가능한지 궁금합니다. 클러스터를 하나로 구성하여 사용하자니 레플리카 수가 감당 가능할지 고민되고 클러스터를 여러개로 구성하여 사용하자니 그에 따른 비용과 오버 엔지니어링이 고민됩니다. 파티션이 많을수록 파일 같은 자원을 더 사용하고 각 클라이언트로부터 수많은 요청을 받게 되는데, 브로커를 충분히 늘리면 감당 가능한 정도일까요? 큰 규모의 카프카 클러스터를 운용해본 적이 없어 강사님께서 카프카 클러스터를 어떻게 운용하셨는지 여쭤봅니다. (이정도 수준의 레플리카를 운용해본적이 있는지 등) 참고로 카프카는 3.x (KRaft 모드) 버전을 사용하려고 합니다. 아래는 참고한 자료입니다. 참고1) 컨플루언트 개발자 가이드 에 따르면 토픽은 KRaft일 때 수백만 개 생성 가능하다고 하지만 결국 각 토픽당 파티션 수에 따라 달진다고 언급하고 있습니다. 참고2) 컨플루언트 블로그 에 따르면 가용성을 고려하면 2,000~4,000개를 권장하고, 지연시간을 고려하면 100 × b × r (b: 브로커 수, r: 복제 팩터) 공식을 제안하고 있습니다. 그런데 10년 전에 작성된 글이라 현재는 더 많이 지원하지 않을까 싶습니다.
14:42 에서 Snowflake 알고리즘으로 articleId를 생성한 후 DB에 저장된 121530268440289280L값을 사용해서 테스트 코드를 작성하시는 것을 보고, 실제로 Snowflake를 도입해서 Id를 생성하고 같은 방식으로 테스트 코드를 작성한다면 DB에 종속적이라서 반복적으로 테스트 코드를 실행할 때 테스트 코드의 유지보수에서 문제가 발생할 수 있을 거라는 생각이 들었습니다. 이런 문제를 막기 위해서 테스트 시에는 Mock 객체를 사용해 미리 정해진 Snowflake가 고정 ID 값을 반환하도록 하는 방식으로 테스트 코드를 작성하는게 맞는건지 궁금해서 질문글을 남기게 되었습니다.
'25. 엔티티의 자연키 지정' 영상의 후반부에 적용한 @NaturalIdCache 에 대해 추가로 학습한 내용이, 저처럼 해당 애노테이션을 처음 접한 분들에게 도움이 될 것 같아서 글을 작성합니다. 강의에서 오해가 있을 수 있는 부분, 그리고 자연키에 캐시를 적용하는 방법을 정리해 보았습니다. 강의 내용과 실제 동작의 차이점 강의에서는 “같은 트랜잭션 안에서 같은 아이디 값을 가지고 여러 번 조회 시 Persistence Context 에 캐시된 값을 꺼내오는 것 처럼. @NaturalIdCache 를 적용하면 이것도 영속 컨텍스트에 캐싱이 된다.”고 말씀하셨습니다. 해당 내용에 대한 이해를 돕기 위해 Hibernate의 두 가지 캐시에 대해 간단히 짚고 넘어가겠습니다. 1차 캐시 (First-Level Cache): 세션(영속성 컨텍스트) 범위의 캐시입니다. 같은 트랜잭션 안에서만 유효하며, 트랜잭션이 끝나면 사라집니다. Spring Data JPA에서는 기본적으로 @Id 에 대한 조회를 1차 캐시합니다. 2차 캐시 (Second-Level Cache): 세션 팩토리 범위의 캐시로, 여러 세션에서 데이터를 공유할 수 있습니다. 적용하려면 별도의 의존성 추가 및 캐시 관련 설정( @Cache 등)이 필요합니다. 따라서, "같은 트랜잭션 안에서 캐시된 값을 꺼내온다."는 말은 세션 범위의 1차 캐시로 해석됩니다. 하지만 제가 직접 테스트해 본 결과, @NaturalIdCache 는 1차 캐시 가 아닌 2차 캐시 와 관련이 있었으며, 1차 캐시를 적용하기 위해서는 다른 방법이 필요했습니다. 테스트를 통한 확인 자연키에 대한 1차 캐시 동작을 확인하기 위해, 강의에서 적용한 Member 엔티티의 @NaturalIdCache 를 제거 하고, 자연키(Email)에 @NaturalId 만 적용 한 상황에서 두 가지 방식으로 테스트를 진행했습니다. 테스트1: findByEmail 메서드를 사용한 조회 @Test void NaturalIdFirstLevelCache() { Member member = Member.register(createMemberRegisterRequest(), createPasswordEncoder()); memberRepository.save(member); entityManager.flush(); entityManager.clear(); System.out.println("회원 저장 및 persistence context 초기화 완료"); // 같은 email(Natural ID)로 두 번 조회 Member findMember1 = memberRepository.findByEmail(member.getEmail()).get(); Member findMember2 = memberRepository.findByEmail(member.getEmail()).get(); assertThat(findMember1).isSameAs(findMember2); } Spring Data의 쿼리 메서드를 사용하여 이메일로 조회하는 findByEmail 메서드를 만들고, 한 트랜잭션에서 같은 회원을 두 번 조회했습니다. 자연키에 대한 1차 캐시가 동작한다면, SELECT 쿼리는 한 번만 실행되어야 합니다. 결과는 SELECT 쿼리가 두 번 실행 되었습니다. 즉, 자연키에 대한 1차 캐시가 동작하지 않았습니다. 테스트2: Hibernate의 자연키 관련 API를 사용한 조회 @NaturalId 를 다루는 글들을 찾아본 결과 Hibernate가 제공하는 자연키 관련 API가 있다는 것을 확인했고, 이를 적용하기 위해 커스텀 리포지토리를 구현했습니다. @Repository @RequiredArgsConstructor public class CustomizedMemberRepositoryImpl implements CustomizedMemberRepository { private final EntityManager entityManager; @Override public Optional<Member> findByNaturalId(Email naturalId) { return entityManager.unwrap(Session.class) .bySimpleNaturalId(Member.class) .loadOptional(naturalId); } } 그리고, 테스트 1과 같은 방식으로 테스트를 진행하였습니다. @Test void NaturalIdApi() { Member member = Member.register(createMemberRegisterRequest(), createPasswordEncoder()); memberRepository.save(member); entityManager.flush(); entityManager.clear(); System.out.println("회원 저장 및 persistence context 초기화 완료"); Member findMember1 = memberRepository.findByNaturalId(member.getEmail()).get(); Member findMember2 = memberRepository.findByNaturalId(member.getEmail()).get(); assertThat(findMember1).isSameAs(findMember2); } 결과는 SELECT 쿼리가 한 번만 실행 되었습니다. 이를 통해 자연키에 대한 1차 캐시는 @NaturalIdCache 애노테이션과 무관하게, 전용 API를 사용해야만 동작 하는 것을 확인했습니다. @NaturalIdCache의 용도 @NaturalIdCache Javadoc에는 다음과 같은 설명이 있습니다. Specifies that mappings from the natural id values of the annotated entity to the corresponding entity id values should be cached in the shared second-level cache. …중략 This annotation is usually used in combination with Cache , since a round trip may only be avoided if the entity itself is also available in the cache. 대략 “natural id와 상응하는 id에 대한 매핑을 2차 캐시에 저장 하는 애노테이션이고, 엔티티가 캐시되어있어야 하기 때문에 일반적으로 Cache 와 함께 사용 된다.”라고 해석됩니다. 즉, 1차 캐시가 아닌 2차 캐시를 위한 애노테이션입니다. 정리 2차 캐시 관련 설정 및 테스트를 마저 진행한 후 최종 정리한 내용은 다음과 같습니다. 자연키의 1차 캐시 @NaturalIdCache 애노테이션과 관련 없습니다. 자연키에 @NaturalId 만 붙이면 됩니다. 반드시 Hibernate Session의 bySimpleNaturalId() 같은 전용 API를 사용해야 적용 됩니다. 자연키의 2차 캐시 @Cache 와 @NaturalIdCache 를 함께 사용해야 동작합니다. @Cache 만 사용 시 @Id 로 조회할 때만 2차 캐시가 동작합니다. @NaturalIdCache 만 사용 시 자연키와 ID에 대한 매핑 정보는 캐시 히트 되는 걸 확인했지만, ID와 엔티티에 대한 캐시가 없어서 캐시가 적용되지 않았습니다. @Cache 와 @NaturalIdCache 모두 사용 시 ID를 통한 조회와 자연키를 통한 조회 모두 2차 캐시가 적용됩니다. 참고 자료 Hibernate6.6 공식 문서 NaturalCache javadocs baeldung: Hibernate Natural IDs in Spring Boot Spring Custom Repository 글의 오류나 부족한 내용을 알고 계신 분은 코멘트를 달아주시면 감사하겠습니다.
인라인 스타일 사용 시 style이라는 객체 prop이 매번 달라져 리렌더링이 발생한다고 해주신 부분 관련하여 질문드립니다 부모가 리렌더링되는 상황이라 이와 무관하게 자식의 리렌더링도 유발하게 될텐데요 자식 컴포넌트 자체에 memo를 적용하는 경우가 아니라면, useMemo를 쓰더라도 최적화 효과가 없을 것으로 보이는데 맞을까요?