우승이의 블로그

성주아이앤티엘 이라는 곳에서 탱고미니라고 하는 미니PC을 출시했군요. 그런데 그 모양이 맥미니 그대로이군요. 위의 그림은 맥미니이구요. 아래는 탱고미니입니다. 얼핏보면 구별하기도 쉽지 않지요? 현재 맥미니 케이스에 인텔CPU가 얹어서 출시가 되면 더욱 구별이 쉽지 않겠네요. 가격이 좀 싸면 탱고미니도 나쁘지 않은 선택일 수도 있을 것 같은데, 같은 가격대라면 저는 아직 맥미니에 점수를 더 주고 싶네요. 솔직히 둘다 갖고 싶은 걸요. 키보드/마우스/모니터 2포트 셀렉터를 사서 두대를 연결해 쓰면 재밌을 것 같아요.



[맥미니]



[탱고미니]

Release Candidate 가 나온지 얼마안되었는데 그새 1.0이 릴리즈가 되었군요. 업데이트해서 3주전쯤에 스터디하면서 간단히 구현해본 프로그램을 돌려보니, 한글이 깨지는 군요. 인코딩문제이겠지요. 또 멀 손대놓은 것인지. 웹에서 한글 인코딩은 정말 머리가 아프군요. 개발환경이 설치된 오에스에서부터 실제 운영될 오에스나 환경에 따라서 거기다가 DB의 인코딩까지 신경쓸려면 늘 헷갈립니다. (머리가 나쁜탓인지도.) 여하튼 속도도 빨라지고, 좀더 안정성이 좋아졌을 거라고 생각이드네요.제가 비주류인 Rails에 관심을 가지고 있는 것은 지금 대부분의 웹어플리케이션 프레임워크들이 너무 복잡해서입니다. 닷넷보다도 J2EE가 너무 복잡해지고 있다는 느낌입니다. 최근에 다시 여러가지 대안이 나오고 있다는데 관심을 가지고 있지 않아서 자세한 내용을 모르겠습니다. (음,이것도 시간을 내어서 살펴보아야 겠군요.) LAMP도 그런면에서 대안이 되는 것이구요. 좀더 냉정하게 기술을 봐야 할 시기인 것 같습니다. 다른 얘기입니다만 자바와 닷넷 그리고 기타 비주류 환경이나 프로그래밍언어등을 생각해볼때 우리나라의 경우엔 너무나도 한두가지 플랫폼과 프로그래밍 언어에 치중하는 경향이 더욱 크기에 경계를 해야한다고 봅니다. 어떠한 것을 선택하든 균형 감각을 가지고 전체를 이해하고 적절한 것을 선택할 수 있어야 할텐데 말입니다. 현실적으로는 사실 매우 어렵지요. "언어가 뭐가 중요해 다 익숙해지면 마찬가지고 필요할 때 적절한 것을 선택하면 되지" 라고 말하는 천재 프로그머들의 말에 평범한 저로써는 쉽게 동의하기 힘들죠. (물론 그러기 위해서 노력하는 것은 다른 문제입니다만) 특히 다양한 기술과 성격과 능력을 가진 구성원으로 이루어진 조직에서는 말이죠. 얘기가 완전히 다른데로 샜군요. ^^

http://www.rubyonrails.org

• 프로젝트의 위험을 관리하는 것으로 프로젝트를 관리한다.


• 각 프로젝트의 위험을 조사하고 관리한다.


• 궁극적으로 바람직하지 않은 결과를 추적하는 것이 아니라 원인이 되는 위험을 추적한다.


• 각 위험에 대한 발생 확률과 예상되는 소요 비용을 평가한다.


• 각 위험에 대해 위험이 구체화되는 것을 나타내는 초기 증상을 예상한다.


• 무엇이든지 '할 수 있다"는 자세를 갖고 일하지 않아도 되는 사람을 위험 담당자로 임명한다.


• 나쁜 소식이 조직의 계층구조 상위로 전달되는 데 용이한(필요하다면 익명으로) 채널을 수립한다.

올해 제가 추진했던 프로젝트의 위험관리는 제대로 했는지 곰곰히 생각해 보았습니다. 한가지 분명한 것은 올해 3월쯤 제 나름대로 위험항목을 정리해보았었습니다. 기억나는 대부분의 위험들은 기술적인 것이 아니었습니다. 그리고 대부분의 위험에 대한 원인은 제가 해결할 수 없는 것들이었습니다. 그래도 그러한 위험에 대해서 인지할려고 노력은 한 것 같네요. 종종 제자신이 이 과제의 위험요인이 아닐까 하는 생각도 한적이 있습니다. 다른 사람들이 나를 과제의 위험요인이라고 인지하고 관리하고 있었을 수도 있지요. -.-; 자신이 위험요인이기 때문에 스스로 물러나거나 조치를 취할 수 있는 용기가 있는 사람은 몇이나 될까요? 아마도 대부분은 남의 탓을 하겠죠. 저 자신도 마찬가지라고 생각이듭니다만. 아무튼 자신이 해결하기 힘든 위험을 가장 잘 해결하거나 회피할 수 있는 방법은 위에 명시된 방법 중 가장 마지막 것이 아닌가 싶습니다. 결국 소통이 얼마나 잘되는가, 상하간의 공감대가 얼마나 잘 되느냐가 팀과 프로젝트를 살아있게하고 긴장하게 하는 것이라고 믿습니다. 올해는 그런 경험의 일부를 한 것 같기도 합니다. 더 많은 위험을 안고 앞으로도 프로젝트를 끌고 나아가야 하겠지요.


톰 디마르코의 데드라인 중에서

아우디의 기술팀 지원을 받아서 설치했다고 하는데 사용하기 매우 쉬운 프론트로우라면 운전중에도 별 어려움 없이 조작이 가능하다는 생각이 듭니다. 차도 차지만 저런 취미를 가진 사람들은 누굴까요. 부러비.

아 오늘 너무 힘듭니다. @@...

그나마 교육중이라 좀 쉴 수 있네요.

아웅 졸려~

Konfabulator가 Yahoo! Widget Engine 3.0이라는 이름으로 새로 발표되었습니다. CPU파워와 메모리가 풍부하신 분들은 반드시 설치하셔서 CPU와 메모리를 맘껏 사용하시길 바랍니다. 맥오스10 타이거에는 이미 대쉬보드라는 이름으로 같은 위젯엔진이 들어있는데 새로운 맥버전과 기존의 버전과 큰 차이점이 무엇일지 잘 모르겠습니다. 가끔 폭주하는 버그들은 잡혔을런지.. 아 그러고보니 큰 차이점은 설치할 때 Yahoo 사이트를 디폴트로 할거냐는 등등의 선택옵션이 늘었군요. -.-;; 이젠 야후꺼니까요. 그리고 기존의 위젯들은 인증 안 받은 건데 실행할거냐고 귀찮게 물어보는 군요. 그리고 한가지 더, 한글화가 되어서 메뉴들이 모두 한글메뉴로 되어 있습니다.
http://widgets.yahoo.com 또는 http://www.konfabulator.com

오늘 마이크로소프트웨어 12월호를 보니 "소프트웨어 개발 프로젝트 실용주의 선언" 이라는 특집으로 기사가 실렸더군요. 보고 느낀 것은 "이것마져도 시류인가? 라는 생각이 들더군요. 개인적으로 인터넷이나 잡지를 보면서 앞으로 이러한 것들이 다가올 것이다 생각을 하면 대충 그러한 흐름들이 오는 것을 알 수 있었는데(너무 건방진가?) 데 "실용주의" 역시 이러한 흐름중 하나였나봅니다. 95년즈음부터 객체지향, UML, 디자인패턴, 아키텍쳐, 프레임워크, 자바, 닷넷 등등 이러한 것들이 S/W시장에 넘쳐나면서 일종의 피로현상의 결과로 "기본으로 돌아가자" 고 하는 무슨 운동처럼 비쳐지기도 합니다. 그 내용들을 자세히 보면 너무나도 당연한 얘기들이 새로운 기조처럼 등장하는 것에 웃음이 나오는 것은 왜일까요? 어쩌면 2000년은 IT시장의 거품뿐만 아니라 각종 방법론, 도구, 프레임워크등의 거품이 꽉찬 시절이 아닌가 싶기도 하구요. 저역시 그러한 시류에 휩쓸려 각종 증후군에 시달렸음을 인정합니다. 객체지향 증후군, 패턴 증후군, UML 증후군, 리눅스 증후군 등등 말이죠. 물론 그 덕에 면역이 생기긴 했지만요. 어쩌면 각종 시류에 편승한 IT 시장의 행태도 문제겠지요. 자바 몇년, 닷넷 몇년이라는 경력과 이번 프로젝트는 자바기반이라는 둥, 닷넷 기반이라는 둥. 한편에선 씁쓸한 생각이 드네요. 전체를 보고 이해할 수 있는 진정한 고수들은 여전히 눈에 띄지 않구요. 저 역시 그러한 고수가 되길 꿈꾸었지만 이제는 아님을 압니다.

제가 원래 "직관적"이라는 말을 좋아해서인지 우연히 책을 읽다가 발견한 문장인데 맘에 드네요.




Source : The Ruby Way by Hal Fulton

광고하는 것 같지만, 집안에 이리저리 굴러다니는 저용량 하드디스크를 조금 편하게 사용할 수 있는 어뎁터가 있네요. 외장형 전원어뎁터가 좀 불편하지만, 2.5인치 HDD 인 경우에는 이것도 필요없을 것 같구요. 저두 서랍에 10G, 20G, 40G 이렇게 3개의 하드가 굴러다니고 있군요. 하나는 가족사진만 모아놓았는데 하나 살까나...

여기를 눌러보세요.

Fowler가 쓴 리팩토링이라는 책이 있습니다. 프로그래밍을 하면서 생각해볼 수 있는 여러가지 개선사항(특히 객체지향언어에서)들을 하나하나 이름을 붙여가면서 가이드를 해놓은 실용적인 책중에 하나라고 봅니다. 객체지향 프로그래밍을 하는 분들은 꼭 봐야 하는 책이라고 생각이듭니다만 최근 개발툴들을 보니 이러한 리팩토링을 자동/반자동으로 해주는 기능들이 하나같이 들어가 있더군요. Visual Studio 2005, Borland Developer Studio 2006, 자바의 이클립스에도 있는지 모르겠지만 어떤 자바 개발도구에 있는 것을 꽤 오래전에 본 기억이 납니다.(이 기능때문에 무슨 상도 탄 것 같은데 기억이 안나네요.) 아마도 앞의 두 제품도 이러한 경향을 따른 것이 아닐까 싶습니다. 사실 제가 이책을 2000년도 쯤인가에 볼때 생각난 것은 이랬습니다. "머 이래 당연히 이렇게 고쳐야 하는 것들 조차도 하나하나 이름을 붙이다니 정말 우리나라 사람들과 그 접근방법이 정말 다르군. 개발을 하면서 자신의 코드을 붙잡고 씨름하는 사람들이라면 당연히 해나가야 하는 것들을 일일히 이름을 붙여가면서 그 기법을 정의해 놓았다니 대단하군" 어쩌면 이런 생각은 제법 C++을 일찍 접한 저로써는 생각할 수 있었겠지만 최근에 C++, C#, Java을 접하는 사람들에게는 정말 날로 먹을 수 있는 산지식이라고 생각이 들더군요. 어떤 것은 기계적으로 해도 도움이 되는 부분들이 있고 어떤 것들은 어설프게 적용해서 별로 좋지 않을 수도 있지만 그것은 프로그래머들의 몫이라고 생각이 듭니다. 툴에도 이러한 기법들이 자동화해서 들어갔다는 것은 - 물론 모든 리팩토링기법이 들어가 있는 것이 아닙니다. 대표적이고 쉽게 자동화할 수 있는 것들만 적용되어 있는 것으로 압니다 - 그만큼 이러한 리팩토링에 대한 것들이 객체지향 개발을 할 때 많이 보편화되어가고 있다는 생각이 들더군요. 그런데도 제 주위에는 이러한 책을 보는 노력을 하는 사람이 얼마나 되는지는 잘 모르겠습니다. 그 리팩토링이라는 행위가 주는 의미보다는 "어 개발툴이 이런 것도 해주네!" 하면서 사용하는 프로그래머들이 더 많겠죠. 생각해보니 제가 C++ 프로그래밍을 하면서 가장 큰 도움이 된 책은 C++ 언어문법 책이 아니라 94년도경에 어느 유럽의 통신회사에서 만든 C++ 개발 가이드라인 문서였습니다. 버그 및 코드를 보다 잘 읽기 위한 네이밍 룰과 코딩하면 실수하기 쉬운 부분을 Rule화 해서 작성된 포스트스크립트 문서였지요. 프린트를 해서 팀내에서 공유하고 교육했던 기억이 나는군요. 당시 워낙 교재들이 변변치 않아서 너무 소중한 자료였지요. 지금이야 너무나도 많은 책들이 나와서 질릴정도지만요. 주위에 고수들이 없어도 이런 좋은 책들은 빠짐없이 사서 보는 열정을 잃지 않았으면 합니다. 바로 고수들의 숨결들을 느낄 수 있을테니까요. 이러한 경험을 전달해주는 책은 별로 없지만 발견되면 놓치지 않고 챙겨보는 센스를 가진 프로그래머들이 되었으면 합니다. 이런 측면에서 보면 "실용주의 프로그래머" 라는 책은 반드시 봤으면 하는 책입니다. 코더가 아닌 프로그래머를 원하는 이들이라면요.