Skip to main content

웹2.0에 관심이 생기다.

[bookcover:8995527625(웹 2.0 시대의 기회 - 시맨틱 웹)]

"웹 2.0 시대의 기회 - 시맨틱 웹"이라는 책을 읽고 갑자기 웹2.0에 관심이 생겼다. 아니 뭔가 재밌는 것을 찾았다고 할까? 회사에서 몇년째 하고 있는 한 프로젝트에 질린건지 자꾸 다른 것에 관심이 간다.

책을 읽고 책에서 언급한 사이트들을 방문하여 사용해보기로 하고 오늘 여러 사이트를 방문하여 사용해 보았는데 다음이 그 리스트들이다.
  1. del.icio.us
  2. Technorati
  3. Bloglines
  4. Feedburner
  5. Flickr
  6. Flock
1~5번까지를 방문하고는 사실 별 감흥이 없었다. 그저 책에서 자주 언급되던 태그들이 여기저기 사용되고 있구나, 잘 만들었구나 하는 정도였다. 사실 Gmail의 Label 기능을 사용하면서도 Category처럼 하나의 메일에 하나의 Label만 적용해야 되는건줄 알만큼 태그에 무지했었다. 태그의 편리함은 TatterTools의 태그 클라우드를 사용하면서 알게 된 정도였다.

하지만 마지막 Flock 사이트를 방문하여 Flock 브라우저를 설치하고 "Flock User's Guide" 문서를 따라하면서 이거 정말 장난 아닌데 라는 생각이 들었다. Flock 브라우저는 위에서 언급한 del.icio.us를 브라우저의 북마크 저장소로 사용하고 Flickr와 연동하여 사진 업로드 및 검색을 할 수 있으며 이글을 쓰고 있는 WordPress와 같은 툴들과 연동하여 브라우저내에서 Blog 글을 작성할 수 있게 해준다. 눈치채셨겠지만 이글이 TatterTools가 아닌 WordPress로 쓰이고 있는 이유가 바로 이 때문이다.

Flock을 사용하면서 앞으로는 한 사이트가 모든 것을 다 하는 포탈들보다 각자 자기만의 전문 분야에서 최고의 기능을 제공하고 이 기능을 다른 툴들과 연동될 수 있도록 인터페이스(Open API)를 제공하는 사이트들이 힘을 얻겠다는 생각이 들었다. 위에서 언급한 사이트들은 이미 서로 연동 기능을 제공하고 있다. 예를 들어 Technorati에서 태그를 검색하다가 같은 태그를 가진 사진들을 Flickr에서 볼 수 있는 등의 기능이다.

가족중심의 홈페이지 ((Memory Carrier)) 외에 개인적인 글들을 적어보고자 TatterTools를 사용해 페이지를 하나 열었으나, TatterTools과 같이 아직 다른 툴들과의 연동 기능이 미흡한 툴을 사용해서는 시대의 흐름(?)을 따라잡기 어렵겠다는 생각이 들어 오늘부터는 Wordpress를 사용한 "Idea thinKing" 라는 이름으로 이 페이지를 개설하였다. 어쨌든 최신 기술들을 생활속에서 사용하면서 몸에 익히는 것이 좋을것 같다는 생각이다.

개인적으로 홈페이지에 있는 것 ((Memory Carrier :: Map))처럼 Google Maps API를 다른 사람들도 자신의 Blog에 쉽게 넣을 수 있고 다른 사람들과 지역 정보를 공유하도록 하는 툴을 만들어보려고 했는데 여기에 태그나 Open API와 같은 아이디어도 좀 더 생각해서 넣어 보기로 했다.

추가

참고로 현재 쌍둥이들의 사진을 찍어 계속 PC에 저장하다보니 백업이나 용량에 관한 문제로 고민하고 있었는데 Flickr의 유료 옵션을 보니 1년에 $24.95로 한달 2GB의 업로드 트래픽과 무제한 용량을 제공한다고 한다. 이정도면 거의 하루에 100MB 가까운 사진을 저장할수 있다는 얘긴데 무척 끌리는군... 조만간 결재해버릴지도 모르겠다.

하루만에 Flock이 자기는 Developer Preview 버전이라는 것을 강조라도 하듯 내 셋팅을 모두 날려버렸다. :-( 5월내에 정식베타 버전이 나온다고 하니 그때까진 FireFox로 참는수밖에...

Comments

Popular posts from this blog

1의 개수 세기 - 해답

벌써 어제 말한 내일이 되었는데 답을 주신 분이 아무도 없어서 좀 뻘쭘하네요. :-P 그리고 어제 문제에 O(1)이라고 적었는데 엄밀히 얘기하자면 O(log 10 n)이라고 적었어야 했네요. 죄송합니다. ... 문제를 잠시 생각해보면 1~n까지의 수들 중 1의 개수를 얻기 위해서는 해당 숫자 n의 각 자리의 1의 개수가 모두 몇개나 될지를 구해서 더하면 된다는 사실을 알 수 있습니다. 예를 들어 13이라는 수를 생각해 보면 1~13까지의 수에서 1의 자리에는 1이 모두 몇개나 되는지와 10의 자리에는 모두 몇개나 되는지를 구해 이 값을 더하면 됩니다. 먼저 1의 자리를 생각해 보면 1, 11의 두 개가 있으며 10의 자리의 경우, 10, 11, 12, 13의 네 개가 있습니다. 따라서 2+4=6이라는 값을 구할 수 있습니다. 이번엔 234라는 수에서 10의 자리를 예로 들어 살펴 보겠습니다. 1~234라는 수들 중 10의 자리에 1이 들어가는 수는 10, 11, ..., 19, 110, 111, ... 119, 210, 211, ..., 219들로 모두 30개가 있음을 알 수 있습니다. 이 규칙들을 보면 해당 자리수의 1의 개수를 구하는 공식을 만들 수 있습니다. 234의 10의 자리에 해당하는 1의 개수는 ((234/100)+1)*10이 됩니다. 여기서 +1은 해당 자리수의 수가 0이 아닌 경우에만 더해집니다. 예를 들어 204라면 ((204/100)+0)*10으로 30개가 아닌 20개가 됩니다. 이런 방식으로 234의 각 자리수의 1의 개수를 구하면 1의 자리에 해당하는 1의 개수는 ((234/10)+1)*1=24개가 되고 100의 자리에 해당하는 개수는 ((234/1000)+1)*100=100이 됩니다. 이들 세 수를 모두 합하면 24+30+100=154개가 됩니다. 한가지 추가로 생각해야 할 점은 제일 큰 자리의 수가 1인 경우 위의 공식이 아닌 다른 공식이 필요하다는 점입니다. 예를 들어 123에서 100의 자리에 해당하는 1의 개수는 ((123/1...

CodeHighlighter plugin test page.

This post is for testing CodeHighlighter plugin which uses GeSHi as a fontifier engine. ((Those code blocks are acquired from Google Code Search .)) ((For more supported languages, go CodeHighlighter plugin or GeSHi homepage.)) C++ (<pre lang="cpp" lineno="1">) class nsScannerBufferList { public: /** * Buffer objects are directly followed by a data segment. The start * of the data segment is determined by increment the |this| pointer * by 1 unit. */ class Buffer : public PRCList { public: Buffer() { ++index_; } PHP (<pre lang="php" lineno="4">) for ($i = 0; $i $value = ord( $utf8_string[ $i ] ); if ( $value < 128 ) { // ASCII $unicode .= chr($value); } else { if ( count( $values ) == 0 ) { $num_octets = ( $value } $values[] = $value; Lisp (<pre lang="lisp">) ;;; Assignment (define-caller-pattern setq ((:star var fo...

Coverity Prevent - 소스 코드 검사 도구

이번에 회사에서 소스 코드 검사 도구를 하나 구입하는데 이것저것 비교해본 결과 Coverity Prevent 라는 툴이 가장 좋아 이걸로 결정했다고 하더군요. 간단히 말하자면 Lint 처럼 소스 코드에 대해 static analysis를 하는 도구입니다. 그래서 시험삼아 돌려본 결과를 보게 되었는데 그 품질이 정말 놀랍군요. 메모리 릭이나 초기화하지 않은 변수, 버퍼 오버런, null 체크등등 거의 정확하게 에러를 보고해 줍니다. 다음은 전체 코드에서 발견된 문제점들을 리스트 형태로 보여주는 화면입니다. 정말 많군요. ;-) 다음은 이중 하나의 에러를 자세히 보기 위해 선택하여 들어간 화면입니다. 소스 코드에 라인번호와 에러가 발생한 위치, 에러가 발생할 수 있는 조건들을 자세히 보여줍니다. 정말 '와우!'입니다. 각 함수와 같은 이름들을 클릭하면 그 함수로 바로 이동할 수 있습니다. 사용해보니 개인적으로는 purify 같은 runtime 검사 도구보다 더 맘에 드는군요. 사실 Lint 계열의 도구들은 한번도 사용해본 적이 없는데 다른 것들도 한번 구해다 써봐야겠습니다. 이 툴의 유일한 문제는 비싸다는 것이랍니다. :-)