from airflow import DAG 2import pendulum 3import datetime 4from airflow.operators.python import PythonOperator 5import random 6import time 7 8with DAG( 9 dag_id="shedule_3_hour", 10 schedule="3 * * * *", 11 start_date=pendulum.datetime(2023, 3, 1), 12 catchup=False 13) as dag: 14 def select_fruit(): 15 fruit = ['APPLE','BANANA','ORANGE','AVOCADO'] 16 rand_int = random.randint(0,3) 17 time.sleep(10) 18 print(fruit[rand_int]) 19 20 py_t1 = PythonOperator( 21 task_id='py_t1', 22 python_callable=select_fruit 23 ) 24 25 py_t1 Airflow Webserver UI DAG Detail페이지에 있는 내용 중 Next dagrun ~ 관련 항목이 이해가 안돼서 질문드립니다. UTC 기준 10:34입니다. 설명 편의를 위해 현재시간으로 지칭하겠습니다! Next dagrun이 2024-10-06T10:03:00+00:00 값을 가지는 이유가 궁금합니다. Next dagrun이 다음 DAG 실행 예정 시간인거같은데 왜 현재실행 보다 과거인지 모르겠습니다. 2024-10-06T11:03:00+00:00이 맞는거 같아서요. 현재 시간이 10:34이고 3분마다 실행. 10:03은 실행완료. 이후 11:03에 실행되어야함. Next dagrun create after : 다음 DAG은 11:03에 실행되어야하므로 11:03에 DAG Run 생성 (11:03에 실행하는) DAG 기준으로 처리해야하는 데이터 범위는 10:03~11:03이므로 Next dagrun data interval end는 11:03, Next dagrun data interval start는 10:03. (1) Next dagrun 관련 항목의 정확한 의미와 Next dagrun과 Next dagrun create after 차이를 정확히 몰라서 생기는 문제 같기도 합니다. (1-1) Next dagrun 관련 항목의 의미 아래 내용이 맞는지 확인 부탁드립니다! - Next dagrun: 다음 DAG 실행 예정 시간 Next dagrun create after: 다음 DAG 생성 예정 시간 Next dagrun data interval end: 다음 DAG 데이터 간격 종료 시간 Next dagrun data interval start: 다음 DAG 데이터 간격 시작 시간 (1-2) Next dagrun과 Next dagrun create after 차이 Next dagrun 과 Next dagrun create after 은 항상 같나요? Next dagrun create after는 정해진 시간에 생성되고(3분 마다) Next dagrun 은 Next dagrun create after이후에 되는데 즉, DAG run이 생성되고 실행되는거 맞나요? (Airflow 공식 문서에 Web UI에 있는 항목별 의미를 알 수 있는 페이지가 있는지 찾아보았는데 없어서 질문드립니다! 아래 링크보면 Airflow UI 설명은 간단하게 있는데 항목별 설명은 없네요...) https://airflow.apache.org/docs/apache-airflow/stable/ui.html )
나만의 앱 실행파일(.exe)로 만드는 방법 강의 까지 착실히 따라ㅇ해봤는데요, 마지막 exe파일 만들떄오류가 났습니다. pyinstaller -w -F 03.네이버지식인GUI.py 위 명령어 치고 나서, 아래와 같은 오류가 나왔고요. 제가 챗gpt에 오류를 검색해보니 PyQt6 또는 PySide6 둘중하나를 제거하면 되는거같은데.. 이렇게 지워보면 될까요? Aborting build process due to attempt to collect multipl e Qt bindings packages: attempting to run hook for 'PyQt6', while hook for 'PySide6' has already been run! PyInstaller does not support multiple Qt bindings packages in a frozen application - either ensure that the build environment has only one Qt bindings package installed, or exclude the extraneous bindings packages via the module exclusion mechanism (--exclude command-line option, or excludes list in the spec file).
Dynamic Page로 설정되는 기준 중에서 동적 함수(쿠키, 헤더, 쿼리스트링)을 사용하는 컴포넌트가 있을때가 있다고 말씀해주셨습니다. 그리고 웬만하면 Static Page로 만드는 것이 성능 측면에서 좋다고 하셨습니다. 하지만 예를 들어, 거의 모든 페이지에서 header나 footer 컴포넌트를 공통 컴포넌트로 쓰고있고, 그 컴포넌트에서 쿠키를 통해 어떤 값을 세팅한다면 Static Page는 거의 없을 것으로 판단이 되는데 따로 해결방안이 있을까요? Dynamic Page로 설정되는 기준 중에서 아래와 같이 캐시되지 않는 data fetching을 사용하는 경우가 있다고 하셨는데 async function Comp() { const response = await fetch('...') return <div>...</div> } async function Comp() { const response = await fetch('...', {cache : "no-store"}) return <div>...</div> } 아래와 같이 revalidate로 캐시 옵션이 세팅되었을때는 Static Page로써 적용이 되는 것이지요? 그 이유가 해당 time이 지났을때는 데이터캐시에 있는 값이 stale되었다고 판단이 되어 캐싱되어있는 값을 가져오지않고 새로운 값을 가져오기 때문이라고 보면 되는걸까요? async function Comp() { const response = await fetch('...', { next: { revalidate: 3 } }) return <div>...</div> }
안녕하세요! 이번에 금융권 핀테크 기업으로 이직하면서 강화학습을 직무에 활용할 수 있을까하여 공부하고 있는 사람입니다. import gymnasium as gym import numpy as np import pprint # SFFF (S: 시작점, 안전) # FHFH (F: 얼어있는 표면, 안전) # FFFH (H: 구멍, 추락) # HFFG (G: 목표, 프리스비 위치) # LEFT = 0 # DOWN = 1 # RIGHT = 2 # UP = 3 map = "4x4" SLIPPERY = False # 결정론적 환경 #SLIPPERY = True # 확률적 환경 # FrozenLake-v1 환경을 생성합니다. # desc: None이면 기본 맵을 사용합니다. # map_name: 사용할 맵의 이름을 지정합니다. # is_slippery: True이면 미끄러운 표면(확률적 환경)을 사용하고, False이면 결정론적 환경을 사용합니다. env = gym.make('FrozenLake-v1', desc=None, map_name=map, is_slippery=SLIPPERY) GAMMA = 1.0 # 감가율 (discount factor), 미래 보상의 현재 가치 THETA = 1e-5 # 정책 평가의 종료 조건, 변화가 이 값보다 작으면 평가 종료 num_states = env.observation_space.n # 환경의 상태(state) 개수 num_actions = env.action_space.n # 환경에서 가능한 행동(action) 개수 transitions = env.P # 상태-행동 전이 확률 (state-action transition probabilities)s) 강의로는 36강, 자료로는 015_DP_frozenlake_policy _evaluation.p y 상에서 질문이 있습니다. 여기서 THETA가 1E-5인데, 이는 정책 평가의 종료 조건이라고 되어있었습니다. 이 때, 모든 그리드에서의 변화량 중 단 하나의 값이라도 THETA보다 작아지면 평가가 종료되는 것인지, 모든 그리드의 변화량이 THETA보다 작아지면 평가가 종료되는 것인지 궁금합니다.
spring boot, jpa, junit5, testcontainers를 이용해서 테스트 코드를 작성하고 있습니다. 총 12개의 테스트 클래스를 만들었고 각 클래스마다 testcontainers 객체를 static으로 가지고 있고 모두 @SpringBootTest, @Testcontainers 어노테이션만 추가했습니다.(Controller 테스트 시 @AutoConfigureMockMvc 어노테이션 추가) jpa의 ddl-auto 값을 create-drop으로 설정했기 때문에 gradle test를 실행할 때 예상되는 결과는 각 클래스를 테스트할 때마다 테이블이 새로 생성되어야 할 것 같은데 실제로는 총 2번 생성됩니다. 각 클래스마다 Testcontainers를 적용했음에도 불구하고 실패한 로그를 보면 이전 클래스에서 사용한 데이터를 다음 클래스에서도 사용하는 것처럼 보이는데 테스트 실행 시 각 테스트 클래스마다 jpa의 ddl-auto 속성이 동작하지 않는 이유 각 클래스에 Testcontainers를 적용했음에도 불구하고 생성된 데이터베이스가 컨테이너들이 공유하는 이유 가 궁금합니다.
junit5, jpa를 이용해서 테스트 코드를 작성하고 testcontainers를 이용해서 테스트를 수행하려고 합니다. A entity는 n개의 B entity를 가지고 있고, B entity는 C entity를 가지고 있습니다. A에 관련된 테스트 클래스, B에 관련된 테스트 클래스(A entity 이용), C에 관련된 테스트 클래스(A, B entity 모두 이용)를 클래스별로 각각 테스트를 진행하면 모두 정상적으로 통과합니다. 하지만 gradle test로 전체 클래스에 대해서 테스트를 진행하면 종종 실패합니다. 로그를 확인했는데 C 클래스를 테스트하면서 db에 A, B, C 데이터가 insert됐고 이어서 B 클래스를 테스트할 때 @BeforeAll로 B, A 순서로 데이터를 삭제하는 과정에서 C 데이터가 남아있기 때문에 B 데이터를 삭제할 수 없어 테스트가 실패합니다. 이해하기로는 testcontainers가 각 클래스에서 static으로 선언되면 테스트 시작 시점에 컨테이너가 생성되어 순수한 상태의 db로 테스트를 진행할 수 있고 테스트가 끝나면 컨테이너가 삭제되어 db도 자연스럽게 초기화된다고 생각했는데 실제로는 하나의 db를 여러 개의 container가 공유해서 사용하는 것처럼 보입니다. 컨테이너 생성이 db의 생명주기에 영향을 주나요?
getServerSideProps 함수 내부에서 context.query.q로 데이터를 불러오는데, 이러한 querystring을 활용하는 요청 또한 사전 렌더링으로 처리를 할 수가 있나요? 초기 접속 요청(인덱스 페이지)에서 서버는 유저가 querystring을 입력하기 전까지는 querystring의 값을 모르지 않나요? 어떻게 context.query.q도 사전 렌더링의 SSR 방식으로 처리를 할 수가 있나요?
img 태그를 사용할 때처럼 이미지 사이즈를 따로 작성하지 않고 그 공간의 크기에 따라 자동으로 이미지 사이즈가 적용되는 방법은 없을까요? 예를 들어 화면이 줄어들면 리스트 아이템들도 사이즈가 줄어들어 이미지 사이즈도 자동으로 줄어들게 되는 것처럼 그 부모에 맞춰(이때 부모도 사이즈 고정x) 사이즈가 자동으로 변하도록 하는 방법이 있는지 궁금합니다
이진석 강사님 안녕하세요, 올려주신 Django 강의를 차근 차근 따라가며 즐겁게 학습하고 있습니다. 작성해주신 코드에 대한 동작 원리를 이해하려고노력하면서 수강하고 있습니다. 그 과정에서 작성하신 코드의 동작 원리에 관련해서 궁금한 게 있어서 이렇게 질문 드려요 🙂 11-10 강의에서 SignupForm 모델 폼에서 clean_email(self) 메서드를 정의하여 입력 받은 email 값에 대한 유일성을 검사하는 코드 관련해서 궁금한 점이 있습니다. 정의한 clean_email(self) 메서드는 언제 django 내부에서 호출되는지 궁금합니다. 폼의 is_valid() 메서드를 통과한 이후에 self.cleaned_data 인스턴스 변수에 사전으로 값이 담긴 이후에 호출되는 걸로 이해했는데 맞을까요? return 값으로 email 변수 하나만 넘겨주게 구현이 되어 있는데요. email 변수만 반환하는데, email 변수에 담긴 cleaned_data 인스턴스 변수 값이 반환 된 이후에 Django 내부적으로 어떻게 처리 되는지 궁금합니다. UserCreationForm 클래스에 clean_username(self)가 정의되어 있던데요. def clean_{field_name}(self) 의 형태로 제가 원하는 필드에 대해서 추가로 유효성 검증 로직을 구현하고 싶을 경우, 위와 같은 형태로 메서드를 추가로 정의해서 코드를 구현하면 되는 거로 이해했는데 제가 제대로 이해한 건지 궁금합니다. 감사합니다!
