OddPoet's βetalog

집에 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에서만 사용중...ㅡ.,ㅡ

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"라는 이름으로 서비스가 등록되어 있는 걸 확인할 수 있을것이다. 그 서비스를 시작시키면 된다.

사무실 동료가 스크린세이버로 쓰어서 보게된 이 영상.
처음에는 대수롭지 않게 봤는데 보면 볼수로 묘하게 빠져들어
현재 집, 사무실 PC 모두에 스크린세이버로 설정해놓았다.

유니클락이라는 일본의 여성 의류 브랜드 광고라는데
젊은 아가씨들의 기묘한 동작들이 이상하게도 시선을 잡아 끈다.
매 정시에는 스페셜 동작들이 나오고, 밤에는 잠자는 영상이 나온다.
게다가 사무실에서 듀얼 모니터를 쓰고 있는데 양쪽 모니터에 서로 다른 영상이 나온다.

홈 페이지에 가보면 2007년 12월 22일 2시 19분 현재,
76개국의 17,164명이 블로그에 이 동영상을 설정해놨고 208개국의 57,147,610이 보고 있단다.
또, 이 동영상이 설정된 블로그를 랜덤하게 세계지도에 위치와 함께 보여준다.
여성의류에는 1g도 관심없는 내가 블로그에 이 동영상을 걸어놓아 광고에 협조(?)할 정도니,
정말 대단한 광고랄 밖에....

아래 URL에서 스크린세이버 다운로드 및 Blog에서 세팅하는 방법을 볼 수 있다.
http://www.uniqlo.jp/uniqlock/

부서에서 소스형상관리툴로 PVCS를 사용하고 있었다.
써본사람은 알겠지만 Subversion과 비교하면 도대체가 장점을 찾기 힘든 툴이다.
오래된 툴이라서 그러려니 하고 살아보려 했으나, 요상한 Archive 관리에 파일 삭제와 관련된 문제들,
그리고 결정적으로 매우 조악한 수준의 eclipse plugin은 내 인내력의 한계를 넘어버렸다.

개인적인 용도로 Subversion을 몇년동안 써왔던 터라 Subversion으로 옮겨가자고 건의도 해봤지만,
오픈소스 프로그램에 대한 근거없는 불신과 관리조직의 회사표준툴 강요 등의 이유로 묵살당했다.
결국 시스템 전체 소스들을 Subversion으로 이주시키는 것은 포기하고(50여개의 서브프로젝트들로 구성),
내가 관리하는 5개 서브프로젝트들만 PVCS에서 Subversion으로 옮겼다.

소스의 현재 상태만 옮겨간다면야 그리 복잡할 것도 없는 작업이지만, 3년 가까이 쌓여있는 변경 히스토리를 통채로 가지고 가야 하기 때문에 마이그레이션 작업은 필수적이었다.

구글링을 통해 PVCS -> Subversion 컨버전 툴을 2개 정도 찾을 수 있었다.

1. SVNImporter
SVNImporter는 Eclipse subversion plugin인 Subversive를 만드는 Polarion.org의 프로젝트로,
PVCS 뿐만아니라 CVS, VSS, ClearCase, MKS, StarTeam 등의 리파지토리로 부터 Subversion으로의
conversion을 지원한다. (jdk1.4 이상에서 실행)
SVNImporter는 PVCS에서 리비전 별로 파일들을 받아서, subversion dump file로 만든 후에
'svnadmin load' 명령을 사용하여 subversion 리파지토리에 로드하는 방법으로
리비전 히스토리를 컨버전한다.

2. pvcs2svn.pl
Thomas Wolkenstein이 만든 perl script이다.
이 스크립트는 PVCS에서 파일을 get 한 후에, subversion에 commit하는 것을 리비전 별로 반복적으로
수행하므로써 컨버전 작업을 수행한다.

속도면에서는 SVNImporter의 경우가 다소 빠른 것 같았으나, 한글이름의 파일들을 정상적으로 처리하지
못하는 문제가 있었다. 그리고 변경 comment의 한글 일부가 깨지는 문제가 있었다.
반면, pvcs2svn.pl 스크립트는 한글이름의 파일에는 문제가 없으나, SVNImporter와 마찬가지로
comment의 한글 일부가 깨지는 문제가 있었다.

컨버전 시간은 프로젝트의 파일 수, 파일 리비전의 수, 파일의 크기 등에 영향을 받을 수 있으니
단정적으로 말할 수는 없지만 Subversion으로 변환 후 리비전 번호가 1000, 파일 갯수가  7000여개 정도되는
프로젝트의 경우 컨버전에 10시간이 넘는 시간이 소요되었다. (pvcs2svn.pl로 작업)

마이그레이션에 소요됐던 시간과 수고는 Subversion으로 옮겨온 후에 얻을 수 있는 이점을 생각하면,
충분히 상쇄될만 하니 개인적으로는 만족스럽다. 다만 최근 회사에서 PVCS대신 Dimension으로
소스형상관리툴을 교체해나가고 있는데, 어떻게 버텨야 할지가 문제......

시간 잡아먹는 귀신이라 평소 시리즈물은 선호하지는 않았는데,
iPod touch 구매 기념(?)으로 공각기동대 TV판 1,2기를 지하철에서 짬짬이 봤다.

글솜씨가 없어서 리뷰 수준의 글은 못 쓰겠지만,
역시 소문처럼 명작이라 할 만 하다.

디지털의 특징상 나타나는 수많은 복사본들.
여기 약간의 조작이 더해지면, 어느 순간부터 무엇이 '오리지널'이었는지 알 수 없다.
더욱이 어떠한 의도에 의해 그 '오리지널'에 조작이 가해지면,
정말 '진실은 저너머'로 사라진다.

음모론에 불과한 망상이던 아니던 간에
대형포털의 언론 조작설과
끊임없는 상호복제에 의해 오리지널리티를 상실한 뉴스 기사들을 비론하여
저작권을 무시한 블로그 컨텐츠의 펌질과 도용,
개인 저작 컨텐츠의 증가에서 나타나는 검증되지 않는 정보들.......
어쩌면 현대를 사는 우리들 역시 이러한 현상의 공범일 수도 있다.

어쩌면 광대한 네트웍에 연결되면서부터
이미 '개성'도 '오리지널리티'도 비현실적인 것이 되어가고 있는건지도 모르겠다.
모방과 복사에 길들여진 내가 '오리지널리티'를 운운한다는 것 자체가 모순이겠지......
아~괜히 머리가 아프다.

외모로 디자이너와 개발자를 구별할 수 있을까?
오늘 회사동료가 알려준 재미있는 사이트를 소개한다.

http://designervsdeveloper.com.au/photo ··· 53d.aspx
사진 속의 사람이 '디자이너'인지, '개발자'인지 추측해서 버튼을 누르면 오른쪽에 정답/오답 수가 집계된다.
열댓명 사진을 보고 열심히 찍어봤는데 정답율이 50%가 채 못되더라는......

이 재미난 장난에 동참하고 싶으면, 자신의 사진과 직업을 등록할 수 있다.
내 사진을 올려볼까 하다가 '딱! 개발자의 얼굴이군!'이라는 얘길들으면, 비참해질까봐 그만뒀다. ㅜ.,ㅜ
그래 난 생긴 것부터가 개발자다!