공부란 '머리 속에 지식을 쑤셔넣는 행위'가 아니라 '세상의 해상도를 올리는 행위'라고 생각한다. 뉴스의 배경음악에 불과했던 닛케이 평균 주가가 의미를 지닌 숫자가 되거나 외국인 관광객의 대화를 알아들을 수 있게 되거나 단순한 가로수가 '개화 시기를 맞이한 배롱나무'가 되기도 한다. 이 '해상도 업그레이드감'을 즐기는 사람은 강하다. 참고 글 그대들, 어떻게 공부할 것인가 그대들, 어떻게 공부할 것인가. (주니어, 중니어, 시니어의 공부방법은 같아야 할까?) charsyam@naver.com docs.google.com

이전에 했던 프로젝트에서는 구현을 1. 백엔드 단에서 바이너리를 쪼금 주무르고, api 화 시킴 2. 완성된 api를 통하여 화면 단에서 바로 불러오게 함. 이런 형식으로 구현했었는데.. 그럴 필요가 없다는 것을 알게 되었다. 인터넷 서칭해보면 양 단에서 blob 형태로 잔뜩 주무르고 있는 것들을 볼 수 있어서, 쉽게 쉽게 하는 방법을 포스팅해보고자 한다. 물론, 화면 단에서 서버로 이미지를 바이너리 타입으로 저장하는 것은 비슷한 방법으로 먹히는지 모르겠다. 현재는 "불러와서 화면에 뿌려주기"에만 집중한다. 1. 백엔드에서 이미지 파일을 가지고 온다. 그대로 가지고 옴. (가공 x) 2. 프론트엔드 단에서 해당 데이터를 확인해보면 바이너리 타입이 아니라 string 타입으로 가지고 올 것이다. 3. 프론..

https://yozm.wishket.com/magazine/detail/2198/

원가(cost)란? 어떠한 목적으로 소비된 경제가치를 화폐액으로 표시한 것. 재료비, 노무비, 경비로 구성되며, 이를 원가의 3요소라고 함. - 이것들은 다시 각 제품에 직접 부과할 수 있는 직접비와 여러 제품의 생산에 대하여 공통으로 쓰이는 간접비로 세분됨. 표준 원가 (Standard) * 미리 결정된 원가로 창고를 평가 * 예상 원가로 마진을 계산 * 표준 대비 실제 차이 (Variance:변화량) 로 발생 * 표준 원가로 조직 평가 (목표 대비...) * 경영 의사 결정 용도로 사용 * Cost Type 을 달리하여 여러 시뮬레이션 가능 평균(실제) 원가 (Average) * 가중이동평균 방식으로 창고 평가 * 표준원가 정의가 불 필요함 * 실제원가 방식으로 마진을 계산 * 과거 원가 자료를 통하..

1단계. 문제 이해 및 설계 범위 확정 기능적 요구사항 파일 추가. 가장 쉬운 방법으로는 구글 드라이브 안으로 drag-and-drop 가능하도록 파일 다운로드 여러 단말에 파일 동기화. 한 단말에서 파일 추가 시 다른 단말에도 자동으로 동기화 파일 갱신 이력 조회(revision history) 파일 공유 파일이 편집되거나 삭제되거나 새롭게 공유되었을 때 알림 표시 비기능적 요구사항 안정성: 저장소 시스템에서 안정성은 매우 중요. 데이터 손실 발생하면 안됨 빠른 동기화 속도 네트워크 대역폭: 너무 많이 사용하면 사용자 불편 초래 규모 확장성: 아주 많은 양의 트래픽도 처리 가능해야 함 높은 가용성: 일부 서버에 장애가 발생하거나, 느려지거나, 네트워크 일부가 끊겨도 시스템은 계속 사용 가능해야 함 개략..

1단계. 문제 이해 및 설계 범위 확정 아래와 같은 기능을 갖는 비디오 스트리밍 서비스 설계에 초점을 맞출 예정 빠른 비디오 업로드 원활한 비디오 재생 재생 품질 선택 기능 낮은 인프라 비용 infrastructure cost 높은 가용성과 규모 확장성, 그리고 안정성 지원 클라이언트: 모바일 앱, 웹 브라우저, 그리고 스마트 TV 개략적 규모 추정 일간 능동 사용자DAU 수는 5백만(5million) 한 사용자는 하루에 평균 5개의 비디오 시청 10%의 사용자가 하루에 1비디오 업로드 비디오 평균 크기는 300MB 비디오 저장을 위해 매일 새로 요구되는 저장 용량 : 150TB CDN 비용 클라우드 CDN을 통해 비디오를 서비스할 경우 CDN에서 나가는 데이터의 양에 따라 과금 아마존의 클라우드프론트C..

검색어 자동완성 (autocomplete, typehead, search-as-you-type, incremental search)에 관한 이야기. 1단계. 문제 이해 및 설계 범위 확정 요구사항 빠른 응답속도 : 사용자가 검색어를 입력함에 따라 자동완성 검색어도 충분히 빨리 표시되어야 함 페이스북 공식 문서 기준 시스템 응답속도는 100밀리초 이내여야 한다 연관성 정렬 : 시스템의 계산 결과는 인기도(popularity) 등의 순위 모델(ranking model)에 의해 정렬되어 있어야 한다. 규모 확장성 : 많은 트래픽을 감당할 수 있도록 확장 가능해야 한다. 고가용성 : 시스템의 일부에 장애가 발생하거나, 느려지거나, 예상치 못한 네트워크 문제가 생겨도 시스템은 지속 가능해야 함 개략적 규모 추정 ..

1단계. 문제 이해 및 설계 범위 확정 페이스북 메신저, 위챗(WeChat), 왓츠앱(WhatsApp) 처럼 1:1 채팅에 집중하는 앱, 슬랙(Slack) 같은 그룹 채팅에 중점을 둔 업무용 앱, 게임 채팅에 쓰이는 디스코드(Discord) 같이 대규모 그룹의 소통과 응답지연(latency)이 낮은 음성 채팅에 집중하는 앱 요구사항 1. 응답지연이 낮은 1:1 채팅 기능 2. 최대 100명까지 참여할 수 있는 그룹 채팅 기능 3. 사용자의 접속 상태 표시 기능 4. 다양한 단말 지원. 하나의 계정으로 여러 단말에 동시 접속 지원 5. 푸시 알림 6. 5,000만 DAU(Daily Active User: 일별 능동 사용자 수) 처리 2단계. 개략적 설계안 제시 및 동의 구하기 이 채팅 서비스는 아래 기능 ..

뉴스 피드 란? 홈 페이지 중앙에 지속적으로 업데이트 되는 스토리들로, 사용자 상태 정보 업데이트, 사진, 비디오, 링크, 앱 활동(app activity), 그리고 페이스북에서 팔로우하는 사람들, 페이지, 또는 그룹으로부터 나오는 '좋아요(likes)' 등을 포함하는 것 비슷한 유형의 문제로 페이스북 뉴스 피드, 인스타그램 피드, 트위터 타임라인 설계 등이 있다고 한다. 1단계. 문제 이해 및 설계 범위 확정 모바일 앱, 웹 모두 지원해야함 새로운 스토리 올리기 및 보기 다 가능해야한다. 피드 나열은 간단하게 시간 흐름 역순(reverse chronological order)으로 : 최신순 한 명의 사용자는 최대 5000명의 친구를 가질 수 있음 트래픽 규모는 약 1,000만명 피드에는 이미지나 비디오..

웹 크롤러란? 로봇(robot) 또는 스파이더(Spider)라고 부름 검색 엔진에서 널리 쓰는 기술로, 웹에 새로 올라오거나 갱신된 컨텐츠르 찾아내는 것이 주된 목적 -> 몇개의 Web Page 에서 시작해서 그 링크를 따라 나가며 새로운 콘텐츠를 수집한다... 크롤러가 이용되는 곳들 ? 1. 검색 엔진 인덱싱(Search Engine Indexing) 크롤러가 제일 보편적으로 사용되는 곳 웹 페이지를 모아 검색 엔진을 위한 로컬 인덱스(local index)를 만듬 ex) Googlebot - 구글(Google) 검색 엔진이 사용하는 웹 크롤러 2. 웹 아카이빙(Web Archiving) 나중에 사용할 목적으로 장기보관을 위해 웹에서 정보를 모으는 절차를 말함 ex) 미국 국회 도서관(US Librar..

1단계. 문제 이해 및 설계 범위 확정 예시 시스템의 기본적 기능 1. URL 단축기: 주어진 긴 URL을 훨씬 짧게 줄인다. 2. URL 리디렉션(Redirection): 축약된 URL로 HTTP 요청이 오면 원래 URL로 안내 3. 높은 가용성과 규모 확장성, 그리고 장애 감내가 요구 2단계. 개략적 설계안 제시 및 동의 구하기 API 엔드포인트 클라이언트는 서버가 제공하는 API 엔드포인트를 통해 서버와 통신 URL 단축기 - (일반적) 2개의 엔드포인트 요구 1. URL 단축용 엔드포인트 새 단축 URL을 생성하고자 하는 클라이언트 -이 엔드포인트에 단축할 URL을 인자로 실어서 POST 요청 POST /api/v1/data/shorten 인자: {longUrl: longURLstring} 반환:..

'auto_increment 속성이 설정된 관계형 데이터베이스의 기본 키를 쓰면 되지 않을까?' -> 분산 환경에서는 이 접근법이 안 먹힐텐데.. DB 한대로는 요구를 감당할 수 없음 -> 여러 DB server를 쓰는 경우에는 지연 시간(delay)을 낮추기가 무척 힘들 것 1단계. 문제 이해 및 설계 범위 확정 * ID는 유일해야 한다. * ID는 숫자로만 구성되어야 한다. * ID는 64비트로 표현될 수 있는 값이어야 한다. * ID는 발급 날짜에 따라 정렬 가능해야 한다. * 초당 10,000개의 ID를 만들 수 있어야 한다. 2단계. 개략적 설계안 제시 및 동의 구하기 분산 시스템에서 유일성이 보장되는 ID를 만드는 여러 가지 방법 * 다중 마스터 복제 (multi-master replicati..