August 2008 Archives

올해 처음 시작해 본 베란다 텃밭 이다. 거의 실패하고... 생각지도 못한 고구마만 무성하다.

보기 좋은 고추랑... 수박먹고 그냥 심어본 수박씨가 잘 자라 나온게 신기해서 올려 본다.

보낸 사람 베란다 텃밭

보낸 사람 베란다 텃밭

구글 맵을 블로그에  embed하기 위해서는 구글 코드(http://code.google.com/)에서 확인 할 수 있다. 목록에서 맵을 찾으면 된다.(http://code.google.com/apis/maps/)

구글 맵스 API에서 다음과 같은 순서로 작업하기를 설명한다.

1. Sign up for a Google Maps API key. (구글 맵스의 API키를 얻기 위해서 등록하라.)
2. Read the Maps API Concepts. (맵스 API Concept 를 잘 읽어보고..)
   
3. Check out some Maps examples. ( Maps의 예제를 체크할 것.. )
   
4. Read the Maps API Reference. ( Map API레퍼런스를 참조하라)
   

여름휴가.

서울서 열심히 달려서 목포 북항에 왔다. 여기서 비금도로 떠나는 농협 철부선(?)을 타고 떠났다. 8월 중순이 넘어가니 사람이 뜸해져서 인지 예정된 11시 보다 30분 전에 출발해 버렸다. 황당~~




섬까지 1시간 30분 여 걸린다. 연수의 지겨움은 기둥이 해결해 주는 듯..

명사십리 해수욕장이다. 너무 넓어서 광활한 수준이다. 여긴 모래가 단단해서 차로 달릴 수 있는데 끝까지 달리는데도 한참 걸린다.







엇!! 이것들 뭐야? 썰물이면 고동들이 잔치를 벌인다. 좀 징그러울만치 많이...
 





배경으로 보이는 해변을 봐라... 신기하지? ♡♡♡♡♡




방파제에서..



연꽃이 너무 너무 많은 못이다. 이름이 뭐더라(?) 하여튼 비금도는 스케일이 있다...
 









즐겁기만한 연수..

작년엔 비바람 속에서 놀았다. 덕분에 사람이 적어서 참 좋다. 연수도 많이 커서 튜브가 작다.


아빠가 가르쳐 주는 데로 준비운동도 잘하고 영차!



멋지게 수영이다....

[오해]프로그래밍은 비자아적(egoless)이 될 수 있고,또 되어야 한다.

출처 : 소프트웨어 공학의 진실과 오해

이 책에서는 The Psychology of Computer Programming(http://weinbergonwriting.blogspot.com/)에서 말한 "프로그래머는 그들이 만드는 제품에 자신의 자아(ego)를 투영해서는 안 된다." 라는 주장에 대해서 논하고 있다.

당연한 주장으로 받아 들일 수 있는 부분이다. 프로젝트에서 오류보고서, 동료검토 등을 인신공격으로 받아 들이는 개발자들이 너무도 많이 보아왔고 나 역시도 그 부분에 자유롭다고 말할 수는 없다.

그렇다면 그냥 "자아를 투영하지 말라" 라고 교훈을 주는 것이 끝일까? 사실 어느 누구도 프로그래밍에 자아를 투입시키지 않을 자신이 있는 사람은 없을것이다. 그럴수 있다고 말하는 사람은 어쩌면 프로그래밍에 정성을 쏟지 않는 다는 의미 일 수 도 있다.

이런 점에서 어떤 형태이든 팀 프로그래밍이 다른 대안보다 나은 것으로 인정되고 있다.

설계자가 숙지한 기본단위(primitive) 수준으로 문제가 분해됐을때 설계에서 코딩으로 전환된다. 설계자와 코더(coder)가 동일한 사람이 아니라면, 설계자와 코더의 기본단위가 같지 않을수 있고, 이는 문제를 초래할 수 있다.

출처: 소프트웨어 공학의 사실과 오해

요즘 공정분리에 대한 관심이 높다. 얼핏 설계의 상세성에 대한 논란이 많다. 내가 속한 조직에서는 설계는 무조건 상세 해야 한다는 식의 논리가 힘을 얻고 있는 듯 보인다.  이는 들쭉 날쭉한 코더의 개발 역량, 원격지에서의 커뮤니케이션 오류 등을 모두 염두에 두고 생각하는 듯 하다.

다만 이런 식의 공정분리가 우리에게 주는 것이 무엇일까? 첫번째 경제성에 대해 생각해보다. 얼핏 봐도 설계의 비용이 늘어서 경제적인 이득이 있다는건 아닌 것 같다. 인건비가 싼 중국, 인도에 코딩을 아웃소싱 한다 치더라도 설계의 비용이 늘어난 것에 대한 보전에 지나지 않을 것이다.

두번째, 개발프로세스에 대해 생각해보면.. 요즘 방법론은 Waterfall 방법론의 약점을 보완하기 위하여 점진적인 방법론의 성향을 띈다. 더 나아가 Agile방법론에서는 일주일단위의 iteration을 운영하는 방법을 쓰기도한다. 이런 방법론에 공정분리가 적절한가?  iteration이 잦을 수록 공정분리에 따른 커뮤니케이션 비용, 시간이 증가할 것이다.

세번째, 고객이 공정분리가 가치있는 것이라고 생각하겠느냐? 공정분리를 한다고 고객에게 설득하는 것이 쉽지 않다고 한다. 얼핏 생각해도 설계 이후엔 요구사항의 변경이 힘들것 같다는 생각이 지나간다.고객의 입장에서도 한번 내 뱉은 요구사항을 번복하기가 쉽지 않다는 것을 받아들이기가 어려울것이다.

지금까지 공정분리에 대해 심하게 깐것 같지만 공정분리라는 말이 나온 것은 다른 곳에 있는 것 같다. 설계/코드 를 1인이 하는 경우에 설계의 품질이 엉망이라는 판단에서 일 것이다. 문제는 문제가 있는 곳에서 해결하라는 말을 하고 싶다.
설계의 품질이 엉망이란 것은 아직도 우리가 Waterfall에서 벗어나지 못해서 초기 설계에 대한 수정 없이 그냥 진행해 버리는 것 일수도 있고, 개발자(설계자+코더)들은 자신에게 Burden으로만 느껴지는 무거운 산출물을 본능적으로 무시고 싶을 것 같기도 하다. 그런면에서 Agile 방법론이 빨리 빨리 자라줬으면 한다.

소프트웨어 문제에 대해 최상의 솔루션이 하나인 경우는 거의 없다.

출처 : 소프트웨어 공학의 사실과 오해

프로젝트에서 어떤 문제에 부딛혔을 때,  PM이 물어 본다.

PM: "이거 해결할려면 어떻게 해야 하지?"
나 : "이걸 이렇게 해결하려면 A방법과 B방법이 있습니다. 음.. 그런데 A방법은 당장 X솔루션을 구매 해야 하기 때문에 추가 비용이 발생합니다. 그리고 B방법은 개발 공수가 많이 들고 품질이 떨어질 우려가 있습니다. "
PM: ...
PM: 그럼 어떻게 하면 좋겠는가?

이런식으로 대화가 진행된다. 여기서 판단은 PM이 해줘야 하는 것 아닌가? 비용, 시간 , 품질 등을 놓고 저울질 해야 하는 사람이 당신이 아니오??? 라고 강하게 말하고 싶은데.. 현실을 그렇지 않다.

나 : (반복) A는 돈이 들고 B는 개발자가 고생하고 품질이 떨어질수 있습니다.
PM : 그래서 뭘로 하자는 거야?

짜증이다... !!

"개인차"에 관한 연구에 따르면, 최상의 프로그래머는 최악의 프로그래머 보다 28배 더 뛰어나다, 여기에 비례해서 이들에게 임금을 28배 주는 것이 아니라면, 이들은 소프트웨어 분야에서 가장 값싸고 훌륭한 자원이다.

출처 : 소프트웨어 공학의 사실과 오해


SI프로젝트에 SW아키텍트로서 참여해 오면서 몇번 개발자의 면접을 본 적이 있다. 그리고 내손으로 뽑은 개발자와 함께 프로젝트를 진행해 오면서 "앗차 이사람은 뽑지 말았어야 했는데..!", "이 사람은 개발 역량이 너무 없어..!", "이 사람과 2년만 같이 일하면 속터져 죽을거야..!!!" 등의 후회를 해 본적이 있다.

그 때마다 정말 뛰어난 개발자를 알아보는 방법이 있을까?
지난 수년간 프로그래머 자질 테스트, 각종 인증시험 등..으로 알아낸 결과는 이 시험과 실무 능력은 별 상관이 없는 것 같다...

특히 SI 프로젝트에서와 같이 단기 프로젝트에서는 더욱더 막막한 일이다.  개발자들과 같이 일하고 1개월 정도이면 어느 정도 개발자의 생산성을 파악할 수 있는데... 6개월 근처의 납기를 가진 프로젝트에서는 그 인력을 교체하기에 이미 늦었다고 볼 수 있다.

 

 

OKJSP에서 개발자 면접에 대한 고민의 댓글 중에 쓸만한 놈을 가지고 왔다.

 

1. Object, Class, Instance를 각각 설명하시오.
2. 개발환경을 스스로 구축해 본적이 있는가?
3. 지금껏 문자열을 다루면서 가장 곤란했던 경험을 이야기하고 해결과정을 설명하시오(한글문제 포함)
4. static 키워드의 의미를 설명하시오
5. stack과 queue를 각각 설명하시오.
7. 오버로딩과 오버라이딩의 차이를 설명하고 간단한 적용 예를 구현해 보시오(종이&연필)
8. interface의 의미를 설명하고 interface를 이용하여 간단한 패턴을 구현해 보시오.(종이&연필)
9. Collection Framework에 대하여 설명하시오.
10. 가장 최근에 수행했던 프로젝트에 대하여 설명하고, 어려웠던 점, 보람찼던 점, 팀원들에 대하여 이야기하시오..

영문 사이트는 별다른 노력없이 그럴 듯한 폰트 만으로 멋스런 느낌을 줄 수 있다. 계속 부러워 해 왔었는데.. 영문과도 잘 어울리고 자체로도 아름다운 폰트가 나왔다. 바로 "맑은 고딕체" 이다.

맑은 고딕체를 웹페이지에서 표시하기 위해서 CSS를 수정할 필요가 있다.

만약 Body의 모든 글을 맑은 고딕으로 하고자 한다면 body selector를 다음과 같이 작성한다.

body{
    font: normal 13px 'Malgun Gothic';
}

이것은 단순한 컨셉이다.
시스템이나 라이브러리, 프레임웍은 적절한 기본 설정을 포함하고 있어 쓸데없는 설정작업을 하지 않고도 적절히 작동해야 한다는 것이다.

Ruby on Rails나 EJB3와 같은 프레임워크는 이 컨셉을 잘 따르고 있다. 

Maven도 이 컨셉을 따르고 있는데 커스터마이징을 하지 않으면 디렉토리 구조가 아래와 같다고 가정해 버린다.

${basedir}/src/main/java - java 소스 디렉토리
${basedir}/src/main/resources - resources 디렉토리
${basedir}/src/test - test code 디렉토리

${basedir}/target/classes - 컴파일된 byte code 디렉토리
${basedir}/target - 배포할 jar파일 디렉토리

이런 디렉토리 구조는 사소한 것이지만 ANT를 사용할때는 항상 결정해야 하는 귀찮은 일이다.
Maven은 디렉토리 구조 뿐만아니라 소스코드 컴파일, 패키징, 웹사이트 생성 등 많은 프로세스에서 Convention Over Configuration의 Concept를 적용했다.


출처 : maven definitive guide

자동화된 컴포넌트 레벨의 단위테스트를 수행하기 위해서 환경들은 여전히 골치 거리이다. 내 창의성으로는 WAS, DBMS에 역인 넘들은 테스트가 불가능 하다고 버려 두었다.

요즘 느끼는 건데 실전에서 가치있는 내용은 책의 중간이나 후반부에 나오는 것 같다. "실용주의 프로그래머를 위한 단위 테스트 with JUnit" 를 읽다가 Mock Object에 대한 부분에서 눈이 번쩍 뜨인다.

<참고 사이트>
http://www.mockobjects.com
http://www.easymock.org

Movable Type 설치 완료