Go Gradually - Repository

문제가 되는 비즈니스 로직일정 간의 사이클 검사Dependency는 from/to 두 개의 schedule을 알고 있다.CycleChecker는 그 중 indegree가 0인 임의의 schedule을 잡고, 의존관계를 탐색하며 사이클이 존재하는지를 파악한다.일정 삭제일정 삭제 시, 해당 일정을 알고 있는 모든 의존관계를 제거한다.즉, Dependency 추가와 삭제 모두 관련된 모든 일정이 관리한다.이전 일정이 완료되었는지 확인일정은 이전 일정을 직접 알고있지 않다.Dependency라는 엔티티를 거쳐서 알고 있다.from.isCompleted()로 사전 완성 일정 체크 일정 간의 사이클 검사일정 간의 사이클 검사에는 Schedule 정보가 필요하지 않다.따라서, ownerId로 해당 사용자의 모든 연관..

필자는 사내 정치에 대한 개인적인 기준을 세워두지 못한 상태였다.이 상태에서 다양한 기업에서 면접을 진행하며, 해당 부분에 대한 면접 질문이 들어왔을 때, 깔끔하게 대답할 수 없었다. 그런데 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식(최범균 著) 도서에 대해 내용을 학습하면서, 중요한 인사이트를 얻을 수 있었다. 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 | 최범균 | 한빛미디어 - 예스24실무에서 자주 겪는 다양한 문제를 효과적으로 해결하는 법서비스 환경에서는 커넥션을 닫지 않아 서버가 멈추고 외부 API의 지연이 전체 장애로 번지며 사소한 설정 실수가 사용자 전체에 영향www.yes24.com 새로 추가할 쿼리가 기존에 존재하는 인덱스를 사용하지 않을 때에는 요구사항을 일부 변경..

필자는 개발보다 알고리즘을 먼저 접했기 때문에, 휴리스틱한 기법보단 증명을 통한 완벽한 계산에 익숙했다.하지만 최근 직접 서비스를 개발해보고, 다양한 AI-ML 알고리즘을 접하기도 하며 휴리스틱과 근사 방법에 어느정도 익숙해지면서, "엄밀한 증명"만 생각하던 상태에서 벗어나게 되었다.이 과정에서 자연스럽게 "Exact 알고리즘"과 "휴리스틱 알고리즘"의 분류 기준을 생각하게 되었다. Exact 알고리즘정확한 답이 증명으로 보장된 알고리즘 휴리스틱 알고리즘정확한 답이 아니더라도, 정확한 답 수준의 풀이를 반환하는 알고리즘원래의 정의는 이렇지만, 이 정의는 실무에서 알고리즘을 선택하는데에는 약간의 미흡함이 있다고 생각했다.따라서 정의를 다음과 같이 약간 수정했다. Exact 알고리즘정확한 답이 증명으로 보장..

일정 도메인일정 타입집중 작업행정 작업(이메일 회신, 전화, 짧은 보고, 회의 준비)짧은 업무(유지관리 활동, 운동, 청소, 정리, 일기 쓰기)일정 중요도(1~10)일정 예상 소요시간일정 마감 일자현재 일정 상태고정된 일정 여부일정 관계 도메인이전에 마쳐야 하는 일정이후에 수행해야 하는 일정사용자 도메인아이디닉네임수면 시간식사 시간쉬는 날이번주 총 집중 시간이번주 총 업무 시간

본 목록은 일정 관리 제품 "PinIt"의 Use Case로, 핵심적으로 구현해야 하는 필수 기능부터 제품의 특색을 살리는 부가기능까지의 기능 구현 우선순위를 기준으로 1, 2, 3순위로 나타낸 Use Case이다. 1순위일정 추가기능사용자는 일정 추가 버튼을 클릭하여 일정 추가 창을 연다사용자는 그 안에 다음을 입력한다.일정 이름일정 타입일정 마감일자일정 중요도일정 예상 시간이전에 수행해야 하는 일정이후에 수행해야 하는 일정사용자는 일정 자동 배치 버튼을 클릭할 수 있다.시스템은 추천 일정 배치일자를 결정한다.시스템은 입력값을 검증한다.시스템은 입력받은 대로 DB에 일정을 추가한다.사후조건사용자가 일정 배치를 수행하지 않았을 경우, 일정 추가를 선택한 날짜에 해당 일정을 추가한다.일정이 DB에 추가되..

다양한 알고리즘의 고민이전 글에서 이것 저것 수행해보고 난 뒤, 좀 더 다양한 기법들에 대해 트레이드오프를 이해할 필요성을 느낀 나는 다양한 알고리즘을 공부했다. 하지만 이번 MountainCar 환경에서는, 결국 DQN으로 다시 회귀할 수밖에 없었다.그 근거는 다음과 같다.나는 최근 다양한 정책 경사 알고리즘들을 공부해왔는데, 각 알고리즘은 해결하고자 하는 문제가 현재 MountainCar 의 상황과 맞지 않았다.하이퍼파라미터 튜닝은 예술의 영역이고, 숙련자들 또한 기존에 푼 문제와 논문에 존재하는 하이퍼파라미터를 참고하여 하이퍼파라미터를 설정한다는 것을 확인했다. REINFORCEREINFORCE는 가장 기초적인 Policy Gradient Method로, 다음과 같은 이점과 한계를 갖고 있다.이점정..

https://gymnasium.farama.org/environments/classic_control/mountain_car/ Gymnasium DocumentationA standard API for reinforcement learning and a diverse set of reference environments (formerly Gym)gymnasium.farama.org 요구사항 정의Mountain Car MDP는 사인곡선의 바닥에 확률적으로 배치된 자동차로 구성된 결정론적 MDP이다.가능한 동작은 자동차에 양방향으로 적용할 수 있는 가속뿐이다. 이 MDP의 목표는 오른쪽 언덕 꼭대기의 목표 상태에 도달하기 위해 자동차를 전략적으로 가속하는 것이다.Mountain Car Continuous ..

아무 생각 없이 import torch 를 수행하면서 pip install torch를 실행시켰는데,이를 수행하니 파이토치가 GPU를 사용할 수 없었다. 추가적인 정보를 확인해보니, 전용 pytorch를 설치해줘야 GPU 사용이 가능했다.먼저 해당 링크에 접속해준다. Get StartedSet up PyTorch easily with local installation or supported cloud platforms.pytorch.org 해당 링크에서 자신의 컴퓨터와 cuda 설치 정보와 맞는 pytorch를 찾아, 해당 Run this Command를 쉘에서 실행시켜준다.cuda의 경우 최신 버전이 출시되더라도, pytorch는 그 버전을 stable로 지원하기까지 좀 시간이 걸린다.물론 Nightl..

데이터베이스 + ACID 소실항상 트랜잭션의 ACID 소실을 의심해라.컨트롤러에서 서비스 메소드 두번 호출하는 상황이 발생하면, 진짜 이래도 되는지 검사해라.서비스에서 여러 데이터를 받아서 DTO로 변환하면, 버전의 불일치 문제가 발생한다.서로 다른 저장소 간 관계있는 데이터를 사용할 땐, ACID 소실 문제에 주의하자.서로 다른 저장소에서 데이터를 조회하다보면, 일관된 버전이 보장되지 않는다.락/버전 관리/오프라인 동시성 문제 해결 도구 등을 이용해 함께 동시에 버전을 일치시키지 않는 한, 반드시 원자성/일관성/고립성 문제가 발생한다.이벤트는 원자성 발행에 조심하라.커밋이 안되면, 이벤트는 발행되지 않아야 한다.트랜잭션 아웃박스 패턴 혹은 TransactionalEventListener를 사용하라.Ex..

코드의 우아함을 신경쓰다보면, 코드 한줄을 짜더라도 이게 잘 구조화된 코드인가 하고 한참을 고민하게 되는데, 이게 좋은 방식인가?그렇다고 아무렇게나 막 짜니, 코드가 지저분해지고 리팩토링하긴 무서워진다.그래서 TDD를 학습했다.후기TDD 적용 방법먼저, 요구사항을 제대로 이해하자.TDD로 일단 돌아가게 만들고, 중복을 제거하자.삼각측량 기법을 적극 활용하자.모든 중복을 제거하기 전까진 테스트 코드를 통과한 것으로 치지 말자.리팩토링을 수행하지 않으면, 단편적인 기능 구현의 연속만 하게되고, 결과적으로는 유지보수하기 어려운 '단순하고 파편화된' 코드 덩어리가 만들어진다.탑다운/바텀업 둘중 하나가 정답은 아니다.막힐때마다 TDD도 해보고, OOD도 해보고 번갈아가며 접근해야 한다.한가지 방식에 얽메이지 말기..