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 알고리즘에 관한 논문을 읽을 예정이다.

소니의 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.

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/)가 실려 있다.

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

Aperios 운영체제는 Sony Research & Development Center에서 개발된 운영체제로서, (과거는 Apertos라고 불림) 자바의 기능중 Reflection을 운영체제 차원에서 제공하는 첫번째 운영체제라고 한다.
(ieeexplore.ieee.org/iel5/ 6433/17161/00792047.pdf?arnumber=792047 )
http://csdl2.computer.org/comp/proceedings/isorc/2003/1928/00/19280007.pdf
 
기존은 언어에 dependent한 부분이 존재했었다.
java는 Reflection이라는 기능이 있어서, 별도의 파일이 없이 클래스의 메타정보를 run-time시 얻을 수 있었다.
반면, C나 C++에서는 run-time시 메타정보를 얻을 수 없다. 따로 header 파일을 이용하여 메타정보를 얻을 수 있다.

객체 지향적으로 접근했을때, 정보의 은폐성은 C나 C++이 높다고 볼 수 있다. 자바는 실행시, 다 reverse engineering을 통해 정보를 얻어내는 단점이 잇다. 하지만, 실제 배포시에는 오히려 C나  C++ 어플을 소스를 이용하여 컴파일해야 하는 경우가 생기는 것을 발견할 수 있다.
특히 window 프로그램시 이유없이 배포한 binary 버젼이 실행이 안되서 SDK를 깔고 소스 빌드를 해야 동작되는 일이나 linux상에서도 이유를 알 수 없는 실행 실패로 인해서 소스를 가져다가 소스 빌드를 해야 안전하게 동작되는 일이 빈번했다.

이런 고민은 바로 운영체제로 스며 들고 있다. 언어에 dependent한 이런 부분을 운영체제상에서 지원하고, 해당 API를 제공하여 알 수 있게 한 것은 상당히 고무적이다.
추후, 관련 논문을 읽고 나서, 자세한 얘기는 블로그에서 해보려고 한다.

결국 하고 싶은 얘기는 피플웨어인가 하는 생각이 들긴 하지만..
나는 Humanism 관리자가 되고 싶다. 야구의 김인식 감독같은 사람처럼 되고 싶다.

이 Article은 IEEE 2005년 6월호에 나온 인간 측면에서 본 학습 방법론이다.
사람이라는 게 자고로 경험에서 우러나와 적용하는 것이고, 자신의 직접적인 경험이든지, 직접적인 경험을 통해서 제품에 철학이 들어가게 된다. 이런 경험을 통해서 소프트웨어 개발 방법론을 제시한다.

문화적 배경, 프로그램 요구사항에 대한 이해도, 엔지니어의 생활패턴 및 성격, 프로그래밍 스타일, 경제관, 가치관에 따라서 소프트웨어 개발이 상당히 달라질 수 있다는 것이다.
신기하게도 개발자의 성격과 코드가 상당히 비례관계가 있다라는 것은 신기하다.

개발과 관련된 부분들이 존재하고, 이 존재한 부분들을 무엇을 통해서 하나의 제품이 나올 수 있게 방법론을 제시할 것인가하는 고민이 생기게 된다. 어떻게 공부를 시켜야 하고, 또는 어떻게 여러 개발자들의 생각을 하나의 생각이 되게 하는 것에 포커스를 잘 두어야 한다.

교육 방법은 다음과 같다.
1. 소프트웨어 개발자에게 조직에서 인재상을 실시하고, 실시하는 교육을 실시한다.
2. 소프트웨어 개발 프로세스를 적용할 수 있는 프로세스 교육을 실시하고 적용시킨다. (spiral, unified, extreme)
3. 교육이 되었으면, 개발 팀과 같이 팀웍으로 개발을 하며, 일부분을 교육시키고, 제품의 큰 그림을 그릴 수 있도록 한다.
4. 고객의 입장에서 바라본 제품을 상기시켜 고객이 원하는 제품이 무엇인지를 알도록 한다.
5. 추상화된 생각을 하도록 한다. 제품의 일반화된 프레임, 혹은 generic한 생각을 하여 common한 것을 발견하도록 한다.


이에 추가한다면, 조직에서 만드는 제품 및 앞으로 무엇을 만들 것인지에 대한 비젼을 보여준다. 각 단계에서 조직 구성원들에게 토의 와 토론을 하도록 유도하고, 앞으로의 개인적인 비젼, 조직의 비젼을 볼 수 있도록 하고, 목표를 설정한다. 또한 개별적 인간들에 대해서 성격, 품성, 가치관들을 인정하면서 guideline을 제시하여 남발되지 않은 자유로운 창조성을 발휘하도록 해야 한다.

관리자들에게 리더쉽은 바로 이런 것이라고 생각한다. 단순히 제품만 만드고 문제 없이 고객의 요구사항에 부합되는 것이 아니라, 인간적인 측면의 모습을 이해하고, 앞으로의 비젼을 보여주는 것이 중요하다고 생각한다.

사례를 바탕으로 하여 지적 재산권에 대해 체계적으로 설명이 되어 있다.
제품의 개발 단계에 따라 고려할 수 있는 여러가지의 법적 지식을 잘 설명해 놓았으며, 쉽게 이해가 가능하게 잘 쓰여져 있다.
변리사를 공부하기 위한 특허법이라는 책보다는 실용적인 이 책을 강추한다.

발명가에게 필요한 것은 바로 특허 출원 방식, 특허의 요건, 특허의 특허권 및 실시권 주장 및 직무 보상이다. 즉 단계별로 어떤 일이 일어나는 지 쉽고 간결하게 사용되었다. 또한 법적 문제에서 해결 방법에 대한 주요 내용이 상당히 인상적이었다.

특허 취득 절차는 잘 이해하고 있었다. 특허를 출원하고, 특허 심사관에 의한 등록 심사시 이의를 제기할 때마다 반박 자료를 만들어 설득을 시켜 등록한 경험을 가지고 있던 까닭에 취득 절차를 어렵지 않았다.
하지만, 효력, 소멸에 대해서는 잘 알지 못했다. 심사할 때에 돈이 꽤 들어가는 것도 잘 알 수 있었다.
특허를 취득하려고 할 때 단계적인 아이디어의 예제가 상당히 도움이 되었으며, 보호 및 침해에 대한 손해는 상당히 고무적이었다. 특허권을 이용하여 대출도 받을 수 있었다!!

특허 지식을 좀 더 확장하기 위해서 일부 내용을 발췌하였다.

특허 침해자에 대한 특허권자의 보호방법
1. 침해금지 청구
2. 침해예방 청구
3. 침해금지 가처분 신청
4. 손해배상 청구
5. 부당이득 반환 청구
6. 신용회복 조치 청구
7. 형사 고소

특허 권자의 공격에 대한 방어
1. 기술적 범위 검토
2. 특허를 무효화시킨다.
3. 특허권의 효력이 제한됨을 주장한다.


특허권에 대한 당사자들간의 분쟁
1.  다른 사람의 특허를 못 받게 하고 싶을 때
 (1)  특허 등록이 되지 않도록 정보제공을 한다.
  (2) 특허 이의 신청을 한다.
  (3) 특허 무효 심판을 한다.
2. 내 기술이 다른 사람의 특허권에 포함되지 않음을 확인받고 싶을 때, 특허에 침해 되지 않음을 증명한다.
3. 나의 특허권에 다른 사람의 기술이 포함됨을 확인받고 싶을 때, 권리 범위확인심판을 청구해서 이긴다.
4. 다른 사람의 특허를 실시하고 싶은데 특허권자가 허락하지 않은 경우 - 강제 실시권을 이용한다.
5. 회사에서 주는 직무발명 보상금이 너무 적을 때, - 법원에 보상금 지급 소송을 제기한다.
6. 타인의 상표권을 취소시킬 때
  (1) 상표권자가 정당한 이유 없이 3년간 계속해서 등록상표를 사용하지 않은 때
  (2) 상표권자가 등록받은 상표를 다르게 사용하여 수요자로 하여금 오인 혼동을 일으킨 때


특허청에 대한 요구 또는 불복
1. 특허받은 명세서를 고치고 싶을 때
2. 출원을 거절 당했을때
  - 거절 이유는  발명이 아닌 것/ 산업상 이용가능성, 신규성, 진보성이 없는 것 / 다른 사람보다 후출원인 때 / 공공질서와 선량한 풍속에 위반되는 발명/ 정당한 출원인이 아닌 때 / 명세서의 기재가 잘된 경우 이다.
  - 위의 거절 이유가 아닌 데도 거절 결정되면, 심판원에 거절 결정 불복 심판을 청구할 수 있고. 불복사항이 있으면 심결 취소 소송을 제기할 수 있다.
3. 국가에 수용당한 발명의 보상금이 너무 적을 때
4. 특허법원에의 소송 (심결 취소 소송)

마이크로 소프트웨어 2006년 7월 자료입니다.

무어는 '더욱 집적되는 집적회로'라는 제목의 논문에서 앞으로 집적회로가 전자공학의 미래가 될 것이라는 글을 썼으며, 이 후, 이더넷을 만든 멧칼프의 법칙은 네트워크의 가치가 사용자 수의 제곱에 비례한다고 발표했다.

1975년 수천개-1만개의 집적이 10년후에 32비트 마이크로프로세서가 범용화되었으며, 다시 10년이 지나서, 네트워크가 안방까지 파고 들었을 뿐아니라 임베디드 시스템이 더욱더 활성화되었다.  이제는 유비쿼터스라는 말이 너무 쉽게 이해할 정도로 어디서나 항상 연결지향적인 생산적인 할 수 있는 시대가 왔다.
시스템의 비용은 인원수에 비례하여 증가하는 경향이 있지만, 네트워크의 가치는 사용자 수의 제곱에 비례한다고 생각했다.

그러면 얼마 후 네트워크의 가치는 투자비용을 상회하고 더 빠른 속도로 증가하며 그 이후에는 네트워크의 폭증이 있을꺼라 예측했다. 무어의 법칙, 멧칼프의 법칙도 모두 기하급수적으로 증가한다.

너무 급속도로 경사진 상황에서 사람들은 쉽게 공황장애에 빠질 것 같은 상황을 잘 버텨온 정도가 아니라 즐긱도 한다.
경쟁에서 이길 수 있다면, 1~2년 정도 남들부터 더 빨리 기술을 소유할 수 있다면, 기꺼이 위험을 감수한다.

그렇지 않으면 경쟁에서 지기 때문이다.
지적인 능력, 추진력, 엄청난 열정, 마지막으로 운이 있어야 한다.
세월이 점점 빠르게 진화되고, 변화의 폭이 가파르게 상승하고 성장하는 부분때문에 사람들의 정신을 산란하게 만들었다.

이런 세상에서 나는 무엇을 해야 하는 것일까? 후배들에게 어떤 길을 보여줘야 하는 것일까?
공병호의 10년 후 한국, 자기 경영 노트, 부자 아빠 / 가난한 아빠 의 글처럼 (이 분의 모든 글을 지지하지는 않음.) 자기 계발 정신을 가져야 한다. 변화의 흐흡에 몸을 타고, 변화의 폭에 맞춰 비즈니스를 창출할 수 있는 부분을 잘 캐취해야 한다.

1,2년이 늦은 것에 대해서 후회할 필요는 없다. 오히려 노력하지 않는 자신을 후회해야 한다. 항상 노력하고 공부하는 자세.. 이것이 변화에 대해서 살아 남을 수 있는 기본적 토양이라고 생각한다.

정보과학회논문지: 데이터베이스 32권 2호 (2005.4) - 김성진, 이상호

이 논문은 유명사이트 집합과 임의사이트 집합에 속한 웹 문서들을 100일동안 주기적으로 수집하여 변경 경향을 관찰하고 그 실험결과를 내어 뤱 로봇의 운용에 도움이 되도록 관찰연구지이다.

성공적으로 다운로드된 URL은 여전히 잘 다운로드되고, 내용의 변경이 없던 문서는 여전히 현재 상태를 유지하는 것으로 나타났다. 절반정도들이 규칙적으로 변경이 된다. 웹 데이터 베이스의 freshness을 높이기 위해서는 이런 확률적 수식을 통해서 알 수 있다.

웹 문서의 주기별로 자주 바뀌는 것이 반정도, 안바뀌는 것이 반정도 있으며, 바뀌는 것은 주기가 있기 까닭에 웹 로봇의 변화 분석이 필요하다. 웹 문서 변화에 대한 잘못된 예측, 판단으로 인하여 발생할 수 있는 커버리지 손실에 대한 연구가 필요하라는 것이 논문의 주요 요지이다.

DMB 방송에서는 BWS라 하여 방송사에서 웹 컨텐츠를 전송할 때 무작정 보내는 것보다는 dynamic 컨텐츠는 따로, static 컨텐츠는 따로 전송하여 실시간으로 구분하여 전송하면 수신기단에서 파일이 바뀐 dynmaic 컨텐츠만 변경된 것으로 판단하여 잘 보는 게 중요하다.

이 논문을 본다면, 생산자-소비자 : 웹문서 - 웹로봇 : BWS 송출 - BWS 수신 으로 확장할 수 있으며, BWS 송출이 자주 변경되는 것과 변경되지 않는 것으로 구분하여 전송이 되는 것에 대해서 따로 따로 전송이 되어야 함에도 불구하고 이런 나누어서 전송하는 방법은 현재까지 존재하지 않는다.

파일 전송에 대한 스케쥴링도 전혀 생각치 않되어 있기 까닭에 이런 부분이 필요하다.
수신기는 따로 따로 전송되는 파일들을 분석하여 항상 freshness정보를 얻을 수 있으며, 사용자의 만족을 극대화 할 수 있는 장점이 있을 것이다.

이 기사를 내가 가장 공감하는 것은 로버트의 행동이었다.

엄청난 실수를 저지른 후, 도망가고 싶은 그 느낌은.. 정말 겪지 않은 사람은 이해를 할 수 없다. 일을 잘 해결하지 못하고, 수정된 버그는 엄청나게 커져서 더 이상의 도움을 받지 못해서 끙끙앓고 있는데, 상사는 언제 끝낼 수 있는 채찍을 들어서 괴롭힐 때면 엄청난 자괴감에 빠진다. 이런 상황에서는 내성적인 마인드가 살아나서 회사를 그만두고 싶은 충동을 느낀 적이 한 두번이 아니었다.

자신의 코드가 완전히 사라지고, 무력감을 느끼는 순간.. 답답했다. 이 자리를 영원히 뜨고 싶었다.
문제가 생기기 전에 교육을 제대로 받았으면 하는 생각이 얼마나 들었는지 모른다.

실수를 만회할 수 있는 시간이 짧아서 작은 실수가 다른 실수를 낳지만, 실수를 두려워하거나 거부하지 않아야 하고, 실수를 정정당당하게 끌어안고 그것을 뛰어넘는 사람만 발전할 수 있다라는 부분에서 큰 힘을 얻었다.

그러기 위해서는 개인자체가 스스로 마인드를 달리 해야겠지만, 조직의 변화도 같이 이루어져야 한다.

교육시스템과 조직시스템이 변경되어서 다시는 똑같은 실수가 없도록 해야되만, 똑같은 일이 계속 반복적으로 이루어지는 조직.. 변하지 않는 조직에서는 개인 스스로 어떻게 해야하는 것일까???