본문 바로가기

전체 글

[JS] encode 함수 비교

2009. 10. 1.
encodeURI () 함수  

문자열을 유효한 URI(Uniform Resource Identifier)로 인코딩합니다. 문자가 기본 문자의 소규모 그룹에 속하지 않은 경우 전체 URI를 모든 문자가 UTF-8 이스케이프 시퀀스로 인코딩된 문자열로 변환합니다.

다음 표에서는 encodeURI 함수를 통해 UTF-8 이스케이프 시퀀스로 변환되지 않는 기본 문자 세트 전체를 보여 줍니다.

인코딩되지 않는 문자
0 1 2 3 4 5 6 7 8 9
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
; / ? : @ & = + $ , #
- _ . ! ~ * ' ( )
encodeURIComponent () 함수  

문자열을 유효한 URI 구성 요소로 인코딩합니다. 문자가 기본 문자의 매우 작은 그룹에 속하지 않은 경우 URI의 하위 문자열을 모든 문자가 UTF-8 이스케이프 시퀀스로 인코딩된 문자열로 변환합니다.

encodeURIComponent() 함수는 URI 구성 요소라고 하는 URI 문자열 부분에만 사용된다는 점에서 encodeURI() 함수와 다릅니다. URI 구성 요소는 구성 요소 분리 기호(: / ; 및 ? )라고 불리는 특수 문자 사이에 나타나는 모든 텍스트입니다. URI 구성 요소의 일반적인 예로는 "http" 및 "www.adobe.com"이 있습니다.

이 함수와 encodeURI() 사이의 또 다른 중요한 차이점은, 이 함수에서는 URI 구성 요소를 처리하는 것으로 가정하므로 특수 분리 기호 문자(; / ? : @ & = + $ , #)가 인코딩 대상인 일반 텍스트로 취급된다는 점입니다.

다음 표에서는 encodeURIComponent 함수를 통해 UTF-8 이스케이프 시퀀스로 변환되지 않는 문자를 모두 보여 줍니다.

인코딩되지 않는 문자
0 1 2 3 4 5 6 7 8 9
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
- _ . ! ~ * ' ( )
escape () 함수  

매개 변수를 문자열로 변환하고 URL 인코딩 형식으로 인코딩합니다. 이때 영숫자가 아닌 문자는 대부분 % 16진수 시퀀스로 바뀝니다. URL 인코딩 문자열에 사용된 퍼센트 기호(%)는 이스케이프 문자를 시작하는 역할을 하며 모듈러스 연산자(%)와 다릅니다.

다음 표에서는 escape() 함수를 통해 이스케이프 시퀀스로 변환되지 않는 문자를 모두 보여 줍니다.

인코딩되지 않는 문자
0 1 2 3 4 5 6 7 8 9
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
@ - _ . * + /



출처 : http://manacle.egloos.com/4776614

'프로그래밍' 카테고리의 다른 글

[Eclipse] JadClipse Plug-in (Decompiler)  (1) 2009.10.14
[JS] encode 함수 비교  (0) 2009.10.01
개발자의 심리학  (2) 2009.10.01
RFC3852 - Cryptographic Message Syntax(CMS)  (0) 2009.07.30

태그

댓글 0

개발자의 심리학

2009. 10. 1.

개발자는 어떤 사람일까? 개발자는 과학자에 속한다는 사람도 있고, 엔지니어에 속한다는 사람도 있고, 예술가에 속한다는 사람도 있다. 개발자는 지적인 작업으로 새로운 것을 창조하기 때문에 예술가에 가깝다. 그럼 이러한 예술가들을 어떻게 이해해야만 잘 관리할 수 있을까? 지금부터 그에 대한 내용을 알아보자.

 

개발이라는 작업은 고도의 집중력을 필요로 한다. 개발자가 개발하기 위해서는 명명규칙, 공통 API, 디자인 패턴, DB 테이블 구조, 성능, 상호 인터페이스 등등 많은 내용들을 머릿속에 장전하고 개발을 시작해야 한다.

 

개발자의 직업병

 

이 러한 내용이 머릿속에 제대로 장전되지 않으면, 오류가 생기거나 개발 속도가 떨어진다. 한 가지 일에 집중해야 하는 직업 특성상 개발자를 주변에서는 내성적인 사람이라고 오해하기도 한다. 하지만 그들 성격이 내성적이기 때문에 그런 것이 아니라, 정신의 에너지를 내부에 집중해야 하기 때문에 다른 사람이 볼 때 그렇게 보이는 것이다.

 

개발자들은 숲을 보기보다는 나무를 보는 경향이 있으며, 작은 것에 민감하게 반응한다. 또한 자기 관심 분야에는 굉장한 열정을 보이지만 다른 분야에는 관심을 보이지 않는다. 모든 개발자가 그런 것은 아니지만, 외부에서 개발자를 보는 인식은 대체로 위와 같다.

 

개 발자는 자기 자신과 일을 가장 많이 한다. 타인과 같이 일하는 시간보다, 자기 자신과 대화하면서 일하는 시간이 많다. 그러다 보니 다른 사람과의 커뮤니케이션 기술이 부족한 경우가 많아서 함께 일하는 데 원활하지 못한 경우가 있다.

 

그 런데 개발자라고 처음부터 내성적이고, 커뮤니케이션이 부족한 사람은 아니었을 것이다. 직업 특성상 자기 자신과의 싸움을 오랫동안 외롭게 하다 보니 그렇게 된 것이다. 개발자와 함께 일하는 관리자와 이해 관계자들은 이러한 개발자의 특성을 잘 이해해야만 프로젝트를 성공적으로 수행하는 데 유리하다.

 

개발자의 무아지경

 

개 발자가 고도의 집중 상태에 빠져드는 것은 마치 ‘무아지경’과도 같다(영어로는 ‘in the zone’ 또는 ‘flow’라고 한다). 한번 이런 상태에 빠지면 굉장한 속도로 개발을 해 나간다. 개발자의 생산성이 최대가 되는 순간이다. 그런데 한 가지 안타까운 것은 이 상태가 너무나도 쉽게 깨져 버린다는 것이다. 한 예를 들어보자.

 

개발자가 열심히 무아지경에 빠져서 개발하고 있는데, 갑자기 고객으로부터 전화가 왔다. 개발자는 전화를 받자마자 고객으로부터 짜증 섞인 목소리를 들었다.

 

고 객은 온갖 짜증을 내면서 이따위 시스템 못 써먹겠다고 불평불만을 쏟아낸다. 이 순간 개발자의 무아지경 상태는 깨졌고, 이를 다시 회복하는 데에는 많은 시간이 소요될 것이다. 머릿속에 장전해 놓은 각종 명명규칙, 공통 API, 디자인 패턴, DB 테이블 구조, 성능, 상호 인터페이스 등등 많은 내용이 순식간에 언로드(unload)되고 고객의 짜증섞인 불만 내용이 머릿속에 로딩(loading)된다.

 

이를 다시 끄집어내고(unload) 다시 무아지경에 빠지기 위해 명명규칙, 공통 API, 디자인 패턴, DB 테이블 구조, 성능, 상호 인터페이스 등의 내용을 다시 장전하기 위해서는 정신 상태부터 치유해야 한다. 갑자기 고객으로부터 온갖 욕을 얻어먹은 개발자는 정신 치유를 위해 담배를 피우던지, 음악을 듣던지 하는 휴식 시간이 필요하다.

 

그런데 프로젝트 막바지에 다다라서 시간이 촉박하고 깐깐한 관리자를 만났다면 그나마도 못한다. 정신적인 쇼크 상태에서 개발을 지속하다 보면 많은 오류를 양산하게 되고, 향후 고객으로부터 다시 한 번, 이 시스템 못 써먹겠다는 소리를 듣는 악순환이 이어진다.

 

낮에는 이해 관계자들의 전화에 시달려 일을 하지 못한 개발자는 드디어 모두 퇴근한 밤이 되어서야 자기 자신만의 시간을 가질 수 있었다. 밤새 무아지경에 빠져서 수정사항을 다 고친 후에야 퇴근했다. 그런데 다음날 아침 9시에는 관리자가 프로젝트 진행 상태를 점검하기 위해 이해 관계자와 함께 하는 회의 시간을 잡아 놓았었다.

 

관리자와 이해 관계자는 아침 9시에 모여서 회의가 시작되기를 기다리는데, 개발자는 아직 출근도 안했다. 관리자는 개발자가 어제 몇 시에 퇴근했는지 모르는 채, 그리고 왜 야근을 해야 하는지도 모르는 채, 매일 지각 출근한다고 이미 불만이 많았다.

 

고객은 아침 9시부터 불러놓고 회의도 안 한다면서 관리자를 독촉하기 시작했고, 관리자는 연신 휴대폰을 부여잡고 개발자에게 전화를 한다. 드디어 아침 10시가 되어 개발자가 나타나자, 관리자는 그동안 참았던 모든 불만을 다 쏟아냈다. 이를 묵묵히 듣고 있던 개발자는 끊었던 담배를 다시 피워야만 했다. 그렇게 프로젝트는 진행이 되었고, 그래도 끝을 보게 되었다.

 

드디어 프로젝트 종료보고를 하던 어느 날 그 개발자는 홀연히 사라져 버렸다. 그가 어디로 갔는지 아는 사람은 없었다. 혹자는 그가 머리를 깎고 중이 되었다는 사람도 있고, 그가 공사장에서 트럭 몰고 있는 모습을 봤다는 사람도 있고, 이민을 갔다는 사람도 있고, 다들 추측만 난무했다.

 

위는 실제 사례는 아니지만, 현장에서 얼마든지 있을 수 있는 사례다. 개발자는 고도의 집중상태에 한번 빠지면 엄청난 생산성을 낼 수 있지만, 아쉽게도 이 상태는 외부의 충격에 의해 쉽게 깨져버린다. 그런데 이 무아지경 상태는 context switching(문맥 변화)이 일어나는 상태에서만 깨진다.

 

컴퓨터에서 프로세스나 스레드가 바뀔 때 context switching이 일어난다. 하나의 CPU는 한 번에 하나의 작업만 할 수 있기 때문에, 여러 작업을 동시에 하기 위해서는 작업이 바뀔 때마다 context switching을 해서 작업을 진행하기 위한 기본적인 내용을 CPU 레지스터에 로딩해야만 한다. 사람의 두뇌도 이와 유사해 비슷한 일을 계속하는 경우에는 context switching이 일어나지 않는다.

 

개 발자가 개발하는 중간에 지금 무슨 일을 하고 있는지 묻는 질문은 context switching을 일으키지 않는다. 하지만 위의 사례처럼 고객의 전화를 받는 작업은 context switching을 일으킬 수 있는 작업이다. 개발자는 과학자도 엔지니어도 아니다. 자기 자신과의 싸움에서 새로운 것을 창조해 내야 하는 예술가인 것이다. 그런 예술가를 마치 하나의 기계 부속품인 것처럼 고장나면 교환하면 된다고 간주하거나, 통제를 많이 하면 할수록 더 일을 잘 한다고 생각한다면, 개발자의 업무 특성을 잘 이해하지 못한 것이다.

 

무아지경에 빠지기 위한 환경

 

유명한 개발자 사이트인 DevX(www.devx.com)에 보면 Bryan Dollery가 2003년에 쓴 ‘개발의 심리학 이해’라는 글이 있다(www.devx.com/DevX/Article/11659). 이 글에 보면 개발자가 무아지경에 빠지는 것을 돕는 세 가지 방법이 나와 있다.

 

- 적절한 정신적 격리 상태를 제공할 것
- 창의적인 에너지를 재충전할 수 있는 적절한 시간을 제공할 것
- 이치에 맞는 특별한 요구를 수용해줄 것

 

개 발자가 정신적으로 집중할 수 있도록 방해되는 주변 환경을 차단해야 한다. 한 예로 수정사항이나 요구사항은 개발자가 직접 듣는 것이 아니라 관리자가 일괄 취합해서 우선순위를 정해 개발자에게 전달하는 것이 전체 프로젝트의 생산성을 높이는 데 도움이 된다.

 

개 발자가 개발에 집중할 수 있도록 주변 환경을 조성해 주는 것이 관리자로서 해야할 첫 번째 임무인 것이다. 두 번째는 개발자가 중복된 실수를 하지 않도록 그들에게 적절한 휴식시간을 제공해 주어야 한다는 것이다. 무아지경 상태에 다시 빠질 수 있도록 적절한 휴식이 필요하기 때문이다. 세 번째는 개발자들이 원하는 특별한 요구사항이 있다면 수용해주라는 것이다.

 

긍정 심리학 분야의 세계적인 대가인 시카고 대학의 칙센미하이(Csikszentmihalyi) 교수는 노벨상 수상자 또는 뛰어난 과학자들의 심리 상태를 연구해 몰입(flow)에 대한 많은 책을 썼다. 특히 우리나라에도 소개된 ‘몰입의 즐거움’, ‘몰입의 경영’ 등을 통해 ‘몰입 이론’으로 세계적인 명성을 얻었다.

 

그가 인용한 한 유명 컴퓨터 과학자는 자신이 샤워를 할 때 가장 많은 아이디어가 떠올랐다고 한다. 그러던 그가 한 회사에 취직을 했는데, 그 회사는 샤워 부스를 제공하지 않았다. 그 이후 그는 새로운 아이디어가 떠오르지 않아서 그만 두었고 샤워부스를 제공해 주는 다른 회사로 옮겼다. 그랬더니 거기에서는 많은 아이디어가 떠올라서 일을 계속 할 수 있었다고 한다.

 

여기에서 샤워부스는 개발자의 특별한 요구사항에 속하는데, 아마 우리나라의 환경에서는 개발자 1명을 위해 샤워부스까지 만들어 주기는 어려울 것이다. 그것보다는 개발자들이 무아지경(몰입)에 다시 쉽게 빠질 수 있도록 적절한 휴식 공간을 제공해 주는 것이 더 좋은 방법이다.

 

개발자는 멀티태스킹 기계가 아니다

 

조 엘은 그의 블로그의 ‘개발자는 멀티태스킹 기계가 아닙니다(Human Task Switches Considered Harmful)’라는 글에서 개발자에게 두 가지 일을 동시에 시키지 말라고 했다. 위에서 언급했듯이 개발자가 개발을 하기 위해서는 한 가지 일에 집중해야 한다.

 

그런데 두 가지 일을 한꺼번에 시키면 개발자는 두 가지 일 사이에서 문맥교환(context swtching)을 하느라고 오히려 전체 개발 시간이 더 늦어지게 된다. <그림 1>은 조엘이 제시한 예제이다. A라는 작업과 B라는 작업이 있는데, 각각 10초씩 걸린다. 이를 순서대로 처리하면 아래와 같다.

 


 

이를 멀티태스킹으로 처리하면 <그림 2>와 같다.

 



 

순 서대로 처리하면 A를 처리하는 데 10초, B를 처리하는 데 20초가 걸렸다. 평균으로 하면 15초이다. 그런데 멀티태스킹으로 하면 A를 처리하는 데 19초, B를 처리하는 데 20초 걸렸다. 평균 19.5초이다. 오히려 멀티태스킹의 평균 시간이 더 큰 것을 알 수 있다.

 


 


문맥을 교환하는 데 비용이 드는 경우도 따져봐야 한다. 실제 개발자가 멀티태스킹을 하기 위해서는 문맥 교환 비용이 들어간다. 문맥을 교환하는 데 0.5초가 걸린다고 가정하고 계산하면 <그림 4>와 같다.

 


평 균적으로 보면 멀티태스킹이 28초나 걸린다는 것을 확인할 수 있다. 이렇듯 개발자에게 두 가지 일을 동시에 시키는 것은 결국 생산성만 악화시키는 결과를 초래한다. 개발자들이 한 가지 일에 집중할 수 있도록 관리자는 일을 적절히 배분하는 기술과 요령을 익혀야 한다.

 

가장 최악의 케이스는 관리자가 개발자에게 할 일을 모두 던져주고 알아서 하라는 식으로 두는 경우이다. 그렇게 일을 주면 개발자는 한 가지 일에 집중할 수 없다. 관리자는 근본적으로 일에 대한 관리를 하는 사람이다. 자신이 작업에 대한 관리를 하지 않고 개발자에게 일임한다면 그 팀의 생산성은 좋지 않을 것이다.

 

비자아적 프로그래밍(egoless programming)

 

비 자아적 프로그래밍은 『컴퓨터 프로그래밍의 심리학』(The Psychology of Computer Programming, Weinberg 1971)이라는 책에서 처음 언급됐다. 그 책의 요지는 개발자는 자신이 만든 프로그램에 자아를 투영해서는 안 된다는 것이다. 프로그램을 마치 자신의 작품인 것처럼 생각한다면 남들의 비판에 방어적이 되기 때문이다. 오류보고서는 인신공격으로, 검토는 위협으로, 작업에 대한 질문은 비생산적으로 생각해 오히려 제품의 품질을 떨어뜨릴 수 있다. 팀으로 작업하는 프로젝트에서는 이러한 상황을 내버려 둬서는 안 된다.

 

누군가가 자신의 코드에 대해 오류를 지적하면 개발자는 감정적으로 대응하게 되고, 나중에는 오류가 있더라도 지적을 하지 않는 사태가 발생해 결국에는 프로젝트의 품질이 떨어질 수 있다. 따라서 개발자는 프로그램을 자신의 작품처럼 생각해서는 안 되며, 팀 작업의 결과물로 인식해야 한다는 것이다. 이러한 ‘비자아적 프로그래밍을 위해 개발자가 갖춰야 할 10가지 지침(Ten Commandments of Egoless Programming)’이라는 것을 TechRepublic이라는 사이트에서 Lamont Adams라는 사람이 주장했다.

 

1. 당신은 실수할 수 있다는 것을 받아들이고 이해하라
실수는 일찍 발견할수록 좋은 것이다. 일찍 발견할수록 수정 비용도 적게 든다.

 

2. 당신의 코드는 당신의 작품이 아니다
코드 리뷰의 목적은 문제를 발견해서 치료하는 것이다. 그것을 개인적인 감정으로 받아들이지 마라

 

3. 장기도 훈수 두는 사람이 더 잘 안다
장기를 두다 보면 장기에 몰입해서 장기를 두는 사람보다도 주변에서 훈수를 두는 사람이 더 잘 알 수도 있다. 따라서 주변에서 하는 가르침에 겸손해야 한다.

 

4. 조언 없이 코드를 다시 쓰지 마라
혼자서 독단적으로 판단해서 코드를 다시 작성하지 말고, 코드 리뷰를 통해 코드를 다시 작성해라

 

5. 잘 알지 못하는 사람들을 존경하고, 복종하고, 참아라.비기술자들은 개발자들을 좋을 때는 오페라의 프리마돈나처럼 생각하지만, 안 좋을 때는 울보로 간주한다. 여기에 휘둘리지 마라.

 

6. 세상에서 변하지 않는 진리는 변한다는 것이다.
변화에 대해 열린 마음으로 웃으면서 받아들여라. 요구사항의 변화, 플랫폼의 변화, 기술의 변화 이 모든 것에 대해 열린 마음으로 받아 들여라.

 

7. 진정한 권위는 직위가 아닌 지식으로부터 나온다.지식은 권위를 낳고, 권위는 존경을 낳는다. 그러므로 비자아적 프로그래밍 환경에서 존경을 받고 싶다면 지식을 쌓아라.

 

8. 당신이 알고 있는 지식을 고수하며 싸워라. 그러나 패배는 겸허히 받아 들여라.때로는 당신의 아이디어가 채택되지 않을 수 있다. 심지어 나중에 그것이 더 낫다고 밝혀지더라도 “내가 말한 게 맞죠?”라면서 복수할 필요는 없다.

 

9. 독방의 개발자는 되지 마라어두운 사무실에 홀로 앉아서 콜라 살 때만 나타나는 은둔형 개발자는 되지 마라.

 

10. 사람이 아닌 코드를 비판하고, 코드가 아닌 사람에게 친절해라코드에 대한 코멘트는 긍정적이며, 개선하는 방향으로 해야 하며, 기존 코드에 대한 비판적인 방향은 좋지 않다.

 

이 러한 비자아적 프로그래밍이 정착되기 위해서는 프로젝트 팀 내에서도 노력이 필요하다. 가령 “이 프로그램은 누가 짜서 이렇게 오류가 많아”라는 식으로 말하게 되면 이는 결국 말하는 사람 스스로가 개발자와 코드를 하나로 인식한 셈이 된다.

 

이 러한 언급을 용인하고 묵인해 주는 환경에서는 비자아적 프로그래밍을 할 수 없다. 또한 개발자가 한번 개발한 코드에 대해서는 영구적인 오류 수정 권한을 부여하는 환경에서도 비자아적 프로그래밍을 할 수 없다. 비자아적 프로그래밍은 특히 오픈소스 환경에서도 잘 적용되는 개념이다. 한명의 독창적인 작품이 아닌 공동의 작품으로 간주하는 오픈소스 환경에서는 누구든지 오류를 수정하고 개선해 가면서 함께 개발해 나갈 수 있다.

 

이러한 비자아적 프로그래밍은 여러 명이 작업하는 팀 환경에서는 어느정도 필요한 부분이다. 그런데 위의 10가지 지침을 다 지키려면 개발자는 소인이 아닌 군자가 되어야 한다. 남의 비판도 겸허히 받아들여야 하고, 자신이 공들여 애써 만든 작품을 남들이 무너뜨리더라도 웃으면서 받아들여야 한다.

 

개 발자는 자존심을 다 버리고 군자가 되어야 한다. 현실적으로 쉽지 않은 일이다. 필자는 현재도 개발을 하지만, 필자가 개발하는 프로그램에는 최대한의 정성을 다 쏟으려고 노력한다. 하나의 작품을 만든다는 생각으로 내 자신의 자아를 투영한다. 그래야만 정성을 가지고 애착을 가지고 만든다. 만약 개발자가 프로그램에 자아를 심지 않는다면 어떤 정성과 애착을 가지고 잘 만들 수 있을까? 자아 없이 잘 통제하고 잘 감시하면 좋은 프로그램이 나올 수 있을까?

 

정도의 차이는 있겠지만, 극단적인 비자아적 프로그래밍도 좋지 않으며, 그렇다고 프로그램에 자신의 자아를 너무 투영한 나머지 주변의 충고를 무시하는 것도 좋지 않다.

 

필 자는 앞으로도 내 ‘작품’에는 자아를 투영할 것이다. 자신의 작품에는 항상 최선을 다 하고 싶은 것이 예술가들의 자존심이다. 이를 무시한 채, 자아를 버리라고 강요하는 것은 이 또한 현실을 무시한 생각이다. 열린 마음으로 자신의 작품을 향한 주변의 비판을 받아들이는 예술가야말로 진정으로 좋은 작품을 만드는 예술가다.

 


참고자료
1. 소프트웨어 공학의 사실과 오해, 로버트 L. 글래스, 2003
2. 조엘 온 소프트웨어, 조엘 스폴스키, 2004
3. Professional 소프트웨어 개발, 스티브 맥코넬, 2004
4. 똑똑하고 100배 일 잘하는 개발자 모시기, 조엘 스폴스키, 2007
5. 스크럼-팀의 생산성을 극대화시키는 애자일 방법론, 켄 슈와버, 마이크 비들, 2002
6. 피플웨어, 톰 디마르코, 2003
7. 개발의 심리학 이해, http://www.devx.com/DevX/Article/11659
8. 개발자는 멀티태스킹 기계가 아닙니다, http://www.joelonsoftware.com/articles/fog0000000022.html
9. 비자아적 프로그래밍을 위한 10가지 지침, http://articles.techrepublic.com.com/5100-10878_11-1045782.html

 

[필자소개]
한용희 woom33@korea.com|현재 Microsoft Visual C# MVP이며, 여러 SW 개발 프로젝트에 참여했다. 다양한 SW 개발 프로젝트에 참여해 오면서 항상 더 나은 개발 방법에 대해 고민하고 있다.


출처 : http://www.zdnet.co.kr/ArticleView.asp?artice_id=20090914155953



'프로그래밍' 카테고리의 다른 글

[JS] encode 함수 비교  (0) 2009.10.01
개발자의 심리학  (2) 2009.10.01
RFC3852 - Cryptographic Message Syntax(CMS)  (0) 2009.07.30
공인인증서로 전자서명하기  (0) 2009.07.27
댓글 2

마우스 지름(2)

2009. 9. 29.






지난 주 토요일!

친구놈이 자기도 뉴익스3.0을 사고 싶다고 해서
친구의 라쎄티프리미어sx일반썬루프포함(-_-;)을 타고
강변 테크노마트로 고고씽~~

뉴익스3.0 가격을 알아보던 중
'나 좀 봐줘~' 하면서 광채를 뿜어내는 놈이 있었으니..

그 이름하야 로지텍 MX518 !!!
결국 전에 샀던 뉴익스3.0은 친구에게 되팔고 이 놈으로 구입!
그립감 좋고 움직임 좋고 떨림 없고.. 아~ 좋아요!



'끄적끄적' 카테고리의 다른 글

<매트릭스투비> 전자세금계산서 표준인증 획득!!!  (6) 2009.10.12
마우스 지름(2)  (0) 2009.09.29
RSS + PIM 이야기  (2) 2009.09.22
마우스 지름  (0) 2009.09.22
댓글 0

RSS + PIM 이야기

2009. 9. 22.

* RSS : Really Simple Syndication or Rich Site Summary, XML기반의 표준 통신 포맷
* PIM : Personal Information Management, 개인 정보 관리


인터넷에 떠도는 방대한 자료들을 일일이 찾아다닐 수는 없으므로,
나는 주로 RSS를 통해 많은 자료들을 수집하곤 한다.

자료 수집 못지 않게 중요한 것이 수집된 자료들을 관리하는 것인데,
이를 관리하는 활동을 PIM이라 한다. (이를 돕는 System을 포함하여 PIMS라고 한다.)

일을 하다 보면 지난 자료들을 찾아야 하는 경우가 굉장히 많은데,
어디 저장해 놨는지 몰라서 찾아 헤멘 적이 한두번이 아니다.

예전부터 이것에 관심이 많았던 삼이는 최적의 조합을 찾아
강호에 뛰어들게 되는데.. (응?)



첫번째 조합 : RSS 프로그램(?) + DK Notes



RSS 프로그램은 뭐였는지 잘 기억이 나지 않는다. -_-;;
개인pc에 설치해서 사용하는 일반 어플리케이션 이었던 것 같고,
DK Notes는 많이들 아시겠지만 포스트잇 프로그램이다.

웹RSS 사이트가 없던 터라 RSS 프로그램을 설치해서 썼었는데
프로그램 완성도가 매우 낮아서 짜증을 많이 냈던 기억이 있다;;

DK Notes는 본래 용도인 포스트잇으로서는 굉장히 훌륭한 프로그램이지만
자료 정리 용도로는 불편했고 쉐어웨어라서 불안불안한 관계로
후에 jwFreeNote라는 프로그램으로 변경하여 잠깐 사용하였다.



두번째 조합 : HanRSS + Outlook Express



집에서나 휴대용 인터넷 기기로 가끔씩 심심할 때 RSS에 수집된 글을
읽고 싶어서 택한 것이 HanRSS이다.
처음에는 OPMN 가져오는 기능이 없어서 RSS 등록할 때 좀 고생하긴 했지만
변경 목적에 잘 부합되어 어디서든 RSS의 글을 읽을 수가 있어 좋았다.

그리고 사회 초년생일때는 잘 몰랐는데 일을 계속 하다보니 e-mail의 중요성을
깨닫고 아웃룩에 폴더별로 정리를 하여 모든 e-mail을 보관하였다.
메모나 기타 자료들도 자신에게 편지를 작성하여 보관하는 만행을....;;
나중에 용량이 기가 단위가 넘어가니 아웃룩은 점점 버벅대기 시작하고...
(툭하면 용량 압축을 시도해서.. ㅠㅠ)



세번째 조합 : Google 리더(iGoogle) + Essential PIM + 마가린


iGoogle의 가젯을 이용한 시작페이지가 너무 마음에 들어서 HanRSS를 버리고
iGoogle을 시작페이지로 하여 Google 리더 가젯을 추가하였다.
그 외에도 뉴스 가젯, 사전 가젯 등등을 설치하고 나니 어찌나 뿌듯하던지-_-;;

Essential PIM은 대부분 모르실 것 같은데,
상용 PIM 프로그램으로 일정관리, 할일, 노트, 이메일 기타 등등 굉장이 막강한 기능을 담고 있다.
Free 버전도 있긴 한데 그땐 내가 뭐에 홀렸는지 5만원 정도의 금액을 지불하고
Pro 버전의 라이센스를 구입하여 얼마전까지 사용하였다.
메일 관리 기능을 제외하고 기능상의 불편함은 전혀 없었는데,
집에서 가끔씩 일할 때 메일을 찾는 일이 많아져서 결국은 Uninstall.... -_-;;

마가린은 즐겨찾기 관리 사이트이다.
URL이 무려.. http://mar.gar.in !!! (이때 이걸보고 몇 일간 도메인 장사를 꿈꿨었다..;;)
딜리셔스라는 사이트를 벤치마킹하여(URL까지? +_+) 만든 사이트인데
사이트가 깔끔하고 개발하시는 분들이 굉장히 친절(?)하셔서 필요한 기능을 요청하면
바로바로 추가해줘서 굉장히 애착이 가는 사이트이다.



네번째 조합 : HanRSS+ Gmail(iGoogle) + MS 웹오피스 + 마가린


현재 사용하고 있는 조합이다.
설치형 프로그램은 모두 사라지고 웹서비스들만 남았다.
이 조합으로 오기 전까지 Google 문서도구, Google 노트, Naver 메일, Naver NDrive 등 많은 서비스들을
거쳐왔지만 결국은 이 조합으로 당분간(?) 사용하게 될 듯 싶다.

이 조합으로 오게 된 결정적인 계기는 메인 웹브라우져를 Firefox로 변경함에 있었다.
IE8의 기능들에 어느 정도 만족하고 있던터라 웹브라우져를 바꿀 생각이 없었는데,
Firefox의 수많은 플러그인들을 보니 도저히 안 바꿀 수가 없었다. -_-;;

HanRSS의 Firefox 플러그인이 괜찮아 보여서 RSS 리더를 이쪽으로 옮겼고,
(이번에는 OPMN 가져오기 / 내보내기가 있어서 손쉽게 이동할 수 있었다)

라벨링과 메일Chain(?) 기능, 무엇보다 용량이 큰 장점이 있는 Gmail로 이사하였다.
전에 IE 사용할때는 Naver나 Daum에 비해 너무 느려보였던 Gmail이
Firefox와 Chrome으로 써보니 그렇게 빠를 수가.. +_+

MS 웹오피스는 오픈한지 얼마 안되었는데,
Google 문서 도구와 비슷한 서비스로 현재는 Excel, PowerPoint, Word만 지원하고
추후에 OneNote가 추가된다고 한다.
Google 문서 도구도 훌륭한 서비스이긴 한데 로컬에서 작업한 문서들의 서식이
업로드하고 다운로드 하는 중에 너무 많이 바뀌는 단점이 있다.
하지만 MS 웹오피스는 웹에서는 편집 자체를 로컬pc에 설치되어 있는 Office 제품과 연동하기 때문에
문서 서식이 깨질 염려가 없는 장점이 있다.
(물론 로컬pc에 Office 제품이 설치되어야만 편집이 가능하다는 단점도 있다.)

마가린도 Firefox 플러그인을 설치하여 툴바나 컨텍스트메뉴에 북마크를 바로 추가할 수 있도록 하여
굉장히 유용할 듯 싶다.


※ 현재 사용하고 FireFox 플러그인 (좋은 플러그인 있으면 소개좀..^^;;)




'끄적끄적' 카테고리의 다른 글

마우스 지름(2)  (0) 2009.09.29
RSS + PIM 이야기  (2) 2009.09.22
마우스 지름  (0) 2009.09.22
손금.  (0) 2009.06.11

태그

PIM, RSS
댓글 2
  • 오피스 라이브라는 것도 나왔군요. 구글 Docs를 사용하면서 서식에 그렇게 크게 신경을 안 쓰다보니 만족스러웠는데 나중에는 오피스 라이브도 한번 써 봐야겠습니다. 좋은 정보 감사합니다.

    • 그냥 간단하게 쓰기에는 구글 닥스가 더 편하고 좋은 것 같은데,
      아무래도 저는 서식이 신경쓰여서리.. ^^;;
      언능 원노트를 추가해주기만을 바라고 있습니다~

마우스 지름

2009. 9. 22.




가지고 있는 마우스만 해도 G1, 아야쿠초, 삼성 애니젠..
회사에서 쓰고있는 IBM ScrollPoint + Qck mass steel 패드(난 왜 이걸 회사에-_-)

나름 이것저것 많이 가지고 있는 편인데 친구 놈이 마우스 하나만 사달라 그래서
사주러 갔다가 그만 유혹에 못 이기고.. 흑흑.. ㅠㅠ

1. Microsoft InteliMouse Explorer 3.0
Microsoft IntelliMouse Optical 1.1, 로지텍 MX518 등과 함께 치열한 각축전을 벌였지만
결국엔 사용기가 제일 좋던(팔랑 팔랑~) 이 놈으로 결정하였다.

2. RANTO 파우치
게임방 갈때 마우스+패드를 달랑달랑 들고 다니게 되면 쪽팔리지 않을까 해서 구입-_-;;
아무생각 없이 샀는데 아무래도 Qck 마우스 패드는 안 들어갈 것 같다.. 윽~

3. 슈퍼 브레이킹 스티커(?)
이건 아직 한번도 안 써봤던 건데 마우스 다리(?)에 붙여서 미끄러짐을 줄이는 역할을 한다고 한다.
개인적으로 슉슉 미끄러지는 것보다는 약간 거친 느낌(-_-?)을 좋아하기 때문에 그냥 한번 사 봤다..


나는 편의점이나 마트에 가면 '이거 사면 저거 증정', '이거 사면 저거 할인' 상품을 많이 사곤 하는데,
이번에도 어김없이 파우치, 스티커 이런 것들을... -_-;;

과연 그는 투자한 만큼 쩌라+안스(쩌는 라플+안정된 스나;;)가 될 수 있을런지.. 기대하시라~ 쿠쿠..


'끄적끄적' 카테고리의 다른 글

RSS + PIM 이야기  (2) 2009.09.22
마우스 지름  (0) 2009.09.22
손금.  (0) 2009.06.11
오랫만에~  (2) 2008.12.09
댓글 0