공룡호가 사는 세상 이야기

앞으로 가젯(=위젯?)이 웹에서 상당한 비중을 차지할 수 있다. 아직은 그 미래가 불확실 한 것은 사실이나, 가젯이 가지고 있는 많은 매력들이 그렇게 될 가능성이 충분하다는 것을 시사하고 있다.
아직은 시장이 크지 않지만, 국내 포털에서도 위젯을 개발할 수 있는 환경을 제공하고 있다. 사실 DAUM의 위젯뱅크는 구글의 그것을 그대로 가져와서 사용했다. 아직, 많은 숙제들을 안고 있긴 하지만, 많은 이들이 여기에 관심을 내보이고 있는 데에는 나름의 이유가 있다. 가젯? 위젯? 그게 뭐냐고? 그것의 정의를 일러주면 아! 하고 이해할 수 있을 것 같은가. 그것이 무엇인지, 어떤 이유로 누구를 이롭게 하는지에 대한 막연한 궁금증 들은 일단 만들어 보면 대부분 이해할 수 있지 않을까.

 MLB Batting Stats

구글 차트 API, 구글 스프레드시트 API, 구글 가젯 API, 이 3가지 API를 통하여, 메이저리그 야구 팀의 최신 타율을 표시하는 재미있는 야구 핵을 구현한다. 예제는 파이썬으로 진행된다.
특히나 스프레드시트 API는 정말로 유용하다. 길어질 수 있는 코드를 작성해야 하는 수고를 덜어준다.
구글 가젯 만들기에 관련된 article을 몇몇개 리뷰했었는데, 이것이 조금 어렵다고 느끼는 분들은 그 중 가장 쉬웠던 것을 찾아 먼저 하는 것도 좋겠다. 우측 위에서 '가젯'이라 검색하면 될거다. 아마도.

가젯이 할 수 있는 일은 상당히 많다. 내가 필요한 것은 다른 누군가에게도 필요하지 않을까.
이번 주말에는 간단한 가젯을 구상하고, 개발하는 것도 좋은 일이다.
부쩍 차가워진 날씨에, 따뜻한 블랙커피도 함께.

링크 : http://www.ibm.com/developerworks/kr/library/wa-googlecode1/

요즘 괜찮은 아티클이 많이 올라온다.
셸 스크립트. 유닉스의 꽃이라 해도 과언이 아닐 정도로 필요하고, 유용하고, 멋지다.
예전에 도스(DOS)를 이용해 본 사람이라면, 확장자가 'bat'로 되어 있는 batch 파일을 알고 있을 것이다. 스크립트라는 말에서 느낄 수 있듯, 프로그램 언어와 배치파일 사이에 있는 정도라고 이해하면 되겠다.
도스를 몰라도 상관없다. 순차적으로 어떠한 일을 해야 하는데, 그 일이 단순한 반복 작업을 계속해야 한다면, 이를 미리 정의 해 두고, 자동적으로 실행하고 싶다는 생각은 누구나 할 것이다. 비슷하다고 생각하면 이해가 쉽다.

프로그램을 조금 해 보신 분들이라면 syntax만 파악하셔도 될 것 같다. 프로그램 언어를 배우면 가장 먼저 배우게 되는 변수, 표준 입/출력/오류, 함수, if-else, case문 등의 분기분 차례로 튜토리얼이 진행되는데, 평소 셸 스크립트를 한번 공부해보고 싶었거나, 유닉스에 대해 이제 조금 뭔가 알아갈 것 같다. 하시는 분들에게 권한다.

유닉스를 만지면 언젠가는 부딪혀야 하는 셸 스크립트. 잘하든 못하든 일단 다룰 줄은 알아야 될 것이다.
그 기본이 되는 아주 기초적인 문법부터 시작하고 있으며, 생각보다 자세하다.
유의해서 보아야 할 것이 있다면 오류처리 부분. 내가 생각하는 대로 늘 스크립트가 작동할 것이라는 생각은 하지말도록 하자.
1~2시간만 시간을 투자한다면 아래 코드를 이해하고 작성할 수 있게 될 것이다.'

$vi my_second_script.ksh
#!/bin/ksh
###################################################
# 작성자: Jason Thomas
# 목적: 이 스크립트는 첫 스크립트를 개발하는 방법을 보여주기 위해 작성했다.
# 2008년 5월 1일
###################################################

# 변수 정의
HOME="/home/jthomas" # 간단한 홈 디렉터리
DATE=$(date +%H%M) # 콘 셸 명령인 date를 수행한 결과를 DATE에 저장한다.
HOSTNAME=$(hostname) # HOSTNAME은 hostname 명령을 수행한 결과를 저장한다.

##################
function if_error
##################
{
if [[ $? -ne 0 ]]; then # 함수에 전달하는 오류 코드를 점검한다.
    print "$1" # if rc > 0이면 오류 메시지를 출력하고 끝낸다.
exit $?
fi
}
if [[ -e /tmp/file ]]; then  # 먼저 파일이 존재하는지 살펴본다.
   rm -f /tmp/file # 파일 삭제
   if_error "Error: Failed removing file /tmp/file"
else
   print "/tmp/file doesn't exist"
fi

if [[ -e /tmp/test ]]; then
     mkdir /tmp/test # 디렉터리 test 생성
     if_error "Error: Failed trying to create directory /tmp/test"
else
     print "Directory exists, no need to create directory"
fi

case $TIME in
                 "2200")
                  rm -f /tmp/file1
                        ;;
                  "2300")
                  rm -f /tmp/file1
                        ;;
# 스크립트 끝
esac

결론에서도 말하고 있듯, 스크립트 헤더를 작성하고, 변수를 정의한 다음, 오류를 점검하는 순서로 배우도록 하자.
진짜, 익숙해지면 모든 작업을 스크립트로 하려고 들게 된다-_-

링크: http://www.ibm.com/developerworks/kr/library/au-kornshellscripting/

유닉스는 어렵다. 쉽지 않은 게 사실이다.
혹자는 말한다. 알고 보면 유닉스도 쉽다고? 그런데 모르는걸 어쩌나.
일단 텍스트 기반에, 명령어를 모르면 어디서 시작해야 할 지 조차 알 수가 없다.
언젠가 부터, 정말 쉬운 유닉스 강좌를 한번 해보고 싶다는 생각을 했다.
dW 연재는 튜토리얼 4편으로 나뉘며, 사용자 관점에서 기본적인 유닉스 사용법을 소개한다.
유닉스 계정만 하나 있으면 되니, 접속 할 서버가 없다면, VMWARE나 Virtual Box에 유닉스 하나 얹어놓고, 조금씩 따라 해 보자.

먼저 가장 많이 쓰는 명령어들 부터. ls, cd, pwd, mkdir, rmdir, 디렉토리 구조.
파일에 관계된 touch, cp, mv, rm,  소유권/권한에 관계된  chown, chgrp, chmod,
여러 파일을 한꺼번에 다루는 와일드 카드와 재귀(사실 별건 없다 -R 옵션으로 반복 작업을 자동화 하는 것 뿐)
압축에 관계된 tar, gzip,  파일시스템과 파일 크기에 관련된 df, du, /dev, mount, umount
입력과 출력에 관계된 stdin, stdout, redirection, cat, more, head, tail, grep, 파이프 연산자 까지.

사실 위에 것들만 다 알아도, 기본적인 유닉스 운영에는 큰 무리가 없을 정도로 중요하고 많은 비중을 차지하는 것들이다. 하지만, 조금 아쉬운 부분은, 파일시스템에 대한 설명이 조금 약하다 싶다.
윈도우 파일 시스템에 익숙해져 있는 이들이 df 명령어에 대한 간략한 설명과 다음 결과값으로, 어떻게 이해를 할 것인가.

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             7.9G  3.7G  3.9G  50% /
none                  3.9G     0  3.9G   0% /dev/shm
/dev/sda3              24G   20G  1.9G  92% /export


/dev/sda1이 총 7.9G 이고 그 중, 3.7G를 사용하고 있고 3.9G가 남아있다는 것은 알겠다.
그런데, 대체 /dev/sda1 은 무엇인지, / 과 Mounted on은 무엇인지에 대한 설명이 없다.
파일시스템에 대한 사전지식이 없는 이들이 이해하기에는 다소 무리가 있다 싶지만, 의욕있는 분들은 알아서 검색을 통해서 난관(?)을 헤쳐가시리라 믿는다. 그래도 이해가 어렵거나, 궁금한 것이 많아서 미치겠다 하시는 분들은 메일 또는 댓글을 통해 질문을 주시면 성실히 답변을!

총 4편이 연재될 것이고 다음 편 부터는 vi나 shell을 사용하는 기교와 팁을 다룬다고 하는데,
어려워 질 수록 더 자세한 설명이 필요한 것은 당연하다. Part 1에서 아쉬웠던 부분이 좀 더 보완되었으면 하는 바램이다.

링크 : http://www.ibm.com/developerworks/kr/library/tutorial/au-dw-au-unixtips1-i.html
원문 : http://www.ibm.com/developerworks/edu/au-dw-au-unixtips1-i.html

예제 애플리케이션 테스트 및 검증 페이지

출장 때문에 너무 늦었다 -_-...
개발 또는 테스트 용도로 아파치 톰캣 서버 설치와 설정에 대해서 단계별로 알아보자.
몇 년전, 개인 홈페이지를 운영하기 위해서 아파치, PHP, MYSQL을 유닉스 위에 설치하고 설정을 시도했던 적이 있었다. 모든 것은 소스를 받아 다시 컴파일 하여 설치하고, 설정할 것은 무엇이 그렇게 많은지, 끝내 성공하긴 했지만, 굉장히 힘들었던 기억이 든다.

웹 사이트가 어떻게 돌아가는지, 브라우저에서의 어플리케이션 접근에 대한 최소한의 공통 분모로 무엇이 필요할 것인지 기본적으로 인지하고 있고, 웹 혹은 어플리케이션 서버에 필요한 내용을 알고, 유닉스 서버에 접근할 수 있다면 다음 튜토리얼을 따라 해 보자. 튜토리얼은 다음과 같은 내용을 담고 있다.

  • 아파치 톰캣과 유닉스에 대한 소개뿐 아니라 시작하기 위해 필요한 것들에 대한 소개
  • 엔터프라이즈 웹 아키텍처 대 독립형(stand-alone) 웹 아키텍처에 대한 비교
  • 아무것도 설정되어 있지 않은 유닉스 서버에 웹 혹은 애플리케이션 서버 설치 준비
  • 톰캣 웹 서버 설치와 시작 방법에 대한 상세한 단계별 지시
  • 톰캣 웹 애플리케이션 매니저(Tomcat Web Application Manager) 접근 설정 정보
  • 예제 애플리케이션 배치에 대한 지시 사항
  • 추가적인 내용
  • 서버에 유닉스를 설치하고, 10GB 이상의 디스크 용량과 512M 이상의 메모리, 웹 브라우져 하나, JRE 5.0이상, C컴파일러를 준비하면 튜토리얼에 대한 준비가 끝났다.
    굉장히 상세하게 되어 있지만, 번역이 조금 아쉬운 부분도 없잖아 존재한다.
    원문을 원하시는 분을 위해서 원문도 링크한다. 대부분 이런 설치/설정에 관한 문서는 누군가의 경험에 의한 문서들이 많다. 따라서, 적용도 힘들고, 제작자와 동일한 환경이 아니면 실패할 확률도 높다.
    요즘은, NT환경에서 위와 같은 구성을 하는 경우도 종종 있다.. 하지만, 왜 유닉스에서 이들을 설정해야 하는지, 왜 필요한지 아는 분들은 알 것이다. 따라 해 볼까.

    링크(한글) : http://www.ibm.com/developerworks/kr/library/tutorial/au-dw-au-webdevserver-i.html
    링크(원문) : http://www.ibm.com/developerworks/edu/au-dw-au-webdevserver-i.html


    XML이 처음 세상에 알려진 때는 나도 언제인지 모르겠다.
    다만 나는 내가 스무살이었을 때, 그러니까 2001년도, 내 주위의 많은 컴퓨터 공학도 들이 조금씩 관심을 가졌었던 것 같다. 나도 덩달아 잡지도 보고 책도 구해 보곤 했었지만, 그 당시 내가 익힐 수 있었던 것은 HTML과 같이 정형화된 문법의 틀을 벗어나, 사용자가 정의할 수 있는 문서를 만들 수 있구나. 하는 것이 전부였다.

    이제, XML은 개발자에게 필수 불가결한 언어로 자리잡았다. 많은 이들이 XML을 사용하고 있고, 또 많은 이들이 XML에 입문을 시도하고 있을 것이다. 현재 능숙히 사용하는 사람도, 입문하려는 사람들에게도 도움이 될 만하다. 사실 읽어 보면, 너무 당연한 이야기 아니냐고 반문할지도 모르겠다. 하지만, 언제나 원칙은 잘 지켜지지 않는다. 한 번쯤 되새겨 볼 만한 내용. 

    1. XML과 인코딩을 정의하라
    2. DTD 또는 XSD를 사용하라
    3. 항상 검증하라
    4. 때로는 검증으로 부족하다
    5. 엘리먼트냐 속성이냐
    6. XPath를 활용해 정보를 찾자
    7. 정보 인출을 위해 반드시 구문분석기를 사용할 필요는 없다
    8. SAX가 DOM보다 나은 경우
    9. DOM이 SAX보다 나은 경우
    10. 좋은 XML 편집기를 사용하라

    좋은 습관을 가지면, XML의 장점과 기능을 100%활용하기 쉬워진다. 초보적인 검증과 구문 분석으로 시간과 노력을 낭비하고 싶지 않다면, 한 번 정독 후, 위 10가지를 인쇄하여 책상앞에 '탁' 붙여주는 센스-
    (이미지 출처:imagebank)

    링크 : http://www.ibm.com/developerworks/kr/library/x-tengoodxmlhabits.html



    사람과 컴퓨터 사이의 인터페이스는 끊임없이 변화하고 있다.
    요즘은 대부분 GUI환경이지만, CLI사용법을 배운 적이 없거나 기초를 다시 한번 되새김질할 필요가 있다면, 이 기사가 도움이 되지 않을까. GUI로의 변화는 다른 시각에서는 기능 상실을 의미하며, 사용자로 하여금 더 이상 무언가를 익히는 것을 꺼려하는 경향을 만들어 냈다고 볼 수 있다. 좀 더 편하고 직관적인 형태로 변화하는 지금의 GUI가 항상 올바를 방향을 지향했다고 보기는 어렵다.

    유닉스는 CLI이다. 어렵고 까탈스러우며, 낯설다. 하지만 세밀하고, 심플하며, 무엇보다 강력하다. 이를 아는 많은 이들이 유닉스를 현존하게 해 주었으며, 이 기사에서는 좀 더 능숙하게 유닉스를 다루기 위한 내용을 포함하고 있다.

    명령행이 무엇인지, 셸은 또 무엇인지, 그 역사와 가계도.
    그리고, 콘 셸(ksh)과 세부적인 환경 설정 및 활용, 마지막으로 셸 스크립트에 대한 내용까지.
    하단에 위치한 참고자료 또한, 많은 도움이 될 터.

    링크 : http://www.ibm.com/developerworks/kr/library/au-speakingunix_commandline/

    프로젝트 문서화는 소프트웨어 제품을 내 놓을 때, 종종 필요악이 됩니다.
    참 맞는 말이다. 개발 할 시간도 없는데 언제 문서까지 만들고 있을까... 실제로, 학부생 때, 프로젝트를 진행 하면서, 중간 보고 때 마다 진척 상황를 문서화 해야 하는 사실이 너무나 귀찮고 어려웠다. 왜 하는 지도 몰랐었던 때가 있었는데, 얼마 후, 코드가 모두 담겨 있는 USB 메모리 스틱을 분실했다. 물론, 백업을 해 두지 않은 잘못이 크긴 하지만, 절망적이었다. 6개월 간의 코드를 분실했다고 생각해 보라.
    형식도, 정형화도 되어 있지 않은 내 나름대로의 문서였지만, 나는 그 간의 문서들을 기초로 다시금 코드를 작성했고, 기간은 한 달도 채 걸리지 않았다. 그러나 여전히 필요악인 건 사실인..가(?)

    문서화는 중요하다. 진행 중인 프로젝트의 팀원이 변경 되거나, 통채로 중지했다 다시 시작하거나, 실수로 데이터를 유실했을 여러가지 경우에 대해서 문서는 정말 중요한 수단이 된다. 그러나, 개발 할 시간도 부족한데, 일일이 문서를 만드는 것을 좋아 할 개발자가 어디있겠는가.. 비슷한 맥락에서 다음 내용을 보자.

    내 경험에 비춰봤을 때, 두 개의 핵심 문제 때문에 소프트웨어 개발 문서화가 병들고 있다. 첫 번째는 아무도 그것을 읽지 않을 것이라는 가능성 때문이다. 두 번째로 흔한 문제는 문서 작성 시기가 거의 대부분 지연된다는 것이다.

    그러면 문서작성을 자동화 하는 것을 생각해 볼 수 있다. 코드가 작성될 때 마다, 버튼 한 번으로 문서를 작성할 수 있다면, 그것을 항상 최신 상태로 유지함으로써 프로젝트에 참여한 모든 인원들 그리고 사용자 까지도 더 유용하게 만들 수 있다.
    과연, 어떻게 그것을 자동화 할 수 있을까? dW에서 그 해답을 찾아보는건?

    원문보기
    http://www.ibm.com/developerworks/kr/library/j-ap06108/

    유닉스에서 셸이란 명령줄이라고도 하는데, 운영체제 상에서 다양한 운영체제 기능과 서비스를 구현하는 인터페이스를 제공하는 프로그램이다. 사용자와 운영체제의 내부(커널) 사이의 인터페이스를 감싸는 층이라는 의미에서 셸 이라는 이름이 붙여졌다. 셸은 그 종류가 다양한데, 그 종류별로 세부적인 기능의 차이들이 조금씩 존재한다. 또한, 셸 스크립트 문법도 조금씩 다른데, 사용자 별로 자신에게 익숙한 셸이 하나씩은 있기 마련이다.

    dW에서 소개하고 있는 배시(bash) 셸은 거의 모든 유닉스기반에서 활용 가능한데, 이번 튜토리얼에서는 배시 셸에 대한 간략한 역사, 주요 기능을 다루며, 유닉스 파일시스템, 디렉토리와 파일 조작방법 등을 설명하고 있다.

    • 배시 개괄
    • 배시에서 명령 행 프롬프트로 작업하기
    • 배시에서 파일과 디렉터리 다루기
    • 배시 개인화하기
    • 배시 작업 제어

    이 튜토리얼을 읽기 위한 시스템 요구 사항은 없다. 단지 글을 읽고 배시를 익히면 된다. 하지만 이 튜토리얼을 최대로 활용하려면 튜토리얼이 제공하는 기법을 시도할 필요가 있다. 이렇게 하려면 버전 2.05 이상인 동작하는 배시 셸이 필요하다. 컴퓨터에 설치된 배시 셸 버전을 모른다면, 배시 셸 홈 페이지를 방문해 필요한 정보를 얻기 바란다.

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

    NIS(Network Information Service)는 유닉스, 리눅스 사이에서 시스템 파일 등을 NIS map 형태로 도메인에 참가하고 있는 이들끼리 공유하는 서비스이다. 방법은 NFS, automounter 등이 있다. 유닉스와 리눅스는 비슷하나, 두 시스템을 통합하는 과정을 어렵게 하는 몇 가지 중요한 차이점이 있다.
    아직도 NIS가 무엇인지, NIS로 둘을 통합하는 것이 과연 어떤 의미를 지니는지 잘 모를 것이라 생각한다.

    좀 더 자세히 이야기 해 보자. 최초 SUN에서 처음 개발되어 현재는 거의 모든 UNIX 시스템에서 사용되는 대표적인 통합 서비스이다. 기본 개념은 서버에 저장된 /etc 환경파일 정보를 유닉스 클라이언트들이 공유하는 서비스이다. 보통은 윈도우즈의 도메인 개념과 비슷한데, 서버에 저장된 사용자들은 클라이언트에서도 로그인 및 서비스를 이용할 수 있다는 의미가 된다.
    유닉스 서버와 워크 스테이션들이 단일한 공간에 많이(10대 이상) 설치되어 있는 경우, NIS를 이용하면 편리하나, 실제로 많이 쓰이지는 않는다. 그래서 연구기관이나 학교같은 실습 장비가 많은 곳에 주로 사용되기도 한다.
    이제, 조금 감이 오는지?

    이러한 NIS를 이용하여, 유닉스, 리눅스간 통합에 대해서 dW에서 다루고 있다. 구조는 다음과 같다.

    NIS 마스터와 슬레이브 구조

    이를테면, 사용자가 암호를 변경할 때, 사용자가 NIS 데이터베이스에 직접 변경을 가하면 NIS 마스터로 변경 내역이 전해지며, 데이터베이스를 갱신하고 슬레이브 서버에 변경 내역을 전파하게 된다. NIS 데이터베이스에 변경이 일어나면 변경이 일어난 시점에서 슬레이브 서버로 자동으로 전파되며, yppush 명령을 사용하여 수동전파가 가능하다. 그럼, NIS 구성에 대해서 알아보자. NIS는 무엇보다 OS나 머신에 무관하게 파일시스템을 통해 각자의 파일과 자원을 계속 사용할 수 있다는 점이다.

    자세한 내용과 구성방법 등에 대해서는 아래에서 확인하자.
    http://www.ibm.com/developerworks/kr/library/au-linuxtogether/index.html

    포스팅을 해 놓고 비공개로 설정된 것을 몰랐다니...-_- 어쨌든 이달 마지막 리뷰.
    간단한 이야기를 하나 해 보자.

    '갑' 기업의 새로운 업무 프로세스를 '을'기업에서 저렴한 비용으로 개발을 하게 되었다.
    많은 회의 끝에 시스템이 도입되었고, 해당 시스템 위에서 6개월간 개발되었다.
    6개월 후, 프로그램 테스트에서 결함이 발견되었다. 다름아닌 '성능'이었다.
    개발의 완료단계에서 '성능'이 이슈가 되어 '을'은 굉장히 당황스러웠다.
    결국은 시스템의 하드웨어를 증설하여 성능 문제를 어느정도 개선시킬 수 밖에 없게 되었다.

    이러한 사례를 가끔 보게되는데, 요즘같은 고성능 하드웨어 시대에서 조차 프로그램 성능을 고려하지 않을 수는 없다. dW에서 자바코드 벤치마킹을 두 편에 걸쳐 연재하게 되었는데, 그 첫번째가 번역되었다.

    Listing 1. 성능 수수께끼

    protected static int global;

    public static void main(String[] args) {
        long t1 = System.nanoTime();

        int value = 0;
        for (int i = 0; i < 100 * 1000 * 1000; i++) {
            value = calculate(value);
        }

        long t2 = System.nanoTime();
        System.out.println("Execution time: " + ((t2 - t1) * 1e-6) + " milliseconds");
    }

    protected static int calculate(int arg) {
        //L1: assert (arg >= 0) : "should be positive";
        //L2: if (arg < 0) throw new IllegalArgumentException("arg = " + arg + " < 0");

        global = arg * 6;
        global += 3;
        global /= 2;
        return arg + 2;
    }


     다음 중 어느 버전의 실행 속도가 가장 빠를까?

    1. 코드를 그대로 둔다(calculatearg를 테스트하지 않음).
    2. L1만 코멘트를 해제하지만 조건 확인(assertion)은 비활성화하여 실행(JVM 옵션 중 -disableassertions 사용. 이는 JVM의 기본 동작임)
    3. L1만 코멘트를 해제하지만 조건 확인은 활성화하여 실행(JVM 옵션 중 -enableassertions 사용)
    4. L2만 코멘트를 해제한다.

    적어도 테스트를 전혀 하지 않는 A가 가장 빠를 것이라고 짐작할 것이다. 그리고 좋은 동적 최적화 컴파일러가 죽은 코드인 L1은 제거할 것이므로, 조건 확인을 끈 B쪽이 A에 근접한 성능을 보일 것이라 짐작하리라. 그렇지 않은가? 불행히도 이러한 짐작은 틀렸다. 위의 코드는 Cliff Click이 2002 자바원(JavaOne)에서 소개한 것을 수정하였다. 그가 발표한 실행 시간은 다음과 같다.

    놀라운 결과와 다양한 이슈들은 아래 링크에서 확인하자.
    링크 : http://www.ibm.com/developerworks/kr/library/j-benchmark1.html#listing1

    마음이 급하여 Part 2의 원문을 확인하고 싶으신 분들은 아래로.
    링크 : http://www-128.ibm.com/developerworks/java/library/j-benchmark2/

    'IBM dW review' 카테고리의 다른 글

    배시 셸로 작업하기  (0) 2008.08.31
    유닉스와 리눅스 함께 어울리기.  (0) 2008.08.31
    Ajax에서 XML 처리하기, Part 3  (0) 2008.07.30
    10가지 더 좋은 유닉스 습관  (0) 2008.07.30
    Ajax에서 XML 처리하기, Part 2  (0) 2008.06.30