델리 키포스

요즘 트위터에 조금 익숙해진 것 같습니다. 아무래도 미투데이와 트위터를 동시에 사용하다보니 분산되긴 하지만 SNS 전체 활동량이 늘어났기 때문에 트위팅 시간도 많이 늘었습니다.  구독(follow)하는 사람들도 조금 늘었고 트윗 개수도 조금씩 늘어가고 있습니다.

몇일전 워드프레스를 2.9.1버전으로 업그레이드 했습니다. 저희 서버는 SFTP를 사용하기 때문에 자동 업그레이드가 실행이 안되서 다소 귀찮지만 수동으로 업그레이드 했습니다.  그나저나 처음에는 SFTP가 마냥 좋은 줄 알았는데 몇가지 단점도 있고해서 FTPS도 한번 고려해봐야 겠네요.

아무튼 워드프레스 업그레이드 하면서 트위터 플러그인도 몇가지 추가해봤습니다. 아무래도 블로그보다는 트위터에 포스팅을 많이 하기 때문에 포스팅이 빈한 블로그를 보완하기 위해 사이드바에 트위터 위젯을 추가했습니다. 처음에는 구글링의 가장 상단에 나오는 Twitter Tools라는 플러그인을 설치했습니다. 그런데 기능이 너무 많고 무거워서 너무 무거운게 제 취향이 아니었습니다.

그래서 Twitter for Wordpress를 설치했는데 기능도 단순하고 옵션도 적당해서 일단 제 마음에는 들었습니다. 하지만 처음 페이지를 렌더링할 때 다소 지연(delay)가 발생합니다. 아마도 트위터로부터 정보를 가져와서 캐싱하는데 시간이 좀 걸리는 것 같습니다. 일단 캐싱되면 빠르게 렌더링이 되지만 거슬려서 다른 플러그인을 찾아보았습니다.

결국 Twitter Wordpress Sidebar Widget이라는 플러그인을 설치했습니다. Twitter for Wordpress보다는 옵션이 부족하지만 렌더링 시간이 거슬릴 정도는 아닙니다. 그런데 트윗한 시각을 ‘2 house ago’ 형식으로 보여주는데 포스팅 시각이 그리 중요한 것 같지는 않아서 php 소스를 살짝 고쳐서 ‘#’로 표시되도록 했습니다.

트위터 위젯은 사이드바 가장 상단에 배치하였습니다. 아무래도 가장 업데이트가 자주 발생하는 정보인 만큼 우선순위를 가장 높였습니다.  그다음 최근 글, 태그, 월별 목록 순으로 위젯을 배치하였습니다. 블로그롤(링크 목록) 위젯은는 트위터 위젯과 다소 중복적으로 우선순위를 낮췄습니다.

그리고 Tweet This라는 플러그인도 설치했습니다. 이 플러그인을 설치하면 글 아래에 ‘Tweet this’라는 버튼이 표시됩니다. 이 버튼을 클릭하면 현재 보고 있을 글을 트위터로 포스팅할 수 있습니다. 그리고 제가 블로그에 포스팅하면 자동으로 트위터에 URL과 제목을 포스팅해주는 기능도 있습니다.

별건 아니지만 그래도 설치해놓고 보니 뭔가 작은 성취감을 느낄 수 있었습니다ㅎ. 당분간은 열심히 트위팅을 할 것 같습니다~

키포스 미분류 워드프레스, 트위터, 플러그인

제 블로그로 들어오는 여러 가지 경로 중 구글을 통해 들어오는 경우를 관심있게 보고 있습니다. 최근에 ‘크롬 맑은 고딕’이라는 키워드로 들어오는 경우가 제법 있었습니다. 아마도 크롬에 맑은고딕을 적용하는 방법을 찾는 사람이 아닐까라고 생각해봅니다.  저도 굴림이나 돋움에 너무 질려서 웬만하면 나눔고딕으로 보고 싶은데 크롬 3.0에는 글꼴 강제 지정 기능이 없어 많이 아쉬웠었습니다.

그런데 오늘 혹시나 하는 마음에 크롬 확장 프로그램(extension)을 찾아보니 userContent라는 확장 프로그램이 있었습니다. 내용을 대충 읽어보니 사용자가 지정한 CSS를 모든 웹 페이지에 적용하는 확장 프로그램인 듯해서 설치를 진행해봤습니다.

우선 2010년 1월 현재 안정 채널(stable channel, 크롬 프로젝트에서는 버전 대신 채널이라는 용어을 사용하고 있네요)은 버전 3.x으로 확장 프로그램 기능을 지원하지 않습니다.  그래서 크롬 프로젝트 홈페이지에 가보니 베타 채널과 개발 채널을 설치할 수 있더군요. 아무래도 베타 채널이 조금 더 안정적이기 때문에 베타 채널을 설치했는데 다행이 베타 채널(ver 4.0)은 확장 프로그램을 지원하더군요.

그리고 userContent 확장 프로그램을 설치했습니다. 아직 사용자 CSS를 지정하지 않았기 때문에 웹 페이지를 열어도 아무런 변화가 없었습니다. ‘도구 메뉴 > 확장 프로그램’을 선택하면 확장 프로그램 페이지가 열리고 userContent 항목의 옵션 버튼을 클릭하면 사용자 CSS 입력 페이지가 열립니다.

* { font-family : ‘나눔고딕’ !important; }

편집 창에 위 내용을 입력한 후 저장합니다. 그러면 크롬으로 여는 모든 페이지에 나눔고딕이 적용됩니다. 당연한 얘기지만 PC에 나눔고딕이 설치되어 있어야 합니다.

CSS 구문을 간단하게 살펴보면 *는 전체 선택자(universal selector)이며 해당 구문은 모든 엘리먼트(element)에 나눔고딕을 글꼴로 적용해라는 내용입니다. (만약 맑은고딕을 적용하려면 ‘나눔고딕’ 대신 ‘맑은 고딕’이라고 입력합니다.)  !important는 사용자 스타일의 우선 순위를 높게 합니다. 기본적으로 제작자(author)가 지정한  스타일이 사용자 스타일보다 우선 순위가 높습니다. 그러나 !important가 선언된 스타일의 경우 사용자 스타일이 더 높은 우선 순위를 갖게됩니다. 그래서 제작자 지정한 글꼴은 무시되고 사용자 지정한 나눔고딕이 웹 페이지에 적용됩니다.

* { font-family : sans-serif !important; }

사용자 스타일을 위에 내용으로 저장하면 브라우저에서 지정한 산세리프체 글꼴이 페이지에 적용됩니다. 이 방법은 사용자 지정 글꼴을 변경할 때 CSS 구분을 직접 편집하는 않고 브라우저가 지원하는 옵션 기능을 이용하기 때문에 CSS 문법에 익숙하지 않은 사용자들이 쉽게 사용할 수 있습니다. 사용자 지정 글꼴을 변경하려면 ‘기능 메뉴 > 옵션 > 고급설정 > 언어와 글꼴’에서 변경할 수 있습니다.

파이어폭스도 좋은 브라우저이긴 하지만 개인적으로 빠른 랜더링과 UI의 간결함 때문에 크롬을 더 좋아합니다. 그러나 지금까지는 크롬에 글꼴을 강제하는 기능이 없어 파이어폭스를 메인 브라우저로 사용하고 있었습니다. 하지만 크롬 4.0부터는 사용자 스타일 지정할 수 있기 때문에 더이상 크롬을 메인 브라우저로 사용하지 않을 이유가 없습니다. 크롬 좋아요~!

키포스 미분류 css, 글꼴, 나눔고딕, 맑은고딕, 사용자스타일, 크롬, 폰트

최근 관심을 갖고 틈틈히 공부하고 있는 것이 REST(Representational State Transfer)입니다. REST는 아키텍처 스타일이라고 할 수 있는데 레일스 2에서 REST를 처음 접하게 되었습니다. 아키텍처 레벨은 REST를 기반으로 구현 레벨은 MVC로 설계가 잡히면서 프레임웍이 훨씬 더 짜임새 있어 보였습니다.

좁은 의미에서 REST는 ROA(Resource-Oriented Architecture)라고 볼 수 있습니다. 마치 객체 지향에서 모든 것을 객체(클래스)로 정의하 듯이 ROA에서는 서비스내에 의미를 가질만한 요소들을 리소스(resource) 단위로 정의합니다. 그리고 리소스가 의미를 가지기 위해서는 리소스의 이름이 필요하며 그 이름을 URI라고 합니다. 참고로 URI와 URL은 같은 걸로 보면됩니다.

그런데 리소스만으로는 서비스의 모든 URI를 표현할 수 없습니다. 모든 내용이 그 내용을 보여주는 형식을 필요로 하듯이 리소스도 리소스를 보여주는 형식이 필요합니다. 리소스를 보여주는 형식을 리프리젠테이션스(representaions)라고 합니다. 그리고 URI는 리소스와 리프리젠테이션의 조합으로 만들어집니다. 예를 들어 레일스에서 아래와 같은 URI 관례가 있습니다.

• /orders
• /orders/1
• /orders/new
• /orders/1/edit

‘/orders’과 ‘/orders/1′처럼 리소스만으로 표현된 URI가 있는가 하면 ‘/orders/new’와 ‘/orders/1/edit’처럼 리소스와 리프리젠테이션이 조합으로 구성된 URI도 있습니다.

일반적으로 리소스를 대상으로 할 수 있는 기본적인 조작(operation)은 몇가지 정해져 있습니다. 흔히 이것들을 CRUD(Create, Read, Update, Delete)라고 하며 레일스에서 정해놓은 CRUD 관련 URI는 아래와 같습니다.

• List : GET /orders
• Create Form : GET /orders/new
• Create : POST /orders
• Read : GET /orders/1
• Update Form : GET /orders/1/edit
• Update : PUT /orders/1
• Delete : DELETE /orders/1

여기서 주목할만 것은 Create, Update, Delete의 경우 별도의 URI를 갖지 않으며 리소스 URI를 요청하는 방식(method)를 달리 가져갔다는 점입니다. 리소스를 GET으로 요청하면 해당 리소스의 리프리젠테이션을 기대하게 되며 리소스를 POST로 요청하면 해당 새로운 리소스를 추가합니다. 마찬가지로 리소스를 PUT으로 요청하면 해당 리소스를 수정하는 것이며 DELETE 방식으로 요청하면 삭제하는 것을 의미합니다.

이러한 기본 규칙을 통해서 URI는 통일성을 가지게 됩니다. 그리고 이 통일성을 좁은 의미에서 RESTful이라 할 수 있습니다. 나아가 이러한 통일성은 개발 효율로 이어집니다. 새로운 서비스의 API를 접할 때 그 서비스가 RESTful하다면 URI의 기본 규칙이 동일하기 때문에 API 학습량이 줄어들기 때문입니다. 아마도 이러한 점이 관례를 중시하는 레일스가 적극적으로 REST를 도입한 이유가 아닐까 싶습니다.

그런데 서비스 기능 중에는 기본적으로 정의된 CRUD 이외의 것들이 있을 수 있습니다. 예를 들어, 단순하게 주문 목록을 보여주는 기능을 List라 하고 목록과 달리 주문과 주문 품목을 함께 보여주는 기능을 Inquiry라고 정합니다. 이때 Inquiry 리프리젠테이션의 URI는 아래와 같이 2가지로 생각해볼 수 있습니다.

• GET /orders?view=inquiry
• GET /orders/inquiry

앞에 것은 쿼리스트링에 리프리젠테이션(view) 정보를 넘기는 경우이며 뒤에 것은 URI에 리프리젠테이션을 명시한 경우입니다. 사실 어느 것으로 하던 상관은 없다고 봅니다. 다만 앞의 것의 경우 List와 Inquiry가 동일하게 주문 목록을 보여준다는 쪽에 무게를 실은 반면에 뒤에 것은 둘이 서로 다른 리프젠테이션이라는 것을 조금 더 명시적으로 표시한 것입니다. 저희 팀의 경우 뒤에 방식을 선택했는데 사용자들이 보기에 List과 Inquiry은 서로 다른 페이지라고 느낄 것이라고 판단했기 때문입니다.

지금까지 REST를 공부하면서 익혔던 것들을 정리해보았습니다. 참고로 RESTful Web Services을 보고 있는데 아직 중간 쯤 읽은 상태라 정리한 내용 중에 틀린 부분이 있을 수도 있으니 기회가 되면 덧글 좀 남겨주세요~

키포스 미분류 rest, restful, uri, url, 레일스