20210820(금) [항해 75일 차]

외로움은 주변에 사람이 없는 데서 오는 것이 아니라 
자신에게 중요해보이는 것을 전달하지 못하거나 
다른 사람들이 용납 할 수 없다고 생각하는 특정 견해를 가지고 있는 데서 옵니다.
- 칼 구스타프 융 -

 

memberStatus를 room에 포함하는 형식으로 변경했다. 원래 임베디드도 되어 있고, collection으로 따로 나와있기도 한 상태라 데이터의 중복 발생 및 중복 쓰기, 수정이 있었는데 이를 변경하여 쿼리문을 줄일 수 있게 되었고, API속도도 더 빨라졌으리라 생각한다.

카드 위치 수정하는 비즈니스 로직을 설명했더니 다들 주기적으로 요청을 받아오는 방식으로 하자고 하셨다. 

정보의 불일치가 있는 곳을 클릭했을 때 정보를 새로 받아올거냐 불일치가 있든 없든 주기적으로 정보를 새로 받아올거냐의 차이였다. 

전자는 사용자가 클릭하기 전에는 새로고침이 이러나지 않고, 후자의 경우 정보의 불일치가 존재하지도 않는데 요청을 보내는 것이 단점이다. 

나는 정보의 불일치가 일어나는 부분을 조작했을 때만 바뀌는 게 맞다고 생각했는데 다들 주기적으로 요청을 보내는 게 좋다고 하셨다. 카드가 복사가 되지는 않고 가장 마지막에 카드를 옮긴 사람의 명령이 되고 있어서 정보의 불일치가 크게 문제가 된다고 생각하지는 않으셨다. 확실히 내가 옮기고자 하는 위치가 있고 그것을 바로 조작하는 게 편한데 내가 생각했던 방식은 옮기고자 하는 위치를 정했다 하더라도 옮기고자 하는 카드가 최신의 카드 정보를 가지고 있지 않을 경우 새로고침이 되니 불편할 수 있겠다는 생각은 들었다. 그럼에도 불구하고 나는 정보가 불일치하다면 최신 정보를 받아오고 바꿀 수 있게 하는 게 맞아보이는데 나를 제외한 대부분이 다르게 생각하니 그 생각을 따라가기로 했다.

방 수정하기의 경우 누군가 수정 중 다른 사람이 못들어온다. 만약 이 때 비정상적으로 종료했을 때 다른 사람이 수정할 수 없는 버그가 있는데 들어갈 때의 시간값과 나갈 때의 시간값을 추가해서 넣어주면 해결할 수 있는 문제긴 하다.

InTime을 수정시작 시간, OutTime을 수정완료 시간으로 두고,

1. OutTime이 InTime보다 최신일 경우 수정 가능하다. 

2. InTime이 OutTime보다 최신일 경우 방을 수정중이라 들어갈 수 없도록 한다.

만약 다른 사람이 수정버튼을 눌렀을 때 서버에서 현재 시각과 방의 InTime을 비교 해 X시간이 지났을 경우 수정가능하도록 하고 InTime을 현재시각으로 리셋 시키는 방법이 있을 것 같다. 이 방법은 몇 시간으로 설정할 지가 중요하고, 만약 수정을 하는 도중 누군가 와서 또 수정을 할경우 마지막에 수정을 한 사람의 것으로 덮어쓰여지기 때문에 이것을 어떻게 해결할 지 결정해야한다. 

우선 수정 중이면 밖에서 봤을 때 ㅇㅇ님이 ㅇㅇ시 ㅇㅇ분 부터 수정 중입니다 라고 알람이 떠야되고 만약 긴 시간이 흘렀을 경우(혹은 시간은 덜 흘렀지만) 강제로 수정가능한 상태로 만들 수 있는 장치도 만들어야 될 것 같다.

임시 저장을 만들면 좋을 것 같은데 임시저장을 눌렀을 때 기능이 저장(기존 거 덮어쓰기)의 기능만 있다면 상당히 쉽게 구현될 수 있고, 이 경우 수정 중인 사람이 저장을 누르면 시간이 초기화 되어 InTime과 현재 시간과의 간격을 적게 잡아도 될 것 같다.

인트로 페이지에 올라갈 프로필도 올렸다. 

해야할 게 너무 많고, 하고 싶은 것도 많다. 타협이 필요한 시점이다. 

당장 다음주 화요일에 배포할 것 같고, 월요일에는 마케팅을 시작할 텐데 어디에 홍보할지, 경품은 누구에게 어떤 기준으로 무엇을 얼마나 나눠줄지 등을 생각하고 정해야 한다. 우선 알리는 것에 대한 비용은 우리의 노력만 들도록, 지인과 몇몇 커뮤니티를 통해 서비스 베타테스트(?)시작을 알리기로 했다. 버그 최초 발견자, 많이 쓴 사람, 모범사례 등등을 기준으로 경품을 지급할 것 같고, 노력이나 기여도에 따라 정도를 차등 지급하는 게 합리적으로 보인다.

배포를 할 때 자꾸 수정된 router는 보내는 데 Schema에 대한 것은 잊어버려서 프론트분들과 나의 시간을 동시에 잡아먹는 일이 생긴다. 상태메세지에 띄우고 배포할 때 마다 상기시켜야겠다.

테스트 코드를 작성 중인데 테스트 커버리지를 어떻게 보는 지 잘 모르겠다. 현재 20개 테스트 케이스 (약 16개 API)를 추가한 상황 속도가 좀 붙어서 이제부터 집중해서 빠르게 한다면 5분에 하나의 케이스 추가가 가능할 것 같다.

이것을 빨리 해야 배포 전 테스트케이스를 믿고 수동 테스트를 적게 할 수도 있으며, 어디가 제일 시간이 많이 걸리는 지 보고 연산 최적화를 어디부터 해야할 지도 쉽게 결정 할 수 있을 것 같다. 나아가서 TDD도 진행하고 싶은데 이번 프로젝트에는 할 일이 거의 없어보인다.

 

실패에 대한 것도 쓰고, 성공도 여러 케이스를 추가해야 하지만 우선 성공하는 케이스 API별로 하나씩만 추가하는 것이 목표

 

MongoDB의 각 요소들을 뭐라 불러야 되는 지 잊어버려서 다시 공부하려는 마음으로 찾아봤다.

 

MySQL 과 MongoDB 비교

Terms

RDB(MySQL)	MongoDB
Database	Database
Table	Collection
Tuple / Row	Document / BSON document
Column	Field
Table Join	Embedded Documents & Linking
Primary Key	Primary Key(_id)

 

Database Server

MySQL	MongoDB
mysqld	mongod

Database Client

MySQL	MongoDB
mysql	mongo

SQL

MySQL	MongoDB
Insert
insert into users ("name", "city") values("lee", "seoul")	db.users.insert({ name: "lee", city: "seoul" })
Select
select * from users where name="lee"	db.users.find({ name: "lee" })
Update
update users set city="busan" where name="lee"	db.users.update({ name: "lee" }, { $set: { city: "busan" }})
Delete
delete from users where name="lee"	db.users.remove({ name: "lee" })

 

 

다시 한번 살펴보는 SQL, NoSQL 차이, 좋은 커밋메세지

https://www.stevenjlee.net/2020/07/06/%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-nosql-vs-sql-%EA%B7%B8%EB%A6%AC%EA%B3%A0-nosql-%EC%9D%98-%EC%A2%85%EB%A5%98/

[이해하기] SQL vs NoSQL | STEVEN J. LEE

https://parkadd.tistory.com/41

SQL vs NoSQL (MySQL vs MongoDB)

 

https://blog.ull.im/engineering/2019/03/10/logs-on-git.html

ull.im