YY

오래전에 LaTeXing in Mac (with TextMate) 라는 글에서 TextMate와 Skim을 이용한 LaTeX 논문작성 환경을 소개했습니다. 그런데 저는 정작 이 환경을 이제는 이용하지 않고 있습니다. 제가 요새 이용하는 환경을 소개합니다.

TextMate의 한계

TextMate는 훌륭한 편집기지만, 맥에서만 사용 가능하고, 자유 소프트웨어가 아니며, 개발이 수년간 정체되어 있습니다. 2006년에 안정 버전 1.5가 출시되었고 2009년에 2.0이 곧 출시된다는 예고가 등장했지만, 버전 2.0은 아직도 소식이 없습니다.

Vim

TextMate가 가져온 편리한 기능들은 그 사이 다른 편집기에 반영되었습니다. Vim 진영에서는 macvim이 활발히 개발되고, pathogen, NERDTree, snipMate 등 훌륭한 플러그인들이 등장하여 TextMate와 비슷한 환경을 구축하는 게 가능해졌습니다. 자연스럽게, 많은 개발자들이 Vim으로 이주하기 시작했습니다. 최근 vim을 다룬 블로그 글이 늘어나는 것도 이런 흐름을 반영하는 게 아닌가 싶습니다. 저도 원래 Vim과 TextMate를 함께 써 왔지만, 작년 Steve Losh의 Coming home to vim, Vincent Driessen의 How I boosted my Vim 같은 글을 보다가 결국 Vim으로 이주를 결행했고, 현재 아주 만족하고 있습니다. Vim을 본격적으로 써 보고 싶으신 분은 제가 Vim을 사용하기 시작하면서 정리한 자료를 참고하시면 아마 도움이 되실 겁니다.

Make

컴퓨터 과학자들과 논문을 함께 쓰면서 여러 가지를 배웠는데, 그 중 하나가 GNU Make의 유용성입니다. 그림을 그리는 gnuplot 스크립트나 TeX 컴파일 명령들을 Makefile로 조직해 놓으면 매번 그림을 다시 그리고 논문을 컴파일하는 번거로움 없이 make 한번으로 최신 버전의 결과물을 얻을 수 있습니다. 사실 make가 그런 일에 쓰라고 만들어놓은 물건인데 전 논문 작성할 때 쓰면 된다는 생각은 못하고 있었죠.

TextMate 환경은 latexmk.pl을 사용합니다. LaTeX에 최적화된 Make 유틸리티라고 보시면 되는데, 무척 편리하긴 하지만 저는 그냥 간단한 Makefile을 만들어 사용하는 게 편하더군요. 논문을 작성할 때 TeX 컴파일만 하는 게 아니라 gnuplot으로 그림도 그리고 PDF 결과물들을 합치기도 하는데 latexmk만 쓰는 건 한계가 있습니다. 아주 기본적인 Makefile은 대략 다음과 같습니다. make를 실행하면 편지 (cover letter), 논문 본문, 기타 자료 (supporting material) 이렇게 세 개의 PDF 결과물을 만들고 이걸 하나로 합쳐주게 됩니다.

monex.py

Vim과 make의 조합에만 익숙해져도 꽤 편한 작업이 가능합니다. 하지만 매번 make를 실행하는 건 여전히 귀찮죠. 어떻게 하면 자동화를 할 수 있을까 고민하다가 예전에 봤던 autotest 가 생각나 monex.py라는 짤막한 스크립트를 하나 만들었습니다. 이 스크립트가 하는 일은 무척 단순합니다. 주어진 파일들을 감시하다가 파일이 변경되면 주어진 명령어를 실행하는 거죠.

결과물을 Preview에 띄워놓고, 다음과 같이 실행해 놓으면,

$ python monex.py -c "make all" *.tex *.bib *.plt 

파일을 저장할 때마다 알아서 그림을 그리고 컴파일해서 결과물을 갱신 해 줍니다. 이걸 만들어 놓으니 논문 쓸 때뿐만 아니라 여기저기 쓸모가 있더군요. 이 글을 보시는 분들에게도 유용할까 싶어 여기에 붙입니다. (혹시 더 좋은 방법을 알고 계시면 알려주세요. :)

(Tip via James Bagrow)

TeX distribution

먼저 TeX은 가장 널리 쓰이는 배포본인 MacTeX이 정답이다. 가장 깔끔한 관리가 가능하고, Bibdesk나 ghostscript등 유용하고 필요한 패키지들이 알아서 설치된다.

TextMate

MacTeX에 포함된 TeXShop도 훌륭한 편집기지만, 아무래도 TextMate의 강력한 편집기능과 자유로운 번들 기능과는 비교가 힘들다. TextMate의 문제는 기본 LaTeX 번들이 시원찮다는 것인데, 현재 개발중인 LaTeX 번들을 아래와 같이 따로 설치하는 것으로 해결이 된다.

• http://github.com/textmate/latex.tmbundle 에서 download source를 선택해서 다운받고 압축을 푼다.
• 압축을 풀면 만들어지는 폴더 이름을 .tmbundle로 끝나도록 바꾸어주면, 폴더가 하나의 아이콘으로 변한다.
• 아이콘을 더블클릭해서 설치.

Skim

컴파일 결과물 (PDF) 를 보는 용도로는 Skim이 쓸만하다¹. 보통 논문을 작성할 때, 결과물과 소스 사이를 수없이 오고가는데, 이때 PDF의 특정 위치가 TeX 파일의 어느 위치에 해당하는지를 알 수 있어야 한다. 그래서 나온 것이 SyncTeX인데, Skim이 이걸 지원한다².

Skim을 설치하고 나서 TextMate LaTeX 번들 환경설정에서 skim을 기본 뷰어로 설정해준다. 환경설정에 Latexmk.pl라는게 있는데, 이 스크립트는 결과물을 모니터하면서 bibTeX과 LaTeX을 번갈아 돌려주는 스크립트다. LaTeX - BibTeX - LaTeX - LaTeX 의 번거로운 과정 없이 한번의 컴파일 명령으로 최종 결과물을 얻을 수 있다.

사용방법

이제 TextMate에서 command + R 을 누르면 컴파일을 해 준다. command + control + W 은 'watch' 기능이다. 누르면 컴파일한 결과물을 보여주는데, TeX 파일을 수정하고 저장하면 알아서 PDF를 갱신해준다. Skim에서 command + shift + 클릭 을 하면 TeX 파일에서 해당되는 부분으로 이동한다.

각종 자동완성과 편리한 기능들은 TextMate의 LaTeX 번들 메뉴를 참고.

---

유쾌한 멀티라이터:아이폰으로 그린 멋진 작품들!

터치스크린을 무엇에 쓸까? 먼저 생각나는 용도 중 하나는 '그림판'이다. 아이폰 출시 이후 여러 그림판 프로그램들이 등장했는데 대부분은 낙서 프로그램들에 가깝고, 진지한 프로그램은 'Brushes'와 'Colors!' 정도이다. 아이폰의 조그만 스크린에 얼마나 대단한 걸 그릴 수 있을까 싶지만, 위에 링크한 글에 걸려 있는 그림들 ('Brushes' 이용) 과 'Colors'의 갤러리를 보고 나면, 실력을 갖춘 사람들에게 도구는 중요하지 않음을 다시 한 번 깨달을 수 있을 것이다. 뭐 사람들이 싸이월드의 조그만 그림판이나 윈도우즈 그림판에서도 잘만 그리는 걸 보면 그렇게 놀랄 일은 아니다.

도구의 관점에서 두 프로그램은 큰 차이가 없다. 하지만 'Colors'의 경우 모든 붓질이 그림 안에 저장되어, 그림을 그리는 과정을 다시 돌려볼 수 있다. 게다가 그림을 공개 갤러리에 올리는 것도 가능하고 다른 사람들이 올린 그림을 내려받아 그림을 그리는 과정을 돌려보는 것이 가능하다. 'Colors' 갤러리에서 그림을 클릭하면 과정을 구경할 수 있다. 아이폰이나 터치에 공짜로 'Colors! Lite'를 내려받으면 공개 갤러리에 올라온 그림들의 과정을 바로 구경할 수 있다. 은근히 재미있다. 그리고, 유료 풀 버전을 사면 그림을 저장할 수 있게 된다(!).

아이폰으로 가장 많이 방문하는 웹사이트는 http://www.google.com이다. 아이폰에서 구글 홈페이지로 접속하면 메일, 달력, 리더등을 편하게 이용할 수 있다. 각 프로그램들의 모바일 버전들은 꽤 훌륭하게 만들어져 있고, 기본 화면이 이들을 잘 묶어주고 있다.

나는 그 중에서도 구글 리더를 가장 많이 사용하는데, 그래서인지 불편한 점들이 여럿 보인다.

첫째, 자주 다운된다. 특히 사진이 많고 긴 글을 읽다보면 '앗, 왠지 다운뙬 것 같은데!'라고 느끼는 순간이 있고, 이럴때면 종종 브라우저가 죽는다. 사실 이건 꼭 구글리더의 문제라기보다는 아이폰, 그리고 아이폰에 들어간 사파리의 문제라고 볼 수도 있다.

그러나, 구글 리더의 책임은 브라우저가 죽었다 살아난 이후에 있다. 구글리더에서 일단 클릭한 글은 읽은 것으로 간주되고 다시 구글리더가 떴을 때 보이지 않는다. 그래서 막 흥미로운 글을 읽으려던 찰나에 브라우저가 죽으면, 'all items'를 클릭해서 찾아가거나 귀차니즘으로 몸부림치며 그 글을 포기해야 한다. 나는 보통 후자로 귀결되며 많은 스트레스를 받는다. 이건 탭 브라우징을 지원하는 웹브라우저에서 실수로 탭을 닫았을 때 그 탭을 복구하는 기능이 없는 것과 비슷한 상황이다. 마지막에 닫은 탭을 복구해주는 기능을 브라우저들이 다 갖춰가는 것처럼 RSS 리더도 브라우저의 다운이나 독자의 실수에서 비롯된 '방해받은 읽기'를 복구해 줘야 할 책임이 있다. 그리고 이 책임은 매우 간단하게, 리더를 열 때마다 마지막으로 읽은 글 몇 개를 항상 리스트에서 보여주는 것으로 실현이 가능하다고 본다.

이 기능은 비슷한 또다른 문제도 해결해준다. 구글 리더에서 'see original'을 클릭하면 새 창에 원본을 보여준다 (구글 리더 옵션으로 원본을 모바일 버전으로 바꾸어서 열어주는 훌륭한 기능도 있다). 문제는 글을 다 읽고 '별표 해야지~' 혹은 '공유 해야지!'라고 생각하며 구글 리더로 돌아왔을 때 생긴다. 아이폰에 담긴 사파리는 열려 있는 웹 페이지를 항상 저장하고 있지 않는다. 많은 경우, (기준은 잘 모르겠지만) 각 창들은 주소만 기억하고 있다가 유저가 돌아왔을 때 다시 그 주소를 열어준다. 이 때문에 '별표 해야지~'라고 생각하며 돌아온 나를 맞이하는 것은 다시 로드된 – 아무것도 모른채 웃고 있는 – 새로운 구글 리더인 경우가 잦다. 그러면 나는 다시 귀차니즘으로 몸부림치며 스트레스를 받는다.

둘째, 버튼이 너무 작다. 각 포스트의 하단에는 '공유', '노트와 함께 공유', '이메일', '읽지 않은 것으로 표시'등 중요한 버튼들이 자리하고 있는데, 우리가 아무리 궁극의 포인팅 디바이스인 손가락을 가지고 태어났다고 한들, 이런 조그만 버튼을 매번 정확하게 클릭하기는 쉽지 않다. 게다가 버튼과 다음 포스트 사이에는 공간도 없어서 'share'를 누르려다가 다음 포스트를 눌러버리는 경우가 허다하다. 바로 다음 포스트가 리사이즈 안한 백 장의 사진이 담긴 여행기라면 상황은 바로 위에 토로한 첫째 문제로 돌아간다. 이 작디 작은 링크들은 오리지날 구글 리더를 단순히 모바일 버전으로 변환하면서 주의를 기울이지 않아 그대로 남은 것 같은데, 조금 더 큼직큼직한 아이콘으로 바뀌고 다음 포스트와의 사이에 공간도 조금 넣어주었으면 하는 소박한 바램이 있다. 손가락으로 쓰윽 쓰다듬으면 수백 픽셀 우습게 넘어가는 아이폰이니 세로 길이에 너무 집착할 필요 없다.

셋째, '별표하기'는 위에만, 나머지는 아래에만. '별표하기'는 가장 원초적인 기능이기에 특별대우를 받는 건 불만이 없는데, 포스트 아래쪽에도 '별표하기' 버튼이 없는 건 불만이다 (데스크탑용에는 있다). 포스트의 길이가 짧을 때는 큰 차이가 없지만, 상당히 긴 포스트의 경우에는 불편을 초래한다. 예를 들어, 별표를 하지 않은 채로 엄청난 분량을 다 읽고 났더니 반드시 별표를 해야 할 것 같은 글이 있다면? 정답: 다시 글의 맨 위를 찾아 올라간다. '별표하기'가 아닌 다른 기능들은 반대 상황에 처해 있다. 예를 들어 클릭해보니 엄청 긴 글인데, 당장 읽기는 싫고 공유를 해야 한다면? 누군가에게 이메일을 보내야 한다면? 정답: 글의 맨 밑으로 찾아가서 '공유/이메일'을 클릭해야 한다. gmail에서 '보관', '삭제'등의 버튼들이 위와 아래에 모두 자리하고 있는 것처럼 이런 기능 버턴들은 양쪽에 자리해주면 좋겠다.

넷째, 왜 포스트 정렬 옵션이 꼴랑 'auto'뿐인가. 사실 이건 구글 리더 전체에 대한 가장 큰 불만이다. 포스트의 적절한 정렬은 구글 검색결과를 정렬하거나 아마존에서 책을 추천해주는 것과 같이, 독자가 원하는 글을 우선적으로 제시해 줌으로써 환상적인 경험을 선사할 수 있는 가능성을 가지고 있다. 구글 리더로 넘어올때도 '정보의 흐름'을 적절히 정렬해준다는 개념이 맘에 들었고, 곧 강력한, 개인화된 글 추천 기능을 제공하지 않을까 하는 기대에 부풀어 있었는데, 꽤 오랜시간이 지나도록 'newest', 'oldest', 'auto'뿐이다. 전체적인 인기를 가지고 정렬할 수도 있고, 친구들 사이에서 인기있는 글 순으로 정렬을 할 수도 있고, 내가 좋아하는 성향의 글을 파악해서 정렬을 할 수도 있고, 각 포스트당 하루에 올라오는 글의 수를 제한할 수도 있고, 등등, 정말 많은 옵션들이 가능한데 아무것도 발표를 안 하고 계신다. (물론 지금도 사내에서는 여러가지 알고리즘들을 테스트하고 있다고 믿는다. -_-+ )

글을 쓰고 보니 새삼 구글에 종속된 웹 생활을 하고 있다는 생각이 든다. --;

텍스트큐브 1.6이 발표되어 설치했습니다. 많은 기능들이 추가되고 개선되었지만, 그 중에서도 새로운 포매터로 마크다운(Markdown)이 들어간 것이 제게는 가장 의미있는 변화입니다. Markdown은 텍스트로부터 html을 만들어내는데 쓰이는 마크업 언어입니다. 워드프레스에서 텍스트큐브로 이전하면서 가장 아쉬웠던 것이 바로 Markdown에 대한 지원이었는데 이번 업데이트로 해갈이 됐습니다.

위지(윅|윔) 편집기 vs. 마크업 언어

html(xml) 문서를 직접 입력하는 것은 몹시 괴로운 일입니다. 그래서 웹문서를 만들어주는 툴들(위키, 블로그)은 위지윅 편집기를 제공하거나 마크업 언어를 제공합니다.

스프링노트처럼 'what you mean'을 표현함으로써 보이는 모습과 의미를 일치시키려는 노력은 계속되고 있긴 하지만, 위지윅이든 위지윔이든 '결과물'을 바로 편집할 수 있게 하는 편집기는 태생적 한계를 가지게 됩니다. 사용자들이 겉모습이 아니라 안에 들어있는 구조를 보게 하려면 사려깊은 디자인이 필요하고, 사용자의 무심한 듯 시크한 입력에 숨은 의도를 간파하려면 똑똑한 프로그램이 필요합니다. 이렇게 인간의 횡포에 맞서 아름다운 DOM tree를 보존하려면 프로그램은 필연적으로 무거워지고, 버그도 많아지게 됩니다.

반면, 마크업 언어의 경우, 익숙해지기까지 시간은 조금 걸리지만, 조금만 노력해서 문법을 배우게 되면 매우 가벼운 편집기로 쉽고 빠르게, 의도한 대로의 문서를 작성할 수 있고, 쉽게 수정할 수 있으며, 키보드 만으로 문서를 작성할 수 있습니다. 번역기도 복잡할 필요가 없습니다. 게다가 plain-text 기반이므로 네트워크에 접속되어 있건 말건, 어떤 컴퓨터를 쓰고 있던간에 문서를 작성하는게 가능합니다.

위지윅, 위지윔 편집기들이 점점 발전하면서 마크업 언어의 장점을 희석시키고 있고, 위지윅 편집기가 진작부터 세상을 지배하고 있긴 하지만, 저는 아직 마크업 언어가 더 좋습니다.

Markdown

위키를 오래 써 왔기 때문에 위키에서 쓰이는 모인모인, 미디어위키 문법이 가장 익숙함에도 불구하고, 제가 가장 훌륭하다고 생각하는 html 마크업 언어는 Markdown입니다.

Markdown은 쉽고 직관적입니다. Markdown으로 작성된 문서는 그 자체로 잘 만들어진 plain-text 문서입니다. Markdown 소개 페이지도 역시 Markdown으로 작성되었는데, 소스와 결과물을 한 번 비교해 보시기 바랍니다.

Markdown의 제작자인 John Gruber의 홈페이지에서 Markdown의 철학을 옮겨보겠습니다.

Markdown:Philosophy (강조는 제가)

Markdown is intended to be as easy-to-read and easy-to-write as is feasible.

Readability, however, is emphasized above all else. A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters — including Setext, atx, Textile, reStructuredText, Grutatext, and EtText — the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.

To this end, Markdown’s syntax is comprised entirely of punctuation characters, which punctuation characters have been carefully chosen so as to look like what they mean. E.g., asterisks around a word actually look like emphasis. Markdown lists look like, well, lists. Even blockquotes look like quoted passages of text, assuming you’ve ever used email.

Markdown 문법은 이메일 용법에서 가져왔으며, 따라서 이메일에 익숙한 사람들은 바로 이해할 수 있습니다.

홍민희님이 Markdown의 링크 문법이 얼마나 자연스러운지를 잘 설명해주셨는데, 저도 Markdown의 문법 중에서 가장 마음에 드는 것이 링크 문법입니다. 괄호안에 링크를 넣는 자연스러움, 마치 논문을 쓸 때처럼 링크에 이름을 붙여 반복적으로 사용할 수 있고 링크들을 한 곳에 모아놓고 인용할 수 있다는 점은 정말 최고입니다. 이런 훌륭한 문법은 참고 링크를 더욱 쉽게 달 수 있게 해주고, 그래서 긴 글이나 많은 자료를 인용한 글을 쓸 때 위력을 발휘합니다.

Markdown이 제공하는 문법은 textile같은 언어와 비교하면 초라해 보이지만, 블로그 포스트같은 단순한 문서를 만들 때는 이게 오히려 장점이 됩니다. 어짜피 다른 html 요소들이 필요하면 그냥 html을 그대로 쓰면 되니까요.

태터툴즈나 텍스트큐브를 쓰시는 분들은 1.6으로 업그레이드하셔서 Markdown을 꼭 한 번 써보시길 바랍니다. :)

참고

• Markdown
• Wikipedia: Markdown
• textile

Ruby on Rails를 세상에 널리 알린 것은 DHH 이 녹화해서 보여준 "15분만에 블로그 만들기"라는 스크린캐스트입니다. 이후 다른 프레임워크들도 스크린캐스트를 적극적으로 이용하기 시작했고, 여기저기서 수많은 스크린캐스트가 만들어졌습니다.

홍보수단으로서의 스크린캐스트는 일종의 짜고치는 고스톱입니다만, 학습 도구로 쓰일 경우 꽤 유용합니다. 스크린캐스트로 만들어진 여러 RoR 튜토리얼을 제공하고 돈을 받는 peepcode라는 서비스도 등장했고, 프로그래밍 비디오팟캐스트들도 생겨나고 있습니다 (왠지 자연스럽게도 대부분 레일스 & 코코아 관련 팟캐스트입니다).

그 중에서도 가장 돋보이는 팟캐스트는 Ryan Bates가 진행하는 Railscasts입니다. 이 팟캐스트는 무척 성실하게 나옵니다. 2007년 3월에 시작했고, 지금까지 88개의 에피소드가 나왔습니다. 각각의 에피소드가 짤막짤막하면서도 충실합니다. 혹시 모르고 계셨다면 한 번 구독해보셔도 좋습니다. :)

coderpath라는 재미난 팟캐스트도 있습니다. Miles K. Forrest가 '코더의 길'을 걷기 위해 개인교습을 받으며 그 과정을 스크린캐스트로 제공합니다. 근데, 이 개인교습을 DHH, Amy Hoy, Ryan Bates같은 사람들이 해 줍니다. ㅎㅎ

defaultdict는 파이썬 2.5 버전부터 collections에 새로 추가된 자료형입니다. dictionary대신 쓰면 좋습니다. 아실만한 분들은 다들 아시겠지만, syntaxhighlighter 테스트도 해볼겸 올립니다. ㅎㅎ

디폴트값을 지정해 줄 수 있는 루비의 Hash같은 역할을 합니다.

> a = Hash.new(0) > a[1]+=5 > a[2]+=1 > a[1]+=1 > a => {1=>6, 2=>1}

보통 네트워크 구조를 가지고 뭘 할때, 전 네트워크 구조를 dictionary로 저장합니다. 각 노드들이 key가 되고 그 노드들의 이웃 노드들의 set이 value가 되는 dictionary죠. a라는 노드에서 b라는 노드로 향하는 링크를 만드려면

net = {} def addLink(net, a, b): if net.has_key(a): net[a].add(b) else: net[a] = set([b])

이렇게 하면 됩니다. python 2.5가 나오기 전에는 setdefault()를 쓰면 if문을 없애고 좀 더 깔끔하게 할 수 있었습니다.

net = {} def addLink(net, a, b): net.setdefault(a, set([])).add(b)

하지만 가장 깔끔하고 빠른 방법은 defaultdict를 쓰는 것입니다.

import collections net = collections.defaultdict(set) def addLink(net, a, b): net[a].add(b)

데이터로부터 분포를 얻을 때도 유용하게 쓰일 수 있습니다.

from collections import defaultdict distribution = defaultdict(int) def add(distribution, n): distribution[n] += 1

참고

• openlook:파이썬 모듈 관광 4회: 기본제공 자료구조 겉핥기!
• 파이썬마을:텍스트 파일에서 한글의 자음과 모음의 갯수
• 파이썬마을:알파벳을 찾아내는 함수

Gruff는 이쁜(루비스런?) 그래프를 그려주는 라이브러리이다. 광우병에 대해 썼던 글의 그래프가 바로 Gruff로 그린 것이다.  Gnuplot처럼 다재다능하지는 않지만, 한글로 라벨을 넣기도 쉽고 코드 몇 줄로 꽤 보기좋은 그래프를 얻을 수 있다.

• RMagick
  

  • Installation FAQ
    
  • 리눅스에서 인스톨하기
    
• Gruff
  

RMagick 설치

RMagick은 다른 gem들에 비해 설치가 좀 까다롭다(고 한다.) Installation FAQ을 먼저 훑어보고, 권장하는 FreeType, libjpeg, libpng, libwmf, ghostscript등의 패키지를 먼저 설치한다.

데비안의 경우 RMagick이 패키징 되어 있어서 apt(dselect)를 이용하여 RMagick을 쉽게 설치할 수 있다.

1. apt-get install librmagick-ruby
   

Gruff 설치

1. gem install gruff

여기 있는 예제를 실행했을 때 png파일이 잘 생기는 지 확인해본다. 소스를 보면 사용법이 정말 쉬움을 알 수 있다. 객체를 만들고 타이틀과 레이블 지정하고, 데이터를 넣어주면 끝이다.

테마

Gruff는 미리 만들어놓은 몇 가지 테마를 메쏘드로 제공한다. 데이터를 넣기전에 이들 메쏘드를 호출하면 색들을 조정해준다. 'keynote', '37signals', 'rails_keynote', 'odeo'등의 테마를 제공한다. 'keynote' 테마를 선택하면 사람들이 키노트로 그렸다고 생각한다. ㅎㅎ

물론 직접 설정하는 것도 가능하다. 테마는 'colors', 'marker_color', 'background-color'들로 구성된다. 'colors'는 데이터를 그리는 색상들이고, 'marker_color'는 보조선의 색상, 'background-color'는 그라데이션으로 그려주는 배경 색상이고, 이런 색상들을 정해서 Array로 넣어주면 된다.

근데 데이터 색상의 경우, 'data'함수를 이용하여 데이터를 넣을 때 색상이 지정되므로, 이후에 테마 메쏘드를 실행하더라도 데이터 색상은 바뀌지 않는다. 그러므로 데이터를 넣기 전에 색상 설정을 끝내놓는게 좋다.

레일즈에서 쓰기

그림만 보여주는 메쏘드를 쓰려면 이 튜토리얼을 참고하면 된다. 그림을 웹사이트 안에 삽입하려면 컨트롤러에서 파일을 저장하고 뷰에서는 그 파일을 읽어서 보여주도록 하면 될 것이다. (캐싱을 적절히...)

한글

한글을 쓰려면 한글 ttf 폰트의 경로를 'font' 메쏘드로 지정해야 된다.

이 글은 스프링노트에서 작성되었습니다.

• yy's wiki:OpenID
  
• yy's wiki:RubyOnRails
  

해봤더니 기본적인 기능은 무척 쉽게 작동시킬 수 있었다.

설치

먼저 openid_login_generator를 설치한다. 이건 login_generator의 openid버전이고 login_generator와 거의 똑같은 방법으로 쓸 수 있다고 한다.

1. gem install openid_login_generator

생성기를 실행한다.

1. ./script/generate openid_login auth

다음과 같은 파일들이 생성된다.

1.      create  lib/openid_login_system.rb
        create  app/controllers/auth_controller.rb
        create  test/functional/auth_controller_test.rb
        create  app/helpers/auth_helper.rb
        create  app/models/user.rb
        create  test/unit/user_test.rb
        create  test/fixtures/users.yml
        create  app/views/layouts/scaffold.rhtml
        create  public/stylesheets/scaffold.css
        create  app/views/auth
        create  app/views/auth/welcome.rhtml
        create  app/views/auth/login.rhtml
        create  app/views/auth/logout.rhtml
        create  README_LOGIN
   

'README_LOGIN' 파일에 필요한 것들은 거의 기록되어 있다. 열어서 따라한다. 애플리케이션 콘트롤러 ('app/controllers/application.rb')를 열어서 다음과 같이 보이도록 바꾼다.

1. require_dependency "openid_login_system"
   
   class ApplicationController < ActionController::Base
     include OpenidLoginSystem
     model :user
   

테이블 만들기

'app/models/user.rb'파일은 만들어져 있지만, db에는 아무것도 없기 때문에 users 테이블을 추가해야 한다. user.rb를 열어보면 이런 메쏘드 딱 하나가 있다.

1. def self.get(openid_url)
     find_first(["openid_url = ?", openid_url])
   end
   

users 테이블에 'openid_url'라는 컬럼만 만들어주면 openid login이 작동한다. migration을 하나 만들어서 테이블을 만들어 준다.

1. class InitialSchema < ActiveRecord::Migration
     def self.up
        create_table "users" do |t|
         t.column "openid_url", :string
         t.column "name", :string
         t.column "email", :string
   
2.      end
   
3.   end
   
4.   def self.down
   
5.     drop_table "users"
6.   end
   

이제 마이그레이션을 실행하고

1. rake db:migrate
   

편한 툴로 테이블이 잘 만들어졌는지 본다.

뷰 손보기

이제 http://localhost:3000/auth/login 으로 접근하면 로그인폼이 나올 것이다. 근데 오픈아이디 로고도 없고 영 멋이 없다. 먼저 뷰를 모범답안으로 수정한다. app/views/login.rhtml의 input 태그를 다음처럼 바꾼다.

1. <input type="text" name="openid_identifier" class="openid_login" size="30" value=""/><br/>
   

name 속성을 바꾸었으니 컨트롤러('auth_controller.rb')를 열어서

1. @params[:openid_url]

를

1. @params[:openid_identifier]

로 고쳐준다.

그 다음에 'public/stylesheets/scaffold.css'나 아니면 자신의 레이아웃에서 사용하는 css파일에 다음을 추가한다.

1. input.openid_login {
      background: url(http://openid.net/login-bg.gif) no-repeat;
      background-color: #fff;
      background-position: 0 50%;
      color:#000;
      padding-left: 18px;
   }
   

이제 다시 페이지를 열어보면 폼이 이뻐졌을 것이다. ㅎㅎ

사용하기

사용은 간단하다. 접근을 제한하고 싶은 컨트롤러에다가

1. class SomeController < ApplicationController
     before_filter :login_required
   

라고 써 주면 된다. 메쏘드별로 접근을 제한하고 싶으면 :only, :except를 쓸 수 있다.

1. before_filter :login_required, :only => [:myaccount, :changepassword]
   before_filter :login_required, :except => [:index]
   

현재 사용자의 아이디는

1. @session[:user_id]
   

에 저장되어 있다. 예를 들어

1. user = User.find(@session[:user_id])
   

이런 식으로 사용하면 된다.

이 글은 스프링노트에서 작성되었습니다.

구글 북스에 인용 기능이 생겼다. 내용을 볼 수 있는 책일 경우, 일부분을 크롭해서 이미지로 바로 링크를 할 수 있다. 게다가 크롭한 부분의 텍스트도 인용할 수 있다. +_+ 물론 공개되어 있는 책에서만 쓸 수 있는데다가 OCR도 아주 정확하지는 않기 때문에 당장의 활용도는 그렇게 높지 않겠지만, 왠지 밝은 미래를 상상하게하는 기능이랄까...

예제는 TechCrunch에서 볼 수 있다.

텍스트큐브를 깔아보았다. 오픈아이디도 기본으로 들어갔네. 속도도 빠르고 좋다. 일단 전체적으로 만족스러움. +_+