A seeker after truth

지금까지는 비교적 단순한 모델링만 경험했던 것 같고, 무엇보다 본인이 주도적으로, 깊게 참여했던 적이 잘 없었는데 이번에 깊게 관여해보니 생각할 거리, 의문 거리가 한두가지가 아니었다 1:1, 1:N, N:M 관계란 것도 그 안으로 깊이 들어가면 얽혀있는 이론, 법칙들도 따로 있었던 데다 어떤 테이블은 뭘로 정의하지? 지금 얘랑 얘 간 관계는 어떻게 정의해두는게 좋을까? 외래키 제약 조건은 어떻게 하지? 라는 생각이 들때, 결정 기준이 될만한 것들에 대한 지식이 없었다는 문제가 있었다. 의문거리, 생각할 거리 예시로는 아, 지금 이 관계 이렇게 만들어 놔도 되는 건가? 이런 관계도 존재하나? 이 칼럼은 테이블 분리를 하는 게 맞나 안 하는게 맞나? 정규화 수준은 어디까지 고려해야 하지? 개발 업무 측면에..

미들을 구할 필요가 있는가? 해야함. 왜냐면 미들 하나 구해서 이걸 왼쪽, 오른쪽과의 크기 비교 한 뒤에 l, r 인덱스 값 조정에 이걸 써야 하기 때문임 최소값은, 배열 값들이 계속 증가하다가 확 바뀌는 지점이다. 음.. 맨 처음 if를 통과하지 못한 이상 이미 앞쪽 애들이 뒤쪽보다 큰 건 확실하잖아? 그래서 미들을 구해보는거지 얘가 증가구간에 있는 앤지 감소 구간에 있는 앤지 봐야 하잖아 난 미들을 계속 ..l, r 그 자체가 아니고 오른쪽 혹은 왼쪽 값에 대해 얼마를 더했거나 뺀.... 값으로 설정해보기로 했다 일단. 이 아이디어가 이상하다 생각이 들기도 하지만,.. 궁극적 최소값이 어떻게 구해지는가? 에 대한 아이디어가... 흠... 글고 m-nums[m] 이런 비슷한 것들 하는 과정에서 +1, ..

CI는 리눅스 등 로컬 OS 환경에서 뭘 할 수 없을 때, 검사하고 싶은 타 OS 에서 뭘 하고 싶은지 CLI 명령어 기반으로 정의 내리고 시키는 일이라고 생각한다. 대표적 툴인 github actions 의 문법이 공식 문서에 정리돼있다: https://docs.github.com/en/actions/using-workflows 검사 속도를 빠르게 하는 캐싱에 관한 건 여기 정리돼있고 https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows 최종 프로젝트 환경 구성에선 이 레포에 나오는 내용을 참고해 설정했다: https://github.com/actions/cache 또 feature/**..

보호되어 있는 글입니다.

보호되어 있는 글입니다.