Founders at Work (Stories of Startups' Early Days) / 제시카 리빙스턴 / APress L.P / 2007
번역된 제목만으로 환상을 가지면 실망할 수 있는 책.
그러나 미국의 IT벤쳐들이 경험한 초기의 모습들을 볼 수 있어서 좋았다.
결과적으로 성공한(혹은 아직은 역사의 저편으로 떨어지지 않은) 사람들의 과거 이야기인데,
흥미로운 부분들이 꽤 많았다.
물론 한국이 동일한 환경을 가지고 있는건 아니지만,
무언가 일을 시작할때 고려해야 할 것들을 미리 생각하도록 마련해주는 기회가 될듯싶다.
예전만큼 벤쳐 열풍은 없지만, 오히려 그 시기가 더 혹독했을지도 모른다는 생각이 들고,
가능성은 여전히 열려있다는 생각을 해본다.
글에서 눈이간 벤쳐의 인터뷰는 다음과 같다.
블로거닷컴, 파이라랩스
GMAIL
FLICKR
37SIGNALS
HOT OR NOT
TICKLE -> 아쉽게도 몬스터에 인수된 이후 shut down.
Alliant Computer Systems, Sharehlder.com
p51
"당신은 하드웨어 분야 출신인데, 그런 경험이 과부하를 견딜 수 있는 서버를 만드는데 도움이 되었나?"
사비어 바티아 : "... 하드웨어는 한번 잘못되면 큰일이 나는데 칩을 한 번 잘못 만들면 수백만 달러가 날아갈 수도 있기 때문이다.... 이렇게 논리적인 방법으로 개발을 하면 실수가 거의 생기지 안는다. 반면, 소프트웨어 개발자들은 매우 창조적으로 생각하며 개발을 한다. ... "
p195
이반 윌리엄스 : 타협이 좋은 아이디어를 죽인다는 점을 명심하라. ... 사람들의 의견을 존중하지 말라는 얘기가 아니라 가끔은 다른 사람의 의견을 무시할 수 있을 정도로 냉철해야 한다는 뜻이다. 모두들 반대하지만 스스로는 확신하는 것이라면 새롭게 혁신적인 것일 가능성이 있다. 반명 모든 사람들이 동의하는 것이라면 평범할 확률이 높다.
가장 큰 잘못은 다른 사람들이 어떻게 느끼는 지에 관심을 기울이지 않았다는 것이다. 그래서 동료와 문제가 생길 때마다 무척 놀랐다. 알고 보면 오랫동안 쌓여온 문제이고 그리 놀랄 일이 아니었는데도 말이다.
p428
" 어도비라는 이름을 어떻게 짓게 되었나?"
찰스 게슈케 : PARC에 있을 때 프로젝트를 시작하면서 이름이 필요할 때마다 우리는 지도에 화살을 던져 꽂힌 지역의 이름을 사용했다.
p487
필립 그린스펀 : 나는 소프트웨어업계 사람들이 ... 변화사나 의사, 건축가와 같이 진정한 전문가가 되어야 한다고 생각한다. ...
소프트웨어 업계 사람들은 문제에서부터 생각을 시작하는 기술을 배워야 하며, 생각한 결과를 문서로 적는 데 시간을 투자해야 한다. ...
사람들은 글로 적는 것을 좋아하지 않는다. 하지만 훌륭한 소프트웨어 언지니어는 훌륭한 작가다. 자기 생각을 정리하고 대화하는 데 뛰어난 역량이 있다.
p581
제임스 쿠리에 : 하버드 비즈니스스쿨 재학 당시 한 교수님이 창업한 경험이 있는 학생들을 모아놓고 "이 학교에서 회사 창업에 대해 가르쳐주지 않은 것이 있다면 무엇인지 얘기해보라."고했다. 그래서 나는 "고통을 가르쳐주지 않았다." 고 말했다.
학교 다닐 때 한 수업시간에 교수님이 눈물이 글썽거리면서 걸어나오는 것을 본 적이 있었는데, 친구분이 케이블회사를 창업했다가 자신과 가족의 인생을 망쳐버린 비참한 모습을 보고 슬퍼한 것이었다.
그것이 내가 하버드 비즈니스스쿨에서 회사 창업의 고통에 대해서 배운 유일한 경우였다.
p596
"파이어폭스에서 배운 것 중 지금 회사에 적용하고 있는 게 있나?"
블레이크 로스 : 제품을 실제로 사용할 사람들과 계속 소통하는 게 중요하다는 것을 배웠다.
프로그래머는 사무실에서 틀어박혀 사람들이 뭘 원하는지도 모르고 하루종일 코딩만 하는 실수를 범하기 쉽다. 하지만 끊임없이 사람들과 얘기하고 계속 제품에 반영해야 한다.
p612
미나 트로트 : ... "회사를 시작하고 일본에 공짜로 여행 온 것외에는 아무것도 손에 쥐지 못하더라도 후회는 없다" 라고 말했다. 그 전에는 다른 사람 돈으로 여행을 한다는 건 생각하지도 못했다. 그제서야 비로소 우리에게 좋은 기회가 많이 있었고 다양한 것을 배웠다는 생각이 들었다. "내일 회사가 없어지더라도 많은 것을 배웠으니 괜찮다." 라고 생각했다.
이 글은 스프링노트에서 작성되었습니다.
http://sourceforge.net/projects/coqua/
Coqua measures 5 distinct Java code quality metrics, providing an overview and history for the management, and down-to-the-code, detailed views for the developer. Metrics can be defined per team. Ideal for mid- to large-sized and/or offshore projects.
License : GPL
version : 1.0.1
기능1 : dashboard (CC, NCSS, Checkstyle, CPD, Cycling )
기능2 : dashboard history ( per week)
기능3 : 컴포넌트 정보 ( pkg, class, method, ncss 수, 소스목록)
기능4 : 상세 보고서 (over long class list ? )
requirement : java1.4 over, ant 1.6 over, checkstyle conf file (4.x), svg-support browser (FF or IE with SVG-plugin)
이 글은 스프링노트에서 작성되었습니다.
최근 관련 업무에서 Jira issue로 올라온 내용
"db file 삭제가 안됨"
sqlite를 사용하고 있고 ORM으로는 ibatis를 쓰고 있는 환경.
Eclipse plugin인데 일단 한번 ibatis가 호출되고 나서는
db file을 삭제할수 없는 상태인 것이다.
호출한 서비스를 해제하고, 강제로 system gc를 호출하고 별 짓을 해봤는데도
db file은 삭제되지 않았다.
sqlite의 문제인지, ibatis의 버그인지 이것저것 찾아보았는데,
실마리를 찾지 못했다.
포기하고 해결하는 대신 삭제를 못하게 하는 방향으로 가려다가
마침내 관련 글을 발견.
원인은.... ibatis의 기본기능으로 일단 맺어졌던 connection에 대해서 Pool에 담아 보관하기 때문이었다.
해결책으로 ibatis 설정시 connectionPool의 idle 갯수를 지정할수 있었는데, 0으로 셋팅하면 된다.
sql-map-config.xml
<transactionManager type="JDBC">
<dataSource type="SIMPLE">
...
<property name="Pool.MaximumIdleConnections" value="0" />
</dataSource>
</transactionManager>
물론 이경우 발생하는 이슈는 당연히 작업할때마다 connection을 맺어야 하니까(놀고있는 커넥션이 없으므로) 커넥션
타임비용이 추가로 발생한는 점이다.
하지만 프로그램의 성격이 성능목표는 다소 낮은 편이라서 스킵...
이 글은 스프링노트에서 작성되었습니다.
from Forbes Korea 2009.2
운칠기삼의 유래는 중국 청나라 문인 포송령의 요재지이 에 수록된 소설이라 전해진다.
어떤 선비가 변변치 않아 보이는 다른 사람은 버젓이 과거에 급제하는데 자신만 낙방을 거듭해 패가망신에 이르자 옥황상제를 찾아가 연유를 따졌다.
옥황상제는 정의의신과 운명의 신에게 술 내기를 시키고, 만약 정의의 신이 술을 많이 마시면 선비가 옳은 것이고, 운명의 신이 많이 마시면 세상사가 그런 것이니 선비가 체념해야 한다는 다짐을 받았다.
내기 결과 정의의 신은 세 잔 밖에 마시지 못하고 운명의 신은 일곱 잔이나 마셨다.
옥황상제는 그러나 선비에게 세상 일의 7할은 운명이 지배하지만, 나머지 3할은 정의와 합리가 지배하니 운명 탓만 하지 말라고 일깨워 줬다.
요컨데 모든 일이 행불행에 따라서 결판 나는게 아니므로 운수에만 기대지 말고 스스로 노력을 다하라는 교훈을 담고 있는 것이다.
운칠기삼의 진짜 의미 - 이동규의 감성경영 p151
이 글은 스프링노트에서 작성되었습니다.