OddPoet's βetalog

한국 웹 포털의 지도전쟁, 상황종료?!

(OddPoet) — Tue, 20 Jan 2009 02:26:19 +0900

2008년 11월 다음이 스카이뷰와 로드뷰 런칭에 대한 홍보를 시작으로 본격적으로 한국에서도 웹포털 간의 지도전쟁의 서막이 열렸습니다. 그 후 많은 사람들의 기대에도 불구하고 다음의 스카이뷰&로드뷰 런칭이 늦어지던 상황에서 네이버가 2009년 1월 6일 기습적으로 먼저 위성항공지도 서비스를 오픈하였지요. 그리고 드디어 1월 17일 다음에서 스카이뷰와 로드뷰를 런칭했습니다.

그 전 포스트에서도 예견했다시피, 그리고 많은 사람들이 예상했던 것 처럼 이번에 오픈한 다음의 스카이뷰가 보여주는 위성항공 사진의 품질은 네이버의 그것을 뛰어넘는 수준입니다.(50cm급이 아니라 25cm급인듯...) 게다가 다음의 로드뷰는 국내 포털에서는 대적할 만한 서비스가 없을 정도로 훌륭합니다. 다음의 지도서비스는 이제 한국 내 로컬 서비스에 있어서는 구글맵 수준에 도달했다고 할 만합니다. (전 세계 지도서비스를 하지 않으니, 구글 어스 같은 서비스는 불가능하겠지만요.)

서비스 런칭에 있어서 엔지니어들이 넘어야 할 기술적인 이슈들도 많겠지만, 위성항공 사진이나 구글 스트리트 뷰(다음의 로드뷰와 동일한) 같은 서비스에서 더 중요한 건, 사실은 컨텐츠 부분입니다. 실제 비용은 알 수 없지만 스카이뷰와 로드뷰에 몇 백억의 비용을 들였다는 얘기가 있는 만큼, 관련 컨텐츠를 구축하는데 상당한 비용이 드는 건 누구도 부인할 수 없을 겁니다.

지도서비스라는게 당장 돈이 될만한 수익 모델은 없고, 모바일, 위치기반 서비스 등은 향후 몇 년 후에야 중요한 서비스들이 될 수 있을 테니, 투자비용의 회수기간을 생각하면 당장은 ROI 측면에서 우선 순위가 떨어지는 서비스 일지도 모릅니다. 이러한 면들을 생각하면 다음과 네이버가 바라보는 지도서비스에 대한 관점이 보이는 것 같습니다.

다음은 지금 당장은 부담스러운 출혈이더라도, 향후 양질의 지도 기반 서비스를 위한 초석을 다지므로써 미래를 위한 투자를 하는 것일테고, 네이버는 총알(?)은 충분하니 필요하다면 컨텐츠 부분은 단기간에 따라갈 수 있다는 안이한 생각인 것 같습니다. 글쎄요~. 개인적인 생각으로는 네이버는 1등의 자만에 빠진 것 같습니다. 지금까지의 네이버의 성장동력은 타 서비스의 장점을 빨리 흡수하는 것이었는지는 모르겠지만, 이제 한국 시장 점유율 1위인 업체라면 시장을 주도하는 모습을 보여주어야 할 때가 아닌가 싶습니다.

위성항공 사진 서비스는 둘째치고, 한 두 달 이내에 다음의 로드뷰와 맞먹는 혹은 뛰어넘는 서비스를 보여주지 못한다면, 사실 지도전쟁은 끝입니다. 지도서비스의 기능에 있어서도 다음이 네이버를 압도하고 있는 지금, 다음의 지도API를 이용한 매시업 서비스들이 국내에서 쏟아져 나오기 시작하면 지도플랫폼에 있어서 네이버는 쉽게 따라가기 힘들겠지요. 지도는 컨텐츠 구축비용이 크기도 하고 당장 돈이 안되는 서비스이기 때문에, 상황을 뒤집을 자신이 없다면 한번 밀리면 선뜻 투자하기 힘든 분야 입니다. 게다가 네이버 지도는 기능면에서도 이미 타 포털에 비해 떨어지는 편이지요.(버스정류장 정보나, 실시간교통정보 등) 솔직히 지도전쟁은 1월 17일부로 끝난 것 같습니다.

자만심에 빠져서 어설픈 컨텐츠로 경쟁사보다 먼저 서비스를 오픈하고 선빵쳤다고 자위하는 네이버보다는, 힘든 상황에도 미래를 위해 투자하고 최고의 서비스를 보여주는 다음을 응원하고 싶습니다. 일단은 네이버가 깜짝 놀랄 서비스로 지도전쟁 2차전에 들어갈지, 이대로 지지부진한 모습을 보이며 미래의 핵심 서비스를 포기하게 될 지 궁금합니다.

차세대 웹브라우저 성능 비교

(OddPoet) — Sun, 11 Jan 2009 06:28:34 +0900

구글 크롬(google chrome)의 출시 이후 웹브라우저들의 성능 경쟁이 본격화 된 것 같습니다. 특히 웹브라우저에서 렌더링 외에도 Javascript 성능이 중요지면서 Firefox의 TraceMonkey, Safari의 SquirrelFish 등 새로운 javascript 엔진으로 성능에 초점을 맞추고 있는 것 같습니다. 기능이 비슷비슷하다면 이제는 성능이 비교척도가 되겠죠.

그래서 아직은 베타 단계에 있는 웹브라우저들의 성능을 비교해보려고 합니다.

비교할 브라우저들은 다음 5개 입니다.

Internet Explorer 8 beta2
Firefox 3.1 beta2
Google Chrome 2.0.156.1
Safari 4.0 (528.1.1) Developer Preview
Opera 10.0 alpha (build 1139)

모두 윈도우즈용입니다. (Google Chrome의 개발자 2.0 베타 설치는 웹초보님의 포스트를 참고하세요.)

ACID3 테스트

잘 알려진 웹표준 테스트인 ACID3 테스트 결과입니다.

Opera, Safari, Chrome이 100점을 받았습니다. 하지만 Chrome은 linktest 실패 외에도 깨지는 부분이 있습니다. 그리고 Safari와 Chrome 모두 테스트 수행시 100점 안나올 때가 있습니다. 조금 불안정하지요.

Firfox는 93점으로 체면 유지, IE8은 여전히 안습입니다. 웹표준 지키겠다더니 아직 먼 얘기인듯 합니다.

Firefox3.1

IE8

Chrome2.0

OPera10

Safari4

이제 IE8을 제외하고 대부분의 브라우저들이 ACID3 테스트 통과를 눈앞에 두고 있는 것 같습니다.

Javascript 성능 테스트

SunSpider, V8 benchmark suite, Celtic Kane online의 javascript 테스트를 수행했습니다.

SunSpider

숫자 작을 수록 성능이 좋습니다. 여전히 Chrome이 제일 우수합니다만, Firefox가 거의 근접한 수준의 결과를 보입니다. TraceMonkey 엔진이 정말 좋긴 좋은가 봅니다. Safari와 Opera가 2위 그룹, IE8이 최악의 성능을 보입니다. IE8은 Chrome과 비교해서 6배 가까이 느린 성능을 보이는 군요. 그래도 IE7이 10배이상 차이를 냈던 것을 생각하면 많이 좋아졌습니다.

V8 benchmark suite

V8 benchmark가 Chrome의 javascript 엔진 튜닝을 위해서 만들어졌다지만, 결과는 사실 좀 어이가 없을 정도입니다(숫자가 클 수록 좋은 성능입니다). Chrome의 그래프가 너무 심하게 올라가서 다른 브라우저들은 다 고만고만하게 보입니다만, Firfox와 Opera가 비슷한 성능을 보이고, Safari는 그보다 좀더 나은 성능을 보입니다. IE8은 이번에도 꼴등입니다.

Celtic Kane Online

이 테스트는 수행에 걸리는 시간은 짧지만, 수행할 때마다 결과값의 편차가 제법있습니다. 대충 5번 수행해서 평균냈습니다. 역시 Chrome이 1등, IE8이 꼴등입니다. Firefox 역시 다른 브라우저들에 비해 떨어지는 성능을 보이는 군요.

Javascript 성능에 있어서는 여전히 Chrome이 괴물급인 것 같습니다만, 다른 브라우저들도 많이 좋아진 탓에 Chrome 출시 초기때와 비교해서는 격차 줄었습니다. (솔직히 V8 benchmark 결과는 구라 같습니다.ㅡ.,ㅡ)

웹페이지 로딩

WebWait.com에서 Naver 메인 페이지를 20초 간격으로 5번 로딩하게 해서 측정한 결과입니다. (단위:초)

역시 웹페이지 로딩에 있어서는 Safari가 아직도 지존이군요. Opera는 새로운 렌더링 엔진(Presto2.2)의 파워로 2위 랭크입니다. 뭐 여전히 IE8이 꼴지입니다.

메모리 점유율

네이버, 다음의 메인페이지와 구글 개인화페이지를 각각 탭으로 띄워놓은 상태에서 위의 5개 테스트를 마친 후의 메모리 점유율을 측정한 결과입니다. (총 8개탭이 열린 상태입니다)

탭 각각에 Process를 할당하는 Chrome과 IE8이 메모리 점유율은 많은 편입니다. 단순한 메모리 점유율보다는 메모리 누수 등의 메모리 관리가 더 중요한 문제이니, 이 측정치는 그냥 참고만 하는 게 좋겠습니다.

결론

전반적으로 구글의 Chrome이 성능면에서는 최강이지만, 타 브라우저들 역시 그 사이 많이 좋아졌습니다. 지금까지는 새로운 기능이 웹브라우저 발전의 주요 트랜드였지만 구글 Chrome 출시 이후, 이제는 성능이 상당히 중요한 이슈가 되어 가는 것 같습니다.

google favicon이 바뀌었습니다.

(OddPoet) — Sat, 10 Jan 2009 21:56:52 +0900

오늘 구글의 favicon이 바뀌었습니다.

아시다시피 favicon은 브라우저의 주소창이나 탭의 타이틀에 표시되는 작은 이미지이지요. 북마크에서도 favicon이 보여지기도 하구요. 때문에 작은 크기의 이미지임에도 불구하고, favicon은 웹사이트의 메인 로고 만큼이나 중요하다고 할 수도 있습니다.

Official Google blog에 따르면 작년에 구글 favicon을 변경한 후 많은 유저들이 새로운 아이디어를 보내왔다고 합니다. 사용자들이 보내온 아이디어들과 디자인 요소들로 부터 이번 새 favicon이 만들어 졌다고 합니다.

그 중에서도 Brazil의 대학생인 André Resende가 보내준 favicon을 베이스로 만들었다고 합니다. 그의 아이디어는 심심한 백그라운에 구글의 컬러라 할 수 있는 red, yellow, green, blue를 'g' 문자 주위에 배치한 것이었죠. 비슷한 아이디어를 보내준 다른 사람들의 이름들도 소개하고 있습니다.

구글의 로고들도 그렇지만 favicon도 사용자들의 참여로 만들어나가는 것을 보면, 역시 많이 부럽습니다.

Windows 7 beta(build 7000) 소감

(OddPoet) — Fri, 09 Jan 2009 01:06:21 +0900

오늘 Windows 7 beta와 언어팩이 공개되었다.
현재는 MSDN 및 TechNet구독자들만 다운로드 받을 수 있고, 현지 시각으로 9일부터 일반인들도 윈도우 7 사이트에서 다운로드 받을 수 있다.
MSDN이나 TechNet 구독자가 아니지만 내일까지 기다릴 수 없는 사람이라면 Torrent나 웹하드 등에서 지난 달에 유출된 build 7000 버전을 구해도 된다. (참고로 파일명이 7000.0.081212-1400_client_en-us_Ultimate-GB1CULFRE_EN_DVD 이다) 한글 언어팩은 초짜 플머 헬마 님의 블로그를 잘 둘러보시면 찾을 수 있다.

build 7000을 1주일쯤 전에 설치했었고, 오늘 공개된 베타가 build 7000인 걸 확인하고 바로 언어팩을 다운받은 후 설치해보았다. 아직은 베타이다 보니 언어팩을 설치해도 군데군데 한국어로 표기되지 않는 부분들이 있다. 역으로 영문으로 표기 되는 부분이 비스타에서 변경된 부분이라고 볼 수도 있겠다.

전체적인 체감 성능에 대해서 간단히 10자평으로 쓰자면, 'XP만큼 가볍고 빠르다!'이다.

부팅직후 메모리 점유율이 400메가 초반이다. (서비스 설정 건드린거 없이 설치 후 디폴트이다) 게다가 부팅속도, 프로그램 실행 속도도 체감상 확실히 빨라진 것 같다. 측정해보지는 않았지만 느낌상 윈도우XP보다도 더 가볍고 빠른 것 같다.

아래는 Macbook Pro에서 VMWare로 1CPU / 1G ram을 할당해서 Windows7을 부팅시킨 직후 메모리 사용량이다.
거의 Vista의 절반 수준이다.

6000번대 빌드와 달라진 부분만 살펴보겠다.

슈퍼바의 경우는 사용습관에 따라 호불호가 갈릴 것 같은데, 개인적으로는 Mac OSX의 Dock의 컨셉과 비슷해져서 기존의 태스크바보다 맘에 든다. 슈퍼바에서는 아이콘을 좌우로 드래그 해서 아이콘의 순서를 바꿀 수 있으며, 아이콘을 위로 드래그해서 해당 프로그램에 대한 추가적인 메뉴 (IE의 경우 열어본 페이지 목록 같은)를 볼 수 있다. 한마디로 태스크바과 빠른실행의 기능을 하나의 인터페이스로 제공하는 셈이다.

에어로 스냅은 OSX의 데스크탑 보기 기능과 유사한 기능인데 창을 흔들어서 바탕화면을 본다는 점에서 재미가 더해진 기능이랄까. 기존 Vista까지의 바탕화면보기 기능은 단순히 보여지는 창을 모두 최소화시켜버리는 기능이었다면, OSX의 데스크탑보기나 윈도우7의 에어로 스냅은 창을 최소화한는 개념보다는 안보이게 했다가, 다시 그 창들을 보이게 하는 토글 기능이라 할 수 있다.

슈퍼바, 에어로스냅 외에도 사이드바 제거 등을 보면, 사용자인터페이스에 대해서 많이 고민한 티가 난다. 그래서 얼핏보면 윈도우7은 Vista와 비슷한 외양인 것 같지만, 써보면 Vista와 비교해서 편해지고 세련되어 졌다.

사실 시스템 리소스를 제대로 관리못해서 OS 자체가 너무 무거웠던 Vista는 실패작이 맞다. Vista에서 개선된 부분도 많았지만 윈도우7을 보면, Vista는 커널 및 UX의 변화를 위한 과도기적인 버전임을 실감하게 될 것이다. 그래서 아직은 베타 버전임에도 윈도우7이 기대되고 기다려진다.

네이버 위성항공지도 서비스, 그리고 다음...

(OddPoet) — Thu, 08 Jan 2009 04:05:34 +0900

1월 6일자로 네이버가 위성항공지도 서비스를 오픈했다.
다음이 11월 부터 스카이뷰와 로드뷰를 대대적으로 홍보해왔지만 아직 서비스 오픈을 하지 못한 반면, 소문만 있었을 뿐 상대적으로 조용하던 네이버가 선빵을 날린 셈이다.

포털들의 위성지도서비스 비교

이미 위성항공지도 서비스를 제공하고 있던 야후, 구글과 네이버의 위성항공사진 이미지 품질을 비교해본다. 파란은 Firefox에서 지도자체가 보이지 않고, 콩나물은 IE에서만 위성항공서비스를 이용할 수 있는 관계로 제외한다. (Mac에서 확인 불가능.) 동일하게 인천국제공항 일부를 캡쳐했다. 캡쳐 후 jpeg으로 변환했기 때문에 실제 브라우저로 보는 것과는 다소 차이가 있을 수 있다.

Naver

Yahoo

Google

Google Korea

구글 한국 지도서비스(http://maps.google.co.kr)의 경우 고해상도 위성사진을 제공하지 않아 지도와 위성의 줌레벨이 2레벨 넘게 차이가 난다. 거의 사용할 수 없는 수준이다.
구글 맵(http://maps.google.com)은 고해상도 위성항공사진을 제공하지만, 한국 지역의 지도서비스와 연동되지 않아 사진만 보일 뿐 라벨 표시가 되지 않는다.
야후 지도는 전국지역 60cm급 위성사진을 제공하지만, 구글맵, 네이버 등과 비교해봤을 때 사진 품질이 많이 떨어지는 느낌이 든다. 하지만 전지역에 동일한 해상도의 위성사진을 제공하는 것 장점이다.
네이버 지도의 경우 50cm급 항공사진이 서비스되는 지역에 한해서는 다른 서비스들보다 더 나은 품질을 보여주고 있다. 하지만 50cm급의 고해상도 사진이 서비스되는 지역이 많지 않다는 것이 단점이다. 심지어는 서울 시청, 신촌 등의 서울 주요 지역 조차 2m급 해상도의 사진만 서비스되고 있다. 확실히 다음을 의식한 듯...

그럼 다음 주 쯤 오픈할 예정이라는 다음의 스카이뷰는 어느 정도일까?

likejazz님의 '지도 플랫폼 혁시의 시작, Daum 스카이뷰/로드뷰'에 있는 캡쳐이미지를 보건데, 아마도 위성사진 퀄리티는 현존 최고를 보여주지 않을까 생각된다.

네이버 vs. 다음 지도전쟁은?

국내 포털시장의 라이벌이라 할 수 있는 네이버와 다음의 지도서비스를 보자.
다음이 스카이뷰 & 로드뷰에 대해 대대적인 홍보를 하면서 지도서비스에 상당히 적극적인 입장을 보이고 있는 반면, 네이버는 전반적으로 소극적인 자세를 보이고 있다. 그것이 2등이 가지는 치열함과 1등이 가지는 여유일지도 모르겠다.

사실 한국의 경우 보안시설에 대한 검수 때문에 위성사진 서비스를 한 두달 사이에 뚝~딱 만들 수는 없으니, 네이버도 다음의 스카이뷰 발표 전부터 위성사진 서비스를 준비해왔으리라 생각된다. 하지만 다음이 50cm급 전국 서비스를 오픈하려는 시점에 일부 지역의 고해상도 사진만으로 성급히 서비스 오픈을 한 것은 이미 지도전쟁에서 다음에게 밀리고 있음을 인정했다는 얘기다.

위성사진서비스는 한 발 앞서 오픈해서 모양새는 갖췄다지만, 다음의 로드뷰에 대해서는 어떤 카드를 내놓을지 사뭇 궁금하다. 다음의 스카이뷰와 로드뷰도 오픈해봐야 알 수 있겠지만, 어쨌거나 일단은 다음이 네이버보다는 한 발 앞서 나가고 있는 듯 하다.

UCC로 대표되는 Web2.0 의 패러다임과는 달리 직접 상당한 비용을 들여서 컨텐츠를 구축해야하는 지도서비스는 앞으로 모바일까지 아우르는 위치기반서비스에서 중요한 서비스 플랫폼이 될 것은 자명하다. 아직 구글의 서비스를 뒤쫓고 있는 형국이지만 한국의 포털들이 앞으로 구글을 넘어서는 어떤 멋진 서비스를 내놓을지, 또 지도서비스에서 어떤 수익모델을 만들어 나갈지 기대된다.

Apple In-ear headphones with Remote and Mic

(OddPoet) — Tue, 06 Jan 2009 06:59:05 +0900

크리스마스 선물로 와이프에게 Apple In-ear headphones with Remote and Mic를 선물 받았다.

예전 휴대형 CDP시절만 해도 Sony의 MDR-E888와 Cresyn의 E700을 쓰면서 나름 이어폰에 돈을 썼었는데,
MP3P 시절이 되니 손실음원인데다가 주로 실외에서 듣는 휴대형 기기에 비싼 이어폰 안쓰게 되더라.
그래서 iPod 쓰면서 부터는 번들 이어폰을 써왔었는데, 이번 iPod touch의 번들 이어폰은 기변 사이클을 못 버티고 전선피복 벗겨지고 얼마전부터 한쪽 소리가 안 나오더라는.....

때마침 출시된 Apple in-ear headphones!
iPod touch 1세대를 쓰는 터라 리모콘&마이크는 무용지물이지만, 10만원 미만의 가격에 2 드라이버 이어폰라는 점에서 눈이 뒤집히고야 말았다. (확실히 연말은 인센티브에 대한 기대감 때문에 지름신이 강림하는 시기인듯.)

예약주문한지 대략 열흘만에 받았는데,
외양은 애플제품 답게 디자인이나 착용감은 우수하나, 내구성은 그다지 뛰어나 보이지 않는다.
(번들 이어폰처럼 1년만에 피복벗겨지고 그러면 안되는데 ...)
음질쪽은 저음이 약하다는 말들이 있던데, 몇일간 사용해본 바로는 그다지 저음이 부족하다는 생각은 들지 않는다.
그리고 커널형이라 차음성이 좋아서 지하철 같은데서 글렌 굴드 앨범을 들어도 허밍소리가 명확히 다 들리더라.

기십만원대 고급형 이어폰에 비할바는 못되겠지만(써본적도 들어본적도 없으니 비교불가 ㅡ.,ㅡ),
2드라이버 이어폰들이 보통 20만원대 이상인 걸 생각하면 가격대 성능비는 괜찮은 제품이라 생각된다.

Macbook Pro 구입!

(OddPoet) — Thu, 11 Dec 2008 09:55:00 +0900

2년 가까이 쓰던 Macbook을 와이프에게 양도(와이프에게 버렸다는 표현이 더 맞을지도)하고 드디어 Macbook Pro(구형/2008초 모델)를 구입했다. 누군가의 '맥북은 시작에 불과하다. 결국 맥북프로로 가게 되리라!' 라는 저주(?)가 최종적으로는 맞아 떨어졌다.

사실 가격 때문에 맥북프로는 망설여 왔었지만, 신형 유니바디 맥북라인업의 가격표를 1달간 보고 있자니 착시현상이 생기면서, 200이 넘는 구형 맥북프로가 싸보이더라. 개발자들의 로또라는 iPhone App 개발이라는 대의명분(?)으로 와이프를설득해서 결국은 지르게 된 것!!!

기존에 쓰던 구형맥북과 비교한 장점이라면,

팬시한 느낌의 맥북과는 달리, 금속바디의 신뢰감이랄까. 간지 100% 향상!!! (다른 제조사에서도 다양한 컬러의 노트북을 내놓다 보니, 화이트 컬러의 희소성이 상대적으로 떨어진 면도 있고...)
LED 백라이트 사용으로 눈이 시릴정도로 cooool한 화질을 보여준다. 이거 보다가 맥북LCD를 보면, 매우 어둡다는 느낌이 들어서 F2키를 난타한다는....
15인치 1440x900 해상도는 13인치 1280x800 와 별 차이 없을 것 같지만, 써보면 확실히 넓고 시원한 느낌이다.
2008년 모델이라 4손가락 제스쳐까지 가능하다. multiClutch로 설정하면 Firefox에서도 트랙패드만으로 Go/Back이 가능하니 마우스가 없는 상황에서도 편하다.
키보드의 말랑말랑한 느낌. 기계식 키보드의 시원시원한 맛과는 다르지만, 기존 맥북의 키보드보다는 손이 더 편한 느낌이다.
그래픽 카드의 존재! 게임을 하지 않더라도, 외부 모니터 물렸을 때 확실히 차이가 있다. 램3G로 업그레이한 맥북이었음에도 외부모니터를 사용할때는 눈에 띄게 화면전환이 버벅거렸다. 하지만 맥북프로의 경우 절대 힘들어 하지 않는다.
확실히 나아진 발열. 메롬과 펜린의 차이, 바디 재질의 차이, 내부팬의 갯수 등 발열과 관련된 부분들의 스펙차이가 꽤나 나기 때문이겠지만 전반적으로 10도 이상 낮아진 것 같다. 대부분의 경우 50도 초반 온도를 보인다.

상대적인 단점은? 글쎄 없는 것 같다. ^^
휴대성이 떨어진다고는 하지만 맥북에어라면 모를까, 크기나 무게는 별반 차이 나지 않는다. 넷북 같은 소형 노트북이 대세인 시대에 13인치나 15인치나 휴대성이 떨어지기는 그놈이 그놈이라는...

유니바디 맥북 라인업의 경우 맥북과 맥북프로가 뽀대나 스펙상으로 별 차이 없어보이지만, 절대 넘을 수 없는 화면 크기와 해상도의 벽이 있으니, 여전히 맥북프로를 강추하는 바이다.

Lightroom 네트웍 드라이브로 데이터 공유하기

(OddPoet) — Mon, 04 Aug 2008 16:03:19 +0900

집에 PC가 여러대이다 보니 공유나 백업 등의 목적으로 사진파일과 Lightroom의 카타로그 파일을 파일서버(Linux Samba)에 올려놓고 관리하려고 했는데, 그럴 경우 Lightroom이 구동될 때 네트웍 드라이브나 읽기 전용 장치에 있는 DB파일은 지원하지 않는다는 메시지가 뜨면서 해당 카타로그DB 파일로 실행이 되지 않는다.

이건 Lightroom의 경우 내부적으로 sqlite로 사진 카타로그정보를 관리하는데, 이게 아직 다중사용자 지원이 되지 않아서 그렇단다. 이번에 Lightroom 2.0이 릴리즈 되었길래 혹시 이제는 지원할려나 싶었으나 아쉽게도 아직도 네트웍 드라이브에 있는 카타로그DB 파일은 지원하지 않는다.

하지만, Windows 계열의 OS일 경우 다음과 같은 명령으로 해당 네트웍경로를 드라이브로 설정하여 Lightroom 구동이 가능하다.

C:\> subst p: \\catsby\photos

위 명령은 \\catsby 라는 파일서버의 photos 라는 공유폴더를 로컬PC의 P 드라이브에 마운트한다.

subst 라는 명령은 특정 디렉토리를 디스크드라이브처럼 인식하게 하는 명령어인데, 이렇게 하면 Lightroom에서 해당 경로가 네트웍 드라이브인지 판단하는 로직을 회피할 수 있게 되는 것 같다.
(출처는 예전 해외포럼에서 본 건데 어디였는지는 기억이 안남 ^^)
따라서 네트웍 상의 카타로그파일로 실행이 가능할 뿐이지, 여러사람이 동시에 하나의 카타로그파일로 Lightroom을 실행할 수 있는 것은 아니다.

암호가 있는 네트웍 파일서버라면 아래와 같이 스크립트를 만들어서 실행한다.

net use \\catsby\photos PASSWORD /user:USERID
subst P: \\catsby\photos

그런데 맥 OSX에서는 방법을 못찾아서, 이젠 Lightroom은 PC에서만 사용중...ㅡ.,ㅡ

Windows 서버에서 Rails 배포하기

(OddPoet) — Mon, 23 Jun 2008 22:51:43 +0900

Unix 환경이라면 카피스트라노(Caspistrano)를 이용하여 Rails 애플리케이션을 배포할 수 있지만, Windows 환경인 경우는 대부분의 작업을 직접 해줘야 한다. 이 포스트에서는 Windows 서버에 Apache2 + mySql + Mongrel 구성으로 Rails 애플리케이션을 배포하는 방법에 대해 설명한다.

1. Apache2 / mySql

Apache와 MySQL을 각각 설치해주는 방법도 있지만, 윈도우즈 환경에서 손쉽게 APM(Apache+PHP+MySQL)을 설치할 수 있는 APMSetup을 설치한다. (나의 경우 기존에 다른 application 때문에 APMSetup을 설치해놓은 것이 있다 보니, 선택의 여지가 없었다.)
APMSetup으로 mysql을 설치한 경우, 디폴트 설정때문에 Mongrel 서버가 죽는 경우가 생길 수 있다. 따라서 C:\APMSetup\my.ini 파일을 열어 아래와 같은 설정을 주석처리하자.

#connect_timeout = 60
#wait_timeout = 60

그리고 Http Proxying으로 백엔드의 Mongrel로 rails 요청을 보내기 위해서 C:\APM_Setup\Server\Apache\conf\httpd.conf 파일을 아래와 같이 수정한다.

# mongrel cluster
<Proxy balancer://mongrel_cluster>
BalancerMember http://127.0.0.1:3000
</Proxy>
# rewrite rule
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]
# web root가 아니라 web서버의 /rails_app 경로에서 서비스 하려면
# 위 라인 대신 아래 라인을 추가한다. (이 경우 mongrel에 prefix 옵션을 줄것)
# RewriteRule ^/rails_app/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]

# web root로 rails_app의 public 디렉토리를 잡는다.
DocumentRoot "C:/rails_app/public"
# rails app를 web root가 아닌 /rails_app 경로로 서비스 하려면
# 위 라인 대신 아래 라인으로...
#alias /rails_app "C:/rails_app/public"

<Directory "C:/rails_app/public">
   Options Indexes FollowSymLinks
   AllowOverride none
   Order allow,deny
   Allow from all
</Directory>

2. Ruby 설치

루비 공식홈페이지에서 윈도우용 원클릭인스톨러를 다운로드 받아 설치한다.
설치 후 cmd창에서 gem update 및 rake, rails, mongrel, win32-service, mongrel_service 등을 설치한다.
ruby 1.8.6 버전을 설치했다면 gem update는 해주는 것이 좋겠다. 그리고, rails 최신버전이 아닌 버전을 사용한다면 설치시 --version 옵션으로 원하는 버전을 지정해주자.

C:\> gem update --system
C:\> gem install rake
C:\> gem instal rails
C:\> gem mongrel
C:\> gem win32-service
C:\> gem mongrel_service

3. Rails Application 셋업

개발된 rails application 디렉토리를 서버로 복사하는 것도 방법이지만, 추후 재배포를 생각해서 소스리파지토리에서 checkout하는 것이 좋다. subversion의 경우 나중에 svn update 명령만으로 최신파일로 쉽게 갱신할 수 있다.
위의 예에서와 같이 C:\rails_app 라는 경로로 설치했다고 가정하고 다음 작업을 진행하자.

3.1 DB 설정

우선 rails application에서 사용할 database를 생성한 후, config/database.yml 파일의 production 모드의 DB 설정을 확인한다. 그 후 cmd창에서 해당 DB에 db:migrate 작업을 수행한다.

C:\rails_app> rake db:migrate RAILS_ENV=production

3.2 mongrel을 서비스로 등록

위에서 win32-service와 mongrel_service를 설치했다면, mongrel을 윈도우즈의 서비스로 등록할 수 있다.

C:\rails_app> mongrel_rails service::install -N "Rails APP" -e production -p 3000 -c "C:\rails_app" -r "C:\rails_app\public"

혹시 web서버의 root 경로가 아닌 /rails_app 경로로 서비스하는 경우라면, 아래와 같이 --prefix 옵션을 추가한다.

C:\rails_app> mongrel_rails service::install -N "Rails APP" -e production -p 3000 -c "C:\rails_app" -r "C:\rails_app\public" --prefix /rails_app

윈도우즈의 [제어판]-[관리도구]-[서비스]에 가면 "Rails APP"라는 이름으로 서비스가 등록되어 있는 걸 확인할 수 있을것이다. 그 서비스를 시작시키면 된다.

ZiPhone으로 ipod touch 1.1.4 jailbreak 하기

(OddPoet) — Tue, 11 Mar 2008 00:49:11 +0900

DevTeam의 jailbreak가 1.1.1로 downgrade 한 후에 순차적으로 작업해야 했던
번거로움 때문에 계속 1.1.2를 사용하고 있었는데, DeGool님의 포스트를 보고 1.1.4로 upgrade를 단행했다!

방법은 DeGool님이 설명한 바와 같이

iTunes를 사용해서 펌웨어를 1.1.4로 업그레이드.
ZiPhone 2.5c 를 사용해서 jailbreak. (http://www.ziphone.org)
(현재 jailbreak버튼 난타(?) 없이도 iPod touch jailbreak가 가능해짐)
끝!

Mac이던 Windows이던 방법은 동일하다.
펌웨어를 1.1.1로 다운그레이드하고 1.1.4까지 jailbreak & upgrade하려면
대략 1~2시간 걸리던 작업이 10분내에 끝이 난다.

그런데!
문제는 키보드만 뜨고 나면 iPod이 먹통이 된다는거!
사실 지난주에 아는 사람 부탁으로 DevTeam의 방법으로 jailbreak할때도 그런적이 있었는데,
ZiPhone을 사용해도 같은 문제가 발생했다. 여러번 삽질했지만 결과는 동일...
'내 손은 저주받은 손인가!'라고 생각하고 포기하려다가 구글링을 했더니 ....역시!!!

출처: http://www.ipodtouchfans.com/forums/sho ··· %3D44187

요점은 다음과 같다.

펌웨어를 1.1.4로 업그레이드 한 후에 iPod이 리부팅되고, iTunes가 iPod을 감지했다고 할때
그냥 무시하고 iTunes를 종료시켜버릴것!
jailbreak과정 중에 iPod이 리부팅을 1~2회 할텐데, 그때 iTunes가 자동으로 실행되면서
복구모드 어쩌고 하더라도 절대 버튼도 누르지말고 내버려 둘 것!

Mac/Windows 양쪽 모두 테스트해본 결과 위의 2가지만 지켜주면 키보드가 먹통되는일은 없다.

어쨌든 진정한 one-click Jailbreak의 등장은 SDK공개와 더불어
iPod Touch 유저들의 행복지수를 올려줄 사건일듯....