요새 가끔씩, 헤매고 있는 전자정부 때문에, Boot Camp의 도움으로 Windows로 시동해야 할 때가 가끔 있다. 그 때마다 여기저기 둘러보는데, 유독 Windows의 Internet Explorer에서 바라본 이 곳 사과나무의 모습은 결코 깔끔하지도 않으며 그 구조 또한 무참히 깨져서 보인다. 👿

하지만, 보고난 후의 언짢은 마음이 남으면서도 그냥 내버려 두고 있는 이유는, 단지 귀찮아서다. 곧이 말한다면, 꽁수들을 써가면서까지 바라지도 않는 덧칠들을 하고 싶지가 않은 것이다. 그렇다고 거의 3년 전에 Microsoft가 했었던 약속을 아직까지도 지키지 못 하고 있음을 원망하지도 않는다.

그저, 이 곳에서 얘기되고 또 얘기하고 싶은 것들이 “그들”과는 너무나도 거리가 먼 것이 제일 큰 이유가 되겠지.

Markdown은 간단히 말하면 웹 저자들을 위한 글자-HTML 변환 도구이다. 그래서, 읽기 쉽고 쓰기 쉬운 일반 글자 형태의 글을 손쉽게 (X)HTML 문서로 변환할 수 있단다.

이미, WordPress에서는 1.2 버전부터 이 Markdown plugin을 제공하고 있었지만, 여태 모르고 무심결에 넘겼었다. (WordPress v2.0부터는 새로 추가된 시각적 HTML 편집기로 인해, 이 기능을 꺼놓지 않는 이상은 더 이상 사용할 수 없단다.)

요새는 거의 누구나가 자기 blog를 운영하고 있듯이 기본 HTML 문서를 다룰 일들이 많은 환경에서 Markdown은 또 하나의 유용한 도구로 사용될 수 있을 듯 한데, 부담이 되는 것은, 또 하나의 문법을 익혀야 한다는 것이다.
하지만, 처음 소개 문장에서도 밝혔듯이 Markdown의 기초 문법은 비교적 간단하며, 한 번 익히고 나면 직접 (X)HTML로 쓰는 것보다 시간과 노력이 덜 들어갈 듯 하다.

그리고, HumaneText.service라는 것을 설치하면, 어느 글자 편집기에서든 메뉴막대의 서비스 항목에서 선택하여, Markdown 형식의 글을 XHTML로 간편하게 변환할 수도 있단다.

당분간, MarkDown Cheat Sheet을 붙여놓고 참고하면 금새 익힐 수 있을 듯. 😉

Safari가 사용하고 있는 오픈 소스 웹 브라우져 엔진인 WebKit의 개발 버전을 탑재한 웹 브라우져로 이름도 WebKit이라는 놈이 있는데, 이 WebKit 웹 브라우져를 위한 JavaScript debugger가 발표되었다.

Drosera라는 이름은 가장 큰 식충 식물류의 이름에서 가져왔다고. 😀

항상 Safari를 쓰면서 아쉬워 했던 것이 마땅한 debugger의 부재였는데 이로써 벌레 퇴치기의 아쉬움을 말끔히 씻을 수 있게 되었다.

Drosera의 사용자 인터페이스를 보면 얼마 전에 흘러나온 DashCode의 JavaScript debugger와도 무척이나 닮아있는 것이 흥미롭다. 또한 Desora의 90 % 이상은 HTML과 JavaScript로 짜였졌다고 하니, 웹 어플리케이션의 새로운 가능성을 보는 듯 하다.

WebKit에서 Drosera 벌레 퇴치기를 불러오는 법은 WebKit Nightly Builds를 내려받아 WebKit과 Drosera를 하드 디스크에 복사한 후, WebKit을 실행시켜서 JavaScript debugger가 필요할 때마다 Drosera를 실행시키고 File 메뉴의 “Attach…”로 WebKit에 붙여놓으면 된다. (아직은 자동적으로 debugger를 꺼내볼 수 없는 것이 아쉽다. 하지만 이미 Dock에 올려놓고 적당한 벌레 아이콘까지 입혀 주었단다.)

아울러, WebKit 개발 버전을 사용하면 웹 페이지의 구조를 쉽게 파악할 수도 있는, 보기에도 멋들어진, Web Inspector까지 덤으로 얻게 된다. 😉

화면 해독기(Screen Reader)에서도 잘 작동될 수 있는 Ajax 구현이라는 글에는 화면 해독기의 작동 원리와 그에 따른 적절한 Ajax 어플리케이션들의 구현 방법, 그리고 이러한 방법들을 적용한 몇 가지 예시들을 설명하고 있다.

하지만, 아직 자연스럽고 완벽하게 적용되려면 갈 길이 멀은 듯.
새로운 기술이나 최신 유행이라도 현재의 사용 습관과 환경에 적용되기란 결코 만만하지가 않을 것이다.

웹 어플리케이션 개발/구동 언어로 Perl은 어쩐지 난해해 보이지만, 이 Ruby라는 놈은 이미 실제 운용 웹 어플리케이션들에 바로 적용될 수 있는 제법 훌륭한 공개 웹 프레임워크가 존재하며, 덕분에 높은 효율의 개발 생산성을 보장해주고, 또한 Mac OS X에서의 지속적인 지원도 기대할 수 있다. (그리고 Rails 개발자들 중에는 Mac 사용자가 많은 것도 우연은 아닌 듯.)

결정적으로, Ruby 자체가 띠고 있는 빛깔도 매력적이라, Ruby on Rails의 활약상을 보고나면 탐이 날 수 밖에. 😛

• Python 소개의 글이지만, 정작 Ruby에 괌심을 갖게 한 글.

  Python says explicit is better than implicit. Ruby says implicit is better than explicit. If you find yourself nodding at any of those attitude statements, you’ve probably found your scripting friend.

• Python과 Ruby의 비교.