풀캠정글러

협력사 멘토링 이후 생각해볼 것이 많았다. 남들 다 하니까 하자는 느낌이었던 커뮤니케이션 툴은 개발하지 않는 것으로 결정 핵심 기능과는 아무 연계가 없는데, 개발을 시작하면 프로토콜부터 다 갈아엎어야 한다. 협력사님 말씀대로 이건 좀... 중간발표 직후 당장 프론트에서 보여줄 것이 없을 때는 해볼만한 아이디어였지만 이젠 우리 조와 어울리는 다른 아이디어의 구현목표가 많이 쌓여있다. 대신 데이터 차트와 영상을 보며 편집자 유저가 고른 하이라이트 북마크들, 이것을 이용한 아웃풋을 몇개 개발하기로 했다. 1. 크롬 익스텍션 편집자 유저가 editor 페이지에서 작업을 마치고 내보내기한 북마크 구간들의 데이터는 우리 서버에 저장 익스텐션의 설치자(=시청자)는 해당 url의 풀영상을 볼 때 편집자가 북마킹한 구간..

결국 새벽까지 붙잡고도 동기화 문제 해결을 못하고 돌아갔는데 코로나 검사를 해야된다고 12시에 강제기상 모닝콜... 잠을 못자서 화가났는데 와보니까 팀원이 내가 어제 매달렸던 문제를 해결해둬서 기분풀림 ㅅㅅ 대체 어떻게 해결한건가 싶어 들어보니 플레이어 라이브러리의 내장함수를 컨텍스트에 넣어서 Provider로 각 컴포넌트에 배포했다고 한다 이게 된다고?? 어제의 내 삽질은 도대체... 알아야할걸 모르면 몸이 고생하는 나쁜 예 아무튼 덕분에 우리의 핵심기능은 구현되었다 스트림 데이터를 하이라이트를 감지할만한 factor로 가공하여 차트로 시각화 -> 유저는 차트에서 특이점이 있는 부분들을 체크하며 하이라이트인지 확인하며 북마킹 -> (덤) 모든 검토가 끝났을 때 유관된 아웃풋 기능 제공 에서 못만들면 프..

1. 로그인 구현 우리 팀의 질문 : Q. 한 팀원이 토큰을 이용한 로그인 기능을 구현하는데 nodeJS+mongoDB 세트의 구현이 레퍼런스가 잘 되어있어 이를 기반으로 개발하고 싶어한다. 하지만 현재 우리의 서버는 파이썬을 이용한 데이터처리의 용이성 때문에 flask & MySQL. 이런 개발 상황일 때, 로그인 서버를 따로 두어 개발을 하는 것은 괜찮은 개발 방향인가? A. 세션과 토큰의 차이를 아는가? -> 세션은 서버에서 따로 처리가 필요한 무언가라는 정도로 알고있다. 토큰은 서버에서의 그 과정을 생략하게 해준다 JWT든 Oauth든 토큰을 써서 세션을 대체하는 이유가 서버 자원 때문도 있다. 우리팀 규모의 프로젝트에서는 토큰을 쓰면 서버측 자원소모가 거의 없기 때문에, 로그인 서버를 따로 두지..

오늘의 목표 (였던것) 페이지에 탑재한 Video Player 컴포넌트의 동기화 문제 해결 영상의 현재 재생시각인 {elapedTime} 값이 context {Pointer} 값을 바꿔 타 컴포넌트에 영향을 주는건 구현됐지만 반대로 다른 컴포넌트가 context값을 바꿨을 때, 그것이 elapedTime을 바꾸지 않는 상황 해결하지 못하면 예를들어 차트 컴포넌트를 완성해서 머지했을 때 차트에서 하이라이트가 될 것 같은 포인트를 더블클릭하는데도 해당 부분 미리보기가 안되는 등의 문제가 생길 것이다. = 프로젝트가 망한다는 뜻 일단 Data Chart 영역을 담당한 팀원이 멋지게 구현을 해둬서 그걸 컴포넌트에 올렸다. 차트 영역을 클릭하면 해당 위치로 context값이 동기화되는 모습 (노란 세로선) 하지만..

불꽃벼락치기로 밀렸던 일지를 겨우 다 정리하고 이제부턴 드디어 현재진행형으로 일지를 쓴다... 팀원이 비디오 플레이어와 채팅 뷰어의 기능을 구현했다 구현된 채팅 뷰어에 채팅이 보여지기 위해서는 추출한 채팅 데이터로부터 시각이랑 메세지만 남겨 {x초 : [x초에 발생한 채팅들의 리스트]}의 dict 구조체를 chatProcess의 return으로 줄 필요가 있다. 채팅을 파싱해서 시각만 추출해 분포도를 만들고 메세지는 버리던 기존 알고리즘 => 메세지도 주워서 dict에 담는 것으로 수정 알고리즘을 서버 담당 팀원에게 보내고, 구현된 컴포넌트를 제 위치에 합친 결과 영상의 재생에 따라 타 컴포넌트들의 time 값도 매 초 잘 바뀌고, Chat Viewer는 그걸 이용해서 해당하는 시각의 채팅을 보여준다. ..

전날 짠 컴포넌트들의 모습 각 컴포넌트의 jsx 파일 안에 유저 이벤트를 의미하는 버튼들을 만들어두었다 비디오 플레이어는 초마다 재생시각을 바꿔야 하니까 버튼에 t+=1, 북마커의 버튼은 누르면 그 장면으로 이동해야 하니까 t={북마크의시간값} 등등 이제 각 컴포넌트의 버튼을 눌렀을때 바뀌는 Time Pointer의 값이 다섯 컴포넌트간에 동기화되는 기능을 구현하면 된다 이걸 구현한다면 결과적으로 하나를 눌러도 나머지 컴포넌트들도 해당 시간에 맞는 모습으로 렌더링될 것 예를 들어 차트에서 눈에 띄는 부분을 클릭했으면 영상 플레이어가 해당 장면으로 넘어가서 보여준다거나 등등 일단 컨텍스트와 그걸 바꿀 함수를 선언 리액트 공식문서에는 한글로 모든게 다 있다 리액트 최고 js에는 () => {} 라는 문법으로..

팀 노션 페이지 중 일부 우리가 바라는 각 기능들이 제대로 동작하려면 function이 어떻게 굴러가야할 지 고민한 결과 이걸 구현하려면 유저 이벤트에 따라 값이 바뀌는 전역변수가 최소 두개는 필요하다. 더 늘어날 수도 있고... 리액트를 간단히 찍먹하며 느낀 것 하위 컴포넌트가 상위 컴포넌트로부터 정보를 받는건 쉽다 그냥 선언할 때 주면 됨 근데 하위 컴포넌트에서 변화가 발생했을 때 위로 정보를 올려서 갱신하는건 조금 귀찮은 우리 프로젝트에선 물론 후자를 구현해야 전체 페이지가 영상의 해당 장면 시간으로 동기화가 가능 프론트 팀원이 알려준 얘기로는 여러 방법이 있다고 한다 context 혹은 redux context를 쓰는 방법도 class 쓰기 vs function 컴포넌트에서 구현하기 등등 사실 뭐..

원래는 분석해서 시각화를 했으니 이제 하이라이트를 감지하는 알고리즘을 탑재할 계획이었다 하이라이트 포인트를 추천해주는 기능인 셈 그런데 중간발표에서 데이터 분석 툴에 가깝고 프론트단에서의 서비스적인 것이 전무하다는 비판을 들었다. 그래서 약간의 진로변경 기존 계획처럼 하이라이트 포인트를 추천하고 다운로드받는 사이트가 되면 프론트에선 아무리 잘해봐야 유튜브 음원추출해주고 영상추출해주는 원페이지 사이트급의 구현밖에 할게 없다 프리미어프로같은 UI로 웹 내에서 다양한 기능을 제공하는 에디터스러운 방향으로 가야 프론트가 뭘 했다는 것이 잘 보일 것 그리고 이걸 가능하게 하려면 팀장인 내가 알고리즘깎기에만 매달려서는 불가능하다 그냥 직전 포인트보다 일정%이상 뛴 부분을 추천하거나, 평균치보다 일정%이상인 포인트를..

수요일은 하루종일 발표 자료 제작 시연부터의 파트는 우리가 무엇을 구현했는지에 따라 달라지지만 시연 이전의 프로덕트 소개, 니즈 이해, 구현 방향 등은 최종발표때와 거의 같게 fix될 내용이니 최종발표 자료 만들듯이 각잡고 만들었다 시연 이후의 슬라이드는 개발 과정에 따라 바뀔 내용이니 적당히 힘빼고... 목요일, 발표날 슬라이드의 디자인적인 부분을 좀 다듬고, 팀원 앞에서 발표 연습 완전히 체화돼서 버퍼링 없이 머리에서 나오는 것에 대해선 발표를 유창하게 할 수 있는데 조금이라도 머리속에서 정리가 안된 부분은 바로 말문이 막힌다 학부장님 말씀대로 나라는사람이 원래 그런거라(ㅠㅠ) 고치긴 힘든 문제고, 항상 가능한한 머리속에 때려넣어서 해결해왔는데 정글에선 그러기엔 늘 시간이 부족해서 아쉽다 오후 15시..

중간 발표 피드백 1. 편집 에디터가 아니다. 데이터 분석 도구 수준에서 멈춰있다. 2. 데이터 분석을 더 깊게 들어가는건 정글 결과물로써 의미가 없다. 분석은 이쯤해도 충분히 잘 잡는다고 본다. 3. SW 엔지니어링적 노력을 발표에 서술하지 않았다. 해온 것, 만드려는 것들이 있을텐데 그것이 드러나지 않았다. 4. 발표를 꼭 리더가 할 필요는 없다. 발표 스타일이 논문발표식 모노톤인데 리액션, 임팩트가 있어야 한다. 5. 발표의 시연 전 파트, 시연 시나리오까진 좋았다. 뒷부분은 엎어야 한다. 피드백 분석 1. 편집 에디터가 아니다. 데이터 분석 도구 수준에서 멈춰있다. 원인 : 프론트와 백의 프로젝트 진행 단계 차이 할일 : '백의 분석을 가지고 그래서 뭘 제공할지' 프론트 빌드업 필요 현재 백엔드의..