한결과 레지아이스

42GG 백엔드 시퀀스 다이어그램 2부입니다. 이번 글은 정보 전달이라기보다는 기록에 의미를 두고 작성하게 되었습니다. 백엔드에서 사용한 컨트롤러가 이것뿐이지는 않지만, 구현할 때 애를 먹거나 단순 조회가 아니고 무언가 로직이 들어간 부분들에 대해서 정리해 보았습니다. 개인적으로는 로직도 중요하지만 어떤 예외 처리를 어떤 이유로 했는지도 꽤나 많이 배우게 된 부분입니다. 로직을 만드는 것은 누구나 고생한다면(혹은 하지 않아도) 만들 수 있지만, 서비스로서 원활히 돌아가게 하기 위해선 수많은 예외 상황들을 생각하고 이에 대해 적절한 처리를 해줘야 한다고 느꼈습니다. 사실 저희 서비스에서 로직은 어려운 부분도 아니고 누구나 비슷하거나 어쩌면 다른 더 나은 방식으로도 비슷한 결과를 낳도록 구현하는게 어렵지 않..

42GG 서비스를 개발하며 스케쥴러를 사용하고, 그 과정에서 추상 클래스를 처음 만들어본 경험을 적은 글입니다. 우리 서비스엔 총 4개의 스케쥴러가 존재한다. 우리 서비스를 제공하는 2시에서 5시 사이에 각 5분, 10분 간격으로 돌아가는 스케쥴러 하나씩, 그리고 매일 한 번씩 실행되는 스케쥴러가 두 개 해서 총 네 개이다. 이런 스케쥴러를 어떤 방법으로 만들었는지, 그리고 처음에는 하나였던 스케쥴러가 네 개로 늘어나며 어떻게 추상 클래스를 구성하게 되었는지 설명해보려 한다. 스케쥴러 우리 서비스는 매일 일정 숫자의 게임 슬롯을 생성한다. 그리고 매 5분 간격으로 슬롯이 꽉 찼는지 여부에 따라 잠시후 매치가 시작된다는 알림을 보낸다. 10분 간격으로는 게임이 성사되었는지 여부에 따라 취소되었다는 알림, ..

우리 프로젝트에 정식으로 멘토님이 배정되거나 한 것은 아니었지만, 오며가며 많은 조언을 주시고 도움을 아끼지 않아주신 이호준 멘토님이 계십니다. 저희 프로젝트 팀에 관심을 많이 가져주시고 도와주셔서, 그리고 좋은 기회까지 주셔서 이 자리를 빌어 크게 감사의 마음을 전하고 싶습니다. 이호준 멘토님 왕감사합니다! 시퀀스 다이어그램은 전적으로 멘토님께서 제안해주셔서 그려본 것입니다. 설계 단계에서 미리 그리고 시작했다면 더 좋았겠지만, 개발 단계에서 그렸는데도 큰 도움이 되었기에 포스팅을 하게 되었습니다. 로그인 시퀀스 우여곡절 끝에 개발된 로그인 시퀀스이다. 42서울 내부에서만 사용할 계획이었고, 구성원들만 이용할 수 있는 탁구대에 대한 서비스였기 때문에 42OAuth를 통한 로그인만 구현했다. 아직 구현되..