내 도메인인 dahlia.kr 아래쪽에 있는 URL 중에 3년 정도 된 게 하나 있다.
http://justhing.dahlia.kr/io-tutorial-for-programmer/
예전에 썼던 짧은 Io 튜토리얼인데, 까맣게 잊고 있다가 얼마 전에 다른 블로그에서 여기로 링크된 게 있어서 생각이 났다. 눌러 들어가서 오랜만에 봤더니 데이터가 날아가서 에러가 나고 있었다. 날아간 데이터를 어찌할 수 없어서 그냥 요즘 IBM developerWorks에 연재중인 Io 연재로 링크를 해놨다.
소를 위한 IPv6
- wooil: 그런데 IPv6라도 1인 1 아이피는 안 되죠?
- darjeeling: 아뇨
- darjeeling: IPv6는
- kkung: IPv6는
- kkung: 미생물에게 하나씩 줘도
- kkung: 남는다는
- kkung: 계산을 누가 했던데
- kkung: =3=3
- wooil: -0-
- darjeeling: 아 모르셨군요.
- darjeeling: 저희가 앞으로
- darjeeling: 소를 키우면서
- darjeeling: 소에게 IP를 할당해서
- darjeeling: 멀티캐스트로 핑을 쏘면
- darjeeling: 죽었는지 살았는지 나올꺼임.
요즘 느끼는 건데 상업적인 프로젝트에서 개발자들이 문서라고 남겨둔 것들은 대체로 불친절하고 누가 시켜서 억지로 했다는 느낌이 강하다. 불친절하다는 것을 어떻게 알 수 있냐면: 일단 상업적인 프로젝트의 문서에서 튜토리얼이 나오는 경우는 절대 없다. 왜냐면 튜토리얼은 꼭 있어야 하는 문서는 아니지만 이해를 더 쉽게 하기 위한 것이고, 나처럼 문서화를 좋아라하는 개발자들은 원래 적기 때문이다. 그걸 감안하더라도 오픈 소스 프로젝트에 비해 상업적인 프로젝트의 문서들이 더 형편없는 경우가 많은데, 오픈 소스 프로젝트의 경우 문서화를 잘 해야 프로젝트 홍보가 잘 되고 날개돋힌듯 널리 알려지고 쓰이며 발전하기 때문에 문서화를 중요하게 생각하기 때문이다.
오픈 소스 프로젝트에게 있어서는 문서와 프로젝트 홈페이지가 프로덕트 패키지의 역할을 담당하는데다 오픈 소스 프로그램은 대부분 유형적인 패키지가 존재하지 않는 프로덕트이므로 문서화는 사용자를 유혹하는 가장 직접적인 수단이다. 예를 들어 인기있는 웹 프레임워크인 Django를 써본 사람들은 처음 Django를 쓰게 된 이유가 홈페이지 디자인이 좋고 Sphinx로 문서화된 매뉴얼이 훌륭해서라는 사실을 무시하지 못할 것이다. 이런저런 이유 때문에 인기 있는 오픈 소스 프로젝트는 대부분 훌륭한 매뉴얼이 존재하고, 튜토리얼도 꼭 함께 있다. 요즘엔 아예 동영상으로 찍어서 스크린캐스트를 제공하기도 할 정도니.
어쨌거나 소스는 물론 API조차 외부에 알려지지 않더라도 Sphinx로 꼼꼼하게 문서화를 하는 편인 나에게 있어서는 상업적인 프로젝트에서의 전혀 이해에 도움을 주지 않는 구실뿐인 문서들은 괴롭기만 하다. “없는 것보단 낫다”라고들 하지만 나한테 그건 아예 고려 대상도 아니고.
손으로 미세한 최적화를 하지 말자
How to Micro-Optimize Your CSS1 같은 글을 보면 한숨이 난다. 저런건 사람이 할 일이 아니다. 반복적이며 사소한 저런 최적화는 원래 프로그래밍 언어에서는 컴파일러 등이 해야할 문제다. 저기 나온 최적화 팁들은 CSSTidy 쓰면 죄다 자동으로 할 수 있다. 사람은 그냥 자기가 가장 편한 방법으로 코딩하면 된다. 제발 저런 문제는 코딩할 때 신경쓰지 말자. 저건 배포의 문제니까, 배포할 때 자동화할 생각을 하자.
Apache, lighttpd 모듈로 mod_csstidy라도 만들어야 하냐는 생각이 들었다.
-
파이어준 님이 한국어로 같은 내용을 포스팅하셨다: 스타일 시트를 경량화하는 11가지 팁 18 ↩
쉽게 말해 deprecated는 아직 폐지되진 않았지만 곧 그럴 예정이니 사용을 지양하라는 식의 뜻으로 쓰이고, obsolete는 아예 이제 폐지되어서 작동도 안 된다는 뜻이다.
나도 처음 안 사실이라 링크 및 요약.
