구글 검색 활용하기(구글 커맨드)

구글 페이지는 썰렁하다 입력할 수 있는 공간만 덜그러니 놓여있다보니, 그냥 아무생각 없이 타이핑하고 나타나는 수많은 검색결과들을 눈으로 스캐닝 하곤 하는 사람을 많이 본다.
사이트, 블로그내용 등등 수도없이 돌아다니면서 필요한 내용을 찾을 순 없지 않겠는가?
어 쨌든 “구글링” 이라는 말이 의미있는 용어로 통용될 정도이니 구글에 대해서는 더 말해 뭐하겠는가. (구글링이라는 말이 단적으로 검색엔진에 대한 신용과도 같은 의미를 갖는다고 생각한다 – 왠지 브리태니커에 의하면 ~~ 과 같은 뉘앙스가 느껴지지 않는가?)

단 지, 주변에 있는 사람들에게 “구글은 모든 검색엔진의 슈퍼셋이다.” “구글링 해봐라” 이런 말을 해도 Nxx 지식검색을 더 자주 하는 모습을 보면서 약간은 구글을 십분 활용하지 못하는 것 때문에 누군가가 걸러준 내용중에서 검색함으로써 사용자들에게 좀더 빠르게 원하는 것에 접근하는 듯한 착각을 주고 있는 것 같아서, 구글 검색 부분에 대해서 활용할 수 있는 내용을 약간 정리해본다.

구글 검색엔진창에 입력할 수 있는 커맨드(검색을 좀더 스마트하게 해주기 위한 옵션기능)의 종류가 많다보니 대부분의 사람들은 그냥 검색어만을 나열해서 입력하는 경우가 대부분이다.

커맨드를 알려줘도 자주 사용하지 못하게 되면 잊어버리게 마련이니, 아래와 같은 사이트의 도움을 받는 것도 방법이겠다.

• 구글 커맨드라인 헬퍼 : http://projects.felipc.com/gcl/
• 구글 좀더 쉽게 전문 검색하기 : http://www.soople.com/

유용한 커맨드 몇몇개 정리

1. filetype : 파일타입별 검색 파일의 타입별로 검색한다.
   (예) pdf 파일중에 ruby 라는 단어가 포함된 것 ==> filetype:pdf ruby
2. site : 특정 사이트내 내용 검색
   (예) apple.com 사이트에서 macosx 검색하기 ==> site:apple.com macosx
3. define : 단어에 대한 정의 검색하기
   (예) early adopter 에 대한 정의 검색 ==> define: early adopter
4. link : 누가 사이트를 링크하고 있는지 보기
   (예) link:jimanryu.wordpress.com
5. related : 입력한 url 과 관련된 페이지 찾기
   (예) related:jimanryu.wordpress.com
6. cache : 페이지가 없어지거나 한 경우 구글에 캐시된 내용 보기
   (예) cache:jimanryu.wordpress.com
7. bsd, linux, mac, microsoft: 특정 OS 관련 검색
   (예) mac:macosx

우선 위정도만 가볍게 ~~
그럼. 즐거운 구글링 ~~~

Tear Drop 일냈다 !!!

호세 밴드가 드디어 세상에 더욱 널리 알려지려나보다.

이번 Rocket 2006 Fest 에서 당당히 1등을 차지한 그룹 Tear Drop !!! ㅎㅎㅎ 아래 링크에 가서 1등 그룹의 음악을 들어보시라 ~~~

1등 수상소식

음악은여기 

싸이 홈페이지

MoinMoin – UnicodeDecodeError

모인모인 사용시 UnicodeDecodeError가 발생하는 경우 페이지가 제대로 안열리는 경우가 생길수 있다.

이때 몇몇 파일에서 except 처리를 해주면 잘 나타나게 되는 경우도 있으니 아래 파일들을 변경해보자.

~/site-packages/MoinMoin/logfile/editlog.py

<code>
try:
hostname = socket.gethostbyaddr(host)[0]
- except socket.error:
+ hostname = unicode(hostname, config.charset)
+ except (socket.error, UnicodeError), err:
hostname = host

remap_chars = {u'\t': u' ', u'\r': u' ', u'\n': u' ',}
</code>

~/site-packages/MoinMoin/logfile/logfile.py 48 line 근처.

<code>

# Decode lines after offset in file is calculated
try:
self.lines = [unicode(line, config.charset) for line in self.lines]
except UnicodeError:
self.lines = [unicode(line, "iso-8859-1") for line in self.lines]

</code>

무엇을 공부해야 하는가? 방향성 상실에 대한 팁들.

프로그래머가 바라본「진보에 장애가 되는 습관」
주목받는 SW 개발방법론「비교 분석」
「논쟁에서 승리하는」개발자가 되려면?

우선 오래된 글인데, 위 세가지 글을 읽어보라고 나 자신에게 권하고 싶다. 어떤 기술에 대해서 관심을 가져야 하며, 어떤 것이 도움이 될 것인가? 또 어떤 것을 개선해야하는 항목으로 선정해야 할 것이며, 또 어떤 것을 버리고 어떤 것을 도입해야 할 것인가???

모든 질문은 최근 몇일간 나 자신에게 던져진 질문인데, 위 링크의 첫번째 글 ” 진보에 장애가 되는 습관 ” 이란 글을 읽고 다시 생각하는 계기가 되었다. “아 난 자신의 어떤 도그마에 빠져있었구나” …. 고기를 낚았으면 그물을 버리라니? 고기를 잡는 방법은 그물만 있는 것이 아니라니? 도대체 상식적으로 이해하기 어려운 것 같으면서도 왠지 공감이 갈려고 하는 이 분위기는 뭐지?

본능적으로 쿨한 것에 끌리는 나로서는 왠지 이 글을 읽고나서 반응이 오는 느낌을 갖게된다… 아 뭔가 다시 생각할 부분이 있구나.

새로운 기술들을 도입하는데, 새로운 뭔가를 찾아 헤메이는데 지금 갖고 있는 것을 버리지 못하고 있었다.

“어떤 관습이 편안하게 느껴질 때 그것을 때려 부숴라.” — 니코스 카잔차키스

지금 편하게 느끼고 있는 기술은 무었인가? 지금 버리지 못하고 애물단지 처럼 안고 놓지 않는 기술은 무었인가?
제일 편하다고 느끼는 것에서 문제의식을 느껴야 한다. 버려야 한다.

“우리의 탐구나 수련으로 통해 얻게 된 지식은 그 자체로서 완결되는 것이 아니라 결국 어느 순간, 과정 내지는 다른 지식을 위한 초석이 된다”

멋진 말이다.

결국 우리가 안주하고 있는 기존의 패러다임. (RM – Engine?) 이 적절한 비유가 될까? 이것을 걍 버리라는 말이 아니다.
“대부분 패러다임의 변화는 이전 패러다임의 한계와 오류를 극복한 대안이기 때문에 오히려 패러다임에 대해 깊은 이해를 가지면 다음 패러다임의 예측도 가능합니다.”

이제는 과거의 패러다임에서 벗어나야 할 때가 온 것 같다.

나는 지식노동자인가?

스스로 반문하는 일이 요즘들어서 많아졌다. 근래에 들어서 더더욱 고민하는 꺼리도 많아졌다. 새삼스러울 것도 없지만, 뭔가 개인적으로 주기 같은 것이 있는데, 최근에 읽었던 책의 목록들을 살펴봐도 내가 내심 어떤 것을 원하는지를 알고 싶어하는 것 같았다.

최근 3개월 이내에 내가 읽은 책들은

• 조엘의 두번째 책
• 대체 뭐가문제야?
• 백만불짜리 습관
• 마인드 혁명
• 삶의 에너지를 높이는 습관들

이다. 많지는 않지만, 대체로 개인적으로 뭔가 개선할 만한 꺼리를 찾고 있었던 것 같다. 3개월이 지난 지금에 와서도 비슷한 행태를 계속 하고 있는 중이기도 하고… 이 와중에 또 김창준 님이 쓰신 블로그 내용을 보고 다시금 또 반성을 하고 있는 중이다 ㅡㅡ;; 도무지 운동이란 것에 담쌓고 사는 것이 얼마나 무지한 일인가 깨닫게 해주는 내용인 것 같다. (다시 생각해보니 과거에 김창준님이 쓰신 무술과 프로그래밍을 연관지어 쓴 내용을 봤을 때도 그랬던 것 같다).

역시나 게으른 것이 제일 문제였던가 보다… 잠시 수많은 일들을 떨처버리려고 고민만 하던 패턴을 약간 바꿔볼 필요가 있겠다. 머 거창하게 시작하면 나 자신을 잘 아는 나로써는 오래가지 못할 것을 알기에, 간편한
것부터 시작해봐야겠다.

워드프레스의 버그인가? 아래부터 내용이 주욱 잘려서 다시 씀

• 국선도, 내가 예전부터 좋아했었고 한동안 하던 수련인데 자식넘 태어나고 부터 계속 못했었다.
• 수영, 이건 접영만 아직 못하는데 최소한 접영까지는 마스터할 수 있도록 해야겠다.
• 줄넘기, 얼마전부터 시작한 것인데 생각보다 무지 힘들다. 이렇게 힘든 건지 몰랐지만, 짬짬히 해서 시간을 더 늘려갈 수 있도록 해야겠다.

쩝, 기억력의 한계인가? 뭔가를 작성하고 포스팅하고나면 다 잊어버린다니까 ㅡㅡ;; 더 생각이 안난다. 여기서 접어야겠다. (이것도 운동 꾸준히 하면 좋아지려나?)

블로그내용 소개 – 에릭 싱크

원문 : http://software.ericsink.com/No_Programmers.html

개발자와 프로그래머의 차이에 대해서 기술한 블로그 내용.

여기서 ‘프로그래머’란 새로운 기능을 코딩하고 운이 좋으면 버그를 고치는 일만 하는 사람입니다. 프로그래머는 스펙을 작성하지 않습니다. 자동화 테스트케이스를 작성하지도 않습니다. 그리고 자동화 빌드 시스템을 최신으로 유지하는데 도움을 주지도 않습니다. 또 고객이 힘든 문제를 해결하는 걸 돕지도 않습니다. 설명서를 작성하는 데 힘을 보태지도 않고, 테스트에 참여하지도 않습니다. 코드를 읽는 일조차 하지 않습니다. 프로그래머가 하는 일은 오로지 새 코드를 작성하는 것뿐입니다. 소규모 ISV에서는 이런 사람을 원하지 않습니다. 여러분에게는 코드를 작성하는 특수 임무를 맡은 ‘프로그래머’가 아니라, 성공적인 제품 개발을 위해 다양한 방식으로 기여하는 ‘개발자’가 필요합니다.

라는 내용의 글을 에릭싱크 자신의 블로그에 올려놓았다. 위 글을 언급하는 이유는? 최근에 다시금 어떻게 하면 무지막지하게 고생하는 팀원들과 나 자신에게 좀더 테스트 코드를 작성하고 활용하게 할 수 있을까에 대한 고민을 다시 새로이 시작하는 시점에 참고가 될만한 내용이라고 생각해서이다.

물론 테스트코드 .. 작성하면 된다. 무조건 통과할 수 있도록 거기에 맞추어서 코드를 추가할 수도 있다. 형식적인 자료만 될 수 있는 코드도 무지하게 추가할 수 있다. 하지만, 스스로가 이건 정말 도움이 되는 것 같다… 정말 도움이 되었다. 라고 느끼지 않는 다면 얼마 지나지 않아서 다시 이런 자동화된 테스트 코드를 작성하는 것을그만 둘 것이다. 나 자신도 물론 그럴 것이고.

문제는 현재까지는 이런 테스트 코드를 작성하는 일이 재미도 없고, 그리 도움이 될만하다고 느껴본적이 없으며, 쉽게 느껴지지도 않는다는 것이다.

어떻게 하면 진정으로 도움이 되는 테스트라고 생각할 수 있을까? 어떻게 하면 이런 것을 경험할 수 있을까? 누군가 나서서 이렇게 하자!! 라고 지속적으로 외치기만 해서 해결될 수 있을까?

일단 위에나온 에릭 싱크의 말처럼 접근을 시작하는 것도 좋겠다. 누구나 자신이 발전하는 것을 좋아하기 때문이다. 이렇지 않는 사람이라면 전혀 재고의 가치도 없을 것이다. 발전을 원하는 사람들에게라면 어느정도 씨앗이 될 수 있을 만한 거리를 제공하고, 어떻게는 테스트 코드를 작성하는 것도 하나의 일이며, 이런 일을 할 수 있는 시간을 확보해서 제공하는 것만이 결국에는 모두에게 이익이며 개발비용을 오히려 절감할 수 있는 것이라는 사실을 윗사람들에게도 제공할 수 있도록 데이타가 축적되어야 하겠다.

# 우선 작은 성공을 경험할 수 있도록 제공하자.

# 쉽다고 느낄 수 있도록 자동화할 수 있는 방법을 고민하자.

# 신입사원도 자연스럽게 할 수 있는 상태가 되면 누구에게나 쉬운 것이다.

거창하게 모든 것을 한꺼번에 통합할 필요성은 없다. 단위테스트 코드들이 늘어날 수록 테스트를 자동화해서 매번 거치는 코드들은 그만큼 검증되었다고 인정해주는 분위기가 되어갈 때 즐거움을 느끼는 ‘개발자’ 단계로 들어가는 것임을 상기시켜야 하겠다.

블로그내용소개 – 에릭 립퍼트

[블로그내용소개] 에릭 립퍼트 – 전구하나바꾸는데 마이크로소프트 직원 몇 명이 필요할까?

원문 : http://blogs.msdn.com/ericlippert/archive/2003/10/28/53298.aspx

위 내용이 번역되어진 책이 최근에 조엘의 두번째 책으로 엮어졌습니다.
읽다보니 역시나 조엘의 블로그 만큼이나 재미난 것들이 많더군요. 아직 읽는 중입니다.

이 글에서 나온 내용중에 너무나 지금 하고 있는 일에 딱 맞는 조언이 될 수 있을 것 같아서 한번 생각해보자는 의미에서 발췌해서 보냅니다.
(오래된 글인데, 역시 좋은 글은 언제 읽어도 도움이 되는 것 같습니다. 자세한 내용은 원문을 살펴보시면 되겠습니다.)

물론 우리 회사가 마이크로소프트와는 다른 성격의 제품을 생산하는 곳이라 약간 다르기도 하고 마이크로소프트자체의 프로세스가 상당히 복잡하고 까다로와서 아래와 같이 될 수도 있지만, 어쨌든 한번쯤 기능을 추가하실 때 생각해볼만한 문제라고 생각합니다.

(한때 우리가 마이크로소프트를 이기자? 라고 외치셨던 분이 계셨습니다. 높으신 분으로 … 생각해보면 이기긴 힘들 것 같습니다. ㅎㅎ)

[내용]
마이크로소프트에 근무하고 있는 에릭 립퍼트라는 사람이 VBScript 에 기능을 추가하는 일을 담당하고 있을 때 벌어진 일화를 소개하고 있습니다.

고객이 특정 기능(일반적으로 사용되지 않는 기능)을 추가해달라고 요구하는 상황에서 예기했던 내용이라고 합니다. 물론 이 기능을 에릭이 추가하는데는 5분도 걸리지 않는다고 합니다. 하지만 이러한 기능을 넣을 수 없었던 이유에 대해서 아래와 같이 얘기했습니다.

“전구 하나 바꾸는데 마이크로 소프트 직원 몇 명이 필요하다고 생각하십니까?”

# 요구 기능을 5분 안에 구현하기 위한 개발자 1명
# 명세를 작성하기 위한 프로그램 관리자 PM 1명
# 명세의 지역화 문제를 검토하기 위한 지역화 전문가 1명
# 명세의 접근성과 사용성 문제를 검토하기 위한 지역화 전문가 1명
# 발생 가능한 보안 취약점을 점검하기 위한 개발자 1명, 테스터 1명, PM 1명 (최소인원)
# 보안 모델을 명세에 추가하기 위한 PM 1명
# 테스트 계획을 작성할 테스터 1명
# 테스트 스케줄을 갱신할 테스트 리더 1명
# 테스트 케이스를 작성하고 테스트 자동화 방법을 만들 테스터 1명 (단위테스트만 하는 개발자형 테스터가 따로 있는 모양이군요)
# 무작위로 버그를 찾아내기 위한 테스터 3-4명
# 문서를 작성하기 위한 기술 저장 1명
# 문서를 교정하기 위한 기술 검토자 1명
# 문서를 교정하기 위한 편집자 1명
# 새로 작성한 문서를 기존 문서에 추가하고 목차, 인덱스를 갱신할 문서 관리자 1명
# 문서와 에러 메시지를 윈도우에서 지원하는 모든 언어로 번역하기 위한 번역자 25명
# 이들 업무를 조정하고 개발 비용을 부사장에게 승인 받아야 할 상위 관리자 팀.

이들 중 개별적으로 시간이 많이 소요되는 건 없지만 다 더하면 상당한 시간을 소모하게 됩니다. 그것도 아주 간단한 기능을 구현하기 위해서 말이죠. 그리고 위 작업은 모든 것이 딱 맞아 떨어질 때를 가정한 것입니다. 만약 처음에 작성한 코드 다섯 줄에 버그가 있다면 어떻게 할까요? 우리는 버그를 찾고, 다시 테스트를 수행하는 등의 작업을 하기 위한 비용을 추가해야 할 것입니다.

처음 생각한 5분 이라는 개발 시간은 많은 사람의 작업과 비용으로 확장됐습니다. 그저 한 고객에 자신이 원하는 기능을 담은 1회용 VB6 컨트롤을 만드는 수고를 덜어 주기 위해서 말입니다. 미안합니다, 그렇게 하는 것은 사업상 불가능 하군요. 마이크로소프트 직원은 덜 익은 소프트웨어를 출시하는 일이 없도록 매우 열심히 노력합니다. 소프트웨어를 올바르게 작성하는 것 – 무엇보다도 평범한 일반 사용자가 보안 문제 없이 쉽게 기능을 사용할 수 있도록 보장하는 것 – 은 비용이 상당히 많이 드는 일입니다.

하지만 우리는 그 일을 잘 해내야 합니다. 우리가 새로 만드는 스크립트 엔진을 수억 명이 사용하고 수천만 명이 프로그래밍할 테니까요.

보편적인 일반 사용자와 관련이 없는 기능을 새로 작성하는 것은, 주요 기능을 구현하고 버그를 잡으며 보안 취약점을 찾을 자원 (사람, 시간, 돈)을 훔치는 일과 다를 바 없습니다.

끝.

위와 같은 내용입니다.

밑줄친 부분을 해석할때 오해를 갖게되면 곤란하니… 다시 얘기하면 어쨌든 우리는 제품을 내놓기도 하지만, 커스터마이징도 해줍니다. (이런 경우를 같이 하고 있는 상황을 염두해두고 이해하시면 좀 안맞는 상황일 수 있습니다)

내부적으로 연구소가 PS 팀 또는 다른 협력업체에게 릴리즈 한다는 개념 선상에서 이해하시면 좋을 것 같습니다.

(고객에게 바로 릴리즈하는 것은 SI 죠? 안그렇습니까? 우리 회사는 SI 이다 라고 생각하시면 쩝 머 그런거겠죠. 그럼 여기서 생각은 스탑. – SI 하면서 고객에 요구하는데 안하면 안되지 않습니까?)

어쨌든 마이크로소프트와 우리가 다르다고 생각하십니까? 그렇죠 여러가지 여건이나 상황은 다를 수 있습니다. 머 그럼 여기서 생각은 또 멈춰버리겠네요. 그럼 재미 없겠죠? 어쨌든 상황은 마소나 우리나 비슷한 것 같습니다. 제품을 패키징해서 내보내고 있으니까요. 제품 출시가 계속 되는 한은 위 문제를 우리 것으로 소화해서 고민해볼 만한 가치가 있는 것 같습니다.

한번쯤 사간나실때 읽어보시고 (원문을) 생각하는 시간을 가져보시기 바랍니다.

Using Ruby on Rails for Web Development on Mac OS X

Using Ruby on Rails for Web Development on Mac OS X

A short guide to RubyOnRails for MaxOS X users.

Ajaxian: More handy Prototype documentation

Ajaxian: More handy Prototype documentation: “More handy Prototype documentation”

AJAX 라이브러리인 Prytotype 의 좋은 Tutorial… 해보자.

try ruby! (in your browser)

try ruby! (in your browser)

우와아앗… 멋진 걸…
웹에서 루비 인터프리터를 … 핫핫핫 재미난 친구군.
어쨌거나 가볍게 투닥투닥 해보고 공부하기에는 최적!!!

즐겨찾기 당근 추가. 매일매일 들르는 사이트 순위 급 상승 예상 !!!

좋아좋아.