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에게 커다랄 수 있는 중대함으로 다가올 수 있기 때문에, 늘 염두를 해야한다.

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

 

상당히 부담스러울 정도로 나에게 압박을 준다. 책 한권이 마치 1ton의 무게가 나가는 건물이 나를 누르는 느낌이다. 아직 8장밖에 읽지 못했지만, 앞으로 기대가 되는 책으로, 그동안 읽은 것을 잠깐 소개하고자 한다.

1. 재미있는 명세
나에게 부담스러운 부분은 글쓰기이다. 그 중에 가장 부딪히는 부분은 초안, Proposal, comment라 할 수 있겠다. 특히 주석은 공유할 때, 곧바로 화살이 날아오는 부분이라 가장 신경쓰는 부분이기도 하다.
글을 쓸때 항상 명료하고 딱딱하기 쉬우면, 틀리기 쉽고, 다시 내가 읽을 때에도 무슨 말인지 몰라서, 다시 지우고 글을 쓰게 된다. 조엘 온 소프트웨어에서는 재미있게 쓰는 명세를 권하고 있다. 즉, 시나리오를 생각하며, 글을 쓰기를 바라며 칭찬하고 있다.

2. 가혹하리만큼의 솔직함
책에서 얼간이, 바보, 대단한 사람이라고 표현할 정도로 약간의 비꼬는 기술적인 책은 조엘 온 소프트웨어가 처음이다. 상당히 솔직하고, 명세적이고, 순수하리만큼 잘 쓰여진 책이 마음에 든다.

3. 정확한 진단
이 책에 대해서 가장 멋있는 표현을 썼다. 날카로운 진단, 분석 이라는 말도 괜찮을 법 싶다. 2장 기본으로 돌아가기 파트는 상당히 가슴이 뜨거워지는 부분이다. 삽질하는 러시아 페인트공 알고리즘, XML에 대한 정확한 인식, 하향 평준화에 대한 분석은 가슴깊이 반성하는 부분으로서, 앞으로 계속된 프로그래밍 마인드에 상당히 도움이 될 것으로 보인다.


조엘은 대학생이 갖춰야 할 지식 목록 으로, 다음을 꼽았다.
1. 졸업 전에 작문법을 배운다
2. 졸업 전에 C를 배운다.
3. 졸업 전에 미시 경제학을 공부한다.
4. 따분하다고 비 전산 과목을 등한시하지 마라.
5. 프로그래밍 심화과정을 수강하라.
6. 모든 직업이 인도로 넘어간다는 걱정은 그만둬라.
7. 무엇을 하든 여름 인턴과정을 거쳐라

나는 C와 작문을 소홀히 했고, 심화과정을 수강은 했지만, 올바로 적용을 하지 못하는 부분이 있어서, 이 부분을 고치고 공부하는 것이 중요하다고 생각이 든다. 경제학 원론, 민법 총칙을 수강하였으며, 비 전산과목(법학, 종교, 역사, 심리학)에 관심이 많고, 4학년때 임베디드 시스템과 자바 프로그래밍을 해본 것이 그나다 다행이라는 생각이 든다. 하지만, C코딩과 작문법, 전산 심화과정이 가장 약하므로, 열심히 해야겠다는 생각이 든다.

조엘은 소트프웨어팀 평가 테스트를 다음을 들었다.
1. 소스코드 관리시스템을 사용하고 있습니까?
2. 한방에 빌드를 만들어 낼 수 있습니까?
3. 일일 빌드를 하고 있습니까?
4. 버그 추적시스템을 운영하고 있습니까?
5. 코드를 새로 작성하기 전에 버그를 수정합니까?
6. 일정을 업데이트하고 있습니까?
7. 명세서를 작성하고 있습니까?
8. 조용한 작업 환경에서 일하고 있습니까?
9. 경제적인 범위 내에서 최고의 성능의 도구를 사용하고 있습니까?
10. 테스터를 별도로 두고 있습니까?
11. 프로그래머 채용 인터뷰때 코딩 테스트를 합니까?
12. 무작위 사용편의성 테스트를 수행하고 있습니까?

팀장님의 뜻을 조금씩 조금씩 이해가 가고 있는 거 같다. 팀원들과 공유하고 어떤 비전을 공유하고 싶은지 서서히 감이 잡힌다. 일찍 잡혀야 했는데, 이제서야 잡히다니, 어서 팀원들을 보고 싶다..


참고 : 3장, 4장에 오타 발견했다.

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은 괜찮아 보인다.