http://www.cs.umass.edu/~emery/pubs/04-15.pdf

힙 메모리를 가비지 콜렉션이 가능한 여러 윈도우로 나눈다. 이 윈도우는 pause, mark, sweep을 독립적으로 차례로 수행되기 까닭에 compact하고, 속도도 지금까지 나온 GC 알고리즘보다 획기적으로 빠르게 쓰일 수 있다.
JVM의 강점인 GC는 때로는 약점이 될 수 있는 상황에서, 예를 들자면, Thread를 이용하여 많은 객체를 생성하거나 많은 이미지를 불러오는 경우에 대해서 GC가 자주 일어날 수 있는데, 이 때, pause time이 길어지면, 마치 JVM의 성능에 영향이 있는 것처럼 보일 수 있는 부분들이 다소 존재한다.

이런 최적의 환경에서 사용될만한 최근 GC 알고리즘이라고 할 수 있다.

GC 알고리즘 논문치고 최근 것을 읽어서 어렵지만, 끝까지 읽을 수 있었다. 계속 GC 알고리즘에 관한 논문을 읽을 예정이다.

드디어 Advanced Programming in UNIX Environment를 공부하기 시작했다.
이 책의 2판은 2005년도에 나왔는데, Stevens가 1999년도에 사망했다는 얘기를 듣고 이 사람에 대해서 좀 알아 보려고, 구굴에서 Richard  Stevens를 검색했더니 그 자신이 쓴 일대기를 볼 수 있었다.

http://www.kohala.com/start/bio1.html

http://www.kohala.com/start/


UNIX와 소프트웨어의 큰 획을 그으신 분이 어떻게 돌아가셨나 구글링을 한 결과, 다음과 같은 글을 발견했다.

W. Richard Steven noted technology author and teacher died last Wednesday. Stevens was best known for his UNIX Network Programing series and and TCP/IP Illustrated book. The family has asked that in lieu of flowers, be made in Richard's name to Habitat for Humanity, 2950 E. 22nd Street, Tucson, AZ 85713. He is survived by his wife and three children. The cause of death was not reported.
(http://www.hackcanada.com/hackcanada/media/hnn090899.html)

Born: 1951
Birthplace: Luanshya, Northern Rhodesia
Died: 1-Sep-1999
Location of death: Tucson, AZ
Cause of death: unspecified
Gender: Male
Ethnicity: White
Occupation: Author
Nationality: United States

(http://www.nndb.com/people/948/000023879/)

그의 죽음은 불명확한 돌연사인듯 하다. 너무 열심히 산 까닭일런지는 모르겠다. 특이한 점은 그가 해비타트와 연관이 있다는 점이 그가 어떻게 인생을 살았는지 알아 보는 것도 괜찮을 것 같다라는 생각이 들었다. 48살에 운명을 달리했지만, 그 사람이 아니었다면, IT의 역사가 거꾸로 갔을 지도 모르겠다라는 생각이 든다.

소니의 Yasuhiko Yokote의 논문이다.

http://csdl.computer.org/comp/proceedings/isorc/2003/1928/00/19280007.pdf

이 논문에서는 임베디드 운영체제의 역할으로서, intervening (잘 나누어져 있음), providing facility (기능 제공), managing a distributted environment등의 3가지를 들고 있다. 이는 실제 reflective 운영체제인 Aperios에서 실제로 사용된 개념이라고 한다. (사실은 당연한 개념인듯..)

또한, 네트웍 장치로서 필요한 7가지 layered model를 설립하고, 그의 가치를 역설했다.

------------------------------------

Application (browser, EPG)
------------------------------------
Providing Service(Such as Java, 3D)
------------------------------------
Representing exchangeable data / information
------------------------------------
Communication
------------------------------------
Secruing protection
------------------------------------
Resouce managing and controlling Software (linux)
------------------------------------
underlying hardware (Manaing and controlling H/W resource)

------------------------------------

간단하게 잘 표현했다고 본다. Communication을 하나의 계층으로 본 것이 상당히 인상적이랄까?

//TODO 봐야할 것들
Advances in Object-Oriented Metalevel Architectures and Reflection, 1st edition -ACM
(http://portal.acm.org/citation.cfm?id=525045&dl=ACM&coll=ACM)
 
DART: A Reflective Middleware for Adaptive Applications
http://www.csg.is.titech.ac.jp/~chiba/oopsla98/proc/raverdy.pdf
 
Adaptive operating system design using reflection (1995)
http://citeseer.ist.psu.edu/lea95adaptive.html
 
 

G. Kiczales, "Beyond the black box: Open implementation," IEEE Software, vol. 13, Jan. 1996. 33

Yokote, Y. The Apertos Reflective Operating System: The Concept and Its Implementation. In Conference on Object-Oriented Programming Systems, Languages, and Applications, pp. 414--434. ACM, October 1992.

저는 전공 서적을 보고 깊은 감동을 받아 본 일이 거의 없습니다. 제가 이 책을 보고 감동을 받은 까닭은 저의 과거입니다. 부끄럽지만, 저는 C언어 자체를 학교 수업에서만 쓰일 것이다라고 생각하고, 사용하려고 노력하지 않았고, 자바-OO 교조주의 빠져 C언어 학습 자체를 불필요하다고 생각했었습니다. 항상 디자인 패턴이나 새로운 프레임의 자바 API를 습득하는 데에 집중을 했었습니다.

최근 미들웨어의 일부를 개발하면서, C언어를 이용하여 제가 담당한 모듈을 구현을 해야 했습니다. 기본적인 C언어의 문법, 활용사례도 모른 체, 얄팍하게 아는 지식으로 당당하게 구현을 하려고 시도했지만, 엄청난 시련의 시기가 있었습니다.

단순히 C언어를 잘 아느냐의 문제보다는 그 동안, 기본기에 대해서 상당히 소홀히 했음을 깨달았던 시기였습니다. How to programme C, A book on C  와 같은 책들을 훑으며 단순히 이 정도만 알면 머 C코딩은 금방 할 수 있겠구나 하는 단순한 생각은 저를 산산조각으로 만들어 주었습니다.

이런 저의 마음을 어루어 만져준 책은 K&R의 C Programming Language 2nd 였습니다. 고등학교 시절에 학원에서 저자 직강이라는 수업은 다른 과목 수강비보다 비쌌습니다. 그 이유는 저자의 생각, 철학을 최대한 이해하고, 의도하는 바가 정확하게 어떠한지를 알 수 있는 기회였기 때문입니다.

마찬가지로 이 책은 저자 직강책입니다. C Programming Language를 디자인한 두 명의 그루(해커)가 C언어를 디자인하면서 이런 용도로, 저런 용도로, 이런 한계, 저런 기능등을 잘 서술하였습니다. 혼자서는 잘 이해가 안가는 구절때문에 쉽게 포기하는 일도 있었는데, 다른 분과 같이 이 책을 가지고 공부를 시작하였습니다.

기초부터 다시 차곡차곡 쌓아 올리고 싶은 마음과 군 복학 후 학교에서 오랜만에 전공 과목을 듣는 간절한 마음으로 이 책을 정독하기 시작했습니다. 한 문장 한 문장을 꼼꼼히 읽어 가면서 어떤 의도에서 이런 말을 했는지, 지금의 gcc, visual c 컴파일러를 일일히 실행하고, 의문점을 가지거나, ISO/IEC C 스펙을 읽어보는 등, 최선을 다해서 공부를 시작했습니다.

파라미터 패씽에 대해서 다른 언어에서는 어떻게 활용되는지, Java가 native 코드를 호출할 때, 어떻게 메모리 구조를 가지고, 어떤 sequence를 가지며 내부적으로 어떻게 동작을 하는지등을 공부하게 되었습니다.

프리미티브 타입, struct, union과 같은 구조체에 대한 정확한 정의를 다시 한번 명확히 하였고, 같이 공부하는 상대방에게 쉽게 이해시킬 수 있는 communication skill, presentaion skill도 덤으로 키울 수 있었습니다.

정확한 의미가 전달이 되고, C언어의 저자를 듣고 나면서, 기분이 한결 많이 나아졌으며, 실제 C 코딩을 할 때 큰 도움이 되었습니다. 또한, 이 책을 가지고 공부할 당시, 제가 Code Reading을 읽던 때라 상당히 머리 속에 도움이 되었습니다.

특히 이 책의 하이라이트 8장에서는 malloc, free에 대한 구현이 나와 있습니다. 이 구현을 통해서 c언어의 활용에 대해서 많은 것들을 깨닫게 되었고, 기초가 다져지는 느낌을 많이 받았습니다. 역시 c언어는 알고리즘을 이해하는 데 가장 이해가 되는 언어라고 생각이 듭니다.

저에게 훌륭한 깨달음을 주신 K&R 선생님께 깊은 감사를 드립니다. 그리고, 정말 제대로 C언어의 기초를 다시 쌓고 싶거나, C중급자로 가시는 분들에게 원서를 강하게 추천해 드립니다.

나름대로 생각해왔다는 디자인이 많이 수정되었다.

Top-down으로 내려보면서, 이슈가 되는 것들을 모아놓고, 그 역할에 해당하는 모듈을 결정하는 방법을 택했다.
하지만, 선임자로부터 다시 한번 생각하여, Bottom-up으로 올라가서 보라는 말에 다시 한번 생각하게 되었다.
빠지는 부분들을 발견하게 되었고, 작은 단위의 모듈을 묶어놓고, 작은 모듈을 다시 상위 모듈로 묶어 보니, Top-down 방법으로 보이지 못했던 일부 기능 및 이슈가 좀더 확실히 지는 것을 발견하였다.

또한 이슈를 제기하여 이슈에 대한 모듈 및 기능을 정하였다.

이런 작업중에 중요한 것들을 발견하였는데, 바로 "Constraint", 제약조건이다. 즉 이는 규격에 맞는 것, 혹은 요구사항 분석시 반드시 염두해야 하는 것으로 말할 수 있는데, 이 부분들을 계속 발견이 되었다. 미처 발견되지 못해서 구현상에서 문제가 될 수 있는 부분들이었다.

그렇다면 어떤 부분을 잘 염두를 해야하는 것일까??

2005년 3/4월 IEEE Software의 "아키텍처의 미스터리를 푼다"에서는 다음의 내용을 염두해야 한다고 하였다.

Issue, Decision, Status, Group, Assumptions, Constraints, Positions, Argument, Implications, Related decisions, Related requirements, Related principles, Notes 등을 요소로 뽑았다.
(개인적으로 중요하다라고 하는 것은 Bold체로 강조를 했다.)

설계를 할 때, 다양한 Approach들을 제시할 수 있는데 이를 테이블을 이용하여 주어진 Approach들에 대해서 여러가지의 문제 해결 능력에 대해서 구현할 수 있는지를 yes/no로 구분하여 제시하였다. 이렇게 함으로서, 문서화 및 결정단계에서의 근거를 마련하였고, 무엇이 가장 최선에 가까운 구현인지를 찾는 것인지를 알리고 있다.

또한, 상기 주어진 요소들에 대해서 가장 최선에 가까운 구현 시스템에 대해서 해당사항에 맞춰 그 내용을 기입하여 문서화, 분석화, 결정을 적도록 하였다. 그래서 구현할 때 요구사항 및 참조사항으로 하여 아키텍쳐의 기반 내용으로 삼을 수 있도록 하였다.

해당 Article의 내용을 디딤돌로 삼아 분석한 내용을 기반으로 하는 문서화를 통해서, 문제점을 일찍 파악하고 그 문제를 해결할 수 있는 것이 중요하는 것을 깨달았다.

잘 써먹어야지.

ACM 2005 Feb 에서..

온라인상으나 오프라인상이나 Trust는 상당히 중요하다. 아니, 상도에서는 제일 중요하다고 볼 수 있다.
이 기사는 Trust에 대해서 분석적으로 접근하여 전자 상거래의 유발의 순차적이고 관계성을 View로 보고 있다.
엔지니어에게는 상당히 추상적으로 느껴질 수 있을 것이다.

인터넷 사용에 대한 믿음은 전자 상거래 웹싸이트에 대한 자세와 특정 웹 벤더에 대한 신뢰가 그 벤더에 대한 사용 의지를 높여 방문을 자주 하게 되고, 이런 과정을 통해서 웹 벤더와 사용자간의 relationship을 형성한다. 이런 관계의 발전을 극대화하여 신뢰를 구축하게 되고, 이 신뢰를 통해서 전자 상거래를 이루게 하여, 제품 구매자와 제품 공급자가 서로 가치를 얻을 수 있는 상태를 얻도록 하는 것이 이 기사의 주된 내용디ㅏ.

결과적으로 신뢰는 기술적, 행동학적, 사회학적, 심리학적인 복잡한 현상으로서, 인간과 비인간간의 구조적인 상호관계를 이룰 수 있다고 믿고 있다. 즉 고객과 온라인 비즈니스 사업자가 긴 시간동안의 신뢰성을 가지도록 하는 것을 통해 온라인 비즈니스 사업자가 돈을 벌 수 있는 방법에 대해서 강조하고 있다.

사실 개인적으로 특정 전자 상거래를 구입하기 위해서는 그 동안의 정(情)을 생각하고 구매를 결정하는 경우가 많다. 같은 제품이고 같은 가격이면, 나랑 관계가 있고, 과거의 구매경험이 있는 경우를 생각하고 구매한다고 본다면, 어느 정도 맞을 수 있다고 본다.

또한, 인간적인 신뢰 관계를 웹 벤더와 고객간의 관계를 최대한 극대화 하여 상대방이 돈을 쓰도록 구매할 수 있는 좋은 효과적인 방법을 웹 벤더는 생각해야 한다. 그러기 위해서는 꾸준한 컨텐츠를 통해서 기반 인프라를 바탕으로 좋은 정보를 보내줌으로서, 잠재 구매자에게 어필을 하는 것이 중요하다. 구매 결정을 할 수 있는 건덕지를 웹 벤더가 적용하는 것이 좋을 것이다.

내가 하는 있는 TV분야에서는 어떻게 적용하는 것이 좋을까?  결국 구매력을 가진 잠재력을 최대한 늘리기 위해서, 그리고, 양방향 데이터 방송에 대한 접근을 편리하게 하고, 좀 더 친밀감있게 접근하여 장기적으로 데이터 방송에 친숙하게 하여 신뢰를 튼튼히 한다. 그리고, 실제 구매력이 필요한 시점에서 자연스럽게 구매를 할 수 있는 형태의 호소력이 있는 T-commerce 어플리케이션을 이용하는 것이 효과적이라고 생각한다.

Software Engineering Theory in Practice IEEE June 2005

모든 프로젝트의 원인은 만능이라고 생각하는 특정 소프트웨어 개발론의 신봉이다. 개발 방법론이 heavy할 경우에는 delay의 원인이 될 수도 있다.

Heavy Software 개발 방법론은 다음과 같은 프로젝트에서는 사용될 수 없다.
간단하고, 작은 프로젝트,
현존하는 제품의 새 버젼
legacy SW의 유지보수
비용이 적은 프로젝트
빠른 시간내에 나와야 하는 프로젝트
요구사항이 없는 프로젝트

요구사항이 없는 프로젝트의 경우는 고객으로부터, 또는 시장으로부터 요구사항을 꺼집어 내어야 한다.

이런 내용으로 구성되어 있다.

"은 총알은 없다"라는 말이 문득 떠올랐다. 하나의 총알으로 모든 것을 다 잡을 수는 없다라는 말이다.
나는 개인적으로 카메라를 좋아한다. 펜탁스의 istD라는 DSLR, 렌즈 교환식 카메라를 사용하고 있다. 모든 것을 렌즈 하나로 해결할 수 없다는 사실을 안다. 그리고, 광각이나 망원이냐에 따라서, 날씨가 좋냐, 나쁘냐, 실내에서 쓰냐 안쓰냐에 따라서, 쓰는 렌즈가 달라지고, 렌즈에 따라 달라지는 색감과 AF능력까닭에 상황에 따라서 사용하고 있다.

즉, 개발 환경은 상황에 맞춰 그에 맞는 프로젝트 개발 방법론을 사용하는 것이 좋다는 것이다. CMM 레벨의 내용을 따라하다가, 문서만 만들다가 시간이 촉박여서 밤을 새기 보다는 필요한 것만 정리하며 개발에 착수하여 기간내에 고품질의 제품을 만들어내는 것이 가장 우선순위가 높은 것이다.

또한 데모와 같은 작업을 하는 데에서 가장 문제가 되는 것은 요구사항이 없다는 것이다. 해당 당일날 그제서야 원하는 기능이 없다며 문제를 왜 얘기하지 않았냐는 것은 요구사항이 빨리 나오지 않았거나, 의사소통의 부재일 것이다.
요구사항이 가장 먼저 나오고, 의사소통을 통해서 확실히 하는 것이 가장 빠르고 안전한 길인데도, 왜 이렇게 제대로 하지 않는 것일까??

내가 관리자가 되면, 일처리 하나만큼은 잘 할 것이다!. 실력도 함께 말이다.

http://www.cs.tut.fi/~taivalsa/main.html

Antero Taivalsaari는 KVM을 주도적으로 개발한 사람이다. 이 사람이 실제 구현한 논문 (http://citeseer.ist.psu.edu/taivalsaari98implementing.html)을 공부하고, sun에서 인터뷰한 기사(http://developers.sun.com/techtopics/mobility/midp/luminaries/taivalsaari/)가 실려 있다.

이 분의 발자취를 따라 가는 중...

지금까지 IT 개발자로 있으면서 가장 힘든 것중의 하나가 무엇이냐 라구 물으면,..

API 디자인이라고 말하고 싶다.
응용 및 상위 계층의 모듈에게 Adaption layer의 형태로 Api를 제공해야 하는 상황일 때, 참 힘이 들기도 했다.
명확한 기준도 없고, 참고 사항도 없이 경험을 바탕으로 하다 보니, 쉽지 않았다.

좋은 API 디자인에 대한 Idea에 대한 링크를 첨부한다.

Java API Design Guidelines in Artima
http://www.artima.com/weblogs/viewpost.jsp?thread=142428


An excellent tutorial on netbeans.org, How to Design a (module) API.
http://openide.netbeans.org/tutorial/api-design.html


Josh Bloch's Design key note
http://lcsd05.cs.tamu.edu/slides/keynote.pdf

http://en.wikipedia.org/wiki/Gulliver's_Travels  
In the discipline of Computer Architecture, the terms big-endian and little-endian are used to describe two possible ways of laying out bytes in memory (see endianness). One of the conflicts in the book is between people who preferred cracking open their soft-boiled eggs from the little end, and the people who preferred the big end.


다들 다 아는 내용이겠지만, 걸리버의 여행기로부터 Little endian과 Big endian의 유래가 나왔다가 한다. 뾰족한 부분 혹은 둥글한 부분을 깨는 부분에 따라서 유래가 나왔다.

Big Endian과 Little Endian은 알아도 Medium Endian이라는 것도 있다.
명확히 알기 위해서 http://en.wikipedia.org/wiki/Endianness 를 참조한다.

100번에 4A3B2C1D를 저장한다고 가정해 보자.
 
각 종류마다 저장방식이 다르다.
 
Big-endian

	100	101	102	103
...	4A	3B	2C	1D	...

Little-endian

	100	101	102	103
...	1D	2C	3B	4A	...

Middle-endian

	100	101	102	103
...	3B	4A	1D	2C	...

or alternatively:

	100	101	102	103
...	2C	1D	4A	3B	...

middle endian방식은 mixed라고 불려진다.

운영체제가 지원하는 endian 지원 방식을 헛갈리지 말자~