EminentStar's Dev Wiki

HTTPS 란 HTTP의 가장 유명한 보안 버전이고 그냥 보안 전송 계층(SSL; Secure Socket Layer)를 통해 전송되는 HTTP다. 기존의 HTTP가 암호화되지 않은 메시지를 TCP를 통해 다른 곳으로 전송했다면, HTTPS는 HTTP 메시지를 TCP로 보내기 전에 먼저 이걸 암호화 하는 보안 계층으로 보낸다. 보안 계층은 SSL과 이것의 현대적 대체품인 TLS로 구현되었는데, 이 둘을 모두 의미하는 단어로 SSL이 자주 불린다고 한다. URL이 https스킴을 가지고 있다면 클라이언트는 서버에 443번 포트로 연결하고 서버와 바이너리 포맷으로 된 몇개의 SSL 보안 매개변수를 교환하면서 핸드쉐이크를 하고 그 후에 암호화된 HTTP 명령이 뒤를 잇는다. SSL 트래픽은 바이너리 프로토콜이..

OS는 OSX,pyenv와 virtualenv가 설치있다고 가정한다. 파이썬 가상환경 설정 및 앱 구축$ pyenv virtualenv 3.5.2 JWT-sample-3.5.2$ pyenv shell JWT-sample-3.5.2 $ pip install --upgrade pip$ mkdir jwt-sample && cd jwt-sample$ pip install django==1.8$ django-admin startproject jwtsite . setttings.py 변경 (jwtsite/settings.py)TIME_ZONE = 'Asia/Seoul'#########STATIC_URL = '/static/'STATIC_ROOT = os.path.join(BASE_DIR, 'static') Data..

로컬에서 로그인을 할 때psql -d 데이터베이스명 -U 데이터베이스계정명 외부의 PostgreSQL에 로그인을 할 때psql -h host명 -d 데이터베이스명 -U 데이터베이스계정명 데이터베이스 목록 조회(데이터베이스에 접속한 상태에서)# \l 데이터베이스 변경(데이터베이스에 접속한 상태에서)# \c 데이터베이스명기본적인 테이블 생성(데이터베이스에 접속한 상태에서)CREATE TABLE table_name( column1 datatype, column2 datatype, column3 datatype, ..... columnN datatype, PRIMARY KEY( one or more columns ) ); 테이블 목록 조회(데이터베이스에 접속한 상태에서)# \d테이블 상세 스키마 조회(데이터베이..

Bitbucket Private Repository를 ssh key를 이용하여 git clone 해오기 bitbucket의 private 저장소를 로컬로 받아오려면 두가지 방법이 있다. (내가 아는한..?)ssh 프로토콜를 이용하여 clonehttp 프로토콜을 이용하여 clone예를 들어, ssh 프로토콜을 이용한 bitbucket의 ssh-key-add 리포지토리의 복제는 git clone git@bitbucket.org:junk3843/ssh-key-add.git와 같다. 그리고 http 프로토콜을 이용한 bitbucket의 ssh-key-add 리포지토리의 복제는git clone https://junk3843@bitbucket.org/junk3843/ssh-key-add.git와 같다. 이때 htt..

형상관리를 하면서 프로그램을 짜다보면 기능 구현을 위한 커밋과 lint작업이나 리팩토링과 같은 작업의 커밋들이 있다. 하나의 커밋에 이들을 섞지말고, 분리해서 작업하자.

로그는 집약과 수집을 구별해서 다룸이렇게 구별하는 이유는 각각의 목적과 정밀도가 다르기 때문집약: 웹 서버가 출력하는 로그를 항상 전송해서 한곳에 모으는 것수집: 각 서버상에 출력된 로그를 정기적으로 모아서 저장하는 것 로그를 집약하는 목적: 순간순간의 상황을 파악하기 위함 (무슨 일, 어디서 일어나고 있는지) 장애 발생시 어떤 머신에서 문제가 일어나고 있는지를 확인사이트의 액세스 상황(순간 페이지뷰, 사용자 수등을 집계) 로그를 수집하는 목적: 집계, 분석, 그리고 보존을 위함서비스 운영시 웹서버나 AP서버의 로그 집계, 분석을 기본로그 분석에는 일별, 주별, 월별등 다양한 단위의 로그가 필요한데, 이를 위해 로그가 여러군데 분산되어 있으면 불편하다. 로그 집약, 수집에는 다양한 방법이 있다. 파일이 ..

GitHub Flow는 Deploy가 빈번하게 일어나는 프로젝트에 알맞은 브랜치 기반 워크플로우이다.여기서 deploy란, 소스 코드를 실제 환경에 올려서 실행하는 것을 의미한다.deploy를 자주 하려면 단순한 개발 과정 및 자동화된 환경이 필요되어지는데 이를 위해 github flow는 적절하다. GitHub Flow 기본 흐름master는 항상 deploy할 수 있는 상태로 둔다.새로운 작업을 수행할 때는 master 브랜치로부터 새로운 브랜치를 작성; 새로운 브랜치의 이름은 무슨 작업을 할지 알 수 있도록 자세히.작성한 브랜치를 local repository에 commit같은 이름의 브랜치를 GitHub remote repository에 만들고 해당 remote repo.에 주기적으로 push커뮤..

Pull Request(이하 PR) PR이란 내가 추가한 변경 사항을 다른 상대의 리포지토리에 적용하고 싶을 경우 사용하는 것GitHub에서 PR을 보내면 해당 리포지토리의 소스코드에 Issue가 생성됨. 개발이 아직 덜끝난 것에 대한 PR이라면 PR 제목에 '[WIP]bulabula~~'라고 [WIP]를 붙여줄 것. (Work In Progress)작업이 다 끝나면 [WIP]를 지워준다.PR을 할때 토픽 브랜치를 하나 생성해서 작업후 그 토픽 브랜치에서 PR을 보내자.PR보내고 나서도 그 토픽 브랜치에서 작업후 푸시하면 PR에 연결됨. Fork 리포지토리 최신 상태로 유지하는 방법fork나 clone을 하고나서 리포지토리를 계속 방치해두면 최신 버전의 소스 코드와 멀어지게됨.보통 clone한 리포지토리..

Consistent hashing: 웹서버의 갯수가 변동하는 가운데 요청을 분산하는 방법. 출처: wikipedia 해시테이블의 크기가 변할때, 평균적으로 K/n의 키만 재매핑되면 된다. 즉, 노드나 슬롯의 개수가 바뀔때, 노드의 추가나 삭제를 할 때, 오직 K/n의 아이템만 다시섞이면 됨. (n은 전체 노드의 갯수, K는 item의 개수) 기존의 해싱에서는 슬록의 개수 변화가 거의 모든 키가 다시 재매핑되야만 했다. (키와 슬롯간의 매핑이 모듈러 연산에 의해 정의되었기 때문) Consitent hashing이 사용되는 상황Consistent hashing은 분산 캐싱을 위해 나오게 되었다. 이는 변화하는 웹서버들의 수들 사이에서 요청을 분산하는 방법의 하나로 소개되었다. 또한 consistent has..

어떤 기술이 있으면 그게 뭔지는 중요하지 않다. why it was introduced, what problem it was trying to solve, when it is appropriate to adjust,what advantages and disadvantages it has,what kind of other methods there were before it was introduced, 를 생각하면서 공부를 해야한다.