2014-12-19

Facade pattern - 간단한 인터페이스 만들기

 퍼사드 패턴이란 복잡한 서브 시스템에 하나의 레이어를 씌워서 복잡한 시스템을 사용하기 쉽게 만드는 방식을 말한다. 퍼사드 패턴은 레이어를 하나 추가하지만, 이 레이어는 추상화가 목적이 아니다. 어디까지나 사용하기 쉽게 만드는 것이 목적이다. 그래서 보통 퍼사드의 인터페이스는 매우 간단한 모습을 가진다.
http://en.wikipedia.org/wiki/File:Example_of_Facade_design_pattern_in_UML.png

 퍼사드 패턴의 대표적인 사용처는 로그 API다. 로그를 그대로 STDOUT에 출력할 수 도 있고 어딘가에 저장할 수도 있다. 저장하는 것도 로컬에 있는 파일에 기록을 남길 수도 있고, 데이터 베이스에 파일을 저장할 수도 있고, 그 이외의 방식으로 로그를 저장할 수도 있다. 즉, 만약 파일에 저장한다면 적절하게 파일 포인터를 관리해야 하고, 데이터 베이스에 저장한다면 그 connection을 적절하게 관리해야한다. 게다가 로그를 저장하는 것도 IO로 인한 병목을 피하기 위해 일정 시간 혹은 일정 갯수의 로그를 모았다가 저장할 수 도 있다. 만약에 모았다가 저장한다면, 저장할 조건을 만족시키지 않았더라도 프로세스가 종료되기전에 저장을 완료해야 한다.
 이런 조건들을 사용자가 일일히 챙겨가며 로그를 저장하는 것은 귀찮은 일이다. 그래서 Logback같은 API에서는 back-end가 어떻게되든 상관 없이 필요한 back-end를 사용하도록 초기화해주면, 그 뒤로는 같은 인터페이스로 기록을 남길 수 있게 해준다.

 전에 소개한 적 있던 Pluggable한 log aggregator인 fluentd의 경우도 퍼사드 패턴을 사용한다. Input plug-in, Buffer plug-in, Output plug-in은 모두 간단한 인터페이스만을 요구한다. 덕분에 fluentd의 engine은 간단한 코드를 유지할 수 있고, 간단하게 원하는 back-end를 선택해서 동작을 바꿀 수도 있다.


본 글은 CC BY-SA 3.0 라이센스를 따릅니다.

2014-12-18

file URI와 same-origin policy

 modern web browser에는 보안을 위한 여러 가지 기능들이 들어있다. 그중 가장 대표적인 기능이 same-origin policy다. same-origin policy 덕분에 (개발자 입장에서는 약간 짜증 나기는 하지만) 특별히 신경을 쓰지 않아도 보안에 관해 상당히 많은 부분을 커버할 수 있다. same-origin policy의 원칙은 매우 간단하다. 내 사이트가 다른 사이트에서 호스팅 되는 리소스에 의존하는 것을 금지해서, 내 사이트가 오염되거나 다른 사이트에 의해 공격당하는 것을 막는 것이다.

 same-origin인지 결정하는 것은 매우 간단한데 프로토콜, 호스트, 포트가 같은 URI를 same-origin이라고 판단한다. 요새는 대부분 개인 서버와 개인 도메인을 사용하기 때문에, 프로토콜과 포트까지 같은지 판단하는 것은 너무 빡빡한 기준이라고 생각할 수도 있지만, 워크스테이션이나 공용 서버에서 작업하는 일도 많다는 것을 생각하면 포트와 프로토콜까지 고려하는 것은 역시 상식적인 판단이라고 할 수 있다.

 브라우저에서 많이 쓰이는 http나 https에서는 이 규칙이 상식적이라고 할 수 있다. 문제는 file URI에서의 동작이다. file URI에 대해서는 어떤 URI를 same-origin이라고 할 것인지 정해진 것이 없고, 브라우저마다 알아서 자신이 옳다고 생각하는 방식으로 구현했다.

 우선 오페라는 file URI도 다른 URI와 같은 정책으로 처리한다. 따라서 file URI로 접근한 페이지에서는 읽기 권한이 있는 모든 파일을 읽어서 리소스로 활용할 수 있다. 어차피 파일은 OS가 access list로 보호하고 있으니, 로컬 파일에 대한 보안을 OS에 맡겨 버린 것이라고 할 수 있겠다. 약간 무책임한 것 같지만, 오페라의 구현이 가장 웹서버 없이 웹 페이지를 테스트하기 편한 구현이다.

 반면 크롬은 modern browser 중에 가장 빡빡한 규칙을 적용한다. 크롬에서는 file URI로 들어오는 요청에 대해 무조건 다른 origin인 것으로 처리한다. 심지어 host name을 명시적으로 입력해서 겉으로 보기에는 protocol, host name, port가 같아서 같은 origin으로 보이는 경우도 다른 origin인 것처럼 처리한다. 따라서 크롬에서는 웹 서버 없이 웹 페이지를 테스트하는 것이 불가능한 경우도 생긴다.
 이렇게 빡빡한 규칙을 적용한 이유는 찾을 수 없었다. 아마도 크롬이 Chrome OS와 코드를 공유하기 때문으로 추측된다. Chrome OS의 파일 권한이 앱별로 있는 것이 아니라서 다른 앱에서 로컬에 있는 파일을 읽는 것을 막기 위해서 file URI를 모두 다른 origin으로 취급해야 했던 게 아닐까 싶다.

 파이어폭스는 크롬과 오페라의 중간 정도 되는 정책을 취한다. 파이어폭스에서 file URI를 쓰면 현재 directory를 기준으로 자신보다 아래 경로에 있는 파일은 읽을 수 있도록 허용한다.1) 덕분에 파이어폭스도 웹 서버 없이 테스트하지 못하는 웹 페이지가 생기기도 한다. 하지만 크롬보다는 상황이 조금 나은 게 최소한 자신의 것이 확실한 (자기 디렉토리 아래에 있는)리소스는 마음껏 사용할 수 있다.

 크롬 브라우저에는 file URI를 이용하면서도 다른 파일을 같은 origin인 것처럼 사용하는 방법도 있다. 크롬을 실행할 때 --allow-file-access-from-files switch를 이용하면 file URI에서 모든 파일에 접근할 수 있도록 해준다. 주의해야 할 것은 기존에 실행시켰던 크롬이 백그라운드로 떠 있으면, 새로 크롬을 실행시켜도 백그라운드 프로세스로 떠 있던 크롬이 포크 되며 실행되기 때문에 switch가 반영되지 않는다. 따라서 switch를 주면서 크롬을 실행시킬 때는 기존의 프로세스가 전부 꺼졌는지 확인하고 실행해야 한다.
 파이어폭스도 file URI에 대한 동작을 변경할 수 있다. security.fileuri.strict_origin_policy 설정을 이용하면 오페라와 같이 모든 로컬파일을 리소스로 쓸 수 있게 된다.

 이런 식으로 크롬이나 파이어폭스를 이용해도 switch나 preference를 통해서 file URI로 로컬에 있는 페이지에 접근해서 테스트할 수도 있다. 하지만 테스트를 위해서가 잠시 값을 바꿔서 쓰는 게 아니라 기본값을 바꿔서 계속 사용하는 것은 좋은 방식이 아니라고 생각한다. same-origin policy라는 것의 목적은 보안을 위한 것이다. 보안을 위한 기능을 편의를 위해 끄고 쓰는 것은 열쇠 가지고 다니기 귀찮다고 문 열어놓고 다니는 것과 마찬가지의 행동이다.
 게다가 file URI를 통해 간단한 테스트는 가능할 수도 있지만, file URI는 http나 https와 동작이 달라서 실제 웹앱과 완벽하게 같은 테스트는 안된다. 따라서 실제로 웹 서버를 띄우는 것이 가장 확실한 방법이다.

 하지만 구태여 웹 페이지를 file URI로 테스트하려고 했던 것은, 현재 머신에 웹서버를 설치하기 싫거나, 설치할 수 없거나, 설정하기 귀찮은 경우일 것이다. 그런 상태에서 웹 서버를 설치하고 테스트하라고 말해봐야 보안에 구멍이 생기더라도 브라우저 설정을 바꾸는 것을 택할 것이다. 그런 사람들을 위해 간단하게 웹서버 돌리는 방법을 소개해 주겠다.

 어디든지 실행시키고 싶은 웹 앱의 최상단 경로에서 python3 -m http.server {port}를 입력하면 python으로 웹 서버가 실행된다. 아무 기능도 없지만, 최소한 file URI로 테스트하려던 수준의 웹 페이지라면 충분히 테스트할 수 있다.

1) https://developer.mozilla.org/en-US/docs/Same-origin_policy_for_file:_URIs

2014-12-14

WebGL 공부 시작

 나는 그래픽스 관련해서는 모든 것을 야매로 배웠었기 때문에, 전반적으로 기초가 없다. 이게 나름대로 꽤 스트레스였다. 하지만 천성적으로 게을러서, 계속 언젠가는 제대로 공부해야 한다고 생각만 하고 미루기만 했다. 그러다가 문득 이렇게 미루기만 하면 언젠가 후회할 날이 올 것 같아서 바로 공부를 시작하기로 했다.

 우선 공부할 그래픽스 라이브러리는 OpenGL로 정했다. 모바일 시장이 있어도 역시 많이 쓰이는 것은 Direct3D고, 게다가 apple에서는 metal이라는 새로운 그래픽스 라이브러리를 발표해서 OpenGL의 입지가 더 줄어들 것이라고 한다. 하지만 나는 이번 목표가 당장 어딘가에 써먹기 위한 것을 배우기 위한 것이 아니라 기본적인 것을 배우기 위한 거라서 뭘 하더라도 상관없었다.
 사실 지금 내 윈도우 pc는 망가지고, iMac은 이제 개발용으로 쓰기에는 성능이 너무 나빠서 별 다른 선택의 여지가 없었다.

 OpenGL API 구현체도 platform 별로 여러 가지 구현체가 있다. 나는 그중에서 WebGL을 공부하기로 했다. 특별히 web platform에서 작업할 일이 있었던 것은 아니지만, 리눅스 환경에서 OpenGL로 코딩하려면 리눅스 드라이버를 수동으로 재 설치해야 하는 경우가 많아서 브라우저만 있으면 바로 작업 가능하다는 특징은 WebGL의 큰 장점이라고 생각한다.

 그리고 무엇보다도 WebGL Inspector라는 좋은 디버깅 툴이 있다는 것은 WebGL
 사실 WebGL의 가장 큰 장점은라고 생각한다. 리눅스에서 OpenGL 개발 환경을 구성할때는 개발 환경 자체를 준비하는 것도 귀찮지만, 디버깅 환경을 구성하는 것이 진짜 귀찮다. 그래픽 드라이버 버전에 따라서는 아예 디버깅할 수 없어서 무조건 실행시켜보는 수밖에 없는 경우도 있다.
 하지만 브라우저의 플러그인 형식으로 설치 가능한 WebGL Inspector를 사용하면, 프레임을 멈추거나 속도를 조정할 수도 있고, 어떤 콜이 불렸는지, array buffer나 element array buffer에 어떤 값이 들어있는지, 어떤 프로그램을 사용했고, 현재 state가 어떤지, texture의 값은 어떤지까지 알 수 있어 다른 환경보다 상대적으로 쉽게 디버깅할 수 있다.

 물론 WebGL이 무조건 좋은 것은 아니다. 기본적으로 OpenGL API에서는 멀티 스레딩을 위한 lock이나 동기화 방식을 제공하지 않는다. 그래서 고급 테크닉들을 보면 대부분 어떻게 멀티 스레딩 환경에서 효율적으로 작업을 나누어 그림을 그리는가가 대부분이다. 하지만 WebGL은 main thread에서밖에 호출할 수 없어서 이런 테크닉을 쓸 수 없다.
 하지만 이는 어디까지나 고급 테크닉들이고 기초와는 상관없기 때문에 WebGL로 시작하는 게 딱히 문제 될 것 같지는 않았다.

2014-12-11

도메인 이전했습니다.

며칠 전에 말했던 대로 http://blog.seulgi.kim으로 이전했습니다.

기존 도메인인 blog.seulgik.im으로 접속해도 리다이렉트 되겠지만, 해당 도메인은 앞으로 사용할 예정이 없어서 2016년 6월(!) 이후로는 접속이 안 될 겁니다.

2014-12-03

조만간 도메인 이전합니다.

기다리고 기다리던 seulgi.kim을 드디어 샀네요.
조만간에 blog.seulgi.kim으로 이전합니다.

바로 이전하고 싶은데 blogger가 동시에 여러 개의 cname을 지원하지 않네요.
요새 너무 바빠서 시간 나면 리다이렉트 페이지 만들고 그때가서 이동할게요.