(TIL) 2020-06-15 기록

오늘 한 일

• 오늘은 오전에만 코딩을 하고 쉬었다. 왜냐하면 주말에 갑자기 막혔던 부분이 생각나서 일요일에 자정부터 4시까지 코딩을 하고 10시에 일어나서 또 거의 밤 8시까지 코딩을 했다 보니 피로가 매우 많이 쌓였기 때문이다. 쉴 때는 확실히 쉬는 게 좋은 것 같다.
• 주말에 보이스챗 앱의 데이터베이스 구조를 짜는 데 시간을 많이 보냈다. Firestore는 Document 기반의 NoSQL 데이터베이스이기 때문에 기존의 SQL DB 스키마를 그대로 적용하기엔 무리가 있었고 어느 정도 참고는 할 수 있었다.
• 가장 난관이었던 것이 읽지 않은 메세지의 개수를 세는 것이었는데 이것은 유저 정보 내에 안 읽은 메세지 배열을 두고 배열의 원소를 <대화방 id, 안 읽은 메세지 개수> 형식의 map으로 만듦으로써 해당 대화방에 입장할 때 해당 원소릐 key값을 대화방 id로 검색해 그 값을 초기화 시켜주는 식으로 읽은 것을 처리하게 만들었다.
• 그리고 어제 오늘 작업한 내용은 새로운 공개된 보이스 메세지를 불러올 때 필터링을 어떻게 할지에 관한 것이었다. 이것은 아직 고민 중인 문제이긴 한데 공개 보이스 메세지 문서에는 음성 파일 레퍼런스, 게시일, 게시 위치 등이 있는데 파일 레퍼런스나 게시일 같은 건 한 번 만들어지면 정해지는 데이터이나 필터링을 해당 유저의 정보(평판이나 나와의 거리)로 필터링을 하려면 보이스 메세지 문서에 있는 작성자 id를 가지고 한 번 더 쿼리를 수행해야 한다. 물론 문서 id를 특정해서 하는 쿼리라 시간이 많이 걸리지는 않을 것 같기는 하다. 그래도 쿼리 횟수가 1회 증가하는 거지만 크게 보면 2배 증가하는 건데 이게 실시간 유저의 정보를 보이스 메세지 필터링에 반영함으로써 얻은 이득을 초과할지에 대해 고민해야 한다.
• 아직 Flutter에서 Firestore에 있는 데이터에 대해 Geoquery를 할 수 없다는 것을 알았다. 다시 말해 위치 정보를 가지고 필터링을 해서 쿼리를 수행할 수 없다는 것이다. 위도 경도 정보만 있지 이걸 가지고 어디와 가까운지 먼지 계산을 해서 쿼리를 수행할 수 없다. 그러다 flutter 패키지에 geofireflutter라는 게 있어 firestore에서도 geoquery를 수행할 수 있게 해준다. 이로써 특정 거리에 있는 사용자만 필터링 해서 메세지를 받는 기능을 구현할 수 있게 됐다.
• Rust의 Ownership(소유권?) 개념에 대해 배웠다. Rust는 힙 공간에 할당하는 데이터들에 대해서는 Ownership 개념을 적용한다. Ownership에 관한 규칙 몇 가지를 말해 보자면,
  • 한 데이터는 반드시 하나의 Ownership만을 가진다. 다시 말해 동시에 두 곳에서 한 데이터를 소유할 수 없다는 것이다.
  • Ownership이 없어진 데이터는 힙에서 제거된다. Ownership이 알아서 없어지게 되어 있는 데이터는 굳이 메모리에서 프로그래머가 제거해줄 필요가 없다.
• 이 Ownership은 누가 가지느냐? 쉽게 말하면 중괄호 안에 들어가면 그 중괄호 안에서만 그 변수를 소유할 수 있다. main 함수 내에서 선언한 변수라고 하더라도 그걸 바로 함수에 매개변수로 넣어주면 소유권이 함수로 넘어가게 되고 그걸 명시적으로 다시 반환해주지 않으면 소유권이 사라져 main에서 선언한 변수임에도 불구하고 그 함수의 실행이 끝나고 나면 메모리에서 사라진다.
• 이때 필요한 개념이 바로 borrowing(빌려주기)인데 약간 C/C++에서 참조 매개변수를 넘겨주는 것과 같다. 이 참조 매개변수도 mutable과 immutable이 있어서 mutable한 변수라 하더라도 immutable한 레퍼런스를 생성하면 이 레퍼런스로 접근해서는 변수를 변경할 수 없다. 그리고 한 변수에 대해 immutable한 레퍼런스와 mutable한 레퍼런스는 동시에 만들 수 없다. 그리고 immutable한 레퍼런스는 여러 개를 만들 수 있지만 mutable한 레퍼런스는 한 변수에 딱 하나만 만들 수 있다.
• 또 slicing에 대해서도 배웠는데 힙에 할당되는 자료형 변수들의 일부분만 사용하고 싶을 때 쓰는 이것도 하나의 ‘자료형’이다. String의 슬라이스형은 &str이고 배열의(예를 들면 i32형을 원소로 갖는) 슬라이스형은 &[i32]이다. 슬라이스의 좋은 점은 언제나 본 변수를 반영하고 있다는 것이다. 그래서 본 데이터가 변경되어 나중에 생성된 슬라이스가 의미가 없어지게 되면 컴파일 시간에 바로 오류를 잡아낼 수 있다.

내일 할 일

• 내일은 보이스 메세지를 필터링할 때에 실시간 유저 정보를 반영할 것인지 보이스 메세지가 생성될 당시의 유저 정보를 이용할 것인지 그 득실을 따져볼 것이다.
• 상대방 차단 기능, 개인 메세지 보내기 기능, 삭제된 대화 상대에 대해 다시 메세지를 보낼 수 있는 기능, 유저 검색 기능 등을 차차 구현해 볼 생각이다.