로그인 API 구현 이후로는 채팅 API를 구현하게 되었다. 우선 실시간 채팅 API를 구현하기 위해 Firestore 에서 제공하는 document 변경 감지 기능을 사용하는 것을 고민해보았다. https://firebase.google.com/docs/firestore/query-data/listen?hl=ko Cloud Firestore로 실시간 업데이트 가져오기 | Firebase 의견 보내기 Cloud Firestore로 실시간 업데이트 가져오기 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. onSnapshot() 메서드로 문서를 리슨할 수 있습니다. 사용 firebase.google.com 채팅방에 해당하는 문서를 만들고, 그 문서 안에서 채팅 내역 데이터가 바..
https://www.acmicpc.net/problem/20055 20055번: 컨베이어 벨트 위의 로봇 길이가 N인 컨베이어 벨트가 있고, 길이가 2N인 벨트가 이 컨베이어 벨트를 위아래로 감싸며 돌고 있다. 벨트는 길이 1 간격으로 2N개의 칸으로 나뉘어져 있으며, 각 칸에는 아래 그림과 같이 1부 www.acmicpc.net 간단한 시뮬레이션 문제이다. 나는 생각을 어렵게 해서 쌩 배열로 구현해서 그런지 구현이 빡셌지만.. 난이도 매기는 사람들 의견보니 구현은 쉬운편이라고.. 그냥 덱 자료구조로 하면 더 쉽게 할 수 있을 것 같다. Python 리스트 (배열) 사용 풀이 배열과 리스트는 다르지만 사실상 리스트를 배열처럼 활용하여 풀었다. 나는 2N 개의 배열을 미리 잡아두고 '올리는 위치(put_..
핵심 기능인 아이 돌보기 / 돌봄 맡기기 데이터의 CRUD API 를 구현하였으니, 다음으로는 로그인을 구현하기로 했다. 로그인을 빠르게 구현한 이유는 각 유저마다 '아이 돌보기' 데이터를 하나만 생성할 수 있도록 세운 정책에 의해 '돌보기' 데이터의 생성 API 는 현재 로그인된 유저의 정보를 가져오도록 코드를 작성하여 로그인이 필요했기 때문이다. 구현을 시작하기 전에는 전에 플러터로 개발한 앱에서 Firebase로 로그인을 해봤으니 금방 구현할 수 있겠다고 생각했었으나, 막상 해보니 내가 03 있었던 점이 있었음을 깨달아서 난관에 부딪혔다. 클라이언트 Firebase vs 서버 Firebase 내가 착각하고 있었던 점은 플러터 + Firebase 로그인을 할 때는 플러터 앱(클라이언트) 에서 Fire..
API 명세 논의 24년 1월 8일, 사당 스타벅스에 모여 회의를 진행했다. 내가 작성한 명세서를 토대로 더 추가해야할 API 가 있는지, API 에서는 어떤 형식의 데이터를 주고 받아야 하는지를 논의하였다. 논의 결과 아래와 같은 형태로 데이터를 주고 받게 되었다. { "start_time": 1100, "date": "20240115", "child_age": 2013, "rating": 4.2, "address": "서울시 마포구 와우산로 70 홍익대학교 T동 702", "end_time": 2000, "email": "test2@example.com", "status": "waiting", "gender": "f", "id": "test2@example.com" } 이걸 논의하면서 프로젝트 기획의..
현재 상황 1. 학교 개발 동아리에서 팀 프로젝트를 하기 위해 레포지토리를 만들었는데, 처음에 만들 때 프론트와 백 레포지토리를 분리하지 않고, 하나의 레포지토리에서 모두 작업하며 만들었다. (프론트는 리액트 네이티브, 백엔드는 장고였는데, 이를 하나의 레포지토리에 통합해서 진행했다. 왜 처음부터 분리를 안했는지 묻는다면.. 동아리 활동 운영 정책상 분리를 하면 안되는 줄 알았기 때문이다.) 2. 그 상태에서 프론트도 커밋을 올렸고, 백엔드도 커밋을 올렸다. 3. 그런데 동아리 운영공지로 백엔드와 프론트 레포지토리를 분리해서 만들라는 공지를 받았다. 4. 단순히 백엔드 소스코드만 복사해서 새 레포지토리에 커밋을 할 수도 있겠으나, 그렇게 하면 지금까지 작업한 커밋들이 모두 사라지는게 아쉽다. 그래서 지금..
23년 10월, GDSC Hongik 에서 진행한 프로젝트 트랙에 참가하였다. 2달간의 Django 온라인 학습을 마치고 23년 12월 중순부터 본격적으로 '프로젝트' 활동을 시작하였다. 23년 12월 15일에는 같이 프로젝트를 진행할 팀 빌딩이 진행되었다. 백엔드 2명, 프론트 2명으로 이루어진 팀이었고, 나는 백엔드로 참여하였다. 프로젝트는 구글 솔루션 챌린지와 연계되어 진행하는 방향으로 기획되었다. 구글 솔루션 챌린지는 UN이 정한 인류 발전을 위해 해결해야 하는 17가지 문제를 위한 사회적 서비스를 2달 동안 만드는 챌린지이다. 처음에는 가볍게 학교나 일상 속 불편함을 해결할 수 있는 주제로 기획하면 될 줄 알았는데, 구글 솔루션 챌린지 조건에 맞는 주제로 고민을 하려고 하니 아이디어가 잘 떠오르..
벌써 2023년이 끝났다. 2022 회고를 쓴 지 얼마 안된 느낌..은 사실 없고 딱 1년이 지난 느낌이다 ㅋㅋ 2022년에 세웠던 목표 돌아보기 먼저 작년에 썼던 내년 계획을 한번 보면서 얼마나 지켰는지 돌이켜보았다. 1. 리액트를 다루는 기술 정독 사실 이 책은 전역하고 펼쳐보지 않았다..ㅎㅎ 그런데 리액트 하니 문득 생각난 게 작년까지는 프론트 할까 백엔드 할까 고민이 정말 많았는데, 요즘은 백엔드를 하고 싶다는 생각으로 많이 치우치게 되었다. 그렇게 생각한 이유는 다음과 같다. - 자바스크립트라는 언어가 별로 마음에 안든다. (타입스크립트는 그나마 괜찮은 것 같기도) - 리액트도 처음 겉핥기는 재밌는데, 파고 들고 싶다는 생각은 별로 안 들었다. - 리액트로는 '웹' 밖에 못한다. 물론 웹앱도 있..
정렬의 종류별 알고리즘에 대해 정리할 때, 기수 정렬의 시간복잡도는 O(N)이 나왔었다. 그런데 일반적으로 정렬의 시간 복잡도는 O(N log N) 으로 알려져있다. 어떻게 기수 정렬은 O(N) 시간에 정렬을 할 수 있었을까? 그리고 왜 일반적으로 정렬의 시간 복잡도는 O(N log N) 으로 알려져 있는 걸까? 한번 O(n log n) 시간으로 고정되어있는 merge sort 의 comparison 과정을 tree로 표현해보자. a, b, c, d 라는 4개의 데이터에 대해 merge sort 를 수행하면, 반씩 쪼개다가 merge 하는 과정에서 비교를 수행한다. 이때 비교를 통해 정렬을 수행하는 모든 경우의 수를 comparison tree 로 그려보자. 제일 먼저 비교가 일어나는 부분은 a, b 이..
방식의 비교횟수와 쓰기 횟수를 비교해보고자 한다. 병합 정렬 merge_sort() 함수의 호출시, 기존 배열을 복사해서 넣어놓고, 카운팅할 비교횟수와 데이터 쓰기 횟수를 초기화한다. mergeSort() 라는 재귀용 함수를 호출한다. 받은 배열을 반씩 나눠서 재귀적으로 mergeSort 를 호출하며, mergeSort 로 반씩 정렬된 결과를 다시 합쳐서 정렬할 merge 함수도 호출한다. 실질적인 정렬이 수행되는 merge 함수다. 먼저 반씩 정렬된 배열을 다른 배열에 복사해서 옮겨둔다. merge sort 를 배열롤 구현할 때 반드시 수행해야 하는 작업이기에, 이는 데이터 쓰기 횟수에 포함시켜서 카운팅했다. 그리고 기존 입력된 배열을 복사한 배열을 반씩 나눠 탐색하면서 작은값부터 채워나간다. 이 과정..
그림과 같이 100만개의 랜덤 성생된 정수가 있다. 이 정수를 각 정렬 방법으로 정렬해보려고 한다. (100만개를 N^2 시간에 정렬하면 시간이 오래 걸려서, 실제로는 100, 200, ..., 900 단위로만 정렬해 볼 것이다.) 정렬을 수행하면서, 비교는 몇번 일어나는지, 정렬을 하기 위해, 기존 배열에 (또는 새로 생성한 배열에) 데이터를 쓰는 행위를 몇번이나 하는지 횟수를 세보고자 한다. 이를 위해 먼저 100만개의 정수가 담긴 데이터를 ' ' 기준으로 끊어 배열에 저장한다. 그리고 각 정렬을 수행한다. 정렬은 사이즈가 100, 200, 300, ..., 900 인 상황을 매번 수행해보면서, 그 때의 비교횟수와 데이터 쓰기 횟수를 카운팅한다. 차례대로 정렬을 구현하고, 횟수를 카운팅한 결과를 출력..
