code atelier

블로그 제목을 좀 바꿔야 하나 싶다. 제목 때문에 더 글을 안 쓰게 되는 것 같다. 당최 무슨 생각으로 이런 이름을 붙였는지 모르겠다. 'code atelier'라는 말이 담고 있는 이미지는 너무 이상적인 것 같다. 이미지도 이미지지만 '아틀리에'라는 간판을 내걸 정도로 그렇게 능숙하게 '코드' 이야기를 풀어낼 정도로 능력이 있는 것도 아니고. ('프로그래밍을 주제로 하는 블로그를 운영하려면 프로그래밍 능력이 뛰어나야 해!'라는 이야기를 하는 게 아니다.)

https://gist.github.com/kyukyukyu/17f2cf941bf00e885f84

내가 주로 사용하는 컴퓨터에서 실행되는 운영체제가 Windows에서 OS X으로 변경된 지 어느덧 3년을 넘어 어느덧 4년째다.

맥을 쓰기 전에는 음원 스트리밍 서비스를 사용하지 않았다. 맥을 쓰기 시작할 무렵부터 벅스를 사용하기 시작했고, 그리고 지금은 네이버 뮤직을 사용하고 있다. 벅스나 네이버 뮤직이나, OS X에서 돌아가는 네이티브 클라이언트 앱이 없는 탓에 맥으로 iTunes에 없는 노래를 들을 때에는 웹 브라우저로 사이트에 들어가서 스트리밍 서비스를 이용하곤 한다.

얼마 전에 Spotify에 가입했다. VPN 쓰니까 가입이 아주! 잘 된다. 가입한 다음부터는 VPN을 사용하지 않아도 Spotify 서비스를 자유롭게 이용할 수 있더라.(?!)

Spotify에는 맥용 클라이언트 앱이 있다. 물론 내 맥에 설치해뒀다. 이거 정말 편하다. 서비스를 이용하기 위해서 웹 브라우저를 항상 띄워둘 필요도 없고, 행여나 웹 브라우저를 다시 시작해야 할 때에도 음악 감상을 계속할 수 있고, 심지어 핫키 연동도 매끄럽게 된다. 단순히 음악을 감상하는 사용자 입장에서는 iTunes를 사용하는 것과 거의 유사한 경험으로 다가온다. Spotify에서 제공하는 플레이리스트나 라디오 같은 컨텐트가 마음에 들기도 하지만, 클라이언트가 운영체제와 통합되어 있다는 느낌도 이 서비스에 빠져들게끔 만들지 않나 싶다.

한편으로, 아니 사실 제일 처음에 든 생각은 이거다. '아, 이래서 사람들이 멜론을 불편하게 느끼지 않는구나.' 예전에 Windows를 사용하면서 멜론 클라이언트를 썼던 걸 돌이켜보면, 나름 괜찮았던 것 같다. 바탕 화면에 있는 멜론 아이콘을 더블 클릭하고 로그인 하면 플레이어가 그냥 뜨니까. 트랙 다운로드해서 iTunes 라이브러리에 바로 꽂아주는 기능도 있고. 굳이 필요한가 싶긴 하지만 폰트를 변경하는 기능도 있다. 핫키 연동은... 글쎄 이건 잘 모르겠다. 되나?

사상-누각 (沙上樓閣)

명사

모래 위에 세운 누각이라는 뜻으로, 기초가 튼튼하지 못하여 오래 견디지 못할 일이나 물건을 이르는 말.

(출처: 네이버 국어사전)

문득 이 말이 생각난다.

2.

써브웨이 샌드위치에서 샌드위치를 주문할 때에는 아래와 같은 절차를 거친다.

메뉴를 고른다.

빵을 고른다.

빵을 구울지 말지 고른다.

넣을 야채를 고른다.

소스를 고른다.

계산한다.

손님이 샌드위치를 주문할 때, 보통 4번 단계에서 점원이 "야채 뭐뭐 넣으시겠어요?" 라고 손님에게 묻는다. 내가 지금까지 써브웨이 매장을 이용하면서 이렇게 물어 보지 않은 경우는 없었다. 나는 그 때마다 "다 넣어주세요" 아니면 "골고루 넣어주세요" 라고 답한다. 아마 다른 손님들도 그렇게 말할 것이다.

그런데 어제, 써브웨이 샌드위치 정자점을 이용할 때에는 달랐다. 4번 단계에서, 점원이 나에게 "싫어하시는 야채 있으세요?" 라고 물었다. 점원의 질문이 달라지니, 나의 대답도 달라진다. "아니요."

다른 손님들도 나처럼 야채를 골고루 넣고 싶어하는지 확실하지 않지만, 만일 그렇다면 점원이 다르게 질문함으로써 많은 손님들이 4번 단계를 더욱 편리하게 거칠 수 있다고 할 수 있다. '무엇인가' 하는 질문보다는 '그런가 아닌가' 하는 질문에 훨씬 간단하게 답할 수 있기 때문이다.

지금 내가 겪은 일이 딱 이런 경우다. 한 달 정도 전인가? 어떤 모델을 나타내는 관계형 스키마를 정의할 일이 있었다. (사실 SQLAlchemy를 사용하였기 때문에 관계형 스키마를 직접 정의하진 않았다.) 이 모델에는 객체가 나중에 위치할수록 더 큰 양의 정수를 갖는 순서값 속성이 있었다.

스키마를 정의하면서, 나는 이런 생각을 했다. '여러 객체가 동일한 순서값을 가지면 나중에 객체들을 순서대로 나열할 때 문제가 생길 수 있으니까, 순서값을 나타내는 컬럼에 UNIQUE constraint를 걸어놓는 게 좋겠어.' 그래서, 걸었다. 별 문제가 없었다. 객체들의 순서를 변경하는 기능을 구현하기 전까지.

얼마 전에 이 모델의 객체들을 다루는 관리 도구를 구현하기 시작했는데, 새로 생성되는 객체가 맨 앞에 위치하도록 관리 도구를 구현해야 했다. 그래서 새로운 객체의 순서값을 1로 설정하고, 기존에 존재하던 모든 객체들의 순서값을 1씩 증가하도록 코드를 작성하였다. 대충 아래와 같다.

query.filter(pos_col >= new_pos) \ .update({pos_col: pos_col + 1}, synchronize_session=False)

그런데 코드가 제대로 작동하지 않았다. DB에 저장된 순서값이 1, 2, 3, 4, ... 와 같이 인접한 정수들인 경우에 중복된 키 값이 존재한다고 오류가 발생하는 것이었다.

해결책을 고민해 보았다. 기존의 객체들을 순서값 기준 내림차순으로 정렬한 다음에, 순서값을 하나씩 증가시키고, 트랜잭션을 마치고, 순서값을 하나씩 증가시키고, 트랜잭션을 마치고, ...를 반복하면 어떨까? 쿼리가 너무 많이 발생한다.

알고 보니 UPDATE 문에도 ORDER BY 절을 사용할 수 있다고 한다. 근데 SQLAlchemy에서 지원을 안 한다. 헐. 그렇다고 raw query를 날리자니 영 찜찜하고.

결국 스키마를 정의할 때에 걸어둔 UNIQUE constraint를 지우는 것으로 문제를 해결하였다. 뭐... 그랬다.

오늘부터 내일까지 네이버에서 DEVIEW 2013을 진행한다. 첫째 날에 진행된 세션들 중에서 내가 들은 세션들에서 무엇을 다뤘고, 어떤 생각을 했고 무엇을 느꼈는지 이야기해 보겠다.

Android Bionic Linker

SK planet에서 T store ARM (Application DRM)을 구현한 이야기. 어렵다. 배경지식이 부족해서. 어... 딱히 할 말이 없네?

프로그래머로 산다는 것

<프로그래머로 산다는 것>의 공동저자 유석문씨의 이야기. '자바 3~5년 경력 개발자를 대상으로 기술면접을 보면 스택을 못 짜더라'는 이야기는 꽤나 충격적이었다.

<애자일 프랙티스>에 나오는 이야기와 이번 학기에 '컴퓨터구조론' 강의를 들으면서 배운 과학과 공학의 차이가 생각났다. 이야기가 많이 겹쳐서.

'좋은 개발자'는 '공유'와 '협업'을 할 줄 알아야 한다고 말씀하셨다. '공유'를 하는 이유는 본인이 관대하거나 잘나서가 아니라, '주변 사람을 똑똑하게 만들어 사고를 줄이기 위해서'라고 하셨다. 음... 그럴싸한 말이긴 한데 주변 사람들이 나보다 똑똑한 경우도 얼마든지 있기 때문에 반드시 맞는 말은 아닌 것 같다는 생각이 든다. 성공 사례보다는 실패 사례를 공유하는 게 도움이 된다는 이야기와 메일링 리스트, 세미나 (재미있게), 코드 리뷰 등의 방법을 사용하라는 말씀에는 동의.

'협업'의 전제 조건은 상대에 대한 이해라고 하셨다. 당연한 이야기이지만 잘 안 지켜지니까 강조하셨을 것이다. 상대에 대한 이해만큼 중요한 것이 자아존중감이라고 하셨는데, 자신이 있는 그대로를 인정하고, 타인의 부정적인 견해에 크게 (부정적으로) 영향을 받지 않아야 한다고 하셨다. 음! 좋은 말씀.

그리고 끊임없는 연습을 강조하셨다. 이 또한 지극히 당연한 이야기. 전반적으로 '새롭다'고 느낀 이야기는 많지 않지만 당연하면서도 중요한 이야기니만큼 이것들을 다시 한 번 생각하게 되는 계기가 되었다.

OSCON 이야기

이거는 등기 우편 하나 부치고 오느라 늦어서 제대로 못 들음. 몰랐는데, 일본에 개발자 커뮤니티가 그렇게 크다고 한다. 오픈소스 카페였나? 그런 게 있다고 하던데. 신기방기.

안드로이드 앱 성능 테스트 자동화

안드로이드 앱 개발을 본격적으로 해 보지는 않았지만, '테스트 자동화'라는 키워드에 이끌려 들은 세션이다. 성능의 측정 기준, 측정 방법을 정하는 것이 중요하다는 이야기를 들으니까 또 '컴퓨터구조론' 강의가 생각난다. 암튼 코드 레벨에서 성능 측정 테스트와 UI 테스트를 어떻게 자동화하셨는지 살펴 본 세션이었다. 아, 그렇구나.

안드로이드/iOS 웹 뷰 개선

이 세션을 보고 음... 삽질 쩐다...가 아니라 '성능 개선을 위해서 이런 수단까지 동원하는구나'라는 생각이 들었다. 일단, native app과 웹 뷰 안의 페이지가 어떻게 서로의 함수를 호출하는지 방법을 보여주셨는데, 여기서부터 '헐...' 소리가 나왔다. 북마클릿을 쓰던데... 허허헣허

해서 안드로이드 프레임워크의 웹뷰가 제공하지 않는 WebSocket를 구현하고, 제공은 하지만 성능이 영 좋지 않은 canvas API의 성능을 올리는 방법을 살펴 보았다. WebSocket이야 그냥 API에 맞춰서 통신 기능을 구현하면 된다 치는데, canvas는 무슨 있는 API를 덮어써버리고 좌표 맞춰서 화면에 그리는 작업을 수행하고... 더 이상의 자세한 설명은 생략한다.

제한된 환경에서 최고의 성능을 끌어내기 위한 모바일 개발자들이 새삼 대단하게 느껴진다.

UI 테스트 자동화 도구 GUITAR

네이버에서 AutoItScript를 사용하여 만든 UI 테스트 자동화 도구 GUITAR를 소개하는 시간이었다. 스크립트를 사용하여 UI 조작을 자동화하는 건 언제 봐도 신기하다. 개념 자체는 별로 신기하지 않지만 말이다.

데모를 보여주셨는데, 처음에 봤을 때 (GUITAR의) UI가 구려서 큰 기대를 안 했는데, 나름 할 건 다 하는(?) 모습을 보고는 쓸 만하겠다는 생각을 했다. 테스트 보고서도 자동으로 뽑아주고, CI와 연동하여 말 그대로 테스트 자동화를 실현할 수 있더라.

VNC 서버 연결을 사용하여 모바일 기기의 UI도 테스트할 수 있다고 한다. 물론 iOS에서는 탈옥이 필요하다고.

스크립트를 한글로 작성한다! 물론 아희 언어만큼 기괴한 언어는 아니다. 세션에서는 영문으로도 스크립트를 작성할 수 있는지가 언급되지 않았는데, 만약 불가능하다면 한국어를 사용하지 않는 사람들이 사용하기에 많이 불편하겠다는 생각이 든다.

관심이 있다면 확인해 보시길. 찾아 보니까 만들어진 지는 좀 됐다. 2011년.

Ubuntu Phone OS

Canonical의 Alex Chiang씨께서 직접 진행하신 세션. Ubuntu Phone OS를 기획하게 된 계기와 주요 컨셉, 그리고 간단한 개발 예시를 살펴 보았다.

'Scope'라는 인터페이스가 있는데, 여러 스토어에 있는 콘텐트를 한 인터페이스에서 통합하여 보여준다고 한다. 안드로이드에서 이용할 수 있는 다양한 스토어(혹은 마켓)들을 iOS의 App Store나 iTunes Store처럼 사용할 수 있는 것.

Ubuntu가 Unity라는 UI를 채택하면서 이뻐졌는데, Ubuntu Phone OS도 마찬가지로 Unity를 채택하여 꽤 이쁘다. UI 파편화를 위한 해결책으로 반응형 디자인을 제시하였다. Twitter Bootstrap처럼 그리드 기반 UI를 사용할 수 있다고 한다. 아, 그리고 UI 요소들의 길이 단위는 픽셀 같은 절대 단위가 아닌 'gu' (grid units)를 사용한다.

UI 구현은 Qt를 사용하기 때문에, QML을 사용할 수 있다. Inline JavaScript도 지원한다고 한다. HTML과 섞어서 사용할 수도 있다고 한다. 개발하는 입장에서 편할 수도, 불편할 수도 있겠다.

Canonical에서 오신 분과 함께 Ubuntu Phone OS의 구체적인 것들에 대해 알아 보았다는 점에 의의를 둔다.

BOF: D2Fest 수상작

사실 BOF 시간(Birds of a Feather: 관심사가 같은 사람들끼리 모이는 네트워킹 시간)에는 Ubuntu Phone OS 개발을 함께 해 보는 자리에 가고 싶었는데, 어쩌다 보니 못 갔다.

그래서, D2Fest 수상작을 살펴 보았다. 그림 파일의 픽셀에 원본 파일의 데이터를 저장하여, iOS에서 파일 교환을 쉽게 할 수 있는 라이브러리를 보았다. 아이디어는 굉장히 참신하고 사용하기도 간편하다고 생각을 하는데, 카카오톡이나 LINE에서 이미지 크기를 압축하는 과정 때문에 한 번에 전송할 수 있는 데이터의 크기가 한정되어 있다는 점이 많이 아쉬웠다. 이런 한계점에도 불구하고, 픽셀의 Y 값이 손실되지 않는다는 점을 이용하여 이미지가 파일의 이름이나 생성 날짜 따위의 메타데이터를 보여주는 것은 정말 놀라웠다. 오오...

맺는 말

Cover Flow는 쥬크박스의 내부를 디지털화시킨 UI로,1 미국의 예술가 Andrew Coulter Enright가 설계했다. 시각적으로 표현되는 항목들을 쥬크박스 안에 들어 있는 레코드들처럼 보여주는 UI이고, 처음에 독립 Mac 개발자 Jonathan del Strother가 이를 사용하여 iTunes의 음악 보관함에 있는 앨범들의 커버 아트들을 탐색하는 단독 애플리케이션을 구현했다. 2006년에, Apple이 Cover Flow를 사들이고, iTunes 7.0에 통합되었다.2

이게 OS X의 Finder에도 들어가고, Safari에도 들어가더니, 언젠가부터 Apple이 아닌 곳에서 만든 서비스에서도 비슷한 UI를 사용하기 시작했다. 예를 들자면 네이버 오픈캐스트와 최근에 출시된 카카오그룹 앱 정도가 있다.

Cover Flow 형태의 UI가 적합한 경우는 사용자에게 전체 항목을 한눈에 보여주되, 사용자를 현재 선택된 항목에 집중시켜야 하는 경우이다. 전체 항목을 한눈에 보여주는 것이 더 중요하다면, 목록 형태나 격자 형태의 배치가 더 적합하다. Cover Flow는 이러한 배치와 단일 항목을 표시하는 것의 타협점이라고 할 수 있다.

Cover Flow 형태의 UI를 사용하려면, 각 항목이 변형되거나 일부분이 가려져도 항목을 인식하는 데에 무리가 없어야 한다. 기본적으로, 이 형태의 UI에는 3D 애니메이션이 적용되는데, 여기에서 항목이 작아지거나, 사다리꼴 모양으로 변형되거나, 일부분이 가려지기 때문이다.

이런 특징 때문에, Cover Flow 형태의 UI는 처음 봤을 때 시각적으로 굉장히 멋진 UI로 보이지만, 사용하다 보면 전체 항목을 한눈에 파악하는 것도, 단일 항목을 확인하는 것도 불편하다. 따라서, 전체 항목을 빠르게 파악해야 하는 경우에는 이런 형태의 UI를 사용하지 않는 것이 좋다.

iTunes 음악 보관함의 Cover Flow는 위에서 언급한 경우에 해당하고, 조건을 만족할뿐더러, 모양과 쓰임새, 그리고 담고 있는 항목들의 내용이 실재하는 물건의 것들과 일치하기 때문에, 충분히 수용할 만한 UI라고 생각한다. 하지만, 이런 형태의 UI가 갖고 있는 불편함은 여전히 존재한다. 결국 iTunes와 iOS 음악 앱 모두에서 사라졌다. 더 이상 쉴드가 안 쳐진다.

네이버 오픈캐스트의 경우에는, 항목이 작아지거나 가려지면 그 내용을 파악하기 아려워지기 때문에, 이런 형태의 UI가 적합하지 않다. 카카오그룹 앱의 경우에는 사용자가 각 항목에 집중할 필요도 없고, 전체 항목을 빠르게 파악할 필요가 있기 때문에 이런 형태의 UI가 적합하지 않다. 이건 네이버 오픈캐스트의 경우에서도 마찬가지이다.

OS X용 애플리케이션이었던 Cover Flow를 Apple이 사들인 뒤, iTunes와 iOS(당시에는 iPhone OS)에 적용하였고, Cover Flow UI는 iPhone이 제공하는 UI/UX의 상징들 중 하나가 되었다. 상징적인 UI를 무작정 따라서 쓰다가 오히려 UX를 망친 제품들이 몇 있어서 아쉬울 따름이다.

Cover Flow는 처음부터 고안된 것이 아니라 쥬크박스 내부의 모습을 흉내낸 것이라고 달리나음님께서 지적해주셨습니다. 고맙습니다. ↩︎

여느 운영체제가 그러하듯 iOS에서도 시스템의 locale 값이 설정되어 있다. Locale에 저장된 언어 혹은 국가 값에 따라 동작을 달리 할 필요가 있다면, 이 값에 접근할 필요가 있을 것이다. NSLocale 클래스에서는 currentLocale 메서드를 제공하는데, 이 메서드를 호출하면 현재 사용자의 논리적 locale을 반환하는데, 사용자가 '시스템 환경설정 (System Preferences)'에서 설정한 언어(Language), 지역 포맷(Region Format) 값 등이 여기에 반영된다.

그런데, 이 객체에서 '언어'나 '국가' 따위의 값에 접근하기 위해서는 반환된 locale 객체에 objectForKey 메서드를 호출하여야 한다. 여기서, 매개변수로 무엇에 대한 값을 반환할지 정해주어야 한다.

Locale의 국가 코드에 접근하려면 다음과 같이 코드를 작성하면 된다.

NSString *localeStr = [[NSLocale currentLocale] objectForKey:NSLocaleCountryCode];

이렇게 하면, 사용자가 '시스템 환경설정'에서 지정한 '지역 포맷' 값에 따른 국가 코드 값을 확인할 수 있다.

갑자기 이걸 찾아본 이유는, 최근에 카카오톡에 생긴 '위치 정보 보내기 기능'이다. 단체 대화방에 올라온 위치 정보 메시지를 눌러 보니까, iOS의 MapKit을 사용한 지도가 나타났다. 널리 알려진 사실이지만, iOS 6에서 제공하는 한국 지도는 정말 답이 없기 때문에, 내가 본 지도도 정말 끔찍했다. 그런데, iPhone을 사용하는 친구에게는 네이버 지도에서 제공하는 지도가 나온다는 것이었다. 헐?

본능적으로 locale 때문일 것이라고 느꼈다. 나는 '언어'를 영어로, '지역 포맷'을 미국으로 설정해놓고 사용하고, 그 친구는 '언어'를 한국어로, '지역 포맷'을 대한민국으로 설정해놓고 사용하기 때문이다. (내가 굳이 지역 포맷을 미국으로 설정한 건 대한민국으로 설정해 놓으면 날짜나 시간을 나타내는 문자열에 한국어가 섞여 나오기 때문이다.)

그래서 '지역 포맷' 설정만 바꾸면 나도 네이버 지도의 지도를 사용할 수 있지 않을까, 생각했다. 아니었다. '지역 포맷' 설정이 아니라 '언어' 설정이 문제였다. 바꿔 말하면, '지역 포맷'을 다른 국가의 것으로 설정해도 '언어'를 한국어로만 해놓으면 네이버 지도에서 제공하는 지도를 사용할 수 있는 것이다.

요즘 진행하는 프로젝트에서 웹 프론트엔드 개발을 열심히 하고 있다. 개발을 하면서 AngularJS라는 프레임워크를 사용하고 있다. 양방향 데이터 바인딩, 템플릿, URL 라우팅 등 웹 앱 개발을 비교적 쉽게 진행할 수 있도록 도와주는 괜찮은 프레임워크이다.

그러나, 이토록 다양한 기능을 지원하는 AngularJS도 모든 기능이 완벽한 것만은 아니다. 위에서 URL 라우팅을 지원한다고 했는데, 상당히 기본적인 수준을 지원한다. Nested URL 라우팅이나, state 관리 같은 것은 지원하지 않는다. 이런 단점을 보완하기 위해 AngularUI 팀에서 제작하고 있는 라이브러리가 ui-router이다. Nested URL 라우팅, state 관리, named views, sub-views 등을 지원한다.

꽤 훌륭한 해결책이긴 하지만, 여기에도 몇 가지 아쉬운 점이 있다. 그 중 하나가 제목에서 언급한 것과 같이, 파라미터에 따라 템플릿 URL을 다르게 하는 것을 (공식적으로) 지원하지 않는다는 것이다.

이런 기능을 필요로 하게 된 계기는 이렇다. URL 끝에 주어지는 파라미터에 따라 컨텐트가 보여지는 방식을 다르게 하고 싶은데, 여기서 컨텐트가 보여지는 방식을 정의하는 뷰 템플릿을 동적으로 로드하고 싶었다.

물론, 나와 같은 고민을 한 사람이 꽤 있고, ui-router의 GitHub 저장소의 issue에 질문이 올라오기도 했다. 커멘트를 보면, templateUrl 속성에 그냥 함수를 넘기면 된다고는 하는데, 제대로 작동할 것이라는 보장이 없어서... 가 아니라 잘 된다. 설마 해서 ui-router 소스 파일을 분석해 보았더니 잘 된다. 헤헿

내가 발견한(?) 방법은, templateProvider 속성을 이용하는 방법이다. $stateParams 서비스와 $templateFactory 서비스를 inject한 함수를 값으로 설정하는 방법이다. $templateFactory 서비스는 ui-router 내부에서 템플릿 소스 공급을 위해 사용하는 서비스이다. 여기에는 fromUrl이라는 메서드가 있는데, 첫 번째 파라미터로 템플릿의 URL을 공급하면 해당 URL의 데이터를 읽어 와서 템플릿 소스를 반환해준다.

그렇게 의미 없는 삽질...이 되어 버린 해결책의 코드는 아래와 같다. 뭐, 그래도 다른 서비스를 inject하면서, 특정 URL의 데이터를 템플릿으로 쓰고 싶다면 나름 유용하게 쓸 수 있지 않을까 싶다.

...에 대한 대답은 공식 문서에 나와 있다.

As initialized upon program startup, the first item of this list, path[0], is the directory containing the script that was used to invoke the Python interpreter. If the script directory is not available (e.g. if the interpreter is invoked interactively or if the script is read from standard input), path[0] is the empty string, which directs Python to search modules in the current directory first. Notice that the script directory is inserted before the entries inserted as a result of PYTHONPATH.

근데 뜬금없이 이걸 적어두는 이유는 이렇다. Python 스크립트에서 import 문 혹은 __import__ 함수로 패키지에 있는 모듈을 읽어올 때에, 패키지 디렉토리에 있는 __init__.py 파일을 해석하는데, 여기에서도 sys.path의 값은 Python 스크립트를 해석하기 시작할 때와 같다. 따라서, 이 파일에서 특정 패키지의 다른 모듈을 읽어오고자 할 때에는 sys.path를 조작하거나 Python 인터프리터가 실행된 디렉토리를 기준으로 패키지를 지정해줘야 한다.

WebRTC도 꽤 인상깊었다. 개념과 기술 자체는 참신하지만, 아직 개선할 부분이 많다고 생각. 너무 불안하다.

드디어 TDD를 직접 해 보기로 결심. 현재 작업중인 페이지에 삽입하기 위해 만들고 있는 아주 아주 작은 규모의 라이브러리를 테스트하는 데에 QUnit을 사용하기로 함. '테스트 코드를 먼저 짜라'는 규칙, 따라야 하는데 멋대로 안 된다. 좀 더 연습해야겠다.

ECMAScript strict mode에서, global 객체를 얻는 코드:

Function('return this')()