watist's blog ... I am interested and passionate in building software.

계획을 세우는데 도움을 주는 엑셀 양식 2개

최윤호 — Wed, 02 May 2012 10:37:41 +0900

우울함 속에서도 중심을 찾아보려 노력 중인 2012년 입니다.

계획을 세우는데 엑셀 양식만한 것이 없죠.

인터넷에서 찾은 달력 양식 파일과, 월지출 계획 실적 내역 파일입니다.

calendar2.xls

월지출내역.xlsx

빨리 정신차려서 이 늪을 벗어 나야 할 텐데, 이번 5월달 출력하는 것으로 시작해 봐야겠습니다^^

부탁할 땐 미안한데로 시작하세요.

최윤호 — Thu, 12 Apr 2012 11:13:08 +0900

이제야 결혼 6년차.. 맞나...

이런 이야기 쓸데없는 것일 수도 있지만, 4월을 맞아 주변에 결혼하는 많은 분들을 보며 느낀 점이 있다.

부인에게, 남편에게 무엇인가를 부탁할때는 꼭 "미안한데"로 시작해서 "고마워"로 끝내자는 것이다.

결혼은 양쪽 모두에게 부담스러울 수 있는 상황이다.

먹고, 자고, 씻는 것 모두가 자연스럽고 편하던 생활에서 이제는 그렇지 못한 상황이다.

배우자에게 무엇을 부탁할 때도 마찬가지이다.

아들이, 딸이 엄마에게 밥 달라고 하는 거야 당연한 것이지만(이제 나이 먹으니 이것도 당연하지 않은 것처럼 느껴지지만 그래도 엄마가 밥 해주는 게 좋다), 아내가 밥 하는 게 당연하다고 생각하면 곤란하다.

밥 달라고 하기 전에 "미안한데, 배가 고파서 그러는데 밥 좀 주면 안될까?"로 시작해서, 먹는 게 라면일지라도 "응, 고마워"라고 끝내면 좋다.

물 좀 떠달라고 부탁하고, 리모콘 좀 건네 달라고 부탁하고, 분유 좀 타 달라고 부탁하고, 수도꼭지 교체해 달라고 부탁하고, TV 좀 끄라고 부탁하고, 귀가 길에 과자 사 오라고 부탁하고, 부모님께 안부 전화하라고 부탁하고, 기저귀 가는데 잡고 있으라고 부탁하고, 놀아 달라고 부탁하고, 청소기 돌려달라고 부탁하고, 전등 갈아달라고 부탁하고, 소풍 가자고 부탁하고, 계좌 이체 해 달라고 부탁하는 등 이루 헤아릴 수 없이 많은 부탁이 있는데 이 때는 항상 "미안한데"로 시작해서 "고마워"로 끝내자.

선택과 나의 삶

최윤호 — Fri, 06 Apr 2012 09:42:32 +0900

20대에 나를 괴롭혔던 많은 문제들이 사실은 선택의 문제였단 생각이 든다. 그때는 필수이고, 회피의 대상이던 것들이 이제는 선택의 문제처럼 느껴진다.
상황에서 멀어지면서 비주관화되어버린 것일 수도 있고, 관념화되어버려 추억으로 간직하게 된 것인지도 모르겠다.
단지 후에 지금 겪고 있는 상황과 시련도 비슷하게 느껴지지 않을까? 내가 모든 것을 결정해 온 것은 아니지만, 그렇다고 내 선택이 작동하지 않았다고 장담할 수 있을까?
지금의 내 생활에 대한 더 당당하고 자랑스러운 태도를 갖아야겠다는 생각이 든다. 나의 생활과 삶은 타인과 상황에 의한 필수의 문제가 아니라 선택의 결과니까 말이다.

EBS 오페라 하우스

최윤호 — Mon, 05 Dec 2011 21:02:20 +0900

주말 오전에는 규연이 덕분에 EBS를 많이 보는 편입니다.
식사할 때나, 같이 놀때도 그냥 습관적으로 틀어 놓습니다.
혹시라도 규연이가 집중하면 쉬시식~~ 다른 일을 하려고 말이죠.

지나 12월 3일도 그렇게 틀어놨는데, 좀 유치한 듯한 만화가 하네요.
그림체는 동화처럼 만들었고, 움직임은 그림체때문에 어색하고, 중간중간의 3D 캐릭터들은 너무 원색이고, 뭔가 조잡한 기운이 느껴지는 뭐 그런...

근데 보고 있으려니 재미있습니다. 다른 것은 잘 모르겠지만, 참 재미있습니다.
EBS에서 한달 동안 4번 반영하는 오페라 하우스의 마술피리였습니다.
http://home.ebs.co.kr/opera/index.html

규연이는 옆에서 열심히 종이 오리기 놀이하는 데 혼자 열심히 봤습니다. ㅎㅎ
여차여차 하여 다시 보기는 안 된다는데, 기회가 되신다면 지금부터라도 재미있게 보세요.
남은 3개도 마술피리만큼 재미있으면 좋겠네요.

주인공이 성에 들어가기 위해 문지기와의 대화하는 중에 문지기가 이런 말을 합니다.
"그게 사실이긴 하지만 진실은 아니다."
요즘 곰곰히 생각하게 하는 "실체적 사실"의 문학적 표현이 "진실"일까요?
"진실"은 숨겨진 의도가 고려된 사실인 것일까요?

어렵지만, 재미있는 마술피리였습니다.
제발 나머지 3개도 보게 해줘~~

PC 모니터 변경

최윤호 — Sat, 26 Nov 2011 21:48:54 +0900

어느덧 각종 PC 사양에 욕심 부리던 시기는 지났지만, 최근 모니터를 바뀌니 정말 좋네요.
제품은 FLATRON E2360인데, 제가 직접 구매한 것은 아닌지라 제일 비슷한 모델이 플랫트론 E2360V-PN같습니다.

기존 모니터도 LG 17인치 LCD를 8년 가까이 썼는데, 사실 고장나면 바뀌야지 하는데 좀처럼 고장이 안 나네요.
일단 교체하긴 했는데, 듀얼되는 그래픽 카드로 업그레이드 하게 되면 서브 모니터로 사용하면 될 것 같습니다.

기존 모니터와 새 모니터입니다.
정말 화면도 시원시원하고, 브라우저는 2개를 좌우에 띄워도 딱 좋고, 동영상을 보는 재미도 더 좋습니다.
가로 두께도 정말 앏게 잘 나왔는데, 기존 것은 17인치고, 이건 23인지인데도 이게 더 가벼워요~~ ㅎㅎ

SSIS에서 오류가 발생한 데이터 로그에 쌓기

최윤호 — Thu, 24 Nov 2011 23:13:09 +0900

업무에서 SSIS를 사용하다보니 하나, 둘 생각해야 할 것들이 생깁니다. 역시 그냥 데이터 추출해서, 간단히 꽂는 것만 알아서는 "제대로" 업무에 적용하기가 쉽지 않습니다.
상당히 직관적인 이름과, 말풍선 도움말이 있어 전체적으로 이용하기 어렵지 않음에도 오류가 발생한 데이터가 무엇인지 확인하는 작업은 쉽게 구상이 되지 않네요. 다행히 MS가 제공하는 친절한 자료가 있습니다.

SSIS 자습서: 간단한 ETL 패키지 만들기 > 5단원: 오류 흐름 리디렉션 추가
http://msdn.microsoft.com/ko-kr/library/ms169917.aspx
http://msdn.microsoft.com/ko-kr/library/ms166569.aspx

1) 스크립트 구성 요소를 추가해서 오류 발생을 의미하는 붉은 선을 연결하고, 각각의 원본과 대상에서 오류 발생시 행 리디렉션을 선택합니다.
2) 그리고 스크립트 구성 요소 안에서는 ErrorDescription의 출력 열을 추가하고, 스크립트 편집기를 열어 Input0_ProcessInputRow 메서드에 다음의 명령을 추가합니다.

[VB] Row.ErrorDescription = Me.ComponentMetaData.GetErrorDescription(Row.ErrorCode)
[C#] Row.ErrorDescription = this.ComponentMetaData.GetErrorDescription(Row.ErrorCode);

3) 마지막으로 오류가 발생한 행을 저장할 플랫 파일 대상을 연결해서 적절한 이름과 파일 경로를 설정하면 됩니다.

그럼 다음과 같은 결과를 보실 수 있습니다. 화면은 Number 타입에 문자열이 들어 있는 원본 오류과, PK 중복 오류가 발생하는 대상 오류를 샘플링한 결과입니다.

추가 URL>
Capturing and Logging Data Load Errors for an SSIS Package
http://www.mssqltips.com/sqlservertip/2149/capturing-and-logging-data-load-errors-for-an-ssis-package/
좀 더 복잡하지만, DB를 이용해 오류가 발생한 데이터를 ErrorLog 테이블에 저장하는 방법입니다.

SSIS 오류 및 이벤트 참조
http://msdn.microsoft.com/ko-kr/library/ms345164.aspx

[서평] 예제로 쉽게 배우는 프로페셔널 ASP.NET MVC

최윤호 — Mon, 14 Nov 2011 00:36:02 +0900

예제로 쉽게 배우는 프로페셔널 ASP NET MVC
2011-11-13
롭 코너리 , 스콧 핸슬만 , 필 해크 , 스콧 구스리, 역자 장현희, 제이펍

유명한 빨간책 시리즈입니다. 보통 한가지 주제에 대해서 Beginning과 Professional 두 종의 책을 출판하는데, 이 책은 독특하게도 ASP.NET MVC 개발팀에서 집필한 "예제"가 강력한 책입니다.

책은 1장에서 전체 570페이지 중에 220페이지를 할애해서 NerdDinner라는 모임을 등록하고, 근처 모임을 검색해서, 모임에 참여를 신청할 수 있는 ASP.NET MVC 애플리케이션을 완전히 구현합니다. 기본적인 데이터베이스를 생성하고 모델 객체를 구현하고, 컨트롤러와 뷰를 추가한 후에 데이터의 생성과 수정, 삭제를 위해 이를 확장합니다. 이중에 ViewModel을 사용하는 방법, 부분 뷰와 마스터 페이지, 페이징 기능을 설명합니다. 그리고 인증과 권한을 부여해 보안을 적용하고, AJAX를 이용한 동적인 모임 참여 기능을 구현하고, 지도도 통합합니다. 그 후에 단위 테스트를 수행하는 방법을 설명합니다.

그리고 이어지는 2장과 3장의 개념 소개를 지나, 4장부터 11장까지 1장에서 NerdDinner를 만들면서 사용했던 방법을 하나하나 설명합니다. 마지막 12장은 독특한 지위로 웹폼과 MVC를 동시에 사용하는 애플리케이션을 구성하는 방법에 대해 설명합니다. 물론 1장의 예제가 완전하다고 해서 나머지 장이 의미없는 반복은 절대아닙니다. 2장부터는 예제의 각 부분을 아주 상세하게 그렇게 작동하는 "이유"를 설명해줍니다. 특히나 "개발팀의 한마디"로 들어가 있는 내용은 유익할 뿐만 아니라 유쾌하기도 합니다.

ASP.NET에서 MVC를 이용하는 방법이 ASP.NET MVC 프레임을 사용하는 방법만 있는 것은 아닙니다. 다양한 방식으로 Model-View-Controller를 분리할 수 있죠. 하지만, 1장의 예제만 완벽히 따라해봐도 ASP.NET MVC가 어떻게 작동하는 지를 이해하고, 이를 어떻게 사용해야 하는지에 대한 거의 완벽한 지식을 얻을 수 있습니다. 그리고 2장부터 "왜" 그렇게 했고, 그렇게 해야 하는지에 대한 설명이 담겨 있습니다.

높은 질의 애플리케이션을, 수용가능한 일정과 예산안에서 구현하는 것. 그것이 제 관심사이고, 이 책은 그에 대한 ASP.NET MVC 개발팀의 답변입니다. 제 생각에 요는 "ASP.NET MVC를 사용하세요."입니다. 저를 포함해 ASP.NET 개발자라면 이 책을 통해 ASP.NET MVC를 접해볼 이유가 확실히 있음을 자신하게 됩니다.

- 올바르게 이해하기 위해 계획을 세우지 말기를 바란다. ... 여러분이 "반드시 해야만"하는 것에 대해 논의하다 보면 금새 질려버릴 수 있다. 따라서 필자들이 여러분에게 요구하고 싶은 것은 여러분이 뭔가 잘못하고 있다고 말하는 것에 대해 걱정하지 말기 바란다. 여러부은 늘 잘못된 방향으로 가고 있다. 혹은 그렇게 보인다.

미래를 만든 GEEKS
2011-11-08
앤디 허츠펠드 지음, 역자 송우일, 인사이트

글쎄요. 처음에는 눈에 띄는 제목이라 읽기 시작했는데 내용은 제목과는 별로 어울리지 않는 것 같습니다. 1980년 당시 약 5년에 걸쳐 맥킨토시를 만든 팀의 이야기입니다. 당연히 주역은 고 스티브잡스와, 메인 보드 개발자 버렐, 핵심 그래픽 컴포넌트 개발자 빌 앳킨슨과 저자를 포함한 여러 프로그래머입니다.

"가장 친한 친구가 되어줄게"라는 유쾌한 에피소드에서 시작해서 팀이 꾸려지고("검은 수요일"), 잡스가 개입하고("현실 왜곡장"), 예술가적 노력을 기울이고("서명 파티"), 갈등이 생기고("브루스를 해고하면 안 돼요!"), 바쁘게 만들고("바쁘게 살다"), MS와 갈등을 빗고("제록스라는 부자 이웃"), 드디어 출시하는 이야기("가방에서 나오니 정말 좋아요!")를 담고 있습니다.

단지, 아쉬운 점은 일자 순으로 전개되면서도 짧게, 짧게 쓴 글의 느낌이 강하고, 전체적으로 정리된 글의 전개는 약하다는 점입니다. 인터넷 사이트에 연재하면서 생긴 스타일을 그대로 살려서 그런 것 같은데, 전체적으로 정리된 상태였으면 하는 아쉬움이 좀 남네요.

비슷하게 원도우 NT를 개발한 팀의 이야기를 다룬 "싸우는 프로그래머"[추가링크]도 재미있게 본 기억이 있습니다.

- 맥 팀은 스스로 이상적인 고객이 되어 다른 어떤 것이 아니라 자신이 원하는 것을 개발했다.

- 현실 왜곡장은 카리스마 있는 달변, 불굴의 의지, 눈앞의 목적에 맞게 현실마저 굴복시키려는 열의가 당황스러울 정도로 뒤섞인 것이었다. 한 마디 주장으로 설득하는 데 실패하면 잡스는 교묘하게 또 다른 주장을 했다. 때로는 그가 다르게 생각했음을 인정하지 않고 갑자기 상대방의 입장을 자신의 것인 양 각색해 상대방이 평정을 잃어버리게 하기도 했다.

- 1981년 여름 소프트웨어 작업을 약간 거친 다음 애플2용으로 가변폭 텍스트 위드 프로세서를 비롯해 조그맣고 멋진 GUI를 갖게 된 것이다. 우리 손으로 잠재적으로 가치 있는 제품을 만들었다고 생각했다. 이 GUI를 잡스에게 보여주기가 썩 내키지 않았는데 잡스가 그것을 빼앗아 갈 것임을 알았기 때문이었다. ... 잡스게에 보여 주었더니 불행히도 잡스가 새 GUI를 굉장히 좋아했다. 그러면서 우리가 그 GUI를 남는 시간에 개발했는데도 GUI에 대한 권리를 모두 애플이 소유해야 한다고 우겼다. ... 버렐과 나는 그 일을 빨리 극복했지만 씁쓸함이 약간 남았고 그 사건은 결국은 우리만의 일을 하고 싶다는 욕구를 자극했다.

- 맥 팀의 동기는 다양했지만 가장 독특한 부분은 예술적 가치를 강하게 경험한 것이었다. 무엇보다도 먼저 스티브 잡스가 스스로를 예술가라 생각했고 자신들을 그렇게 생각하라고 맥 팀에 장려했다. 목표를 경쟁에서 이기거나 돈을 많이 버는 것이 결코 아니었고, 최고로 훌륭한 일을 해내거나 조금 대단해지기라도 하는 것이었다.

- "이봐, 그건 코드를 짜는 바른 방법이 아니야. 당신들 해커야? 나는 해커들과 일하고 싶지는 않다고." 래리와 나는 바이트와 사이클을 최대한 절약하기보다는 빌이 화내지 않게 하는 데 더 신경을 쓰느라 수정 코드를 더 느리고 좀 더 보수적이며 빌이 인정한 기법을 사용하는 것으로 바꾸었다.

- 잡스가 소리쳤다. "나는 당신을 믿었는데 당신은 지금 우리 것을 훔치고 있어." 그러나 빌 게이츠는 냉정하게 그 자리에 서서 잡스의 눈을 똑바로 바라보며 찡얼대는 목소리로 이야기하기 시작했다. "이봐, 그 일을 보는 데는 여러 가지 시각이 있다고 생각해. 우리에게는 둘 다 제록스라는 부자 이웃이 있었고 내가 TV를 훔치러 그 집에 몰래 들어갔다가 당신이 이미 TV를 훔친 사실을 안 것과 비슷하거든."

[서평] Head First Software Development

최윤호 — Sun, 06 Nov 2011 22:30:00 +0900

Head First Software Development
2011-11-02
댄 필로네 지음, 황상철 옮김, 한빛미디어

Head First는 Design Patterns 보고, 두번째 입니다. Head First Java는 구매만 하고 보질 않았네요. Head First는 설명이 필요 없을 정도로 유명하고, 좋은 시리즈입니다. HFSD도 명성에 걸맞는 내용입니다.

Software Development는 사실 한권에 담기 어려운 큰 주제입니다. 이 책은 Agail 방법론에 기반해 소프트웨어 개발을 어떻게 관리할 것인가에 대한 전체적인 그림과 세세한 사항을 짚어줍니다. 자바때문에 약간 덜그럭 거리는 부분은 있지만, 분량도 그리 많지 않아 가벼운 마음으로 빠르게 읽기 좋습니다.

이렇게 함부로 정리해도 될지 모르겠지만, 내용을 간단히 요약하면 1) 사용자의 요구사항을 수집해서, 2) 사용자 스토리로 정리합니다. 3) 이를 태스크로 만들고 4) "충분히" 좋은 설계를 한 후에 5) 버전 관리, 6) 빌드 관리, 7) 테스트 관리 등의 기법을 사용해 8) 개발을 합니다. 그리고 이 모든 것은 9) 20일, 한달 가량의 이터레이션으로 묶어 계속 반복한다는 내용입니다^^
저는 "커다란 현황판"이 가장 마음에 와 닿네요.

* 이터레이션으로 목표 달성하기
- 이터레이션이 없는 경우 : 문제와 가정이 생길때마다 프로젝트는 점점 목표와 멀어져 고객이 바라는 모습이 아닌 결과물이 나옵니다.
- 이터레이션이 있는 경우 : 문제가 생겨도, 고객의 생각이 바뀌어도, 중간중간에 고객의 피드백을 받아 수정해가면서 진행하기 때문에 고객이 원하는 결과를 만듭니다.

* 각 이터레이션은 작은 프로젝트와 같고, 요구사항 > 설계 > 코드 > 테스트 > 피드백을 계속 반복합니다. 즉 각 이터레이션은 품질 좋은 소프트웨어입니다.

* 고객 요구사항을 알기 위해서는 크게 생각해야 합니다. 개별적으로 브레인스토밍을 한 다음 모여서 다시 좀 더 브레인스토밍을 합니다. 떨어져서 무슨 일이 일어날지 생각해 보고 돌아와서 다 같이 두번째 미팅을 합니다. 혹은 역할극을 하고, 사용자들 관찰하는 방법으로 고객의 요구사항을 알아냅니다.
하늘은 한계가 없기 때문에 요구사항을 받을 때도 블루스카이를 한다고 생각하세요. 그렇게 고객에게 더 많은 정보를 달라고 말합니다.

* 사용자 스토리가 정리되면 계획 포커 게임을 합니다. 개발자들이 각 스토리에 대해 예상되는 일수를 카드로 제시하고, 그렇게 생각한 이유를 설명하면서 서로간의 합의 가능한 추정치를 찾아갑니다.
너무 동떨어진 추정치에서 많은 사람이 놓치고 있는 가정이 나올 수도 있습니다. 또, 모두의 추정치가 비슷해도 서로가 생각하는 바를 이야기합니다. 추정치가 너무 크다면, 스토리를 나눌 수 있는지 확인합니다.
가정에 대해 가정을 하지 마세요. 모든 것을 이야기해야 합니다.

* 스토리에 우선순위를 부여하고, 선행 작업을 확인합니다. 이렇게 스토리에 우선순위와 추정치가 결정되면, 20일 기준으로 팀에서 할 수 있는 만큼의 스토리를 선택해 이터레이션들을 구성합니다. 그리고 첫번째 이터레이션을 진행합니다. 이때 팀의 개발 속도는 0.7로 고려해서 시행착오에 대비합니다.

* 이터레이션으로 계획이 세워지면, "피곤하게 하는" 혹은 "동정의 여지가 없는" 고객을 다루어야 합니다. 이터레이션 계획을 설명하고, 범위를 벗어나는 사용자 스토리는 없어지는 게 아니라 연기하는 것뿐임을 설명합니다. 구체적으로 수치가 어떻게 나왔는지를 설명합니다.

* 벽에 "커다란 현황판"을 만드세요.(이건 정말 해 보고 싶어요!!!)
한쪽에는 처리할 사용자 스토리가, 가운데는 처리 중인 스토리의 태스크가, 다른 한쪽에는 소멸 그래프와, 다음 이터레이션으로 넘어갈 스토리, 그리고 완료된 스토리를 놓은 큰 현황판입니다.
현황판을 직접 적용해서 친절하게 사진까지 올려주신 블로거가 있습니다. 꼭 한번 방문해 보세요.
커다란 현황판 : http://mckdh.net/353

* 일은 스토리에서 태스크를 확정하는 것으로 시작합니다. 태스크는 개발자에게 할당되어 개발이 시작됩니다. 그리고 매일 간단한 미팅을 위해 "스탠드업" 미팅을 진행합니다.
이 모든 작업이 일을 줄여주지는 않습니다. 하지만 우리가 어디에 있는지를 "정확히" 알고 있습니다. 더욱이 고객도 우리가 어디에 있는지 알고 있습니다.

* 충분히 구현 가능한 좋은 설계와 안전한 개발을 위한 버전 관리, 작성한 코드 빌드하기, 그리고 테스트와 지속적인 통합은 가볍게(?) 넘어갑니다.

* 이터레이션에서 위의 방법을 통해 할 수 있는 일은 고객 주도적 기능, 코드 컴파일, 감시되는 빌드, 지속적으로 테스트된 코드, 견고한 테스트 커버리지, 믿을 수 있는 진행상태 추적, 팀에 알맞는 속도로 나아가기 등입니다. 이제는 테스트팀의 테스트와 여기서 발견된 버그를 수정합니다.
버그까지 마무리가되면 이터레이션을 마무리하고, 첫번째 버전을 정식으로 배포합니다. 그리고 이터레이션 마지막날 이터레이션 리뷰를 진행합니다. 이번 이터레이션이 어떻게 진행되어 왔는지를 느낀 점을 서로 전달하는 시간입니다. 진취적인 자세를 취하고, 속도와 범위를 파악해서 지표를 계산합니다. 이제 잠시 휴식을 취하며, 훈련이나 교육을 위한 시간을 갖거나, 다음 이터레이션을 위한 프로토타입을 만들어 보세요.

* 작동하는 소프트웨어는 이터레이션을 마쳐야 하고, 테스트를 다 통과해야 하며, 고객이 만족해야 합니다.
우리가 개발하지 않은 코드, 라이브러리, 혹은 프로그램이 만약 그것이 우리의 소프트웨어에 적용된다면 이제는 우리의 책임입니다. 외부 업체와 다른 사람이 우리의 프로세스를 따르리라고 가정하면 안 됩니다. 적용된 코드, 라이브러리, 프로그램을 우리의 시스템에 넣고, 우리가 코드를 만든 방식 그대로 관리합니다.

* 소프트웨어 개발 프로세스를 명확히 합니다. 좋은 프로세스가 좋은 소프트웨어를 만듭니다.
현황판, 사용자 스토리, 버전 관리, 지속적인 통합, 테스트 주도 개발, 테스트 커버리지를 사용합니다.

[서평] CEO 안철수, 지금 우리에게 필요한 것은

최윤호 — Wed, 02 Nov 2011 13:45:31 +0900

CEO 안철수, 지금 우리에게 필요한 것은
2011-10-12
안철수, 김영사

딱히 요즘 인기가 많아서 읽은 건 아닙니다ㅡㅡ;;
그냥 가볍게 읽히지만, 별 내용은 없네요. 2004년에 출판되어 그동안 많이 이야기되어서 그럴지도 모르겠습니다.

- 어떠한 상황에서도 자발적으로 동기부여를 하고 자신을 관리하면서 역량을 강화하는 것이 바람직한 삶의 태도일 것이다. 자기 자신에 대한 관리는 타인이나 조직을 위해서 하는 것이 아니다. 이는 우선적으로 본인을 위한 것이다. 발전함으로써 가장 큰 혜택을 보는 것도 자기 자신이며, 실력이 부족해서 가장 큰 손해를 보는 것도 자기 자신이기 때문이다.

- 개발자들이 갖추어야 할 자질 : 1) 전문가로서의 지식, 특히 실제 프로젝트에 적용할 수 있는 지식과 경험. 2) 커뮤니케이션 능력. 3) 팀을 이루어서 다른 사람과 같이 일을 잘해나갈 수 있는 성품과 능력. 그리고 '창조적 마인드'와 '장인 정신'

- 그러다가 어느 날 잠자리에 들어 하루를 정리하는데 문득 이러한 생각이 들었다. 내 경쟁 상대들은 세계 각국의 실험실에서 열심히 일하고 있는 비슷한 나이의 사람들이다. 내가 잠을 자고 있는 사이에도 미국에 있는 내 경쟁자들은 열심히 공부하고 있지 않겠는가? 그런 생각이 드는 순간 초조함에 숨이 막힐 지경이었고 잠을 이룰 수가 없었다. 결국 밤중에 일어나서 책을 뒤적이게 되었고, 그 이후로는 잠을 줄여가면서 열심히 공부할 수밖에 없었다. 세계 각국에 흩어져 있는 미래의 경쟁자들을 의식하면서 말이다.

- 자신이 직접 할 수 있는 일을 다른 사람에게 맡겨야 진정한 권한 위임이 될 수 있다.

- 살아가는 데 도움을 주는 여섯 가지 조언 : 1) 자신에게는 엄하고 다른 사람에게는 관대하라. 2) 다른 사람과 비교하면서 살지 말라. 3) 매사에 긍정적으로 생각하면서 살라. 4) 매순간을 열심히 살아라. 5) 미래의 계획을 세워라. 6) 각자 자신에게 맞는 삶의 철학, 즉 원칙을 가져라.

글로벌 소프트웨어를 꿈꾸다.
2011-09-21
김익환. 한빛미디어

단 하나, Trac(혹은 Redmine)과 Subversion으로 이슈와 소스를 관리하면서 개발작업을 하고 싶다. 다들 이슈 작성하는 것을 싫어하는 것 같다. 왜 일까?
"우리에겐 뒤돌아보며 후회할 과거따위는 없다. 오로지 전진만이다" 정신일까?
덕분에(?) 항상 달리고, 달리고, 또 달리는 현실만 있고, 장미빛 미래도 없는 것은 아닐까?

- 일정은 협상 대상이 아니다. 논리적인 근거로 일정이 세워질 때까지 일정을 정하지 말아야 한다. 그전까지 관리자가 잡은 일정은 희망사항일 뿐이라는 것을 기억하자.

- 통상적인 미국회사는 기본적으로 회사가 70%를 제공한다. 그러니까 사람이 아무리 망쳐도 기본적으로 70점은 얻는다. ... 회사의 책임이기도 한 70%에는 기반시스템 설치, 프로세스 정립, 코딩의 표준화, 문서화 방법, 개발방법론, 공유 문화 정립 등의 많은 일이 있다.

- 이런 회사에서는 사람이 없어지면 큰 타격이다. ... 언뜻보면 개발자에게 힘이 있는 상황처럼 들리지만 개발자는 휴가 갈 여유도 없는 무척 고단한 삶을 살 수 밖에 없다. 모든 개발자가 서로의 생명줄을 쥐고 있는 것과 비슷하다. 한 사람이라도 손을 놓으면 추락하는 인간띠로 만든 구조대와 비슷하다. 생명줄을 놓아 버릴 수도 없으니 힘들 수 밖에 없다.

- 소프트웨어 회사가 성공하기 위한 다섯 가지 조건 : 이슈관리시스템와 소스관리시스템, 전문성을 갖춘 인력 조직, 프로세스, 기술, 그리고 참여, 공유, 개방의 문화

- 이슈의 정의는 ... 오류 혹은 버그는 당연하고 '새로운 기능'도 이슈에 포함된다. 또한 작업요청, 사소한 질문이나 의견 같은 것도 이슈에 속한다.
이슈관리시스템은 이슈를 아무나 막 등록하게 하는 느슨함과 포괄성을 전제하게 생긴, 전략적으로 유연함을 허용하는 시스템이다. 이슈를 처음부터 정확하게 등록한다는 것은 매우 어렵고 초기에는 그럴 필요도 없다. 이슈관리시스템은 각자 아는 정보만큼만 입력하고, 진행하면서 저절로 데이터가 추가되고 정리되고, 대화를 통해 모든 정보가 투명하게 기록에 남는 것이 핵심이다.
"이슈 등록으로 이슈에 대한 논의를 시작한다."

- 비록 개발을 위해서 주어진 시간이 1시간에 불과하더라도 SRS(Software Requirements Specification) 작성은 가능하며 또 해야 한다. 시간이 많고 적고와는 관계없는 문제다. 시간이 많으냐, 적으냐 하는 문제는 프로젝트가 근본적으로 시간 안에 가능하냐 가능하지 않느냐의 이슈고, SRS를 작성하느냐 안 하느냐는 효율적으로 개발하느냐 안 하느냐의 문제다. 이 가능성과 효율성의 두 이슈를 혼동해서 시간 안에 불가능한 프로젝트를 SRS를 적으면 해결된다는 얘기로 들으면 안 된다. ... 가능한 시간이 주어졌을 때 가장 효율적으로 개발하게 만드는 것인 SRS를 잘 적는 것부터 시작하는 것이고, 적지 않고한다면 엄청난 위험성을 가지고 행운을 기대하며 시작하는 것이다.
SRS의 핵심은 기능목록을 작성하는 것이 아니다. 제품의 목적을 확실히 이해하고 설계를 할 수 있게 충분한 정보를 주는 것이다. 그 중의 일부분이 기능일 뿐이다. 무엇(what)을 만들까 보다 무엇을 결정하는 원인인 '왜(why)'가 더 중요하다.

- 가끔 소프트웨어의 전문성을 이해하지 못하는 개발자를 본다. 원하는 것이 너무 많다. 개발자 경로에 있으니 코딩도 해야 한다고 하고 실력이 있으니 주니어 개발자의 기술 리더, 팀장이 되어야 한다고 하고, 그러면서 팀의 평가, 인사관리, 일정관리도 해야 한다고 한다. 필요로 하는 기능이 무엇인지 잘 알고 있으니 제품기획도 할 수 있다고 한다. 혼자서 기술전문가, 관리자, PM, 제품 마케팅 등 모든 역할을 다 하고 싶어 한다.

- 영업은 하나의 고객만 있더라도 당장 제품을 판매하길 원하는 단기 전략이 우선이고 개발팀은 선행연구도 해야 하고, 유지보수도 걱정해야 하고, 버전도 최소화해야 하고, 컴포넌트화된 산뜻흔 제품을 만든기도 해야 하므로 중장기 전략이 우선이다. ... 이 다툼을 조율하는 부서는 통상적으로 마케팅 부서다. 마케팅 부서는 제품 기획과 판매 전략 등 비교적 단기 전략과 중장기 전략을 모두 균형 있게 고려한 계획을 짠다.

- 전체 프로젝트를 외주 줄 경우에는 계약을 2단계로 나누어 별도로 진행한다. 분석을 1단계로, 설계와 코딩을 2단계로 나눠어서 발주한다.

- "같이 일할 사람 한 명을 설득할 수 없다면 창업은 시작하지 않는 게 좋습니다. 인생을 바쳐서 같이 일할 사람 두 명을 설득할 수 없다면 희망이 없습니다. 다시 말하건대 누군가 다른 한 사람을 공동 창업자로 구하십시오. 그것이 당신이 성공하기 위해 필요한 최소한의 일입니다." - 온라인 상점의 시초였던 비아웹의 공동창업자인 폴 그래함

- 좋은 소프트웨어를 만들어 내는 길은 이 모든 규칙, 법, 다양한 평가지수보다 "지금 내가 하고 있는 행위가 그대로 신문에 헤드라인으로 나왔을 때 자랑스러울 수 있는가?"를 생각하면서 일을 하는 것이다.

히트상품 어떻게 탄생하는가
2011-09-28
원슬로우 페릴. 푸른솔

도서관에서 책장 사이를 지나가다 책 날개의 저자 약력을 보고 나름 괜찮을 듯 싶어 골랐는데 별로다. 이런 약력을 갖고 이 책을 성공시키지 못 했을 때 눈치를 챘어야 하는건데 아쉽다.

- 사람들이 고립된 채 물건을 구매한다면 그 물건은 히트상품이 되지 않는다. 히트상품의 가능성은 구매자로서 "우리는 누구인가?"의 물음을 "우리는 무엇을 구입하는가?"로 대체할 때 비로서 발현되는 것이다.

- 유명해지기 전에 새로운 그룹을 주목하면서 애호가들은 "예언자적인 자부심"을 느끼고, 친구들로부터 우쭐함을 느낀다.

공의 경계
2011-08-24
나스 기노코. 역자 권남희. 학산문화사

전기소설이라 하던가. 마법과 초능력, 혼과 정신, 기계장치와 인형, 괴수와 요정 등이 마구 등장하는 일본식 환타지 소설로, 주인공은 이중인격을 타고나 닌자처럼 싸움을 잘 하는 여자 아이와 그 애를 좋아하는 정말 순수한 매력의 남자 아이다.
정체성과 기억에 대한 혼란스러움과 일본식 환타지에 익숙하지 않은 점은 있지만, 끝까지 진행하면 내용의 이해에 대한 혼란은 많이 줄어든다. 요약하기 쉽지 않은 내용이거니와, 작가의 구성에 따라 진행하면서 이해되는 부분이 있어 내용은 잘 설명하지 못 하겠지만, 환타지 문학, 혹은 그냥 소설을 좋아한다면 읽을 만하다고 추천한다.

프로그래밍 언어 사용량

최윤호 — Sun, 16 Oct 2011 00:46:00 +0900

저의 메인 언어는 C#입니다. 전공이 이분야가 아니었던 관계로 VBScript(ASP)를 처음 접하고, Java나 C++ 등은 개인적으로 공부해 본 적은 있지만, 이것으로 실제 프로젝트를 해 본적은 없습니다.
그리고 저도 MS의 정책을 따라 .NET으로, 그리고 C#으로 흘러온 겁니다.

Java를 메인으로 하는 분을 만나면 묘한 신경전을 벌일 때가 있습니다.
생각하는 방식이 다르게 느껴집니다. "편한게 편한거지"라는 MS식 개발자 사고방식(저만 그렇게 생각하나요??)이 좀 안 통한다고나 할까요?

TIOBE Software라는 곳에서 매월 발표하는 프로그램 언어 사용량이 있습니다.
구굴, 야휴, 빙, 유투브 등의 유명 검색 엔진의 자료를 이용해 지수를 만든다고 합니다.
뭐 신빙성에 대한 의문은 제쳐두고 흥미로만 봐도 좋습니다.

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

1등은 Java입니다!! 10년 넘게 1등을 유지하고 있는 것 같습니다. 이 글을 작성하는 2011년 10월에 다음달에는 C에게 역전당할지 모르겠다는 우려가 좀 있네요.
2등과 3등은 C와 C++입니다. C++은 그렇다고 해도 C가 아직도 이렇게나 많이 쓰인다는 것은 좀 놀랍네요.
4, 5, 6등은 PHP, C#, 그리고 Objective-C입니다. 역시 PHP도 팔팔하게 살아있네요. 제가 좋아하는 C#도 있고. 최근의 유행을 반영하는 듯 Objective-C도 있습니다. 더욱이 C#과 Objective-C는 증가폭이 상당하네요. 조만간 Objective-C가 4위로 올라가지 않을까 싶습니다.
그외 눈에 띄는 것은 9위 Perl, 아직도 살아 있었군요. 11위 Ruby입니다.

Long term trends를 보면 2004년 중반에 무슨 일이 있었는지 궁금해 지기도 하고...
우야튼 직접 한번 보셔도 좋을 듯 싶습니다. 어디까지나 재미로요^^