전체 글(103)
-
20240409 (화) 이력서 준비 - PDF, 이력서
오늘은 인텔리픽에 올릴 이력서를 작성했다. 위 자료는 내가 작성한 이력서의 PDF 파일과 캡처사진.
2024.04.09 -
20240408 (월) 이력서 세션, 이력서 준비
이력서 세션을 맞이해서 내가 여태까지 했던 프로젝트들을 정리해보았다. 주로 쓸건 최종프로젝트 티켓레이더와 바로 이전에진행한 대용량 트래픽 동시성제어프로젝트 1. 티켓레이더 (최종 프로젝트) 간단한 구현이나, 기능을 수정했던 경험이 있다면 적어주세요. CRUD Category Place AvailableSeat Price Redisson Pub/Sub Lock AOP를 활용한 Pub/Sub Lock 어노테이션 Vue 웹페이지 디자인 뼈대 티켓예매시 좌석배치도 구현 Axios를 활용한 Front-Back 구현 트러블슈팅이나, 어떤 기능 또는 성능을 개선했던 경험이 있다면 적어주세요. 이벤트 조회시 N+1 문제 발생 우려 문제 이벤트 리스트 조회시 N+1문제 발생 우려 원인 관계를 다시 LAZY로 설정하고 리..
2024.04.08 -
20240405 (금) 최종 프로젝트 티켓레이더 6주차 - 최종발표회
오늘은 최종발표회를 진행했다.. 6주간 진행한 프로젝트의 결과물을 내보였다. 여러 고난도 많았지만 나름대로 만족스러운 결과물을 내서 다행인것 같다. 우리 프로젝트의 주요기능들을 짤막하게 적어보자면 1. OAuth2.0을 활용한 소셜로그인(구글, 카카오를 통한 로그인) 2. QueryDSL을 활용한 동적쿼리(다양한 조건의 검색) 3. Redisson Lock 을 사용한 동시성제어(Pub-Sub Lock) 4. Redis를 이용한 Cache(인기검색어, 평점, 좋아요 등의 TOP5를 메인화면에 위치) 이렇게 된다.. 사실 적을만한게 없어가지고 주요기능이라도 적어놨다. 아래로는 이번 프로젝트를 진행하면서 우리조가 느낀점등을 KPT로 적어보았다. KEEP 김건우: 팀원과 필요한 기능에 대해 논의하며 의사결정했던..
2024.04.05 -
20240404 (목) 최종 프로젝트 티켓레이더 6주차 - 피드백 수용
1. createdAt, updatedAt 의 LocalDateTime.now() 문제 문제 : 시간이 대한민국/서울 시간과 달라서 리뷰, 티켓 생성 시간 등의 시간이 다르게 나타났음 2. 좋아요 새로고침 직접 값 업데이트 장점: 빠른 사용자 경험(UX): 서버로부터 응답을 기다리지 않고 즉시 UI를 업데이트할 수 있다. 이는 더 빠르고 반응적인 사용자 경험을 제공 네트워크 트래픽 감소: 서버에 추가 요청을 보내지 않으므로 네트워크 부하가 줄어든다. 단점: 데이터 불일치의 가능성: 동시에 여러 사용자가 같은 이벤트에 좋아요를 누르는 경우, 실제 likeCount와 프론트엔드에서 보여지는 값 사이에 차이가 발생할 수 있다. 오류 처리 복잡성: 좋아요 요청이 실패했을 때 UI를 다시 롤백하는 로직을 구현해야..
2024.04.04 -
20240403 (수) 최종 프로젝트 티켓레이더 6주차 - 유저테스트 시작
1. 브로셔 제출 [TicketRadar] 티켓 예매 서비스 [TicketRadar] 티켓 예매 서비스 | Notion 🏗 아키텍쳐 teamsparta.notion.site 2. 깃헙 리드미 수정 아래는 주로 추가된 내용 3. 이벤트리스트 캐싱관련 (평점 오류) 문제 : 유저테스트를 진행하고 얼마 지나지 않은 시점에서 메인화면의 좋아요, 평점순 top5가 나타나지 않았음 원인 : 캐싱작업중에 Double이 들어가야할 평점에 String 값이 들어가 생긴 오류였음 왜 String 값이 들어갔느냐?! 한 유저가 리뷰가 0개인 이벤트에 리뷰를 남겼다가 삭제를 하는 과정에서 리뷰 평점 계산이 잘못된것으로 보임 평점 = 토탈점수/리뷰갯수 로 나눠서 계산하는데 토탈 0점 /갯수 0개 로 나눠지면서 null값이 들어..
2024.04.03 -
20240402 (화) 최종 프로젝트 티켓레이더 6주차 - 유저테스트전 최적화?
엔티티에서 대부분을 FetchType을 EAGER로 설정해놨다. 일부 Response에서 LAZY로 해놓을시 불러오질 못해서였다. 하지만 EAGER 라는것은 상당히 조심해서 써야한다. 이유를 들자면 EAGER 를 사용하면 예상치못한 SQL이 발생할수 있다. ManyToOne이 5개가 있는데 전부 EAGER로 설정되어있다면 조인이 5개 일어난다. EAGER 는 JPQL에서 N+1 문제를 일으킬수 있다. 위에 이유에 이어서 일어나는 문제인데, 다대일 관계에서 멤버(다)2개와 팀(일)이 2개 있다고 가정해보자 멤버 2명을 조회한다. JPQL에서는 EAGER시에 반환시점에서 전부 다 조회가 되어있어야 한다. 멤버를 조회했는데 그 멤버마다 팀을 추가로 또 가져온다. 이처럼 N+1의 문제는 쿼리를 1개 날렸는데 그..
2024.04.02