공룡호가 사는 세상 이야기

네트웍 인프라가 너무나 좋아지면서, 대충 설계하고 무거운 이미지를 덕지덕지 붙여놓고, 각종 스크립트들로 도배를 해 놓아도, 요즈음은 큰 불편함이 없이 웹서핑이 가능하다. 그러나, Birds-Eye의 2007년도 Broadband Statistics에 따르면 미국 인구의 25%는 인터넷을 사용하지 않고 있으며, 53%는 광대역을 사용하고 있고, 21%는 아직까지도 전화 접속을 사용하고 있다.
내가 설계한 웹 페이지는 www를 통해 전 세계로 공유가 되는데, 광대역 연결을 사용하는 사람들만 고려할 수만은 없다.
developerWorks에 소개되었는데,

1. 좋은 구조 사용하기
2. 레이아웃을 오버로드 하지 않기
3. 이미지로 텍스트 표시하지 않기
4. 쿠키 사용 검사하기
5. 필요없는 JavaScript 코드를 포함하지 않고 가능한 한 외부화 하기
6. 되도록이면 테이블 사용하지 않기
7. 불필요한 항목 제거하기
8. HTTP 압축을 사용하고 항상 소문자 div 및 클래스 이름 사용하기
9. 이미지 크기 설정
10. 스크립트 로드를 지연시키기
11. CSS파일 최적화하기
12. 컨텐츠 배포 네트워크 사용하기
13. 자산 도메인을 이용하여 연결 수 늘리기
14. Google Gear 사용하기
15. PNG 이미지 사용하기
16. 짧고 적절하기 Ajax 호출 유지하기
17. 핵심 Ajax 호출을 만들고 클라이언트 데이터를 로컬에서 처리하기
18. 코드 테스트
19. 사이트 코드 분석
20. JSLint를 사용하여 JavaScript코드의 오류 또는 잘못된 코드 검사하기
21. 분리된 파일 및 누락된 이미지 검사
22. YSlow 확장
23. YSlow를 사용하여 페이지 분석

잊지말아야 할 원칙들. 기억해 두자.
http://www.ibm.com/developerworks/kr/library/wa-speedweb/index.html

맘에드는 아티클이다. 명령행 기교와 연산자를 익히면 유닉스가 정말 가깝게 느껴진다.
일단 시스템에 문제가 생기거나 점검을 수행할 때, 프로세스를 확인하는 것은 흔한 일이다.
시스템의 퍼포먼스가 떨어졌다던가. I/O가 느려졌다던가.
이유를 찾기 위해선 어떤 프로세스가 CPU나 DISK를 얼마나 점유하고 있는지 찾고,
평소에 그렇지 않은데, 지금 그러한 이유가 무엇인지 찾아나가는 순서로 진행된다.
프로세스를 확인 해 보자.

# ps -ef
     UID     PID    PPID   C    STIME    TTY  TIME CMD
    root       1       0   0   Jul 27      -  0:05 /etc/init
    root   53442  151674   0   Jul 27      -  0:00 /usr/sbin/syslogd
    root   57426       1   0   Jul 27      -  0:00 /usr/lib/errdemon
    root   61510       1   0   Jul 27      - 23:55 /usr/sbin/syncd 60
    root   65634       1   0   Jul 27      -  0:00 /usr/ccs/bin/shlap64
    root   86102       1   0   Jul 27      -  0:00 /usr/lib/methods/ssa_daemon -l ssa0
                                                .
                                            (중략)
                                                .
    root  315646  151674   0   Jul 27      -  0:00 /usr/sbin/lpd
    root  319664       1   0   Jul 27      -  0:00 /usr/atria/etc/albd_server
    root  340144  168018   0 12:34:56      -  0:00 rpc.ttdbserver 100083 1
    root  376846  168018   0   Jul 30      -  0:00 rlogind
 cormany  409708  569522   0 19:29:27  pts/1  0:00 -ksh
    root  569522  168018   0 19:29:26      -  0:00 rlogind
 cormany  733188  409708   3 19:30:34  pts/1  0:00 ps -ef
    root  749668  168018   0   Jul 30      -  0:00 rlogind

실행중인 프로세스만 가지고는 상세한 정보를 알기가 어렵다. 기교를 조금 부려보자.
# ps -ef | grep -E "rpc|ksh" | grep -vE "grep|rpc.ttdbserver" |
   awk -v _MAX_PID=200000 '{if ($2 > _MAX_PID) {print "PID for
   process",$8,"is greater than", _MAX_PID}}'

PID for process /usr/sbin/rpc.statd is greater than 200000
PID for process /usr/sbin/rpc.lockd is greater than 200000
PID for process -ksh is greater than 200000

같은 명령어에서 파생된 결과지만 결과의 질은 달라진다. 내가 원하는 정보를 보다 효율적으로 손쉽게 접해보자.

원문 : http://www.ibm.com/developerworks/kr/library/au-spunix_clitricks/

지난 달 Part 3 에서는 grep, sed, awk 와 같은 명령행 도구의 필터들을 소개했었다. Part 4 에서는 셸 스크립트 기교에 대해서 소개한다. 셸 명령 실행, 산술연산/진법변환, 대화형 셸 스크립트의 기본이 되는 인라인 입력이나 키보드 입력, 루프 등에 대해서 다룬다. 본 셸이 기본 조건이긴 하나 배시 셸도 관계없다.

거두절미하고 아주 짧은 셸 코드 하나를 보자.
for i in ??; { mv $i $i.ppm; }

위 코드는 현재 디렉토리의 파일 이름이 정확히 2글자인 모든 파일의 확장자를 .ppm 으로 변경한다.
i는 파일이며 ??는 파일의 글자 수이다. 루프 내는 for문의 조건이 만족되는 경우 $i를 $i.ppm으로 변경하는 간단한 코드이다. 하나 더 보자.

#!/bin/sh
# baseconv: 진법을 변환하는 간단한 스크립트
#
NUMBER=1
while [ $NUMBER ]; do
    read -p "Input base: " IN
    read -p "Output base: " OUT
    read -p "Number: " NUMBER
    bc -ql <<- EOF
  obase=$OUT
  ibase=$IN
  $NUMBER
  EOF
done

위 코드는 숫자를 입력 진법에서 출력 진법으로 변환한다. 간단하다. 튜토리얼에 모두 설명된 부분.
이번 튜토리얼은 일전에 몇 번 소개되었던 셸 스크립트 관련 아티클에 비해 자세하다. 일전의 아티클을 먼저 읽어 보는 것도 좋을 것 같다. 셸 스크립트의 강력함은 말로 다 할 수 없다. 배워봅시다.~
유용한 인라인 셸 코드들도 존재하니 많은 참고가 되겠다.

원문 : http://www.ibm.com/developerworks/kr/library/tutorial/au-unixtips4/index.html


XML은 이제 선택이 아니라 필수가 되어가고 있다.
구조적인 문서와 데이터를 교환하기 위한 통신 형식으로 충분한 계획/설계 없이 개발 중에 즉흥적으로 선택하는 경우가 많다. 올바른 XML 형식의 설계가 선행되어야, 통신에 참여하는 모든 이들의 요구를 만족시킬 수 있다. 한 개의 XML 스키마를 유지보수 하는 일은 상대적으로 간단하다. 그러나 수백 개 조직에 영향을 미치는 변화는 엄청난 충격이 될 수 있다. 이번 아티클에서는 이 충격을 관리하고 최소화 하는 두 가지 논제에 대해 다룬다.

원문 : http://www.ibm.com/developerworks/kr/library/x-extensxml.html

 

1984년, 너저분한 C코드 대회, 불명예 작품상이다. 무슨 의미인지 해석이 가능한가?
	int i;main(){for(;i["]<i;++i){--i;}"];read('-'-'-',i+++"hell\ 
	o, world!\n",'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);

코드는 내가 작성하지만, 나만 보는 것은 아니다. 그리고, 나만 본다 하여도 이 코드를 언제 다시 살펴보게 될 지는 알 수 없다. 수직 공백과 수평 공백, 들여쓰기와 띄어쓰기를 적절히 활용하여 코드 블록 구조를 효과적으로 표현하고, 주석을 반드시 달되 불필요한 주석은 피한다. 명명규칙을 따르고, 변수 이름, 함수 이름을 효과적으로 정의하고, 선언의 방법과 헤더파일의 선언규칙을 따른다.
항상 오류를 방지하는 방식으로 코드를 구현하고, 코드의 의도를 명확히 밝히는 프로그램을 작성한다.
그 외에도 C프로그램을 작성하면서 지켜야 할 것, 주의해야 할 것 들을 알려주고 있다.

소프트웨어는 유지보수에 상당한 노력과 비용이 소모된다는 사실은 누구나 잘 알고 있다. 이식이 불가능한 비표준 기능을 사용하고, 바람직하지 못한 방식으로 코드를 구현하는 잘못된 습관은 유지보수를 더욱 어렵게 만든다. 아래 원문에서 오랫 동안 유용하게 활용할 구현 지침을 익혀보자

원문 : http://www.ibm.com/developerworks/kr/library/au-hook_duttaC.html



inode는 유닉스에서 사용하는 자료구조로 파일 시스템 내부에 파일을 유지하는 중요한 정보를 담는다. 유닉스에서 파일 시스템을 생성할 때, 수 많은 inode집합을 생성한다. 일반적으로 전체 파일 시스템 디스크 용량의 대략 1% 정도가 inode테이블에 할당된다.

inode 테이블은 개별 파일 시스템을 위한 inode 숫자 목록을 포함한다. 사용자가 파일에 접근하려면, 유닉스 시스템은 올바른 inode 번호로 inode 테이블을 탐색한다. inode 번호를 발견하면, 사용자가 내린 명령이 inode에 접근해서 가능하다면 적절한 변경 작업을 진행한다.

파일과 디렉토리는 inode의 도움 없이는 유닉스 세상에서 거의 쓸모가 없다.
inode로 작업하는 방법을 익히려면 시간도 많이 필요하며 짜증도 난다. 아래 원문의 내용을 읽어가면서 inode에 대해 모를 때 겪었던 두통거리 몇 가지를 완화해보자.

원문 : http://www.ibm.com/developerworks/kr/library/au-speakingunix14/



필터.
사전적으로는 이물질을 걸러내는 장치로 풀이된다.
데이터가 너무 많다 보니 내가 필요한 데이터를 걸러내기란 쉬운 일이 아니다. 이번에는 유닉스 필터에 대해 알아보자. grep, sed, awk 등 세가지 명령행 도구는 자료를 검색하고 조작하는 속력이 훨씬 빨라진다.

grep을 사용하여 파일 내용을 효율적으로 검색하고, sed를 이용하여 많은 파일을 일괄적으로 편집하고, awk는 입력 행에 있는 각 문자열의 단어별 참조를 가능하게 하며, 스크립트로 구현하는 코드에서 변수로도 참조가 가능하게 한다.

원문 : http://www.ibm.com/developerworks/kr/library/tutorial/au-dw-au-unixtips3-i.html




zero copy 기법을 이용하면 리눅스나 유닉스에서 실행되는 I/O 위주의 자바 애플리케이션의 성능을 향상시킬 수 있다. zero copy 기법은 중간 버퍼 간의 불필요한 데이터 복사를 피하게 해 주고, 사용자와 커널 사이의 context switching을 효과적으로 줄여줄 수 있다.
데이터를 소켓을 이용하여 전송하려 할 때, 기존 방식은 디스크에서 해당 데이터를 읽어 커널-사용자 간 경계를 넘어 애플리케이션 단계로 밀어 올리고, 그 것을 다시 소켓에 쓰는 과정에서 커널-사용자 경계를 다시 넘는다. 결국 데이터를 가져왔다가 바로 보낼 건데, 비 효율적으로 중계자를 두고 있다. 이 차이는 매우 적지만, 전송해야 할 데이터 양이 많아질 수록 그 차이는 현격하게 차이나기 시작한다.

자바 클래스 라이브러리에서는 리눅스와 유닉스 시스템에서 java.nio.channels.FileChannel 클래스의 transferTo() 메소드를 통해 zero copy를 지원한다. 이 방법이 왜, 그리고 얼마나 효율적인지 알아보자.

기존 방식의 context switching
기존 방식에서의 맥락 전환


개선된 방식을 사용할 때의 context switching
transferTo()를 사용할 때의 맥락 전환

궁금하지 않은가? 그리고 얼마나 효율적일지도.

원문 : http://www.ibm.com/developerworks/kr/library/j-zerocopy/

유닉스를 자주 다루다 보니, 유닉스 관련 포스팅이 잦다.
지난 달에 포스팅 했던 '콘(Korn) 셸(Shell) 스크립트 작성하기'에 이어 두 번째 리뷰.
지난 번 포스팅이 초보용 이었다면, 이번은 중급용이다. 좀 더 깊게 배우고 싶으면 이번 Article을 주의깊게 보자.
단순하고 유연하게 스크립트를 작성하고, 아무리 강조해도 지나치지 않는 문서화.
그리고 디버깅 까지. 사실 여기서 다루는 디버깅은 환경변수가 올바로 등록되어 있다는 조건 하에서 이루어지는 것이긴 하지만...
그리고 set -x 옵션으로 실행 과정을 표준 출력으로 찍는 것 까지.

작업을 단순하게 만들고 깔금하고 유연하게 코드를 작성하며, 문서로 만드는 기본 규칙을 철저하게 따르면, 이 기사에서 배운 디버깅 기법을 활용해 최상급 스크립트를 작성할 수도? ㅎㅎ
배울 수록 느끼게 되겠지만, 쉘 스크립트로 할 수 있는 일은 생각보다 대단하다.

원문 : http://www.ibm.com/developerworks/kr/library/au-speakingunix_shellscripttech/





개발자들의 수다

IBM developerWorks에서 독자, 필자, 리뷰블로거 등이 함께하는 즐거운 이야기 장을 마련합니다. 이름하여, ‘개발자들의 수다’ 입니다.
이 행사는 '현장에서 참여자들이 토론 주제를 정해서 실시간으로 자유로이 이합집산하면서 토론을 진행'하는 OST(Open Space Technology) 형식으로 진행할 예정입니다.
정해진 아젠다 없이, 현장에서 함께 얘기 나눌만한 주제를 정하거나 건의해서 독자, 필자, 리뷰블로거들이 편안하게 생각을 나누고 그 과정에서 서로 영감을 받을 수 있는 행사입니다.
개발자로서의 진로, 고민이나 기술 및 트렌드에 대한 난상 토론 등 어떤 내용이어도 무방합니다.
독자, 필자, 리뷰블로거가 한자리에 모일 수 있는 올해 처음이자 마지막으로 열리는 이번 행사에서 개발자들의 수다가 활발하게 이뤄지도록 많은 분들의 참석을 기대합니다.

  • 일 시: 11월 8일 토요일 오후 2:00~6:00
  • 장 소: 도곡동 군인공제회관 23층 온디맨드홀 (약도 참고)
  • 참가 신청
    참가 신청은 전자우편(dWkorea@kr.ibm.com)으로 해주시고, 신청시 이름, 소속, 연락처 등을 적어서 보내주시기 바랍니다.
    장소 관계상 참가 신청은 선착순 200명으로 한정하니, 빠른 신청을 부탁드립니다.
  • 그 동안 developerWorks에 기고하였던 김도형, 김석준, 김승권, 김영후, 김창준, 박재호, 송치형, 이영석, 박찬욱, 서광열, 이준하, 지형준, 권용호, 안영회 씨 등 다양한 분야의 전문가들이 참석할 예정입니다.
  • 수다 예고편
    "개발자들의 스타트업과 창업", "나는 어떤 일을 잘 할 수 있는가?", "오픈소스에 대한 나의 생각", "개발자들의 제태크", "개발자와의 연애, 불가능한가?", "여성개발자의 커리어패스", "개발자와 QA, 친해지길 바래" 등 이외에도 참가자들이 즉석에서 주제를 제안할 수 있습니다.
  • 관련기사: 한국IBM, "개발자들끼리 수다 떱시다"
  • * 행사페이지 바로 가기