Dharma

간만에 정리를 하는군요. 그만큼 이번 글은 매력적인 글입니다. 평소 '잭 트라우트' 스타일의 마케팅을 전략처럼 다루어서 회사가 나아갈 지침으로 삼는 스타일의 마케팅 전략과도 비슷한 글이라고 보기 때문에 정리를 안할 수가 없더군요. 원문: http://hbr.org/2013/12/when-marketing-is-strategy/ar/1 제품을 만들고 판매하는 것을 어떠한 '개천의 흐름'이라고 생각한다면, 개천 상류쪽에서는 공장에서 일어나고 상점에 보급하는 일이 일어난다고 볼 수 있습니다. 즉 구매, 생산, 유통과 같은 것을 기업의 업스트림이라고 볼 수 있습니다. 그렇다면 개천의 하류로 볼 수 있는 다운스트림은 무엇일까요? 소비자의 인식을 형성하고 비용과 위험을 줄이는 데 초점을 맞춘 것이라고 저자는 이야기..

Android NDK (Native Development Kit) 을 이용해서 개발하고 있습니다. NativeActivity 를 이용하고 있습니다. 그런데 작지만 해결하기 어려운 버그가 있습니다. NativeActivity 는 Java 의 Activity 의 일종인데 JNI 를 이용한 Native C/C++ Entry Point 를 쓰레드 (Thread)를 이용해서 호출하는 부분을 잘 감싸서 NDK 를 이용해서 개발하고자 하는 사람들에게 편의를 제공할려는 목적으로 만들어 진것으로 보입니다. 특히나 게임 , 전화, 멀티미디어 용 어플리케이션을 개발하는 사람들은 필히 관심을 가져볼 만합니다. 발생한 이슈는 제가 추천한 책에서 언급된 소스에 다른 모듈을 붙일려고 하는 순간에 발생했습니다. 참고로 만들어본 An..

저는 Command Line 에서 GIT 을 쓰고 있습니다. '뭐든지 가장 기본이 되는 것부터 마스터를 하자!' 라고 평소 떠들고 다니기도 하지만, CLI (Command Line Interface) 가 가장 마음이 편안해 (?) 지는 환경이기 때문이도 합니다. 그러나 Eclipse 에서 개발이 최적화 되어 있는 분들은 어떤 방식이 되도 무조건 Eclipse 에서 돌아가길 원합니다. (진정한 IDE 라고 할 수 있죠) 그런분들에게 추천하고 싶은 포스트가 있습니다. http://www.vogella.com/articles/EGit/ 일단 포스트 주소입니다. 그리고 이 포스트와는 별도로 저 분의 사이트는 안드로이드 개발하는 분들에게 참조가 될 만한 내용을 정말 많이 가지고 있어서 즐겨찾기 해두시고 가끔가다 ..

Emacs 와 JDEE 와 Maven 과의 결합의 마지막을 해결했습니다. 그 전의 세팅을 보시고 싶으시면 1. Emacs 와 JDEE 로 안드로이드 개발하기 2. pom-parser 를 이용해서 pom.xml 을 파싱해서 classpath 에 포함시켜주기 2 번까지 끝을 내고 나니 Emacs 내에서 maven 컴파일과 빌드를 하고 싶더군요. (당장은 mvn install 만 되게) 딱히 다른 사람들이 만든 것은 내 필요에 부합하지 않은 것 같기도 하고 지원도 더 이상 하지 않는 것 같기에 직접 만들게 됐습니다. jdee 프로젝트 안에 있는 jde-make 를 변경했습니다. 간단하게 되더군요. 적당한 곳 (~/.emacs.d 안에)에 jde-mvn.el 을 복사하시고 .emacs 안에서 (require '..

원문 : http://hbr.org/2013/04/three-rules-for-making-a-company-truly-great/ 저자: Michael E. Raynor and Mumtaz Ahmed 요약 세상에 많은 기업중에서 수 천개의 기업을 대상으로 한 통계 연구에서, 수 백개의 기업이 상대적으로 성과가 탁월하고 지속적으로 존속하는 '이례적인 기업'이라고 볼 수 있습니다. 수 십년간 성공해 온 이런 기업들의 공통점으로는 전략적 선택으로 세 가지 기초적인 규칙에 근거하고 있다는 점입니다. 1. 가격을 저렴하게 하기 전에 더 좋아져라 가격으로 경쟁하기 전에 다른 차별적인 요소로 경쟁을 해야 한다는 이야기 입니다. (보통 혁신을 많이 이야기 합니다) 2. 비용을 생각하기 전에 수익을 먼저 생각하라 비용..

간만의 HBR 아티클 입니다. 그동안 제가 (게을러져서) 바빠져서 짬을 낼 틈이 없었습니다. 이번 아티클은 기업의 역사를 리더쉽 도구로 활용할 수 있는 방안에 관한 글 입니다. 평소 역사를 좋아하는 제 입장에서는 오옷 이런 내용이? 하고 (제목만 보고) 게다가 저자들이 역사학자라고 하니 기대를 엄청하고 봤지만, 보다고 졸아버린 몇 안되는 아티클 중 한개 입니다. 다르게 생각해보면 고래로 제왕학이나 정치학의 기본은 역사였습니다. 고래로 많은 문화적 과학적 발전이 있었지만 사람 자체는 많이 변하지 않았습니다. 따라서 사람이 벌이는 일에는 고대나 지금이나 별 차이가 없다는 것이 한 때 역사를 진지하게 생각했던 제 입장입니다. 그렇기 때문에 예나 지금이나 역사를 공부하는 것은 과거를 돌아봄과 동시에 미래를 계획..

지금 하고 있는 간단한 App 서버를 만들기 위해서 Node.js 를 사용해 보고 있는 중입니다. 빠르고 간단하고 아주 쉽게 App 서버를 만들 수 있는 강력한 툴이지만, 조금만 깊이 들어가면 골치 아픈 구조더군요. Async Hell 이라고 불리는 CallBack 이 CallBack 을 부르고 , 또 부르고 부르고 부르고.. 한 5단계 내려가게 되면 환장하겠더군요 지금까지 제가 익숙하게 다뤄온 언어들이 대부분 Event-Driven 방식이 아니라서 그런지 적응하는데 시간이 좀 걸릴거 같습니다.

by A.G. Lafley, Roger L. Martin, Jan W. Rivkin, and Nicolaj Siggelkow ( September 2012) 혁신적인 리더? 라고 질문을 던지면 대개 사람들은 잡스를 떠올립니다. '죽은 공명이 산 중달를 물리쳤다' 고 하는 것과는 약간 다르지만 대개 죽어버린 사람의 업적이나 평가를 산 사람이 뛰어넘기가 어렵습니다. 하물며 잡스처럼 쇼맨쉽이 강했던 사람은 더욱 더 힘이 듭니다. 그가 대중적으로 누구보다도 더 유명했기 때문입니다. 래플리(A.G Lafley)는 P&G 에 입사해서 30년 동안 근무하고 10년동안 CEO 로 재직했다가 최근 은퇴했습니다. 잡스처럼 굴곡이 많고 스토리가 많지 않지만 그는 정말 훌륭한 혁신가 입니다. '좋은 기업에서 위대한 기업으로'..

http://attractivechaos.github.com/plb/ 위 주소가 원문이 있는 사이트고 저는 거기서 그림만 가져왔습니다. 사이트의 내용은 각기 어떠한 기준으로 테스트를 하는지에 관한 설명이 있습니다. 그렇지만 역시 그림을 보는것이 편하겠지요? 몇가지 특이할만한 사항이 있습니다. 1. 자바 (Java) 무지 빨라졌습니다. 2. 제이루비 (JRuby)는 자바 버프 빨인지 무지하게 빠릅니다. 심지어 오리지널 루비보다 빨라 보입니다. 3. 자이썬 (Jython)은 다만 자바 버프를 못 받았는지 많이 느린것 처럼 보입니다. 4. V8:JS 의 속도를 보십시오!! 이걸 보니 Node.js 가 대체 얼만큼 빠른것인지 알 수가 있습니다. Node.js 에서 쓰이는 자바스크립트(Javascript)는 언어..

by Scott D. Anthony 혁신을 시대별 형태로 나누고 이제 혁신4.0 의 시대가 열렸다고 말하며, 그것에 관한 사례를 들고 있는 아티클 입니다. 물론 아직 널리 널리 퍼졌다는 이야기는 아니지만, 그러한 성공 사례들이 모여서 앞으로의 혁신 방향을 이끌어 나갈것이라고 예측하는 아티클입니다. 조선비즈에서도 다루어진 적이 있습니다. http://biz.chosun.com/site/data/html_dir/2012/08/31/2012083101362.html 기사 중간에 나오는 HBR 최신호에 나오는 아티클 이라는 것이 바로 이 아티클 입니다. 아티클에서 논하는 혁신의 역사에 대해서 간단하게 정리하자면 혁신의 1.0 외로운 발명가의 시대. 1915년 이전에 발전한 대부분의 중요한 개혁들은 개인에 의해서..