★2차 프로젝트 회고(feat. 트러블 슈팅)

 

1. 금요일 10시에 발표 끝나니 진이 빠져서 회고를 바로 못 쓰고 주말에

다시 프로젝트 되짚어보며 쓰기로 했다.

 

2. 내가 했던 일

 

여기에 자잘 자잘한 부분을 뺐다

골고루 일한 모습을 어필하려고 서로 일한 양을 맞추자고 얘기를 했다.

 

 미로에 데리고 들어가서 같이 기획했던 부분,  인앱 알림 구현과,

 fcm 설정 부분, 리버팟을 공부하고 상태관리를 실시간으로 했던 부분을 뺐다.

하나씩 상세히 되짚어 보는 시간을 가져야 겠다.

 

(1)전에 기획 일을 했던 사람이 있어서 같이 프로젝트 한 적이 있었다.

그때 미로에서 기획했던것을 가져와서 팀원들 데리고 어떻게 했는지, 되짚어가며 기획을 했다.

아이디어가 꽤 괜찮게 나왔는데 도움이 되었던거 같다. 10시부터 6시 정도까지 걸렸는데

내 생각에 다음 프로젝트는 기획 하루종일 해도 좋을거 같다.

 

 

 

(2)  몇일간은 리버팟 강의를 들으면서 상태관리에 대해 공부했다.

 

강의가 너무 어려웠다. 고급 강의라고 할만한 정도였다.

꾸역꾸역 들었는데, 리버팟을 바로 사용할 거라고 생각하니 좀 더 집중이 되었다.

고급 강의라서 내가 나중에 반복해서 들어도 좋다고 생각한다.

 

(3) 투표결과를 담당했다.

리버팟을 적극적으로 썼다.

 

UI 는 훈련을 많이 해서 빠르고 이쁘게 잘 뽑아낼 수 있었다.

결과를 실시간으로 끌어와야해서 리버팟을 많이 쓰게 되었다.

저번 프로바이더를 쓸때보다는

좀 더 부르럽고 빠르게 결과가 나오는 모습이 보였다.

또, 프로바이더 를 사용할때는 호출하면서 서로 호출주고 받고 하다 무한 루프에 빠지기 쉬웠고,

호출 순서나 그런 부분에서 NULL 값이 나오곤 했다.

 

하지만 리버팟을 쓸때는 좀 더 깔끔하게 실시간으로 상태 관리를 하고 결과를 바꿀 수 있었고,

STATEFUL 위젯을 쓸때보다 에러가 훨씬 적게 났다.

 

(4) FCM 을 했는데 고생이 많았다. 대부분의 시간을 여기서 썼다.

양이 많아서 따로 링크 첨부로 대신해야 겠다.

https://kook1488.tistory.com/47

fcm 구현 과정

 

 

(5) 그 다음 페이스북 로그인을 구현했다.

컴퓨터가 꺼져서 고생했다.

구현만 해 두었다.

https://kook1488.tistory.com/46

페이스북 로그인 과정

 

(6)인앱 알림도 구현했다.

푸쉬알림을 오도록 설정을 바꾸면 인앱 알림이 오도록 했고

설정을 하면 FCM이 오지 않도록 했다.

 

https://kook1488.tistory.com/49

인 앱 알림 구현 과정

(7) 시연영상. 마무리를 위해 끝까지 컴퓨터를 붙들고 있었다!

원테이크로 찍으려니 너무 오래 걸렸다. 목소리는 따로 녹음해서 덧입히는 방법을 찾는게 좋을 것 같다.

 

시연영상을 대본을 보며 찍었다

버튼 클릭과정 숙달하고 오류없이 잘 진행되도록 해야한다.

대본 미리 작성해서 숙달하되, 외워서 하려고 하면 너무 오래 걸린다.

 

다음에 영상 자체에 대사도 넣고 옆에 확대도 해주면 좋을 것 같다.

시연영상 뒤에 어울리는 배경화면 해두고

유투브에서 어울리는 음악 찾아놔서 같이 틀었다.

 

capcut 으로 빨간 동그라미 붙이기
임포트 해서 가져오고 +- 로 영상 세분화 조절하고
circle 검색해서 동그라미 붙였다.

https://www.youtube.com/watch?v=QRmmQ4X6ecA

 

(8)발표 역시 준비 많이 했다 대본을 쓰고 15분 안에 들어가도록 했다. 

요점이 정확히 전달 되도록 연습했고, 발표 4시간 전에 리허설을 해서 피드백을 받았다.

피피티 넘어가는 속도가 마이크로 말이 넘어가는 속도와 맞지 않아서 싱크 조절을 해야했다.

팀원이 끝나고 '발표가 더할 나위없었다' 고  했다.

!!!슬라이드추가버전_발표용PPT_UP_DOWN!!!.pdf

12.72MB

 

 

3.  여러가지 트러블 슈팅

 

 

 

(1) 채팅방이나 홈화면이 수정되었을때 투표결과창이  에러창으로 바뀌었다.

string 으로 타입문제인데 이를 엮여있는 채팅방에 타입 변화를 통해 해결했다.

 

(2) api요즘 container resistry : docker 

 

이게 서버리스 개념과 연관되어있는 건데, 파이어베이스는 펑션은 서버리스라서

요청을 할때 서버를 잠깐 킨다. 이떼 container resistry : docker 가 서버 배포할때마다

취약점 검사를 하면서 이미지를 싹 훑고가서 비용이 많이 청구되었다.

 

결제에서 취약점을 해제하니깐 해결 되었다.

 

 

(3) 페이스북 로그인을 하는데 토큰 값에 대해 string 자체로 받지 않다보니 계속 에러가 났다.

    access token에서 token을 눌러서 해당 함수로 직접 찾아간다음에 거기에 맞는 값으로 바꿔주었더니 해결되었다

  string으로 바꾸니깐 해결되었다.

 

 

(4) 테스트 알림을 보내면 오는데 실제 fcm을 쓰니 구현이 되지가 않았다.

그 이유가 펑션을 배포하지 않아서인데,
테스트 메세지처럼 직접 토큰 값을 넣으면 나오길래 그냥 본인의 토큰확인만 되면 알림이 가는중알고

배포하지 않은 상태로 코드만 계속 바꾸면서 해결하려고 하다보니 시간이 너무 많이 걸리게 되었다.

코드상의 에러는 없었는데 구현이 안됬다

많은 소스 코드를 참고해도 안되는게 다 이유가 있었다.

 

나중에  firebase function  을 배포하니 한걸음 나아가게 되었다.

미리 firebase function 개념을 좀 알았으면 수월했으거라 생각한다.

(5) 펑션을 배포해도 실제 fcm 알림이 오지가 않았는데

이유를 찾으려고 모든 과정마다 로그를 붙여 확인했다

 

알고보니 fcm 토큰을 회원가입한 모든 유저정보에 저장을 해놔야 했다.

그래야 그 토큰값을 통해 알림을 보낼 수 있는것이였다.

토큰을 찾을수 없으니 inter 에러가 발생했던 것이다.

우선  index.js 를 통해 유저정보에 앱을 설치하고 킬때  유저 각자의 토큰값이 저장되도록했다.

그리고 fcm함수로 토큰을 받아 알림을 보내는 함수를 구현하도록 했다.

 

index.js 가 뭔지 잘 몰라서 코드 바깥의 오류가 계속 났던거 같다.

서버에서 토큰을 주고 받고 알림을 보내는 '과정'을 알아두었으면 일이 더 빨랐을 거라고 생각한다.

 

4. 마무리 

팀원들에게서 1.8 인분 몫을 했다는 감사인사를 들었는데 그거면 족하다.

재능있다고도 얘기를 들으니 그걸로 만족하다.

 

이주간 혼을 갈았다...!

팀장을 해보면서 이전에는 생각하지 못했던 부분들이 많이 눈에 밟혔고,

서로 다른 사람들을 하나의 팀으로 만들기 위해 협업하는 요령을 많이 갈고 닦을 수 있는 기회가 되었다.

 

공부를 해가며 실력이 늘수록 일이 더 쉬워질 거라고 생각을 했었는데,

오히려 아는게 많아진 만큼 향상시켜야 할 것들이 더 많이 눈에 보였다.