Dashboard Widgets의 개발 도구로서 Mac OS X 10.5 Leopard부터 배포될 예정인 Dashcode의 베타 버전이 ADC 회원들에게 공식적으로 배포되기 시작했다.

물론, 아직 베타 버전이라 기능상으로 완전하지 못하며 Mac OS X 10.4와의 호환성을 위해 몇 가지의 제약이 있단다. 앞으로 Dashcode에 관한 새로운 소식은 Dashcode ADC 페이지에서 확인할 수 있다.

이미 오래 전에 우연하게 유출된 것과 비교하면, 기본적으로 제공되는 각 template들의 기능과 돌아가는 모습이 보다 안정적이어서 개발이 거의 마무리 단계에 있는 것 같고, 기타 개발 환경도 벌써부터 실제 widgets 개발과 디버깅에 커다란 도움이 되리라 생각된다.

오른쪽 그림에서 보여주는 것처럼, 이번 Dashcode beta 버전에서 기본적으로 제공하고 있는 widget template들 중에서 Gauge의 것은 아무런 수정 없이 바로 사용할 수가 있을 정도여서, 또 한번 Dashcode 개발 붐이 일면서 더 멋진 widget들이 쏟아져 나오리라 기대된다. 8)

검은색 맥북의 특성상 키보드 위에 먼지가 쌓이는 족족 젖은 행주의 출동을 재촉하게 된다. 이럴 때마다, 행주를 맞이하기 전 준비 작업으로 Keyboard Cleaner는 아주 요긴하게 쓰일 듯 하다.

역시나 언제 어디서든 자기 몫을 제대로 하는 놈은 꼭 덩치가 클 필요는 없나보다.

Firefox에서는 저장되어 있는 책갈피들을 사용자가 직접 지정해두었던 키워드(keyword)를 주소창에 대신 입력해서 바로 불러올 수 있는 기능이 있다.

이것은 단지 약간의 타이핑 수고를 덜어줄 뿐만 아니라, 주소 뒤에 붙는 query string의 조합으로, 웹에서 제공하고 있는 다양한 정보 검색 서비스들을 간편하게 이용할 수 있는 길을 열어주게 된다.
다행스럽게도, 이런 탐나는 기능을 Safari에서도 그대로 흉내낼 수가 있는데, 이 기능은 SafariStand의 Stand 메뉴 속 SafariStand Setting…을 누르면 보이는 Quick Search 항목에 숨어있어서 그냥 지나치기 쉽상이다.

아래의 그림은 Ruby와 Rails API 문서를 손쉽게 검색할 수 있는 방법이 소개된 글에 나와있는 것을 그대로 Safari에 적용한 모습이다.

이 곳에 새로운 검색 서비스 주소를 입력할 때, Firefox에서의 입력 주소와 다른 것은, query string을 뜻하는 %s 대신에 @key를 입력해 주면 된다.
이렇게 해서, 예를 들어 ruby link_to와 같은 식으로 입력하면 찾고자 하는 method나 class의 문서를 바로 보여주면서, 개발의 집중도를 흐트러뜨리지 않는 데에도 도움이 될 것이다.

24 ways to impress your friends – 웹 개발에 관련된 다양한 주제의 주옥같은 글들이 모여있다.
웹 개발에 관심을 가진 사람이라면, 여기에 있는 글 하나하나 모두 머리 속에 담아놓고 싶어할 것이다. 이미 2005년도서부터 시작해서 한해에 모두 24개의 방법이 소개되는 듯한데, 올해는 아직 13개의 비법만이 올려져 있다.
나머지의 비법도 마저 공개되길 바래본다.

그런데, 이런 것으로 감명받을 수 있는 친구는 분명 괴짜이어야겠지. 😛

 없음.

Yahoo! User InterfaceBlog의 글에도 나와 있듯이, 웹 브라우져에서 특정 웹 페이지를 읽어드리는데 가장 많은 시간이 소요되는 부분은 html 문서를 생성해서 전달하는 과정보다도 그림 파일들이나 스크립트, 스타일쉬트들과 같은 기타 부분들을 읽어드리는 데에서 대부분의 시간이 소요되는 것으로 알려져 있다.
그렇다면, HTTP의 요청 횟수를 적당한 수준으로 줄일 수 있다면, 여기서 얻어지는 성능의 향상은 서버 튜닝이나 DB 최적화에 의해 얻어지는 성능의 향상보다 훨씬 손쉽게 더 큰 이득을 볼 수도 있다는 얘기가 된다.

하지만, HTTP의 요청 휫수를 줄이고자 무턱대고 멋드러진 웹 유저 인터페이스를 포기할 수도 없는 노릇.
그래서, 불필요한 HTTP 요청들을 즐이면서도 효과적이고 멋진 유저 인터페이스 환경을 제공하기 위한 노력으로서, 관련 자바스크립트나 CSS 파일들을 압축해서 한 데 묶고 캐쉬 기술을 사용하거나 메뉴의 Rollover 이미지들을 하나로 묶는(Pixy rollover) 등의 기법들이 사용되기도 한다.
물론, 여기서 더 나아가 사용자들이 취할 수 있는 조치로, 웹 페이지의 로딩 속도를 단축하기 위해 특정 웹 브라우져의 HTTP의 Pipelining 기능을 커놓는 작업도 할 수 있겠지만, 아직 모든 브라우져들이 이 기능을 지원하지도 않고, 또한 대부분의 서버들은 아직 pipeline된 요청들에 대해 편차가 심한 반응들을 보여주는 것으로 알려지고 있다.

따라서, 적당한 HTTP 요청 횟수를 판단하는 것은 웹 사이트별 사용 환경과 요구 사향에 따라 차이를 보일 수 밖에 없으며, 결국은 개발자 경험에 의한 판단이 중요하다고 말할 수 있다. 여기서 판단의 기초 자료로 사용될 수 있는 도구로 마침 BETA 딱지를 붙이고 새로 갱신되면서 추가된 Firebug의 Network Monitoring 기능을 빼놓을 수 없다.

위에 보이는 창에서처럼 FireBug의 Net 항목을 선택하면, 현재 접속한 웹 페이지를 읽어드리는데 소요된 HTTP 요청들의 횟수와 크기, 시간을 파일별로 한 눈에 살펴볼 수가 있다. 여기서 얻은 자료는 유별나게 웹 페이지 로딩 속도를 지체하게 만드는 불필요한 병목 요인을 끄집어내서, 추가 최적화 작업이 필요한지를 판단하는 중요한 단서가 될 수 있을 것이다.

결국, 웹 개발자들에게 FireBug는 찰떡궁합이라는 얘긴가?