Outsider's Dev Story

약간 아쉬웠던 네이트 오픈정책발표회

(Outsider) — Thu, 09 Jul 2009 02:04:24 +0900

7월 7일에 SK컴즈의 "오픈정책 발표회" 가 있었습니다. 7월 7일이 길일이라도 되는지 티맥스의 윈도발표와 SK컴즈의 발표회가 둘다 있었습니다. 끝난 뒤에 블로고스피어를 봐도 윈도 발표에 더 많은 관심이 몰린것 같기는 하지만(이건 SK로써는 좀 굴욕이었겠군요. 같은 날이 아니었으면 더 이목을 집중받았을텐데요.) 저는 티맥 윈도에는 큰 기대감이 없었기 때문에 오픈정책 발표회쪽에 더 관심을 가지고 있었습니다. 사실 티맥스 윈도가 실체가 있다는거에 약간 놀라긴 했습니다. 머 둘다 큰 기대감에 부풀어서 볼 회사는 아니었지만 SK컴즈의 발표회쪽이 더 제 생업과 비슷했다고 할까요? ㅎ

어쨌든 지난 주에 팀장님이 오픈정책발표회 갈 생각없냐고 했는데 약간 바쁠것 같기도 해서 안간다고 했습니다. 머 SK컴즈가 제대로 개방해줄꺼라고는 기대하고 있지 않았고 실제로도 그랬습니다.(내년되면 어떨지 모르겠지만요. 사실은 더 폐쇄적이리라고 기대했는데 기대보다 이상이었던 것은 사실입니다.) 마침 실시간으로 발표회영상을 제공하고 있어서(요즘은 이렇게도 제공하는군요.) 회사에서 귀로만 들었습니다. 업무하면서 들어서 놓친 내용도 많아서 대충 분위기만 파악하고 자세한 내용은 결국 집에와서 다른 포스팅들을 보면서 파악했습니다.

네이트 오픈정책 발표회
이 발표회에서는 크게 2가지가 있었습니다. 네이트 커넥트랑 앱스토어죠.(아~ 정말 네이밍 센스 참... 이름짓는데 시간 하나도 안들었겠군요. 좀 참신하게좀 짓지...) 네이트 커넥트는 SK는 공개형 SSO인 OAuth냄새가 좀 났습니다. 네이트나 싸이월드 아이디를 이용해서 SK와 제휴된 사이트에 로그인하고(여기선 NID라고 하더군요.) 네이트와 싸이의 알리미를 이용해서 정보도 받을수 있는 형태의 서비스입니다. 어떻게 보면 OAuth보다는 OpenID에 더 가까운 것 같기도 합니다. 두번째는 앱스토어입니다. 개발자나 업체들이 앱스를 만들어서 싸이월드 시스템 내에서 유통시킬수 있는 것입니다. Facebook의 F8같은 시스템이라고 할 수 있겠습니다.

일단 제일 아쉬운건 제목과 다르게 오픈이 없다는 것입니다. 오픈이라 하려면 나갈수도 있고 들어올 수도 있어야 하는데 모든 것을 네이트안으로 끌어들이기만을 원했지 단 하나도 내어주려고는 하지 않았습니다. 요즘 추세에 맞게 하려고 오픈이라고 이름은 졌지만 딱히 반쪽자리 오픈이라는 느낌이었습니다..

어쨌든 SK컴즈로써는 가장 큰 관건이 싸이월드 살리기일꺼라고 생각합니다. 몇년전 대한민국을 뒤흔들만큼 인기를 끌었던 한국최고의 SNS 싸이월드가(휴가나와서 일촌이 뭐냐고 물었다가 캐무시받은 기억이 새록새록 나느군요.) 최고점을 이후로 점점 추락(?)하고 있고 어디 밀리지는 않았지만 딱히 전환점을 만들지 못하고 사용자가 이탈하고 있는 것을 두눈뜨고 보고있는 상황이라고 생각하고 있습니다. 이 싸이월드의 새로운 전환점으로 생각한 것이 C2서비스였고 C2의 실패이후 새로 가닥을 잡은 것이 싸이블로그였지만 둘다 참패하고 말았습니다. 일반 싸이월드 유저가 이 두 서비스를 알고나 있는지 모르겠군요.

물론 애플이 만든 앱스토어라는 풍토가 특별히 시스템 및 인프라를 갖지 못한 개인 개발자 혹은 업체에게 쉽게 수익모델을 가질수 있는 플랫폼에 대한 희망을 만들어주었고 네이트 앱스토어도 이런 점을 잘 겨냥한듯합니다. 미니홈피의 미니룸에 앱스를 올릴수 있는 것도 괜찮은 아이디어라고 생각하고 있습니다.

축소되는 국내 SNS
하지만 네이트가 여전히 방향을 좀 잘못 잡고 있다는 생각을 하고 있습니다.

Image by 10ch via Flickr

싸이월드가 대박이 났던것은 그 이전이긴 하지만 웹2.0이 도래한 이후 웹의 최대 화두는 Social Network입니다. 세계적으로 마이스페이스 -> 페이스북 -> 트위터 로의 SNS의 흐름이 이어지고 있습니다. 하지만 이건 해외의 사정이지 국내하고는 완전히 다릅니다. 국내 최고의 SNS인 싸이월드이후에 이렇다할 서비스가 없습니다. People2, 첫키스, IDtail, 링크나우등 SNS서비스가 등장했지만 유지만 하고 있을뿐 싸이월드의 흐름을 넘겨받은 서비스는 아직 없습니다. 싸이월드의 내리막길을 몇년째 걷고 있지만 아직도 국내에서는 최대의 SNS입니다.

블로그가 대새라니까 블로그쪽으로 빠져 나온 사람들도 있을테지만 제 생각에는 대부분 더이상의 재미를 못느끼고 싸이를 그만두지 않았나 싶습니다. 제 주위 일촌에서도 일주일에 한번이상 업데이트를 하는 사람은 그다지 많지 않습니다. 이런 것은 싸이월드가 다시 성공하느냐 다른 SNS가 대체하냐의 문제를 떠나서 국내 SNS파이(pie)의 크기문제라고 생각하고 있고 국내 SNS라는 파이가 점점 축소되고 있습니다. 블로그시장이 많이 성장하기는 했지만 소셜이라는 요소가 같이 있을뿐 블로그는 SNS를 중점으로 이루어지는 시스템은 아니라고 생각하고 있습니다. 물론 모든건 소셜네트워크로 연결되는 것이지만요.

완전한 오픈을 위해서...
SNS서비스라는 것은 그 이름대로 관계중심이기 때문에 혼자서는 활동하기가 쉽지 않습니다. 블로그는 딱히 정해져있는 인맥이 없고 피드백이 많지 않아도 그럭저럭 유지할 수 있는 시스템이라고 생각하지만 SNS는 관계를 통해서 더 활동량이 증폭되게 되고 이게 힘이되는 시스템입니다. 쉽게 말해 싸이월드에서 제 주위사람이 싸이를 안하게 되면 저도 싸이를 하는 빈도가 줄어들게 된다는 것입니다. 앱스같은 것은 형성된 인맥내에서 할거리를 줌으로써 활동량을 증폭시키는 역할이라고 생각하고 있습니다. 효과가 전혀 없는 것은 아니겠지만 싸이월드를 안하는 사람이 앱스를 추가하기 위해서 재진입의 요소는 좀 적지않나 생각하고 있습니다.

이런 면에서 진정한 오픈(싸이내의 콘텐츠도 밖으로 내어줄수 있는)을 한다면 모든 면에서 윈-윈할 수 있지 않을까 생각하고 있습니다. 저같이 절대 싸이월드의 미니홈피를 운영하지 않을 사람도 미니홈피에 있는 사람들과 컨텐츠를 주고받을 수 있고 SNS라는 파이자체가 더 커짐으로써 싸이월드의 유저활동량도 늘릴수 있지 않을까 예상합니다. 사실 이렇게 전체 파이가 다시 커질수 있다면 사람들이 SNS서비스를 다시 이용하면서 이글루스타 티스토리같은 서비스보다는 가장 익숙한 싸이나 대형 포털서비스를 이용할 가능성이 훨씬 높겠지요. 굳이 어려운 새시스템에 적응할 필요없이 익숙한 싸이를 사용해서 훨씬 많은 사람과 교류를 할 수 있으니까요.

위에 길게 쓰기는 했지만 사실 개방과 공유에 대한 부분은 제가 기대하는 웹에 대한 방향이지 반드시 이게 성공하고 돈이 되는 것은 아니라는 것은 아닙니다. 실제로도 해외 웹2.0과 비슷한 모델들이 국내에서는 이렇다할 성공을 못거두고 있는거지 국내웹의 현실입니다. 대기업이 이런 행보에 참여한 것은 어쨌든 환영할만한 일이라고 생각합니다. 이제 첫 발걸음입니다. 기업의 이미지를 떠나서 잘한 일은 잘했다고 칭찬해 주어야지요. 첫걸음부터 모든게 만족스러울 수는 없기에 시간이 지나면서 더욱 좋은 방향으로 진행되었으면 좋겠네요.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

Mozilla Labs 웹개발관련 도구 디렉토리 사이트 "Open Web Tools Directory" 오픈

(Outsider) — Wed, 08 Jul 2009 03:12:24 +0900

Mozilla Labs에서 괜찮은 사이트를 오픈했습니다.

모질라랩은 웹개발자에게 유용한 많은 툴이 있지만 이런 툴에 대해서 모르는 사람들이 많고 이것들을 중앙관리하는 장소가 없는 것을 아쉬웠다고 합니다. 이런 툴들에 대한 정보를 관리하는 것은 매일 이런 정보를 찾아다니는 사람들에게도 아주 어려운 일이기 때문에 웹개발자에게 유용한 툴(Tool)에 대한 정보를 인덱스 관리하는 사이트인 Open Web Tools Directory 를 오픈했다고 블로그를 통해서 밝혔습니다.

(이 GUI를 보려면 Firefox 3.5, Safari 4, Chrome2, Opera9같은 브라우져가 필요합니다.)

Canvas태그를 사용해서 만든 사이트같은데 제 느낌으론 애니메이션이 조잡하게 느껴지더군요. ㅡ..ㅡ

하단의 탭을 누르면 해당 카테고리에 속하는 툴들이 중앙에 정렬되어서 나타납니다. 현재 탭은 Design, Code, Debug, Test, Deploy, Docs 이렇게 6개가 존재하며 아래쪽 검색박스를 통해서 검색이 가능합니다.(Firefox 3.5에서 사용해 봤는데 UI는 좀 되다가 말다가 하네요 ㅡ..ㅡ)

원하는 아이콘을 클릭하면 툴팁으로 간단한 설명과 해당 툴의 Homepage링크가 나타납니다.

Mozilla Labs랩은 이 인덱스 사이트의 데이터 관리를 직접하기 보다는 웹2.0에 맞게 집단지성을 이용하려고 하고 있습니다. 그래서 이곳에 등록되어 있지 않은 툴을 등록할 수 있는 data entry form 을 제공하고 있습니다. 그리고 사람들이 어떤 툴들을 주로 관심을 갖는지 데이터를 수집할 예정인듯 합니다.

GUI 페이지 외에도 접근성이 좋은 Plain HTML Version의 페이지 도 제공하고 있습니다.

GUI가 개선되고 데이터가 많이 쌓이면 상당히 좋을 듯 하군요.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

트위터에 제한적 본인확인제 검토에 대한 기사를 보고

(Outsider) — Wed, 08 Jul 2009 02:25:52 +0900

오늘 방통위에서 트위터 의 이용자 확산에 따라서 본인확인제 적용여부를 검토하고 있다는 기사 가 떴습니다. 얼마전에 유튜브의 본인확인제를 구글이 거부한 사건 도 있었는데 이건 더 어이없는 일입니다. 생각난 김에 관련해서 실명확인에 대한 얘기나 해볼까 합니다.

주민등록번호 필요한가
물 론 본인확인제뿐만 아니라 저는 주민등록번호를 지금처럼 사용하는 것조차 별로 좋아하지 않습니다. 사실 저는 웹에 몸담고 있으면서도 웹사이트가 왜 이렇게 본인확인이라는 것에 연연하는지 도대체 이해할 수가 없습니다. 개인적인 추측으로는 초기 국내 웹환경에서 기인했다고 생각하고 있습니다. 아주 초기에는 어땠는지 모르겠지만 웹 1.0시대에는 전혀 수익모델은 없었지만 닷컴열풍이 불면서 그 기업의 가치가 곧 회원수였습니다. 지금도 약간 그렇지만 사이트의 회원수가 증가하고 기업을 판매하는 것이 가장 큰 성공이었던 것으로 기억하고 실제 회원수 곱하기 얼마하는 식으로 기업을 평가해서 매각하기도 했습니다. 그러다 보니 사는 입장에서는 회원수가 허위회원인지 아닌지를 확인하고 싶어했고 파는 입장에서도 증명해야 했습니다. 그러다보니 중복가입을 막기위해 가장 편한 주민등록확인을 하기 시작했고 어느새 모든 사이트가 당연한듯 주민등록번호를 받고 있습니다.

이 풍토는 국내 웹사이트에 아주 팽배해져서 아무리 작은 사이트도 주민등록번호를 요구하고 있고 심지어는 동네 PC방 회원가입란에도 주민등록번호 입력란이 있는게 현실입니다. 이렇게 주민등록번호를 포함한 갖가지 개인정보를 수집하려고 하면서 막상 그 정보를 어떻게 어떻게 활용할 건지 계획조차 없습니다. 사실 웹에서는 회원이 중요하지 그 회원이 누구인지는 별로 중요하지 않습니다. 웹사이트에서 Outsider를 쓰는 내가 실제 오프라인에서 누구인지는 전혀 필요치 않습니다. UV, PV하듯이 요즘은 실제 엑티브 유저 혹은 구매회원이 필요하지 내가 아이디를 2개를 돌려서 2개를 열심히 하든 1개에만 집중하든 사이트입장에서 구별해야 할 하등의 이유가 전혀 없습니다. 정말 이해할 수가 없습니다.

Image by Dominic Sayers via Flickr

하지만 이렇게 개인정보를 수집하는 대신 가지는 리스크는 상당히 큽니다. 주민등록번호를 암호화해서 관리해야 되고 개인정보유출에 대한 이슈가 커지면서 보안도 높여야 되고(물론 보안은 이거 아니더라도 높여야 되지만요.) 요즘은 주민등록도용때문에 실명확인까지 진행해야 하는데 실명확인을 하면서 대행업체에 비용도 계속 지불해야 합니다. 사실 이 실명확인도 금융정보를 이용하는 것이기 때문에 금융기록이 없는 사람은 실명확인조차 되지 않는 반쪽짜리 시스템입니다. 거기에 대형사이트의 경우 개인정보 유출되면 그 피해규모는 엄청나죠. 특정업체를 비하할 생각은 없지만 개인정보로 이슈가 되었던 옥션을 예로 들어보겠습니다. 제가 옥션에서 outsider라는 아이디로 가입했을때 이 아이디를 가진 사람이 실제 누구인지를 알고 있을 필요가 있나요? 배송할때는 제가 원하는 곳에 원하는 사람에게 배송받을 수 있고 카드를 이용한 결제는 별도의 프로세스를 이용해서 진행이 됩니다. 제가 옥션을 이용하고 옥션이 outsider라는 회원을 관리하는데 있어서 실제 누구인지에 대한 정보는 전혀 필요치 않습니다.

물론 뱅킹등 실명정보가 필요한 사이트들이 있기는 하지만 이는 극소수일뿐 전혀 필요치 않은 사이트들이 훨씬 많습니다. 수익모델고민이니 UI니 하면서 가장 기본적인 것조차 고민해보지 않는 전형적인 관리편의주의중 하나라고 생각하고 있습니다. 그래서 저는 OpenID 를 상당히 지지하고 있습니다.

본인확인제
하지만 국내에서는 웹이라는 시대를 역행해버리는 제한적 본인확인제라는 어이없는 법이 시행되면서 웹사이트들의 주민번호관리를 국가가 전폭적으로 지원하고 나서버려서 대형사이트들은 이젠 주민등록번호를 버리고 싶어도 버리지 않게 됩니다. 이 블로그에서는 정치적인 성향 얘기는 하고 싶지 않기 때문에 이 법에 대한 의도같은 것은 얘기하고 싶지 않습니다만 일일 게시판 이용자가 10만명이 넘는 경우는 본인확인을 해야만 게시판을 이용할 수 있는 법때문에 사이트가 커지면 본인확인의 부담도 같이 안아야 되게 되어버렸습니다.

이건 정말이지 웹이 그냥 컴퓨터에서 e아이콘을 클릭하면 되는거 정도로만 이해하는 사람들이 만들었다고 생각할 수밖에 없는 법입니다. 댓글의 욕을 없애고 서로 모욕하는 것을 막는다는 취지가 있기는 하지만 그다지 실효성도 없는게 사실이고 웹은 오프라인처럼 제한된 공간으로 존재하는 것이 아니기 때문에 다른 공간으로 이동해 버리면 그만입니다. IT기업들은 IT기업대로 울며겨자먹기로 따를수밖에 없었고 어쨌든 법시행은 그냥 되는 것처럼 보였지만 유튜브와의 본인확인제 충돌로 인하여 이 생각없는 법의 한계가 드러나버립니다.

동영상 UCC의 대표격인 유튜브가 국내서비스가 진행되고 많은 동영상이 공유되자 정부에서는 유투브에도 제한적 본인확인제를 요구하고 맘처럼 진행될줄 알았겠지만 구글은 이를 거절해 버리고 한국국적으로는 글을 남길수 없게 만들어버렸습니다. 구글로써는 그렇게 굴욕적으로까지 하면서 한국이 매력적인 시장이 아닐테고(처음 듣고는 미국본사에서는 이게 뭔말이야? 하지 않았을까 생각하기도 합니다.) 그렇다고 한국사람들이 아예 접속못하는 것도 아니니까 큰 피해는 없다고 판단했으리라 보입니다. 사실 국가선택만 바꾸면 글을 남길 수 있고 프록시를 타거나 우회할 수 있는 방법은 아주 많이 있습니다.

어쨌든 이 법 덕분에 국내 포털에서 OpenID 컨슈머 지원을 해달라든지 해외 사이트들과 OAuth 지원을 해달라는 요구를 할 수 없어졌습니다. ㅠ..ㅠ

트위터에도??
이 때도 구글이 한국이 IT에서 퇴보하는 것처럼 표현했다고 흥분하는 걸 보고 문제의 본질을 전혀 파악하지 못하고 있다고는 생각했는데 이젠 트위터에도 이걸 적용하려고 고민한다니 너무 어이없어서 웃음밖에 안나올 정도입니다. 트위터를 선거활동에 이용했다는 오바마를 만나고 오더니 이명박 대통령이 트위터에 가입할까 생각중이라는 얘기를 하더니 몇몇 정치인이 발빠르게 트위터에 들어오더니 김연아가 트위터한다 트위터가 대세다 하면서 언론에서 나오니까 엄청 큰 사이트라고 생각했나 봅니다.(조사도 안하나요? ㅡ..ㅡ) 사실 세계적으로 트위터의 성장은 엄청 나고 대세인 것이 확실하지만 국내에서는 최근에 아무리 성장했다고 하더라도 아주 미비합니다. 데이터는 없지만 제 생각에는 만여명정도 되지 않을까 싶고 한달에 활동하는 회원은 그보다도 못할꺼라고 생각하고 있습니다.(순전히 개인적인 예상입니다.) 일일 10만명이 될라믄 멀었고 제 예상보다 국내에서 트위터의 성장이 꽤 되기는 하지만 사실 10만명까지 갈꺼라고는 별로 생각하고 있지 않습니다.

Image by JoshSemans via Flickr

더군다나 정말 어이없는건 10만명이건 100만명이건 트위터에는 이걸 적용할 수가 없습니다. 일단 트위터는 구글코리아처럼 한국지사가 존재하지 않고 웹사이트를 미국에서 오픈해 놓은거 외에는 국내에서 활동이 전혀 없습니다. 할 필요도 없지요. 이건 트위터가 국내법 적용을 받을 이유가 전혀 없고 우리도 강제할 수가 없습니다. 방통위에서는 메일보내서 해달라고 사정해 볼 생각인걸까요 아니면 적용하라고 지시만 하면 트위터가 벌벌 떨면서 열심히 실명인증 대행기관에 비용지불에 가면서 제한적 본인확인제를 적용할꺼라고 생각하는 걸까요? 그리고 설사 트위터가 한국정부의 요청을 받고 구글처럼 국내유저를 막는다고 하면 그냥 프록시타고 들어가면 끝입니다. 컴퓨터를 잘 모르는 유저들은 진입하기가 쉽지 않겠지만요.

저런 기사가 났다고 트위터가 본인확인제가 되면 어떻하지?라는 걱정은 전혀 하고 있지 않습니다. 다만 나름 IT강국이고 앞으로 더욱 경쟁력을 키워도 모자랄 IT분야에 대해서 저런 기본적인 이해도 없이 컨트롤 한다는게 눈물이 날정도로 안타깝기만 합니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

veign.com이 공개한 HTML 5 Cheat Sheet (PDF)

(Outsider) — Tue, 07 Jul 2009 00:34:33 +0900

SMASHING MAGAZINE에서 veign 에서 만든 HTML 5 Cheat Sheet를 공개 했습니다.

위 기사에 따르면 XHTML은 끝나고 이제 HTML 5가 살아날꺼라고 합니다. W3C의 XHTML2 워킹그룹이 2009년 말에 작업을 중단할 것으로 예상 되며 대신 HTML5의 키울계획이라고 합니다. 비록 HTML 5는 2022년까지 완전히 지원되지 않는다 고 하더라도 이것이 앞으로 HTML이 넓게 퍼지지 않는다는 것을 의미하지는 않는다고 합니다.

그래서 현재 지원하는 HTML5의 Cheat Sheet를 공개하기로 했고 Final Recommendation 스펙이 나올때까지 업데이트할 예정이라고 합니다.

물론 저도 HTML 5에 대해 기대하는 바가 크고(최근 릴리즈된 Firefox 3.5에서 HTML 5의 일부를 지원하고 있습니다.) 트위터에서도 많은 개발자들이 HTML 5에 대해서 얘기하고 있습니다. 하지만 웹표준의 보급에도 큰 장애가 되고 있는 것과 마찬가지로 일정점유율이상의 브라우저가 지원하기 전까지는 실험적 또는 특수한 경우를 제외하고는 사용하기가 어려운 것이 사실이고 새로운 스펙은 좋고 나쁨을 떠나서 개발자에게 부담되는 것도 사실입니다. 수년이 걸릴거라고는 예상하고 있었지만 2022년까지는 전혀 생각지 못하고 있었네요. 어찌보면 현실적인 예상일 수도 있겠습니다.

어쨌든 HTML은 좋은 스펙이라고 생각하지만 새로운 Needs에 대한 충족을 못하고 있는 것도 사실이기에 HTML5의 성장을 기대해 봅니다.

HTML5 Cheat Sheet Download

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

WEBrick 실행 시 "`require_frameworks': no such file to load" 에러 메시지

(Outsider) — Mon, 06 Jul 2009 23:43:43 +0900

Rails를 공부하면서 Ruby로 짜여진 레일즈의 기본 웹서버인 WEBrick을 실행하려고 하니까 실행이 되지 않고 에러메시지가 떨어졌습니다. WEBrick서버는 아래의 명령어로 실행이 됩니다. 기본적으로는 WEBrick이 실행되고 Mongrel, lighthttpd등이 설치되어 있으면 해당 웹서버가 실행되는 것으로 알고 있습니다.

ruby script/server

이렇게 하면 WEBrick이 실행되고 예제를 따라했어야 했는데 실행되지 않고 아래와 같은 에러메시지가 떨어졌습니다.

outsider@outsider-laptop:~/Sources/Ruby on Rails/demo$ ruby script/server
=> Booting WEBrick
=> Rails 2.3.2 application starting on http://0.0.0.0:3000
/usr/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/initializer.rb:269:in `require_frameworks': no such file to load -- net/https (RuntimeError)
    from /usr/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/initializer.rb:134:in `process'
    from /usr/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/initializer.rb:113:in `send'
    from /usr/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/initializer.rb:113:in `run'
    from /home/outsider/Sources/Ruby on Rails/demo/config/environment.rb:9
    from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.2/lib/active_support/dependencies.rb:156:in `require'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.2/lib/active_support/dependencies.rb:521:in `new_constants_in'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.2/lib/active_support/dependencies.rb:156:in `require'
    from /usr/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/commands/server.rb:84
    from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from script/server:3

자세한 에러메시지를 모르겠지만 `require_frameworks': no such file to load라는 메시자를 뿌리면서 WEBrick 실행에 실패했습니다.

관련 정보 를 찾아보니 위의 에러는 OpelSSL 라이브러리가 없어서 나타난 에러라고 합니다.

sudo apt-get install libopenssl-ruby

apt-get 명령어로 OpenSSL 라이브러리를 설치합니다.(환경은 우분투 9.04입니다.)

이제 WEBrick을 실행하면 기본포트인 3000포트로 실행이 잘 됩니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

댓글 알리미 표준화 캠페인을 지지합니다.

(Outsider) — Tue, 30 Jun 2009 01:07:43 +0900

라지엘 스튜디오 에서 댓글 알리미 표준화 캠페인 이란 것을 진행하고 있는 것을 오늘 알게 되었습니다.

진행된지는 그렇게 오래되지 않은 듯 하지만(댓글 알리미에 대한 표준화에 대한 얘기는 블로고 스피어에서 종종 있었던 것으로 기억하고 있습니다.) 각 포털 블로그(표준화를 얘기하는데 대형포털 블로그가 빠질수는 없죠)에도 제의를 해서 긍정적인 답변을 얻어내고 기술명세서 도 멋지게 작성되어 있습니다.

아시는 분들은 아시다시피 댓글알리미는 테터툴즈, 지금의 텍스트큐브에 들어있는 기능입니다. 제가 다른 텍스트큐브를 쓰는 블로그에 가서 댓글을 남겼는데 누군가 그글에 다시 답변을 달면 내 블로그 관리자를 통해서 답변이 달린 여부를 확인할 수 있는 기능입니다. 블로깅을 하면서 종종 다는 댓글을 다시 찾아가서 글이 달렸나 안달렸나 확인해 보는 건 꼭 답을 봐야하는 질문이 아닌 경우에 거의 어렵습니다. 이런 점은 댓글알리미를 통해서 소통의 길을 더욱 편하게 할 수 있고 더욱 잦은 소통을 통해서 장기적으로 블로그라는 전체파이가 커지는데 일조할 수 있겠죠.(댓글알리미가 정말 좋다고는 생각하고 있었는데 이 기능이 테터툴즈를 처음 시작하신 정재훈님 이 아이디어를 내서 테터툴즈의 초기버전에도 들어있었던 것은 오늘 처음 알게 되었군요.)

얼마나 호환되는지까지는 테스트해보지 않았지만 최근 XE에도 이기능이 들어갔고 GR Blog 도 동참을 했습니다. 뭐 최근에 블로거들 사이에 소통에 대한 자세는 좀 회의감을 가지고 있기는 하지만 그래도 원활한 소통을 지원할 수 있는 툴은 환영할 만한 일입니다.

하루빨리 급속도로 퍼져서 플랫폼에 상관없이 댓글을 주고받을 수 있는 시대가 왔음 좋겠네요. 지지하는 뜻에서 배너를 달았습니다. (사이드바가 점점 무거워지는군요. ㅡ..ㅡ)

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

Thomas Fuchs 새로은 비쥬얼이펙트 라이브러리 : scripty2

(Outsider) — Mon, 29 Jun 2009 01:38:57 +0900

Prototype.js기반의 비쥬얼 이펙트 라이브러리인 Script.aculo.us 를 만든 Thomas Fuchs가 새로운 비쥬얼 이펙트 라이브러리를 만들고 있었네요. scripty2 입니다.

현재 버전은 Alpha1 버전으로 가져다가 적용하기에는 약간 꺼러질만한 버전이긴 합니다. 사이트에는 딱히 명시되어 있지는 않지만 디자인도 그렇고 이름도 그렇고 Script.aculo.us의 후속버전으로 제작하고 있는 것이 아닐까 합니다. 네임스페이스도 S2라는 네임스페이스로 쓰고 있군요. 디자인도 이전 사이트와 거의 동일하고요.

사이트에 나온대로 아직 알파버전이기 때문에 문서화도 많이 부족하고 메서드나 내용도 계속 작성중이라서 아직 완전히 확정된 형태는 아닙니다. script.aculo.us의 개발계획이 어떻게 되는 건지는 잘 모르겠네요.

Scripty2는 크게 scripty2 core, scripty2 fx, scripty2 ui 3가지로 나누어집니다. 아직 문서화도 많이 되어 있지 않은데다가 능력도 안되서 소스까지 분석할 능력은 없습니다. script.aculo.us를 하면서 배운 경험을 가지고 비쥬얼효과와 UI에 대해서만 최적화한 듯합니다.

현재 토마스퍽스가 만든 twistori 와 freckle 에서 쓰이고 있습니다. 저장소는 GitHub 를 이용하고 있고 커뮤니티는 구글 그룹스 를 이용하고 있습니다.

현재 데모는 2가지가 제공되고 있습니다. Cards Demo 와 Puzzle Demo 가 있습니다. 요즘은 비쥬얼 효과가 워낙 많아서 놀랄만한 데모는 아니지만 깔끔하니 괜찮아 보니는군요. 나중에 시간내서 좀 만져봐야겠습니다.

덧) Thomas Fuchs와 Amy Hoy가 이글에 대해서 포스팅한 것을 모르고 있었네요. Amy Hoy의 글 에 따르면 Scripty2는 Script.aculo.us 2가 맞고 Thomas Fuchs의 포스팅 에 따르면 script.aculo.us라는 이름을 좋아하지만 더 외우기 좋은 이름으로 바꾸어야 될 때라는 것에 동의한다고 합니다.(사실 외우기 쉽지 않긴 하죠.. ㅎㅎㅎ) scripty2라는 이름도 앞으로 바뀔수도 있다는군요.
애니메이션을 그래프로 동작타임을 조절하는 데모 는 참으로 맘에 드는군요.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

jQuery로 iPhone스타일의 Checkbox 만들기

(Outsider) — Wed, 24 Jun 2009 02:16:15 +0900

아이폰이 전세계적으로 히트친 뒤로 아이폰의 UI는 하나의 상징이 되어버렸습니다.(요즘도 루머때문에 국내에서 난리죠.)

Thomas Reynolds라는 사람이 jQuery를 이용해서 iPhone스타일의 checkbox를 웹에서 구현할 수 있는 스크립트를 만들어서 공개했습니다. 실제 아이폰의 체크박스처럼 아주 부드럽게 잘 동작합니다.

<script src="jquery-1.3.2.js" type="text/javascript" charset="utf-8"></script>
<script src="iphone-style-checkboxes.js" type="text/javascript" charset="utf-8"></script>
<link rel="stylesheet" href="style.css" type="text/css" media="screen" charset="utf-8" />
<script type="text/javascript" charset="utf-8">
    $(document).ready(function() {
        $(':checkbox').iphoneStyle();
    });
</script>

저는 jQuery는 거의 안만져봤지만 사용법은 아주 간단합니다. jQuery를 인클루드하고 iphone스타일로 바꾸기 위한 Thomas Reynolds의 js파일과 CSS와 이미지 5개면 준비가 끝이고 Dom Ready 콜백에 iphoneStyle()함수를 지정만 해주면 간단하게 실행됩니다.

위 스크린샷처럼 아주 깔끔하게 표현이 됩니다. Thomas Reynolds의 아이폰스타일 체크박스 소개페이지 를 보면 간단한 예제를 볼 수 있습니다. 머 체크박스를 바뀌주는 것이므로 이 이상의 예제도 없기는 합니다. 옵션을 주면 기본인 ON/OFF 메시지 대신 원하는 글자를 표시해 줄 수도 있습니다. 소스저장소 를 보면 처음 소개할때보다 소스가 좀더 나아져서 스타일 class에 대한 지정을 옵션으로 줄 수 있습니다.

가장 좋은 점은 역시 js가 돌아가지 않으면 일반적으로 보는 checkbox를 그대로 볼 수 있기 때문에 접근성에도 문제가 별로 없어보입니다. 전 jQuery를 아직은 안써봐서 이걸 prototype.js기반으로 해볼까 했는데 소스저장소 를 보니까 이미 prototype.js기반으로도 제작중이군요.(아직 제대로 돌아가지는 않습니다.)

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

Ubuntu의 apt-get 명령어 정리

(Outsider) — Tue, 23 Jun 2009 02:52:43 +0900

apt-get(Advanced Packaging Tool)은 우분투(Ubuntu)를 포함안 데비안(Debian)계열의 리눅스에서 쓰이는 팩키지 관리 명령어 도구입니다. 우분투에는 GUI로 되어 있는시냅틱 꾸러미 관리자도 있기는 하지만 이런 저런 개발관련 패키지를 설치할 때는 커맨드기반인 apt-get이 더 편하기도 합니다. sudo는 superuser권한으로 실행하기 위함입니다.

패키지 인덱스 인덱스 정보를 업데이트 : apt-get은 인덱스를 가지고 있는데 이 인덱스는 /etc/apt/sources.list에 있습니다. 이곳에 저장된 저장소에서 사용할 패키지의 정보를 얻습니다.

sudo apt-get update

설치된 패키지 업그래이드 : 설치되어 있는 패키지를 모두 새버전으로 업그래이드 합니다.

sudo apt-get upgrade

의존성검사하며 설치하기

sudo apt-get dist-upgrade

패키지 설치

sudo apt-get install 패키지이름

패키지 재설치

apt-get --reinstall install 패키지이름

패키지 삭제 : 설정파일은 지우지 않음

sudo apt-get remove 패키지이름

설정파일까지 모두 지움

sudo apt-get --purge remove 패키지이름

패키지 소스코드 다운로드

sudo apt-get source 패키지이름

위에서 받은 소스코드를 의존성있게 빌드

sudo apt-get build-dep 패키지이름

패키지 검색

sudo apt-cache serach 패키지이름

패키지 정보 보기

sudo apt-cache show 패키지이름

apt를 이용해서 설치된 deb패키지는 /var/cache/apt/archive/ 에 설치가 됩니다.

Last modified : 2009.06.25

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

Rails에서 입력형식 변경시 유니크값 체크하기

(Outsider) — Sun, 21 Jun 2009 23:14:14 +0900

요즘 Ruby on Rails 온라인 코스를 하면서 보통 Homework의 난이도가 그렇게 높지 않았었는데 이번에는 상당히 어려웠습니다. 물론 이부분은 Ruby에 대해서 배울때는 따로 루비를 공부하고 있었던 탓도 있었고 지금은 Rails는 따로 공부하고 있지 못하고 있어서 이기도 합니다. 어쨌든 그래도 약간 고민하고 있으면 할 수 있었는데 이번에는 장시간동안 고생을 했습니다. Homework와 관련된 것이라 따로 언급하지는 않겠습니다.

어쨌든 레일즈의 Active Record에는 유효성검증을 위해서 제공하는 기능들이 있습니다. 웹개발에서 유효성(Validation) 검증은 필수적이라고 하는데 이걸 편하게 할 수 있도록 validates_라는 이름으로 시작하는 유효성 검증 헬퍼를 제공하고 있습니다. 미리 약속된 이 헬퍼를 사용하면 자동으로 유효성검증을 실행합니다. 또한 이 검증외에 기능을 수행하기 위해서 각 단계별로 콜백함수 또한 제공하고 있습니다. before_validation, before_save같은 함수이고 이걸 정의해 놓으면 해당 단계에서 해당 함수가 실행이 됩니다.

Homewor의 제약조건은 간단했습니다. ActiveRecord에 credit_card라는 컬럼이 있는데 이 컬럼은 유일한 값이어야 하고 입력밧은 0000 0000 0000 0000나 0000-0000-0000-0000의 2가지 형식만 입력받아야 하고 필드에 저장은 0000000000000000와 같은 형식으로 저장이 됩니다. 콜백함수는 before_create, before_save 2가지를 사용해서 구현하는 것이었습니다.

아주 간단하게 생각하면 validates_uniqueness_of로 credit_card를 유니크로 지정하고 validates_format_of를 정의하여 정규식으로 입력형식을 지정해 주면 되는 것이고 before_create, before_save에서 입력받은 형식을 컨버팅해주고 저장하면 되는 것이었습니다. 하지만 막상 구현하려고 하니까 문제가 생겼습니다.

validates_uniqueness_of:credit_card,
    :message=>"credit card is unique."

validates_format_of:credit_card,
    :with=>/[0-9]{4}[-| ][0-9]{4}[-| ][0-9]{4}[-| ][0-9]{4}/,
    :message=>"Invalid credit_card format"

콜백함수인 before_create, before_save보다 validates의 실행시점이 더 빠르기 때문에 validates_uniqueness_of가 실행되는 시점에서는 디비에 들어있는 값들은 입력값의 형식이 변환되었기 때문에 유효성검증의 기능을 전혀 하지 못했습니다. validates_format_of에는 configration option인 실행시점을 바꿀 수 있는 :on이 있지만 :on은 validates_uniqueness_of에는 존재하지 않았습니다. API문서 에도 Rails 2.1에도 나오지 않습니다. 다만 제가 가진 책인 Rails 1.2기반인데 여기서는 :on 옵션이 나와있는데 중간에 없어진 것인지는 잘 모르겠지만 일단 실행시점을 바꾸는 동작을 동작되지 않았습니다.

결국 오랜 고민을 했지만 Unique확인을 유효성 검증 헬퍼가 아닌 콜백함수에서 실행할 수밖에 없었습니다. 제가 선택한건 before_create였습니다. before_save에서 데이터 형식의 변환을 실행하고 before_create에서 변환된 값을 가지고 유일값인지 아닌지를 체크했습니다.

def before_create
    if User.find_by_credit_card(self.credit_card)
        errors.add_to_base("credit_card is not unique")
        return false
    end
end

어쨌든 동작은 원하는대로 되긴 했는데 이게 맞는지도 잘 모르겠습니다.(이래서 좀더 공부를 해야되는데요.. ㅠ..ㅠ) ActiveRecord의 ORM기능을 이용해서 credit_card함수를 현재값으로 Select해서 값이 있을 경우 errors에 오류를 추가하고 false를 반환합니다. errors만 추가할 경우에는 에러만 추가되고 실제 값을 저장하는 것에는 상관이 없었습니다. raise를 이용해서 ActiveRecord의 오류를 발생시키는 것도 시도했었지만 return false를 하는 것만으로도 디비저장을 멈출 수 있었습니다.(저도 정확히 알지 못하는 상태의 포스팅이라 약간은 찜찜하군요. )

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.