## 음악 조회 기능 구현풍선을 생성할때 음악을 보여줘야 겠다고 생각했다. 이 링크가 잘못된 링크면 풍선 생성이 실패했다는 토스트가 떠오를텐데 사용자 입장에선 처음부터 다시 입력하기 귀찮다.때문에 생성할때 첫번째 화면에서 음악 주소를 입력하면서 조회도 하고, 검증하는 기능을 넣었다.백엔드에 /music?streamingUrl= 으로 GET 요청을 보내는 방식이다. ## 알록달록 풍선풍선의 색깔을 좀 다양하게 만들어봤다. 색은 풍선 엔티티에 직접 저장되며 아래와 같이 풍선 추가 모달의 두번째 페이지에서 고를 수 있다. 이런식으로 다양한 색깔을 제공한다.위의 헤더의 레이아웃도 손을 봤다. 로고를 중앙에서 왼쪽으로, 기록 과 알림(아래 설명)은 왼쪽으로 배치했다. 사실 색깔 팔레트를 제공하고 있지만 사실 직접..

음악 응답 스키마에 공통 필드가 있는 MusicResponse를 추상 클래스로 만들고  YoutubeMusicResponse, SpotifyMusicResponse를 만들던 중,com.fasterxml.jackson.databind.exc.InvalidDefinitionException 라는 오류를 만났다. 오류는 대략 다음과 같다.Cannot construct instance of `com.musicinaballoon.music.application.response.YoutubeMusicResponse` (no Creators, like default constructor, exist): cannot deserialize from Object value (no delegate- or property-b..

그동안 글 쓰기가 귀찮고 어려워져 일기에 소홀해지고 있다.그래도 어디까지 업데이트 되었는지 적고자 한다. ## 맵 화면과 풍선/map 으로 이어지는 맵 화면은 오른쪽과 같이 변했다.원래는 어떤 컨테이너 안에서 보여주는 형태였는데 굳이 테두리를 보여줄 필요가 없으니 이렇게 변한 것이다.그리고 #12 게시글에서 말했듯 구글 맵은 진작에 Leaflet으로 바꿨다. 잘 작동한다. 풍선의 색은 아직까지는 풍선 id % 3 해서 구하는 방식이다. (추후 바꿀지도 모름)풍선의 아이콘도 좀 손을 봤다. 광원?을 추가했다 더 생동감이 있어 보인다:) 풍선들은 최대 만개가 맵 위를 떠다니는데 이는 canvas에 그리는게 아닌 만개의 svg element 가 html에 있는 것이라서 버벅임이 심했다.때문에 현재 화면에 보이..

풍선 여러개를 조회할때 이미 주운 풍선은 보여선 안된다는 조건 때문에, 조금 복잡한 sql이 필요했다. 처음에는 JPQL을 사용하려 했지만 이거 문법이 뭔지도 잘 모르겠고.. 문서도 오래되어서 보기가 어려웠다.그래서 자동완성을 지원하는 QueryDSL을 사용하게 되었다.  ## 적용 방법이 글은 튜토리얼 같은 것이 아니라, 내가 고민한 것과 막힌 부분에 대해서 적는게 목적이기 때문에 적용 방법을 하나하나 설명하지는 않겠다. 개인적으로는 아래 글이 좋은 것 같으니 필요하다면 참고 바란다.https://tecoble.techcourse.co.kr/post/2021-08-08-basic-querydsl/  ## JPA + QueryDSLQueryDSL 자체는 쿼리를 생성해주는 역할만 하는 것 같다.문서도 아주..

그동안 개발일기를 안썼는데, 대신 프론트 개발에 열중했다.현재는 풍선을 보여주는 맵 페이지 / 유저 등록 페이지 / 풍선을 생성하는 페이지를 생성했는데, 그중에서 기억에 남는 것들을 정리해보고자 한다. ## 지도를 어디서 가져올까?### Google Map 를 쓰자첫번째 후보는 당연 구글 맵이였다. 구글맵은 api를 제공하는데, API_KEY를 생성해서 사용하면 그만이였다.또, 내가 거의 배낀 “행록” 프로젝트에서도 구글맵을 활용했기 때문에 그냥 그대로 가져왔다.하지만 곧이어 문제가 생겼다. 은근히 이 api 무료 제공 횟수가 짜다!월간 200달러 어치는 무료로 사용 가능한데, 맵을 1000번 렌더링 할때 마다 7달러가 부과된다그러니 달마다 2.8만번 호출 가능하고, 일간 1천번 못 미치는 정도 호출 가..

막상 풍선을 실제로 날리는걸 구현하려고 하니까, 어떻게 풍선을 움직이는 매개체; 바람을 구현할지 의문이 들었다. ## 일직선으로 날리기사실 처음 생각한 방법이 이거였다. 근데 이런 건 인공위성 같다는 의견을 받은 뒤로 이런 방식은 왠지 불편해졌다.일직선으로 도는건 계속 같은 장소만 반복하니 좋지 않아보인다. ## 실제 바람을 시뮬레이션 하기그래서 가장 더 그럴 싸한 바람을 생각했다. 실제 바람을 어디선가 제공할 것 같은 기분이 들었기 때문이다.찾아보니 유럽이나 미국에서 지구 바람과 기온을 예측하는 모델을 가지고 있고, 이 데이터를 제공하고 있었다. (GFS 같은것) ….나는 좀 더 단순한 모델이 필요하다. (컴퓨팅 비용때문에) 그래도 얻은 건 있다. 바람은 극지방으로 움직이기보다는 옆으로 도는 것 같다...

스프링에서는 예외를 처리하는 예제를 쉽게 볼 수 있다. 갓갓 우테코 레포에서 많이 참고했다.이번 글에서는 다양한 예외를 정의하는 것, 구분하는 것, 예외를 사용자에게 어떻게 응답으로 대답해줄지를 다룬다.## 내부 에러 코드 관리하기내부 에러코드를 상수로 관리할 필요가 있다. 이 값을 토대로 어떤 예외의 상세 설명을 가능하게 한다.대충 이렇게만 작성했다.public enum ErrorCode { // 404 USER_NOT_FOUND("The user does not exist"), BALLOON_NOT_FOUND("The balloon does not exist"), // 500 INTERNAL_SERVER_ERROR("Internal server has a problem"),..

~결론~병 대신 풍선이란 표현을 쓸거예요~풍선에 실제 좌표(위도, 경도)를 줄거예요~유저는 지도에서 풍선을 습득하고, 노래를 추천받을 수 있어요~ ## 수정하는 이유프로젝트의 기획을 수정하기로 했다.원래 프로젝트의 의도는 누군가 추천해주는 음악을 받아 듣는다는 취지에서 Music in a Bottle이라 했지만,이건 어쩌면 음악 추천 게시판이나 음악 추천 알고리즘을 이용해 해결 할 수 있을 것이다.병을 음악에 담아서 보내고 받아보는게 재밌는 부분인데 이 점을 실제로 살리지 못하는 것 같다. ## 병을 실제로 지구상에 둥둥 떠다니게 할까?차라리 병에 실제 좌표를 부여하고 이를 Google Map를 이용해 화면에 보여주면 더 멋질 것 같다.그리고 배치 작업을 돌려서 병을 조금씩 이동시키면 될것 같다.구글 맵..