mongodb가 혜성처럼 등장해 많은 사랑을 받은 이유가 여러가지 있다.  가장 큰 덕은 모바일의 폭발적인 성장이지만, 개발자에게는..

  • auto-sharding
  • schemaless + json 데이터 저장
  • 자체적으로 가지고 있는 master-slave  high availability 기능

정도 되지 않을까 생각한다.

sharding이라는 것은 꽤 귀찮은 작업으로 어떻게 데이터를 분배해야 할지 많은 고민을 해야 되는데, 굳이 크게 고민하지 않고 auto-sharding을 쓸수 있는 적당한 규모의 프로젝트라면 마다할 필요가 없다.

또한 High Availiability를 자체적으로 지원을 하는데

replica-set-primary-with-secondary-and-arbiter1) 별도의  watcher인  arbiter 를 셋업하여 master-slave를 감시하는 방법

replica-set-primary-with-two-secondaries2) watcher없이 master-slave가 서로 heartbeat 메세지를 보내고 문제를 감지해 failover를 처리하는 방법

이렇게 두가지를 지원한다.  개발자에게는 야호하고 소리를 지를수 있는 좋은기능! (단 죽은 master를 어떻게 살리지는 개발자 여러분의 몫 – 좋은 방법이 있으면 공유를…)

계속 읽기

안드로이드 개발시 Eclipse에서 Android Studio로 넘어가는 하나의 허들이 Memory 분석 툴이었는데. Android Studio 가 이에 대한 해답을 가지고 왔습니다.

안드로이드 스튜디오가 Memory 관련 프로파일러들을 잔뜩 추가/업데이트를 했습니다.

기존에 command 명령어를 좀더 시각적으로 보여주고,  이클립스 플러그인 MAT에서 볼수 있는 내용을 좀더 보기 편하게 만들었다고 생각이 듭니다.

Memory Monitor 

Memory Monitor

디테일한 메모리 분석용이라기 보다는 앱을 실행시키면서 메모리가 갑자기 튀어 오른다음. 특정 시간이 지나도록 감소하지 않는 등과 같이 큰 흐름을 판단하기 좋은 도구 입니다.  모든 시나리오를 상세하기 일일이 heap dump를 떠 가며 분석하는 것은 큰 비용이 드는 일입니다.

핵심 시나리오나, Crash Report로 보고된 에러중 Out Of Memory등으로 보고된 에러들을 다시 한번 이 툴로 가볍게 검증해 보시길 바랍니다.  이렇게 말씀 드리는 이유는 이러한 에러가 특정 디바이스나 특정 OS에서만 나는 경우가 있기 때문에 가볍게 상황을 판단하실때 쓰라는 말씀 입니다.

계속 읽기

Android Studio 1.0 버전이 정식 릴리즈 되면서, 많은 편의성들이 강화 되었습니다.

이미 안드로이드 개발에 40%가 Eclipse , 30% 정도가 Android Studio로 개발을 하고 있고, Google 공식적으로 Eclipse ADT Plugin을 개발하지 않을 거라는 이야기에 이미 대세는 Android Studio로 넘어갔다고 볼수 있습니다.

제가 오랫동안 Android Studio로 넘어가지 못한 이유중에 하나인 MAT (Memory Analyzer) 가 크게 작동을 하였는데요.  1.0을 설치하고 모든 개발 환경을 Android Studio로 이관중  Heam Dump 분석에 문제가 생겼습니다.

MAT 화면

안드로이드 개발시 가장 많이 만나는 두가지 크래시인 NPE 와 OOM중 Out Of Memory를 잡기 위해 사용하는 유일한 도구라 할수 있는  MAT가 Android Studio에서 만든 hprof (heam dump) 파일을 분석하지 못하는 문제가 발생한 것입니다.  (Eclipse 같은 경우는  dump만 뜨면 자동으로 MAT를 뛰우며 분석 화면을 뛰워줍니다.)

계속 읽기

좋은 사람, 등을 맡길수 있는 동료랑 같이 일할수 있다면 얼마나 행복할까.. 많은 생각이 드는 시기입니다. 이들과 동고동락하여 성공을 맞보고, 믿음이 생기면,  얼마나 행복할까 잠시 꿈을 꾸기도 했습니다.. 또한 요즘 제가 겪는 여러가지 일들이,  내부의 동료를 신뢰하다 보니, 그들의 일방적인 의견만 들어 프레임효과에 갇혀 외부에 올바른 시그널을 듣지 못한다는 것입니다.   이 사이에 적절한 중용을 찾는것 […]

안드로이드에서 종종 만나는 문제가   NullPointer Exception이며 또 하나는 OOM (Out Of Memory) 입니다. Crash Report 서비스인 UrQA ( http://www.urqa.io) 를 운영하면서 많은 문제들을 볼수 있습니다. 하지만 위 두 문제는 모든 앱이 다 겪고 있는 문제죠. (현재 URQA는 300개가 넘는 업체가 사용하고 있으며, 안드로이드 뿐만 아니라 곧 iOS, Unity, JS를 지원하게 됩니다. 내부 테스트 중입니다)

 

이러한 문제를 어떻게 해결할까? 에 대해 해당 디바이스를 직접 구하지 않는 한 답은 없지만, 개발자 선에서 해결할수 있는 방법이 Profiler가 아닐까 생각이 듭니다. 하지만 안드로이드 Profiler는 처음 접하기에 러닝 커브가 좀 있고,  이것들을 어떻게 활용하는지 많은 분들이 잘 모릅니다.

또한 안드로이드 OOM (Out of Memory)의 주 원인인 BITMAP. 이것을 어떻게 다루는 것이 좋은지 안드로이드 개발자 사이트에 있으나, 그 밑단에 많은 개념들을 숙지하고 있어야 합니다.

  • JVM과 다른 Dalvik 의 메모리 관리 기법
  • 다양한 Reference를 사용하여, Garbage Collection 시 불 필요한 리소스를  빠르게 수거하는 방법
  • 그리고 Heap Dump를 이해하기 위해 MAT라는 툴을 사용해야 하는데 보는 방법

이 외에도 많은 숨겨진 지식들이 있어야 Profiler를 제대로 활용할수 잇고,  그 문제에 대한 해결책을 찾아갈수 있습니다.

계속 읽기

TDD

꽤 진부하면서도, 논쟁거리가 될수도 있지만, 개인적인 경험과 고민 끝에 글을 나누고자 한다. 꽤 스타트업을 기술적, 아키텍팅 쪽을 컨설팅하면서 지켜보아 왔던 경험치를 가지고 말씀 드리는 겁니다.  (물론 삼성이라는 대기업만 다닌 니가 스타트업을 얼마나 잘 알아? 라고 물어보실수 있지만 말랑 스튜디오, 빙글, 이노피아 테크 등 꽤 많은 업체들을 컨설팅하고 이야기를 나누고, 그들을 지켜보온 경험치라고 생각을 해주시면 될듯 합니다)

개발자들에게 TDD의 도입을  물으면 찬반이 매우 명확한 편입니다. 특히 큰 규모의 라이브 시스템을 운영한  웹 개발자 분들은 TDD를 통해 조기에 많은 문제를 잡고, 찐한 경험 이야기를 해주십니다. 100%로 동의합니다. 많은 유저들이 동시에 모여서 나가는 서비스라면 품질이 매우 중요해지고,  돌다리도 두들기고 건너가는 것이 맞습니다.  큰 웹서비스를 경험하신 분 입장에서는 TDD 가 큰 보험이 되며, 그 다음 Step을 넘어가는 좋은 보험이 되죠.

은총알은 없다.

특정 방법론, 전략이 A 상황에서는 좋은 약이 될수 있지만, 모든 상황에  항상 옳다고 할수 있을까요?

어떤 방법론이든, 기법이든 항상 장단이 있습니다. 전달을 할때 꽤 신중하게 전달을 해야 한다고 봅니다. “TDD는 좋다!” , “내가 해본 경험으로서는 정말 보험이 되고 든든한 녀석이다!!”  라고 말을 하지만, 모든 상황에서 적절한 방법인지는 정말 고민을 해봐야 합니다. 정말 크게 이슈가 되었던 Joel과 Bob 삼촌의 TDD 논쟁 사건을 보더라도, Joel쪽에 공감하는 사람도 제법있습니다.  이 논쟁에서 Bob 삼촌의 이야기를 지지하는 사람도 있지만, 아닌 사람도 꽤 많다는 것이죠..

정말 공감가는 글이 있는데,  바로 TDD역시 비용의 문제라는 것이다.  미물님께써 적은신 글을 보고 크게 공감을 하고 있습니다.   바로 비용이라는 측면에서 바라보아야 한다는 것입니다. 또한 지금 xper 에서 논의되고 있는 “TDD 는 죽었다.”  라는 글을 보면 공감할 부분이 꽤 있습니다.

계속 읽기

소마에 멘티들과 지난 몇개월 동안 재미난 프로젝트를 진행했습니다.

조재우, 노성현, 윤강호, 박종훈    (사진은 추후 잘 나온걸로 공개하겠습니다.)

안드로이드 테스트 자동화와 프로파일러를 직접 구축한 프로젝트를 진행했습니다. 기획, 개발 총 3달이 걸렸으며, 아직 시장에 바로 나가기에는 좀더 다듬을 필요는 있습니다.

일단 보시죠. 백번 듣는것 보다는 보시는게 더 나을거 같습니다.

기존 프로파일러와 다르게 SaaS 형태로 접근성을 높였으며,  테스트를 쉽게 그리고 프로파일링도 쉽게 만들기 위해 큰 고심을 했습니다. 몇몇 업체를 만나 안드로이트의 동적 분석, 자동화 테스트를 도와 드렸으며, 시행 착오를 겪으면서 조금씩 더 개선하고 있습니다.

계속 읽기

종종 멈춘다거나, 빈번하게 죽는 앱이라면 사용하시지 않겠죠. 그렇다고 전체 개발자중 1인 개발자가 70%인  상황이라. 개발자들의 TDD, Profiling 등을 통해 품질을 검증해서 앱이 나오기는 매우 힘듭니다. 

그래서 아실말한 분은 다 아시겠지만, Android 에는 크래쉬 리포트라는 서비스가 있습니다.  대표적인 것으로 Bugsense , ACRA, Crashlytics 같은 것이 있죠. 품질을 시키기 위해 이러한 서비스를 사용하는 경우가 전체 앱에서 10%정도 밖에 안됩니다.

왜 이러한 서비스를 사용하지 않는 걸가? 그리고 기존 Bugsense , ACRA, Crashlytics같은 서비스들의 불편함은 무얼까 고민을 했습니다. 그래서 만들어진 서비스가 바로 UrQA 입니다 .  초기 서비스에는  양현철, 정승수, 안정원 이 3명이 매우 빠르게 고생해서 만들었습니다.  3개월안에 기획, 구현, 디자인 까지 이 3인방이 끝냈습니다.  소마에 멘티들로 정말 최고의 실력을 가졌고, 세상에 도움이 되는 서비스를 만들었기에 박수를 치고 싶습니다.  한번 보시죠..

등급화, 쉬운 재현,  Native (C언어)를 지원하는 것에 초점을 맞추었고, 오픈소스이며 서비스도 ucloud의 커뮤니티 지원으로 무료로 운영중입니다.

이 서비스를 자랑하고 싶기도 하고, 많은 애용을 말씀 드립니다.  크게 홍보하지 않았지만 100개의 앱이 넘게 저희의 서비스르 무료로 이용하고 있습니다.

계속 읽기

견고한 소프트웨어를 만들기 위해서는 쉽게 변화를 흡수하는 자세가 중요합니다. 흡수하는 아키텍쳐가 아니라. 서로를 걱정하며, 그 변화를 적극적으로 흡수 할려는 자세가 필요하죠.

건강한 조직이라면. 아마 뒤에서 서로의 문제를 이야기 하기 보다는 앞에서 만나 언제든지 서로에게 피드백을 주고  적극적으로 풀어볼려는 시도를 했을 겁니다.  서로의 의견도 깊게 경청하구요.  만약 이렇게 서로 편하게 대화를 할수 없다면, 건강한 조직 문화가 아니겠죠…

Nature of Order와 아키텍쳐 시각화를 정리하는 중에. Roughness – Egoless Programming의 십계명이 눈에 들어와 공유합니다.

  • 자신도 실수 할 수 있다는 것을 이해하고 받아 들일줄 알아야 한다.
  • 너의 프로그램은 너 자신이 아니다.
  • 리뷰의 중요한 것은 문제를 발견하는 것이라는 것을 기억하라. 문제가 발견되어도 당신 개인 문제로 적용하지는 않는다.
  • 아무리 당신이 그것에 대해서 자세히 알아도 세상에는 당신보다 많이 아는 사람이 항상 존재한다.
  • 타인과 상의 없이 코드를 다시 쓰지 마라.
  • 당신보다 지식이 없는 사람이라도, 존중, 인내하는 습관을 길러라.
  • 세상에서 변하지 않는 것은 ‘변화’뿐이다.
  • 심각한 불편과는 싸울 수 없으니, 새로운 도전으로 요구사항, 플랫폼, 도구의 변화를 받아들여라.
  • 권위를 낳는 것은 직함(위치)이 아니라 지식이다. 당신이 믿고 있는 신념과 싸워라. 그러나 패배는 우아하게 받아들이자.
  • 고정관념에서 벗어나야 발전할 수 있다. 타인과 적극적으로 커뮤니케이션하라. 비난한다면 사람이 아니라 코드에게 하라.

계속 읽기

제 3회 AsianPLoP이 열립니다.

가까운 도쿄에서 열리구요. 유명한 패턴 전문가 들을 초청하고, 아시아에 많은 분들과 교류를 할수 있는 좋은 행사입니다.

구체적인 프로그램은 좀더 협의해 봐야 겠지만,  지난 행사에는  아래 두분이 facilitator로 프로그램 전반에 참여해 주셨습니다.

  • AOM (Adaptive Object Model) , Big ball of mud의 저자인 Joe Yoder
  • Refactoring to Patterns의 Joshua Kerivsky

다른 분이 오실수도 있으나, 아마 거의 이급으로 오실거 같아요

또한 여기 제출하신 논문은 ACM 에 자동으로 올라가니, 참고하시구요

  • 일시 : 2014년 3월 5일~8일
  • 장소 : 도쿄 진보초 NII(National Institute of Informatics)

계속 읽기