공룡호가 사는 세상 이야기

엔디안 방식에 구애 받지 않는 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/





    제9회 자바 개발자 컨퍼런스를 다녀왔다.
    사진기를 가져가지 않아, 인터넷에서 구한 사진으로 대체-_-; (http://blog.naver.com/pmj09142 퍼옴)
    오전에 축구 한게임 하고 오후에나 도착해서, 사람은 그다지 많지 않을 것으로 예상했는데 아니었다.



    썬은 하드웨어 벤더이긴 하나, 자바 때문에 이번 컨퍼런스의 핵심이기도 하다.
    경쟁사이지만 좀 부럽더라. - 마찬가지로 사진 퍼옴(http://blog.naver.com/lyia2)



    IBM도 참가했는데, 우리회사랑 HP는 없다. 아쉽다. 저기 권환이 회사도 보이는구나.
    사람은 정말 많았다.(짜증날 정도로) - 마찬가지로 사진 퍼옴(http://blog.naver.com/lyia2)
    사진을 퍼 온 블로그에서 읽고 알았는데 티맥스에서 상담 받으면 2G 메모리 스틱을 줬다는데 ㅠㅠ



    IBM의 세션. 이과장님과 성균씨 오랫만에 뵙고 인사도 드렸다. 조만간 모임할 예정이라는데, 언제쯤일지..
    다음에 모니터 요원 모임이나 발대식 있으면 규현이와 함께 가야지.
    - 마찬가지로 사진 퍼옴(http://blog.naver.com/lyia2)





    DAUM에 입사한 규현이를 만났다. 함께 입사한 개발자 분과 인사 나누고, 커피한잔.
    디카 샀다고 자랑은 -_-...
    늦게 가서 정신없이 인사하고 구경하다가 돌아오는 길에 함께 리뷰 블로거 활동중이신 영회님 뵙고 인사.
    아직 명함이 안나와서 뻘쭘하긴 했지만 반가웠다. 두번 째 뵙는 것이고 잠깐이지만 인상이 참 좋으신 분이다.

    끝나고 수희누나 꼬드겨서 비싼 저녁 얻어먹고, 원석이 만나서 삼겹살에 쇠주한잔.
    주말도 빡빡한 일정으로 가득가득 채우는게 참 좋다.
    몸이 쉬면 마음이 불편하다.
    난 아직 젊으니까. :)

    텔넷 기반에서 웹 기반으로의 변화가 이루어진지 얼마 후 자신의 홈페이지를 내 손으로 만들고자 하는 욕구가 여기저기서 일어났다. 그 때, 나를 비롯한 많은 사람들이 사용했던 언어가 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
    간단한 채팅 시스템

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

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

    원문 : http://www.ibm.com/developerworks/kr/library/ws-soa-composite11/index.html

    이번 기사는 조금 어려울 수도 있고, 어쩌면 학생개발자들에게는 크게 와닿지 않을 기사일지도 모른다.
    WebSphere Service Registry and Repository를 커스터마이징 하고, 이를 WebSphere Process Server에 통합하는 것인데, WebSphere Process Server가 서비스 소비 거버넌스에 어떻게 사용될 수 있는지에 대한 이전 주제에 대한 구현 상세를 설명하고 있다.
    이전 주제에 대한 Article를 보고 싶은 사람은 아래 링크를 참조하자.
    http://www.ibm.com/developerworks/kr/library/ws-soa-composite10/?S_TACT=105AGX55&S_CMP=EDU

    WebSphere Process Server를 사용하여 등록자 권한 부여 프로세스를 구현하고, 이것을 SOAP 인터페이스를 사용하여 WebSphere Service Registry and Repository와 통합한다.
    WebSphere Service Registry and Repository는 서비스 메타데이터용 레지스트리 및 저장소인데 다른 소스에서 얻은 서비스 메타데이터를 찾고 관리하는 중앙 포인트를 구축한다. 서비스 메타데이터의 예는 서비스 공급자와 서비스 등록자간 합의도니 비용과 응답 시간을 들 수 있는데, 이를 이용하여 서비스 공급자 중심의 계약정보를 나타내거나 각종 엔티티들을 연관시키고, 확장성 있는 UI를 위해 커스터마이징을 수행할 수도 있다.

    즉, 이 글에서는 WebSphere Service Registry and Repository를 커스터마이징 하는 방법을 설명하는데, WebSphere Service Registry and Repository와 WebSphere Process Server 서버에서 실행되는 등록자 권한 부여 프로세스를 통합하여 공지 플러그인과 WebSphere Service Registry and Repository API를 사용하는 방법을 말한다. 다소 어려운 주제일 수도 있겠다. 하지만 이를 통해 얻을 수 있는 장점들은 아래 워크플로우만 조금 살펴보아도 알 수 있을 것이다.



    WebSphere Process Server와 Websphere Service Registry and Repository 통합 포인트

    WebSphere Integration Developer에 나타난 등록자 권한 부여 프로세스의 인터페이스
    WebSphere Integration Developer에 나타난 등록자 권한 부여 프로세스의 인터페이스


    WSRRServiceHelper 웹서비스의 인터페이스
    WSRRServiceHelper 웹서비스의 인터페이스

    Ajax 기술을 이용해서 영화와 슬라이드 쇼를 보여주는 예제로, 많은 사람들이 알고 있는 YouTube와 비슷하다.
    국내에도 이와 비슷한 서비스를 하는 곳이 생겨나고 있는데, 미디어에 PHP와 Ajax를 결합하여 일반적으로 미디어를 보는 방식과 미디어와의 관계를 변화시킨다.
    이 글에서는 간단한 웹 비디오 호스팅 애플리케이션에 Ajax 프론트엔드를 추가하는 방법을 설명한다.
    이것으로는 설명이 부족하다. 만들어 보기 전에 뭘 만드는 지는 알고 만들어야 할 게 아닌가.

    간단한 쿼리를 사용한 영화 쿼리
    간단한 쿼리를 사용한 영화 검색이다. 쿼리는 's'이며, 's'로 시작하는 2가지가 검색됨을 볼 수 있다.
    예제에서 검색 가능한 리스트는 총 3개 이며, 이 그림에서 볼 수 있는 2개 이외에 'w'로 시작하는 'Water Splash'가 있는데 이에 해당하는 검색은 다음에서 볼 수 있다.

    "water" 영화를 찾는 영화 쿼리 페이지
    'Water' 영화를 찾는 영화 쿼리 페이지이다.

    이러한 방식으로 이 글에서는 DHTML(Dynamic HTML)과 Ajax를 사용하여 프론트엔드를 만드는 방법을 설명하고 있는데, 글의 후반부에서는 비디오 공유 사이트를 만들 수 있는 다른 방법들에 대해서도 간단히 소개하고 있다.
    또한 비디오를 핸들링하고 공유하기 위해 기초적으로 고려해야 할 3가지 사항들에 대해서도 다루고 있다.

    Article : http://www.ibm.com/developerworks/kr/library/x-ajaxxml7/index.html
    Sample Code : http://download.boulder.ibm.com/ibmdl/pub/software/dw/xml/x-ajaxxml7-media.zip