안드로이드에서 종종 만나는 문제가   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를 제대로 활용할수 잇고,  그 문제에 대한 해결책을 찾아갈수 있습니다.

계속 읽기

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

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

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

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

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

계속 읽기

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

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

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

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

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

계속 읽기

12/13일 미래창조부, NIPA에서 개최한 제 2회 아키텍처 실무자 컨퍼런스에 발표한 자료입니다. 저희 모바일 분과에서 “안드로이드 오픈소스 어플리케이션 블록 2″라는 주제로 발표를 하였습니다. 실제 현업에서 활동하시는 한분 한분을 모아서 만든 자료이므로 많은 안드로이드 개발자에게 도움이 될거리 믿습니다.

어플리케이션 블록

어플리케이션 블록 이라는 것은? 기존 Framework들을 더 쉽게 잘 쓸수 있게 추상화 놓은 Block으로 보시면 됩니다. 하나의 프레임워크에 거대하게 모든 기능을 다 들고 있는게 아니라, 잘 블록화 되어서, 필요한 것만 그때 가져다 쓰는 컨셉이라고 생각하시면 됩니다.  모바일 에서는 다양한 오픈소스를 활용해야 하므로, 어쩔수 없는 상황입니다. 안드로이드에서 Spring 프레임워크가 잘 안 쓰이는 이유도 이거죠. 덩치가 큰 편입니다.

안드로이드는 인기있는 Framework입니다. 하지만 단편화나 폐쇄적인 운영으로, 개발자를 골치아프게 하는 여러 이슈들이 많습니다. 이러한 문제를 해결하기 위해 무수한 오픈소스가 존재중이며, 알람몬, Sleep if you can 을 비롯해, 안드로이드  개발자들이 자주 사용하는 여러 오픈 소스들을 모아서 정리하고 Layer별로 분류후 아키텍처와 사용 방법을 정리해 공유한 자료입니다.

같이 고생을 많이 해 주신 주윤회 님, 오유한 님,   알람몬 팀, 신재명 님 , 진성주 님에게 감사를 드립니다.

계속 읽기

2013년 11월 21일 한,중,일을 대표하는 오픈소스 전문가가 모여 트레이팅 캠프를 엽니다.

장소는 부산  파라다이스 호텔에서 오전 10시부터 시작됩니다.

제가 동북아 오픈소스 포럼의 한국측 WG2 인력양성 분과장이라 소개를 하는 시간을 가지며,  오시는 분은 다음과 같습니다.

  • 한국 : 진성주 ,  Apache Usergrid Committer
  • 중국 : Hui CHENG, Open Stack Board Member
  • 일본 : Yoshiki SIGIURA , NCA Steering Committer

한중일을 대표하는 오픈소스 선수가 직접 여는 캠프이며, 부산 시민 여려분에게도 큰 도움이 될거 같습니다.

경남 지역에 개발자 분들의 많은 참여 바랍니다. :)

신청은 여기에 하시면 됩니다.

계속 읽기

PLoP이 드디어 20주년을 맞이 했습니다.

20주년 행사인 만큼, 초기 패턴을 이끌었던 맴버들이 대거 참석한다는 것이고, 가장 먼저 PLoP 이 열렸던 성지인 Allerton Park에서 열립니다. 책에서 본 그곳에서 책에서나 보는 대가들과 만난다니 기쁘네요.

  • Ralph Johnson
  • Ward Cunningham
  • Rebecca Wirfs_Brock
  • Joseph Yoder
  • Richard Gabriel
  • Joshua Kerivsky

계속 읽기

패턴 저자 : 손영수, 오혜성, 양현철, 정승수

아키텍쳐 시각화 패턴 I 회에서는  아키텍처 시각화 패턴의 전체적인 구조와 구성되는 패턴들의 종류들을 간단히 소개하고, 아키텍처 시각화를 하기 전에 소프트웨어 시스템을 분석하기 위한 기본 요소들인 Domain Level Classifier Pattern과 Class Dependency Classifier Pattern에 대해서 살펴보았다. 2회에서는 시간에는 소프트웨어 시스템의 아키텍처적인 분석에 기본이 되는 다양한 Metric 분석과 관련된 패턴에 대해서 설명하고자 한다

Base Metric Extractor Pattern의 정의

소프트웨어 시스템의 아키텍처를 분석하기 위하여 의존성만을 이용하게 되면 분석의 시야가 좁아 보다 다양한 측면에서의 분석이 힘들어진다. 그리고 의존성만을 시각화한 Chart로는 상호 참조와 같은 아키텍처적인 문제만을 바로 확인할 수 있고 그 외의 소스 코드의 크기나 복잡성 등과 관련된 문제들은 확인할 수 있는 방법이 존재 하지 않는다. 의존성 분석만으로는 파악할 수 있는 아키텍처적인 문제들의 한계가 존재한다. 그렇기 때문에 이를 보완할 수 있는 다른 분석 방법들이 필요하다. 또한 이를 보완할 분석 방법도 매우 직관적이고 명시적으로 분석할 수 있어야 하며, 매우 빠른 시간에 아키텍처를 파악할 수 있어야 한다.

이때 소프트웨어 메트릭이라는 소프트웨어 시스템의 품질을 나타내는 지표를 이용하면 이 문제를 해결할 수 있다. 이 지표는 소프트웨어의 측정 기술을 기반으로 소프트웨어 생명 주기 동안에 소프트웨어의 특징 또는 특성을 객관적이고 과학적인 수치로 정량화한 지표이다. 또한, 다양한 문제점들을 정의하고, 관련된 기초 데이터를 수집하고, 문제점들을 객관적이고 과학적인 수치에 의해 분석하여 다양한 문제점들의 연관 관계 및 해결 방법을 탐색하며, 다양한 문제점들을 종합적으로 해결할 수 있는 문제 분석 프로세스 및 소프트웨어에 대한 지표이다.

이러한 지표들 중에서 품질 향상에 많은 도움을 줄 수 있는  소프트웨어 메트릭의 종류를 크게 4가지가 존재한다.

  • 첫번째로 단순히 패키지, 클래스, 메소드, 필드의 갯수,  코드 라인 수를 나타내는 “Count Metric”,
  • 두번째로 코드내의 순환복잡도, 무거움, 엉킴을 나타내는 “Complexity Metric”,
  • 세번째로 코드 간의 의존성을 나타내는 “Robert C. Martin Metric”,
  • 마지막으로 코드간의 상속을 수치로 나타내는 “Chidamber & Kemerer Metric”

이러한 메트릭을 통해 다음과 같은 이점을 얻을수 있다.

  •  소프트웨어 시스템의 코드를 정량적으로 분석이 가능하다.
  • 소프트웨어 시스템의 품질을 수치화 시키기 때문에 객관적인 분석이 가능하다.
  • 소프트웨어 시스템의 문제를 직관적으로 파악할 수 있다.
  • 소프트웨어 시스템을 다양한 시각으로 분석할 수 있게 된다.

계속 읽기

champ poster

오랜만에 지방에 강의를 하러 내려갔습니다.  강의 비용은 서울에 비해 많이 적은 편이며, 이동 시간과 차비 그리고 하루를 꼬박 다 날려야 하기 때문에. 금액만 보면 솔직히 지방에 가기란 쉽지가 않습니다.

하지만 전 지방은 찾아 내려가는 편입니다. 저 역시 고향이 부산이라, 지방 개발자의 서러움을 잘 알고 있기 때문입니다. 소마에 과정에 만난 제자이며, 청출어람이라고 평할수 있는 고액 수입자인 Sleep if you can의 신재명 대표님과 같이 내려갔습니다. 먼길을 마다않고 같이 가준 신재명 대표에게도 정말 감사하구요.

도착을 하자 마자 깜짝 놀랐습니다.  현수막과 포스터까지 곳곳에 부쳐져 있었거든요.. 참 예전 생각이 많이 났습니다.  지방 에서 무엇을 하겠다고 깔짝 거리는 시절.  아는것도 없으면서 잘난체 하고, 정보를 몰라 좌절하는 옛날 기억들이 났습니다.

계속 읽기


패턴 저자 : 손영수, 오혜성, 양현철, 정승수 

소프트웨어 시스템에 있어서 아키텍처는 소프트웨어의 개발이 진행 되면서 지속적으로 성장해 나가며, 고객의 다양한 요구 사항들을 수용할 수 있도록 변화에 대응할 수 있어야만 한다.  높은 품질을 가지는 소프트웨어 시스템을 개발하기 위해서는 계속 진화하는 소프트웨어 시스템의 아키텍처를 실시간으로 확인할 수 있어야 한다. 그러나 현재 알려진 기본적인 방법들로는 이러한 아키텍처 파악이 매우 힘든 것이 현실이다. 그래서 이번에는 소프트웨어 시스템의 아키텍처를 시각화 할 수 있는 다양한 방법들을 패턴으로서 이야기 하고자 한다.

소프트웨어 시스템의 아키텍처는 다양한 사람들이 참여하여 개발하게 되면 처음 의도와는 다른 방향으로 바뀌어질 가능성이 존재하며, 이에 따라서 원치 않았던 잠재적인 아키텍처의 문제들이 발생하거나 추후 확장 가능한 유연한 아키텍처에서 멀어지는 상황이 발생하게 된다. 이러한 상황을 방지하려면 개발을 진행하고 있는 소프트웨어 시스템의 아키텍처를 자주 살펴보고 문제가 발생될 수 있는 부분들을 개선해나가야만 한다.

이러한 소프트웨어 시스템의 아키텍처를 파악하기 위한 방법들은 일반적으로 클래스 다이어그램을 분석하거나 소스 코드를 분석하여 파악하는 방법들이 존재한다. 그러나 이러한 방법들은 여러 단점들을 가지고 있는데 클래스 다이어그램을 기반으로 분석하는 방법의 경우 너무 넓은 시점에서 소프트웨어 시스템을 분석하기 때문에 정확한 아키텍처를 파악하기도 힘들며, 아키텍처적인 문제들을 해결하기에는 너무 적은 정보를 제공한다. 그리고 코드 기반 분석은 클래스 다이어그램 기반 분석과는 달리 너무 작은 시점에서 소프트웨어 시스템을 분석하기 때문에 아키텍처를 파악하는 것이 힘들고, 분석하는 것도 너무 많은 시간이 걸리게 된다. 이렇게 기존의 쉽게 접할 수 있는 방법들로는 소프트웨어 시스템의 아키텍처를 파악하기란 매우 어렵다고 할 수 있다.

그래서 여기에서는 소프트웨어 시스템의 아키텍처를 보다 간편하게 분석할 수 있도록 도와주는 아키텍처 시각화 기법들을 패턴으로써 정리하여, 해당 시각화들을 구현하기 위한 기본적인 방법들을 소개하고, 각각의 시각화 패턴을 활용한 분석들의 장점과 단점들을 소개할 것이다.

아키텍처 시각화 패턴을 위한 로드 맵

앞서 이야기 했던 아키텍처 분석 방법들은 소프트웨어 시스템을 너무 넓은 범위에서 보거나, 너무 좁은 범위에서만 보기 때문에 다양한 문제들이 발생 하였다. 그렇기 때문에 적절한 수준에서 소프트웨어 시스템을 바라보게 되면, 앞서 이야기했던 방법들에서는 찾을 수 없었던 문제점들을 바로 확인할 수 있게 된다. 이러한 적절한 수준으로 사용할 수 있는 분석 방법은 바로 소프트웨어 시스템의 다양한 Metric 정보(소프트웨어 시스템에 대한 아키텍처적인 수치 정보)와 구성요소(도메인)들의 의존성을 분석하는 것이다. 이 방법을 이용하게 되면 소프트웨어 시스템의 아키텍처에 대한 정보들과 여러 문제점들을 다양한 수치 정보로서 바로 파악할 수 있게 되며, 의존성 분석을 통해 얻은 정보로는 실제 소프트웨어 시스템의 아키텍처적인 의존성을 보여주기 때문에 아키텍처 분석이 더욱 용이해지고, 상호 참조와 같은 아키텍처적인 문제점을 찾기에 용이해진다.

하지만 이러한 Metric 정보와 소프트웨어 시스템의 도메인들의 의존성을 분석하기만 하여서는 직관적이고 명시적인 분석결과를 얻을 수 없으며, 전체적인 분석 또한 빠른 시간 안에 할 수 없다. 그렇기 때문에 이러한 문제들을 해결하기 위해서는 Metric 정보와 도메인들의 의존성을 분석 정보들을 단순히 제공하는 것이 아닌 정보들을 시각화하여 분석 하고자 하는 사람이 쉽게 이해할 수 있는 다양한 Chart를 활용하는 형태로 분석 결과를 제공 해야만 한다.

이러한 아키텍처 시각화 기법을 사용하게 되면 코드 분석이나 클래스 다이어그램 분석에 비하여, 초기 비용(시각화 환경 구성 등)이 많이 필요하지만, 소프트웨어 시스템의 아키텍처를 보다 빠르게 분석할 수 있게 되며 잠재적인 아키텍처적인 문제점들을 미리 예방할 수 있도록 도와주며, 더 나아가 아키텍처를 확장 가능한 아키텍처로 유지할 수 있도록 도와주어, 고객의 요구 사항에 쉽게 대응할 수 있도록 해주게 된다.

이러한 형태로 아키텍처 시각화를 구축하기 위해서는 다음과 같이 패턴들을 적용해야 한다.

  • 가)   Domain Level Classifier 패턴을 기반으로 소프트웨어 시스템의 도메인들을 분류한다.
  • 나)   Class Relationship Classifier 패턴을 기반으로 분류된 도메인들 간의 객체 지향적인 의존성들을 모두 분류한다.
  • 다)   분류된 도메인들과 객체 지향적인 의존성들을 정보들을 바탕으로 Base Metric Extractor 패턴을 활용하여 소프트웨어 시스템의 품질에 관한 Metric 정보들을 추출한다.
  • 라)   구성된 Metric 정보와 의존성 정보들을 바탕으로 아키텍처 시각화(Dependency Chart 패턴, Size of Component Chart 패턴, Robert C Martin Chart 패턴, Pollution Chart 패턴)를 표현한다.
그림1. 소프트웨어 시각화를 위한 패턴언어

그림1. 소프트웨어 시각화를 위한 패턴언어

<그림 1>은 위에서 소개한 절차를 바탕으로 아키텍처 시각화 패턴을 구성하는 다양한 패턴들간의 관계들을 표현한 패턴 구성도(패턴 맵)이다. 앞으로 시각화 패턴을 구축하는 하위 패턴들부터 시작하여, 구체적인 아키텍처 시각화 방법들이 담긴 패턴들을 소개하는 일종의 하향식 접근을 통해 아키텍처 시각화 패턴에 대해서 이야기 하겠다. 추가적으로 여기에서는 설명을 보다 쉽게 하기 위해서 객체 지향 언어 중 Java을 기반으로 예제들을 설명하겠다.

계속 읽기

may2010-2x3릴리즈 및 설치 프로세스에 대한 디버깅이 프로젝트가 종료되는 시점까지도 진행되지 못하는 경우가 많습니다. 어떤 프로젝트에서는 설치도구를 작성하는 일이 릴리즈 엔지니어에게‘필요악’으로 주어집니다. 리뷰나 데모는 모든 것이 잘 동작함을 보장하기 위해 수작업으로 수행하는 경우가 많습니다. 결과적으로 팀은 너무 늦어서 변경하지 못할때까지도 릴리즈 프로세스 및 릴리즈하는 환경을 경험하지 못합니다.

설치/릴리즈 프로세스는 첫 번째로 고객에게 보여지는 것입니다. 단순한 설치/릴리즈 프로세스는 신뢰할 만한(또는 최소한 디버깅하기 쉬운) 동작 환경을 갖는 첫 단계입니다. 릴리즈된 소프트웨어는 고객이 사용하는 것입니다. 릴리즈된 프로그램이 올바르게 설치되는 것을 보장할 수 없다면, 여러분은 제대로 소프트웨어를 사용하지 못한 고객으로부터 많은 질문을 받게 될 것입니다.

설치 프로세스가 있는 프로젝트로 시작하면 제품 개발 주기 동안 프로세스를 발전시킬수 있는 시간을 벌 뿐만 아니라, 설치를 좀 더 쉽게 할 수 있도록 애플리케이션 코드를 변경할 수 있는 기회를 얻게 됩니다. 설치 프로세스를 주기적으로 수행하고 테스트함으로써 여러분이 작성한 코드가 개발 환경이나 테스트 환경뿐 아니라 사용자의 환경에서도 동작한다는 것을 확인할 수 있습니다.

계속 읽기