2024.03.05

해야될 거.

 

1. 이미지 처리

이미지 로딩 속도를 줄여야 하는데. 우선 데이터베이스에는 300*300픽셀 사이즈의 이미지가 저장되어 있음. 어떤 페이지에서 30*30 픽셀의 크기로 이미지를 띄워야 하고, 어떤 페이지에서는 300*300 픽셀로 띄워야 하는 상황. 30*30 픽셀로 여러 개를 띄울 때는 퀄리티를 좀 낮추고 속도를 향상시키는 방법이 있는지를 알아봐야 함. 일단 기능상에 문제는 없기에 배포하고 나중에 해결하기로.

 

 

 

2. 문서 편집 페이지

아예 바닥부터 만드는 "생성"이랑 "수정"을 다른 페이지로 구성했는데, 통합하기로.

디폴트값을 부여하는 작업을 노가다로 함.

특히 노래 문서 편집 페이지에서 가사 부분을 만드는 게 엄청 어려웠는데,

1) 처음엔 input 값을 서버에 바로바로 저장하지 않고 문서 발행 버튼을 누르면 저장하게 구현하려고 했는데, 버블 자체로 구현이 안되고 orchestra라는 플러그인을 사용해야 되는 것 같음. 그래서 플러그인을 살펴봤는데, 공식 문서가 너무 부실하고 예시로 구현된 페이지에 에러가 62개 떠있는 거 보고 접음. 이해해서 구현하기에는 시간이 부족할 것 같음. 목표는 3.15까지 5000명의 아티스트를 추가해서 배포하는 거.

2) 그래서 song_construction 데이터 타입에 song_lyric을 넣어서 저장하는 방식으로 했는데, 역시나 구현이 어려움. 수정했을 때 원래 문서의 내용을 바로 바꾸면 안되니까 진짜 문서의 song_construction을 복사한 데이터 타입을 이용해야 하는데, 가지고 있는 song_lyric list는 shallow copy 해버려서 어떻게 해야되는지 모르겠음.

3) 그래서 곡구성 데이터 타입 안에 가사들을 저장하는 방식을 버리고 가사 데이터에 곡 구성을 나타내는 건지에 대한 boolean 필드를 만들어서 전체를 deep copy 하게 만듦. (기본적인 데이터 타입, text나 number 같은 것만 deep copy 하는 거 같음) 이러니까 노래 문서에서 곡구성이 가사와 똑같이 기능하게 만들 수 있어짐. 근데 갑자기 동기화 이슈가 생김.

근데 이건 뭐 곧 해결할 수 있을 거 같음. 

 

 

 

3. 오늘의 음악 페이지

기능 구현이 좀 어려워서 (정확히는 디자인을 구현하는 게 어려워서) 디자인을 수정해서 만들기로.

 

4. 구글 애드센스

어떻게 하는 건지 도통 모르겟다.

 

5. 리캡챠

이것도 모르겠다.

 

6. post - bbs 합치기

페이지를 따로 만드는 것보다 url parameter를 이용하면 로딩속도를 줄일 수 있다. (처음 로딩속도는 좀 더 길어지지만 page element가 변하지 않아서 페이지를 왔다 갔다 할 때 빠름) 커뮤니티 특성상 계속 보게 만들어야 돼서 속도를 줄이기 위해 페이지를 합쳐야 될 것 같다.

 

7. 모바일 최적화

대략 990픽셀 이상부터 모든 게 다 정상적으로 돌아감. 페이지마다 다 새로운 디자인을 만들어야 함. 그냥 노가다.

 

 

 

요즘은 계속 백엔드 쪽에서 다루다보니까 진도가 안나가는 것처럼 느껴진다.

어제 힙합엘이에서 가사해석 게시판을 리뉴얼하고, 힙합을 넘어서 다른 장르도 다루겠다고 그래서 몹시 신경쓰인다.

어떻게 딱 지금?