공룡호가 사는 세상 이야기

vi editor는 VIsual display editor 를 의미한다. 버클리의 어느 천재가 만들었다고 했던가, vi를 만들던 시절에는  ed와 같은 라인 에디터가 일반적이었다. 도스의 edlin이라는 라인 에디터를 사용 해 본 사람이라면 그것이 얼마나 불편한 것이었는지 잘 알 것이다. 유닉스 처럼 텍스트 에디터와 포매터가 분리된 환경에서는 텍스트 에디터의 비중이 크기 때문에 기능 면에서도 많은 요구가 있게 마련이다. 때문에 텍스트 에디터가 워드 프로세서 기능의 상당 부분을 가지게 되었다. 유닉스에 여러가지 종류가 있듯이 vi도 여러가지 클론이 만들어졌다. 요즘 대부분의 배포판에서는 vim이라는 vi의 클론이 포함되어 있다. vim은 완벽하게 한글을 지원하고 원래의 vi의 기능을 충실하게 갖고 있을 뿐만 아니라 여러가지 좀 더 편리한 툴들을 제공한다.
참조(http://blog.paran.com/comembedded)

실제로 필드에서 유닉스나 리눅스를 다루다 보면, vi의 일부 기능만으로 문서를 다루는 것을 종종 본다. 능력이 좋은 것인지, 그만큼 vi가 강력한 것인지는 모르겠지만, 솔직히 vi는 쓰면 쓸 수록 강력하다는 것을 느끼게 해 준다. 특히, 나 같이 키보드에서 손을 떼고 마우스를 움직여야 하는 일이 무엇보다 귀찮은 사람이라면 더더욱.

vi를 처음으로 접하는 사람은 익숙해질 기회를! 경험이 풍부한 사용자는 생각을 정리할 기회를!
http://www.ibm.com/developerworks/kr/library/tutorial/l-dw-linuxvi-i.html

Cheat sheet,             final

학생들이 이야기하는 사진소프트웨어 공학이란 과학적인 지식을 컴퓨터 프로그램 설계와 제작에 실제 응용하는 것이며, 이를 개발, 운영하고 유지 보수하는데 필요한 문서화 과정 또는 소프트웨어 위기를 극복하기 위해 제안된 학문으로 소프트웨어 개발, 운용, 유니보수 및 폐기에 대한 체계적인 접근 방법 또는 최소의 경비로 높은 소프트웨어를 생산하기 위한 기법과 도구 등으로 풀이되고 있다.

이제는 학부 과정에서도 소프트웨어 공학이라는 과목을 가르치고 있으며, 기사 자격증 중 가장 많은 응시생을 가지는 정보처리기사의 5과목 중 한 과목이기도 하다. 대학 초/중반에 개발에 필요한 언어를 가르치고, 중/후반에는 소프트웨어 라이프사이클에 대해 논하면서 유지/보수의 중요성을 대두시킨다. 그에 따라 반드시 필요하거나 배워야 할 것은 소프트웨어 공학이며, 대학 3,4학년의 필수과목으로 채택하는 학교도 적지 않다.

애자일 공동체를 위한 전자 잡지인 애자일 저널 11월호에 Daryl Kulak이 쓴 "소프트웨어 공학이라는 용어를 묻어버리자" 라는 기사가 실렸다. Kulak이 독자들에게 전달하고자 했던 메시지는 무엇일까?

http://www.ibm.com/developerworks/kr/library/08/jan08/pollice/

이제, XML은 선택이 아니라 필수가 되어가고 있다.
Ajax에서 XML데이터를 처리하는 방법은 제각기 다르다. 무식하게 엘리멘트/노드 들을 파싱하는 단순 노가다의 반복부터 DOM, XSLT 등을 이용하는 방법까지.
과연 어떤 방법으로 XML을 다루는 것이 좋을까? 정답은 '없다'다. 모든 것은 상황에 따라 변하니까.
하지만, 최적의 방법을 선택하기 위해서는 많은 방법들을 알고 있어야 하며, 그 방법들의 장/단점에 대해서도 알고 있어야 함은 물론이다.

dW에서 이달 초에 다룬 기사 중에서 이러한 접근을 보다 수월하게 가능케 해 주는 기사가 있어 소개코자 한다.
XML을 처리하는 Ajax 뱃지(위젯)을 간단하게 작성하는 과정을 다루는데, 다음 4가지 방법으로 XML에 접근한다.

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

1. DOM 트리 탐색
2. 서버쪽 XSLT
3. 클라이언트쪽 XSLT
4. JSON과 동적 스크립트 태그

Ajax 날씨 뱃지

Part 1에서는 DOM 트리 탐색 방법을 이용하고 있는데, 사실은 2,3,4번 방법이 업데이트 되면 비교해서 리뷰하려 했지만 아직 소식이 없다.(곧 업데이트 될 듯 한데, Part 2에서는 2,3번 방법을 다룬단다.) 접근 방법 1을 위한 데이터 라인을 보면 다음과 같다.
접근 방법 1을 위한 자료 파이프라인

대충 감이 오는지?
세부 내용을 읽고, 기사에서 말하는 장/단점 외에도 추가적인 부분이 있는지 고민해 보는 것도 좋을 듯.
Part 2를 기다려 보자.

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

엔디안 방식에 구애 받지 않는 C코드 작성하기
http://www.ibm.com/developerworks/kr/library/au-endianc/


big-endianlittle-endian은 메모리에 저장된 바이트들의 순서를 말하는데, 빅엔디안은 큰 쪽(바이트 열에서 가장 큰 값)이 먼저 저장되는 순서이며, 리틀 엔디안은 작은 쪽(바이트 열에서 가장 작은 값)이 먼저 저장되는 순서이다. 예를 들면 빅 엔디안 시스템에서는 16진수 "4F52"를 저장공간에 "4F52"라고 저장할 것이다.(만약 4F가 1000번지에 저장되었다면 52는 1001번지에 저장) 반대로, 리틀 엔디안 시스템에서는 거꾸로 "524F"로 저장된다.

리틀 엔디안을 사용하는 대표적인 CPU는 Intel 계열 CPU이며, 빅 엔디안을 사용하는 가장 대표적인 CPU는 Sparc 계열 CPU이다. 즉, 사용하려는 시스템 CPU의 엔디안 방식에 따른 호환성의 문제가 발생할 수 있게 되는데, 아키텍처, 프로세서, 네트워크 스택, 통신 프로토콜은 모두 특정한 시점에서 엔디안 방식을 정의해야 하는데, 엔디안 방식이 코드에 영향을 미치는 경우, 런타임시 엔디안 방식을 판별하는 방법, 코드에서 바이트 순서를 뒤집어 엔디안 방식에 구애 받지 않는 방법을 알아보자.

예제 : 엔디안 방식을 모르고 프로그램을 작성할 때 발생하는 위험

#include <stdio.h>
#include <string.h>

int main (int argc, char* argv[]) {
    FILE* fp;

    /* 예제 자료 구조 */
    struct {
        char one[4];
        int  two;
        char three[4];
    } data;

    /* 예제 자료 구조를 채운다. */
    strcpy (data.one, "foo");
    data.two = 0x01234567;
    strcpy (data.three, "bar");

    /* 자료 구조를 파일에 쓴다. */
    fp = fopen ("output", "wb");
    if (fp) {
        fwrite (&data, sizeof (data), 1, fp);
        fclose (fp);
    }
}

위 코드는 모든 시스템에서 문제 없이 컴파일이 되나, 엔디안 방식에 따라 결과는 크게 다르다.(hexdump)

빅 엔디안 (hexdump -C)

00000000  66 6f 6f 00 12 34 56 78  62 61 72 00              |foo..4Vxbar.|
0000000c

리틀 엔디안 (hexdump -C)

00000000  66 6f 6f 00 78 56 34 12  62 61 72 00              |foo.xV4.bar.|
0000000c

이처럼, 엔디안 방식을 고려하지 않은 코드는 예상치 못한 곳에서 복병을 만날 수 있다.
엔디안 방식이 코드에 영향을 미치는 경우, 런타임 시 엔디안 방식 판별, 네트웍 바이트 순서, 바이트 순서 뒤집기 등으로 구성된 재미있는 기사였다.

요즘 SPARC장비들과 매일 씨름을 하고 있다 보니, 관심이 가지 않을 수 없었다. 미션 크리티컬한 업무가 운영중인 시스템들을 다루다 보니 요즘은 특히나 더 조심스러워 진다. 프로그래머도 마찬가지가 아닐까? 플랫폼이 어떤 엔디안 방식을 사용하든 실패하지 않는 코드를 구현하는 것 또한 프로그래머의 몫이리라.

- 전통적인 RSS
RSS는 RDF site Summary, Rich Site Summary 등의 약칭으로 뉴스나 블로그와 같이 컨텐츠 업데이트가 잦은 웹사이트에서 업데이트된 정보를 사용자들에게 쉽게 제공하기 위해 XML을 기초로 만들어진 데이터 포멧이다.
기존 웹 사이트들이 서비스했던 일방적인 메일링 서비스는 해당 사이트 관리자가 일방적으로 내용을 요약하여 발송하는 수동적인 형태였다면, RSS는 하나의 웹 사이트 내에서도 원하는 카테고리의 내용만을 수집할 수 있다는 점에서보다 진보적이고 능동적인 형태를 취한다.

- 새로운 한계 RSS
이것이 많은 사람들이 RSS를 사이트 피드 같은 배급의 목적에 사용한다고 알고 있는 내용이나, 몇 년 전부터 데이터 배포나 연락처 관리와 같은 목적으로 여타 애플리케이션의 저장 포멧으로도 쓰여왔다.
즉, 데이터를 RSS 형태로 저장함으로써 RSS 수집/구독 프로그램을 데이터에 접근하는 데에도 사용할 수 있다는 의미가 되는데, 예전의 관계형 데이터에서 저장되었던 방식으로 RSS를 사용하여 정보를 저장할 수 있게 된다.

- 튜토리얼에 대해
RSS 포멧과 몇 가지 실제 피드 샘플을 소개하는 것을 시작으로 기존 포멧을 바꿔 이를 다른 목적을 위해 재정의 한다. 테이블 세 개로 데이터베이스 포멧을 정의하고 이 테이블들을 쿼리하여 전통적인 SQL SELECT 모두를 흉내낼 수 있음을 보여주고 결합적 룩업을 제공한다. 마지막으로 쿼리의 결과를 처리하거나 XML폼으로 남겨두거나 이를 XSLT를 사용하여 사용자에게 보여줄 수 있는 다양한 방법으로의 변환법에 대해서도 다루고 있다.

- 코멘트
RSS를 데이터 수집을 보다 효과적으로 하기 위한 용도로 사용되는 것이나, 대부분 웹사이트, 블로그, 뉴스 등의 기사들을 수집하는데 이용되었던 것이 사실이다. 하지만 기본 포멧만 갖춘다면 기존의 수집기를 사용하면서도 또 다른 의미를 가지는 데이터들을 효과적으로 수집/관리할 수 있게 해 줄수 있다는 점에서 재미있는 시도이다. 그리고 실제로 충분히 흥미롭다. 그룹 내에서 서로의 연락처와 그에 관련된 각종 정보들을 공유하는 방법, 일정 관리에 적용하는 방법 등 시도해 볼 만한 곳이 많을 것이다. 아래 원문의 튜토리얼과 그에 따른 참고사항을 링크한다.

원문 : http://www.ibm.com/developerworks/kr/library/tutorial/x-rssdatabase/index.html
참고 : http://www.ibm.com/developerworks/kr/library/tutorial/x-rssdatabase/resources.html

이 튜토리얼을 어렵지 않게 수행해 낸 사람이라면, "사용자 정의 가능한 RSS 피드 수집기 구현하기" 기사에도 관심을 가져보기 바란다. ( http://www.ibm.com/developerworks/kr/library/wa-aj-rssphp/ )

JSEclipse를 이용하는 사람들이 꽤 늘었다.
네이버에서 JSEclipse만 쳐도 꽤 많은 플러그인 자료를 찾을 수 있을 정도이다.

튜토리얼이다. 보다 편하게 자바스크립트 개발을 하고자 한다면 이클립스 플러그인, JSEclipse 툴을 살펴보면서 이것이 제공하는 코드 완성, 템플릿 같은 기능도 살펴볼 수 있다. Firebug라 하여 좋은 디버깅 기능도 다룬다.
Java가 Eclipse에 강력한 지원을 받은데 비해 자바스크립트는 그렇지 못했다.

IBM dW 의 Article에 이러한 자바스크립트 개발 도구(JSEclipse)가 소개되었다.
한글인데다 튜토리얼이다. 이클립스를 설치하고 붙여서 사용할 수 있다.
차근차근히 다음 내용에 대해 배워보자.

  • JSEclipse 설치하기
  • JSEclipse 설정하기
  • JSEclipse 기능 사용하기
  • 내용을 웹 페이지에 새로운 동적으로 만들기
  • 자바스크립트 클래스를 사용해 진화하는 "생명체" 만들기
  • 계속 움직이는 개체 만들기

    링크 : http://www.ibm.com/developerworks/kr/library/tutorial//os-dw-os-eclipse-jseclipse.html

  • - 중략. (송치형 scroco@naver.com) 님의 글
    Hibernate는 RDB와 객체간의 Gap을 채워줌으로서 프로그래머가 DB를 객체를 다루듯 이용하게 해 준다.
    이를테면, SQL은 RDB에 쿼리를 날리지만, HQL은 객체에 쿼리를 날린다. 그러면 어떻게 객체와 RDB를 매핑할 것인가? XML 매핑 파일이나 어노테이션을 이용하는 방법 등이 있다.

    RDB를 객체처럼 다룰 수 있도록 해 주는 ORM의 개념은 좋지만 Hibernate를 사용하면서 가장 불편한 점은 매핑 파일을 작성하는 것인데, 물론 Ant를 이용해서 DB스키마를 통해 매핑 파일을 만들고, 매핑 파일을 통해 POJO를 만들 수 있다. 하지만 별도의 XML 설정 파일을 관리하는 건 귀찮은 작업니다.

    특히 Ruby on Rails에서 제공하고 있는 ORM 프레임워크인 ActiveObject를 사용하면서 Hibernate의 설정 파일 관리가 더욱 귀찮을 것이다. 인터프리터 언어의 특징 상, 하이버네이트에서처럼 별도로 get/set으로 이루어진 POJO를 만들 필요도 없다. 단순히 모델 클래스를 규약에 맞게 만들고 객체 간의 관계(belongs to 등)를 설정해 주면 된다. 만약 규약을 맞지 않는 부분이 있다면 별도로 명시해 주면 된다.

    여기서 Java로 만든 스크립트 언어인 Groovy를 이용하면 ActiveObject에 대응하는 프레임워크를 만들 수 있겠다는 생각을 할 수 있는데, 물론 ORM 프레임워크를 새로 만들 필요는 없고 Groovy를 이용해서 Hibernate를 래핑하면 될 것이라는 추측도 가능하다.

    Grails(Groovy on Rails) 에는 ORM 프레임워크가 있는데 그것이 GORM이다.
    "Convention over Configuration"을 따르지 않아 ActiveObject보다는 코딩이 늘어나지만 순수 자바를 이용할 때보다는 훨씬 편리하다.


    - 얼마전에 보니 Grails 1.0.1 버전이 나왔던데 0.4X버전일 때, 사용해 본적이 있었다.
    그 때는 버그가 꽤 많아 짜증이 좀 나기도 했지만, 일을 할 때, 가장 짜증나는 일 중에 하나가 한가지 문제에 집중하기가 어렵다는 것이었다. 이것을 하기 위해 저것을 준비해야하고, 저것을 하기 위해 이것을 하다 보면, 본래 문제가 무엇이었는지 오락가락 할 때가 많다. 하지만 Grails는 이런 점에서 매력적이었다.
    웹 기반 서비스를 기획한다면 한번 쯤은 검토 해 보아야 할 프레임워크가 아닐까 싶다.

    - IBM dW 에 GORM에 대한 Article에 대해 소개되었다.
    좋은 웹 프레임워크는 견고한 영속성 전략을 필요한다. 여기에서는 (GORM)API, 테이블 간 관계 설정, 데이터 밸리데이션 규칙을 실행하는 방법, Grails App에 관계형 데이터베이스를 수정하는 방법을 설명하고 있다.
    (영문이라 좀 아쉽지만, 어렵지 않다. 번역이 힘들다면 예제만 따라 하여도 이해가 가능할 것으로 생각된다)


    링크 : http://www.ibm.com/developerworks/java/library/j-grails02128/?S_TACT=105AGX55&S_CMP=EDU

    참고 : http://grails.org/GORM

    말이 번지르르하다.
    말이야 쉽지, 레거시 시스템을 SOA에 통합하는 것이 좋다는 것을 누가 몰라서 안하는가.
    유연하고 적응력 있는 프로세스로 만들고 싶다. 하지만 이미 비즈니스 프로세스에 사용 중인 시스템이 있다.
    IBM dW에 SOA와 레거시 App을 통합하여 가치를 올리는 해결책을 단계적으로 설명하고, 피해야 할 함정도 함께 설명하고 있다.

    주로 학생 개발자들의 난이도에 맞을 만한 Article을 고르려고 노력하고 있으나, 정작 본인이 그만한 실력을 가지고 있는지도 의문스럽다. 그저 개발이 좋아 이것저것 하다보니, 리뷰도 하게 되었는데 지난 달에는 한 건도 하지 못했다. 이렇게 2월 마지막날 급하게 리뷰를 쓰고 있는 이달도 썩... 여튼 넋두리는 그만두고.

    레거시 시스템은 이미 제거된 다른 레거시 시스템에 비해 분명 가치적으로 높게 평가되기 때문이다.
    이제 통합은 트렌드가 아닌 필수가 되어버렸다. 누구나 통합을 말한다.

    그래야 할 필요성을 느끼는 누군가가 있다면, 이 Article을 통해,
    레거시 시스템과 App유형에 대해서 구분하고, 그에 따라 기대되는 혜택과 선택의 절차에 대해서 알아볼 수 있는 좋은 기회가 될 것으로 생각된다.

    (여담이지만, 내게 기회가 다시 주어진다면, 말썽 덩어리였던 학교 수강신청 시스템을 모조리 뜯어고치고 싶을 뿐)

    링크 : http://www.ibm.com/developerworks/kr/library/ws-soa-legacyapps/index.html

    알다시피 Java EE의 디자인 원리는 Web2.0 App들을 효율적으로 지원하지 못한다.
    IBM dW에 Java EE와 Web2.0 원리들간의 어긋날 결합의 이유와 비동기식, 이벤트 중심 아키텍쳐가 Web2.0 App에 더 적합한 이유를 설명하고 있다.
    자바 플랫폼에 비동기식 웹 App를 개발하고 실행하는 몇가지 솔루션을 평가하면서 보다 Web2.0에 가까운 프레임워크와 API를 설명하고 있다.

    Java EE는 원래 싱글 관리 도메인에 적용되는 것으로 서비스를 다루기 위해 디자인 되었다.
    즉, 본래 비동기식 통신 기반 패턴이 Java EE App에 맞기 힘들다는 말이 되기도 한다.
    (Ajax와 Java EE의 통합이라는 제목으로 검색을 하면 dW에서 관련 자료를 얻을 수 있다)

    조금 난해한 감이 없지않아 있지만, 이벤트 중심의 아키텍처를 변화시키기 위해 노력하고 있는 많은 학생 개발자분들에게는 꽤 많은 도움이 되지 않을까 기대해 본다.


    링크 : http://www-128.ibm.com/developerworks/kr/library/wa-aj-web2jee/

    텔넷 기반에서 웹 기반으로의 변화가 이루어진지 얼마 후 자신의 홈페이지를 내 손으로 만들고자 하는 욕구가 여기저기서 일어났다. 그 때, 나를 비롯한 많은 사람들이 사용했던 언어가 PHP였는데, 자신의 홈페이지에 채팅방을 만들고자 하는 사람들이 많았다. 일부 공개된 소스가 있긴 하였는데, 새로운 대화가 업데이트 되었는지 점검하지 못하여, 일정 주기로 계속해서 채팅방을 리프레시 하는 방법을 사용하였고, 그 결과 딱,딱,딱 하는 소리가 나고, 대화 메시지도 바로바로 업데이트 되지 않았다. 그 후, 자바스트립트 채팅 엔진을 이용한 채팅방도 생겨났었던 것으로 생각이 든다.

    이번 기사는 채팅 시스템을 Ajax와 PHP를 사용하여 구현하는 것이다. 특별한 인스턴스 메시징 소프트웨어를 설치할 필요 없이 컨텐츠의 가장 가까운 사이트 내에서 고객과 관리자간의 채팅을 구현하는 것이 사이트에서 채팅을 구현하고자 하는 목표일 것이다. 물론, Ajax를 이용하므로 메시징의 업데이트와 동시에 채팅 윈도우의 갱신은 당연히 이루어질 것이고,

    기사는 아래 링크에서 확인할 수 있듯 번역되지 않은 원문이다.
    http://www.ibm.com/developerworks/kr/library/x-ajaxxml8/index.html

    각 단계별로 소스코드와 실행결과를 보여주고 있어 영문이라 해도 그다지 어렵지 않게 따라할 수 있다.

    The login window for the chat
    로그인 윈도우

    The simple chat window
    간단한 채팅 시스템

    간단한 채팅 시스템의 구현을 마친 후, 좀 더 나은 채팅 시스템으로의 업그레이드까지.
    간만에 간단한 예제다. 영문이라도 어렵지 않게 따라하면서 익힐 수 있을 듯 하다.

    시간이 나면 번역이라도 -ㅁ-; (리뷰도 말일에 몰아서 하는 주제에 번역은..)