2005년 5월 이글루스 내 블로그에서.

 

이 내용은 Hoare라는 사람이 자신이 해온 과업을 평가하며 적은 글이다.
sorting의 한 장르(quicksorting)를 열었으며, Algol 60 Compiler를 설계, 디자인을 하면서, 나름대로 정한 룰을 통해서, 컴파일 이론을 정립시켰다.
Ellliott 503 Mark II 소프트웨어 시스템을 만들다 실패한 일을 통해서 이겨내는 모습이 적혀 있었다.
실패요인, 문제, 그 문제를 인정을 통해서, 앞으로 어떠한 소프트웨어를 만들어야 할지를 분석하였다.
소프트웨어의 가장 큰 문제를 complexity를 꼽았다. 복잡성이 증가하면 즐가할수록 실패할 수 있는 가능성이 높다는 그 진심을 꼭 가슴속에 잘 넣어야 하겠다.

Rapid Development 중에는 반드시 지켜야할 사항.
Demo용 애플리케이션을 개발하면서 다른 개발자와의 커뮤니케이션이 제일 중요하다. 코드보다도 더..
독립적인 애플리이션을 개발한다고 했을때, API를 통해 모듈간의 통신이 이루어진다.

A는 Senior, B는 Junior 엔지니어이다.

A의 모듈을 B가 사용한다고 할때, Rapid Development중 A는 개발도중, B에게 자신의 개념을 이해하고, API를 알려준다.
B는 그 A가 생각한 API를 바탕으로 B의 모듈을 개발한다.

A는 모듈의 문제점때문에 refactoring을 한다. B에게 refactoring하게 될 것이다고 알려주고, A에게 간단하게 얘기를 해준다.
B는 A가 refactoring의 범위가 작은 수준이라고 생각했다. (결국은 많이 바뀌었다. 생각의 범위가 다름)

A의 사소하다고 생각되는 수정은 B에게 엄청난 수정을 주었으며, 제대로 동작이 되지 못하였다.

배운점
A는 반드시, B에게 A모듈에 대한 개념과 철학을 api를 통해서 계속적으로 얘기해줘야한다.
단지 소스를 통해 이해도를 높이는 것이 아니라, 설명해주는 것이 훨씬 더 빠르다.

B는 계속적으로 A와 synchrous할 수 있도록 머가 어떻게 바뀌었는지, 계속 물어봐야한다.
A의 사소함은 B에게 커다랄 수 있는 중대함으로 다가올 수 있기 때문에, 늘 염두를 해야한다.

An Evaluation of the Ninth SOSP Submissions

How to give research talk

Advice to authors of extended abstracts

how to Organize your Thesis

Techniques and Suggestion for Presentiers



논문쓰는 방법에 대해서 잘 나온 것들이다.

Becoming A Real Programmer 싸이트를 pthread 자료로 보던중 보게 되었다.

이 글은 진정한 프로그래머가 되는 길로 번역을 할만하다.
진정한 프로그래머가 되기 위해서는 수년의 시간이 필요하며, self criticism을 통해서 스스로 처음보다 발전하도록 노력해야 한다.

새로운 시점으로 보기 위해서 기다릴 줄 알아야 하며, 이해가 안가고 새로운 무언가를 다룰 때는 잠시 그 일에서 손을 떼고 다시 돌아와 그 것을 볼때 못보던 것을 보고 이해를 할 수 있다.

빠른 길이 반드시 좋은 길이 아니어서, 배우는 것을 놓칠 수 있가 있다.
전에 배웠던 lessons(교훈이란 말이 적절)을 통해 waste of time(시간을 아깝게 버림)을 없앨 수 있다.
그리고, 다른 사람의 실수를 통해서 나 자신의 실수처럼 여기고, 봐주며, 실력이 늘어야 한다. 배우는 과정에서는 Pride는 상당한 장애이다. 나는 "똑똑하다"고 생각하면, 절대로 실력이 늘 수 없다. 좋은 코드가 나오기 위해서는 겸손한 자세로 test-case를 생각하며 코드를 체크하는 것이 중요하다.

과거에 실수를 통해서 똑똑해지고, 항상 게으르지 않도록 자신을 채찍질하며, 과거 했던 것들을 잘 생각하여 공부하는 것이 중요하다.

겸손한 마음을 통해서 팀원이나 다른 프로그래머들이 못푸는 문제나 버그들을 해결하며, 항상 공부하는 자세로 일해서, 능력있는 프로그래머가 되어야 겠다.

2005년 5월 - 이글루스 내 블로그에서

 

Virtual Memory, Processes and Sharing in Multics
멀틱스를 구현하면서 현대 운영체제의 시초가 되는 addressing, process, 메모리 관리, 공유에 대한 개념들을 하나하나 설명했다.
일반적인 운영체제의 내용과 거의 흡사했다.
링킹파트는 이해가 힘들어 우선은 넘어가야겠다.ㅡ.ㅡ; 어렵당..

2005년 3월 - 이글루스 내 블로그에서

 

Dawid Kurzyniec and Vaidy Sunderam. Efficient cooperation between Java and native codes -- JNI performance benchmark. In The 2001 International Conference on Parallel and Distributed Processing Techniques and Applications (PDPDA), Las Vegas, Nevada, USA, June25-28 2001.

각 JVM별로 JNI 성능은 얼마나 될까? 이런 궁금한 의문점없이 손쉽게 jni 코딩한다는 것은 상당히 위험스러울 수 있다. jvm 에 따라서 똑같은 코드라도 성능차이가 훨씬 나을 수 있는, 어떤 메소드의 형태냐에 따라 느리고, 빠르다는 것을 알수 있는 벤치마크 논문을 소개한다.

(1) non-virtual/ virtual invocation mode
(2) callback method invocation
(3) field access(private, virtual, static) / no,8 args
(4) arrays and strings
(5) exception
(6) 기타 jni 콜

이렇게 6가지 형태로 나누어서 벤치마크를 했는데, 전체적으로 볼 때, linux의 libm(IBM 1.3.0, jitc for Linux), windows의 wcli(Sun HotSpot Client 1.3.0-C for Win32), wibm(IBM 1.3.0, jitc for Win32) 등이 다른 vm보다 월등히 좋은 성능을 보여주었다.

이 논문에서는 다음과 같은 결론을 내리고 있다.

JIT-optimized 자바보다 다른 JVM은 느리다.
JNI에서 String을 리턴하면, 상당히 overhead가 존재한다.
작은 기능은 JNI에서 쓸 이유가 없다.
callback의 빈번함은 속도의 저하를 일으킨다.
jni 구현은 VM마다 다를수 있고, 새버젼이라서 무조건 빠로고, 성능이 좋다고 판단할 수 없다.
(lcls가 속도가 많이 늦은 이유는 복잡한 메모리 모델 알고리즘을 사용하기 때문이라고 한다.)

JNI가 항상 java보다 느릴 수도 있음을, 그리고, 어떤 메소드를 쓸 때는 상당히 조심스러운 부분이 있어야 함을 배웠다.
약간 아쉬운 부분이 있다면, 왜 jitc의 성능이 왜 좋은지, 어떻게 했기까닭에 좋을 수 밖에 없는지 약간의 비교, 분석이 있었으면 참 좋았겠다는 생각이 들었다.

2005년 3월-이글루스 내 블로그에서.

 

논문에 대한 비평문 형식으로 작성을 한다. 연구의 아이디어가 아니라 연구 방법론에 중점을 두고, 특별한 이유가 없으면, 2페이지 내지 3페이지내로 작성하는 것이 좋다.

글을 쓸때는 다음의 질문을 머리속에서 생각하며 고민할 필요가 있다.

1. 논문의 목적은 무엇인가?
2. 논문을 쓴 저자들이 실험해 보고자 하는 가설이 있는가? 있다면 무엇인가?
3. 실험 환경은 어떻게 설정했는가?
4. 연구는 얼마나 잘 수행되었는지. 어떤 결과를 얻었는지?
5. 결과는 믿을수 있는가? 그 이유는?
6. 내가 이 연구를 수행했다면 어떻게 바뀔 수 있을까? 어떤 점이 달라질까?
7. 이 논문을 읽고 얻을 수 있는 것은 무엇인가?

Evolutionary Desgin 은 Martin Fowler와 인터뷰한 article이다.

소프트웨어 개발 방법론으로 설계를 튼튼히 하고, 개발하는 방법과 아무 디자인없이 개발하면서 점진적인 수정을 통해서 다뤄지는 두가지로 나눌 수 있다.
마틴 파울러는 처음 시작할때는 아무 디자인 없이 기능성을 바탕으로 코등하면서 시작하는
Evolutionary design방법을 소개 하고 있다.

즉, upfront 개발 디자인 방법이 썩 좋지 않다는 의견을 모으고, 디자인을 하면서 복잡성은 늘어가고, flexibility가 사라진다. 그리고, upfront 형 코드는 생각을 많이하며 refactor을 하는데 부담이 된다. 그래서, unit test와 약간의 refactoring 법칙을 통해서 보다 능률적이고 빠르게 일처리를 하고 defect를 줄이는 데 목표를 두고 있다.

well-factored 프로그램과 well-designed 프로그램의 차이는 없으며, 강조의 차이만 있다. 즉, 궁극적인 목표는 서로 같다.

코드에서 냄새가 나는 경우를 살피는 것이 중요하다. 즉, 한 메소의 라인수가 100라인이 넘어서면, 그때는 bad smell이 난다고 판단을 해야 할 것이다. 그래서, 잘 쪼개서, 버그를 쉽게 잡아내는데 있다. 크기가 크면 클수록 버그가 어디서 문제인지 알아차리기 힘들고, 직관성도 떨어지기 때문에 문제를 쉽게 처리하는 것이 중요하다.

하지만, 무조건 디자인 자체를 무시하는 것은 상당히 위험스러운 소지라고 생각이 든다. 즉, 버그의 시작은 구조적인 문제에서 시작되는데, 이는 실제 나중의 사소한 버그에도 관련이 있다. 시스템 구조의 문제를 알아차리기 위해서는 먼저 well-planed design의 detail한 부분까지 가야 구조의 문제의 일부를 겨우 알아차릴 수 있게 될 것이다.

작은 프로그램도 아니고, 여러명이서 동시에 진행하는 것이기에 잘 설계된 구조로 가야 통합이 되기 쉽기 때문으로 보인다. 점진적인 개발과 잘 설계하는 개발, 이 둘이 잘 조화되어서 개발되는 방법론이 가장 멋지지 않을까?

즉, 아주 세부적인 부분까지 계획하지 않고, 구조를 잡고, mock형태의 evolution design을 하는 것이 어떨까? 그러면서 시스템 구조는 구조의 설계대로, 코드별 설계는 설계대로, 그리고 서로간의 상호작용에 의해서 소프트웨어가 멋드러지게 개발되는 건 어떨까?

기타 참고 자료

To be explicit
from http://martinfowler.com/articles.html

음.. 이거 언제 다 보냐..

 

2005년 2월 11일-이글루스에서 쓴 글

 

그동안 이 글을 쓰지 못한 이유는 자신감 상실이었다.

해야할 리스트는 있지만, 하지못함과 능력이 온전치 못해서 오는 무능함이다. 발걸음 하나하나 옮기는 게 쉽지가 않다. 최선을 다해야 함에 불구하고 그러하지 못함에 오는 괴리감은 이글루스를 쳐다보지도 않는 것으로 표현이 되는 거 같다.

잡담은 여기서 끝낸다.

Extensible Security Architectures for Java 를 읽은지 거의 3주가 넘어갔다. 이 논문은 프린스턴 대학교에서 나온 논문이다.

자바는 모든 프로그램에 제한적인 보안정책을 사용하고 있다. 이보다 좀더 확장된 보안모델을 이 논문에서는 3가지부분으로 제한하고 있다. 이는 capability system, name space management, stack instrospection 으로 나누어서 해결책을 제시하고 있다.

자바에서는 Sandbox Model 이라는 보안정책을 사용하고 있다. 즉, local과 remote 코드로 분류하고 이것을 구분하는 것은 ClassLoader가 담당을 하고, applet인지 system 메소드인지 구분하기 위해서 stack frame의 수를 계산함으로써 (stack inspection) classloader의 depth를 이용하는 기법을 말한다.
(정확하게는 잘 몰라서, 공부해야될듯.. 대충만 알고 넘어간다.)

해결방법으로 capability system을 먼저 제시하고 있다. 즉, 제어되는 system resource에 대한 위조할수 없는 포인터를 의미한다. 인터페이스를 제공하여 interposition을 implement한다.

두번째, stack introspection이다. 이는 익스플러어나 네트스케이프에서 제공되는 것으로서, 자바의 기본 기능을 확장한다. 파일과 같은 시스템 자원을 보호할때, 자원에 대해서 target이 정의되고, 접근전에 System이 target에 대한 권한을 체크하며, 권한에 대해서 enable, disable을 통한 자원 접근 제어 방법을 제시한다.

세번째, name space 관리로서, Runtime때의 클래스를 name space에서 제거 혹은 다른 특정 클래스로 매핑하도록 하는 것이다. Classloader를 수정하여 동적으로 제어가 가능한 방법을 제시한다.

이들 모두가 성능과 구현면에서 어느정도의 효과를 볼지는 상당히 미지수로 보이는 게 흠이다. 기존의 자바 메커니즘의 한계를 넘어가는 stack inspection은 괜찮아 보인다.

팀장님으로부터 논문을 한주에 하나씩 쓰는 연습을 해보시라고 권유하셔서, 생전처음 블로그도 만들어보고, 공부도 되고, 글쓰는 연습을 계속 해보려고 한다

Growing a language는 논문인지 아닌지는 잘 모르겠다. 98년도 OOPSLA에서 발표된 자료이며, 당시 Sun에서 근무하던 Guy Steele이 저자이다.

언어적인 접근이 상당히 마음에 든다. 단어, 동사에 대한 문법적인 접근을 통해서 프로그래밍 언어의 디자인에 대해서 small하지만, 뒷사람(추후에 언어를 접근하는 사람들)에게 가능성을 디자인하도록 하는 접근이 가장 마음에 들었다.

저자는 처음부터 완벽하게 library를 제공하는것이 아니라, 틈새(niche)가 없는 small 언어가 성장이 가장 높은 언어가 될것이다라고 말을 하고 있다. 그러면서, Lisp을 추천하고 있다. (Lisp을 잘 모른다.. //TODO : study LISP)

언어의 성장 키포인트는 vocabulary와 새로운 word에 대한 의미를 정의하는 것이라며, 사람들간의 커뮤니케이션하는 언어를 묵시적으로 비교 설명하는 글이 상당히 인상적이었다.

그러면서 언"어의 일부분은 성장을 도울수 있도록 디자인하는 하는 것이다" 라고 말하며, 자바 언어의 generic types, operator overloading, user defined types, vectors가 앞으로 여러 사람들에 의해 추가될꺼라고 말을 하며 글을 읽는 독자에게 작은 언어를 만들어보라며 시도하는 것으로 끝을 내고 있다. (I urge you, too, to give it a try)

프로그래밍 언어에서는 어느정도의 틀을 틈새없이 작게 개발하여 다른 사람들에 의해 다양한 라이브러리를 추후에 개발이 되도록 디자인하는 것은 언어의 scaliability가 높일 수 있다. 지금의 JSR과 같이 다양한 소프트웨어 엔지니어들의 참여를 통해서 라이브러리를 추가하거나 언어자체에 대한 수정연구가 진행중이 Java가 가진 큰 특징이라 할 수 있다.

그런데, 너무 커지면 어떻게 될까? 개인적으로 Java의 철학, Write Once, Run Anywhere! 의 문구는 이미 현실성이 없다고 생각한다. 복잡해지고, 다양해지고, 어디가 머가 있는지, 찾기도 힘든 건 아닐까? 기능의 추가는 역시 엔지니어에게는 좋은 장점이긴 하지만, 너무 많아지만, 최초 언어를 배우는 사람에게는 커다란 진입장벽이 아닐까 하는 생각이 든다.

언어가 계속 발전하는 것이 좋은가? 아니면, 어느정도 성장을 멈춰야 하는가? Growing a language에 대한 나의 입장은 아직은 지켜보아야 할꺼 같다.


상대적으로 중간에 읽다가 어려워서 손을 놓은 다른 논문과 달리 이글은 상당히 이해하기 쉬워서, 나의 첫 블로그에 글을 남기는데 좋은 자료가 될 꺼 같다.