기본 콘텐츠로 건너뛰기

글

최근 확 떠오르는 micro 호스팅 서비스인 now에 meteor deploy가 가능하다고 해서 시도해봄. 먼저 now 와 meteor-now를 각각 설치하고 npm install -g now meteor-now 계정부터 만들어보자. $ now --login > Enter your email: 당신의@이메일.주소 > Please follow the link sent to 당신의@이메일.주소 to log in. > Verify that the provided security code in the email matches Smooth Dormouse. ✔ Confirmed email address! > Logged in successfully. Token saved in ~/.now.json 이게 전부다. .now.json 에 있는 토큰을 잘 뒀다가 나중에 또 써먹자. 우리는 일반 유저가 아니라 프로그래머이므로 password 따위는 사치일 뿐. 좋은 인증 방법이다. 일단 작동 확인을 위해 아무거나 meteor 프로젝트를 만들어보자. git clone https://github.com/meteor/clock clock 예제 정도가 DB를 사용하지 않으니 연습상대로 적당하다. cd clock해서 meteor 프로젝트 디렉토리로 진입한 뒤 meteor-now 하거나 MONGO_URL이 없으면 warning을 보여주니 빈거라도 넣어서 묻지마 deploy를 시작해보자. $ meteor-now -e MONGO_URL= ✔ [METEOR-NOW] - building meteor app ✔ [METEOR-NOW] - preparing build ⠍⠉ [METEOR-NOW] - deploying build (this can take several minutes) 꽤 시간이 흐르고 ✔ [METEOR-NOW] - meteor app deployed to https://clock-cseoxvdfzv.now.sh 뜨든! 주...

[tip] pico-8의 GPIO 기능

http://www.lexaloffle.com/pico-8.php?page=manual  를 읽다보니 재밌는 부분이 있다. 그건 바로 pico-8이 GPIO(General Purpose Input Output)를 지원한다는 점인데 CHIP/Pocket CHIP 뿐만 아니라 Raspberry Pi에도 대응하고 심지어 HTML으로 export했을 때도 된다는 사실. pico-8에는 가상의 메모리 맵이 있고 PEEK/POKE 명령으로 해당 주소를 읽고 쓸 수 있다. 메모리 맵은 아래와 같은데 0x0    gfx 0x1000 gfx2/map2 (shared) 0x2000 map 0x3000 gfx_props 0x3100 song 0x3200 sfx 0x4300 user data 0x5e00 persistent cart data (256 bytes) 0x5f00 draw state 0x5f40 hardware state 0x5f80 gpio pins (128 bytes) 0x6000 screen (8k) 이 0x5f80영역이 GPIO랑 붙는다. PEEK(0x5f80), POKE(0x5f81, 0xff)와 같이 접근 가능하다. CHIP류에선 0~7번 핀을 0x5f80~0x5f87까지 (PocketCHIP은 0,1 생략) RaspberryPi류에선 0x5f80~0x58f8f까지 사용할 수 있다. WiringPi Pin 번호에 주의하자 여튼 GPIO를 사용할 땐 pico8을 반드시 sudo 로 구동하여야 원활하게 사용할 수 있는 점을 명심하자. 재미있는 점은 HTML을 export 했을 때 pgio8_gpio 란 글로벌 변수로 GPIO를 시뮬레이션 할 수 있다. var pico8_gpio = Array(128); 이와 같이 미리 선언하고 PEEK, POKE하면 외부에서 pico-8 모듈로 읽고 쓰기가 가능해서 매우 유용하니 꼭 기억해두자.

pico-8 finger dance

pocketC.H.I.P을 너무 사고 싶은데 가격도 오르고 배송도 압박이어서 안사려는 마음으로 pico-8을 질렀(?)다. 감사합니다. HumbleBundle. 새로운 장난감을 얻었으니 손가락을 단련하자. 부팅 후 처음 접하는 화면은 콘솔 상태. HELP를 보자 load <filename> save <filename> run resume shutdown reboot install_demos dir cd <dirname> mkdir <dirname> cd .. keyconfig splore 명령어들이 나오는데 나머지는 뭐 뻔한 거니 설명이 필요없고 splore는 포럼( http://www.lexaloffle.com/bbs/?cat=7  - 근데 forum/community/bbs 뭐가 맞는거? 용어 통일이 안되있네)에 올라온 게임들을 살펴볼 수 있는 명령인데 s만치고 엔터쳐도 된다. 오호 꿀! 여기에 있는 게임만 다 해보는 것도 일이겠다. 엄청 많다. ESC 로 커맨드라인과 개발환경을 전환할 수 있다. 개발환경모드는 이런 식으로 구성. 오른쪽 상단은 순서대로 코드에디터-스프라이트에디터-맵에디터-SFX에디터-뮤직에디터이고 ALT+좌우화살표키로 이동가능하다. 코드에디터 하단왼쪽은 LINE 현재커서위치라인/전체라인수. 오른쪽은 토큰숫자인데 명령어 하나당 하나씩 증가하고 8192. 즉 8k까지 쓸 수 있다. 핑거댄스니까 단축키 위주로 정리 CMD(CTRL)+C,X,V (copy, cut, paste) CMD(CTRL)+Z,Y (undo, redo) CMD(CTRL)+F,G (find, next) CMD(CTRL)+UP, DOWN (top, end) CMD(CTRL)+LEFT, RIGHT (word 간 이동) ALT+UP,DOWN (function간 이동) CMD(CTRL)+D (줄 복사) TAB, SHIFT+TAB (indent, un-in...

socketcluster tutorial - 11. 성능 (Performance)

성능 벤치 마크 처리량 (SocketCluster v0.9.8) 이 테스트의 목적은 SocketCluster가 적절한 머신에서 얼마나 많은 JavaScript (JSON) 객체를 처리할 수 있는지를 보는 것이었습니다. 절차 이 CPU 벤치 마크에서 SocketCluster는 Linux를 실행하는 8 코어 Amazon EC2 m3.2xlarge 인스턴스에서 테스트하였습니다. 100 명의 동시 클라이언트가 있을 때까지 매 초마다 새로운 클라이언트를 생성하였습니다. 전송한 최대 메시지 수는 170k (클라이언트 당 초당 1700 개의 메시지)로 설정하였습니다. 메시지는 완전히 양방향이었습니다 - 클라이언트는 JSON으로 캐스팅 된 JavaScript 객체를 포함하는 'ping'이벤트를 보내고 서버는 'pong'JavaScript 객체로 응답합니다. 이 객체에는 현재 워커가 지금까지 받은 총 ping의 수를 나타내는 'count'속성이 있습니다. SocketCluster는 5 개의 로드 밸런서, 5 명의 워커 및 2 명의 브로커를 사용하도록 설정하였습니다. 관측 로드 밸런서 모듈을 v0.9.12로 업그레이드하면 워커 간에 훨씬 더 균등한 분배가 이루어졌습니다. 이전 버전의 loadbalancer는 갑작스러운 트래픽 급증에도 반응이 없었습니다. 새로운 버전의 loadbalancer는 무작위 확률을 결정론적 '불운'보정으로 활용하는 알고리즘을 사용하여 부하가 워커 간에 균등하게 분산되도록 합니다. 프로세스 설정은 이전 벤치 마크에서 제대로 조정되지 않았습니다. CPU 코어보다 많은 프로세스를 사용하는 것은 낭비입니다. 더 적은 수의 프로세스를 사용하여 매우 양호한 부하로 평균 3.33을 만들었습니다 (가능한 8 개 중). 아마도 우리의 현재 설정으로 20만 개의 접속이 되도록 했을 것입니다. 로드 밸런서 5대, 워커 5개, 브로커 2개가 여전히 이상적이진 않습니다...

socketcluster tutorial - 6. 미들웨어 및 인증 (Middleware and authorization)

미들웨어 및 인증 SocketCluster를 사용하면 클라이언트는 JavaScript를 사용하여 특정 채널로 데이터를 청취하고 발행하여 메시지를 서로 공유할 수 있습니다. 기본적으로 누구나 자신이 좋아하는 채널에 데이터에 수신하고 게시할 수 있습니다. 일부 시스템에서는 이것이 문제가 되지 않지만 대부분의 시스템은 사용자가 서로 상호 작용할 수 있는 방법을 규제하기 위해 어느 정도의 접근 제어가 필요합니다. 대부분의 시스템은 적절한 접근 권한을 시행하기 위해 연결을 인증하고 권한을 부여하는 방법이 필요합니다. 미들웨어 기능은 이러한 모든 작업을 수행할 수 있는 깔끔한 중앙 집중식 방식을 제공합니다. SocketCluster에서 모든 실시간 이벤트는 서버에서 처리하기 전에 미들웨어 기능을 통과해야 합니다. SocketCluster는 다양한 종류의 상호 작용을 처리할 수 있는 다양한 종류의 미들웨어 라인을 제공합니다. 가장 유용한 미들웨어 라인은 워커 프로세스에 있지만 로드 밸런서(HTTP 용)에 의해 노출되는 미들웨어 라인이 있습니다. 이 튜토리얼에선 워커(실시간) 미들웨어에만 초점을 맞춥니다. 워커는 실시간 scServer 객체를 통해 미들웨어를 노출합니다. 이 객체는 worker.getSCServer() 를 사용하여 액세스 할 수 있습니다. 미들웨어 기능을 서버에 추가하려면 다음을 사용해야 합니다. scServer.addMiddleware (middlewareType, middlewareFunction); scServer에서 사용할 수있는 미들웨어 유형은 다음과 같습니다. scServer.MIDDLEWARE_HANDSHAKE scServer.MIDDLEWARE_SUBSCRIBE scServer.MIDDLEWARE_PUBLISH_IN scServer.MIDDLEWARE_PUBLISH_OUT scServer.MIDDLEWARE_EMIT middlewareFunction에 전달한 req인자는 사용한 미들웨어의 종류에 따라 다릅니다....

socketcluster tutorial - 10. 복수 호스트 확장 (Scaling across multiple hosts)

복수 호스트 확장 SocketCluster를 사용하면 수직적(시스템/호스트의 여러 CPU 코어에 걸쳐)으로 수평적으로(여러 호스트에 걸쳐) 확장할 수 있습니다. 수평으로 확장하려면 SCC(권장)를 사용하거나 처음부터 직접 솔루션을 구현할 수 있습니다. SCC를 사용하는 경우 SC가 시스템에서 채널 데이터를 동기화하는 방법에 대한 구현 세부 정보를 배울 필요가 없습니다. SCC SCC는 2016 년 9 월에 도입되었습니다. SC는 여러 호스트에서 SC를 확장하기 위한 컴포넌트 모음입니다. SCC는 설치가 쉬우며 뒤에서 일어나는 일에 대해 많이 알 필요 없이 수평적 확장성을 제공합니다. Kubernetes위에 SCC를 실행하면 위아래로 스케일 업이 자동으로 처리됩니다. SCC 사용에 대한 전체 안내서는 여기 에 있습니다. SCC를 사용하는 경우 '수동으로 크기 조정'에 대한 아래 섹션을 읽을 필요가 없습니다. 수동으로 크기 조정 수평적 확장의 목표는 최적의 방법으로 트래픽을 모든 사용 가능한 시스템에 분산하는 것입니다. SocketCluster의 컨텍스트에서 수평 확장은 두 가지 특정 문제로 귀결됩니다. 들어오는 클라이언트 연결을 보낼 호스트를 어떻게 선택합니까? 한 클라이언트가 채널에 데이터를 게시할 때 다른 호스트의 해당 채널에 가입 한 다른 클라이언트가 채널 데이터를 실시간으로 수신하는지 어떻게 확인할 수 있습니까? 첫 번째 과제에 접근하는 데는 여러 가지 방법이 있습니다. 예를 들면 다음과 같습니다. 무작위로 호스트 URL을 선택하고 클라이언트 소켓의 connect() 메서드에 옵션으로 전달하여 각 클라이언트를 호스트 중 하나에 직접 보낼 수 있습니다. 로드 밸런서를 사용하여 들어오는 연결을 대상 호스트에 고르게 분산할 수 있습니다. 타사 서비스를 사용할 수도 있고 직접 설정할 수도 있습니다. SocketCuster v1.xx를 사용하는 경우 sticky로드 밸런서(예 : IP 주소 기반의 Sticky)...

socketcluster tutorial - 9. SSL을 적용한 상용 서비스 운영(Running in production (with SSL))

SSL을 적용한 상용 서비스 운영 SocketCluster에 시스템을 구축할 때 마스터 프로세스(server.js)에 런타임 구현을 배치하지 않는 것이 중요합니다. 이러한 구현은 worker(worker.js) 내부에 배치하는 것이 좋습니다. 마스터 프로세스와 달리 워커는 충돌할 때마다 (오류가 발생하지 않는 경우) 자동으로 재발행하고 서비스 중단을 최소화됩니다. 일반적으로 워커는 재발생하는데 1 초 미만이 걸리므로 사용자에게 투명해야 합니다. 마스터 프로세스는 일반적으로 초기 실행 구현을 넣고 장시간 실행되는 데몬 프로세스를 생성하기에 좋은 곳이지만 일단 시스템이 실행되면 오류가 발생하기 쉬운 논리를 실행하는데 이 프로세스를 사용하지 않아야합니다. 이러한 규칙을 따르는 경우 Node 명령을 사용하여 직접 SocketCluster 서버를 실행하면 실제 운영 환경에서 정상적으로 작동합니다. (인수 포함 예제). nohup node server.js -w 2 -s 2 & 안심할 수 있도록 master를 자동으로 재생성하려면 forever를 사용하십시오. npm install -g forever 설치한 후 다음과 같이 실행하십시오. forever start --killSignal=SIGTERM server.js -w 2 -s 2 어떤 경우든 서버 기반 코드를 강제로 업데이트하기 위해 거의 다운타임 없는 배포를 수행하는 경우 마스터 프로세스에 SIGUSR2 신호를 보낼 수 있습니다. 자세한 내용은 이 문제 를 참조하십시오. SSL 프로덕션 환경에서 SC를 실행할 때 고려해야 할 또 다른 중요한 점은 일부 오래된 프록시가 WebSocket 트래픽을 차단할 수 있다는 것입니다. 이 문제를 방지하려면 SC 인스턴스에 키/인증서 SSL쌍을 제공하여 HTTPS/WSS를 통해 앱을 제공해야합니다. SSL/TLS를 사용하도록 SC를 구성하려면 부팅 옵션 을 설정해야합니다. '프로토콜'을 'https'로 설정하...