ikspres

Today의 아이폰 버전

"한 눈에 보는 오늘의 할 일 리스트"라는 모토를 가지고 만들고 있는 Today 서비스를 아이폰이나 아이팟터치에서 쓸 수 있도록 아이폰 버전을 만들었다. 접속 주소는 동일하며, 브라우저의 종류를 판별하여 자동으로 아이폰 버전을 보여준다. 새 할일 추가 기능은 곧 추가할 예정.

2009년의 첫 날을 작지만 뭔가 의미있는 일로 시작하게 되어 기분이 좋다. 여러가지 이유로 춥고 힘든 요즘이지만, 춥다고 웅크릴 수록 더 추운 법이다. 어깨를 펴고 긍정적인 마음을 유지하려고 노력한다면 기왕 살아야 할 매일 매일이 조금은 더 행복하지 않을까한다. 화이팅!

사인필드의 달력

최근에 MS의 TV광고에 나왔다가 광고가 실패해서 여러 사람 입에 오르내렸던 제리 사인필드는 '사인필드'라는 드라마로 유명한 스탠드업 코미디언이다.

그는 유명한 코미디언이 될 수 있었던 비법의 하나로 달력을 활용한 자기 계발 방법을 소개했다. 좋은 코미디언이 되려면 재밌는 유머를 많이 써봐야 하는 데, 이 연습을 매일 거르지 않기 위해서 그는 커다란 달력을 잘보이게 걸어놓고 연습을 한 날은 빨간 매직으로 크게 X표를 했다. 그리고 이 X표가 매일 끊기지 않도록 노력했다고 한다.

사실 영어나 운동처럼 자신이 중요하게 여기는 일을 지속적으로 하기 위해서 이와 유사한 방법을 쓰는 사람을 가끔 보기도 한다.

그런데, techno weenie로도 알려진 Rails계의 실력자 Rick Olson이 최근에 GitHub의 오픈소스 프로젝트에 commit 을 했는 지 여부를 표시하는 사인필드의 달력을 만들어서 공개했다.

Rick의 달력이 상당히 예뻐보여서, 얼마 전에 소개했던 Today 서비스에도 이 달력을 적용해보았다. 자신이 완료한 일이 하나 이상 있으면 X가 표시되는 달력이다. 나는 과연 요즘 얼마나 성취하고 있을까?
Don't Break the Chain!

한 눈에 보는 오늘의 할 일 리스트

내 자신이 쓸 목적으로 할 일 관리 서비스를 만들어 사용해 온 지가 어느 새 2년을 훌쩍 넘었다. 처음에는 단순한 텍스트버전이었는데, 레일스를 배운 후 웹 서비스로 만들었고 일 년 전쯤에 Rdoit이라는 이름으로 슬쩍 공개했던 적도 있다.

그 서비스를 이번에 다시 TODAY라는 이름으로 소개해보려 한다. 할 일 관리 또는 todo list 서비스라는 점에서는 크게 달라진 것이 없지만 다음의 몇 가지는 바뀌었다.

SMS 알림 기능. 구글 캘린더 연동 기능을 제공하여, 정해진 시간에 해야 하는 할 일을 잊지 않도록 SMS로 미리 알려준다.
Tagging 대신 Category를 사용한다. todo list에서 tagging은 오버다.
사용이 훨씬 쉬워졌다.

이 전 버전은 나에게만 익숙한 방식( ':내일' 과 같이 ':'을 사용한 특수 태그 활용)에 많이 의존했기 때문에 일반 사용자에게는 꽤나 어려웠다. 이번에는 복잡한 특수 태그는 없애고, 두 개의 입력 필드에 '주간 보고서 작성하기' '금요일 16:00' 처럼 입력하면 되도록 했다. 그리고 곳곳에 팝업메뉴들을 사용해서 좀 더 직관적으로 사용할 수 있도록 했다.

그리고, 다음은 여전히 바뀌지 않은 점들이다.

변변챦은 디자인. 역시나 아직 많이 부족하다.
베타! 굳이 베타 딱지를 붙이지 않아도 베타가 확실하다.(그래도 사용자 데이터는 매일 백업받는다.)
달력이 없다.

이 서비스는 '일정 관리'가 아니라 '할 일 관리'를 위한 서비스다. 사실 비즈니스맨 처럼 대외약속이 많거나 매시간 단위로 정해진 시간표를 짜고 그 대로 움직여야하는 사람들은 구글 캘린더 같은 일정관리 서비스가 더 필요하다. 하지만 나 같은 사람에게는 시간단위의 일정표는 별 의미가 없다. 대부분의 일들은 언제 시작해야 한다거나 언제까지 끝내야는 한다는 조건이 명확하지 않으며, 급하게 몇 시간 내로 처리해야 할 일들도 수시로 생겨나므로 일들의 처리 순서가 수시로 바뀐다. 이런 상황에서 전체 일들의 시작, 끝시간을 모두 일관성있게 계속 업데이트한다는 것은 힘들 뿐 아니라 무의미하다..

TODAY는 이렇게 수시로 생기는 할 일들을 큐에 넣고, 그 때 그 때 상황에 맞게 적당한 일을 꺼내서 처리하는 식으로 일하는 사람에게 적합한 서비스다.

TODAY에서 제안하는 일 처리 방식은 다음과 같다.

회의나 약속처럼 시작 시간이 정해진 일은 시작 시간을 기준으로 미리 알림을 설정한다.
시작 시간이 정해지지 않은 일들은 그 일을 끝내야하는 시간을 지정한다.
일을 처리할 때는, 'Today' 리스트의 할 일들을 우선 처리한다. 'Today' 리스트의 일들을 모두 끝내고도 시간이 더 있다면 'Later' 리스트에서 적당한 항목들을 'Today' 항목으로 변경한 후, 그 일을 수행한다.
일들을 처리하는 중에 생각이 바뀌거나 급한 다른 일이 생기면 하던 일의 마감 시간을 적절히 변경한다.

TODAY는 위와 같은 일 처리 과정을 최대한 편리하게 지원한다.

서비스를 직접 써보면 알겠지만 TODAY는 기능이 많지도 않고, 별 거창한 기능을 제공하지도 않는다. 얼마 전 플라타너스트리 를 오픈하신 석준님 블로그에도 나왔던 말처럼 '딱 하나의 활동을 지원하는' 서비스다. 부족한 기능들이 아직도 많지만, 틈 나는대로 꾸준히 다듬어서 딱 하나의 활동을 좀 더 '잘' 지원하는 서비스로 만들고 싶다.

UPDATE. TODAY가 자랑(?)하는 편리한 날짜/시간 입력 형식들은 다음과 같다.

생활계획표

그림출처

오늘 뭐하지?

어제 뭐 했더라? 오늘은 뭐하지?

Passenger 팀에서 보내 온 EnumFu 패치 적용

몇 일전에 Passenger(mod_rails) 팀의 Hongli Lai 라는 개발자가 EnumFu의 패치를 메일로 보내주었다. 패치도 물론 고마웠지만 자신들이 EnumFu를 여러 곳에서 사용하고 있다는 내용이 있어 더 반가웠다.

Thank you for the excellent enum_fu plugin. We use it in many of our applications.

....

Passenger 의 명성에 걸맞게 패치의 내용도 알차다.

먼저, car.status = :broken 대신에 car.status = 3 또는 car.status = '3' 등이 가능해졌다.

이 기능은 전에 다른 사람도 요청한 적이 있었지만, 심볼을 입력 값으로 사용하려는 원래 취지에 맞지 않을까 하여 미루고 있었던 거다. 하지만 나 역시 정수 값을 직접 쓰고 싶은 경우를 가끔 경험했기 때문에 그대로 반영했다.

두번째, :broken 이라는 심볼이 DB에 저장될 때의 실제 값을 알고 싶으면 Car.status(:broken) 를 사용한다. 이렇게 심볼의 값을 조회하는 메소드를 정의하는 부분에 있던 중대한 오류를 수정했다.

수정 전 후의 코드는 아래와 같다.

기존 코드

self.class.send(:define_method, name, p1)

새로운 코드

metaclass = class << self
self
end
metaclass.send(:define_method, name, p1)

이해하기 쉽게 Car.status 예를 가지고 계속 설명하면,

기존 코드에서는 싱글턴 메소드 'status'를 Car.class 에 정의했다. 그런데 Car.class 는 'Class' 이므로, 이렇게 하면 Car뿐만 아닌 모든 클래스에 status 메소드가 생겨 버린다. (Aw Snap!)

새로운 코드에서는, 이를 바로잡기 위해서 Car의 메타클래스를 구한 뒤, 이 메타클래스에 status를 정의한다. 역시 메타프로그래밍은 헷갈린다.^^

끝으로, EnumFu에 대한 테스트 코드들이 추가되었다.

이번 패치 덕분에 EnumFu가 많이 진화했다. 아주 간단한 플러그인이지만 내가 만든 소스를 남들이 유용하게 사용해 준다는 것은 참 고마운일이다.

PS.

이 참에 EnumFu의 소스 코드 관리를 GitHub에서 하기로 했다. 위치는 http://github.com/ikspres/enum_fu

구글 크롬 브라우저의 Aw Snap 문제 해결 방법

이틀 전에 구글의 크롬 브라우저 발표가 있자마자, 큰 기대를 가지고 상세 소개 자료를 요약 번역했었다. 그런데 정작 어제 공개된 크롬 브라우저를 설치해보니 전혀

동작하지 않고 'Aw Snap' 이라는 이상한 에러 메시지만 계속 나온다. 어쩌다 한 번이 아니라 매번 나온다.

'Aw snap' 은 'Oh damn' 이란 뜻이라니, 우리 말로는 '젠장' 정도가 되겠다.

정말 '젠장'이 아닐 수 없다. 처음에는 구글링을 해도 답이 없더니, 하루가 지난 이제는 몇 군데에 해결책들이 나오고 있다. 그 중에서 내 경우를 해결해 준 방법은 실행 옵션에 "--no-sandbox"를 추가하는 것이다.

구체적인 적용 방법은 다음의 그림과 같다. 즉, 크롬의 바로가기 아이콘의 등록정보에서 '대상'의 명령줄 가장 뒤에 --no-sandbox 를 추가하면 된다.

Happy Chroming!!!

구글의 브라우저 크롬을 소개합니다.(2/2)

앞의 글 "구글의 브라우저 크롬을 소개합니다." 에 이어지는 글입니다.

3장 검색과 User Experience

탭의 위치

구글 크롬 역시 사용자 인터페이스는 탭 중심이며, 탭이 매우 중요하다고 생각했기 때문에 탭의 위치를, 기존 브라우저와 달리, 브라우저의 최상단인 주소입력창 위로 올렸다.

이에 따라 각 탭은 별도의 주소 입력창과 제어 버튼들을 가지게 된다.

옴니박스

크롬의 주소 입력창은 옴니박스(Omni box)라고 부르는데, 이름이 암시하듯이 추천, 검색, 최근 많이 방문한 페이지, 추천 페이지 등 많은 기능을 가지고 있다.

예를 들어, 옴니박스에서는 방문했던 모든 페이지에 대한 풀 텍스트 검색이 가능하다. 이 기능을 이용하면 어제 방문했던 페이지의 주소를 기억해서 다시 방문하지 않더라도, 검색을 통해서 찾을 수 있다.

옴니박스는 자동 완성 기능도 당연히 제공하며, 아주 짧은 몇 글자만 입력하더라도 동작한다. 만약 c만 입력했다고 하면 c로 시작하는 사이트중 최근에 사용자가 많이 방문했던 사이트로 예를 들면 cnn.com으로 이동한다.

아마존이나 위키페디아 등 사이트 내에 있는 검색 박스를 브라우저에서 바로 이용하는 기능도 있는데 예를 들어 "Search Amazon: Zamfir" 와 같은 검색이 가능하다.

탭 초기 화면

브라우저에 새로운 탭을 열면서 사용자가 기대하는 것은 무엇일까? 어떤 특정 사이트로 이동하거나 또는 검색을 원할 것이다. 그래서 크롬은 사용자의 최근 방문한 9개의 사이트의 썸네일과 최근에 검색한 검색 사이트들을 보여준다. ( 기존의 브라우저들은 미리 정해진 사이트나 빈 페이지를 보여준다.)

프라이버시 모드

구글 크롬에는 프라이버시 모드를 제공한다. 프라이버시 모드에서 일어난 모든 일은 어떠한 기록에도 남지 않으며, 그 탭을 닫으면 해당 쿠키나 세션들도 즉시 지워진다.

팝업창 제어

크롬에서는 팝업창으로 장난 치기가 어렵다. 크롬에서는 모든 팝업창이 그 팝업을 띄운 탭의 범위 안에 포함되어야 하며, 처음에는 제목만 작게 표시된다. 만약 그것이 사용자가 원하는 것일 경우에는 사용자가 드래그 하여 원래의 크기로 볼 수 있다.

4장 보안, Sandboxing, 안전한 브라우징

Sandboxing

구글은 Sandboxing 이라는 것을 통해서 악성소프트웨어를 방지한다. Sandboxing은 악성 소프트웨어가 사용자의 PC에 설치되거나 하나의 탭이 다른 탭에 영향을 끼치지 못하게 막는다. 또 사용자 디스크에 파일을 작성하거나 문서 폴더등의 내용을 읽지 못하도록 한다.

따라서 각 탭의 프로세스는 각각 감옥에 갇힌 것과 같아서 어떠한 나쁜 짓도 할 수 없다.

어떤 탭에서 나쁜 일이 일어난다면, 그 탭을 닫기만 하면 아무 문제가 없다.

플러그인과 보안

그런데 이러한 보안 정책에 있어 유일한 예외는 바로 플러그이다. 플러그인은 브라우저보다 동등한 또는 더 강한 권한을 가지고 수행될 수 도 있다.(예를 들어 플래쉬를 이용하면 디스크의 파일을 읽거나 쓸 수 있다.)

플러그인의 코드는 크롬에서 만든 것이 아니므로 더 안전한 실행을 위해, 플러그인을 수행하기 위한 프로세스는 해당 탭의 고유 프로세스와는 별도로 존재한다.

피싱 방지

피싱은 Sandboxing으로 해결할 수 없다. 이에 해결하기 위해서 크롬은 계속해서 해로운 사이트의 주소들을 구글로 부터 업데이트받는다. 그리고 사용자가 해로운 사이트에 접속하려고 하면 경고를 보낸다.

구글은 악성 사이트 주소 제공 서비스를 무료로 제공할 뿐 아니라 공개 API를 통해서 누구나 사용할 수 있도록 한다.

구글은 또한 의도하지 않게 나쁜 요소를 포함했을 수도 있는 웹사이트를 위해서 그러한 사이트의 운영자에게 경고를 보낸다.

5장 Gears, 표준 그리고 오픈 소스

구글 크롬에는 Gears가 포함되어 있다. Gears를 통해 개발자들은 여러가지로 브라우저의 기능을 확장할 수 있다. 크롬이 사용자를 위한 것이라면 Gears는 개발자를 위한 것이라고 할 수 있다. (Gears에 대해서 더 알고 싶다면 이 곳 참고)

구글 크롬 브라우저는 완전히 오픈 소스로 개발되었으므로 누구라도 원하는 기능을 돈을 지불하거나 허락을 받지 않고 가져다 사용할 수 있다.

구글 크롬이 여러 오픈 소스 프로젝트들의 이용하고 있듯이, 다른 브라우저들도 구글의 크롬 브라우저에 적용된 기술들을 이용하여 더 개선 될수 있기를 기대하며, 이를 통해 전체적으로 웹과 인터넷이 더 발전할 수 있기를 기대한다.

(끝.)

이상으로 구글 크롬 코믹스의 요약을 마칩니다. 이제 몇 시간 후면 크롬을 다운 받아서 사용해볼 수 있겠군요.

구글이 크롬에 대해서 소개한 많은 기능들을 잘 구현하고 앞으로 더 발전시켜서, 구글이 기대하는 대로 크롬이 웹 전체의 발전을 위한 디딤돌이 되어 줄 지, 아니면 웹 개발자가 테스트 해야 할 또 하나의 브라우저에 그치고 말 지는 아직 알 수 없습니다.

그리고 크롬이 MS나 Firefox에 어떤 영향을 어떻게 미치게 될 지도 지금은 알 수 없습니다. 하지만 크롬으로 인해 당분간 강호는 어지러운 시기를 겪을 것이라는 사실은 분명하겠지요. 구글의 더 강력해질 패권이 두렵기는 하지만, 어떻든 모두가 서로 좋은 영향을 받아서 발전하는 기회가 되기를 기대합니다.

구글의 브라우저 크롬을 소개합니다.

어제(9/1) 구글이 전격적으로 자신들의 브라우저 '크롬'을 발표하고 오늘(9/2) 베타버전를 100개 이상의 나라에서 공개하겠다고 했다. 아침에 이 뉴스를 보고 얼마나 놀랐던지...

이번 발표에서 구글은 크롬을 소개하기 위한 만화책을 함께 공개하는 센스를 발휘 했는데 아무리 만화라고 해도 내용이 내용인지라 휙휙 넘기며 보기는 어렵다. 일단 글자가 많다.

그래도 구글이 만든 브라우저이니 한번 찬찬히 읽어보기로 하고, 이왕 시간을 들이는 김에 그 내용을 정리해서 공유하기로 했다.

개발 동기 및 목표

현재 우리가 브라우저에서 보는 것은 단순 웹페이지가 아니라 채팅, 비디오, 게임과 같은 어플리케이션이다. 이러한 웹어플리케이션들은 브라우저가 처음 생길 때는 없던 것들이다.

따라서 브라우저도 이러한 어플리케이션에 맞게 새롭게 만들어진다면 좋지 않을까?

이렇게 시작된 구글 크롬의 개발에 있어서 주요 목표는 다음과 같다.

브라우저는 안정되고, 빠르고 보안성이 높아야 한다.
UI는 깔끔하고 심플하고 효율적적이어야 한다.
오픈소스로 개발되어야 한다.

이제 상세한 기술 사항들을 살펴보자.

1장 안정성, 테스트 멀티 프로세스 구조

멀티 프로세스 구조

크롬 프로젝트 초기에 구글의 Gears팀은 브라우저들이 싱글 쓰레드로 동작하기 때문에 문제가 있다고 말했다. 예를들어, 자바스크립트가 수행되는 동안 브라우저는 다른 일을 전혀 할 수가 없다.

Gears팀은 이에 대한 해결책으로 멀티쓰레드로 동작하는 브라우저를 생각하고 있었다. 하지만, 크롬팀은 멀티 프로세스 방식을 생각했다.

이것은 브라우저의 각 탭마다 별도의 프로세스가 존재하는 방식이다. 따라서 어떤 탭의 자바스크립트가 굉장히 바쁘게 동작하고 있더라도 다른 탭에는 영향이 별로 없게 된다.

나아가서 한 개의 탭이 죽어버리더라도 전체 브라우저가 죽는 일은 없게된다.

메모리 관점에서 기존의 멀티쓰레드 방식은 처음에는 메모리를 덜 사용한다.

하지만 사용자가 오랫동안 많은 탭을 열고 닫고 하면, 하나의 프로세스 내에서 반복된 메모리 할당, 재할당 특히 프레그멘테이션 등이 계속 발생하게되어 결국 브라우저는 점점 더 많은 메모리를 필요로하게된다.

그러나, 크롬의 멀티프로세스 방식에서는 탭을 닫고 열때마다 프로세스가 깔끔하게 새로 시작하게된다. 따라서 초기에 필요로하는 메모리는 좀 더 많지만 오랫동안 사용하더라도 프레그멘테이션 등의 문제가 없다.

그리고 크롬의 Task manager를 사용하면, 특정 사이트를 표시하고 있는 탭의 프로세스가 지나치게 부하가 높거나 특정 탭에서 사용하는 플러그인에 문제가 있는 지를 알 수 있으며 그러한 탭을 닫아버릴 수있다.

테스트

구글 크롬은 구글의 거대한 컴퓨팅 자원을 이용하여 엄청나게 테스트를 하고 있다.
새로운 빌드가 만들어질 때마다, 20-30분 내에 수 만개의 서로 다른 페이지들에 대해서 테스트를 수행한다.

또 매주 '크롬봇'이 수백만개의 페이지를 테스트한다.
(세상에 널린 수십억개의 페이지들 중에서 수백만개의 페이지를 선택하는 것 역시 구글의 축적된 데이터를 이용한다. 즉, 페이지 링크등을 통해 가장 많은 사람들이 방문하는 사이트들을 우선적으로 테스트한다.)

이러한 방식으로 크롬 팀은 문제들을 더 빨리 발견하고 해결하고 있다.

이외에도 크롬 팀은 다양한 자동화 테스팅 기법들을 사용하여 더 튼튼하고 안전한 브라우저를 만들기 위해 노력하고 있다.

2장 속도 (웹킷과 V8)

구글 크롬은 렌더링을 위해서 오픈소스 인 WEBKIT 엔진을 사용한다.

이미 웹킷을 사용하고 있는 구글폰 안드로이드팀에 따르면 웹킷은 메모리를 효율적으로 사용하고 디바이스에 임베드하기에도 좋으며, 전체적으로 간결성을 유지하고 있어 새로운 부라우저 개발에서 베이스 코드로 사용하기에 적합하다고 한다.

자바스크립트를 위해서 크롬은 V8이라는 Virtual Machine을 사용한다. V8팀은 덴마크에 있으며 이들은 Virtual Machine 전문가 집단이다.

아래는 V8팀의 말이다.

버추얼머신은 안정정과 플랫폼 독립성을 제공한다. 과거에 자바스크립트를 위한 버추얼 머신들은 성능과 인터액티비티가 그리 중요하지 않던 때에 웹페이지를 위한 기본적이고 작은 프로그램 수행을 타겟으로 디자인되었다.

하지만, 현재 우리는 GMAIL과 같은 큰 규모의 많은 어플리케이션들을 사용하고 있으므로 기존의 단순한 방식은 더 이상 적당하지 않다.

그래서 우리는 정말 빠른 엔진을 만들기 위해 완전히 바닥부터 새로 만들기로 했다.

V8에서 빠른 속도를 위해 도입한 개념 중 하나는 'Hidden class transition'이다.

자바스크립트는 클래스라는 개념이 없고 모두가 오브젝트이다. 새로운 오브젝트에 동적으로 속성들을 추가해가는 방식으로 동작한다.

하지만 V8에서는 실행이 계속됨에 따라 동일한 속성들을 가진 오브젝트들이 숨겨진 공통의 클래스를 공유하게 하고, 이를 기반으로 최적화를 할 수 있다.

V8이 자랑하는 또 한 가지 특징은 'Dynamic Code Generation'(동적 코드 생성)이다.

일반적인 자바스크립트 엔진은 수행을 위해서 소스크드를 보고(파싱) 자신이 이해하고 수행할 수 있는 내부적인 표현으로 변환한다.
그리고 실제 실행은 이 내부표현을 이용해서 하게된다. 하지만 이 방식에서는
동일한 부분이 반복 수행될 때마 이 내부표현이 반복해서 이해되고(interpretation) 수행되어야 한다는 단점이 있다.

그러나 V8에서는 자바스크립트 코드에서 바로 머신코드를 생성하여 실행한다. 따라서 수행을 위해서 내부코드를 생성하고 반복적으로 이해하는 과정이 없게된다.

끝으로 기존 자바스크립트 엔진의 또 다른 문제는 'Garbage Collection'이다.

자바스크립트를 포함한 최근의 객체 지향 언어들은 메모리 관리를 자동으로 해준다.

기존의 Garbage collection 방식에서는 이를 위해서 프로그램의 실행스택에서 메모리 포인터 처럼 보이는 것들을 찾아내는 과정이 필요하다. 그런데 어떤 값들은 메모리 포인터인지 혹은 일반 정수값인지 정확히 판단할 수 없는 경우가 많다.

V8에서는 'Precise garabage collection'이라는 방식을 사용한다. 이 방식에서는 어디에 포인터가 있는지를 정확히 알고 있으며, 이를 통해서 여러가지 성능 개선이 가능하다.

이러한 성능 개선들을 통해서, V8엔진을 사용하면 웹 화면상에서 더 부드러운 드래그엔드랍과 같은 UI구현이 가능해진다.

V8은 구글 크롭을 위한 특정한 API들을 포함하고 있지만, 코어 부분은 특정 브라우저에 한정되어 있지 않다. 따라서 어떤 브라우저도 원한다면 V8을 사용할 수 있다.

(생각보다 길어지네요.

나머지는 "구글의 브라우저 크롬을 소개합니다.(2/2)"에 이어집니다.)

Net::HTTP 와 http_proxy

회사에서

루비 개발을 하는 많은 사람들은 처음에 proxy로 인해 혼란을 겪는다. 요즘 대부분의 기업 네트워크는 보안 등을 위해서 프록시를 사용하며, 따라서 오픈 API 요청과 같이 네트워크 기능을 사용하는 루비 코드에서는 반드시 프록시 사용을 위한 부분이 추가되어야 한다. 그런데 이를 미처 생각하지 못한 사람들은 코드가 전혀 동작하지 않는다고 생각하게 되는 것이다.

예를 들어, 다음의 코드는 proxy 환경에서는 동작하지 않는다.

(소스 1)

       require 'net/http'

       h = Net::HTTP.new('www.google.co.kr')
h.get('index.html')

제대로 동작하게 하려면 다음과 같이 수정되어야 한다.

(소스 2)

require 'net/http'
h = Net::HTTP.new('www.google.co.kr', '192.168.10.23', '8080')
h.get('index.html')

위에서 HTTP.new 의 2,3번째 파라미터는 물론 http proxy의 주소와 포트번호이다.

그런데

위의 코드는 바람직하지 않다. 프록시의 주소와 포트 번호가 하드코딩되어 있으므로 프록시 주소가 다른 곳 또는 프록시를 사용하지 않는 곳에서는 코드를 수정해야한다.

이 문제를 해결하기 위해서는 일반적으로 많이 사용되는 http_proxy라는 환경 변수를 이용하여 아래와 같이 고칠 수 있다.

(혹시 생소한 사람을 위해 예를들면, http_proxy는 'http:192.168.10.23:8080' 과 같이 정의되어 있다.)

(소스 3)

require 'net/http'
host, p_port = if ENV['http_proxy']
proxy = URI.parse(ENV['http_proxy')
[host, proxy.port]
else
[nil,nil]
end
h = Net::HTTP.new('www.google.co.kr', p_host, p_port)
h.get('index.html')

하지만 내가 작성한 코드가 아니라 다른 사람들이 작성한 라이브러리를 사용하는데, 그 라이브러리가 proxy를 전현 고려하지 않고 작성되어 있다면 어떻게 해야 할까?

실제로 이런 경우는 꽤 많다. 예를 들어 최근에 내가 사용하려고 했던 googlecalendar 라는 gem도 그런 경우였다. 물론 ruby는 열린 언어이므로 해당 코드를 직접 고칠 수 있다. 하지만 googlecalendar gem만 해도 수정이 필요한 부분이 꽤 많아서, 모두를 찾아서 고치는 일이 쉽지 않다.

이 문제의 근본 원인(?)을 따져보면 루비의 기본 라이브러리인 Net::HTTP 가 환경변수 http_proxy의 값을 자동으로 적용하지 않기 때문이다. 이렇게 구현한 데에도 나름의 이유가 있겠지만 개인적으로는 아쉽게 생각한다.

반면 REST기반의 API 구현에 자주 사용되는 rest-open-uri 라는 gem은 http_proxy를 자동으로 적용해주기 때문에 매우 편리하다. (rme2day라는 미투데이 API gem을 개발할 때도 이것을 사용했다.)

결국
나는 악의 뿌리(^^) Net::HTTP를 수정해서 이 문제를 해결해보기로 했다.

net/http.rb 소스코드를 들여다본 결과, 다행히 HTTP.new 함수만 건드려주면 된다는 것을 알게되었다.

net/http.rb를 직접 수정하는 것은 여러가지로 상당히 위험스럽고, 바람직하지도 않은 일이므로, 기존 코드는 그대로 두고 proxy 처리만을 위한 부분을 따로 떼내어, 다음과 같이 use_http_proxy.rb 를 작성했다.

(소스 4)

## use_http_proxy.rb
module Net
class HTTP
#기존의 new 를 alias 해둔다.
        class << HTTP
            alias org_new new
        end
# proxy_addr가 명시적으로 지정되지 않은 경우에는
# http_proxy환경변수에 정의된 proxy를 사용한다.
# proxy정보 적용 후에는 원래의 new인 org_new를 호출한다.
        def HTTP.new(address, port = nil, p_addr = nil, p_port = nil, p_user = nil, p_pass = nil)
            p_addr, p_port, p_user, p_pass = env_proxy unless p_addr
            org_new(address, port, p_addr, p_port, p_user, p_pass)
        end
# http_proxy 읽어오기
        def HTTP.env_proxy
            uri = URI.parse(ENV['http_proxy'] || ENV['HTTP_PROXY'])

            p_user = p_pass = nil
            p_user, p_pass = uri.userinfo.split(/:/) if uri.userinfo

            [uri.host, uri.port, p_user, p_pass]
        end
    end
end

이제, 맨 앞에 나왔던 (소스 1)과 같이 proxy가 고려되지 않은 코드에서 proxy를 사용하기 위해서는 아래처럼 require 'use_http_proxy' 한 줄만 추가하면 된다.

require 'net/http'
   require 'use_http_proxy'

       h = Net::HTTP.new('www.google.co.kr')
h.get('index.html')