NIPA 소프트웨어 공학센터의 지원으로, Android Application Block이라는 안드로이드 참조 아키텍쳐 모델을 만들었습니다 .
컨퍼런스를 통해서 먼저 소개하였고, 프리젠테이션을 통해서 안드로이드의 문제를 해결할때 필요한 여러 오픈소스들을 설명해 드렸습니다. (재미난 것은 외국에서도 Android Bootstrap이라는 형태로 기존 Android의 문제를 해결하기 위해 여러 오픈소스를 묶어 제공을 했고, 안드로이드 개발자에게는 꽤 인기가 좋은 것으로 알고 있습니다. )
이 버전보다 더욱 업데이트된 모바일 참조 아키텍처 (안드로이드) 를 발간 하였습니다. (링크를 통해 다운 받으시면 됩니다 – 소프트웨어 공학센터에 이메일 가입이 필요합니다)
안드로이드 어플리케이션 블록 아키텍처
기존의 안드로이드의 구조(젤리 빈 기준)는 진성주 군과 분석하여 정리해보았습니다 (이 링크를 클릭하시면 됩니다).
그리고 저희가 몇가지 오픈소스들을 더해서 아래와 같이 추가된 모델을 만들었습니다. 새로 추가된 오픈소스가 기존의 어떤 안드로이드 패키지와 연관이 있는지 색깔을 입혀 표현을 하였습니다.
지앤선에서 진행한 “아키텍트가 알아야 할 97가지 Face 2 Face ” 행사가 성공적으로 마쳤습니다. 독자들과 한발짝 다가가서 더 많은 이야기를 나눌수 있어서 좋았습니다. 아래와 같은 주제들을 60분간 나누었습니다. 소프트웨어 아키텍트가 알아야 할 97가지 어떤 책인가? 아키텍트는 신기술에 대한 이해가 필수적인데 어떻게 기술을 접하고 있나요 국내에서 아키텍트가 되는 법 아키텍트는 코딩을 잘 해야 한다. 기획자로 일하는 것이 […]
첫번째 세션인데도 불구하고, 많은 분들이 서서 들으실 정도로 참여해 주셔서 정말 감사합니다 . 많은 분들에게 도움이 되길 바라구요. 슬라이드 쉐어에 공유를 해 놓았고, pptx를 다운 받으실 수 있게 해 놓았습니다. 이번 발표에는 다음과 같은 내용을 다루었습니다 오픈소스의 역사및 현재 이야기 라이센스 변화에 따른 에셋으로써 오픈소스 안드로이드의 로그 문제 해결 – Logdog 구현 이야기 오픈소스 […]
12월 14일 소프트웨어 아키텍트 컨퍼런스에 발표를 합니다.
저를 포함해 알람몬의 개발을 지휘하는 CTO 강진석 님, 그리고 요즘 이슈가 되는 BaaS의 전문가 진성주 PD 님과 함께 80분간 재미난 이야기들을 전달해 드릴 겁니다. 저보다 훨씬 대단한 2분이랑 같이 해서 마음이 무겁네요. 재미난 쇼가 되어야 할거 같아요.
주제는 Android OpenSource Application Block 입니다. 안드로이드 개발시 필요한 여러 에셋들을 소개하는 세션이 될거 같습니다. 슬라이드 쉐어에서 많은 트래픽을 받았던 안드로이드를 개발자를 위한 오픈소스 이야기 보다 더 풍성한 내용으로 설명을 드릴겁니다.
상세한 주제는 아래와 같습니다.
97가지 시리즈 (아키텍트, 프로젝트 관리자, 프로그래머) 를 한 자리에 만나는 세미나를 마련해 볼려고 했으나.
이미 97 아키텍트는 여러 번 해서, facebook open source 프로젝트를 전 발표를 대신하고, 나머지 두 역자분이 프로젝트 관리자, 프로그래머의 핵심들을 발표해 주실거 같습니다.
저 역시 이직을 한 이후 처음의 세미나이기 때문에 마음이 무겁기도 하고, 설레이기도 합니다.
유명한 아키텍트이신 김동열 소장님과 오픈 소스 전문가 이신 분을 섭외해서 진행하는 행사인 만큼, 많은 참여 바랍니다.
세미나 신청 하는 곳 : 링크
드디어 또 하나의 작품이 출간되었습니다.
아키텍트가 가 알아야 할 97가지에 이어 프로그래머가 알아야 할 97가지가 드디어 출간되었습니다.
여러 지인들이 의기투합해서 만든 작품으로, 오랜 시간이 걸려 드디어 빛을 보게 되었습니다. 정말 많은 분들이 고생을 해주셨구요. 10명이 넘게 번역 작업을 하느라 정말 고생이 많았습니다. :
특히 일정한 퀄리티가 나오도록 어려번 검수를 해주시느라 고생해 주신, 김수현 , 최현미 두 역자님에게 정말 감사드립니다.
저보다 더 많은 노력을 해주셔서, 최종 검수때 많이 편했습니다. 정말 두 분에게 고개 숙여 감사드립니다. 어떻게 보면 두 분의 이름이 1,2 역자로 먼저 나와야 하는데, 겸손하게 저에게 1역자를 주셔셔, 책임감이 크게 느껴집니다.
또한 베타리더 분들에게도 정말 감사드립니다. 오역을 많이 다듬어 주시고, 좀더 쉬운 용어로 바꾸는 작업을 해주셔서 이 분들이 아니였으면 정말 더 오래 걸렸을거 같습니다.
이전 소프트웨어 아키텍트가 알아야 할 97가지 보다 좀더 개발자에게 와 닿고 가슴을 적실 선배들의 조언들이 듬뿍 담겨 있습니다. 업계 최고의 아키텍트, 프로그래머, Agile 전문가들이 경험에 기반한 조언들입니다.
또한 특별 부록으로, 원서에는 없는 한국의 유명한 프로그래머들의 추가 에피소드가 실려 있습니다.
지난 주말 (2012년 5월 20일) 코엑스에서 스마트 개발자 협회가 주관하는 글로벌 커뮤니티 써밋에 EVA 커뮤니티 연사로 발표를 했습니다.
먼저 이번 발표에 많은 도움을 준 소프트웨어 마에스트로 멘티인 오유환, 강미경, 김나래, 손윤정 4 멘티에게 감사드립니다. 이 4명이 아니였다면 이러한 좋은 자료는 나오지 못했을 겁니다.
프리젠테이션이 다루는 내용은 다음과 같습니다.
Android 이해
- 구글이 꿈꾸는 Android의 미래 (Modu 사 특허 인수와 Android@Home)
- Binder ( Broker 패턴 )과 Intent
오픈소스 그리고 사례
- Simple Framework
- Logcat보다 Microlog4Android
- 불편하지 않은 화면 갱신 (Publisher-Subscriber)
분석 방법
- Localytics로 사용자 행동 패턴 분석
- STAN을 이용한 Android App 분석방법
이번 발표는 소프트웨어 마에스트로 멘토로 활동하면서, 멘티들과 같이 만들어 낸 작품입니다. 비록 여러가지 상황(취업, 학업등)으로 모든 멘티가 다 2단계에 진출은 하지 못했지만, 지금도 열정을 내뿜으며 같이 성과를 만들어내고 좋은 팀웍을 유지하고 있습니다.
지표란 직접 경험을 하지 않아도 현재의 상황을 알수 있는 도구를 말합니다. 옛날 제주도에서는 식수가 귀해 빗물을 식수로 사용을 했습니다. 빗물의 오염도를 파악하기 위한 지표로, 개구리 (숫놈끼리만 넣거나, 암놈끼리만 넣거나)들을 넣었다고 합니다.
개구리 들이 벌레들을 잡아먹어 물이 항상 청결한 상태를 유지할 수 있었으며, 또한 개구리의 생존 여부로 물 오염도를 파악을 할수 있기 때문입니다.
일전에 소프트웨어 품질을 판단하는 지표로, 1000 피트의 뷰 라는 글을 소개해 드렸습니다. 너무 상세하지도 않고, 너무 추상화되어 있지도 않은 그 사이의 뷰를 1000 피트의 뷰라고 불렀습니다.
이러한 지표중 하나로, 예전 저의 포스트에서 Dependency Structure Matrix (DSM) 을 소개해 드렸습니다.
이번 포스트는 이러한 연장선상으로 Clean Code로 유명하신 Robert C. Martin (줄여서 Uncle. Bob)님이 만드신 Instability/Abstractness Graph 하나를 설명해 드리고자 합니다. (이 그래프에 대해 국내에 명확하게 소개된 자료가 없어서, 꼭 여러분에게 공유를 해드릴려고 합니다. )
이 포스트를 읽기 이전에 Bob 삼촌이 발표하신 패키지 구조의 원칙들(Principles of Package Architecture) 을 읽어보시거나, 또는 저의 이전 포스트인 Dependency를 관리하는 방안 을 읽어보시길 바랍니다.
Uncle Bob의 지표는 Instability와 Abstractness 두 개에 대해 이해를 하셔야 합니다. 물론 여기에 추가적인 지표를 더한 변종(Variant) 들도 있지만, 이 두 가지 개념을 확실히 이해하실 필요가 있습니다.
여러분이 프로그래머라면, 여러분의 관리자나 동료 또는 사용자에게 지금 하고 있는 업무의 예측 결과를 알려 주어야 합니다. 그렇게 해야 그들이 목적을 달성하는 데 필요한 시간, 비용, 기술 등을 정확하게 이해할 것입니다.
정확히 예측하려면 예측에 대한 기술을 배우는 것이 가장 중요합니다. 첫째로, 예측이란 무엇이고, 그것이 어떻게 사용되는지 배워야 합니다. 이상하게 들릴 수 있겠지만, 많은 프로그래머와 프로젝트 관리자들이 예측이 무엇인지 정확히 알고 있지 못합니다.
다음에 나오는 프로그래머와 프로젝트 관리자의 대화는 전혀 이상한 것이 아닙니다.
- 프로젝트 관리자: 이 기능을 개발하는 데 얼마나 걸릴까요?
- 프로그래머: 한 달이면 됩니다.
- 프로젝트 관리자: 너무 길어요. 일주일 안에 완료해야 합니다.
- 프로그래머: 적어도 3주는 필요할 것 같은데요.
- 프로젝트 관리자: 2주까지는 시간을 드릴 수 있을 것 같습니다.
- 프로그래머: 네, 좋습니다. 2주로 하죠.
프로그래머는 결국 프로젝트 관리자가 만족하는 선에 맞춰 예측하고 있습니다. 하지만 이것은 프로그래머가 예측치를 제공한 것이기 때문에 프로젝트 관리자는 프로그래머
에게 책임을 전가할 것입니다. 이 대화에서 무엇이 잘못되었는지 파악하려면 예측, 목표, 커밋먼트라는 세 단어를 정의해야 합니다.
Architecture 101 
