에어플로우 설치 중 오류가 발생해 오랜시간동안 재시도해보다가 질문 드립니다.! 아래의 오류들에 대한 원인이 무엇일지, 그리고 어떻게 해결해야 할지 궁금합니다. 1. sudo docker compose up airflow-init 해당 코드 실행 중 'The container is run as root user. For security, consider using a regular user account.' 라는 알림이 나오며, 사용자-airflow-init-1 이 아닌 airflow-init-1로 뜹니다. sudo docker compose up 해당 코드 실행 중 'airflow-apiserver-1 is unhealthy'라는 오류가 발생합니다. (이 문제로 도커 초기화 및 재설치부터 고유한 user secret key 입력 등 여러번 시도했으나, 동일한 오류가 계속 반복됩니다.) 참고로, sudo docker compose up 코드 실행 중 다음과 같은 오류들이 주로 보입니다. airflow-apiserver-1 | ValueError: The value api_auth/jwt_secret must be set! airflow-apiserver-1 | ERROR: Application startup failed. Exiting. airflow-apiserver-1 | ERROR: Traceback (most recent call last): airflow-apiserver-1 | INFO: Child process [3223] died
안녕하세요! 캡슐화 추가 설명 강의 중 궁금한 것이 있어 질문 드립니다. 상위 모듈인 app 모듈의 providers에서 하위 모듈들의 service나 repository를 주입 받아 사용하게 되면 다음과 같은 문제가 있다고 하셨습니다. 모듈들의 관리가 힘들어진다. 단일책임원칙이 깨진다. 추가적인 학습으로 알게된 1번에서 발생할 수 있는 문제는 다음과 같습니다. -상위 모듈의 providers에서 인덱스 순서대로 service를 불러 오기 때문에 만약 하위 클래스끼리의 의존성이 존재한다면, 그 순서를 관리해줘야 되는 복잡성이 발생한다 . 순환참조 또한 일어날 수 있다. 하지만 2번 단일책임원칙이 깨진다는 문제점이 발생한다는 것은 아직 이해하지 못했습니다. app 모듈안에서 다른 클래스들의 기능을 사용할 때 참조하는 방식이 잘못된 것이지, 해당 클래스의 기능의 책임이 확장된 것은 아니라는 생각이 듭니다. 여전히 기능의 변경이 일어났을 때 해당 클래스만 수정하면 된다고 생각하기 때문입니다. 제 이해가 잘못된 것인지, 강사님께서 SRP원칙의 의미를 조금 더 확장해서 말씀해주신 것인지 궁금합니다!
집합(SET) 활용하여 차집합 개념은 잘 이해했습니다. a-b 가 존재할 경우 레이블 인코딩 하면 문제가 없는 것 b-a 존재할 경우 학습시 b에 존재하는 컬럼이 인코딩이 안되는 문제! 이럴 경우엔 axis=0(열)로 합해서 인코딩 후 다시 분리하는 방법이 있다고 하셨는데 그렇게 하지않고 인코딩 할때 fit을 b(test) 로 하고 트랜스폼을 a(train)으로 하면 무슨 문제가 발생할까요?
학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! 질문과 관련된 영상 위치를 알려주면 더 빠르게 답변할 수 있어요 먼저 유사한 질문이 있었는지 검색해보세요 책은 따로 구매하지않고 강의만 보고 진행할 생각인데 그럼 책에 있는 미션일 경우 그냥 끝이나는 건가요? 아니면 문제는 제공되나요?
안녕하세요. 리액트 초보입니다. 이해하기 쉽게 설명해주셔서 감사합니다. 11.3) Context 분리하기 강의 약 7분 쯤에서 궁금한 부분이 있어서 질문 남깁니다. <TodoDispatchContext.Provider> 를 통해 context를 전달할 때, 함수를 캐싱하기 위해 강의에서는 아래와 같이 useMemo를 사용해주셨는데요! const memoizedDispatch = useMemo(() => { return { onCreate, onUpdate, onDelete }; }, []); 우선 최적화하고자 한 이유는 아래와 같다고 이해했습니다. onCreate, onUpdate, onDelete 모두 한 번 생성한 후에 바뀌지 않는 함수로, TodoDispatchContext를 참조하는 자식 컴포넌트들의 리렌더링 방지 그리고 useMemo를 사용하신 부분에서는 마운트 후 onCreate, onUpdate, onDelete는 변하지 않는 함수 이므로 "값을 캐싱한다"는 의미에서 useMemo를 사용해주셨다고 이해했습니다. 다만 useCallback도 mount 후 deps 변경 전에는 함수의 중복 생성을 방지한다는 점에서는 useCallback을 사용해도 좋을 것 같단 생각이 들었는데요, 결론적으로 제가 궁금한 부분은 아래와 같습니다. useMemo 대신 useCallback을 사용해서도 동일하게 최적화 할 수 있다고 이해했는데, 제가 이해한 게 맞을까요? 1번이 맞다면 강의에서 useMemo를 사용해주신 이유는 캐싱하기 위함(의도)을 표현하기 위함이라고 이해하면 될지도 궁금합니다! 실무에서는 useMemo와 useCallback을 모두 사용할 수 있는 경우 어떤 훅을 선택하시는지, 강의에서 useMemo를 통해 캐싱하신 이유가 궁금했습니다 ! 블로그를 찾아봐도 잘 이해가 되지 않아서 질문으로 남깁니다! 답변 주시면 감사하겠습니다!
n = int(input()) c = [] for _ in range(n): b = int(input()) c.append(b) def DFS(L,first,second,third): global best a = max(first,second,third) - min(first,second,third) if a >= best: return if L == n: if a < best: best = a else: for i in range(n): if ch[i] == 0: ch[i] = 1 DFS(L+1,first+c[i],second,third) DFS(L+1,first,second+c[i],third) DFS(L+1,first,second,third+c[i]) ch[i] = 0 ch = [0] * n best = 10000000000000 DFS(0,0,0,0) print(best)
문제에 대한 정리가 필요해 질문 남깁니다. 결국 문제는 1명, 2명, 3명 이렇게 차례대로 모였을 때 1명 모이면 이동거리 최소 이동 거리 합 : n1 2명 모이면 이동거리 최소 이동 거리 합 : n2 n명 모이면 이동거리 최소 이동 거리 합 : nn 이런 최소값을 원하는 문제인거죠? 그래서 1번 아이디어로 구현 했을 경우에는 모든 좌표에 대해서 1명 모일 때 , 2명 모일 때 반복하면서 모든 경우의 수를 찾아가는 가는 방법이고 2번 아이디어의 경우는 모든 좌표를 볼 필요 없이 각각의 집 좌표만 보면 된다라는 생각을 해서 각각의 집 좌표로 비교해서 경우의 수를 찾는 방법이고 3번 아이디어는 각각의 집 좌표들을 모두 비교할 필요 없이 정렬 후 인원의 수 만큼 돌면서 작은 값이면 바꿔준다 방법이고 이런 느낌으로 접근을 한게 맞는 걸까요?
