프로젝트 (19) 썸네일형 리스트형 [디베이트 타이머 - 5차 스프린트] 2차 유저 테스트와 디자이너 합류 안녕하세요 브로콜리입니다. 디베이트 타이머 팀은 현재 Phase 1 - 의회식 타이머 기능 개발을 모두 마치고 현재 Phase 2 로 접어들고 있습니다.디자이너 분의 합류로 뷰 개선과 더불어 시간총량제 타이머 개발, 그리고 실 유저 모집을 위한 콜메일이 주요 태스크가 될 것 같습니다. 오늘은 2차 유저 테스트에서 나온 의견을 정리해보려 합니다. 1. 테스트 대상토론 강의를 진행하셨던 분을 대상으로 테스트를 진행하였습니다.: 약 1년 반 이상의 토론 강의 경험 보유: 토론 교육기관에서 학생들을 대상으로 토론 강의 및 자료 제작 경험2. 테스트 방식 테스트 방식은 지난 1차 UT와 동일한 방법으로 대상자가 토론 사회자가 되어 토론을 진행하는 방식을 유지했습니다. 다만 이번에는 키보드 조작 및 테이블 수정하기.. [디베이트 타이머 - 3차 스프린트] Backend 기초 인프라 세팅하기 디베이트 타이머 3차 스프린트의 막바지에는 인프라 세팅 과정이 필요했습니다. 기존에 습득했던 인프라 관련 지식들을 복습할 겸, VPC를 세팅하는 처음부터 EC2 + RDS + https 세팅까지 작업해주었는데요. 오늘은 그 세팅과정에 대해 차근차근 소개해보고자 합니다. 목표 인프라세팅하고자 하는 인프라 환경은 다음과 같습니다. 가장 간소화한 인프라 환경 입니다. 그럼 디베이트 타이머 인프라 세팅의 A-Z까지의 과정을 소개해보겠습니다. 목차1. VPC - Subnet 설정하기 1-1) VPC 생성하기 1-2) Subnet 생성하기 1-3) 인터넷 게이트웨이 생성하기 1-4) 라우팅 테이블 연결하기 2. EC2 생성 및 EIP 설정 2-1) EC2 생성하기 2-2) EIP .. deleteAll vs deleteAllInBatch : 성능차이 + 영속성 컨텍스트 반영여부 SimpleJpaRepository에 구현된 deleteAll을 보면 내부적으로 엔티티를 하나씩 순차적으로 돌면서 delete() 메서드를 호출하고 있습니다. 이말은 즉슨 엔티티의 개수만큼 delete 쿼리가 나가게된다는 것을 의미합니다.문제 상황 : deleteAllInBatch를 사용한 메서드 테스트 오류 디베이트 타이머 1차 스프린트의 주요 내용은 디베이트 시간표와 시간표를 구성하는 타임박스들의 CRUD를 구현하는 것이었습니다. 그중 의회식 토론 테이블의 삭제 로직을 구현하는 과정에서 더 나은 성능을 위해 deleteInBatch 메서드를 사용했습니다. @Transactional public void deleteTable(Long tableId, Member member) { .. CI 과정에서 jacoco를 활용한 테스트 커버리지 확인하기 안녕하세요 브로콜리입니다. 프로젝트를 진행하며, CI 스크립트를 맡게 되었습니다. CI 과정에서는 작성한 테스트가 모두 통과하는지 검증해 품질이 보장된 코드가 merge되도록 하였습니다. 그러나, 단순히 테스트의 결과를 검증하는 것은 테스트 결과를 보장할 뿐입니다. 오히려, 코드가 통합되는 과정에서는 다음과 같은 질문이 중요할 수 있습니다.- 내가 작성한 코드를 검증할만한 테스트를 작성하였는가?- 팀의 전반적인 테스트 커버리지는 어느정도 되는가? 그리고 이렇게 테스트에 대한 커버리지 컨벤션을 확인할 수 있도록 도와주는 것이 바로 jacoco 라이브러리입니다. 오늘은 CI 과정에서 테스트 커버리지를 검증하기 위해 사용했던 jacoco의 설정부터 CI 스크립트에 적용한 과정까지를 기록으로 남겨두고자 합니다... JsonDeserializer 커스텀으로 외부 API 에러 핸들링하기 Situation : 에러에도 200을 응답하는 외부 API 지각 방지 서비스 오디에서는 A지점에서 B지점까지의 대중교통 소요시간을 측정하기 위해 ODsay API를 활용하였습니다. 외부 API를 활용하면서 외부 API에서 에러를 반환하는 상황에 대한 핸들링도 자연스레 신경을 써야했습니다. 처음에는 자연스레 ResponseErrorHandler를 만들어서 해결하려 했습니다. 밸덩 글에 수록된 ResponseErrorHandler의 예시를 보겠습니다.@Componentpublic class RestTemplateResponseErrorHandler implements ResponseErrorHandler { //에러인지 판단 @Override public boolean hasError(C.. [디베이트 타이머 - 1차 스프린트] 코드 & Git 컨벤션 정하기 이 글은 지난 1차 OT 이후 글 이후의 과정을 담았습니다. 지난 1차 OT에서 각 파트의 프로젝트 요구사항으로 지정했던 것은 코드 컨벤션과 Git 전략에 대한 서술이었습니다. 코드 컨벤션 : 코드 작성 시 팀원끼리 지켜야할 합의된 규칙을 의미합니다.Git 브랜칭 전략 : 브랜치 생성 / 삭제 / 병합에 대한 팀원간의 합의된 규칙을 의미합니다. 이번주 진행사항은 파트끼리 합의한 하나의 규칙을 선정하는 것이었습니다.따라서, 1차적으로 제가 진행했던 프로젝트 `오디`의 백엔드 컨벤션을 기반으로 각 팀원이 추가하고픈 내용 / 삭제하고픈 내용을 자율적으로 적어와 회의가 진행되도록 하였습니다. 그럼 컨벤션 회의에서는 어떤 내용들이 오고갔을까요? 코드 컨벤션백엔드 코드 컨벤션은 크게 3가지로 나누어졌습니다.1) .. FCM 알림 비동기 + 이벤트 리스닝으로 리팩터링 하기 - 2편(테스트) 안녕하세요 브로콜리입니다. 지난 글에서는 동기화되어 있던 FCM 알림 로직을 비동기 + 이벤트 리스닝을 방식으로 리팩터링한 과정에 대해 소개해드렸습니다. 그 과정에서 1) 알림 로직과 비즈니스 로직간의 결합도 감소 2) latency 성능 개선 이라는 이점을 얻을 수 있었습니다. 그러나, 모든 구현의 완성은 테스트인만큼 비동기 + 이벤트 리스닝 방식을 어떻게 테스트할지 고민이 생겼습니다.Situation : 비동기 + 이벤트 리스닝 방식을 테스트하자! 다시한번 상황을 짚어보겠습니다. 비동기 + 이벤트 리스닝 방식으로 개선된 알림 서비스는 다음과 같은 모습입니다.1) 상위 모듈은 fcmEventPublisher를 통해 이벤트를 발행합니다.2) 발행된 이벤트는 fcmEventListener를 통해 수신합니다.. [디베이트 타이머 - 1차 스프린트] 팀 빌딩과 프로젝트 OT 우아한테크코스 6기를 백엔드를 수료함과 동시에 정말 많은 미련이 남은 활동은 역시나 프로젝트였습니다. 그 아쉬움을 구체화해보자면 다음과 같습니다.- 명확한 문제정의를 통해 그것을 해결하는 서비스를 만들고 싶다.- 실사용자가 있었으면 좋겠다. (== 사용자를 가정한 리팩터링을 하고 싶지 않다)- 서비스의 점진적 성장을 사용자와 함께 하고 싶다 인생 어차피 한번 사는거... 할 생각이 있으면 해야죠!! 실력은 부족하더라도 들이박아보고 싶었습니다.그래서 직접 아이디어를 만들고 프로젝트를 리딩하기로 결정했습니다. 1. 나는 어떤 문제를 해결하고 싶은가 : 아이디어 구체화 이에 레벨4 종료시기에 맞추어 제가 활동했던 도메인들에서 만들고 싶었던 서비스 아이디어를 구체화하기 시작했습니다. 여러가지 도메인이 있었지만 .. 이전 1 2 3 다음
