0814_retrospecitve

권민아

2023/08/14 - API 개발

오늘 한 일
1. 백엔드 주간 수업 - 물리적 데이터베이스 구조
2. 데이터베이스를 위한 ec2 인스턴스 교체
3. HTTPS 설정
4. API 명세서 수정 및 개발

아쉬운 점
1. 데이터베이스 공부하기
    - 오늘 주간 수업은 정말 모르는 내용 밖에 없어서 많이 반성했다. DB도 열심히 공부해야겠다.
2. API 개발 빨리 끝내기
    - 하고 싶은 일, 해야할 일은 많은데 손이 느린 건지 진도가 안 나가는 것 같다. 오늘은 그래도 열심히 했는데 정작 목표한 API 개발을 거의 못해서 슬프다. 마음 조급하게 먹지 말고 차분하게 해야겠다..

한마디
하루 출근 후 다시 휴일🥳🎉👏🎊

김유빈

* TODAY
- Hilt 공부 및 적용
- 코루틴 적용
- 서버통신 테스트
- 질문화면 ui
- 옵션화면 서버통신

*LECTURE : App Distribution
- Build variant
   - debug
   - release
- Gradle build output format
   - APK
   -AAB ~ apk를 split! -> gradle에서 설정가능
+) install(압축 풀리고 디바이스에 설치될때), download(앱스토어에서 다운받을때)
- App signing
   - Upload key : 개발자가 관리 (.jks -java key store)
   - App signing key : 구글이 관리
+) key path에 한글이 없게 주의!
- Firebase App Distribution
+) 버전별 변경사항을 잘 기록해두면 좋을것같다!

박세영

오늘 한 활동
 1. hilt 설정
 2. retrofit api 셋팅 
 3. retrofit typeadapter 에러 해결 
 4. trim api 연동

학습한 내용 
 1. hilt 사용법 (module class, Annotation)
 2. App Distribution

고민해야할 점 
 1. 오프라인 기능 
 2. api 호출 시점 
 3. 클래스 분리

더 학습해야 할 점 
 1.  프래그먼트 생명 주기

엄석훈

오늘은 백엔드 API가 일부 나와서 연동을 시작했다. 확실히 기존 UI구성할 때는 더미 데이터에 사진도 차량 이미지가 아니라 아무 이미지나 넣어서 화면을 보는 재미가 없었는데 오늘은 사진이 들어가니 확실히 재미있었다. 그리고 디자인에는 극단적인 경우에 대한 디자인이 없어서 직접 데이터를 가져온 상황에서 조금씩 수정하면서 화면에 맞게 맞추고 있다. 내일은 푹 쉬고 추후 API가 더 나오면 연동하면서 리팩토링도 해야겠다.

이승현

벌써 3주차다. 뭐지?
시간이 참 빠르다...
UI는 구현을 대충 완료했는데, 드디어 API 연동이 가능해져서 오늘부터 API연동을 시작했다.
패칭 해와서 사용하는데, 타입이 유니온으로 들어가서 타입단언이 필요했는데, 어떻게 해결하는지 결국 알지 못했다.
그래서 함수를 3개로 분기했는데, 분명 방법이 있을 것 같은데 !!! 일단 기능 완성 다 하고 리팩토링할 때 어떻게든 수정해봐야겠다 ㅜ

또 항상 고민이었던 트림페이지 모달은 왼쪽으로 띄우는 것으로 일단 수정했다. 아무리봐도 위로 띄우는건 UX적으로 별로라고 생각해서 ... -> 사실 기술적으로 구현이 힘들 것 같았다. 이거 하려면 구조를 완전 뒤엎어야 하는데, 지금 엎어버리면 그냥 멘탈도 엎어질 것 같아서 ...ㅎㅎ

아직 색상선택 API가 안나와서 연동은 못하지만(이 부분이 제일 만들고 싶었는데!) 그 대신 내일은..쉬고 그 다음날에 공통 컴포넌트로 빼고 싶었던 부분들 빼서 전체적인 코드 리팩토링을 좀 일찍 진행할 생각이다.
수고!

최규현

### <의식의 흐름>
- 내일 공휴일이라 기분이 좋다…최고.. 오펜하이머 볼 생각에 설렘
- 잠을 7시간 잤을 때가 제일 학습 효율이 잘나오는 거 같다. 오늘 잠을 7시간 잤기 때문에 육체적으로도, 정신적으로도 공부하기 좋은 컨디션이었다.
- RESTful한 API가 무엇인지 고민하느라 시간을 쏟아서 목표했던 API 개발이 안됐다. 저녁 빠르게 먹고 마저 개발해야겠다.
- 개발하는 것보다 기획 보면서 네이밍하는 게 더 고민되고 어려운 거 같다….

### <호눅스님 강의 - 물리적 데이터베이스 구조>
- 하드디스크 ⇒ CHS 구조
    - Cylinder, Head, Sector
    - 암 ⇒ Track 선택
    - 분당 회전수 RPM 7200
    - Sector 별 영역은 크기가 다르지만 용량은 같음 (다르면 Sector 별로 회전 수가 달라야해서 복잡해짐)
    - Locality 덕분에 random 접근에 비해 순차 접근이 더 빨름
    - 요즘엔 HDD 씀
- `CREATE DATABASE` 하면  하드 디스크에 db이름으로 directory가 생김
- `CREATE TABLE` 하면 DATABASE 안에 table이름으로 file이 생김
- InnoDB가 지원하는 MVCC란?
    - ??????
- *Row Store*
    - 기본적으로 RDB는 레코드(row) 단위로 저장
- *Column Store*
    - 빅데이터의 경우 Column Store로 사용하기도 함
- Clustered Index
    - 인덱스가 아닌 자료구조임 ⇒ Root PAGE ~ Leaf를 지나 Data PAGE까지 모두 통칭함
    - Data Pages는 모두 정렬해서 저장함ㄴ
    - TABLE 생성하면 기본적으로 PK에 대해서 인덱스가 만들어짐
    - B+Tree
    - **IO의 기본 단위인 PAGE 사이즈로 노드 하나의 크기가 정해져있음 (16KB) ⇒ ‘HDD’를 고려한 최적화**
- 하나의 페이지 안에서 데이터를 어떻게 찾아갈까?
    - slot을 도입하고 b+tree에는 leaf 노드에 RID 저장 (RID ⇒ page 번호 + slot 번호)
    - slot 번호를 page 크기의 파일 앞에 두면 크기의 한계를 갖음
    - (heap이랑 stack이 가변적으로 크기가 증가하다가 만나는 거처럼) slot을 맨 끝에다 두기
    - slot 공간에 free slot 개수랑 남은 size 등 meta data가 존재
    - 사실 삭제할 때 페이지 지우는 게 아니라 delete 플래그로만 처리함
    - 그래서 공간을 차지해서 해당 자리에 insert 못함 *“하지만 편했죠?”*
    - 추후에 느린 작업인 compaction을 사용해서 해당 공간 쓸 수 있게 해줌
- 비클러스터 인덱스에 RID가 아닌 PK값이 있는 이유는?
    - 특별한 이론적인 배경이 있는 게 아니라 경험적으로 구현했더니 이게 좋더라
    - (100만 개의 데이터 있으면 대충 B+tree에서 depth가 3개정도임 (3개도 거의 없다))
- 실제 DB가 어떻게 동작하는지 알기 위해서는? ⇒ PostgreSQL 뜯어보기 (MySQL은 코드 더러움)