겐도사마의 재림

오늘도 발견한 신기한 PHP의 성질.

우선 static 키워드는 뒤의 변수는 상수만을 어사인 할 수 있고 Expression은 오지 못한다.
http://www.php.net/manual/en/language.variables.scope.php 의 Example 7 참고.

이제 스트링을 어사인 하는 경우를 생각해 보자.

static $a = "a";

이경우는 문제가 없다. 허나

static $a = "$b";

이때는 스트링이 익스프레션으로 간주 되기 때문에 문법 에러가 발생한다. '$b'가 문제.

자 이제 첼린지.

static $a = "$";

$뒤에 문자가 저렇게 되면? 역시나 문법 에러가 발생한다.

Double Quoted String에서 '$'는 '\$'로 이스케이핑 하는 것이 정석이다.

대충

static $pattern = "@^gendoh$@";

에서 망했다 오늘. 코딩경력 20년차에 문법에러라니.. 쪽팔려라 ㅠ.ㅠ
레귤라 익스프레션과 스태틱이 만나면 이런 일도 발생한다.

재미있는 것은 Eclipse의 PDT나 Zend Studio에서는 '$b'는 문법 에러를 보여주지만 '$'나 '$@'만 쓰면 정상적이라고 인식한다. '$'뒤에 '{'나 alpha-numeric 이 오지 않으면 당연히 '$'는 '$' 케릭터로 인식할 수 있지만 파서의 특성 차이로 아마 이런 일이 발생하는 듯. PHP 파서는 '$'만 나타나면 익스프레션으로 파싱하는듯 하다. 그와중에 뿜는 에러명이

PHP Parse error:  syntax error, unexpected '"' in ...

쌍따옴표가 못온다고라고라;;;;;

Double Quoted String에서 '$'를 쓸땐 이스케이핑 해 주는 것이 정석일듯 하다.

나도 따라해 보는 비굴모드 @.@;

집에 굴러다니는 컬러레이저젯이 있긴 한데 먼지 쌓인지 오래 -ㅅ-. 아무튼 그놈은 무지 큰데다 퀄리티도 그닥에 소리 엄청 시끄러워졌는데.

5집 Myself(1997)의 11번 트랙. 왠 벼락맞은 여자가 톱들고 연주해서 한동안 톱연주(?)가 방송에 종종 나왔던 기억이. 오늘 하루죙일 들었던 노래.

가사 펼치기

PS.
Myself를 무의식적으로 Mysql로 쳤다;;; 심지어 이 PS 적는 순간에도. 직업병 ㅠ.ㅠ

PS2.
Myself 엘범의 타이틀 곡인 "뻐꾸기 둥지위로 날아간 새"를 들었을 땐 이번 엘범은 별로다~ 라고 생각했는데 이 노래 듣고 이엘범도 좋아했던 기억이 있다.

PS3.
Rumors의 "STORM"이라던가.. 아무튼 징하게 슬픈 내용인데 댄스발랄풍(?) 노래를 대체적으로 좋아하는듯.

"무엇이든지 물어보세요"에서 하는거 보고 경악.

대충 정리된 자료를 찾아보니 아래 정도로 보인다.

http://weekly.chosun.com/news/html/200012/200012190030.html

체크리스트가 거의 만점에 가까운;;;; ㄷㄷㄷ

6개월 정도만 더 버티면 마법사 레벨 1이 될 수 있는데(25세설과 30세 설이 있는데 본인은 30세 설에 좀더 비중을 두고 있다.) 위 기사를 읽다보니...

남성 갱년기의 증상들 중 가장 뚜렷한 것의 하나가 성욕의 감소인데, 남성호르몬의 투여로 남성호르몬치가 정상으로 교정되면 성욕이 회복되고 활력을 찾게 된다. 반대로 성적 활동성이 증가하면 남성호르몬 생산이 증가하기도 한다.

워크홀릭 솔로들이여... 좋지않아... 피로감이 온몸을 지배하지.

120살까지 지켜내어(?) "리치"가 된다 한들 무슨 인생의 낙이!

http://www.zdnet.co.kr/news/enterprise/etc/0,39031164,39169831,00.htm

특히 두번째 세번째에 해당한다.


말단이던 시절에는 개발자 개개인의 자기개발이 중요한 것은 인지하였지만 직급상승 이후에 장기적인 관점에서 보자면 개발팀, 조직의 능력 향상을 위해선 팀내 교육도 상당히 중요하다고 본다.

어떤 조직이 발전해 가는 것은 개개인의 능력이 증가되고 팀내 지식이 쌓이게 되어 조직의 능력 자체가 발전해 가는 것이라 본다. 당장의 프로젝트 수행을 위해선 "닥치고 일" 내지 "쥐어짜기"가 답일 수 있지만 장기적인 관점-특히 내가 속한 조직은 서비스를 계속 잡고 발전시켜나가는 곳이다보니-에서는 당장의 듀 보단 팀의 능력 발전은 매우 중요한 부분이란 생각이 든다. 그래야 다음 사이클에서 좀더 속도가 날 수 있고, 그 다음 사이클엔 좀더 많은 것을 할 수 있고, 그다음엔 획기적인 것도 도전해 볼만해 진다.

단순히 학원 수강료 지원해 주는 차원은 아니다. 선임급 연구원이라면 다른 연구원들의 "Mento" 역할을 할 수 있어야 하고, 누군가 배우거나 연구하거나 발명해 낸 것은 그 조직안에서 쉐어링이 필요하다.

회사의 성장은 아직 CEO질을 안해봐서 모르겠고, 적어도 팀의 지속적인 성장은 다음 프로젝트, 다음 시기가 올 수록 가치는 높아지고 새로운 과실을 열리게 만드는 중요한 거름이라 생각된다.

사람 개개인은 이직도 하고 그럴 수 있지만 팀에 녹아내리는 지식은 중요한 회사의 자산이 될 수 있다고 본다.

테스트 링크 : http://kr.webzine.blog.yahoo.com/WEBZINE/test_q.html?dap=+1&zine_num=37

참고글 : http://news.egloos.com/1769189


두근거리는 마음으로 성실히 답하는 겐도의 결과는????




15단계중 14단계에서 백지;;;;

제길;;;;

거부하는거냐!!!!
 ㅠ.ㅠ

자바스크립트 완벽 가이드
ISBN : 9788991268418
강컴 링크, 출판사링크, yes24
책 표지는 강컴에서 무단으로 도용;;;;

가끔씩 주장하지만 난 JS를 잘 모른다. Dojo를 사용해서 Drag-N-Drop을 구현했지만 그것은 샘플보고 따라 한 것에 지나지 않고 기초적인 문법조차 정확히 알지 못한다. 최근에 Call-By-Referance가 JS에서 되나 안되나 한참을 찾아봐야 했던 적도 있다. 아무래도 계속 이러다간 문제가 생길것 같아 막간을 이용해 JS 공부나 좀 해볼겸 이 책을 샀다.

본책 + 별책으로 되어 있고 별책은 코어 자바스크립트 레퍼런스로 구성되어 있다. 본책은 몇번 읽고 책장에 고이 모셔두고, 별책은 화면이 좁아서 헬프 보기 힘들때 찾아보면 될 것 같다. 아마 JS 1년만 제대로 파고나면 둘다 별로 필요 없을 것이다. 아직 JS의 J자도 모르는 난 당분간 봐야 겠지만.

한시간 정도 앞부분을 주욱 보는데, 나처럼 이미 다른 언어들을 경험해 보았고 ECMA-262에 대해 원래 문서 보자니 갑갑하고 해서 번역 + 케이스별 자세한 설명을 주룩주룩 보면서 JS를 빠른 시간안에 익히고 싶다면 괜찮지 않을 까 한다. 비교적 번역 품질도 괜찮고 설명도 자세하다. 허나 JS를 처음 프로그래밍 랭귀지로 선택한 사람에겐 초반은 상당히 힘든 시간이 아닐까?

이 책을 보면서 느낀 것은 언어 입문서로서의 필요한 부분이다. 나야 BASIC, C/C++, Pascal, Delphi(Object-Pascal), Scheme, ML, Prolog, PHP, C# 등등을 해 봐서 기본적인 프로그래밍 개념은 가지고 있고 JS의 언어적 특성과 문법 정도만 머리속에 넣고 나면 새로운 언어도 금방 적응할 수 있겠지만 처음 시작하는 사람에겐 생소한 개념이고-컴퓨터가 아무리 인간의 두뇌를 모델링하려고 했지만 전혀 다른 시스템이 아닌가- 특히 예제가 부족한 점은 두꺼운 책이 주는 부담감과 더불어 포기하거나 제대로 이해하지 못하게 하는 부분이 아닌가 한다. 이 책의 예제들은 나름 자세한 편이고 나야 눈으로 대충 보면 JS 인터프리팅 엔진이 되어 이해가 가지만 완벽히 독립적으로 동작하는 예제가 주어지지 않는 다는 점은 초보자에겐 어려움으로 다가올 것이다.

동작하는 예제의 중요성은 최근 기타를 배우면서 더욱더 느낀다. 5번째 위치에서 손가락 4개 차례대로 짚는 연습을 하고 있는데 가끔씩(--;) 운지에 성공하더라도 그닥 감흥이 없다. 오히려 그전에 잠시 본 C-Am-F-G7의 장난이 오히려 내가 기타를 치고 있긴 하구나라는 느낌을 준다. 처음 BASIC을 배울때도 각 구문마다(가령 if 라던가, for-loop)10~20개씩의 예제를 작성하면서 배운것이 지금껏 많은 도움을 주는듯 하다.

분명 이 책은 입문서라고 보인다. 앞의 상당 부분을 문법 설명에 할애하고 있고 매우 자세하게, 그리고 차근차근 설명해 준다. 허나 단편적인 샘플 코드는 지금 설명하고 있는 부분을 실제로 동작시키기엔 초보자에겐 너무 어렵다. 예전의 둔기형 흉기라 불리고 떨어뜨리면 발가락 사망에 배고자면 목디스크인 그책처럼 너무 과도한 예제는 문제가 되겠지만 이런 언어피쳐부터 설명하는 책이라면 적절한 예제가 중요한 부분이라 생각된다.

책 광고는 못할망정 빈정거림이 되었지만, 아무튼 혹 내가 다음에 언어를 만든다면 그 설명서엔 아름다운 예제를 만들기 위해 노력해야 겠다.

전통적인 상하적인 조직에서는 비젼의 공유가 중요하였다. 총대를 맨 한사람 아래에 그사람의 의지를 공유한 사람들이 동일의 비전하에 일을 수행한다. 각 구성원의 공유가 잘 될 수록 일은 잘 진행될 가능성이 높다. 장점으론 공유의 코스트만 들인다면 이후 일사천리로 일이 진행될 수 있다. 단점은 집단이 동일한 시각을 가짐으로써 집단의 오류를 일으킬 가능성이 높다거나 정점의 사람의 판단에 의존성이 높다. 고전 게임중 하나인 "레밍즈" 처럼 잘 가이드된 쥐들은 무사히 목적지에 도착할 수 있지만 집단의 오류에 빠져 버리면 불구덩이속으로 집단은 달려가게 된다. 소위 "효율적인 도박"을 하는데 적절한 방법이라 볼 수 있다.

최근의 팀 구조나 Open Source Project에서 보여주는 방식은 구성원의 공감을 통한 진행이다. 오늘 Textcube 1.7이 발표되었는데 이 프로젝트의 구성원인 TNF의 경우 이 방식의 장단점을 본인이 잘 볼 수 있는 케이스중 하나이다. 가령 포럼에서 누군가 의견을 제시하더라도 그것이 실제 TC에 적용되기 위해선 많은 사람들의 공감을 요구한다. 조직의 수장이라 할 수 있는 정규님도 기능을 다 구현하고도 공감을 얻지 못하면 roll-back을 당한다. 새로운 커밋터(Commiter - 코드를 직접 수정할 수 있는 권한을 가진 사람)을 선출함에도 그 방식에 대해 리딩을 하는 사람은 있어도 최종 방법이 나오기 까진 많은 논의와 공감과 동의을 필요로 한다. 의사 진행은 느릴 수 밖에 없지만, 대신 구성원들의 노력을 최대한 끌어 낼 가능성이 높다던가 한 문제를 두고 다양한 시각을 통한 문제 해결을 도모할 수 있다는 방법이 있다. 물론 집단의 오류에 여전히 빠질 수 있다. 집단의 특성 혹은 대다수를 차지하는 구성원의 특성에 의해 집단의 시각이 고정될 수 있기 때문이다.

후자의 방식은 관리자의 입장에선 매우 곤란해질 가능성이 높은 조직이다. 구성원들의 공감에 얼만큼의 시간이 소모될 지 예측하기 힘들기 때문이다. 또한 열정을 가진채 탄생하였다면 몰라도 그저 소집된 인원이라던가, 혹은 장시간이 가져다 주는 피로감에 열정이 식어버리면 원래 조직의 가져야할 장점들은 다 사라져 버리고 어중간한 전자의 조직 형태를 뛰게 될 수 있기 때문이다. 양쪽의 단점만을 취한채 "죽음의 행진"을 시작할지도 모른다.

공감 기반의 조직에 좀 더 끌리는 것은 개인적인 경험에 따른 것일지도 모른다. 첫 프로젝트부터 3~4인의 팀프로젝트부터 하였고, 대학의 많은 강의들에서도 3명 정도의 팀프로젝트를 많이 하였다. 회사에서는 "1 리더 + 3인방" 체계로 개발을 하였다. 자신의 생각을 끊임없이 구성원들에게 검증받으려는 노력이었겠지만 자연스레 의견이 첨가되고 문제점들이 수정되어 나간다. 더불어 최근 몇년간 이런 형태에 대해 좀더 생각해 보게 된 것은, 현대의 프로젝트는 혼자의 힘으론 할 수 없을 뿐더러 현대의 프로덕트는 한사람의 머리로 완벽한 모습을 그려 내기 보다는 다양한 머리가 동원되어야 확률이 올라갈 것이라는 생각이 들어서이다. 적어도 확실한 것은 나의 지식이나 경험조차 편항되어 있고 모든 케이스를 알고 있고 모든 시야를 볼 수 있는 사람이 존재할 확률은 극히 낮을 것이라는 가정때문이다. 아무리 뛰어난 사업가라도 개발적인 부분에서 나보다 뛰어날 확률은 높지 않을 것이다. 분업이라는 현대사회의 개발시스템 특성상 한 사람이 모든 부분을 잘하긴 힘들기 때문이다. 그리고 분야별 전문가가 존재하는 이유도 그럴 것이다.

공감시스템에 참여하는 단위는 3~4개가 적당하지 않은가 한다. 한번에 고민하는 인원이 저정도가 적당할 것으로 보인다. 전체적인 구조는 상황에 따라 병렬 팀 구조나 수직적 트리구조를 가질 수 있다. 중간 리더급 인력이 3~4개의 단위(팀)에 참여해서 공감된 내용을 위로 들고 가서 논의하거나 위에서의 내용을 아래에서 공감작업을 할 수도 있다. 조직의 25% 정도가 공감작업에만 소모될 가능성도 있지만 파티셔닝을 통하여 해당 조직의 사이즈를 적절히 조정한다면 공감작업의 코스트가 10% 미만까지도 떨어지지 않을 까 하는 생각이 든다.

최근 낙하산 브레인에 쓴맛을 본 모 조직이나, 잘나가는 외국계 그 기업을 볼때(더불어 보아온 케이스 등등등) MS의 "빌 아저씨"의 시대는 가고 공감조직이 분명 성공 확률을 높이는데 좋지 않은가 한다. 물론 "스티브 아저씨"의 기업이 절대적이지는 않음을 보여주고 있긴 하지만 말이다.

일단 내가 슈퍼맨-모든 분야에 전문가가 아니라는 사실, 그리고 많은 공감 모델을 통한 장점을 맛본 나로서는 손이 갈 수 밖에 없지 싶다.

VMWare 업데이트가 드디어 나왔습니다. ㅠ.ㅠ

http://www.vmware.com/support/fusion/doc/releasenotes_fusion.html#new113

무엇보다도..

Corrects a problem in which VMware Fusion encountered reactivation problems in the native Boot Camp partition and the Boot Camp virtual machine when installing Windows Vista SP1.

아직 테스트는 못해 보았습니다만, 이제 VMWare에서 붓캠에 설치된 비스타를 문제없이 로딩할 수 있으려나요 +.+


보너스입니다. CNET TV를 PodCast로 받아보는데 재밌는게 있어서.
http://www.cnettv.com/9742-1_53-50002522.html

Prizefight: Bill Gates vs. Steve Jobs