역사 한 잔 하실까요?/톰 스탠디지/세종서적/2006 - 2008/06/19 - 2008/06/24
역사속의 음료라고나 할까?
생각해보면 요즘 와인에 대한 열풍은 실제로 건강상의 효과를 모르다 알아서 생긴 것이라기 보다는, 미국의 흔한 문화에 익숙해져서 좀더 고상한(?) 문화를 섭취하고픈 열망에서 비롯된게 아닐까 싶다.
어쨌거나.. 코카 콜라가 "코카인 + 콜라원액" 이었다는 사실..
그리고 결국은 알콜이냐 카페인이냐 하는 두가지 소재에서
이리저리 치고 받고 있다는 사실을 깨닫는다.
이 글은 스프링노트에서 작성되었습니다.
이외수 소망상자 바보바보/이외수/해냄/2008 - 2008/06/26
물론 정채봉 스타일을 더 좋아하긴 하지만..
하나님 미워
옆집 꼬맹이가 하늘을 쳐다보면서 발악적인 목소리로 화이팅을 연발하다 이마에 빗방울이 떨어지자 그만 울음을 터뜨리고 맙니다.
유치원 소풍 가는 날.
자연스럽게 연상되어 미소짓게 한ㄷㅏ.
책도 강물처럼 바다처럼 깊이를 가지고 있습니다.
그리고 어떤 책이든지 그 깊이는 놀랍게도 읽는 자의 깊이와 정비례합니다.
이 글은 스프링노트에서 작성되었습니다.
피에트라 강가에서 나는 울었네 (Na Margem do Rio Piedra eu Sentei e Chorei )
By the River Piedra I Sat Down and Wept
주역에서 말하길, 도시는 바꿀 수 있어도 샘이 있던 자리는 바꿀 수 없대요.
그래서 사랑하는 사람들이 서로를 발견하는 곳은 바로 샘 근처죠.
사람들은 그곳에서 갈증을 씻어내고 집을 짓고 아이들을 기르지요.
하지만 그들 중 한 사람이 떠나길 원한다해도, 샘을 옮겨갈 수는 없어요.
그러니 사랑은 그 자리에 남게 되죠. 버려진 채로 말이죠.
샘에는 여전히 맑은 물이 가득 차 있겠지만요.
샘을 파기시작하면, 모든 것이 달라진다.
무슨 내용인지 이해하지 못한 사랑이야기.
나이탓인지 머리가 나쁜 탓인지, 감수성이 떨어진 탓인지. 별 감흥이..
재미있는건 책을 반납한 다음 블로깅을 하다가 책 속에 나왔던 이야기와 관련하여 한 글을 읽게 되었다.
gimmesilver 님의 블로그에 있는 백번째 원숭이, 그 이면에 감춰진 진실... 이라는 글이다.
물론 원숭이 이야기는 만들어낸 것이겠지만,
적어도 백마리 원숭이들의 세상은 바뀌었고, 또 새로운 변화를 만들어낼 것이라는 생각은 여전하다.
이 글은 스프링노트에서 작성되었습니다.
http://video.google.com/videoplay?docid=-8246463980976635143&q=genre%3Aeducational
CMU의 교수인 Luis von Ahn이 2006년 발표한 내용입니다.
강연의 요지는 컴퓨터가 하기 어려운 문제를 사람들을 이용해 풀어내도록 만든다는 것.
농담으로 말하자면 영화 Matrix를 구현하고 있다고나 할까요..
다음은 동영상에서 소개한 CAPCHA의 예입니다.
대량의 가상 계정으로부터 뿌려지는 스팸메일을 막기위해 야후,MSN,구글 등 메일제공 업체들은
사용자 등록절차에 캡차(CAPTCHA)를 도입하게 되었습니다.
(캡차는 이미지상에 보여지는 문자를 고의로 일그러뜨려서 컴퓨터로는 판단할 수 없도록 하는 기술입니다. )
스팸 업체들은 이에 대응하여 full time으로 사람들을 고용하여 캡차를 입력하도록 시켰는데 (캡차가 고용창출을..),
좀더 지능적인 포르노 사이트에서는 포르노 사진을 보고싶어하는 사람들에게
캡차화면을 띄워 다음 사진을 보려면 캡차의 문자를 입력하도록 시켜서 모르는 사이에 스팸계정을 만들도록 시켰습니다.
이러한 아이디어를 확장하여 동영상에서는 인간의 계산을 활용하여 다양한 분야에 활용하려는 실험을 소개합니다.
뭔가 지적인 에너지를 소모하지만 Fun하게 할수 있다는건 좋군요.
단지 Matrix가 날 너무 괴롭히지만 않는다면요 ^^
http://endthink.tistory.com/37
이 글은 스프링노트에서 작성되었습니다.
79년 이탈리아 베수비오 화산이 폭발했어. 아름다운 도시 폼페이가 온통 잿더미에 파묻혔지. 정말 끔찍한 사건 아니야? 이 일로 이익을 본 사람은 도대체 누굴까?
돌이켜보면 폼페이는 고고학자들이 받은 가장 아름다운 선물이었을 거야. 그러면 이걸 누가 꾸민 짓이라고 생각할 수는 없을까?
아직 폼페이를 구경해보지 못한 내가 "아름다운 도시" 였는지 의문을 가지는 것은 어쩔수 없다.
하지만 농담 한마디로 시작해서 유쾌하게 농담을 마무리 짓는
작가의 재치는 늘 맘에 든다.
항상 시작이 너무 진지해야할 필요는 없다.
이 책은 실로 꿰매어 제본하는 정통적인 사철 방식으로 만들어졌습니다.
사철 방식으로 제본된 양장본은 오랫동안 보관해도 책이 손상되지 않습니다.
출판사의 자상한(?) 글귀.
책의 내용이 미래의 고전학자가 과거의 아름다움을 보전하기 위해 과거의 도시에 화산폭발을 일으켰다는 건데,
뭔가 비슷한 느낌이 들어서 재미있다.
이를테면,
미래의 고전학자 또는 도서관 사서가 손상되어있는 아멜리 노통의 책에 가슴이 찢어질듯 아팠고,
2003년대의 어느 출판사 사장의 지적 허영심에 세심하게 고려된 약간의 전기적, 화학적 자극을 주입하여
마침내 위와 같은 문구를 삽입하도록 만들었다는 상상.
설마 내가 미래로 잡혀갈 일은 없겠지? :)
이 글은 스프링노트에서 작성되었습니다.
Beautiful Code / 38인의 코딩 명장들이 말하는 내 생아 가장 아름다운 코드
찰스 페졸드 외 / 류광 역 / 한빛미디어
CH03. 내가 결코 쓴 적이 없는 가장 아름다운 코드 / 존 벤틀리
"가능하다면 항상 코드를 훔쳐라"
- 기성의 코드를 잘 활용하고 그 코드들로부터 배우라는 의미인듯.
CH06. FIT : 취약함에서 비롯된 아름다움 / 마이클 페더스
"그러나 이들이 단지 어림법칙일 뿐임을 잊는 것은 우리 스스로를 억압하는 일이다.
그러한 점을 망각하게 되면 우리는 "모든 것을 제대로" 해냈지만 여전히 목표를 만족하지 못하는 설계를 만들어 낼지도 모른다."
- 원칙에 맹신하기보다 목표에 집중할것. 열린 프레임워크.
CH07. 아름다운 검사 / 알베르토 사보이아
"좀 더 우아하고, 유지보수하기 쉽고, 검사가 가능한 코드의 작성 방법을 제시하는 검사들"
- 그래서 TDD가 빛을 발하는 게 아닐까 싶다.
CH20. NASA의 화상탐사로버임무를 위한 고신뢰성 전사적 시스템/ 로널드 맥
아키텍쳐 상의 핵심적인 설계 원리들
표준기반
느슨한 결합
언어독립
모듈성
규모가변성
신뢰성
- 미션 크리티컬한 상황에서 필요한 S/W 개발상의 가치들. 특히 표준,느슨함 의 중요성이 눈에 띤다.
CH29. 에세이 같은 코드 / 유키히로 마쓰모토
"에세이와 코드 모두, 무엇보다도 인간이 읽고 이해하는 것을 의도로 해서 작성한 것"
- 간결함, 익숙함, 단순함, 유연함이 구현된 루비에 대한 홍보...
CH30. 버튼 하나로 세상과 소통하기
"스티븐 호킹 교수는 버튼 하나만 누를 수 있습니다." 이것이 우리에게 주어진 한 줄짜리 명세서였다.
- 사용자에 최적화되는 인터페이스, S/W 구현하기.
호킹 교수를 위해 단종된 Equalizer 를 대체할 새로운 S/W를 구현하는 과정을 보여준다.
명세가 완벽할 경우는 늘 드문 현상이기 때문에, 사용자로부터 관찰하고, 피드백을 받을수 있는 창구를 열어놓는 것이 도움이 됨을 알수 있다.
CH32. 살아 움직이는 코드 / 로라 윈저드, 크리스토퍼 세이월드
"Seven Pillars of Pretty Code"
"책처럼" 만들라
비슷한 것은 비슷하게 만들라
들여 쓰기를 극복하라
블록들을 이용해서 뒤엉킨 코드를 풀어라
코드 블록에 주석을 달아라
군더더기를 없애라
기존 스타일과 조화를 이루라
"살아 움직이는 코드의 성공은 코드를 읽는 사람이 그것을 얼마나 잘 이해할 수 있느냐에 달려 있다"
- 일곱개의 기둥이 잘못 쓰이면 오히려 이해를 어렵게 만든다는 걸 기억해둘것.
결론적으로. 좋은 코드는 어떻다는걸 외우기 전에,
우선 좋은 코드를 보고 배워야 하고, 그리고 코드를 작성하면서 경험을 통해 습관처럼 만들어나가야 하는게 중요하다.
이 글은 스프링노트에서 작성되었습니다.
CI에 대해서 기억해보자면,
2004년쯤의 프로젝트에서 시작된다.
비교적 대규모의 프로젝트로 6-7개 업무가 각각의 빌드를 수행하고,
이를 통합하여 하나의 시스템이 돌아기는 형태였는데,
이때 구현 된것은 형상관리도구로부터 소스를 받아서 빌드 스크립트를 돌리고 배포 가능한 형태로 떨구는 작업까지였다.
(소스를 받아오고 컴파일 하는데 걸리는 시간은 미미했지만 정작 컨테이너를 내리고 올리는데 걸리는 시간이 거의 전부를 차지했다.)
그러나 한줄 엔터로 구현해 놓은 이 스크립트를 빌드담당자가 돌리고, 결과 확인하고, 조치하는데 자주 밤을 새고 있었다.
물론 개발자들이 작업을 하지 않는 시간대에 일을 해야 하다보니 애로사항도 있었고,
빌드가 실패한 경우에 당사자가 아니니 대응도 못하고 시간만 허비하는 경우도 많았다.
그리고 몇년이 지나서 CI 서버 도구에 대해서 알게 되었고,
지속적으로 관심을 가지면서 여기까지 오게되었다.
CI가 무엇을 목표로 하는지, 왜 필요한지 이해는 하고 있지만
현재까지 남아있는 현장(?)의 한계를 생각해보면
- 단위테스트 작성에 대한 부담감이 크다.
테스트 작성에 대한 점진적인 지침이 제시되어야 하는데, 통상 코칭 역할을 해야할 위치에 사람이 적절하지 못한 경우가 많다.
( 일이 2배가 된다고 생각하는 경우가 많다. ) - 시스템 및 기능테스트에 어려움을 느낀다.
소요시간이 지나치게 소모되는 경우도 있고,
이종의 복잡한 환경이 결합되면서 테스트 자동화에 대한 실마리를 찾지 못하는 경우가 있다.
예를 들어 X-Internet 기술을 사용하는 제품의 경우 웹 시뮬레이션 도구로는 한계가 있다. - 품질검사 도구에 대한 표준 정책 부재
유용하게 제공되는 품질검사 도구들이 있지만 무작위적으로 도입하기에는 다소 버거울 경우가 많다.
예를 들어 CCN이 얼마인 경우를 문제로 볼것인가,
또는 Code Inspection Rule을 어떻게 가져갈것인가 등에 대한 판단을 수행해줄 주체가 없는 경우가 잦다. - 지속적인 DB 통합의 어려움
DB를 일반 소스와 같이 형상관리 대상으로 고려하지 못하는 환경적인 측면도 있고,
DB 내의 방대한 샘플 데이터를 재구축하는데 따르는 부담,
DB를 이용하는 프로그램 간의 의존관계가 지나치게 묶여있는 경우가 많다.
CI라는 개념이 좀더 Agile한 개발과 가치, 그리고 삶의 질을 높여주는데 도움이 될것이라는 점에서
보다 많은 사람들이 혜택을 누릴수 있으면 좋겠다.
지속적인 통합 - 소프트웨어 품질을 높이고 위험을 줄이기
위키북스
Continuous Integration:Improving Software Quality and Reducing Risk
Paul M. Duvall, Stephen M. Matyas III, Andrew Glover / 최재훈 역 2008
- CI란?
팀 구성원들이 자신이 한 일을 자주 통합하는 SW개발 실천방법.
- CI의 특징
버전관리저장소로 연결
빌드 스크립트
피드백 메커니즘
통합 프로세스
- CI가 제공하는 가치
위험을 줄여준다
결함을 조기에 발견하고 수정할수 있다.
SW건강성을 측정할수 있다.
반복적인 수작업을 줄여준다
보다 가치있는 일을 할수 있게 해준다.
언제 어느때라도 배포 가능한 SW를 생성한다
배포가능한 SW는 고객의 눈에 보이는 / 손에 잡히는 자산이다.
프로젝트 가시성을 높여준다
효과적인 의사결정을 돕는다.
전체적인 품질의 추이를 인지할수 있도록 돕는다.
개발팀이 SW 제품에 대해 자신감을 갖게 해준다.
변경한 코드가 미칠 영향력에 대한 우려가 줄고 더 자신있게 변경할 수 있다.
- CI가 해결할수 있는 위험요소는 어떤 것들인가
배포가능한 SW의 부재
"내 컴퓨터에서는 되는데요"
"버튼을 안눌렀어요"
뒤늦은 결함발견
"회귀테스트"
프로젝트 가시성의 부재
"제가 남긴 메모 보셨나요?"
저품질의 SW
코딩표준준수
- 왜 도입하지 않는가
CI 시스템의 유지보수 부하
수작업 시간과 비교하라
변경할게 많다
점진적 도입
빌드 실패가 잦다
개인 빌드를 수행하라
추가적인 장비/SW 비용
CI가 없을때의 비용과 비교하라
- 언제 도입할까?
초기가 Best
후반이라면 작은것부터 점진적으로
- 효과적인 CI를 위한 실천지침
코드를 자주 커밋하세요
조금씩 자주 바꾸세요
깨진코드를 커밋해선 안됩니다
개인빌드를 돌리세요
빌드가 깨지면 즉시 고치세요
프로젝트를 위해 최우선으로 할 일입니다.
자동화된 개발자 테스트를 작성하세요
테스트와 검사는 모두 통과해야 합니다
품질을 높여줍니다.
개인 빌드를 돌리세요
깨진 코드는 가져오지 마세요
- 빌드시간이 오래걸린다 -> 빌드메트릭 진단이 필요함
전용 통합빌드장비 사용하기
장비의 사양을 높이기
테스트 성능을 개선하기
빌드구조를 최적화 / 분산하기
- 지속적인 DB 통합
로컬 DB Sandbox 사용
DB자산을 버전관리하여 공유할것
빌드자동화
DB수정권한을 개발자에게
DBA를 팀의 일원으로 만들기 -> 성능향상, 정규화, 가치부가적인 개선업무에 할당.
- 테스트 자동화
단위 테스트
SW내 작은 요소(클래스)의 행동 검증. DB와 같은 외부의존성에 기대지 않음.
컴포넌트 테스트(하위 테스트)
시스템의 일부를 검증. 외부 의존성을 포함.
시스템 테스트
웹페이지, 웹서비스 종점, GUI가 처음부터 끝까지 설계된 대로 작동하는지를 검증
ex) JWebUnit
기능테스트( 인수테스트)
애플리케이션의 기능성을 클라이언트의 관점에서 테스트
ex) selenium
- 지속적인 검사
코드 복잡도 : Cyclomatic Complexity Number
10보다 큰 CCN을 가진 메소드는 상대적으로 결함발생 위험이 높음.
- 지속적인 배포
label 붙이기
clean 환경 만들기
빌드후 label 추가
TEST 수행
빌드 피드백 보고 / 또는 롤백
- 지속적인 피드백
적절한
사람
정보과부하 주의.
정보
시기
방법
적절한 의사소통 메커니즘을 고르고, 어떻게, 누구에게 정보를 보낼지 선택하는 것
ex) 브라우저, 모니터, 소리, 이메일, 메신저
- CI의 미래
빌드가 빨리 이루어지고, 깨지지 않았으면 좋겠다.
"개발자는 단지 버전관리 시스템에 수정한 코드를 커밋하기만 하면 된다."
저장소에 등록되기 전에 미리 통합빌드를 수행하고 성공한 경우에만 커밋처리...
이 글은 스프링노트에서 작성되었습니다.
체스의 챔피언이자 태극권의 챔피언이었던 조시 웨이츠킨이 배움에 대해서 이야기 했다.
추천사를 보면 "스포츠심리학"과 관련이 깊음을 알 수 있는데,
이 책이 단지 배움이 아니라 경쟁관계 속에서 생존하기 위한 나름의 자기관리법을 포함하기 때문으로 보인다.
주된 깨달음을 정리하자면..
- 실패에서 배워라. & 실패에 투자하라
항상 성공할수는 없기 때문에 언젠가는 실패와 직면하게 된다.
그때 실패에 대한 자책감에 머물러 있지 말고, 왜 실패했는지, 다음에 실패하지 않으려면 어떻게 해야 하는지
생각하는데 시간을 투자하는 것이 더 가치있다. - 발달이론
잘해요 보다는 열심히 했어요
성공을 노력과 연관시키고 빠른 결과보다 장기적인 학습과정에 신경을 쓸것 - 기본기에 정통하라.
"배움의 원리는 큰 부분을 이해하기 위해서 작은 부분의 미세한 신비로움 속으로 빠져드는 것이다." - 회복훈련으로 집중력을 길러라
짧은 순간 정신을 집중하는 법, 집중력을 오랫동안 유지하는 법.
휴식을 잘 활용하라.
"LGE의 잭 그로펠은 긴 체스경기 내내 방심하지 않고 체력을 유지하기 위해 45분마다 아몬드 5알을 먹으라고 했다." - "하지만 대부분의 사람들은 다시 한번 '신이 주신 통찰력'을 얻기를 기대하면서 더이상 노력하지 않는다."
음. 문득, 인생에는 배움만 있는게 아니라, 부모나 가족관의 관계형성도 있고.. 사랑도 있고
의외로 섬세한 기술이 필요함에도 가르쳐 주지 않는 여러가지가 있다는 생각이 든다.
그리고 이왕이면 배움의 목표가 우승이나 트로피 보다는, 조시가 처음 체스에 빠져들때 처럼, "즐거움" 이어야 한다고 믿고 싶다.
이 글은 스프링노트에서 작성되었습니다.