2주차 중간발표때 멘토님에게 Query Dsl의 장점에 대해서 질문을 받았는데 가독성이 향상된다 라고만 답변을 했다. 분명히 봤고 Query Dsl의 장점을 딱 두가지로만 나눌 수 있을 정도로 명확했는데 당황해서 그런가 대답을 하지 못했는데 이번에 구현을 하면서 다시 마음속에 새기기로 했다 Query Dsl의 장점 문자가 아닌 코드로 쿼리를 작성함으로써, 컴파일 시점에 문법 오류를 쉽게 확인할 수 있다. 자동 완성 등 IDE의 도움을 받을 수 있다. 동적인 쿼리 작성이 편리하다. 쿼리 작성 시 제약 조건 등을 메서드 추출을 통해 재사용할 수 있다. 근데 이 장점들을 요약해보면은 가독성이 좋은 쿼리문 / 동적 쿼리 2가지로 볼 수 있다. 준비 StringUtils 라이브러리만 있으면 된다. 이게 왜 있어야..
2주차를 마무리하고 돌아보면은 2주차는 크롤링에 대한 기억은 모두 잊고 MVP 기능 구현에만 온 신경을 쏟았다. 아무래도 중간에 기획이 바뀌었다보니 더욱 신경을 쓸 수 밖에 없었다. 중간발표 결과물 엿보기 https://www.notion.so/dd113cf1f55a4ca5bb3eef4feb876e11 중간 발표 Pin-Table 🍽 www.notion.so 중간발표 회고록 엿보기 https://www.notion.so/68c14a65207f410ca3fdef8d609b55a7 중간발표 회고록 1. MVP 중간발표 자료 www.notion.so 2주차까지 마무리하고 나서의 소감은 여태껏 MVP 기능 구현만 했다보니 자존감이 많이 떨어지기도 했다 이건 뭔가 서비스팀도 아니고 그렇다고 특별한 백엔드 성향이 ..
실전프로젝트 14일차 1. 배포 팀원들과 작성했던 코드들을 모두 병합하고 배포했다. 배포하기 이전에 이미 환경설정은 미리해두었기때문에 배포까지의 시간은 얼마 걸리지 않았으나 배포하기 이전 병합을 할때 테스트를 하는등의 과정에서 많은 시간이 소요되었다 이는 이미 2번의 앞선 프로젝트에서 한 경험을 토대로 줄일수있었던 현재의 최대였던거 같다 아무래도 처음 만들때부터 어떻게해야 충돌이 나지 않을까 어떻게해야 효율적일까 라는 고민을 많이 한 덕분에 병합할때 생각보다 많은 에러는 나지 않았다 다만 그냥 그 과정 자체가 우리단계에서는 시간이 오래걸릴뿐이었다 2. MVP 완성 직전 우리가 이제 남은 4주간의 백엔드 성격이 짙은 프로젝트를 완성시키기위한 기초작업이 어느정도 완료되었다 우여곡절이 많았다 일단 중간에 기획..
여러가지 Query Dsl 결과 반환 값 fetch() : 리스트로 결과를 반환 (데이터가 없으면 빈 리스트를 반환) fetchOne() : 단건을 조회하고 반환 (결과가 없을때는 null 을 반환, 결과가 둘 이상일 경우에는 NonUniqueResultException 반환) fetchFirst() : 처음의 한건을 쿼리해서 반환 ( limit(1).fetch()와 동일) fetchResults() : 페이징을 위해 사용될 수 있음 fetchCount() : count 쿼리를 날림 %Like% Query Dsl 구현 where(QEntity변수명.QEntityColumn명.contains(찾을 변수명)) 예시) .where(naver.storename.contains(storeName)) contain..
쿼리를 자바 코드로 작성할 수 있게 도와주는 기술로 JPA로는 어려운 복잡한 쿼리나 동적쿼리까지 해결할 수 있는 장점이 있다. 또한 문법의 오류를 컴파일시에 찾아 낼 수 있다는 장점을 가지고 있다. 1. Query Dsl 특징 1. 쿼리를 코드로 작성 가능 (ide의 자동완성 기능을 사용할 수 있다) 2. 컴파일시 문법 오류를 찾아낼 수 있음 3. 동적 쿼리 구현 가능 4. 가독성 향상 가능 * 동적쿼리(Dynamic SQL) : 특정 조건들이나 상황에 따라 변경되는 쿼리 * 정적쿼리(Static SQL) : 어떤 조건 또는 상황에도 변경되지 않는 쿼리 2. Query Dsl 적용 config 패키지 package com.example.pirate99_final.map.config; import com...
실전프로젝트 12일차 1. Query Dsl Query Dsl을 어떻게 구현해야하나 고민을 많이 했던거 같다 일단 난 query에 자신이 없었고 그 query를 이용해 무언가를 구현해야한다는 것이 부담이었다. 많은 구글링을 통해서 패턴을 좀 보았고 그것이 눈에 익었을때 구현을 해봤는데 뭐 그렇게 어렵지 않게 되었다. 이것도 사실 하기가 어렵지 해보면 별거 아니라는 생각이 좀 든다 리펙토링하는데에서는 시간이 좀 오래 걸린거같다 아무래도 리펙토링도 리펙토링이지만 이 Query Dsl은 카테고리 검색 기능과 묶여서 있는 기능이다보니까 이것을 어떻게 프론트쪽에서 구현을 할까 어떻게하면 프론트엔드에서 처리하기가 쉬울까 라는 고민때문에 시간이 오래걸렸다 그래도 이런 생각을 함으로써 더 좋은 결과가 나오고 더 좋은 ..
💣 크롤링 정말 많은 시행착오를 겪으면서 우리의 목표대로 데이터는 순조롭게 들어가고 있다. 특히 Not Found Error가 발생하면서 정말 많은 시행착오를 겪었다. 우리는 너무 답답해서 여기저기 수소문을 해보기도하고 멘토님께 질문을 드려보았는데 결론은 많은 시행착오와 트러블슈팅을 통해 웹 크롤링시 무분별하게 반복적인 요청은 서비스에 과도한 부하를 줄 수 있기 때문에 그에 대한 처리를 해두었을 가능성도 고려해보아야 하지만 우리가 어느정도까지 처리했을지를 알 수 있을 가능성은 적으므로 시행착오를 겪으며 알아내야 한다는 답변을 받았다. 우리가 정말 다행이라고 생각했던 것은 우리의 방식이 틀리지 않았구나 다른 더 좋은 방법이 있는데 우리가 찾지 못한것이 아니라 그냥 단지 크롤링의 단계를 밟고 있는것이구나 라..
실전프로젝트 9일차 1. 기획 수정 우리가 이제 1주일동안 프로젝트를 진행했는데 크롤링도 안정기에 접어들었지만 다들 서로 말은하지 않아도 의문점이 있었다. 우리의 스코프가 너무 작지않나? 어느 부분이 문제일까 라는 고민을 했는데 오늘 멘토님 피드백을 받으면서 이 부분을 제대로 지적받았다. 요약해보자면 첫번째 MVP 기능이 너무 적다 두번째 단순하게 검색성능 개선에만 초점을 맞췄다 세번째 챌린지팀의 목표를 잊지말자 상세한 내용은 따로 블로그를 적겠다. 기획 수정에 들어갔고 MVP 기능을 늘리고 동시성제어와 대용량 트래픽에 대해서도 집중하기로 했다 오늘 하루는 거의 회의하는데에만 시간을 쏟은거같다 하지만 이렇게 기획에 대해 피드백을 받고나니 마음이 편안해졌다 사실 피드백을 받기전까지 우리는 서로 챌린지팀에 ..
