Big Tree

레이어드 패턴은 백엔드에서 다룰 때 쓰는 패턴이다. 개인적인 생각으로는 MVC와 매유 유사하다고 생각한다. 보여주는 곳/로직 처리/디비 접근 3가지 파트로 나누어 처리하는 것인데, 이는 담당 위치를 분리함으로써 명확한 역할군의 분리가 눈에 띈다. 일반적으로 경력 백엔드 개발자들은 이렇게 작업하는게 "당연"한 것이나, 아무래도 백엔드 자체 특성상 신입이거나 배우는 단계인 사람들에게 지식이 타 계열에 비해 적지 않나 싶다. ㄴcontroller (Presenstation Layer) ㄴuser_controller.py ㄴservice (Business Layer) ㄴuser_service.py ㄴmodel (Persistence Layer) ㄴuser_model.py Presentaion Layer #ser..

Monolithic Service vs Micro Service 두 가지 아키텍쳐로 백엔드 구성이 나뉠 수 있다. 전자는 하나의 큰 줄기에 모듈단위로 작업이 처리되는 것이고, 후자는 기능단위로 여러 줄기로 나누어 작업을 처리하는 것이다. 현재 우리 서비스는 전자로 설계되어 있다. 하지만 이번에 마이크로 서비스로 변경하자는 제안이 있었고 해당 작업을 진행중이다. 이러한 작업을 진행하는 이유는 1. 가독성의 문제(=코드간 독립성 증대) = 사실 이건 모놀리식과 마이크로 간에 문제와는 결이 조금 다르지만, A 모델을 다루는 컨트롤러가 B 모델을 다루는 컨트롤러에 직접 접근하는 경우가 많아지면 보기에 매우 불편하다. 이를 서비스 단위로 나눈다면 조금 더 간편해진단 의견이 있었다. 2. 협업의 문제 = 협업하는 ..

플라스크는 정말 micro한 장점이 있다고 생각한다. 타 프레임워크에 비하면 구조나 세팅에 있어서 매우 자유롭다 즉 그만큼, 자동으로 해주는게 적다는 뜻이기도 하다(=내가 고생을 해야한다) 아무튼 Flask를 활용하다 보면 한 파일에 많은 양의 라우팅 함수가 모이는 경우를 볼 수 있다. @app.route('/users/') def show_users(page): users = User.query.all() return render_template('users.html', users=users) @app.route('/') def main(): return render_template('main.html') @app.route('/report') def report(): return render_temp..

임대 서버의 경우, 해당 서버 상태를 주시하고 문제가 생겼을 때 바로바로 처리가 가능해야한다. 지금이야 트래픽이 많이 발생하지 않지만 언젠가는 문제 생길 수 있다. 더불어 트래픽이 넘친다면 서버 스케일에도 변화를 줘야하기 때문에 더욱 중요하다. 따라서 현재 사용중인 슬랙에 메시지를 적용시키기로 했다. 프로세스는 다음과 같다 1. 서버 내 문제 발생 2. 모니터링 시스템 감지 3. 슬랙 채팅 전송 4. 앱으로 채팅 메시지 확인 여기서 1-3번을 내 로컬 서버에서 처리할 수 있는 시스템이 구축되어야 한다. 4번은 슬랙 앱이 알아서 해주니까. 찾아보니 슬랙 플러그인 중 웹후크라는 것이 있다. API로 텍스트를 JSON으로 전송하면 선택되어 있는 채널에 메시지를 날려준다. Slack app directory 에..

앱을 개발하다보니 푸시알림이 발생할 경우, 아이콘에 숫자 뱃지를 달아줘야 했다. 근데 이게 이렇게 복잡한 것인줄 몰랐다.... 괜히 Sendbird(채팅 API 회기업) 가 기업가치가 1조가 된게 아니다. 그냥 숫자만 달아주면 되는거 아닌가? 싶었는데, 고려할 부분이 너무나도 많고, 버그라도 발생하면 숫자 꼬이기가 너-무 쉽다. 우선 우리 앱은 푸시알림이 2가지 타입이다. 1.채팅 푸시 2.알림 푸시 (새 공지, 새 일정 등록 등등) 내가 생각한 루트는 2가지 이다. 1.서버에서 푸시를 날려서 local에 도착할때마다 local client에서 숫자++ 하는 것. 2.서버에서 푸시에 숫자값을 같이 날려 local client에서 보여주기만 하는 것. 당연히 전자가 처리하기 편하다. 서버는 푸시만 날리고 ..

나에게는 해보고 싶은 많은 사이드 프로젝트가 있다. 쓸모 없어보이는 것부터, 쓸모 있어보이는 것 까지 다양하다. (내기준) 1가지 프로젝트를 6개월 가까이 진행했고, 각종 대회나 지원사업 서류 처리에 바빴던 나는 다른 프로젝트를 가지고 리프레시를 해야겠다는 생각이 들었다. 그 중 가장 짧게 끝낼 수 있을 것 같아 보이는 주제를 가지고 기획부터 배포까지 진행했다. 중요한 포인트는 '빠르게 제작' 이었기에, 최소한의 기능들로만 구성했다. MVP (Minimum Valuable Product) 총 6/1 - 6/9 까지 걸렸으며 실질적으로 개발은 이틀(6/1, 6/2) 걸렸다. [1] 기획 (6/1) 기존의 크고 작은 개발을 진행하며, 초기 가이드 라인을 확실히 잡는게 중요한 것을 알게됐다. 사소한 기능의 추..

여러 프로세스를 사용하면, 같은 메모리 공간을 건드리는 경우도 있을텐데 그러면 문제가 발생할 것이다. 가령 남의 메모리 공간을 지워버린다거나.. 수정한다거나.. 코드를 캡슐화하는 것과 조금 비슷한 고민이라고 생각한다. 즉 Q. 어떻게 메인 메모리를 프로세스간에 공유할 수 있을까? Q. 어떻게 각각의 메모리들을 보호할 수 있을까? 이와같은 물음에 대해 우리는 가상 메모리 개념을 도입한다. 가상 메모리는 physical memory의 주소값을 갖는 형태로, 프로세스별로 각각 독립된 가상 메모리 공간을 가지면 physical memory에 가상 메모리에 담긴 주소값으로 접근하는 것이다. Virtual Memory -> Physical Memery 로의 전환은 MMU(Memory-Management-Unit)이..

"값이 싸면서 처리속도가 빠른 메모리는 없다" SRAM을 활용하는 캐시메모리는 값이 비싸지만 속도가 빠르다 > 0.5ns - 0.2ns per $500 - $1000 DRAM을 활용하는 메인메모리는 값이 싸지만 속도가 느리다 > 50ns - 70ns per $10 - $20 비싼 재료를 쓰면 맛은 좋지만 가격이 많이 나가는 원리랄까.. 이러한 메모리 처리속도의 문제는 컴퓨터 동작에서 문제를 일으킨다. 가령 CPU가 데이터 내놔!! 라고 소리지르는데, 램은 처~언~처~언히 주는 경우, 지연(latency)가 발생한다. 따라서 램보다 빠른놈을 중간에 둬서(캐시) 연산을 하면, 많이 쓰는 놈은 중간놈(캐시)에게 두면 좀 편안해진다. CPU < 캐시 < 메인메모리(RAM) < HDD 순서로 두는 것이다. CPU..

현재 스타링크 약 천여대가 우주에 쏘아졌다. 이로인해 우주쓰레기에 대한 비판적인 시각이 많아졌다. 우주쓰레기가 많아지면 결국 우리가 우주로 나갈 수 없게되고(로켓이 부딪히니까...) 그래서 인류가 자연소멸한다는 이론도 있다. 그럼 우주쓰레기의 주범인 위성들이 실제로 얼마나 간격을 붙여서 날아다닐까? (그래야 날아가던 로켓이랑 잘 부딪히니까..) 확인해보자 지구의 반지름은 6,371km 이고 이번에 쏜 스타링크 위성 궤도는 550km 이므로 위성이 궤도 반지름은 6,921km 이다. 겉넓이 공식이 2 pie r^2 이므로 위성궤도 겉넓이는 601,627,026 (km^2) 이 넓이에 스타링크 같은 위성들이 일정 간격으로 들어간다고 생각해보자 스타링크 목표는 30,000개인데, 뭐 이후에 여러 업체 약 1,..

Flutter 로 iOS에서 작업 중이다. FCM 사용중이고 최근에 앱 아이콘에 뱃지를 달아주기 위해서 background or terminated 상태에서도 동작하는 코드를 구현해야 했다. (ex. 메인 위젯에서 1, 2, 3 푸시 알림 쌓이는거 ...) firebase_messaging 패키지 8.0.0 버전을 썼는데, 문제는 해당 동작이 이뤄지지 않았다는 것이다. FirebaseMessaging.onBackgroundMessage(_firebaseMessagingBackgroundHandler); Future _firebaseMessagingBackgroundHandler(RemoteMessage message) async { AppIconBadger().add(); } *이때 콜백함수는 class..