/Lets-Study

아 대체 뭘 공부해야 될까 싶다면?

Apache License 2.0Apache-2.0

Lets-Study

나만 읽기 아까운 글이나 문서를 모아두는 공간입니다. 어떤 주제를 공부하거나, 공부의 방향을 잡거나, 그냥 가볍게 읽기 위한 재밌는 글을 원하는 누군가가, 양질의 글에 쉽게 접근할 수 있도록 도와주는 것이 이 저장소의 목적입니다.

의식의 흐름으로 나눈 카테고리에, 링크로 이루어진 리스트 형태로 구성됩니다. 일단 링크 막 모아두고, 한번 읽고 나면 이게 어떤 글이고 왜 추천하는지를 간략하게 작성하고 있습니다.

여러분도 북마크에서 몇 개만 공유해 주세요. 레포 주인이 공부하는 분야가 넓지 않아서, 별 거 아닌 것처럼 보이는 기여더라도 큰 도움이 됩니다.

배경지식

그냥 배경지식

  • Microservices with gRPC
  • 함수형 프로그래밍이란?
  • 검색엔진최적화(SEO) 쉬운 가이드
  • 정규표현식의 개념과 기초 문법
    sooop님의 블로그는 개념에 대한 정의가 깔끔하고, 쉬운 설명에 비해 많은 지식이 들어오는 가성비 높은 글 천지라 개인적으로 마음속 1순위 블로그인데, 감사하게도 정규 표현식에 대해서도 써 주셨다.
  • regexr - 정규표현식을 연습할 수 있는 playground
  • Date and Time
    • 협정 세계시(UTC)
      세계 표준시. 우리나라는 여기에 9시간을 더한 KST라는 한국 표준시를 사용한다.
    • 유닉스 시간
      Epoch(1970-01-01T00:00:00Z)로부터의 경과 시간을 초로 환산하여 정수로 나타낸 것. 여담으로 timestamp는 '시각을 나타내는 문자열'이라는 다소 큰 범위의 정의를 가지고 있어서, 1256953732같이 생긴 건 unix time이라고 부르는 것이 가장 정확하다. Sat Jul 23 02:16:57 2018같은 것도 타임스탬프라고 부르기 때문.
    • List of tz database time zones
      시각을 표기하는 곳에서 KST, CST, EDT같이 timezone에 대해서는 약어만 마주치며 살다가, PrestoDB에서 Asia/Seoul같은 표현을 보고 이리저리 찾아보니 timezone의 약어는 표준이 따로 없다고 한다. 그래서 timezone 약어 목록으로 가장 유명한 Time Zone Abbreviations를 찾아봤더니 CST가 미국 중부 표준시, 중국 표준시, 쿠바 표준시를 모두 나타내는 등의 모호함이 있었다. tz database time zones라는 이름을 가진 해당 링크는 그 이름처럼 IANA TZDB에서 사용하는 타임존 목록을 그대로 가져와 정리한 것인데, 약어 대신 Asia/Tokyo, Europe/Lisbon처럼 지역명을 사용하고 있다. 이게 타임존을 다루는 데에 사실상 가장 현실적인 방안이라고들 생각하는 것 같다.
    • ISO 8601
      2018-11-13T22:36:38+09:00처럼 생겨먹은, 시간에 대한 i18n 처리를 할 때 거론되는 날짜와 시간에 관련된 국제 표준. format이 한가지 종류가 아니라는 점(날짜를 YYYY-MM-DD로 표현하는 경우도 있고, YYYYMMDD로 표현하는 경우도 있으며 시간이 UTC라면 +00:00 대신 Z를 쓸 수 있다.)과 timezone에 대한 표기 없이 UTC와의 시차만 표현한다는 점이 흥미로웠다. 어딘가 시간이 들어가는 곳에서는 그냥 KST로 저장하고 2018-11-13 15:31:10처럼 표현했는데, 모든 시간을 UTC로 저장하고 ISO 8601 포맷을 사용하는 게 가장 확장성이 높을 듯. 동일한 시간대에서 통신 시 지역 시간을 가정하는 것이 편할지라도, 서로 다른 시간대 간의 통신에서는 애매할 수 있을테니 ISO 8601 포맷을 사용하여 UTC에서 얼마를 더해 이 시각이 나왔는지를 알려주는 것이 좋을 것이다.
    • What's the difference between ISO 8601 and RFC 3339 Date Formats?
      'RFC 3339 is listed as a profile of ISO 8601. Most notably RFC 3339 requires a complete representation of date and time (only fractional seconds are optional).'
  • What are the differences between server-side and client-side programming?
    서버 사이드/클라이언트 사이드 렌더링에 대한 이야기. 보통 렌더링보단 프로그래밍이라는 단어로 통하는 것 같다.
  • Drop-in replacement
    적은 노력으로 보안/성능/기능/확장성을 향상시키는 것. 예로 Python의 빌트인 시간 라이브러리인 datetime의 drop-in replacement로 arrow, pendulum이 있다.
  • What is difference between LRU and LFU?
    캐시 구현 방법 중 LRU(Last Recently Used)와 LFU(Last Frequently Used) 캐시의 차이에 대한 설명이다. 이 외로 rr cache, ttl cache가 있다.
  • How does MQTT protocol work?
    publish/subscribe 방식의 메시지 큐. 프로토콜에 가까운 것 같다. 일반적으로 알고 있는 pub/sub 패턴처럼, publisher는 토픽을 발행하고 subscriber는 관심 있는 토픽을 구독한다. 메시지는 broker가 관리한다. Facebook Messenger가 MQTT를 사용하는 것으로 유명하지만 지금까지도 쓰고 있는지는 잘 모르겠다. 오픈소스 MQTT 브로커로 mosquito를 사용하곤 한다. Firebase Cloud Messaging(FCM)도 MQTT 구조인가? 싶었는데 얘는 웹소켓이라고 함. 나중에 채팅 구현할 때 MQTT 써봐야겠다.
  • Protobuf
    .proto라는 확장자를 가진 파일에 스키마를 명시하고, 이걸로 직렬화/역직렬화하는 데이터 직렬화 포맷. RPC에서 많이 쓰인다고 하며 타다가 Protobuf를 쓰고 있다고 한다. .proto 파일로 스키마를 명시하게 되면 validation rule도 정의하고 문서화도 되고 클라이언트는 이거 컴파일해서 DTO 만들고 해줄수 있어서 꽤 편할듯. HTTP mimetype에선 application/vnd.google.protobuf나 application/x-protobuf같은 걸 쓴다는데, 그냥 protobuf message를 JSON으로 주기받기도 하는 것 같다.
  • Google Protocol Buffers and HTTP
    'Just write the bytes of the protocol buffer directly into the request/response, and make sure to set content type to "application/octet-stream"', 'ProtoBuf is a binary protocol.'
  • What's the difference between ISO 8601 and RFC 3339 Date Formats?
    시각 데이터를 표현하는 표준이 대표적으로 두가지(ISO 8601과 RFC 3339)가 있는데, 이 둘의 차이에 대한 질문. 'RFC 3339 is listed as a profile of ISO 8601. Most notably RFC 3339 requires a complete representation of date and time (only fractional seconds are optional).'이 핵심 문장.
  • Newline delemited JSON is awesome
    'ndJSON is a collection of JSON objects, separated by \n'이 핵심. 종단 간 통신 레벨에서 쓰일만한 건 아닌 것 같고, JSON으로 이루어진 data collection을 관리할 때 좋을 것 같다. MongoDB에서 특정 collection에 모여 있는 document 목록은 NDJSON으로 표현할 수 있을테니까.
  • DNS
  • Facebook Account Kit
    SMS, 이메일을 통해 passwordless authentication을 할 수 있도록 도와주는 페이스북의 킷. SMS 인증이 한 달에 10만회까지 무료라길래 흠칫해서 알아보게 됨. Auth0라는 서비스도 이런 컨셉인 것 같은데, Auth0가 먼저고 Account Kit이 나중인듯.

동시성 프로그래밍

  • 파이썬과 비동기 프로그래밍 시리즈
    파이썬은 그렇다 치고 그냥 비동기 프로그래밍 자체에 대해 훑어보기 좋은 글.
  • 멈추지 않고 기다리기(Non-blocking)와 비동기(Asynchronous) 그리고 동시성(Concurrency)
    파일이나 네트워크 등과 같은 I/O bound 작업에 대해 처리의 완료를 기다리지 않고, 후속 작업을 처리하는 부분만 콜백이나 await 등을 통해 따로 정의해둔 채 CPU를 다른데서 계속 써먹으며 자원 낭비를 줄이는 패턴을 Non-blocking IO라고 부르고, Non-blocking IO는 Async IO라고도 부른다고 한다. + 프로그램의 주 실행 흐름(메인 루틴)을 최대한 적게 멈추면서 뭐라도 계속 처리하는 걸 Async programming이라 부르고, 이를 위한 재료로서 Non-blocking IO를 활용할 수 있으나 둘은 관점이 다르기에 비교 대상이 되기는 어렵다는 내용. 비동기 IO에 비해 비동기 프로그래밍은 좀 더 추상적인 개념인 듯 하다.
  • 비동기 파이썬
    Hackernoon에 작성된 Asynchronous Python을 번역한 글. 멀티스레딩에서 경쟁 상태나 데드락 등등은 어떻게든 해결할 수 있으나 context switching의 자원 낭비는 어째 해결할 수 없어서 비동기 프로그래밍이 설계되었다는 내용을 시작으로, Python을 기준으로 해서 그린 스레드부터 콜백 스타일, asyncio와 async/await 문법까지 차근차근 설명되어 있다.
  • asyncio : 단일 스레드 기반의 Nonblocking 비동기 코루틴 완전 정복
    asyncio를 조금 더 큰 그림에서 바라본다. 결국 이는 NodeJS가 밀고 있는 non-blocking 비동기 처리에 더 근접하는 개념이다.와 같은 내용처럼.

코딩이나 패턴에 관한 얘기

  • Why is global state so evil?
    전역 변수가 왜 나쁜지에 대한 이야기
  • So Singletons are bad, then what?
  • 코드 커버리지 80% 넘긴 썰 - 테스팅을 잘 하기 위한 8퍼센트 개발팀의 삽질기
  • 점진적인 레거시 웹 어플리케이션 개선 과정
  • Higher-order-function(고차함수) with Kotlin
    인자로 함수를 취하거나, 결과로 함수를 반환하는 함수. HOF라고도 부른다. 이게 수학에서도 있는 개념이라고 함. Java에서 메소드에 overrided method가 포함된 익명 클래스를 만들며 그 객체를 넘겨주는 것도 HOF라고 부를 수 있을까?
  • Currying
    f(x, y, z)를 f(x), g(y), h(z)와 같은 함수 체인으로 만드는 기법. '인자가 미리 채워진 함수'를 만들어 코드의 추상화 레벨을 높이기 위해 써볼만 하지만, 내 경우에는 currying의 주 목표인 '인자를 나누어 함수의 처리를 점차 진행시킨다'를 만족시킬만한 함수를 작성하는 경우가 거의 없었던 것 같다. 차라리 partial function을 쓰는 경우가 더 많은 듯.
  • 함수형 프로그래밍: partial application과 curry
    partial application, currying의 소개와 둘의 차이를 설명한다. partial application은 특정 인자를 고정시킨 새로운 함수를 만드는 기법. 수학의 부분 정의 함수와 연관이 있는 것 같다.
  • 람다, 익명 함수, 클로저
    람다, 익명 함수, 클로저를 연관지어 매우 깔끔하게 설명해 두었다. 클로저는 closer가 아니고 closure(폐쇄)이며, 함수형 트릭이 아니라 개념(함수와 그 함수가 선언된 lexical scope의 조합)이다. 클로저는 자신이 정의된 문맥에서 주변의 변수와 상수들을 캡처한다.
  • Exression verses Statement
    expression은 identifier, literal, operator만을 포함하며 value를 산출하는 식이고, statement는 동작을 수행하는 문이다.
    • Python의 삼항 연산자는 expression이다. - res = 1 if True else 0
    • JavaScript에서 함수는 expression으로 사용할 수 있다. - const sum = function(a, b) { return a + b; };
    • Kotlin의 when 절은 expression과 statement로 모두 사용할 수 있다.
  • 자바스크립트의 호이스팅(Hoisting)
    이게 참 프로그래밍 자체에 전반적으로 이야기할 수 있는 개념인데 클로저나 스코프같은 건 JS에서 많이 이야기하고, Higher order function같은 건 kotlin에서 많이 이야기하고, 코루틴은 go에서 많이 이야기하고 그런 경향이 있어서 어쩔 수 없이 호이스팅에 자바스크립트 얘기를 가져왔다. 웬만한 언어에서 declaration은 호이스팅되고, assignment는 호이스팅되지 않는 것 같다. 대부분 호이스팅이 '작성한 코드의 상단으로 옮겨지는' 것으로 설명되지만, 그냥 컴파일 단계에서 평가되기 때문에 그렇게 보여지는 것이다.
  • DRY code vs. WET code
    소프트웨어 개발 원칙 중 하나지만, DRY 원칙을 지키는 건 프로그래밍의 기본이 아닐까 싶다.
  • 코루틴 소개
    프로그램의 메인 실행 흐름을 메인루틴이라 부르고, 일반적인(call/return 형태의) 함수는 서브루틴이라 부른다. 여기서 이 함수가 suspend/resume 기능을 지원한다면 이를 코루틴이라 부른다. suspend로 제어를 양도하고, resume으로 다시 실행을 재개하는 형태. async/await도 사실상 이런 개념 기반이므로 비동기에 코루틴을 종종 써먹는 듯. 그래서 아무튼 함수는 서브루틴 형태와 코루틴 형태로 나뉘며 코루틴은 또다시 대칭/비대칭 코루틴으로 나눌 수 있다.
  • Function scopes and block scopes in JavaScript
    JavaScript에서 var는 function scope에서 보장되고, let는 block scope가 가능하다는 이야기인데, scope는 애초에 프로그래밍 언어 자체적인 이야기라 볼만 하다. function/block scope, lexical(static)/dynamic scope 등등.. 스코프 얘기는 재밌는 것 같음.
  • What is a pure function?
    same input-same output과 외부 상태에 변화를 주지 않는(no side-effect) 함수를 순수 함수(pure function)라고 부른다.
  • WTF is Memoization
    in-memory caching이라고도 볼 수 있는 메모이제이션에 대한 이야기. 'Avoid doing the same work repeatedly to avoid spending unnecessary running time or resource'라는 문장이 핵심이다.
  • What is the difference between Caching and Memoization?
    Caching은 'general term', Memoization은 'specific form of caching'
  • Static/Dynamic vs Strong/Weak
    정적/동적 타입 검사와 강타입/약타입에 대한 이야기. static/dynamic typing은 'when type information is acquired', strong/weak typing은 'how strictly types are distinguished'로 요약하고 있다.
  • 10가지 소프트웨어 아키텍처 패턴
    이게 뭔가 서비스 관점에서의 패턴 이야기가 아니라, 그냥 아키텍처 자체에 대한 이야기. 역시 패턴 얘기는 재밌는 게 많다.
  • Runtime vs Compile time
    런타임과 컴파일 타임의 비교.

디자인 패턴

백엔드에 가까운

  • Docker
  • 아키텍처 이야기
  • Map AWS services to Google Cloud Platform products
  • 채점 현황 속도 올리기 - 스타트링크
    백준 온라인 저지(BOJ)에서 채점 현황 페이지의 속도를 올리기 위한 경험이 담겨 있다. real world에서의 쿼리 튜닝에 관한 이야기라 재밌게 본 것 같다.
  • ipify: 300억 요청 처리, 그 너머로
    IP 주소 검색 서비스인 ipify를 Node.js로 개발하고, 성능에 문제를 겪은 뒤, Go로 API를 다시 작성해 문제를 해결한 이야기. 월간 200 달러로 300억 요청 처리. Go에 뽐뿌가 오게 만드는 글이다. 근데 Node.js가 왜 훨씬 느렸는지가 구체적으로 안 나와 있어서 아쉬웠다. ab라는 벤치마킹 툴을 새로 알게 되어 좋았음.
  • ab - HTTP 서버 벤치마킹 툴
    학교에서 한창 기숙사 관련 웹 서비스의 백엔드를 개발할 때 벤치마킹 코드를 직접 작성했었던 적 있는데, 그 때 이 도구를 알았으면 덜 삽질했었을텐데 싶다.
  • Blue/Green Deployment: What It Is and How it Reduces Your Risk
    무중단 배포 전략 중 하나로, 기존의 어플리케이션을 green version이라고 부르고, 업그레이드하고자 하는 버전의 어플리케이션을 blue version이라고 이름짓는다. production에서 green version만 존재한 채 트래픽을 처리하다가 -> blue version이 새로 생겨나 트래픽을 둘이 함께 처리하고 -> blue version이 모든 트래픽을 처리하도록 만든 후 -> green version을 제거하고 blue version을 새로운 green version으로 만드는 방식이다. 다만 잠시동안 두 버전의 어플리케이션을 동시에 띄워야 하니 비용 문제가 발생할 수는 있으나 대부분 이런 방식을 많이 쓰는 것 같다.
  • What is the difference between application server and web server?
    web server는 static content에 적합하고, app server는 dynamic content에 적합하므로 web server는 app server의 리버스 프록시 역할을 할 수 있다는 설명이 있다.
  • Difference between proxy server and reverse proxy server
  • The Complete Guide to the ELK Stack - 2018
    이거 진짜 글이 너무 좋다. Complete Guide라고 자신있게 말하는 이유가 있는 것 같다. DevOps를 위주로 일하는 에반젤리스트같은데, Splunk라는 선택지를 두고 왜 ELK를 쓰는지, 왜 유명한지, 로깅은 왜 해야 하는지, 기본적인 ELK stack부터 중간에 redis나 kafka를 써서 버퍼링하는 구조까지 설명하고 있다. 글이 좀 많이 긴데 정말 읽어볼만 하다. ELK는 웬만하면 log shipper로 Beats가 껴 있어서, Elastic에서는 이를 Elastic Stack이라는 이름으로 브랜딩하고 있다. Lucene 검색 엔진 기반의 NoSQL 데이터베이스인 ElasticSearch, 로그 transformation 프록시인 Logstash, 시각화 툴인 Kibana가 기본이 되는 모니터링 스택이다.
  • Time Series Database and Tick Stack
    로그 collector로 Telegraf, 시계열 데이터베이스로 InfluxDB, 시각화로 Chronograf, Alerting&Anomarly Detection으로 Kapacitor를 사용하는 모니터링 스택.
  • What are the advantages and disadvantages of using a content delivery network(CDN)?
    네트워크는 물리적으로 가까운 위치에 있을수록 응답 속도가 빠르다. hop count가 줄어들기 때문이다. CDN은 정적 데이터(css, js, 이미지 등)를 다른 리전의 서버에 캐싱해 둬서, 멀리 사는 사용자에게 컨텐츠를 제공하는 퍼포먼스를 향상시키는 기술. Amazon Cloudfront같은 서비스가 CDN을 제공한다.
  • runscope
    API 모니터링 SaaS. 정해둔 스케줄과 step에 따라 API를 호출하고 validation을 수행한다. pagerduty같은 on-call alert 서비스와의 integration을 지원해서, API에 500이 발생했을 때 내 핸드폰으로 전화가 오게 만들 수도 있다.
  • statuspage.io
    서비스의 상태를 공개하기 위한 status page를 호스팅해주는 서비스
  • wrk
    HTTP 벤치마킹 툴. 웹 프레임워크 퍼포먼스 테스트나 서버 스트레스 테스트같은 거 할 때 자주 쓰이는 듯.
  • Serverless Architecture
  • 서버리스 아키텍쳐(Serverless)란?
    서버리스는 직접 관리하는 인프라가 없다는 의미.

HTTP에 가까운

  • REST

    • REST API 제대로 알고 사용하기
    • 그런 REST API로 충분한가
    • REST 의 Uniform Interface에 대하여
      Uniform Interface 는 REST 에서 가장 기본적인 제약이다. 이는 다음 4가지로 구성되어 있다.
      • Resource Identifier
      • Resource Representation
      • Self-Descriptive message
      • hypermedia as the engine of application state (HATEOAS)
    • 바쁜 개발자들을 위한 REST 논문 요약
      Uniform Interface 를 사용하여 클라이언트-서버간의 인터페이스를 일반화함으로써, 전체 시스템 아키텍처가 단순해지고, 상호작용의 가시성이 개선되며, 구현과 서비스가 분리되므로 독립적인 진화가 가능해진다. 이 스타일에 따르면, REST API는 기본 URI와 미디어 타입의 정의만 알면 이용할 수 있어야한다.

  • GraphQL

  • HTTP2/HTTPS

    • HTTPS는 HTTP보다 빠르다
    • 나만 모르고 있던 HTTP2
      아니 뭐 이렇게까지 HTTP/1.1을 까고 HTTP/2를 찬양하나 싶었는데, 이유 있는 비판인 것 같다. HTTP/2가 SPDY를 기반으로 개발되었고, 구글이 HTTP/2가 SPDY를 대체할 것이라고 발표한 것은 처음 알았다.
    • HTTP/2 소개 - Google Developers
      SPDY가 비표준 프로토콜이라는 말을 듣고 굉장히 의문적이었는데, 실험용 프로토콜이었구나. HTTP/1.1의 성능 제한을 해결해 웹페이지의 레이턴시를 줄이는 것을 목표로 SPDY가 만들어지기 시작했고, HTTP/2의 새로운 기능과 제안을 테스트하기 위해 SPDY가 계속해서 실험 수단으로 사용되었다. 이제는 SPDY가 가지고 있던 대부분의 장점이 포함된 HTTP/2가 표준으로 받아들여지면서 SPDY는 deprecated되었다고 함. high level API는 HTTP/1.x와 동일하게 유지되고, low level의 변경이 성능 문제를 해결했다. 바이너리 프레이밍 계층, 요청/응답 멀티플렉싱, 스트림과 스트림 우선순위 지정, server push, 헤더 압축 등등 + HTTP/1.x의 image sprite, 도메인 샤딩과 같은 임시 방편을 제거하고 최적화하는 기능이 들어 있다.

  • API Security Checklist-ko

  • API development tools

  • WebSocket과 Socket.io
    결국 웹소켓의 요지는 polling을 push 방식으로 만든다는 건데, HTTP/2.0의 server push 기능이 어느정도 웹소켓을 흉내낼 수 있지 않을까 싶었다.

  • HTTP 응답코드 결정 다이어그램

  • Understanding CORS
    핵심은 'CORS is a mechanism which aims to allow requests made on behalf of you and at the same time block some requests made by rogue JS and is triggered.' / 서버가 'A에서의 요청은 허락하고, B에서의 요청은 허락하지 않는다'같은 걸 헤더로 떨궈주는 건데, 이게 허용 여부 자체를 클라이언트 사이드에서 판단한다. OPTIONS 메소드로 요청해서 자기가 allow된 대상인지 확인하고, 권한이 있으면 실제로 요청하는 것. 그래서 allow origin을 특정 도메인으로 한정지어 놓더라도, OPTIONS로 요청 권한을 확인하는 걸 그냥 무시하고 요청하더라도 문제가 없음. 띠용;; 단지 자바스크립트 엔진 표준 스펙의 Same-Origin Policy가 일으키는 문제(자신이 속하지 않은 도메인에 대한 요청을 차단)를 해결하기 위함이라고 하는데, 아니 '특정 클라이언트에게만 액세스 허용'을 할거면 프로토콜 레벨에서 해주는게 맞지 않나? 참 애매한 친구다.

  • Introduction to JSON Web Tokens
    사실 HTTP에서 authentication을 위해 JWT를 사용하는 것은 표준이 아니지만(Authorization 헤더의 value type중 JWT를 위한 것은 없다. - Bearer는 OAuth 2.0의 토큰을 사용해야 하고, JWT라는 타입은 없음) 이미 많이들 사용하고 있는 사용자 인증 프레임워크.

JSONSchema

  • JSONSchema
    JSON payload를 검증하는 데에 쓸 수 있는 JSONschema. 처음 봤을땐 뭐 이런 TMI 스펙이 다있어? 싶었는데 이젠 이거 없으면 validation이 어렵다.
  • object - pattern properties
    property name이 dynamic한 경우, pattern properties를 사용해볼 수 있다.
  • object - Schema dependencies
    JSONSchema object에서 dependency는 '프로퍼티 A가 있으면 프로퍼티 B도 있어야 한다'와 같은 개념이다. property dependencies를 사용할 수도 있으나, schema dependencies는 그 내부에 있는 dependecy들에 대해서도 스키마를 적용할 수 있어 확장성이 더 높다.

개발에 도움을 주는

  • 멋진 Terminal 만들기
    macOS에서 iTerm2, zsh, OhMyZsh을 설치하고 테마도 입히고 폰트도 설정하고 하면서 터미널 예쁘게 만드는 가이드.
  • Making iTerm 2 work with normal Mac OSX keyboard shortcuts
    iTerm2에선 Command+방향키, Option+방향키 등의 커맨드가 macOS의 기본 shortcut과 달라서 조금 번거롭다. 이걸 해결해주는 가이드.
  • Sonarqube
    버그, 취약점, 코드 스멜이라는 3가지의 카테고리로 나누어 rule을 정의해 이를 기반으로 코드를 정적 검사해 주는 도구다.
  • About Travis CI
    필자의 의견을 정말 잘 피력한 글인 것 같다. 개발 과정에서 특정 이벤트에 따라 특정한 job을 계속해서 수행하게 하려면 이와 같은 CI(Continuous Integration) 도구가 필요한데, Jenkins처럼 설치형이 아니라 SaaS로 제공되는 CI 중에서는 Travis가 가장 편하고 좋은 것 같다. push가 일어나면 travis가 테스트를 돌린 후 문제가 없다면 배포하게 만들거나, pull request가 올라갔을 때 테스트를 돌리고 빌드 결과를 직접 comment로 달아주도록 하는 등의 일이 가능하다.
  • Python 프로젝트에 Codecov 연동하기
    테스트 커버리지는 측정하는 것이 문제가 아니라, 개발자에게 쉽게 인지되어야 한다. CI 단에서 테스트를 실행함과 함께 커버리지를 측정하더라도, CI의 job에 직접 찾아가서 percentage나 커버되지 않은 라인을 html 형태로 손수 찾아보는 것은 시간이 아깝다. pull request에 대해 CI를 달아 두고, CI가 커버리지 메타데이터 파일을 codecov에 전달해 분석 결과를 comment를 남기게 하는 것이 한 가지 사용 사례다. 이렇게 외부의 커버리지 측정 도구를 쓰게 되면, 개발 조직으로 하여금 테스트의 커버리지 측정 결과에 대한 접근성을 높일 수 있다. 커버리지 측정 도구가 이것저것 많긴 한데, 내가 여태껏 써봤던 것 중에서는 codecov가 가장 좋았던 것 같다. 검색 결과에 보이던 글 중 가장 좋았던 글이라 Python을 전제에 깔았음에도 가져왔다.
  • codecov vs coveralls
    커버리지 측정 도구로 유명한 codecov와 coveralls를 비교하는 글.
  • Programming Notes for Professionals Books
    48가지의 프로그래밍 언어(+프레임워크, 기술 등) 기술과 트릭들을 Documentation 형식으로 정리해둔 무료 PDF 문서 모음.

데이터 과학

  • The Data Visualisation Catalogue 데이터 시각화를 위한 수많은 그래프들의 특징, 기능, 장단점, 사용처 등이 알차게 정리되어 있어 그래프를 고를 때 유용하게 사용할 수 있는 목록. 어떤 그래프를 사용해야될지 감이 오지 않을때 참고하도록 하자.
  • Kaggle 데이터 분석 및 예측 부류의 가장 유명한 competition 제공 사이트. competition 말고도 kernel과 discussion을 제공하여 데이터 관련 개념들을 알차게 배울 수 있도록 설계되어 있다. 데이터 관련 강의도 추가로 제공한다.

애드테크

소프트웨어 공학

Git

  • git blame
    git blame 명령어를 통해 소스 코드에서 특정 line을 지정한 후 그 일부에 대해서 commit history를 찾아볼 수 있다.
  • How to resolve merge conflict during pull request?
    pull request를 날렸는데 conflict가 나면 어떻게 해결해야 되는지에 대한 질문. 'Merge origin/master into JohnMaster and push this to its remote (origin/JohnMaster).' 그냥 target branch에서 pull 땡기고 merge 해결한 후 push하면 된다.
  • How do I update a GitHub forked repository?
    fork한 레포를 원본 저장소와 어떻게 sync하는지에 대한 질문. 'upstream'이라는 이름으로 remote를 등록하고 fetch upstream하면 된다.
  • What is .gitignore exactly?
    '.gitignore tells git which files (or patterns) it should ignore.' 안드로이드 프로젝트 같은데서 맨날 .idea 하위 파일들 conflict났던 기억이 있는데 gitignore가 있으면 깔끔하게 해결 가능하다.
  • .gitignore is ignored by Git
    Tracked file들은 .gitignore가 생겨도 제대로 먹히지 않는다. 'Even if you haven't tracked the files so far, Git seems to be able to "know" about them even after you add them to .gitignore.'
  • git rebase -i 사용하기
    커밋 히스토리를 정리하기 위해, 또는 커밋의 메타데이터(커밋 날짜, author 등)를 변경하기 위해 사용하는 rebase. 여러모로 쓸만한 곳이 많다.
  • How can one change the timestamp of an old commit in Git?
    과거의 커밋에서 commit time을 어떻게 변경하는지에 대한 질문. 이런저런 방법 많은데 나는 rebase해서 commit --amend하는게 깔끔해 보인다.
  • How to change the commit author for one specific commit?
    과거의 커밋에서 commit author를 어떻게 변경하는지에 대한 질문. 여기서도 대부분 rebase하는 식으로 가이드한다.

Linux

  • export, echo 명령어
  • lsof 사용법
    Address bind 관련 문제가 있을 때마다 포트 점유하고 있는 프로세스 보려고 옛날에 자주 썼던 명령어. 그냥 list 관련된 모든 것에 대한 헬퍼인 것 같다.
  • grep 사용법
    결과를 필터링할 때 자주 사용하는 명령어.
  • awk 사용법
    입력된 라인들의 데이터들을 특정 기준으로 분리해서, 일부 column만 가져올 수 있게 해주는 명령어.
  • htop Explained Visually
    짱 쩌는 프로세스 모니터. devops 하시는 분들이 항상 피벗 모니터에 ElasticSearch 클러스터같은 데서 htop 켜놓고 있더라.
  • Crontab 사용법
    특정 job을 스케줄하기 위해서 사용한다.

CS

자료구조

알고리즘

  • 루프 불변성
    반복 알고리즘의 무결성을 증명하기 위해 사용되는 방법이다. 루프 불변성과 반대되는 개념으로는 루프 변성이 있는데, 이는 루프를 '도는' 동안 변하는 성질을 가진 것들을 칭한다.
  • 시간 복잡도 빠르게 이해하기
    시간 복잡도란 어떤 알고리즘의 실행 시간이 얼마나 되는가? 라는 질문에 대한 대답을 할 수 있는 개념으로, 알고리즘이 입력에 대해 얼마나 오래 실행될 것인지 예측할 수 있다.
  • 점근 표기법
    상기한 시간 복잡도에 대해 조금 더 수학적으로 접근한 내용이다.
  • 분할정복
    커다란 하나의 문제가 사실 '닮은꼴' 문제들로 쪼개질 수 있다면, 여러 부분문제들을 해결한 다음 해를 결합함으로서 원래 해결하고자 했던 문제를 해결할 수 있다.
  • 힙 정렬
    최대 힙이나 최소 힙을 만들어 정렬하는 방식이다. 평균적인 시간복잡도는 퀵 정렬과 같지만(최악의 경우 퀵 정렬보다 빠르다) 트리를 만들어 정렬하는 특성 탓에 자료가 커질 수록 퀵 정렬보다 캐시 활용에 있어 모자란 면모를 보인다.
  • 동적 계획법
    부분 해를 구하는 과정을 거듭해 최종 해를 구한다는 점은 분할정복과 비슷하지만, 분할정복과는 달리 한 번 구한 부분해가 여러 번 재활용되며 (중복되는 부분 문제가 존재하기 때문: n번째 피보나치 수는 n-1번째 피보나치 수와 n-2번째 피보나치 수를 더해서 구할 수 있다), 문제의 분할 자체가 속도 향상에 도움이 되는 분할정복과 달리 이전에 구한 해를 재활용하는 것이 속도 향상에 도움을 준다.

AWS

  • AWS 101 : Regions and Availability Zones
    Region과 AZ(Availability Zones)에 대한 설명. 물리적 데이터 센터인 Availability Zone들을 지리적 위치에 따라 Region 개념으로 묶고, 각 Region은 다른 Region들과 물리적으로 격리되어 있다.

컴퓨팅

EC2

  • EBS
    • EBS(Elastic Block Storage)
      EC2 인스턴스에 마운트해 사용할 수 있는 블록 스토리지. 데이터를 다루는 클러스터를 직접 운영(ex - ElasticSearch, Druid, ...)하는 경우 extra storage가 필요한데, EBS가 그걸 해결해 준다.
    • EBS 최적화 인스턴스
      인스턴스에 EBS 전용 대역폭을 만들어서 EBS에 대한 처리량과 IOPS를 늘리는 것. 현재 세대 인스턴스들은 기본적으로 EBS 최적화되어 있는 상태.
  • EC2(Elastic Compute Cloud)
    컴퓨팅 엔진. 말 그대로 그냥 컴퓨터 하나 대여해 주는거라 EBS(Elastic Block Storage)를 붙여서 Druid를 올리거나, ProxySQL, VPN 서버 등 AWS에서 관리형으로 제공하지 않는 것들을 올리는 데에도 쓰고, 웹 어플리케이션 서버를 통으로 올리는 경우나, ECS(Elastic Container Service)가 컨테이너를 동작시키는 컴퓨팅 엔진, 마인크래프트 서버 구축 등 여러 용도로 사용할 수 있다.
  • 인스턴스 수명 주기
  • 인스턴스 유형
    instance family라고도 부른다. 하드웨어 스펙이 어디에 최적화되도록 설계되었는지에 따라 다르게 분류함. EC2에 올리려는 컴포넌트의 특징에 따라 인스턴스 유형을 잘 선택하면 남는 리소스도 줄이고 비용 최적화에도 좋을 것 같다. ElasticSearch 올릴 때 D2나 I3 쓴다거나..
  • 인스턴스 구입 옵션
    온디맨드, 스팟, 예약 인스턴스만 알고 있었는데 몇가지 더 있었다. 스팟, 예약 인스턴스 잘 써먹으면 비용 최적화에 도움 많이 될듯.
  • Application Load Balancer 서비스 공개
    AWS 블로그의 글이다. 일반적으로 로드밸런싱은 OSI 모델 기준 layer 4(transport layer)나 layer 7(application layer)에서 처리한다. ELB(Elastic Load Balancer)는 layer 4 로드 밸런싱을 제공하는데, layer 7 로드 밸런싱을 위해 ALB를 사용할 수 있다. application layer에서는 transport layer에서 할 수 없었던 패킷 접근이 가능한데, 이 덕분에 HTTP 요청의 내용(헤더, URL 등)을 가지고 rule을 만들어서 패킷 전송 위치를 지정할 수 있다. ELB를 세팅할 때 application load balancer와 classic load balancer가 선택지로 제공된다.
  • 배치 그룹(Placement Gorup)
    placement group을 설정해 두면 group에 있는 인스턴스들이 '물리적으로 가까운 위치'에 할당된다. latency 확보에 도움을 준다고는 하는데, 유의미한 수준인지는 모르겠다.

ECS

  • ECS(Elastic Container Service)
    어플리케이션을 docker 등으로 컨테이너화 하면, 독립된 실행 환경이 보장되고 빌드 스크립트가 파일 형태로 관리되어 배포 과정이 깔끔해진다. 가장 문제는 이러한 컨테이너를 orchestration하는 일인데, 이 일을 ECS가 대신 해준다. ECS는 Kubernetes같은 Docker 컨테이너 orchestration 서비스. EC2를 기반으로 동작시키거나, EC2 인스턴스를 직접 관리하기 부담스러운 경우 Fargate를 사용할 수도 있다.
  • Fargate
    서버리스 컨테이너 컴퓨팅 엔진. 컨테이너를 위한 인스턴스를 EC2 등으로 직접 관리할 필요 없이, 컨테이너 자체만 제공하면 알아서 잘 관리해 준다.

ECR

  • ECR(Elastic Container Repository)
    말 그대로 Docker 컨테이너 저장소를 제공한다. ECS와 잘 통합되므로 배포 프로세스에도 도움을 많이 준다.

Lambda

  • Lambda
    '이벤트에 응답하여 코드를 실행'하는 서버리스 컴퓨팅 서비스. Event Driven한 거라면 뭐든 붙여볼 수 있다. API Gateway랑 엮어서 API 서버 용도로도 사용할 수 있고, 뭔가 스케줄링하는 용도로 사용할 수도 있고 등등.
  • Lambda Function Versioning and Aliases
    Lambda function에는 버전과 alias(별칭) 개념이 있다. 세상에. Lambda function을 업데이트할 때마다 버전이 하나씩 올라가고, 최초 생성된 lambda function의 기본 별칭인 Unqualified는 $LATEST라는 와일드카드 표현식으로 항상 가장 최신 버전을 가리킨다. 버전과 별칭으로 나뉜 lambda function들은 각기 다른 unique한 ARN(Amazon Resource Name)을 가진다. 함수 이름이 test라면, 버전 7의 함수는 arn:aws:lambda:<region>:<acct-id>:function:test:7, 별칭이 PROD인 함수는 ...:test:PROD같은 식. serverless나 zappa 등의 툴킷으로 lambda에 서버리스 웹 어플리케이션을 배포하면, 함수가 업데이트될 때마다 알아서 새 버전을 가르키도록 Unqualified alias에 API Gateway를 매핑해 둔다.

스토리지

S3

  • S3 Storage Classes
    S3에도 종류가 있다. 웹페이지 리소스나 콘텐츠 저장 용도로는 대부분 검색 요금이 따로 발생하지 않는 S3 Standard를 사용하고, 오래된 로그 데이터같이 액세스 빈도가 낮은 데이터는 비용 최적화를 위해 S3-IA(Infrequent Access)나 RRS(Reduced Redundancy Storage)를 고려해볼 수 있다. Intelligent Tiering과 Glacier Deep Archive는 처음 알았다.

EFS

  • EFS(Elastic File System)
    EBS와의 차이는, 여러 EC2 인스턴스에 동시 마운트할 수 있다는 점이다. 엄청 비쌈. 클러스터 환경에서 데이터 처리할 때 써먹을 수도 있지 않을까 싶다.

데이터베이스

RDS

Aurora

  • Aurora Serverless - Features, Limitations, Glitches
    Serverless 형태의 완전 관리형 Aurora 인스턴스. 정확히는 RDS에서 Aurora를 띄울 때 serverless 타입을 선택할 수 있다. Auto Scaling이 제공되고, Aurora가 자체적으로 multi-AZ에 데이터를 복제한다. VPC 내에서만 동작하고 별도로 VPC peering도 불가능하지만 Direct Connect로 해결 가능한데, 비용이 RDS 프로비저닝과 얼마나 차이날 지 궁금하다.

DynamoDB

ElastiCache

DocumentDB

  • Amazon DocumentDB 신규 출시
    MySQL 호환 데이터베이스인 Aurora를 알았을 때, 뭔가 Document-Oriented NoSQL DB도 하나쯤 만들지 않을까 싶었는데 진짜 만들었다. MongoDB 호환 가능하고, AWS답게 replication 짱짱하고 스토리지 auto scaling 잘 되고, 역시나 완전 관리형이다. 나중에 한 번 써봐야지.

TimeStream

  • TimeStream
    2018 AWS re:invent때 공개된 완전 관리형 time series 데이터베이스. 완전 좋아 보이는데 일단 써봐야 알 것 같다. 1000X faster at 1/10th the cost 뭐 이러는데 일단 SQL-like 쿼리 인터페이스가 있다는 거랑 서버리스로 구성돼 있어서 관리 포인트가 줄어든다는 게 좋은 것 같다. ELK는 비싸고 대안이 딱히 없는 것 같아서 InfluxDB 쓰는데 이제 이거 EC2에 프로비저닝 안해도 되겠당. 물론 써봐야 알겠지만. grafana같은 time series visualize 툴들이 timestream 대응하느라 바빠질듯.

마이그레이션, 전송

DMS

  • DMS(Database Migration Service)
    데이터베이스 마이그레이션 서비스. 동종 데이터베이스 마이그레이션 뿐만이 아니라, 이기종 데이터베이스 플랫폼 간 마이그레이션(예를 들면, Oracle Database -> AWS Schema Conversion Tool -> Aurora Database)도 가능하다. 물론 소스 데이터베이스가 RDS 또는 EC2에 있어야 한다.

Snowball

  • Snowball
    데이터를 네트워크로 전송하는 것은, 대용량 데이터 관점에서 매우 느리다. Snowball은 대용량 데이터를 물리적으로 마이그레이션하는 것을 돕는다. AWS Management Console에서 작업을 생성하면 AWS가 물리적인 스토리지 디바이스(Snowball)를 본인에게 배송하고 -> Snowball 클라이언트를 통해 이 디바이스에 연결해 데이터를 업로드한 후 -> AWS에게 Snowball 디바이스를 반송 -> AWS가 이를 S3에 업로드하는 방식이다.

네트워킹

VPC

CloudFront

Route 53

API Gateway

Direct Connect

PaaS

CodeStar

  • AWS CodeStar로 1인 DevOps 코스프레하기
    백엔드는 어렵고 귀찮다 ㅎㅎ. 어디 프로젝트에서 백엔드를 맡게 되면 GitHub같은 Git 서버에서 소스코드 관리하고, Jenkins 머신 따로 띄우거나 Travis같은 SaaS로 CI 세팅해 두고, CodeDeploy나 CloudFormation으로 EC2/ECS/Beanstalk/Lambda 등등에 배포 자동화 세팅해 두고, 따로 퍼포먼스/인프라 모니터링 스택도 준비해야 한다. CodeStar는 CodePipeline으로 hook부터 deploy까지의 과정을 관리해 준다. CodeBuild로 빌드, CodeDeploy+EC2 or CloudFormation+Lambda or CloudFormation+Elastic Beanstalk으로 배포 자동화, CloudWatch로 모니터링까지 어플리케이션 개발 전반에 걸쳐 번거로운 것들을 대신 맡아준다. 프로젝트 대시보드도 제공해줌! 이게 얼마나 괜찮을지는 다음 토이 프로젝트에서 써보는 걸로.

CodeCommit

  • AWS CodeCommit
    private git repository 호스팅 서비스! 외부 이슈 트래커랑 연동도 되는 듯.

CodeBuild

  • AWS CodeBuild
    와! 완전 관리형 빌드 서비스! 사실 조직 내 AWS 인프라들의 인바운드 접근 권한은 대부분 IP를 쓰지 않고 security group 단위로 한정한다. 그래서 DB 등에선 빌드 시스템이나 개발자 PC 등 외부의 접근을 수용하기 위해 따로 VPN 서버를 프로비저닝하고, 이 VPN 서버에 대해서 인바운드를 열어두는 식으로 운용을 하는데, Travis나 Circle같은 SaaS 형태의 빌드 서비스는 VPN setup이 불가능하거나 어렵다. 그래서 그냥 Jenkins 머신을 EC2에 따로 띄우고 해당 인스턴스의 security group을 인바운드에 추가하는 식으로 접근 제어를 하는데, 관리 포인트가 늘어나는 게 문제. CodeBuild는 이런 문제를 해결해 준다. 일단 AWS 위에서 동작하기 때문에 별도의 security group이 할당되므로 인바운드를 허용하기 좋고 + 서버를 직접 관리하지 않아도 됨!
  • CodeBuild의 build spec reference
    CodeBuild가 레포를 clone해서 빌드를 위해 buildspec.yml을 찾는데, 여기에 들어갈 수 있는 것들을 정리한 문서. 여타 CI들과 다르지 않게 phase 기반으로 동작한다.
  • Environment variables not being set on AWS CodeBuild
    CodeBuild에서 buildspec.yml에 명시한 export 명령어가 제대로 먹히지 않는 현상에 대한 트러블슈팅. 버전을 0.2로 올리면 된다고 한다.

CodeDeploy

  • AWS CodeDeploy를 통한 배포 자동화
    EC2, ECS 등의 인스턴스에 대한 배포 자동화에 도움을 주는 착실한 친구. 그런데 뭔가 '배포 자체'에 대해 많이 챙겨줘서, Canary Test/Blue-Green Deploy, 롤백 등의 지원이 필요 없으면 안 쓰게 될 것 같기도 하다.

관리

CloudWatch

  • 일정에서 트리거되는 CloudWatch 이벤트 규칙 생성
    모니터링 도구인 CloudWatch에는 Events라는 하위 기능이 있다. 이벤트 패턴이나 일정을 이벤트 소스로 선택하고, 이벤트가 발생했을 때 lambda, step function, EC2 인스턴스 재부팅 등 타 AWS 서비스를 호출할 수 있다. 이 문서는 일정을 이벤트 소스로 트리거하는 CloudWatch 이벤트 규칙을 생성하는 방법을 다룬다. Linux의 cron과 비슷한 용도로 사용할 수 있다.

Auto Scaling

분석

Athena

Redshift

EMR

ElasticSearch Service

Kinesis

보안, 자격 증명

IAM

KMS

어플리케이션 통합

Step Functions

Amazon MQ

SNS

SQS

DB

데이터베이스 자체에 대한 얘기

  • What is an ORM and where can I learn more about it?
    ORM이 무엇이고, 장점과 단점은 무엇인지에 대한 설명. ORM 라이브러리는 대부분 무겁고 러닝커브가 생기긴 하지만, 상황에 따라 동적으로 SELECT 쿼리를 빌드하는 머리아픈 경험을 해 봤다면 ORM이 이만큼 유연할 수가 없다. 복잡한 쿼리가 아니라면 성능 문제도 딱히 없는 것 같다. 이래저래 논쟁을 끌고 다니는 기술이긴 한데, 단점을 감당하지 않기 위해서 ORM으로 얻을 수 있는 메리트를 모두 포기하고 raw SQL을 쓸 이유가 딱히 없지 않을까 싶다. 물론 대용량 데이터를 다룰 때는 raw SQL을 쓰는 것이 마음 편한 듯.

  • DBMS는 어떻게 트랜잭션을 관리할까?
    CUBRID의 개발을 이끌고 있는 엔지니어가 쓴, 트랜잭션의 관리를 DBMS 레벨에서 설명한 글. ACID 성질부터 UNDO와 REDO, 상태 로깅과 전이 로깅, 커밋을 하면 어떤 일이 일어나는지, group commit과 트랜잭션 철회 등이 정말 잘 정리되었다. 역시 기술은 해본 사람이 잘 아는 것 같다.

  • A Detailed Guide to Database Denormalization with Examples
    역정규화는 정규화된 데이터베이스에서 데이터를 묶거나 중복 적재하는 등 쓰기 작업을 더 많이 수행해서, 읽기 속도를 향상시키는 일이다. 많은 JOIN이나 aggregation이 이뤄지는 읽기 쿼리는 속도가 느려지기 마련인데, 데이터를 중복해서 적재하거나, pre-joined 구조의 스키마를 작성하는 등의 역정규화로 이를 해결하는 경우가 있다. 위 가이드는 역정규화의 몇가지 사례들을 쉬운 예제와 함께 잘 설명해주고 있다.

  • How does database indexing work?
    Index는 특정 레코드를 찾는 데에 linear search하던 걸, 레코드들을 정렬한 별도의 자료 구조를 만들어 여기에 range search하도록 만들고, 이를 통해 block access count를 줄이는 것이라고 보면 되는 것 같다. 너무 추상적인 것 같아 더 파보니 클러스터/비클러스터 인덱스 등등 더 깊게 뻗어나갈 수 있을듯.

  • What do Clustered and Non clustered index actually mean?
    인덱스의 아키텍처는 클러스터형/비클러스터형 인덱스로 나뉜다. 클러스터형 인덱스는 unique row를 컬럼 순서에 맞춰 물리적인 레벨에서 ordering하여 적재하는 인덱스라고 한다. PK를 기준으로 판단하며 따라서 테이블 당 하나씩 가질 수 있음. PK를 만들면 알아서 클러스터형 인덱스가 생긴다. B-Tree 인덱스나 hash table이 클러스터형 인덱스에 주로 쓰인다고 한다. 비클러스터형 인덱스는 물리적으로 데이터를 정렬하진 않고, 인덱스만 정렬한다. JOIN, WHERE, ORDER BY 절에서 사용된 비 PK 컬럼 위에 만들어진다고 함. insert와 update, point query(한두개만 select) operation에 있어서는 클러스터형 인덱스보다 빠르다고 한다.

    * What are the differences between a clustered and a non-clustered index?

  • Why do you create a View in a database?
    두 테이블을 JOIN하는 복잡한 서브 쿼리를 제거하기 위해 처음으로 사용했었던 것 같다. 실제로 복잡성을 숨기기 위해 사용된다고도 한다. 테이블의 특정 컬럼을 보호하기 위한 메커니즘으로 사용할 수 있다는 DBA의 관점도 있다. View는 '쿼리를 캡슐화하여 aliasing한다'라고 이야기할 수 있을 것 같다.

  • Are soft deletes a good idea?
    데이터의 삭제에 대해 DELETE 쿼리를 날리는 것을 pysical delete, 삭제되었음을 나타내는 (is_deleted같은)컬럼을 두는 방식을 soft delete라고 부른다. 이래저래 논쟁이 많지만 'It depends on the circumstances.'와 'You can't do cascading deletions', 'it's a good idea to have a deleted_date field, instead of an is_deleted field.'가 팩트. 'a soft delete like this means you now have to include a WHERE IsDeleted = false clause in every query on this table'같은 휴먼 에러야 테스트 코드로 보완할 수 있는 부분일테고.

  • What are OLTP and OLAP. What is the difference between them?
    'In OLTP database there is detailed and current data, and schema used to store transactional databases is the entity model (usually 3NF).', 'OLAP applications are widely used by Data Mining techniques. In OLAP database there is aggregated, historical data, stored in multi-dimensional schemas (usually star schema).'

DBMS에 가까운

  • InfluxDB
    TICK stack에서 time series 데이터베이스로 사용된다. 외부 의존성 없고, SQL-like한 InfluxQL이라는 질의 인터페이스를 지원하고, 클러스터링 지원하고, Grafana랑 연계하기 좋고, Go로 개발됐고, 원래 LSM(Log Structured Merge) Tree를 지원하는 LevelDB를 스토리지 엔진으로 쓰다가 이를 개량한 TSM(Time Structured Merge) Tree를 스토리지 엔진으로 사용해서 IO도 빠르고, 압축 알고리즘도 적용해서 스토리지 효율 면에서도 뛰어나다. Graphite는 퍼포먼스 문제가 꽤 많다고 하고, Prometheus는 클러스터링 기능이 없다. 그러나 시계열 데이터베이스에도 silver bullet은 없다 ㅜㅜ. 얼마 전에 나온 TimeStream이랑 비교하는 글이 곧 올라오지 않을까?
  • StatsD
    Node.js 런타임에서 동작하는 로그 aggregation 프록시. 단위 시간 안의 API 응답 시간 평균과 같은 것들은 일차적으로 aggregation을 해두면 로그 DB의 부하 방지에 좋을 것 같다. Mongo, Graphite, InfluxDB, Zabbix, CouchDB 등 백엔드 지원도 잘 되어 있다.
  • Reduce MySQL Memory Utilization with ProxySQL
    'The main purpose of the multiplexing is to reduce the connections to MySQL servers. So we can send thousands of connections to only a hundred backend connections.' ProxySQL을 쓰는 걸 구경은 해봤는데 직접 써본 적은 없어서 유의미하게 뭔가 경험해본 적이 딱히 없다. ㅜㅜ 커넥션 관리에 확실히 좋다고는 들음.
  • druid
    OLAP를 위해 디자인된, lambda architecture 기반의 data store. 검색 엔진에서 사용하곤 하는 inverted index 구조를 가진다. realtime data에 대한 aggregation query가 매우 빠르다. Hadoop에서 하기 어려운 데이터의 빠른 접근과 실시간 쿼리를 만족한다. aggregating을 매우 빠르게 처리하는 데이터 스토어라고 보면 될 듯. 비슷한 것으로 Google BigQuery, Dremel, PowerDrill 등이 있다.

SQL

MySQL

  • Illegal mix of collations for operation 'like'
    DATETIME 필드에 대해 유니코드가 아닌 문자열로 LIKE 쿼리 수행 시 문제가 생기는데, 이를 해결하는 방법. 그냥 질의하기 전에 date format validation 돌리는 게 마음 편하다.
  • Insert into a MySQL table or update if exists
    key duplication이 없다면 insert하고, 있으면 update를 MySQL에서는 ON DUPLICATE KEY UPDATE로 표현한다. 다른 데이터베이스 엔진에서는 UPSERT나 MERGE라는 이름으로 사용되고 있는 것 같다.

PrestoDB

  • Date and Time Functions and Operators
    PrestoDB의 date/time 관련 함수와 operator가 정리된 문서. athena에서 view를 만들 때 시간에 관한 계산이 종종 필요한데, 대부분 이 문서 하나면 모두 해결 가능하다. timestamp ↔ unixtime은 to_unixtime, from_unixtime 함수를 사용하면 되고, 타임존 변경은 AT TIME ZONE operator, 포매팅과 파싱은 각각 date_format과 date_parse를 쓰면 된다.

MongoDB

SQLite

Redis

Memcached

ElasticSearch

  • Query
    • Query and filter context
      ElasticSearch docs에서 쿼리 부분에 들어가면 가장 처음 나오는 내용. ElasticSearch의 모든 쿼리는 context를 가지며 이는 query와 filter context로 나뉜다고 정리되어 있다. query context는 '얼마나 잘 일치하는가'같은 scoring의 느낌이고, filter context는 '이것과 일치하는가'같은 SQL의 WHERE절 같은 느낌이다.
    • Bool Query
      bool은 must, should, filter같은 조건 쿼리들을 모아주기 위해 사용된다. 그냥 SQL에서 조건문을 정의하기 위해 WHERE 뒤에 조건식들을 나열하는 것처럼 ES에선 bool을 사용한다고 생각하면 됨.
    • ElasticSearch bool query combine
      ElasticSearch에 쿼리할 때 조건식들을 나열하기 위해 bool query 내부에 should와 must같은 걸 쓰곤 하는데, 이들이 각각 어떤 condition으로 조건식들을 합치는지에 대한 질문. OR은 should, AND는 must와 대응된다.
    • What is the difference between must and filter Query DSL in ElasticSearch?
      AND 쿼리를 위해 사용하는 must query와 filter query의 차이에 대한 질문. must는 스코어를 측정하고, filter는 스코어를 측정하지 않는다. score가 필요없는 쿼리의 경우 must 대신 filter를 쓰면 더 빠르다고 한다.
    • ElasticSearch match vs term query
      bool query 내에서, 특정 필드의 값에 대한 일치 연산을 위해 term이나 match를 대부분 사용하는데, 이 둘의 차이가 무엇인지에 대한 질문. term은 filter context, match는 query context에서 실행된다고 정리하면 된다. exactly equal을 보려면 term을 쓰는 것이 맞음.
    • Source filter
      Source filter(_source)를 통해 ElasticSearch가 결과에 특정 필드만 포함시키도록 한다. includes/excludes를 두면 포함/제외를 별도로 둘 수 있다.
    • Terms Aggregation
      DISTINCT SELECT/COUNT에 쓰이는 terms aggregation.
    • Term level query - range query
      SQL의 between과 대응되는 쿼리.
  • Others
    • Elastic APM
      Elastic에서 제공하는 APM 서비스. New Relic같은 거라고 보면 된다. 하드하게 써본 경험은 없어서 뭐라고 하진 못 하겠지만, 어차피 ES 쓰고 있다면 APM도 Elastic 인프라 내에서 처리해도 괜찮을 것 같다고 생각한다.

언어

Python

언어 자체에 대한 이야기

  • Do you know Python?
    • Glossary
      iterable, iterator, awaitable, context manager, coroutine function과 같이, 파이썬을 쓰다 보면 한번쯤은 마주치게 되는 단어들이 정리된 문서.
    • Hidden features of Python
      그다지 알려지지 않았지만 유용한 Python의 기능들.
    • Intermediate Python
      파이썬에 이런 기능도 있는데 혹시 알아? 하는 느낌의 팁북. 바로 위의 'Hidden features of Python'과 비슷한 느낌이다.
    • A collection of design patterns/idioms in Python
      파이썬으로 구현한 이런저런 디자인 패턴들의 모음.
    • wtfpython
      파이썬을 사용하며 생길 수 있는 해프닝들의 모음인데, 흥미로운 주제들이 많이 정리되어 있다.
    • Better Python 59 Ways
      한국에서는 '파이썬 코딩의 기술'이라고 이름지어진, 'Effective Python'이라는 도서에서 사용된 59가지 예제 모음
  • 제너레이터와 코루틴
  • 비동기 파이썬
    Hackernoon에 작성된 Asynchronous Python을 번역한 글. 멀티스레딩에서 경쟁 상태나 데드락 등등은 어떻게든 해결할 수 있으나 context switching의 자원 낭비는 어째 해결할 수 없어서 비동기 프로그래밍이 설계되었다는 내용을 시작으로, Python을 기준으로 해서 그린 스레드부터 콜백 스타일, Python 3.3부터 제공된 yield from, asyncio의 빌트인화와 async/await 문법까지 차근차근 설명되어 있다.
  • Python GC가 작동하는 원리
  • 파이썬 언더스코어(_)에 대하여
  • Removing duplicates in lists
    리스트에서 중복된 요소를 제거하는 방법에 대한 이야기다. 알아두면 요긴하게 써먹을 수 있음.
  • Difference between append vs. extend list methods in Python
    list를 확장하는 메소드로 append와 extend가 있는데, 이 둘의 차이. 3번째 답변이 오버로딩된 연산자와 timeit을 통한 시간 복잡도까지 잘 설명하고 있다.
  • PEP 484 -- Type Hints
    Python 3.5부터 사용 가능한 type definition. typing 모듈의 overload 데코레이터로 오버로딩도 가능하다.
  • Python __getitem__과 slice의 이해
    getitem 과 slice 에 대한 내용 뿐만아니라, "Ellipsis" 라는 개념이 등장한다. Ellipsis 는 null statement로 pass 대신 쓰이는 경우도 있다.
  • What does the “yield from” syntax do in asyncio and how is it different from “await”
    파이썬에서 비동기 IO를 위해 사용하는 두 키워드.
    • Python 3.3부터 generator가 다른 generator에게 연산의 일부를 위임하도록 하는 yield from이라는 expression을 사용할 수 있게 되었다. 이는 generator가 generator를 호출하고, 서로의 실행을 중지시킬 수 있는 방법이 생긴 것이기 때문에 비동기 프로그래밍이 원활히 가능하도록 만들어 주었다.
    • 이러한 generator들을 실행하는 이벤트 루프를 asyncio 라이브러리가 제공해주기 시작했다.
    • Python 3.5부턴 asyncio가 빌트인 라이브러리로 지원되며 async 키워드가 @asyncio.coroutine를 대체하고, await 키워드가 yield from을 대체하게 되었다.
  • Python equivalent of golang's defer statement
    Go에서 defer는 function call stack의 맨 위에 해당 함수를 push한다. 이걸 Python에선 어떻게 해야 할까?라는 질문. contextlib.ExitStack을 써먹으면 된다.
  • Python GIL

개발 환경

  • 가상 환경 및 패키지
  • pipenv란 무엇인가
    virtualenv+pyenv+pip가 합쳐진 형태의, Python계의 npm인 pipenv에 대한 소개. pyenv가 설치되어 있으면 알아서 필요한 버전을 설치하고 가상 환경을 열어준다는 게 정말 맘에 든다. pyenv 설치하고, pyenv-virtualenv 설치하고, requirements.txt를 dev와 production에 나눠 만들 필요가 없으니 정말 편한 도구.
  • pipenv로 Python 프로젝트 관리하기
    글 자체가 깔끔하게 정리되어 있기도 하고, pipenv가 제공하는 명령어들에 대한 구체적인 설명이 들어 있어서 초심자에게 더 좋은듯.
  • Force pipenv to create a new virtualenv
  • Black
    엄청 잘 만들어진 코드 포매터.

표준 라이브러리

  • Data Types
    • datetime
    • collections.OrderedDict
      내 생각엔 OrderedDict를 써볼만한 case가 그리 많진 않을 것 같은데, OrderedDict를 써야 하는 적은 case 입장에서는 정말 개이득인 컨테이너 타입인 것 같다.(메인 언어로 파이썬 쓴지 1년 넘는 동안 딱 2번 써봤지만, 그때마다 OrderedDict 덕분에 정말 편-안했음) 단지 넣은 순서대로 dictionary가 유지된다는 것 뿐이지, 자동으로 sort는 해주지 않는다는 것을 인지하고 있어야 한다.
    • collections.defaultdict
      dict를 상속받은 dictionary-like한 객체를 반환한다. 이 객체는 함수에 전달된 optional argument인 default_factory를 인스턴스 변수로 가지고 있고, __getitem__ 메소드를 오버라이딩한다. getitem 시 key가 존재하지 않으면 __missing__ 메소드를 호출하고, 이 메소드는 default_factory를 호출해 반환한다. default_factory가 None이면 KeyError를 raise한다. invalid key에 대해 default value를 정의해 두어 KeyError를 방어하기 위해 사용된다.
    • 얕은 복사(shallow copy) vs 깊은 복사(deep copy)
      복사 개념을 잘 모르면 이상한 걸로 삽질하게 된다. Python에서는 복사 작업을 돕기 위해 copy 모듈이 존재한다.
    • enum
      enum이야 뭐 클래스 변수로 쓰면 되지 않나? 싶었는데, 모듈에서 제공해주는 기능이 생각보다 엄청나게 많고 유용하다. enum 정의하려면 일단 Enum 클래스 상속받고 시작하는 게 좋을듯. ㅎ
  • Structured Markup Processing Tools
  • Data Persistence
    • pickle
      객체를 그대로 binary string으로 직렬화하는 것을 pickling이라 부른다. 큰 틀은 serialization인데, Python에서만 pickling이라 부름. 아무튼 이런 pickling을 위해 pickle이라는 모듈을 사용할 수 있다. use case는 잘 모르겠다(내 기준에선 객체 직렬화라고 해봤자 웬만하면 dictionary/list인데, 이건 그냥 JSON으로 직렬화하면 되는 이슈라서). 이 아티클에서는 머신러닝 알고리즘에서 피클링이 '매우 유용'하다고 한다.
  • Generic Operating System Services
  • Functional Programming Modules
  • Debugging and Profiling
    • timeit
      짧은 Python statement에 대해 실행 시간을 측정해준다. 문제를 해결하기 위한 방법이 여러가지일 때, 시간복잡도 면에서 better way를 찾기 위해 종종 쓰게 된다.
    • Python Debugging with Pdb
      pdb 없었으면 내 인생이 참혹하지 않았을까. 흑흑. 사실 옛날엔 그냥 매 줄마다 print 찍어보면서 디버깅하곤 했었는데, 확실히 디버깅 툴을 직접 쓰는 게 러닝커브를 감안하더라도 훨씬 더 나은 것 같다.
  • Concurrent Execution
  • Networking and Interprocess Communication

외부 라이브러리

  • CLI
    • zappa
      WSGI 웹 어플리케이션을 AWS Lambda에 올려서 서버리스 어플리케이션을 잘 배포할 수 있게 도와주는 CLI 툴. maintainer가 완전 착하다..
    • twine
      Python 패키지를 PyPI(python Pacakge Index)에 쉽게 배포할 수 있도록 해주는 CLI 툴.
    • aws-cli
      AWS 서비스를 관리하기 위한 CLI 툴. management console에서 안되고 CLI에서만 되는 것도 종종 있다. 예를 들어 CodeBuild에 hook다는 것?
    • click
      CLI 어플리케이션을 개발하는 걸 도와주는 라이브러리. 'Python composable command line interface toolkit'
  • Schema Validation
    • jsonschmea
      JSONSchema를 통한 validation 라이브러리.
    • schema
      schema validation 라이브러리. Pythonic하다고 하는데 이거 쓰려면 러닝커브가 좀 생길 것 같다. 아이디어는 괜찮은 것 같은데, 컨셉 자체가 너무 그들만의 세계같은 느낌.
    • schematics
      schema validation은 이게 제일 나은듯 ㅎ StringType()처럼 데이터의 스키마를 객체로 정의하게 되면 required, default와 같은 rule들이 생성자의 인자로 전달되기 때문에 자동완성의 도움을 받을 수 있어서 IDE 바깥으로 나가는 일이 줄어들어서 좋은 것 같다.
    • cerberus
      스키마 작성 방식이 JSONSchema와 꽤 닮아 있는 validation 라이브러리. 다만 이걸 쓴다면 자동완성의 도움을 받긴 어려울 것 같다. 나는 오타를 자주 내는 편이라, 이렇게 리터럴이 많은 것과 친해지기 쉽지 않다.
    • voluptuous
      schema와 비슷하게 생긴 validation 라이브러리인데, 비교적 잘 정리되어 있는 편. 클래스 스타일이 싫다면 이걸 써봐도 괜찮을 것 같다.
  • DB Driver
  • DB Helper
    • mongoengine
      Node.js의 mongoose와 대응할 수 있는 ODM 라이브러리. 고딩 시절의 거의 반을 함께한 친구 ㅜㅜ
    • pypika
      SQL query builder. ORM같은 쿼리 인터페이스는 아니고, 단순히 쿼리 문자열을 만들어주는 라이브러리라서 접근 방식이 좀 다르다.
    • SQLAlchemy 시작하기 - Part 1
      짱 좋은 ORM 라이브러리 ^&^
    • peewee
      'Peewee is a simple and small ORM.' API 자체가 '예쁘기'는 한데, SQLAlchemy를 두고 이걸 쓸 메리트가 있을런지 싶기도 하고, 당장은 트랜잭션 생각을 안해도 돼서 괜찮은 것 같기도 하고..
    • peewee-async
      Peewee를 async하게 쓸 수 있게 해주는 라이브러리. Sanic같은 데서 ORM 쓸 때 많은 도움을 준다.
  • HTTP
    • requests
      HTTP request 잘 할 수 있게 도와주는 라이브러리. 내장 라이브러리인 urllib.request를 wrapping함.
    • yarl
      'Yet another URL library'. URL 파싱 관련 작업을 도와준다. 내장 라이브러리인 urllib.parse 위주로 wrapping함.
    • aiohttp로 하는 비동기 HTTP 요청
  • Excel Processing
  • Drop-in Replacements
    • Arrow
      datetime으로 타임존과 싸우는 건 사람이 할 짓이 아니다. arrow는 기본적으로 시간을 ISO 8601 format으로 다루기 때문에 타임존 conversion이 쉽고, time shifting이나 humanize 기능도 잘 준비되어 있다.
    • ultrajson(ujson)
      'Ultra fast JSON decoder and encoder written in C with Python bindings'
  • SaaS Helpers
    • pyfcm
      'Python client for FCM - Firebase Cloud Messaging'
    • python-firebase
      'Python interface to the Firebase's REST API'. pyfcm은 FCM에 한정되어 있고, 얘는 firebase 전체.
    • firebase-admin-python
      Python용 firebase admin SDK. Firebase에서 가장 권고하는 방식이며 official로 관리된다.
    • elastic-apm
      'Official Python agent for the Elastic APM'
    • slacker
      'Full-featured Python interface for the Slack API'
    • boto3
      'AWS SDK for Python'
  • Others
    • pyjwt
      JSON Web Token implementation in Python
    • beautifulsoup
      'Beautiful Soup is a Python library for pulling data out of HTML and XML files.'
    • cachetools
      functools.lru_cache 데코레이터의 변형을 포함하여 자주 쓰이는 캐싱들을 데코레이터 형태로 지원하는 라이브러리. LFU, LRU, RR, TTL cache를 지원한다.
    • aiocache
      async 함수에 대한 캐싱을 도와주는 라이브러리.
    • blinker
      object-to-object signaling을 도와주는 라이브러리. 일종의 옵저버 패턴이라 event driven한 어플리케이션을 잘 만들 수 있도록 해줄 것 같은데, use case는 딱히 생각이 나지 않는다. 최근에 signal을 활용하는 걸 봤던 건, Elastic APM Python agent에서 Flask의 request_started, request_finished signal에 각각 트랜잭션 시작과 종료 함수를 할당해둔 것 정도.

테스팅

SQLAlchemy

Peewee

  • Dynamically defining a database
    Peewee는 모델을 정의할 때 Meta라는 inner class를 정의하고 database 속성에 데이터베이스 객체를 명시해놓아야 한다. 데이터베이스 명시를 동적으로 정의하려면 Proxy 객체를 그 자리에 넣어두고, initialize 메소드로 lazy하게 바인딩해 준다. 동일한 모델에 대해 read/write db 세션을 나누어 접근하기 위해 UserReadModel, UserWriteModel처럼 나누는 건 너무 아닌 것 같아서 proxy 개념을 써먹어보고 있는데, 좋은 practice인지는 모르겠다.
  • How to custom the table name in peewee?
    peewee는 모델 클래스 이름을 그대로 lowercase해서 테이블을 찾는데, Meta 클래스의 db_table 속성을 통해 테이블 이름을 별도로 명시할 수 있다.
  • Performing simple joins
    peewee로 기본적인 join 쿼리를 작성하는 방법이다. join에서 ON 쿼리를 작성하려면 join 메소드에 on 인자로 criterion을 넘겨줘야 한다.
  • Joining multiple tables
    peewee 가이드에서 여러 테이블의 join에 대한 부분이다. join type에 대한 명시 방법, join context에 대한 이야기, join_from 메소드에 대한 가이드가 들어 있다.

MongoEngine

Zappa

  • Enabling CORS
    웹 어플리케이션에서 CORS를 처리하기 위해 Flask-CORS같은 extension을 사용하곤 하는데, 사실 API Gateway 단에서도 CORS를 지원한다. zappa_settings.json에서 cors 속성을 true로 설정하면 반영된다.
  • Scheduling
    CloudWatch Events 기능을 통해 lambda function을 스케줄링할 수 있는데, zappa_settings.json에서 events 속성을 정의하는 것으로 편하게 설정 가능하다. 따로 분리된 cronjob 함수를 WAS와 함께 관리하기 좋음.
  • X-Ray Tracing
    이것도 사실 API Gateway 기능인데, 대시보드 들어가서 켜기 귀찮을까봐 zappa 단에서 지원해준다. X-ray는 어플리케이션 성능 데이터들을 트레이싱해서 서비스맵으로 시각화해주는 도구인데, APM 용도로도 써먹을 수 있어서 요긴하게 써먹기 좋다.

boto3

Golang

언어 자체에 대한 이야기

모바일

Android

iOS

웹 프론트엔드

웹 프레임워크

Flask

Spring

Express.js

수학

  • Markov Chain
    Markov Chain에 대한 (아마도) 가장 쉬운 설명. 이거 읽고 난 다음에 다른 medium 글들을 읽어보면 될 듯.

자기계발

뭔가 어디 카테고리에 특별히 넣어두기 애매하다