뛰어난 디자인일수록 '디자인' 자체를 의식하지 않게 해주는 묘한 특징이 있다(예컨대 잘 디자인된 서적이나 공항 건물 안의 안내판을 보면 내용과 메시지는 뚜렷하게 드러나는 한편 어떤 색상을 사용했는지, 어떤 서체나 컨셉을 사용했는지 자체는 사용자가 알아채지 못 한다). from: 프리젠테이션 젠, 가르 레이놀즈, 에이콘출판사, 30p
발표자는 딱 20장의 슬라이드만을 사용할 수 있고, 각 슬라이드는 20초씩만 화면에 비춰진다. 발표자는 화면에 맞춰 발표를 해야 하는데 통틀어 6분 40초가 걸린다. 슬라이드는 자동으로 넘어가며 시간이 다 되면 발표자도 내려와야 하는 것이 페차쿠차의 규칙이다. from: 프리젠테이션 젠, 가르 레이놀즈, 에이콘출판사, 55p
구글의 발표에서 보았던 번개토크(lightning talk) 강연과 유사했는데, 기회봐서 그런 모임을 만들어야겠습니다. ^^
온실의 화초 같이, 우리에서 사육되는 돼지처럼 길러지면 소모품이 될 수 밖에 없다고 생각합니다. 고기를 주지 말고 고기 잡는 방법을 알려 주라는 옛말은 이럴 때 적용되는 것 아닌가 합니다.
중대한 의사결정이야 최종 의사결정권자가 결정을 내리더라도 일을 진행함에 있어서 수많은 크고 작은 결정의 순간이 있습니다. 이 때 고기잡는 방법이란 판단의 기준이 되는 가치관이 될 것입니다. (낚는 법이라는 게 그럴 듯한 제목으로 낚시글 쓰라는 것은 아니겠지요. ㅡㅡ;) 다른 말로 얘기하면, 자바스럽게 얘기하면 Interface는 알려줘도 Implement는 직접 하게 해라라고 할까요.
okjsp 게시판에 한 후임이 자신의 사수에 대해 너무 하다면서 올린 글이 이슈가 되고 있습니다. 메모 리플이 107개에 굴비가 10마리 정도 달렸고, 각각의 굴비마다 또 토론이 이뤄지고 있습니다.
군 생활에서 좋은 고참을 만나는 것도 중요하지만, 또이또이한 후임병을 만나는 것도 복입니다. 후임병을 아무리 잘 교육시킨다고 해도 자신의 뜻대로 움직이기는 힘들 것입니다. 아마도 후임의 마음을 움직일 수 있는 것은 초코파이가 아닌가 생각되네요.
상황을 바꾸는 가장 좋은 방법은 자신이 먼저 바뀌는 것이라고 합니다. 자기는 바뀌지 않은 채 남들만 바꾸라고 외치면 아무 것도 변한 게 없게 됩니다. 사물 뿐만 아니라 사람에게도 관성이 있습니다. 변하기 귀찮아 하는 마음, 변화에 대한 두려움, 20,30년 동안 살아온 태도에 관한 관성, 이 관성 때문에 함께 일하는 사람들의 마음을 합치기가 어렵습니다. 나의 관성과 다른 사람의 관성이 충돌을 일으키면 자신도 변해야 합니다. 두 힘의 방향을 일치시켜야 협업이 가능할 것입니다. 아니면 싸우는 데 에너지를 많이 소비할 것입니다.
약간 살지고 눈가에 주름 빼고는 고딩때 모습 그대로 입니다. 그때 나이 곱하기 2한 나이가 지금 나인데 말이죠. 인터넷에서 컨퍼런스 강사 중에 제 이름이 있는 것을 보고 검색해서 제 메일로 연락이 와서 만나게 되었습니다. 이런 게 개인정보인가 봅니다. ^^; 그 때 친구들 얘기하는 것이 정말 재밌었습니다.
1차 끝나고 회사 앞으로 간다길래 따라갔더니 "뉴라이트 매국노"라고 외치는 1,500명 +-1,000명 정도의 촛불든 사람들이 있었습니다.
마인드맵을 이용해서 강의한 두 번째입니다. 저도 허진영님 덕분에 알게 된 강의 방식이었죠. 자료는 부분 캡쳐를 차례대로 ppt에 붙여놓았습니다.
최상훈 JCO회장의 인사말과 자바원 개관으로 세션은 시작되었습니다.
현장의 모습에 대한 인상적인 사진이죠. 택시 옆문에 쓰여진 OUR PEOPLE. OUR COMMUNITY.는 자바원과 상관없는 것이지만 눈에 띄는군요.
총 370석이라고 하는데, 300분 정도 참여하신 것 같습니다.
세미나는 JavaOne 2008 내용을 요약해서 발표하는 것이었습니다. 자바의 2008 트렌드에 대한 이야기라고 할 수 있죠.
참가 기념품은 인형스피커인데, 깜찍합니다. 지금도 ipod video에 연결해서 잘 듣고 있습니다. 강사 기념품은 USB였습니다. 이거 뭥미~ 할 뻔하다가 8기가 USB에 헉~뜨 했습니다. 잘 쓰겠습니다. ^^;
세미나 끝나고 문 밖에서 질문받고 있었는데, 테스트 케이스의 효용성에 대해서 프로젝트 후반에 "삽질"을 효과적으로 줄일 수 있다고 답변을 도와주신 분께 감사드립니다. SI 환경에서 테스트케이스를 만드는 것은 이미 생각하신대로 힘든 일입니다. 일정의 압박이나 그 외 스트레스가 많은 환경이니까요. 팀장의 의지와 팀원들의 소통도 원활해야 가능한 일이 아닌가 생각됩니다.
테스트케이스와 더불어 매일 30분 정도의 프로젝트 팀 코드리뷰시간을 갖는 것을 추천합니다. 팀원들 사이에 좋은 커뮤니케이션 시간이 될 것입니다.