13 May 2014

요즘 문래빗에서는 “판타지x러너즈2”의 일본 출시를 준비하고 있는 중이다. 순조롭게 준비 중이지만 개인적으로는 한가지 불편한 점이 있었다. 퍼블리셔인 Nexon Japan에서 사용하는 BTS가 Noss라는 자체 제작한 것으로 보이는 웹 프로그램인데, 아래와 같은 문제점들이 있다.

  1. 담당자를 지정하는 기능이 없다.
  2. 검색 기능이 빈약하다. 옛날 게시판처럼, title/content/작성자등 타겟을 지정하고 검색하는 방식이다.
  3. 필터 기능이 빈약하다. 예를 들어 Complete된 이슈는 숨기고 남은 이슈들만 볼 수가 없다.

이러한 문제들 때문에 내가 어떤 이슈를 처리해야하고, 남은 이슈가 어떤 것이 있는 지 파악하는 것이 무척이나 힘들다. 당장 임시로 매니징을 맡고 있는 나도 파악이 안되는데, 이슈에 대응해야하는 입장에서는 더욱 난감할 것 같았다. 새삼스럽게 redmine이 얼마나 좋은 툴이었는지 느낄 수 있었다.

불편함이 있으면 개선이 필요한 법. Noss를 주기적으로 모니터링하면서 새로 작성되거나 변경된 이슈들을 기존에 사용하던 redbooth 쪽에 동기화해주는 python 스크립트를 작성하기로 했다.

requests

우선 시작은 Noss에서 데이터를 가져오는 것부터 시작하기로 했다. python의 urllib2를 사용해서 가져오려고 했으나, Noss가 계정 인증을 위해 쿠키를 사용하다보니 귀찮은 부분이 있었다. 그래서 편리하게 Noss에 로그인하고 데이터를 가져오는 방법을 찾아보기로 했다.

그래서 찾은 것이 python 모듈인 ‘requests‘이다. ‘requests’는 ‘HTTP for Human’을 표방하는 HTTP 클라이언트 라이브러리이다. 실제로 python 기본 urllib 모듈 시리즈보다 사람이 직관적으로 사용하기 편리한 형태였다. 아래는 사용 예이다.

>>> r = requests.get('https://api.github.com/user', auth=('user', 'pass'))
>>> r.status_code
200
>>> r.headers['content-type']
'application/json; charset=utf8'
>>> r.encoding
'utf-8'
>>> r.text
u'{"type":"User"...'
>>> r.json()
{u'private_gists': 419, u'total_private_repos': 77, ...}

파라미터를 넣어 http request를 하는 것도 상당히 편리하다.

>>> payload = {'key1': 'value1', 'key2': 'value2'}
>>> r = requests.get("http://httpbin.org/get", params=payload)

가장 마음에 드는 부분은 session object였다. session object는 같은 session object를 사용하는 request 전반에 헤더와 같은 파라미터들과 cookie를 유지시킬 수 있도록 도와준다.

s = requests.Session()

s.get('http://httpbin.org/cookies/set/sessioncookie/123456789')
r = s.get("http://httpbin.org/cookies")

print(r.text)
# '{"cookies": {"sessioncookie": "123456789"}}'

내 용도에 딱 맞는 기능이었다. 쿠키 유지시키는 등의 처리가 귀찮아서 편하게 사용할 모듈을 찾았던 것이니까. session object를 사용하면 마치 웹브라우저를 사용하듯이 http request에 대한 처리를 쉽게 짤 수 있었다.

Beautiful Soup

http request를 하고, response를 받는 것까지는 requests를 사용하여 손쉽게 해결했다. 하지만, html을 분석하고 원하는 정보를 가져오는 것은 별도의 문제이다. 특히, Noss는 오래전에 개발되었는지 각 태그에 class 속성을 지정해주는 경우가 거의 없었다. 이런 상태라면 원하는 데이터만 가져오는 것도 상당히 귀찮은 문제가 될 것 같았다.

당연히, 이런 상황에서 사용할만한 모듈이 있을 것이라는 생각에 구글링해보니까 바로 beautiful soup이 나왔다. beautiful soup은 손쉽게 html과 xml 파일에서 원하는 부분을 검색하고, 수정할 수 있는 모듈이다. requests와 마찬가지로 지금 용도에는 딱 맞는 모듈이었다.

예를 들어, input 태그 중 ‘idx’라는 name과 ‘hidden’이라는 type을 가진 태그를 찾으려면 아래와 같이 코딩하면 된다.

soup.find('input', {'name': 'idx', 'type': 'hidden'})['value']

위와 같은 방식으로 쉽게 html 페이지로부터 원하는 정보만 가져올 수 있었다. 특히, Noss 같은 경우 HTML에 하드 코딩된 style들이 많았는데, beautiful soup에서는 아래처럼 편하게 검색이 가능했다.

cell.find('td', style='border-right:#DEDEDE 2px solid;padding-top:5;', valign='top')

만약 직접 html tree를 분석하는 경우에는 꽤나 귀찮았을 것이다.

상당히 유명한 모듈인지, 지금 보니 한국어 문서도 있다.

05 May 2014

GitHub Pages는 예전부터 알고는 있었지만, 오픈 소스 프로젝트의 페이지나 웹 프론트엔드(HTML, css, javascript 등)으로만 구성된 개인 페이지에서만 쓰이는 줄 알고 있었다. 그런데 지난주 금요일(14.05.02)에 Spoqa Tech Blog를 읽다 보니, Pages 서비스에서 제공하는 Jekyll을 사용하면 블로그를 만들 수 있다는 사실을 뒤늦게 알게 되었다.

GitHub Pages을 활용해 개설된 블로그에서는 markdown 파일을 직접 작성하여 포스팅하고, git으로 버전 관리를 한다는 것이 신선했다. GitHub의 위키도 그런 식으로 사용하고 있지만 블로그도 그렇게 사용할 수도 있다는 것에 대해서는 생각도 안 해봤었다. 보통 블로그는 각 블로그 서비스에서 웹으로 제공되는 에디터를 사용하여 글을 작성한다. 버전 관리는 지원하는 경우가 드물며, 지원하더라도 빈약하다. 반면, GitHub Pages를 활용하여 블로그를 개설하면 로컬에서 원하는 텍스트 에디터로 자유롭게 작성하고 git의 강력한 버전관리 능력을 활용할 수 있다. 프로그래머에게는 상당히 매력적인 조건이었다.

안 그래도 머지않아 회사 사이트도 만들어야 하고, 연습하는 겸 GitHub Pages로 블로그를 개설해보기로 했다. 프론트엔드만 만들면 되니까 금세 만들겠지. 밋밋하게 직접 css를 만들고 간단하게 html을 작성해서 만드는 것도 나쁘지는 않겠지만, designmodo에서 만들어 제공하는 Flat UI를 사용해보고 싶으니까 사용해보기로 했다. 비싼 돈 주고 Pro를 구매해놓고도 사용 안 하고 있는 게 아깝기도 하고.

결국,오늘 몇시간정도 투자하여 그럭저럭 봐줄만한 블로그가 만들어졌다. GitHub Pages와 Jekyll는 워낙 간단하고 투명한 녀석들이라 딱히 고생할 것은 없었고, 오히려 내가 웹 프론트 엔드 경험이 거의 없다보니 css와 html에서 삽질을 좀 했다. 만들어보니까 적은 학습으로도 자신만의 블로그를 만들 수 있다는 점이 상당히 괜찮았다.

장점과 단점

장점

  1. markdown으로 글을 작성할 수 있다.
  2. 원하는 텍스트 에디터를 사용할 수 있다.
  3. git의 강력한 버전관리 능력을 활용할 수 있다.
  4. 툴 사용이 자유롭다. (원하는 패턴을 grep 해본다던가…)
  5. 보안이 강력하다. (모든 페이지는 static한 페이지, 어드민 페이지가 없음)
  6. 구성이 자유롭다.
  7. 무료이다.

단점

  1. 관리자 페이지가 없다.
  2. 쉽게 가져다 쓸 수 있는 스킨이 없다.
  3. 웹에서 글 수정이 번거롭다.
  4. 포스트를 보여주는 기본적인 기능 외에는 기능이 없다.
  5. 검색 기능이 없다.

결론

프로그래머들을 위한 서비스인 GitHub 다운 서비스이다. vim, emacs, sublime등으로 글을 작성하고, git으로 글을 게시할 수 있는 블로그가 필요하다면 GitHub Pages로 블로그를 구성하는 것 외에는 방법이 없을 것 같다. 비 프로그래머들은 애초에 타겟이 아니니, 사용할 이유도 없다.

10 Feb 2014

책 정보

스틱! 커버

  • 원제: Made to stick : why some ideas survive and others die
  • 저자: 칩 히스, 댄 히스
  • 역사: 안진환, 박슬라 옮김
  • 출판사: 엘도라도

소개

한국인 중에 “선풍기를 틀고 자면 죽는다”(일명 Fan Death)라는 도시전설을 모르는 사람은 거의 없을 것이다. 과학적 근거가 없는 도시전설임에도 불구하고 이 메시지는 끈질기게 살아남았다. 아직도 수많은 사람들이 무더운 열대야에 선풍기를 켜고 자는 것에 대한 공포를 가지고 있다. 반면, 고등학교 시절 급훈같은 메시지는 기억에 잘 남지 않는다. 1년 동안 교실 한구석에서 볼 수 있었던 메시지임에도 불구하고 고등학교 1학년 때 급훈은 잘 기억나지 않는다.

우리는 평소에 어떤 메시지를 많이 사용할까? 물론 흥미위주의 잡담이나 가십거리를 이야기할 때는 전자처럼 잘 달라붙는 메시지를 사용하는 경우가 많을지 모른다. 하지만 그보다 더 중요할지도 모르는 학교나 직장에서의 이야기들은 어떨까? 특이한 경우가 아니라면 고등학교 교훈처럼 포스트잇처럼 잘 떨어지는 메시지들로 이루어지는 경우가 대부분일 것이다.

그럼 어떤 차이 때문에 어떤 메시지는 끈끈하게 잘 달라붙고, 또 어떤 메시지는 지루하고 빠르게 잊혀지는 것일까? 흥미로운 메시지는 태어날 때부터 흥미롭고, 그렇지 못한 메시지는 가망이 없는 것일까?

서문에 따르면, 스틱!은 “도시 괴담처럼 말도 안 되는 아이디어로부터 교훈을 얻고 그 교훈을 활용해 보다 유용하고 고귀한 스티커 아이디어를 만들 수 있게 하고 싶었기 때문”에 쓰여진 책이다. 잘 달라붙는 메시지에 대한 책인 만큼, 책 또한 머리 속에 잘 달라붙는다. “부동산을 사기 위해 왜 선거 결과를 기다릴까?”나 “판결을 뒤집은 스타워즈 칫솔”등 제목만 봐도 호기심이 생기는 사례들도 흥미를 더해준다.

© Song Jaehak. All rights reserved. Powered by GitHub Pages