ElasticCache 기반 메시징 애플리케이션 개발

AWS에서 제공하는 인프라와 서비스들을 이용해서 대량의 메시지를 교환하는 메시징 애플리케이션을 만들어보려 한다. 메시지는 을 이용한다. 아래와 같은 구성을 가질 것이다.PUB/SUB은 REDIS 고유의 기능으로 구현에 어려움은 없다. 1. 채팅방에 해당하는 Topic을 만든다. 1. 메시지 수신자는 해당 Topic을 구독(REDIS SUBSCRIBE)한다. 1. 송신메시지는 해당 Topic에 출판(REDIS PUBLISH)한다. 1. PUBLISH된 메시지는 모든 수신자가 받아볼 수 있다.

Javascript로 페이지 이동

HTML meta 태그와 javascript를 이용한 두 가지 방법이 있다.

Mysql 외래키

데이터베이스는 여러 개의 테이블로 구성되기 마련이다. 이들 테이블은 특정 키(혹은 필드)를 매개로 서로 연결이 되는데, 이 키를 외래키(foreign key)라고 한다. RDBMS(Relational database management system)에서 명시적으로 테이블을 연결(relation)해주는 장치다. 아래는 joinc 사이트의 유저 관리 테이블이다.이 3개의 테이블은 user.id로 연결된다. preference 테이블과 bookmark 테이블의 userid가 외래키이다. 다른 말로 이 두 테이블은 userid를 키로 user.id를 참조한다고 할 수 있다.

S3기반의 클라우드 스토리지 개발

서비스에서 다루는 데이터의 크기와 갯수가 늘어나면서, "고가용성의 확장가능한 클라우드 스토리지"에 대한 수요도 늘어나고 있다. 단일 서비스에서도 와 같은 기능을 일반적으로 제공할 수 있어야하는 시대라는 거다. s3를 이용해서 드롭박스와 같은 서비스를 만들어보려고 한다. s3를 이용하는 이유는 아래와 같다. 가용성과 확장성을 고민 할 필요가 없다. OpenStack Swift등을 이용해서 비교적 쉽게? 구축 할 수 있을 것이다. 하지만 굉장히 고달픈 작업이라는 것을 깨닫게 될 것이다.

알고리즘 - 생일 케이크

매년 조카의 생일케이크를 준비해야 하는 임무가 주어졌다. 당신은 케이크와 함께 조카의 나이 만큼의 초도 준비해야 한다. 케익을 받은 조카가 촛불을 끄기위해서 바람을 불면, 그 중 가장 길이가 긴 촛불이 꺼지게 된다. 조카가 바람을 불었을 때 몇 개의 촛불이 꺼질지를 계산해야 한다.예를 들어 4살 조카의 생일 케이크라면 4개의 초도 함께 준비해야 할 것이다. 초의 길이가 3, 2, 1, 3 이라면, 이 중 가장 긴 초의 길이는 3일테고 두개의 촛불이 꺼질 것이다.

알고리즘 - 시간변환

AM/PM을 가지는 12시간 시간형식을 군대형식(24시간)으로 변환하라. AM/PM에 대한 시간 정의는 아래 그림을 참고 하자. 12시간 형식에서 AM 12 12시간 형식에서 PM 12hh01 \leq hh \leq 12 와00 \leq mm,ss \leq 59이다."hh00 \leq hh \leq 23입력이07일때 출력은19이다. 에러처리는 하지 않았다.package mainimport ( "bufio" "fmt" "os" "strconv" "strings")func timeConversion(str string) string { times times times times tail switch tail { case "AM"

AWS SAMLocal

AWS는 서버리스 환경에서의 애플리케이션 구현 모델인 AWS SAM을 개발하고 있다. 여기에는 SAM 사양과 SAM 템플릿을 AWS CloudFormation으로 변환하는 코드, 프로그래밍 예제 등을 포함하고 있다. SAM Local은 SAM의 구현체다. 서비리스 응용 프로그램을 만들려면, 람다함수에 대한 사양을 저장하는 JSON이나 YAML 형식의 SAM 템플릿을 만든다. 그리고 SAM 구현체 중 하나인 SAM Local의 CLI를 이용해서 응용 프로그램을 테스트 하고 업로드 및 배포를 한다. SAM은 응용 프로그램의 사양을 클라우드포메이션 구문으로 변환하면서, 지정되지 않은 속성들을 기본 값으로 채우고 호출 권한등을 결정해서 람다를 배포 한다.

The Behavior of Channels

처음 go의 채널을 사용 했을 때, 나는 채널을 데이터 구조체(스트럭처)처럼 다루는 실수를 했다. 채널은 고루틴(goroutine)사이에서 큐를 제공하고, 자동으로 데이터를 동기화 해주는 것이라고 보았기 때문이다. 이렇게 채널을 구조체로 보는 것 때문에, 복잡하고 나쁜 동시성 코드를 만들게 됐다. 시간이 지나면서 채널을 스트럭처로 보는 대신, 행위에 중점을 두는게 좋다는 것을 알게 됐다. 이제 나는 채널을 구조체가 아닌 시그널링(signaling)로 바라본다. 채널은 하나의 고루틴에서 다른 고루틴으로 어떤 이벤트를 보내는 시그널이다. 시그널을 주고 받는 행위가 채널의 핵심이다. 채널을 시그널 관점에서 보면, 좀 더 깨끗하고 정확히 작동하는 코드를 만들 수 있다.