한결과 레지아이스

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

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

영어 단어 Stack은 무더기, 더미를 의미합니다. 자료구조에서도 같습니다. 선형 자료구조의 하나로, 데이터의 더미를 의미합니다. 근데 무언가의 더미라는 건 어떤 특성을 가질까요? 박스 더미를 생각해보면, 우리는 기존에 놓인 박스 위에 새로운 박스를 얹습니다. 밑에 얹을 수는 있지만 잘 그러지 않지요. 박스를 가져갈 땐 맨 위부터가 가져갑니다. 역시 밑에서부터 가져갈 수는 있지만 잘 그러지 않지요. 자료구조에서도 비슷합니다. 데이터를 쌓는데, 먼저 들어온 것들을 밑에 두고 새로운 것이 항상 맨 위에 쌓이는 구조를 스택이라고 합니다. 스택에 접근할 때는? 가장 위의 데이터에 접근이 되겠죠. 저는 ‘뭐야? 배열로, 리스트로 어디에도 접근을 잘하고 있었는데 이런 귀찮은 것은 왜쓰는겨??’ 라는 생각을 했었습니..

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