당분간은 허전한 내 옆구리와 이동간의 지루함을 채워줄 것이다.
조만간 Rails 1.2가 마무리 되어서 정식으로 배포되길 기대해 본다.
올 한 해, 곡괭이질에 익숙해지자.
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는 찰떡궁합이라는 얘긴가?
