검색엔진

토요일, 11월 30, 2013

[B급 프로그래머] 루비 slf4r java_logger의 버그 하나

조금 전문적인 이야기가 될지 몰라 적을까 말까 고민하다, 혹시 jruby에서 slf4r을 사용하다 동일한 문제에 부딪힐지도 모르는 개발자분들을 위해 간략하게 팁을 정리하고 넘어가겠다. 다름이 아니라, jruby에서 Java의 slf4j와 연계해 같은 로그 파일에 기록하려면 slf4r에 속한 java_logger를 사용하면 딱인데, 사소한 버그 하나 때문에 애로 사항이 꽃핀다.

java_logger.rb에서 문제가 되는 코드 일부를 가져와봤다. 눈썰미 있는 독자라면 숨겨진 폭탄을 하나 찾을 수 있을테다. 5분을 줄테니 코드를 검토해 벌레를 잡아보자.

    def #{level}(msg = nil, exception = nil)
      if(@logger.is_#{level}_enabled)
        msg, exception = yield if block_given?
        if(exception.type == NativeException)
          @logger.#{level}(msg, exception.cause)
        else
          @logger.#{level}("\#{msg}\#{format(exception)}")
        end
      end
    end

이미 짐작하는 바와 같이, 위 코드는 exception이 nil이 아닌 경우에만 정상 동작한다. 만일 exception이 nil일 경우 nil에서 type을 찾으므로 런타임 오류가 발생한다. 그렇다면 어떻게 수정하면 문제가 해결될까? 다음과 같이 단순하게 exception.nil?을 사용하는 nil 점검 루틴을 넣어보았다.

    def #{level}(msg = nil, exception = nil)
      if(@logger.is_#{level}_enabled)
        msg, exception = yield if block_given?
        if exception.nil?
          @logger.#{level}(msg)
        else
          if(exception.type == NativeException)
            @logger.#{level}(msg, exception.cause)
          else
            @logger.#{level}("\#{msg}\#{format(exception)}")
          end
        end
      end
    end

연이은 null 연재물로 인해 지금쯤이면 B급 프로그래머를 null 애호가로 부르고 싶을지도 모르겠다. 이렇게 null로 이미지를 굳힌 김에... 다음 시간에 또 다른 null 관련 이야기 보따리를 풀어보겠다. 기대하시라~

EOB

화요일, 11월 26, 2013

[독서광] 실패하는 사람들의 10가지 습관

오늘 소개드릴 책은 빌게이츠가 추천했다는 말을 듣고 호기심이 급상승해 바로 질러버린 '실패하는 사람들의 10가지 습관'이다. 원래 유명인사가 추천하는 책은 조심스럽게 접근하는데, 까다로운 워렌 버핏이 추천 서문을 썼다는 사실을 알고 두 번 고민없이 바로 구매했다. 일단 제목에서 주목해야 하는 단어는 '실패'다. '실패'라는 용어 자체가 금칙어인 한국에서는 흥행 여부는 뭐 안 봐도 DVD라고 볼 수 있겠다(초판 _2_쇄라 적혀있는 판권지를 보며 눈물이... T_T). 이 책은 코카콜라의 전설적인 경영인인 도널드 키오가 자신을 우스갯거리로 만들 각오를 단단히 하고 쓴 아주 특이한 책이다. 보통 유명 CEO가 쓴 책을 읽어보면 결함이라고는 찾아보기 어려우며 모든 역경과 곤란을 극복하며 운 따위는 믿지 않는 인물이 등장하기 마련인데, 이 책은 전혀 그렇지 않다. 코카콜라에서 발생한 각종 실수와 실패를 중심으로 어떻게 이를 인정하고 (약간의 행운까지 활용해) 해결해나가는지 자신의 경험담을 위트있게 기술한 책이라 보면 되겠다.

책을 펼치자 마자 성공하는 방법 따위는 없다는 말로 독자들을 맞이한다. 그리고 자기 조언만 따르면 무조건 실패한다는 주장과 함께 좀더 빨리 실패하는 방법에 대해 단계별로 설명하는 내용이 이어진다. 요즘 나오는 경영/경제서의 특징인 빠른 전개, 풍부한 사례 연구, 화려한 미사여구에 익숙한 독자라면 구석기 시대에 나온 책으로 간주하고 읽다 포기할 가능성도 있지만 의외의 상황에서 깨알 같이 재미를 주는 부분이 나오므로 (독자의 내공에 따라) 교훈과 웃음을 동시에 얻을 가능성도 존재한다. 이 책의 목차가 아주 중요하므로 여기에 한번 더 옮겨보기로 하자.

  1. 모험은 하지마라
  2. 입장을 절대 바꾸지 마라
  3. 자기 자신을 격리 시켜라
  4. 한 치의 오류도 없는 사람인 척 하라
  5. 법은 정도껏 지켜라
  6. 생각할 시간을 갖지 마라
  7. 전문가와 외부 컨설런트를 무조건 믿어라
  8. 관료주의를 사랑하라
  9. 헷갈리는 메시지를 전달하라
  10. 미래를 두려워 하라
  11. 완벽한 실패를 위한 마지막 습관: 일에 대한 열정을 상실하라, 영원히

본문을 읽다보면 나오는 사례나 조언이 기업을 이끄는 아주 높으신 분에게 해당하는 내용이므로 나랑 무슨 상관이 있는지 어리둥절한 느낌이 들지도 모르겠는데, '자신'의 삶을 경영하는 개인에게도 그대로 적용되는 부분이 상당히 많으므로 글자 그대로 읽기 보다는 자신의 습관과 태도와 관련시켜 읽어보면 색다른 깨달음을 얻게 되리라는 생각이다. 개인적으로 대미를 장식하는 "완벽한 실패를 위한 마지막 습관: 일에 대한 열정을 상실하라, 영원히"가 가장 마음에 들었다. 지금까지 지치고 피곤하고 힘들 때 내가 무슨 부귀 영화를 누리겠다고 이 난리를 쳐야하는지 의심이 들며 열정을 상실하는 상황을 여러 차례 접했는데, 그러면 완벽하게 실패한다는 조언을 듣고(완벽하게 실패한 과거 사례가 주마등처럼 스쳐지나가며...) 화들짝 놀라고 말았다. 로버트 C. 마틴 큰 형님께서 언급한, 들어올 때보다 나갈 때 더 깨끗하게(좋게) 만들고 나가야 한다는, '보이스카우트 정신'을 이 책 역시 마지막에서 다음과 같은 교훈으로 정리하고 있다.

처음에 그 일을 맡을 때보다 마무리 지을 때의 상태가 더 나아야 한다고 마음먹고 최선을 다하라.

결론: 이 책을 구입하든 구입하지 않든 위에 정리한 10가지 실패 습관 + 완벽한 실패 습관 목록은 잘 보이는 곳에 두고 힘들 때마다 읽어보면 많은 도움이 되리라는 생각이다. 실패의 비밀을 알고 싶은 분들께 추천!

EOB

토요일, 11월 23, 2013

[B급 프로그래머] 11월 3주 소식 정리

11월 3주도 어느덧 끝나가고 있다. 트위터를 중심으로 들어온 새소식을 정리해드리겠다.

  1. 웹 개발
  2. 개발/관리 도구
  3. 고성능 서버/데이터베이스
  4. 기타 읽을 거리

11월 마무리 잘 하시기 바라며, 12월 1주에 찾아뵙겠다.

정보: 트위터에서 @jrogue를 follow/list하시면 실시간으로 새소식(물론 개발과 전혀 무관한(응?) 다른 정보도 뒤섞이긴 합니다만...)을 보실 수 있습니다.

EOB

토요일, 11월 16, 2013

[일상다반사] 독일에서 생활하면 어떨까?

"규제없는 독일로 오라"…獨, 한국게임업체 '러브콜'이라는 기사에도 나오지만 노르트라인 베스트팔렌(NRW) 주에서 한국 게임 업체에 전폭적인 지원을 아끼지 않겠다는 소식이 트위터를 뜨겁게 달궜다. 게임 개발자여, 독일로 가자!라는 글에서는 일곱 가지 조언을 곁들여 독일에서 주의할 사항도 친절하게 짚어주고 있다. NRW 주에 속한 주요 도시(뒤셀도르프, 도르트문트, 에센)를 왔다갔다한 경험을 토대로 과연 어떤 명과 암이 있을지 한번 생각해봤다.

  1. 맛있는 치맥은 꿈도 꾸지 마라. 독일에서 작은 슈퍼마켓에도 다양한 맥주가 진열장을 꽉 채우고 있다. 맥주뿐만 아니라 와인 역시 애주가들을 반기고 있다. 여기까지는 좋다. 맥주에는 당연히 치킨이 떠오르지만, 독일에서 야식 통닭 배달은 꿈도 꾸지 않는 편이 좋다. 배달 음식이라는 개념 자체가 없으니까. T_T 그리고 일반적인 식재료는 아주 저렴하지만(우유, 치즈, 계란, 빵 가격은 아주 낮게 책정되어 있다), 식당에서 뭘 먹으려면 가격표 앞에서 상당한 용기가 필요하다. 커피도 테이크아웃이 아니라 편안한 의자에 앉아서 먹을 경우 한국의 프렌차이즈 가격을 바로 넘어가버린다(물론 할아버지 할머니들이 자리를 다 차지하고 있으므로 젊은 친구들이 끼어들 분위기가 아니긴 하지만 말이다).
  2. 온돌은 꿈도 꾸지 마라. 독일의 겨울 장마는 악명 높다. 겨울 내내 영하를 조금 내려간 상태에서 가랑비가 오락가락하고(물론 독일 사람들은 어지간한 가랑비에는 우산을 잘 안 쓰는 듯이 보였다) 밤에는 체감 온도가 장난 아니게 떨어진다. 문제는 난방 시설인데, 한국의 온돌 문화에 익숙해있다면 바로 멘붕이 올만큼 형편없다. 뜨거운 물로 공기를 사알짝 데우는 히터가 전부이므로 바닥에 카페트를 깔며, 침대에서 자고, 실내에서도 두툼한 실내화를 신고 돌아다녀야 한다. 현지 필수 품목 중 1위 2위를 다투는 품목이 바로 전기 장판이라는 사실을 알고 있으면 되겠다. 건강하게 지내려면 (남쪽 따뜻한 지방으로 가는) 휴가가 필수라는 이야기가 그래서 나온다.
  3. 빨리 빨리는 잊어먹어라. 운전 면허증 발급부터 시작해 전화/인터넷 설치까지 그야말로 무한한 끈기와 인내가 필요하다. 게다가 담당자가 휴가라도 갔다면, 휴가에서 돌아올 때까지 모든 관련 업무는 중지된다고 보는 편이 정신 건강에 이롭다. 융통성이라고는 찾아볼 수 없기에 맡은 자기 업무 이외 다른 업무는 해주지 않는다.
  4. 에누리를 기대하지 마라. 한국처럼 이리재고 저리재고 목소리가 크면 저렴하게 구입할 수 있는 물건이 별로 없어보인다(시장가서 잘 흥정하면 또 모를까...). 하지만 이게 단점이자 장점이다. 온/오프라인 가격이 일정하므로 어떤 물건을 살지만 결정하면 어디서 구입하나 손해를 보지 않고 살 수 있다. 물건 가격은 한국에 비해 대체로 비싸고 A/S 관련 워런티를 별도로 붙여야 하는 경우가 많고 배송/설치비도 제법 든다. 저렴한 가구 집기의 대명사 이케아가 있잖아? 하지만 배송/설치비가 물건값보다 더 든다는 사실을 알고 가기 바란다(적재함이 넉넉한 자동차가 없으면 가구도 못 산다).
  5. 영어가 100% 통하지는 않는다. (어차피 NRW 주에는 서울/부산처럼 큰 도시도 없지만...) 도심에서 벗어나기 시작하면 영어로 의사 소통이 불가능한 경우가 생긴다. 작은 우체국에 간 적이 있는데, 영어를 아는 직원이 한 명도 없었다. 다행히 독일어 숫자 정도는 읽고 쓸줄 아니까 잘 넘겼다. 하지만 택시를 탔는데 터키 운전사가 독일어로 말을 거는 경우라면? 은행에 갔는데 독일어로 서류를 작성해야 한다면? 기차가 조금 연착되어(독일도 종종 기차 연착이 일어난다. ㅋㅋ) 플랫폼이 바뀌고 있는데, 안내 방송을 유창한 독일어로 한다면? 잠시 방문이 아니라 계속 살아야 한다면 독일어를 모르면 큰 낭패다(바로 뒤에 아주 좋은 예가 나온다). 그리고 영화는 기본적으로 독일어로 더빙되어 나온다. ㅋㅋㅋ
  6. 계약은 문서로 한다. 전화 한통화로 모든 것이 처리되는 한국과는 달리 독일은 문서가 아주 중요하다. 전기/가스요금부터 자동차 보험 계약서 등 모든 계약은 명확하게 문서로 주고받아야 나중에 골치 아픈 일이 안 생긴다. 법정에 출두하더라도 관련 레터만 잘 보관하고 있으면 문제가 없는데, 한국처럼 좋은게 좋을거라고 대충 넘어갔다가는 금전/시간 손실을 감수해야 한다. 그런데... 이걸 독일어로 형식에 맞춰 써야 하는 경우가 생긴다.
  7. 독일 사람들이 모두 다 법을 잘 지키고 남들에게 친절할까? 이건 복불복이라... 각자 상상에 맡긴다. 거기서도 무임승차할 사람은 무임승차하고 사기칠 사람들은 사기치고 도둑질할 사람들은 도둑질한다. 따라서 한국처럼 커피숍에 어서 가져갑쇼~ 하듯 노트북을 내려놓고 화장실가는 우를 범하지 말기 바란다.

이렇게 설명하고 나니 독일에 가지마라는 듯이 들리는데, 독일의 절차에 익숙해지기까지가 힘들어서 그렇지 그 이후부터는 정말 규칙대로 움직이므로 복잡하고 번잡한 것을 싫어하는 사람들에게는 딱 좋은 나라다. 하지만 끊임없이 정치/경제/사회/문화 뉴스거리를 제공하는 역동적인 한국 상황에 익숙하고 그걸 즐기는 사람들이라면 권태/지겨움으로 인해 버티기 어려울지도 모르겠다. 다행스럽게도 규칙을 좋아하는 개발자들에게는 독일이 그렇게 나쁜 선택은 아닌 듯이 보인다.

지금까지 _잡생각_을 늘어놓아봤다. 개인의 주관적인 경험이니 사실과 다른 부분이 존재할 수 있으므로, 잘못된 부분은 댓글로 알려주시기 바란다.

EOB

[독서광] 과학자의 관찰 노트

트위터를 열심히 하다보면 종종 좋은 책을 소개받을 경우가 있다. 오늘은 트위터 뽐뿌질에 넘어가 덥썩 구입해버린 '과학자의 관찰 노트'라는 책을 여러분께 소개해드리겠다. 책 제목보다 조금 작게 쓰여진 '자연을 관찰하고 기록하는 12가지 방법'이라는 부제가 무척 중요한데, 자연사학자, 박물학자, 현장과학자, 자연과학자들이 현장 탐사 과정에서 작성하는 '관찰 노트(Field Note)'를 집중적으로 다룬다.

책을 구입하기 전에 떠올린 이 책에 대한 이미지는 필기의 달인이 작성했을 법한 예쁜 동식물 그림(동식물 도감?), 깔끔하고 깨끗하고 가지런히 정리된 텍스트였다. 하지만 실제 책을 배송받고 펼쳤을 때 예상과 다른 내용이 등장했기에 순간 당황했다. 필기체로 급히 갈겨 써 해독하려면 상당히 노력이 필요한 노트 내용을 보고 공책 정리의 달인이 되는 법 따위는 잊어버리기로 했다(물론 본문 중 몇몇 노트는 그림까지 곁들여 깔끔하게 정리되었기에 귀감이 될만하다). 이 책은 개성이 가득한 총천연색 관찰 노트를 곳곳에 배치하긴 했지만 이는 어디까지나 참고 자료이며, 사실상 자연 탐사 과정의 현장에서 일어나는 다양한 이야기를 '관찰 노트' 작성이라는 주제와 연결해 풀어나가고 있다. 사무실에서 벌어지는 따분한 공책 정리 이야기가 아닌 현장 탐사 장면이 대부분이므로 미국 HBO 미니시리즈인 '지구에서 달까지'의 10편 "갈릴레오가 옳았다'에서 지질학 공부를 위한 현장 학습 장면을 연상하게 만들기도 했다.

이 책은 15명의 현장 전문가들이 각자 자신의 주특기(대상은 아주 다양하다. 동물, 식물, 곤충, 사람, ...)에 맞춰 '관찰 노트'를 어떻게 작성하는지를 설명한다. 아름다운 동식물이나 자연 경관에 대한 화려한 볼거리는 없지만 관찰 결과를 자신, 동료, 후대에 전파하기 위해 쏟아붓는 엄청난 노력이 이 책의 미덕이다. 어릴 때 제법 많은 시간을 야외에서 메뚜기랑 매미도 잡고, 풀도 관찰하고 놀았지만 방학 숙제로 곤충 채집할 때를 제외하고는 어떤 정리나 기록도 하지 않았기에 이 책을 읽고 나서 아쉬움이 많이 들었다. 만일 그 때 기록하는 습관이 들었더라면 지금 완전 다른 모습으로 살고 있을지도 모르겠다. 이 책을 읽으면서 무엇을 얻었냐구? 책 날개 표지에 잘 정리된 자연 탐사와 관찰 노트 작성과 관련한 지은이의 10가지 교훈을 옮겨보겠다.

  1. 관찰을 즐겨라. 그러면 많은 것을 배우게 될 것이다.
  2. 어디라도 상관없다. 흥미로운 것이 있다면 그 즉시 적어라.
  3. 동물을 가까이에서 관찰하고 기록하려면 컴퓨터보다는 수첩이 좋다.
  4. 가능한 한 모든 것을 기록하라. 어디에서 아이디어가 나올지 모른다.
  5. 문장으로 자세하게 기록하는 능력을 길러라.
  6. 관찰한 것을 그림으로 그려라. 잘 그릴 필요는 없다.
  7. 그림을 그리면 관찰 대상을 더욱 자세히 보게 된다.
  8. 관찰 노트를 사진과 파일 등 모든 정보를 하나로 묶는 총사령관으로 이용하라.
  9. 식물 표본의 이름표에는 꼭 들어가야 하는 정보가 정해져 있다.
  10. 컴퓨터를 이용하면 기록 과정을 매우 단순화할 수 있다.
  11. 다른 사람이 쓴 노트를 보고 좋은 점을 취하라.
  12. 관찰 노트를 작성하는 목적에 맞게 자신만의 방식을 설계하라.

이 책의 다른 내용도 아주 좋았지만, 개인적으로는 8장 '왜 스케치를 해야 할까?: 과학 일러스트레이터의 그림 도구'가 가장 마음에 들었다(아니 충격적이었다). 개인적으로 손재주가 없어 그림이라면 질색을 하는 바람에 더욱 그림을 못그리게 되고 파워포인트 등으로 발표 자료 등을 만들 때도 엄청난 곤란을 겪고 있다. 그런데 8장에서 기본 구도를 잡고 간단하게 스케치 하는 방법, 색상을 선택하는 방법, 간단한 도구를 활용하는 방법을 전문가가 아닌 과학자를 위해 설명하는 내용을 보고 무릎을 탁 쳤다. 아니 지금까지 초보자를 배려하는 책이 왜 그렇게 나오지 않았는지 그게 더 궁금한 지경이었다(그래서 강남 교보문고 예술 코너를 돌며 나름 신경을 써서 '초보자'용 스케치/그림 입문서를 찾으려 했으나... 만족할만한 성과를 얻지 못했다). 12장 '나만의 관찰 노트를 만들자'가 그 다음으로 마음에 들었다. 11장까지 나오는 내용을 총정리하는 동시에 다시 한번 자연 탐험과 관찰 노트 작성의 즐거움을 배가하는 각종 팁을 제시하고 있기에 마무리로서 아주 좋은 선택이었다는 생각이다.

결론: 어릴 때 과학자가 되고 싶었던 분들이라면 이 책을 읽으면서 옛날 생각이 많이 날 것이다. 오늘도 현장에서 열심히 뛰어다니는 과학자들의 생동감을 느끼고 싶은 분들께 이 책을 강력하게 추천한다.

EOB

수요일, 11월 13, 2013

[B급 프로그래머] 프로그래머와 NULL, 그리고 Optional

지난번에 올려드렸던 [B급 프로그래머] SQL에서 UNIQUE와 NULL 제약 조건을 많은 분들께서 재미있게 읽어주셨기에, 오늘은 신이 난 김에... 프로그래머 관점에서 NULL을 살펴보기로 하자.

데이터베이스 뿐만 아니라 프로그래밍 과정에서도 NULL은 아주 골치 아픈 존재다. NULL은 실패를 의미하기도 하며, 성공을 의미하기도 하며, 둘 다를 의미하기도 할뿐더러... Map과 같은 자료 구조에서 반환된 NULL은 Map에 키로 조회한 결과 값이 NULL인지 아니면 없는지 구분하기 어렵게 만들기에 주의 깊게 사용하지 않으면 대박 버그를 양산할 가능성을 높인다. 특히 C/C++에 익숙한 개발자라면 습관적으로 NULL을 반환하는 함수를 작성해왔기에 NULL 사용을 특히 조심할 필요가 있다.

자 그렇다면 NULL의 대안이 무엇일까? C++ 프로그래머라면 boost에서 제공하는 Optional을 사용하면 되며, 자바 프로그래머라면 구글이 만든 Guava 라이브러리에서 제공하는 Optional을 사용하면 된다. C++나 자바나 기본 사상은 비슷하므로 실제 자바 코드를 보면서 특성을 파악해보자. 아주 간단한 예부터 살펴보자.

package jrogue
import com.google.common.base.Optional;

public class BasicTest {
    @Test
    public void optionalTest() throws Exception {
        Optional possible = Optional.of(5);
        System.out.println("Is possible present? " + possible.isPresent());
        System.out.println("possible is " + possible.get());
    }
}

Optional은 null이 아닌 값을 포함하거나 아무것도 포함하지 않는다. 위 예에서는 Optional.of() 메소드에 인수로 5를 넘겼기에 isPresent() 메소드가 'true'를 돌려주며, get() 메소드는 값인 5를 돌려줄 것이다. 그렇다면 비어있다는 의미에서 null(응?)은 어떻게 표현할까? 다음 예를 살펴보자.

package jrogue
import com.google.common.base.Optional;

public class BasicTest {
    @Test
    public void optionalAbsentTest() throws Exception {
        Optional absent = Optional.absent();
        System.out.println("Is absent present? " + absent.isPresent());
        System.out.println("absent is " + absent.get());
    }
}

Optional.absent() 메소드는 아무것도 포함하지 않는 상태로 만들어준다. 따라서 isPresent() 메소드가 'false'를 돌려주며, get() 메소드는... "java.lang.IllegalStateException: Optional.get() cannot be called on an absent value"라는 예외를 던진다. 음... try catch로 예외를 잡아도 좋지만 뭔가 다른 처리 방법은 없을까? 다음 예를 살펴보자.

package jrogue
import com.google.common.base.Optional;

public class BasicTest {
    @Test
    public void optionalAbsentOrTest() throws Exception {
        Optional absent = Optional.absent();
        System.out.println("absent or " + absent.or(0));
        System.out.println("absent orNull " + absent.orNull());       
    }
}

or 메소드는 만일 null이 아닌 값을 포함할 경우 해당 값을, 아무것도 포함하지 않을 경우 인수로 넘긴 값을 기본값으로 돌려준다(여기서는 Integer 0을 반환하겠지? 기본값을 잘 활용하면 실행 중 null을 참조함으로써 발생하는 끔찍한 NullPointerException을 쉽게 요리할 수 있을 것이다). 그리고 orNull 메소드는 만일 null이 아닌 값을 포함할 경우 해당 값을, 아무것도 포함하지 않을 경우 'null'을 돌려준다. 자 그렇다면 Optional.of()에 인수로 null을 넘기면 어떻게 될까?

package jrogue
import com.google.common.base.Optional;

public class BasicTest {
    @Test
    public void optionalAbsentAssignTest() throws Exception {
        Optional impossible = Optional.of(null);
        System.out.println("Is impossible present? " + impossible.isPresent());
        System.out.println("impossible is " + impossible.get());
    }
}

지금쯤이면 이미 결과를 예상하고 있겠지만 "java.lang.NullPointerException" 예외를 던진다. of() 메소드는 null을 인수로 받아들이지 않으며, 비어 있는 의미에서 null을 지정하려면 absent() 메소드를 사용해야 한다. 그렇다면 null인지 아닌지 모르는 값을 Optional에 대입할 때 매번 번거롭게 orNull로 점검을 해야할까? 다음 예를 살펴보자.

package jrogue
import com.google.common.base.Optional;

public class BasicTest {
    @Test
    public void optionalAssignTest() throws Exception {
        Integer value_five = 5;
        Integer value_null = null;
        Optional possible = Optional.fromNullable(value_five);
        Optional absent = Optional.fromNullable(value_null);
        System.out.println("Is possible present? " + possible.isPresent());
        System.out.println("Is absent present? " + absent.isPresent());
    }
}

결과는 여러분들이 예상한 그대로다. Optional.fromNullable() 메소드에 Nullable Reference를 넘기면 알아서 처리해준다.

지금까지 Guava의 Optional을 신나게 살펴봤다. null을 넘기는 방식에 비해 번거롭다는 생각이 들지도 모르겠는데, 이게 바로 Guava Optional 설계자의 의도다. 원문을 그대로 가져와볼까?

Besides the increase in readability that comes from giving null a name, the biggest advantage of Optional is its idiot-proof-ness. It forces you to actively think about the absent case if you want your program to compile at all, since you have to actively unwrap the Optional and address that case. Null makes it disturbingly easy to simply forget things, and though FindBugs helps, we don't think it addresses the issue nearly as well.

Optional이 있으면 프로그래밍 과정에서 한번 더 생각해야 하므로 null로 인해 흔히 발생하는 오류를 잡을 수 있게 된다. 하지만 Optional이 절대 null을 완전히 없애버릴 만병통치약은 아니므로, 필요한 상황에서 적절히 활용하면 되겠다.

EOB

토요일, 11월 09, 2013

[독서광] Resonate: 공감으로 소통하라

경제/경영 블로그답지 않게 계속해서 '개발' 책만 소개했는데, 독서의 계절을 맞이하여 본연의 자세로 돌아와 보겠다. 오늘은 'slide:ology 슬라이드올로지 - 위대한 프리젠테이션을 만드는 예술과 과학'에 이은 낸시 두아르테의 신작인 'Resonate: 공감으로 소통하라'를 소개해드리겠다. 이미 슬라이드올로지를 읽어보신 분들이라면 잘 알고 계시겠지만, 이 책 역시 단순히 파워포인트를 사용한 예쁜 발표자료 만들기에 대한 책이 아니다. 차라리 세상을 바꾸기 위해 사람들을 설득하고 공감하게 만드는 방법을 설명하는 책으로 보는 편이 타당하다. 이미 짐작했겠지만, 이 책은 발표 자료 형식이나 구성에 대한 내용은 거의 없기에 기대했던 바와 다른 내용에 당황할지도 모르겠다. 하지만, 프리젠테이션의 목적이 단순 정보 전달을 넘어선 동기 부여와 참여라는 사실을 미뤄볼 때, 프리젠테이션의 가장 기본을 다루는 이런 유형의 책이 형식이나 기교를 다루는 책보다 먼저 나왔으면 더 좋을뻔 했다는 생각이 들었다. 만일 좋은 프리젠테이션의 원리/원칙만 소개하는 선에서 끝났다면 구체성이 결여되어 "So what?"이라는 반응이 바로 나왔을텐데, 이 책 자체도 좋은 프리젠테이션의 형태를 그대로 반영하고 있기에 이 책을 정독하고 나면 분명히 과거와는 달리 프리젠테이션을 바라보는 시각이 바뀌어 있을 것이다.

이 책은 신화, 영화, 예술 분야를 오가며 사람들에게 감동을 주고 변화를 일으킨 여러 요인을 분석해 이를 프리젠테이션에 접목하는 방법을 다룬 학제간 연구서라고 봐도 좋겠다. 특히 후반부에 나오는 모차르트(음악), 히치콕(영화), 커밍스(시), 마사 그레이엄(무용), 레너드 번스타인(지휘)의 사례를 보고 있으면 장인들의 눈물겨운 노력을 느낄 수 있다. 인구에 두고두고 회자되는 뛰어난 작품은 천재들이 그냥 잠깐 생각해 나온 결과가 아니라 끊임없는 연습, 개선, 고민의 결과라는 사실은 한방에 뜨거나 또는 일확천금을 노리는 일반 사람들에게 시사하는 바가 크다. 프리젠테이션 역시 다른 모든 위대한 공연/예술/작품과 마찬가지로 치밀한 기획, 연습, 개선, 피드백이 필요함을 의미한다.

이 책의 가장 중요한 특징을 하나만 꼽으라고 하면, 바로 스파크라인(Sparkline)을 사용한 프리젠테이션 분석이다. 스파크라인은 현실과 이상 사이의 대비, 감정과 전달 방식의 변화를 시간의 흐름에 맞춰 패턴화하는 좋은 도구이므로 다른 발표자의 의도를 객관적으로 분석하는 동시에 한 걸음 더 나가 자신의 스토리텔링을 구축하는 과정에 적합하다. 본문에서는 리차드 파인만, 존 오트버그, 스티브 잡스, 마틴 루터 킹 주니어의 발표 예를 분석해 관중들을 어떻게 들었다 놓았다 울렸다 웃겼다 하는지 시간의 흐름에 따라 주의 깊게 설명하고 있다. Resonate by Nancy Duarte에 가보면 관련된 여러 관련 비디오와 이미지가 나오므로 책(원서 또는 번역서)과 함께 참조하면 좋겠다.

본문에 나오는 몇 가지 좋은 이야기를 정리해보겠다(정말 간만이다. ㅎㅎ)

위대한 발표는 청중을 변화시킨다.
건강한 조직을 유지하려면 변화와 개선이 지속되어야 한다.
설득의 최대의 적은 모호함이다.
감정요소를 배제하고 전문용어로 무장하는 것이 편하긴 하다. 하지만 편한 것이 항상 최선은 아니다.
악당을 물리치는 이야기든 대단한 사업 성취를 이뤄내는 이야기든 누구나 자신이 이야기의 주인공이라 느낄 수 있어야 한다고 했다.
발표자가 겸손한 자세를 취할 때에만 청중은 통찰력을 얻게 되며 공감대가 형성될 수 있다.
"어설픈 시작은 어설픈 결말로 이어지기 마련이다." - 유리피데스
"인간은 웃고 울 수 있는 유일한 동물이다. 오직 인간만이 주어진 현실과 실현 가능한 이상 사이의 차이를 놓고 경악할 수 있기 때문이다." - 윌리엄 해즐릿
모든 청중은 반드시 변해야만 하는 이유가 분명해지기 전까지는 꼼짝도 안 하고 자신의 현재 위치에 안주할 것이다.
편집은 청중을 위한 것이다. 그들은 뭐든 다 들어줄 생각은 갖고 있지 않다.
"특출나게 훌륭한 글에 가위질을 하고 싶은 충동이 느껴진다면 그 충동에 따르라. 전심으로 말이다. 그 글이 공개되기 전에 삭제해버려라. 아끼는 부분을 없애버려라." - 아더 퀼러-카우치 경
"청중은 구조가 확실한 발표를 원한다." - 헨리 M. 뵈팅거
"무엇이든 초안은 형편없기 마련이다." - 어니스트 헤밍웨이
규칙을 아는 것이 중요하다. 그래야만 유연하게 그 규칙을 깨뜨리면서 새로운 의미를 창조할 수 있다.

보너스: 이 책을 간략하게 소개하는 발표 자료를 공유해드리겠다.

결론: 단순 지식 전달을 넘어 프리젠테이션을 공감과 소통의 장으로 만들어 사람들과 세상을 바꾸고 싶은 분들께 적극 추천한다.

EOB

수요일, 11월 06, 2013

[B급 프로그래머] 11월 1주 소식 정리

벌써 11월이니 2013년 한 해도 얼마 남지 않았다. 남은 기간 알차게 보내기 위해 오늘도 새소식을 정리해드리겠다.

  1. 웹 개발
  2. 개발/관리 도구
  3. 고성능 서버/데이터베이스
  4. 기타 읽을 거리

그러면 알찬 내용으로 3주에 다시 찾아뵙겠다.

EOB

토요일, 11월 02, 2013

[독서광] 안드로이드 하드웨어 서비스

최근에 올라오는 글을 보면, 자바만 편애(응?)하고 나머지는 찬밥으로 취급한다는 생각이 들지도 모르겠다. 그래서 잠시 분위기 전환을 위해 오늘은 아주 간만에 임베디드 관련(물론 자바가 들어있긴 하다. ㅎㅎㅎ) 책을 하나 소개해드리려 한다. 안드로이드 프로그래밍 관련 서적이 아니라 기반 동작 원리를 코드로 다루는 '안드로이드 하드웨어 서비스'가 오늘의 주인공이다. 이 책은 안드로이드 관련 기술 중에 전화기로서 동작하는 부분을 수직(vertical)으로 파고들고 있기에 일반적인 안드로이드 앱 개발자가 아닌 안드로이드 핵심 서비스를 대상으로 뭔가를 하려는 개발자에게 적합하다. 책을 읽기 위해 선행 지식이 필요한데, 리눅스 기초 지식(부팅 과정, 커널 기초), C/C++, 자바를 알고 있어야 애로사항이 꽃피지 않을 것 같다.

'전화기로서 동작하는'이라는 표현을 썼는데, 이 책 목차를 살펴보면 왜 이런 표현이 나왔는지 이해가 갈 것이다. 2장 RIL(Radio Interface Layer), 3장 텔레포티 프레임워크, 4장 USIM, 5장 안드로이드 파워 매니지먼트, 6장 안드로이드 커널 파워 매니지먼트라는 각 목차 제목만 봐도 이 책의 집필 의도와 목적이 확실하게 드러난다. 그런데, 단순히 이론적인 원론이 아니라, 실제 코드(자바와 C/C++)를 중심으로 각 계층 사이의 상호 연관성, 자료 흐름, 제어 흐름 등을 설명하고 있으므로 관련 코드 분석에 앞서 조감할 목적으로 적합하다는 생각이다. 다이어그램과 흐름도를 사용한 구조 소개에 이어 각 부분별로 계층적인 코드 파고 들기(drill down) 예제를 제시하는 이 책은 큰 그림을 그린 다음 함수나 이벤트 호출에 따라 대응하는 코드를 각개 격파하는 방식으로 설명을 진행하므로 나무를 보느라 숲 속에서 길을 잃어버리지 않게 세심하게 배려하고 있다. Yes24 책 페이지에 가서 상세 이미지를 살펴보면 감이 오겠다(예제 이미지가 코드와 연결된 부분이 아니므로 코드와 연결된 부분이 나왔으면 더 좋을 뻔 했다. 실제 본문을 넘기다보면 프로그래머 관점에서 기술되어 있다는 느낌이 들 것이다). 각 장이 유기적으로 수직 연결되어 있으므로 차근차근 읽는 방식을 권장한다.

개인적으로는 전화기의 기본 기능과 관련된 설명이 무척 흥미로웠고, 특히 기존에 전혀 감을 잡고 있지 못했던 USIM 부분이 많은 도움을 줬다. 이제 어디 가서 USIM 관련 기술 토론이 벌어지더라도 주고받는 용어를 이해할 기본 소양을 갖춘 것 같다. 또한 전화기 특성에 맞춘 전원 관리 기법과 임베디드 관점에서 자바와 C 코드 사이에서 연동을 위한 설계 부분을 좀더 신경써서 살펴볼 수 있었다는 점도 좋았다.

결론: 일반적인 전화 통신 규약에 안드로이드 특성에 변경된 리눅스 특성까지 고려해 전반적인 소프트웨어 아키텍처의 흐름을 짚어주므로 안드로이드로 스마트폰을 개발하는 분들이라면 꼭 한번 읽어보시기 바란다. 추천!