codestates / codestates/Loca-Musica
[Dev-Log] 210806
- Dominant language
- JavaScript
- Stars
- 0
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Description
### 오늘은 어떻게 프로젝트에 기여했나요?
- 상당히 세세한 1차 피드백을 바탕으로 의견을 조율하여 기존의 API문서, 스키마, 와이어프레임, 플로우차트, 시스템아키텍쳐를 수정했다.
### 오늘의 프로젝트에서 힘든 점은 무엇인가요?
- 생각하는 기능이 어떻게 구현될 수 있을지를 서로의 생각을 확인하면서, 맞춰나가는 과정이 힘들었다.
- 같은 생각을 하고 있어도 표현방식이 달라서 다른 말인 줄 알았다가 말을 끝까지 듣고 보면 의외로 같은 의견인 경우도 있었고, 말이 길어지다보니 이야기가 산으로 가면서 다시 의견을 정리해야할 필요도 있었다.
- 서로 의견을 잘 표현해주고, 정리도 잘해주는 팀원이 있어서 좋았다.
### 오늘의 회의 기록
```js
*210806 5th Team Meating
1. 뮤지컬 상세페이지는 admin계정을 이용해서 등록하면 DB에 저장되는 방식
=> kopis에서 받아올 수 있는 정보의 수준이 그닥 좋지 않지만, api를 통해 정보를 받아오는 것에 의의를 두고
향후 사이트가 발전이 되면 기획사에서 직접 작품등록을 요청할테고 그렇게 되면 양질의 정보를 제공할 수 있게 될 것으로 예상됨.
(또는 kopis를 능가하는 양질의 정보를 API 제공하는 사이트가 나타난다면 바로 이용 가능할 것으로 예상됨)
(참고로 현재 공연정보를 제공하는 플레이디비의 경우, 기획사에서 공연정보를 담은 워드문서를 작성해서 게시판에 업로드하면 담당자 검수 후
등록하는 형태, 기타 쇼핑몰에서의 제품등록도 크게 다르지 않은 방식으로 진행되는 것으로 알고 있음)
2. admin계정으로 작품등록, 수정, 삭제가 가능
3. kopis api 개발가이드를 바탕으로 좀 더 세부적인 기획
1) 개발가이드 안내문서의 2-1:공연 상세조회 서비스를 이용하고 싶지만 이 경우, 공연ID가 필수입력요소이다.
2) 공연ID를 각각 찾아서 입력하는 것은 번거로울 것이라고 예상이 되어 1-2:공연목록조회 오퍼레이션을 이용하여 작품을 검색한다.
(이 경우 줄거리와 출연진의 정보는 가져올 수 없다)
3) kopis에서 제공하는 정보를 최대로 활용하기 위해서는 2번의 과정을 먼저 거쳐서 얻은 공연ID값으로 1번의 과정을 다시 반복하면
해결할 수 있는데 kopis에서 줄거리를 거의 제공하지 않기 때문에 두 과정을 반복하는 것이 의미가 없어보임.
4) 일단은 휴먼의 노동력을 이용하여 두 가지 정보를 입력하는 방식으로 고민하고 있는데, 더 효율적인 방법이 무엇인지는 계속 고민해야할 문제.
4. 각 뮤지컬의 대표넘버(=음악)의 url을 가져오는 것도 유튜브의 api를 활용할 수 있는지 연구 필요.
지금으로서는 역시나 휴먼의 노동력을 이용할 수 밖에
하지만 뮤지컬의 등록은 사이트의 핵심 정보이기 때문에 휴먼을 능가하는 인공지능의 탄생전까지는 휴먼의 노동력이 가장 합리적일 것이라 판단됨
(실제 사업으로 진행한다고 생각했을 때, API 만을 이용해서 부실한 정보로 가득한 사이트를 만든다면 곧바로 취준생 신분 확정!)
(물론 휴먼의 노동력을 덜어줄 코드 작성이나 기발한 API 이용방법 등은 계속 고민해야할 문제)
5. 카카오로그인의 경우, 이메일 주소를 필수로 받아올 수 있도록 카카오디벨로퍼스에 사전 검증 절차를 마쳤고 현재는 유저의 이메일을 필수동의항목으로 지정완료.
(실제 코드작성, 로그인 기능 구현에서 목적한 대로 동작하는지 기대가 된다.)
6. 작품 상세페이지의 해시태그에 가중치를 두는 것은 wordcloud를 이용해서 시각적으로 구현할 수 있을 것.
그러나 각 요소를 클릭했을때 이벤트 핸들러 함수를 적용시킬 수 있는지는 아직 미지수. 이 부분은 프론트가 더 연구해보자.
7. 해시태그는 클릭하면 tagcount가 +1이 되는 형식. 중복으로 클릭이 되지 않게 구현 필요.
백엔드 스키마 중 user_hashtag 테이블에서 공감을 표현한 유저를 등록하고자 했는데, 어떻게 더 효율적으로 구현할 수 있을지 고민해봐야함.
사이드 바의 해시태그는 count 순으로 동일한 CSS로 위에서 아래로 나열, 클릭하면 해당 해시태그가 연관된 뮤지컬을 모아놓은 곳으로 이동,
뮤지컬의 상세 페이지에서의 해시태그는 wordcloud를 통한 시각적 구현, 특정 해시태그를 선택하면 공감 표현
뮤지컬의 상세 페이지에서 해시태그 등록에서 기존에 등록된 해시태그는 새롭게 추가되지 않고, 공감 표현과 같이 처리
해시태그의 글자는 5자 이하, 문자, 기호의 제한은 없음
불순한 의도를 가진 악의적인 해시태그의 경우 여러가지 방법이 있겠지만, 오늘 회의에서 나온 최선의 방어책은 서버에서 배열형태로 악의적인
단어들의 목록을 유지하면서, 새로운 해시태그 등록전에 걸러주는 방법을 사용해보기로 함.
8. 뮤지컬의 분류기준이 지금은 라이선스와 창작 정도로 간단하게 구분하고 있지만 초심자의 입장에서는 라이선스가 뭔지 창작이 뭔지 쉽게 알 수가 없다ㅠㅠ
(첨언을 하면 통상적으로 창작은 국내 창작자들에 의해 만들어진 작품, 라이선스는 해외 원작자에게 판권을 구입해서 공연하는 것을 의미).
영화처럼 스토리 별(영화에서는 장르로 표현. 뮤지컬 자체가 공연의 한 장르이므로 여기에서는 스토리로 대체) 분류나
국가별 분류와 같이 관객 입장에서 와닿을 수 있는 카테고리를 만드는 것이 필요.
그러나 명확한 기준이 없기 때문에 현재는 우리의 자의적 해석에 의한 분류가 될 수 밖에 없지만,
최대한 학술정보를 이용해서 보편타당한 기준을 만들어보는 것이 목표
```
[KOPIS API 사이트](https://www.kopis.or.kr/por/cs/openapi/openApiInfo.do?menuId=MNU_00074&searchWord=&searchType=total)
### 내일은 프로젝트에 기여하기 위해 무엇을 해야 하나요?
- [ ] 주말간 새로운 스택에 대한 공부
- [ ] 떠오르는 아이디어나 새로운 피드백을 통한 수정
Contributor guide
No contributing guide indexed for this repository
Research direction
This issue is a development log rather than a defined change, and it names no source files, tests, or entry points. Read the linked KOPIS API documentation and the recorded notes for context, but no concrete completion condition is specified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 10/100