2014년 2월 21일 금요일

support v4 library 사용 중 PreferenceFragment를 FragmentPagerAdapter 추가 시 문제점

하위 기기 호환을 위해서 android support v4 library
(http://developer.android.com/tools/support-library/index.html)를 사용하여
fragment들을 사용, 관리하고 있는 중에
preference fragment를 fragmentPagerAdapter에 추가 시 문제가 발생함.

android.support.v4.app.FragmentPagerAdapter 에서는
android.support.v4.app.Fragment 를 처리하고 있어
android.app.Fragment를 상속받은 PreferenceFragment을
v4.appFragment로 처리 할 수 없음.

좀 찾아봤으나 어쩔 수 없이 v13 library를 사용하는 것으로 마무리..
더 찾기도 귀찮음.

http://stackoverflow.com/questions/15845632/adding-preferencefragment-to-fragmentpageradapter

This answer led me to the solution of using the v13 support library, which includes a FragmentPagerAdapter that uses bona-fide android.app.Fragments so it can support the PreferenceFragment.
Assuming you use Eclipse and run the new app wizard with the "Scrollable Tabs + Swipe" Navigation (which gives you the v4 pager boilerplate), here are the modifications you need to make to upgrade to v13:
  • Delete "android-support-v4.jar" file from your libs folder
  • Copy "android-support-v13.jar" from SDK_PATH\extras\android\support\v13; if it's not there, use the SDK manager to install or update "Extras/Android Support Library"
Then, in the Java file:
  • Change FragmentPagerAdapter import from v4 to v13
  • Change FragmentActivity to a plain Activity
  • Change calls to getSupportFragmentManager to getFragmentManager
  • Import all necessary classes from android.app instead of android.support.v4
  • (Except: you still need to use the v4 ViewPager, but it's compatible)
I've copied the modified source below, verified on latest Jellybean.

코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기


코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기 : 엉터리 개발자에서 벗어나 진정한 개발자로 거듭나라! 제프 앳우드 저/임백준 역 | 위키북스 | 원제 : How to Stop Sucking and Be Awesome Instead (Hyperink)

이전 코딩 호러의 이펙티브 프로그래밍(http://imhallower.blog.me/90178246899)을 읽고
재미있는 충고들이 많아서 다음 책도 보게 되었음.
비록 오래된 블로그글들을 모아서 책으로 정리한 것이겠지만 나같이 귀찮은 사람들에게는 한꺼번에 몰아서 보기에 도움이 된다.

주요 chapter는 다음과 같다. 
1부 쓸데없는 일을 줄이는 법
2부 프로그래밍
3부 웹 디자인의 원칙
4부 테스트
5부 당신의 사용자를 알라

6부 우리가 관심을 둬야 할 것들
7부 게이밍

8불 읽어볼 만한 내용

보시다시피 책의 부제는 "엉터리 개발자에서 벗어나 진정한 개발자로 거듭나라" 이고 관련된 내용을 정리하였지만
전 책에 비해 각 챕터별 주제와 글들이 좀 탄탄하지 못하고 걸러낸 글들을 모아서 주제를 이래저래 맞춘것 같다.
내용면에서는 좀 실망이다. 3,4,5 챕터는 그냥 감흥없이 읽어 버렸다. 다만 마지막 챕터는 흥미를 끌었음.
아래에서 관심 글들을 정리하니 reference하는 책들이나 article이 어마어마하다....

아래는 읽으면서 개인적으로 해당되거나 동감이 가는 충고들을 정리한 내용과 개인 의견이다.

1부 쓸데없는 일을 줄이는 법

당신이 매일 아침 일어날 때, 신이 제작한 완벽하게 독창적인 장치인 유기적인 두뇌를 이용해 그날 해야 할 가장 중요한 일 세 가지를 떠올릴 수 없다면 그 상황을 진지하게 개선할 필요가 있다.
당신에게 중요한 일이 무엇이고, 무엇이 당신에게 동기를 부여하는지 알아내야 한다는 말이다.
=> 회사에서 뭘 할지 몰라 그냥 무의미하게 흘려 버리는 시간이 있다. 나도 회사도 손해이다....

나는 해마다 '버밍험 감옥으로부터의 편지(Letter from a Birmingham Jail)를 다시 읽는다. 그것이 가장 설득력 있는 에세이라고 생각하기 때문이다.... 당장 읽어보라.
(TODO) => 한번 읽어보자.
때로는 프로젝트 자체가 성공을 거두더라도 당신은 실패하게 되는 경우가 있다. ... 여기에 참여했던 엔지니어들이 모두 궁극적으로 실패를 넘어 생존했을뿐더러 이후에 더 엄청난 성공을 향해 나아가기도 했다는 점이다.... 실패는 놀라운 선생님이다.

당신보다 재능이 있는 개발자가 수천 명 있다는 사실에 기죽지 말라. 당신에게 열정이 있는 데 재능이 무슨 필요란 말인가?
=> 감사하게도 희망을 주는 말이다. 하지만 열정이 그냥 열심은 아니겠지..

- 연습하라, 연습하라, 연습하라!
- 경험과 전문성을 혼동하지 말라.
- 민간풍습을 믿지 말라. 하지만 그것을 배우기는 해라.
- 아무것도 절대적으로 믿지 말라. 자신만의 방법론을 세워야 한다.
- 자가 학습을 주도하라. 아무도 대신 해주지 않는다.
- 명성 = 돈. 스스로의 명성을 구축하고 보호하라.
- 자원, 자료, 도구를 끊임없이 확보하라.
- 자신민의 기준과 도덕률을 확립하라.
- 장인적 기술을 사소한 것으로 만드는 자격증을 피하라.
- 항상 노력하는 동료를 곁에 둬라.
- 쓰고, 말하고, 항상 자신이 보기에 진실인 것만을 발언하라.

(TODO) => 꼭 기억하자.
(TODO) => 읽어보자. 자격증 관련

"실천가를 위한 실용주의 프로젝트 관리: 위대한 관리의 비밀(Behind Closed Doors: Secrets of Great Management)"
(TODO) => 읽어보기, 현재 절판임.

이 소프트웨어 개발자는 자기가 해야 하는 일의 전체 목록을 가지고 있지 않다. 즉, 당당하게 99퍼센트의 일이 완성됐다고 주장하고 있기는 하지만 앞으로 남은 일에 얼마나 더 많은 시간을 쏟아 부어야 할지에 대해서는 전혀 모르고 있다!

=> 저자는 할일을 자세히 나열해 보라라고 말하고 있음.. 하긴 나도 개발 결과를 말할때 대충 다 끝나다고 말을 하지만 이것저것 손볼게 남아 있는게 사실이다. 대략적으로 생각해서 결과를 말하곤 하는데 정량적인 방법을 쓰던 다른 방법을 쓰던 자세히 따져 볼 수 있는 방법을 터득하는게 맞겠다.

Roger Session의 "엔터프라이즈 아키텍처를 향한 더 나은 길(A Better Path to Enterprise Architecture)"




2부 프로그래밍
프로그래밍: 사랑하지 않으면 떠나라.
지난 20여 년 동안 나는 돈을 받으면서 프로그래밍할 자격이 없는 것처럼 보이는 사람들과 일한 경험이 아주 많다. 나는 평균적인 수준의 프로그래머를 말하고 있는 것이다. 우리는 모두 인간이고, 그래서 많은 실수를 범한다.
=> 연차가 좀 되니 자존심을 내려 놓고 끊임없이 배우는 자세가 필요하다..... 하지만 자존심을 내려 놓는 것은 어려운 건 사실이다.

많은 사람들이 자기가 쓴 글에 '낙타는 혹이 두개다 The camel has two humps"라는 학술 논문에 대한 링크를 달고 있다.
(TODO) => 읽어 보자.

최근에 스티븐 예그 Steve Yegge의 방대한 글들을 뒤적이다가, 2005년에 작성된 프로그래밍 훈련하기 Practicing programming라는 글을 읽게 됐다.
(TODO) => 읽어 보자.

코드카타(노력이 담긴 학습을 실천하고 프로그래밍 기술을 연마하는 방법에 해당되는)의 예를 보고 싶다면 스티브가 쓴 글은 탁월한 출발점을 제공한다. 스티브는 그것을 실전 훈련 practice drills 이라고 불렀다.
(TODO) => 위 링크에서 항목들을 반복 읽기

칼 위거스 Karl Wiegers가 쓴 탁월한 책인 "소프트웨어에서의 동료 간 검토: 실전가이드 Peer Review in Software: A Practical Guide"는 2002년 이래로 훌륭한 가이드 역할을 수행해 왔다.
(TODO) => 읽고 정리하기


3부 웹 디자인의 원칙
소프트웨어 프로젝트의 사용성과 관련해서 입문자들을 위한 '물을 끓이는 방법' 수준의 쉬운 글을 읽고 싶다면 이 책을 읽는 것을 중단하고 지금 당장 "스티브 크룩의 사용성 평가, 이렇게 하라! Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Proglems"를 구입해서 읽어보기 바란다.
(TODO) => 빌려서 읽어라.

조엘 스폴스키는 자신의 탁월한 책인 "프로그래머를 위한 사용자 인터페이스 디자인 User Interface Design from Programming"에서 사용성과 학습용이성의 차이를 설명했다.
(TODO) => 읽기

. 그냥 '아니오'라고 말하라.
이런 식의 경험을 하고 나서 많은 소프트웨어 개발자들이 그냥 '아니오'라고 말하라는 원칙을 내면화하게 된다는 생각을 하게 됐다. 양극단의 생각은 모두 위험하다. 하지만 나는 모든 것에 '예'라고 말하라는 원칙이 프로젝트 전체를 실패하게 하는 데 더 큰 위험성을 안고 있다고 생각한다. 둘중에서 어느 한 쪽을 선택해야 한다면 단순함을 추구하는 쪽에 서는 것이 좋다.

5부 사용자를 이해하라

. 개발자에게 UI를 만들게 했을 때 일어나는 일
모든 소프트웨어 개발자의 내면 깊숙한 곳에는 커밍아웃을 기다리는 그래픽 디자이너가 한 명씩 살고 있다. 그 디자이너가 바깥세상으로 나오게 한다면 심각한 문제가 발생한다.
=> 동감이다.. ㅜㅜ , UX, UI, GUI는 디자이너들에게..

게임화 gamification라고도 할 수 있는 이런 방법, 즉 동료를 통한 자극은 정말로 효과가 있다. 하지만 이러한 시스템은 총기류와 같다. 너무나 강력한 힘을 지니고 있어서 그것을 다루는 사람이 방법을 제대로 알고 있지 않으면 위험할 수 있는 것이다.
=> Gamification은 부가적인 기능으로는 매력적이다. 이 책 참고 (http://charlie0301.blogspot.kr/2014/02/gamification.html)

. 반사회적인 사람들을 위한 사회적 소프트웨어 만들기
열 개의 '무시무시한 아이디어', 우리는 이러한 아이디어를 스택 오버플로우를 만들 때 기본요소로 활용했다.
1. 참여를 가로막는 잣대의 수준을 혁신적으로 낮춰라.
2. 사용자들을 (적어도 일부는) 신뢰하라.
3. 우리의 인생 자체가 세계에서 가장 규모가 큰 MMORPG 게임이다.
4. 나쁜 일들은 일어나기 마련이다.
5. 사랑은 금전적 동기보다 우선한다.
6. 규칙은 재미있고 사회적일 수 있다.
7. 현대의 웹사이트 디자인은 모두 게임 디자인이다.
8. 사려 깊은 게임 디자인은 지속 가능한 커뮤니티를 형성한다.
9. 커뮤니티가 항상 옳은 것은 아니다.
10. 약간의 중재는 필요하다.
=> 재미있는 아이디어들 조직에 적용하면 유연하게 만들 수 있지 않을까?


6부 우리가 관심을 둬야 할 것들

.망중립성의 중요성
망중립성은 파일 공유보다 훨씬 더 많은 것을 의미한다. 그런 면에서 팀 우 Tim Wu의 책인 "마스터 스위치: 정보 제국의 흥망과 성쇠 The Master Switch: The Rise and Fall of Information Empires"는 천재적이다.
(TODO) => 읽어 보자.


7부 게이밍

게임 프로그래밍이 이러한 초창기 시절로부터 얼마나 많이 변화했는지에 알고 싶다면 제임스 헤이그의 1997년판 전자책인 "할키온 시절: 고전 컴퓨터와 비디오 게임 프로그래머와의 인터뷰 "Halcyon Days: Interviews with Classic Computer and Video Game Programmers"를 읽어보길 바란다.
(TODO) => 읽어 보자.


8불 읽어볼 만한 내용

. 프로그래머는 책을 읽지 않지만 당신은 읽어야 한다.
=> 몹쓸 기술 서적으로 인해 책을 읽는 것을 피하게 되었지만 좋은 책들을 읽을 때는 경험이 되고 더 깊은 통찰력을 준다고 말함.. 나도 동의하는 바이다. 다만 최신 기술을 습득하기에는 부적합 하지만 단시간에 자신의 경험으로 만들고 다른 방법을 배우는 것에는 효과적이라고 생각한다. 오픈 소스 공부가 최고지만..
(TODO) => 아래 책 읽기
. 코드 컴플리트 2 
. 상식이 통하는 웹 사이트가 성공한다. Don't Make Me Think
. 피플웨어 Peopleware http://charlie0301.blogspot.kr/2014/02/blog-post.html
. 실용주의 프로그래머 Pragmatic Programmer
. 소프트웨어 공학의 사실과 오해 Facts and Fallacies of Software Engineering

앞에서 인용했던 그 사람도 자기계발서 가운데 놀랍게도 5퍼센트에 해당하는 책은 쓰레기가 아니라는 결론을 내릴 수 있었다.
권장하는 책은 "59초: 순식간에 원하는 결과를 끌어 내는 결정적 행동의 비밀"59 Seconds: Think a Little, Change a Lot"
(TODO) => 읽자.

.컴퓨터 범죄, 그 과거와 현재
개과천선한 해커 중 한 명인 케빈 폴슨 Kevin Poulson이 쓴 '킹핀'은 대단히 흥미진진한 독서 경험을 제공한다.
(TODO) => 읽자.

. 사람에게 말을 하는 방법
내가 단지 10페이지 정도만 읽고도 충격을 받을 정도로 도움되는 책이 있음을 깨닫게 된 책이 있다. 당신이 나이가 2세에서 99세 사이에 있는 아이를 다뤄야 하는 입장이라면 지금 당장 가서 "어떤 아이라도 부모의 말 한마디로 훌륭하게 키울 수 있다. How to Talk So kids Will Listen So Kids Will Talk"를 구입하기 바란다. 우리는 이미 이 책을 세 권 가지고 있다. 당신도 읽어야 한다.
(TODO) => 읽자.


. 기본기 다지기: 새루운 튜링 승합차
우리의 CEO인 스콧 스탠필드 Scott Standfield는 고전적인 컴퓨터 공학 퍼즐을 연구하다가 나를 "새로운 튜링 승합차: 66일간의 컴퓨터 공학 여행 The New Turing Omnibus: 66 Excursions in Computer Science"으로 인도 했다. 정말로 믿을 수 없을 정도로 흥미로운 책이다.
(TODO) => 재미 있겠지, 읽자.

2014년 2월 14일 금요일

안드로이드의 Activity 관리 방법 Link 정리

Activity 실행과 관련된 내용들 링크 정리

안드로이드 Service 에서 Activity 를 실행하는 방법|작성자 휴우
http://blog.naver.com/PostView.nhn?blogId=huewu&logNo=110084868855
 > Service에서 Activity를 띄우는 방안

Tasks and Back Stack
: http://developer.android.com/guide/components/tasks-and-back-stack.html
 > Android에서의 Activity 관리에 대한 설명 및 관리 방안, 중요



안드로이드/Android Flag Activity 사용법 및 주의사항 ~!
: http://arabiannight.tistory.com/298
 > Activity 호출 시 사용되는 Flag들 설명


Thread에서 toast 메세지 출력하기
http://stackoverflow.com/questions/3134683/android-toast-in-a-thread
http://stackoverflow.com/questions/18280012/how-to-replace-the-system-out-with-toasts-inside-a-thread/18280318#18280318


Tizen Native Application Programming 대충 정리

아래 내용은 Tizen 2.2 기반이며... 그 이상의 버전에서는 별 의미없는 내용들입니다.

-------------------------------------------------------------

그냥 Tizen SDK document를 보며 정리함.

[Tizen Architecture]
 : https://developer.tizen.org/dev-guide/2.2.1/org.tizen.gettingstarted/html/tizen_overview/tizen_architecture.htm

Tizen architecture

뭐.. Web API, Native API 있다고 보면.. 될듯


[Tizen Native Application Programming]
https://developer.tizen.org/dev-guide/2.2.1/org.tizen.native.appprogramming/html/cover_page.htm

[API reference]
 : https://developer.tizen.org/dev-guide/2.2.1/org.tizen.native.apireference/index.html

[Features]
 : Base
  . database, internatioalization, XML parsing 등
    > Tizen::BaseTizen::Io, and Tizen::Locales namespaces, and in the Libxml2 library.
  . sensors, display, vibrator, power management, device monitoring and event receiving, device analysis
    > Tizen::System

 : Appliation Framework
  . application management (system services, dialer, notification 등 - Tizen::App)

  . Application type
   > 안드로이드와 비슷하게 UI application(UIApp), service applications(ServiceApp) 을 지원함.
  . 소스는 보지 않았지만 아마도 실행 시 life cycle 관리를 위해서 App class에서 자신의 app ID를 넘겨 AppManager에 등록하여 관리하게 하는 것 같음.

app_namespace_classdiagram.png


 : User Interface (UI controls, accessbility- Tizen::Ui Tizen::Uix)

Figure: Tizen native application UI
Tizen native application UI

 : Frame은 Form을 가지고 Form은 full screen container(Ui:Container 상속)로 System UI, 여러 Control들을 포함하고 있음.

 // Creates an instance of Form
    Form* pForm = new Form();
    pForm->Construct(FORM_STYLE_NORMAL| FORM_STYLE_HEADER| FORM_STYLE_FOOTER);

    // Gets a pointer of the frame
    Frame *pFrame = UiApp::GetInstance()->GetAppFrame()->GetFrame();
    pFrame->AddControl(pForm);
    pFrame->SetCurrentForm(pForm);

    // Implements MyActionEventListener
    IActionEventListener* pListener = new MyActionEventListener();

    // Adds a header
    Header * pHeader = GetHeader();
    pHeader->SetTitleText(L"FormSample");

    // Adds a footer
    Footer * pFooter = GetFooter();
    pFooter->SetStyle(FOOTER_STYLE_TAB);
    pFooter->AddActionEventListener(*this);

    // Calls Invalidate() to display the form
    pForm->Invalidate(true)

  . Scene Management
   > 너무 많다.. 모르겠다..
   > https://developer.tizen.org/dev-guide/2.2.1/org.tizen.native.appprogramming/html/guide/ui/scene_management.htm

ui_scenes_namespace_classdiagram.png

 : Communication (3G, Wi-Fi, BT, HTTP, NFC -  Tizen::Net, SMS, MMS, email -  Tizen::Messaging ,  Tizen::Telephony)
 : Web  Tizen::Web
 : Service features (PIMS- Tizen::Social , content management-Tizen::Content)
 : Security Tizen::Security 
 : Graphics  Tizen::Graphics
 > 나머지들은 일반적인 거라....

[Two-phase Construction]
 : Tizen이 C++에서 제공하는 exception mechanism을 제공하지 않고 생성자에서 exception을 발생시킬 수 없으므로 class 생성 시 제대로 생성되었는지 확인하기 위한 approach
 : 초기화를 한뒤 Construct()를 호출하여 결과값을 확인

// Example 3:  Create CallManager
CallType callType = TYPE_UNDEFINED_CALL;
CallStatus callStatus = CALL_STATUS_UNDEFINED;

CallManager* pCallManager = new CallManager();

// Second-phase of construction must be called once right after instantiation
result r = pCallManager->Construct(*this); 

if (IsFailed(r))
{
   delete pCallManager;

   return r;
}

[Application life-cycle]
Figure: Application life-cycle
Application life-cycle


 : App class의 life-cycle 관련 event들을 override하면 상황에 따라서 app resource들을 처리할 수 있음.
virtual bool OnAppInitialized (void)
virtual bool OnAppInitializing (AppRegistry &appRegistry)=0
virtual bool OnAppTerminating (AppRegistry &appRegistry, bool urgentTermination=false)=0
virtual bool OnAppWillTerminate (void)

 : OnAppInitializing()에서 Frame을 추가, OnAppTerminating()에서 Frame 제거
  . 근데 Tizen SDK의 UI application에서는 OnAppInitialized()에서 Frame을 등록하고 있음..
 : Application 실행은 Process Manager가 필요한 library와 app executable을 메모리에 등록하고 OspMain()을 호출한다.

Launching UI applications

[App Control]
 : 다른 Application에서 특정 operation을 요청하는 방법, android intent의 목적과 유사.
    using namespace Tizen::App;

    void
    MyAppClass::AppControlDialSample(void)
    {

        String telUri = L"tel:12345678900";

        AppControl* pAc = AppManager::FindAppControlN(L"tizen.phone", L"http://tizen.org/appcontrol/operation/dial");
        if(pAc)
        {
            pAc->Start(&telUri, null, null, null);
            delete pAc;
        }
    }
 : App Control을 사용하기 위해서는 target application의 Application ID와 operation ID가 필요
 : app control 시작과 결과 전달은 IAppControlResponseListener interface 사용

Launching an application with an AppControl

 : Tizen paltform application의 app control
  > https://developer.tizen.org/dev-guide/2.2.1/org.tizen.native.appprogramming/html/guide/app/platform_appcontrols.htm

[UI application's frame]
 : UI application은 top-level main window인 frame이라는 것을 가지고 있음
 : 아래는 frame의 state transition chart.
 : 당연한 거지만 Deactivated라던지 Minimized될 경우는 resource management 필요

Figure: Frame state transition
Frame state transition

[메모리 부족 시]
 : OnAppCheckpointing (AppRegistry &appRegistry) 호출 후 아래 우선 순위로 종료 시킴
  1.    Background UI applications
  2.    Service applications
  3.    Background media players
  4.    Foreground UI application
  5.    Foreground media player
  6.    Application launcher
  7.    Voice or video call, or other system applications

[기타 참고링크]
Tizen App development : Troubleshooting by mygony
http://mygony.com/archives/4276

2014년 2월 13일 목요일

조직문화 관련 찾아본 것들

조직문화 관련 주서들은 것을 찾아봄.

[밸브사신입사원가이드]
 : http://pds22.egloos.com/pds/201208/07/56/Valve_Handbook_LowRes.pdf
 : http://blog.naver.com/PostView.nhn?blogId=yhp8470&logNo=70148407407

- Valve사의 독특한 HR 철학에 대한 가이드. 이런 회사에서 일하면 좋겠다는 생각도 들고 나도 이런 요구사항에 맞는 사람으로 성장해야 어디서나 살아 남을 수 있겠구나 하는 생각도 듬.
- 수평 조직, 카발(Calbals)의 팀 문화를 통한 유기적인 시너지 효과?
- 개인의 성장에 대해 서는 방임적인 편이지만 자발적인 시도를 통해 성장하며 회사에 기여하길 바라며 실패에서 대해서는 관용적인 것으로 보임.
- 다양한 방면의 수준 높은 기술을 가진 사람(제네럴리스트) + 한가지 분야의 최고 기술을 가진 사람(스페셜리스트) 의 조합인 T자형 인간상을 요구.


http://andrewmpace.com/2012/04/24/623/

 : (Half-Life 기획과정, Cabals) http://parkpd.egloos.com/3730476

성공적인 카발을 위한 조언

- 모든 기능 분야(프로그래밍, 아트 등)의 전문가를 하나씩 포함하라. 회의 참석자들 중 아무도 이해 못하는 분야에 대해 서로 논쟁하는 것은 모두의 시간 낭비다. 

- 모든 것을 기록하라. 브레인스토밍은 회의 도중에는 좋지만, 기록되지 않았다면 며칠 안에 당신의 놀라운 의견은 잊혀진다. 게임의 가장 합리적인 부분들에 대해 최대한 설명하고, 사람들이 해야 할 일에 대해 해답을 주는 문서를 제작하는 것을 목표로 하라. 

- 모든 아이디어가 다 훌륭한 것은 아니다. 당신의 아이디어도 여기 포함된다. 모두가 ‘멍청하다’고 여기는 당신만의 ‘훌륭한’ 아이디어가 있다면, 더 이상 밀고 나가지 마라. 다른 사람들도 멍청한 의견을 낼 때가 있다. 당신이 억지를 부린다면, 그들도 억지를 부릴 것이고, 서로 교착상태가 될 뿐이다. 어쩌면 훌륭한 의견이 단지 잘못된 분야에 배치된 것일 수도 있다. 나중에 언급하면 된다. 어차피 게임 플레이 시간이 30시간 이상인 게임을 제작하고 있을 것이다. 정말 버리기 싫은 아이디어라면 게임의 어딘가에는 적용될 수 있을 것이다. 어쩌면 다른 사람들이 다음 달에는 받아들일 지도 모르지 않는가. 

- 이미 작동하거나, 아니면 플레이 테스트 기간 이전에 완성할 수 있는 기술적인 요소들에 대해서만 계획을 짜라. 출시하기 직전에야 준비될 수 있는 기술에 의존하지 마라. 물론 쿨한 기술에 대해 꿈꾸는 것은 좋지만, 완성될 지도 모르고, 출시할 수 없는 수준일 수도 있는 요소들을 중심으로 게임을 기획하는 것은 무의미하다. 실현되지 않는다면 최대한 빨리 없애버려라. 

- 모든 1회용 기술적 요소들을 피하라. 엔지니어링이 요구되는 모든 작업은 게임에서 적어도 두 번 이상 사용되어야 한다. 엔지니어들은 정말 느리다. 그들의 작업은 본래 수개월이 걸린다. 그들이 만들어낸 기술이 1회용으로 사용될 것이라면, 그건 제한적인 자원을 낭비한 셈이다. 엔지니어들의 목표는 언제나, 어디서나 사용될 수 있는 도구와 기능의 제작이어야 한다. 그들이 한 달을 소비해 모두가 생산적일 수 있는 도구를 만든다면, 성공적인 일이다. 1주일을 소비해서 게임 플레이의 10초에 영향을 주었다면, 그것은 낭비다.


[Zappos, 자포스 조직 문화]
 : http://blog.naver.com/PostView.nhn?blogId=rollpie&logNo=60195792676
 : http://health20.kr/1214

- Amazon에서 9.4억 달러로 매입한 온라인 신발 쇼핑 서비스 회사, 최고의 고객 서비스
'사람'을 중심으로 하는 고객 서비스,
고객과 마찬가지로 직원의 목소리에 귀를 기울이고 있으며,
직원의 개성을 존존하고 이 개성들이 모인 팀이 하나의 문화를 형성하고
이 팀들을 통해 기업의 문화가 정의 되는 기업

- 인재상 => 기업문화에 융화할 수 인재, 경력보다 융화력이 우선
- 10대 핵심 가치

1. Deliver WOW Through Service ("와"하는 감탄사가 나올 정도의 서비스를 한다)
2. Embrace and Drive Change (변화를 포용하고 추진한다)
3. Create Fun and Little Weirdness (재미를 창조하고, 이상한 행동은 하지 않는다)
4. Be Adventurous, Creative, and Open-Minded (모험적이고, 창조적이며, 개방적인 마음을 가져라)
5Pursue Growth and Learning (성장과 학습을 추구한다)
6Build Open and Honest Relationships with Communication (소통을 통해 개방되고 정직한 관계를 구축한다)
7Build a Positive Team and Family Spirit (긍정적인 팀과 가족과 같은 관계를 구축한다)
8Do More with Less (적게 일하고, 많은 것을 성취하라)
9Be Passionate and Determined (열정적이고, 결연한 의지를 가져라)
10Be Humble (겸손하라)


[스포티파이 조직문화]
 : http://ko.wikipedia.org/wiki/%EC%8A%A4%ED%8F%AC%ED%8B%B0%ED%8C%8C%EC%9D%B4

Spotify의 조직문화
 : http://selfothercontext.com/2013/02/27/spotify/
  > Squad, Tribe, Chapter, Guild에 대한 상세한 설명

Squad
 . 기본 구성 팀. 스크럼 팀 스타트업 형태. 여러 직군으로 구성. 리더는 없고 Project Owner가 프로젝트 관리. 린스타트업의 MVP방식을 따라 빨리자주 릴리즈. 10% 업무시간을 hack day로 지정

Tribe
 . Squad의 집합. 같은 물리공간에 배치. 사회적 관계 유지를 위해 100명 제한.

Chapter
 . 모든 Tribe 내의 같은 직군의 집합. 정기적 미팅을 통해 교류. Chapter lead 존재.

Guild
 . 공통 관심사의 사람들이 모인 커뮤니티. Guild coordinator 존재.

spotify
 구성원들을 가로/세로로 엮어주는 매트릭스 조직과 매우 유사하긴 하나 결정적인 차이가 있다. 일반적인 매트릭스 조직은 같은 직군을 한 곳에 모아서 일종의 Pool을 구성한 다음, 그 인원들을 프로젝트에 필요한 자원으로 할당하고, 같은 직군의 관리자에게 업무를 보고하고 관리 받는 형태인 경우가 많다.
그러나 Spoify의 조직 구성은 자원의 관리 측면보다는 좋은 제품을 출시하는 방향으로 조직 구성의 지향점을 삼고 있다. 무슨 일을 할 것인가(what)에 대한 문제는 Squad와 Tribe를 통해서 해결하고, 어떻게 하면 잘 할것인가(how)에 대한 문제는 Chapter와 Guild를 통해 해결하고 있다.

2014년 2월 4일 화요일

게이미피케이션 Gamification : 웹과 모바일 앱에 게임 기법 불어넣기

게이미피케이션 Gamification : 웹과 모바일 앱에 게임 기법 불어넣기

게이브 지커맨,크리스토퍼 커닝햄 공저/정진영,송준호,김지원 공역 | 한빛미디어 | 원제 : Gamification by Design: Implementing Game Mechanics in Web and Mobile Apps

http://www.yes24.com/24/goods/6775080?scode=032&OzSrank=1



Gamification에 대해서 대략적인 정의만 들어봤지 자세한 개념이나 사용예에 대해서는 찾아본 적이 없이 그냥 결과물에 적용을 한적이 있었다가 서비스 기획 관련 책을 찾다 보니 눈에 띄어서 보게된 책임.

책에서는 개념, 사용할 수 있는 게임적인 기법들, 적용 업체와 동향, 실제 적용하기들을 다루고 있음.

Gamificiation을 이해하기 위해 기반된 history나 이론을 간략히 다루고 시작하고
사례를 중심으로 법칙이나 이론을 뒷받침 하는 구성으로 되어 있어
관련 지식이 전무한 상황에서도 부담없이 읽을 수 있다.
Gamification을 궁금해 하거나 관련 기획 입문자에게는 적합하지 않을까 생각한다.

그리고 또한 인상 깊었던 것은 옮긴이의 말이었는데
정진영님께서 작성하신 옮긴이의 말을 보면 Gamification은 너무나 매력적이지만 아직 걸음마 단계라 책에서 나오는 논리를 맹목적으로 따라가지 말고 호기심을 키워가는 계기로 삼으라고 하고 있는데.. 동감한다. 특히나 지금 포스퀘어를 보면 더 동감한다.

아래는 책을 읽으면서 공감되거나 인상 깊었던 사항에 대해서 정리함.

p.45, SAPS
Status(지위), Access(접근권), Power(권력), Stuff(물품)
보상시스템이며 앞쪽에 위치할 수록 더 많은 사람이 원하고 집착하는 보상책
 . Status > Badges, Levels and leader-boards
 . Access > loyalty에 따라혜택을 제공하거나, CEO와의 식사, VIP 좌석 제공 등
 . Power > forum에서 moderator 역할
 . Stuff > reward, prize보다는 덜하지만 사용자가 게임을 지속할 수 있도록 주는 공짜 아이템

p.52, Flow
게임이 성공한 요인의 중심에는 '플로우flow'라는 개념이 있습니다. 플로우는 행복과 창의성 연구로 유명한 심리학 교수 미하이 칙센트머하이 Mihaly Csikszentmihalyi가 주창했습니다.
플로우 상태란 플레이어가 지나친 열망과 과도한 권태감 사이에서 적정한 수준의 동기유발이 되고 있음을 의미합니다.

=> 피플웨어서 언급된 내용인데 출처는 알지 못했었음.
http://en.wikipedia.org/wiki/Mihaly_Csikszentmihalyi#Flow

In his seminal work, Flow: The Psychology of Optimal Experience, Csíkszentmihályi outlines his theory that people are happiest when they are in a state of flow— a state of concentration or complete absorption with the activity at hand and the situation. It is a state in which people are so involved in an activity that nothing else seems to matter. The idea of flow is identical to the feeling of being in the zone or in the groove. The flow state is an optimal state of intrinsic motivation, where the person is fully immersed in what he is doing. This is a feeling everyone has at times, characterized by a feeling of great absorption, engagement, fulfillment, and skill—and during which temporal concerns (time, food, ego-self, etc.) are typically ignored.

TED Talk : 미하이 칙센트미하이의 몰입
: http://www.ted.com/talks/mihaly_csikszentmihalyi_on_flow.html

사용자가 Anxiety Area와 Boredom Area 사이에서 Flow를 지속할 수 있는 것을 보여주는 도표


p.64
다니엘 핑크 Daniel H. Pink의 책 "드라이브Drive: 창조적인 사람들을 움직이는 자발적인 동기부여의 힘(청림출판, 2011)"

(TODO) => 보자

p.117, 소셜 몰입 루프
소셜 몰입 루프는 핵심적인 상품 디자인으로 플레이어가 몰입하고 다시 돌아오게 만드는 모델입니다.

Motivating Emotion > Social Call to Action > Player Re-Engagement > Visible Progress/Reward > Motivating Emotion (반복)

Novice Twitter Player의 예
• Motivating emotion = Connecting and expressing
• Player re-engagement = @Mentions
• Social call to action = Tweets
• Visible progress/reward = Followers

초보 사용자가 사람들과 소통하기 위해 Twitter를 사용하게 될 경우 (Motivating emotion)
Tweet을 통해 의견을 개진하고 (Social call to action)
멘션을 통해 더욱 참여하며 재 몰입하게 된다. (User Re-engagement)
결과로 팔로워라는 결과(보여주는 성과)를 얻게 됨 (Visible progress/reward)

Expert Twitter Player의 예
• Motivating emotion = Collecting and ranking
• Player re-engagement = Tweets and re-tweets
• Social call to action = Follows re-tweets
• Visible progress/reward = Listing followers

숙련 사용자는 수집하고 평가하려는 욕구를 가져 (Motivating emotion)
리트윗을 팔로우 하게 되며 (Social Call to Action)
트윗과 리트윗으로 통해 재 몰입 되고 (User Re-engagement)
결과로 얻어진 팔로워의 수를 통해 성과를 확인한다. (Visible Progress/Reward)

http://www.quora.com/User-Acquisition/How-has-Turntable-fm-grown-so-rapidly-with-no-marketing
: http://lucyhong.blogspot.kr/2012/06/blog-post.html

p.135(영문 P.80), 게임 기법
책에서 12가지의 게임 기법이 표로 정리되어 있는데 참고하면 좋을 것 같다.

Google에서 검색한 pdf 파일  : ftp://ivacuum.ru/i/WooLF/[2011]%20Gamification%20by%20Design.pdf

2014년 2월 3일 월요일

피플웨어 : 정말로 일하고 싶어지는 직장 만들기

피플웨어 : 정말로 일하고 싶어지는 직장 만들기
톰 디마르코,티모시 리스터 공저/박승범 역 | 매일경제신문사


선배의 추천으로 톰 드마르코의 책들을 봤었는데
이 책은 강추를 하게 되어 보게 되었음.
이전 구입을 하려 했었는데 절판이었던 것 같은데.. 지금은 구입 가능. (잘못봤었나? --;) 도서관에서 빌린 책인데 10년동안 많은 사람들이 봤는지 너덜너덜함.
 프로젝트 관리를 소설로 풀어 놓고 대다수의 기업 및 조직을 풍자한 '데드라인', 성과를 위해 잔업 및 군대 문화를 요구하는 조직의 단점과 그런 조직의 발전을 위한 조언을 담은 'Slack'
을 보면서 "관리는 함부로 누구나 하는 것이 아니구나." 라를 느끼며 현재 IT 업계의 현실에 좀 우울 했었음..  
누구나 IT 회사에서 근무를 하게 된다면 경험하게 되는 일반적인 상황들을 인생의 굴레처럼 느끼고 그냥 당연시하게 생각하고 살아가는 중에 위 책들은 나의 생각을 조금은 달리 할 수 있게 해주었다.

피플웨어는 총 6부의 chapter로 구성되어 있고 각 chapter들은 다음과 같다.
1. 인적 자원 관리
2. 사무실 환경
3. 꼭 필요한 사람들
4. 드림팀 키우기
5. 일은 재미 있어야 한다.
6. 피플웨어 그 후

책이 나온지 10년이 넘었기 때문에 사실 chapter 1-5 까지는 좀 오래된 감이 있고 chapter 6는 좀 뜬구름을 잡는 느낌도 있음.

1부, 2부, 3부에서 공감 되었던 것은 인력과 사무실 환경에 대해서 설명하던 부분이었다.

각 개인을 단지 하나의 resource로 바라보며 스페인식 경영을 하는 방법이 그닥 프로젝트의 결과나 회사 측면에서 좋지 않다는 것을 잘 설명해 주었고 사무실 환경이 지식 근로자가 집중(플로 도달)에 큰 도움이 된다는 이유도 여러모로 잘 설득 하였다고 본다.

참고로 종종 소프트웨어 개발 서적에서 나오는 상위, 하위 개발자간의 업무 능력 차이가 10배가 된다는 내용이 이 책에서 나온 얘기 이다.

4,5,6부에서는 팀 구성, 관리, 유지에 대해서 좋은 얘기 들이 나온다.
관리자가 읽는 다면 도움이 많이 되는 내용이고 다소 대규모 회사보다는 중소 기업이나 소규모 프로젝트 팀에 적합할 것으로 보인다.

아래는 읽으면서 공감이 가는 내용과 개인 의견들을 적어 봄.
* 중요한 것은 책을 직접 봐야 아래 내용들이 이해가 갈 것임.

p.18
"사람들은 보통 사람을 다루거나 사람과 관련된 일에 '정치적'인이라는 말을 갖다 붙이곤 하는데 .... 진짜 정치적인 문제는 사소한 부분이고, 사실은 대부분이 사회학적인 문제의 일부분이다."

=> 정치적이라는 핑계를 대며 회피하곤 하는데 정면 돌파 하되 다른 차원의 방법을 찾아봐야 겠다.

p.22, 햄버거 마인드
- 기계(인간 기계)를 최대한 원활히 가동시켜 오동작을 일으키지 않도록 하라.
- 근무시간에 게으름을 피우는 사람들을 봐주지 말라.
- 직원들을 호환 가능한 기계 부품으로 생각하라.
- 작업 능률을 항상 비슷한 수준으로 유지하라(적당한 속도 그 이상 그 이하도 아닌 속도로)
- 프로세스를 표준화하라. 매뉴얼에 적힌 대로 하라.
- 실험적인 시도는 하지 말라. 그것은 본사 경영진들이 할 일이다.

=> 매우 공감한다.. 제조업에서 근무하는 나로써는...

p.34, 빌리 조엘의 비엔나(Vienna) 노래
=> 책에서 말하는 스페인식 경영을 지속하는 회사에서 근무한다면(근무하고 있는지도 모르지만) 정말 위 노래가 머리속에서 계속 반복될 것 같다.. 사실 한창 바빠 집에 마음대로 못 들어갈때 회사 생활, 이직, 새로운 출발, 꿈 등에 대한 책을 많이 읽었던것 같다. 

p.40
시간에 쫓기며 일하는 사람들은 일을 더 잘하는 것이 아니라 단지 더 빠르게 일할 뿐이다.
p.53
관리자들이 프로그래머들과 상의도 하지 않고 단독으로 측정하는 경우와 비교하면, 프로그래머들이 스스로 측정치를 제시한 프로젝트가 더 생산적임을 보여주었다.
낮은 측정치, 빠듯하게 일을 진행해야할 측정치는 개발자의 힘을 빼 버린다. 
p. 65
관리자가 진정 해야 하는 일은 사람들에게 일을 시키는 것이 아니라 그들이 일에 전념할 수 있는 환경을 만들어 주는 것이다.
=> 위 내용들에 대해서 전적으로 동감하며 관리자의 관리 방법, 역량에 따라서 팀 사기나 프로젝트 결과물이 좌지우지 되는 것 같다. 팀 사기가 바닥으로 떨어지고 상황이 지속 된다면 냉소와 패배의식에 사로 잡히게 되는 것 같다..

p.71
감옥 설계 방식의 사무실
=> 아.....

p.79, 개인 편차
- 가장 업무 능력이 뛰어난 사람들은 가장 업무 능력이 떨어지는 사람보다 10배쯤 뛰어나다.
- 가장 업무 능력이 뛰어난 사람들은 중간 정도의 업무 능력을 가진 사람보다 2.5배쯤 뛰어나다.
- 중간 이상의 업무 능력을 가진 사람들은 그렇지 못한 나머지 절반보다 2배쯤 뛰어나다.

생산성과 관련 없는 요소들
- 프로그래밍 언어, 경력, 결함도(좀 의외다.), 급여의 차이
=> 언제나 공부 하며 노력하는게 프로그래머의 기본 이겠지.. 

p.105, 플로
일에 정신 없이 집중하고 있을 때, 사람들은 심리학자들이 '플로(flow)'라고 부르는 이상적인 상태에 빠지게 된다. 플로는 한가지에 깊이 집중하여 거의 명상 상태에 빠지는 것을 의미한다.
... 설계나, 개발, 저작과 같은 업무에는 플로가 필수 요건이다.

p.128
전문적 직원들에 의해 행해지는 일상적인 업무의 대부분은 좌뇌의 연쇄 처리 센터에서 행해진다. 음악은 특별히 이 작업을 방해하지는 않는다. 왜나하면 뇌의 오른쪽이 음악을 소화하기 때문이다.
... 창의적인 도약 과정은 우뇌의 작용이다. 우뇌가 배경 음악을 듣느라 바쁘다면 창의적인 도약 과정이 생겨날 기회는 사라진다.
=> 주변 소음 때문에 음악을 자주 듣긴하는데, 솔직히 코딩에 영향을 미치는 것 같다. 개인적인 집중 시간을 가져야 할듯.

p.149, 꼭 필요한 사람들
- 꼭 필요한 사람들을 뽑아라.
- 그들이 떠나지 않도록 행복하게 만들어라.
- 그들을 자유롭게 풀어 주어라.

p.155
위층의 고위 관리자가 팝콘 튀기는 냄새를 맡았던 것이다. 그는 다음 내용의 쪽지를 게시판에 붙였다. "팝콘은 프로답지 못하다." 그리하여 그 회사에서 팝콘은 금지 되었다.
=> 자주 보는 방법이다.

p.188, 표준화 보다는 통일성
훈련, 도구, 동료의 품평
이런 식으로 방법적인 통일성이 생겨난 후에야 표준화를 생각할 수 있다.

p.190, 호돈효과
위 실험에서 알 수 있는 사실은 변화 자체가 중요한 게 아니라 변화를 가져오는 행동 자체가 더 중요하다는 것이다. 사람들은 뭔가 다른 것에 끌리게 되며, 새롭게 주목할 수 있는 것을 좋아했으며, 참신함에 흥미를 느꼈다. 이것이 바로 '호돈 효과'라 불리는 이론이다.
=> 그런가? Project, 근태 시스템, 사무실 환경의 변화가 도움이 되는 것 같긴하지만 일시적인 것 같아서..

p.199
팀의 목표는 목표의 달성이 아니라 목표의 일치이다.

p.210, 팀 죽이기 전략
- 방어적 관리법
- 관료주의
- 팀을 따로 떨어뜨려 놓기
- 여러 업무를 동시에 분담하기
- 제품의 품질 저하
- 거짓 데드라인
- 소집단 관리

p.217
동시에 여러 가지 업무를 맡는 것은 팀 형성에 좋지 않을 뿐만 아니라 또한 효율성에도 좋지 않다.

=> 회사 생활 얼마하지 않았을 때 매트릭스 조직에 대한 동경이 있었던 것 같다. 여기 저기 프로젝트에 참여하여 자신의 실력을 높힐 수 있고 관리자 측면에서는 최대한 resource를 활용할 것이라고 생각을 했었는데.. 아무것도 모를때라..

p.225
관리자의 기질을 타고난 사람은 거의 무의식적으로 팀에게 무엇을 해줘야 할지를 느낀다.
... 공통점은 바로 관리자가 팀원들이 함께 성공을 거둘 수 있는 작은 업무들을 끊임없이 제공한다는 것이다.

p.238, 건강한 기업을 만들기 위한 독자적 기법
- 품질을 중시하는 문화를 만들어라.
- 종결감을 느끼게 하라.
- 엘리트 의식을 키워 주어라.
- 이질성을 허락하고 격려하라.
- 성공적인 팀들을 잘 유지하고 보호하라.
- 전술적인 것이 아니라 전략적인 방향을 제시하라.

p.252, 건설적인 취지의 무질서를 도입하는 방법
- 실험 프로젝트
- 프로젝트 대회
- 브레인스토밍
- 극기 훈련
- 연수, 여행, 회의, 휴양지 등으로 직원들을 내보내기

=> 극기 훈련은 반대 하지만 다른 방법들은 리프레쉬 하기는 좋은 것 같다. 다만 정말 바쁜 상태에서는 이런 방법도 무시될 것이다.

p.284
사람들이 초과 근무를 하는 이유는 과제를 주어진 시간 안에 끝마치기 위해서라기 보다는, 일을 정해진 기간까지 끝마치지 못했을 때 비난 받게 될 것을 우려해 자신을 보호하기 위함이다.

=> 떠밀려 받은 불가능한 프로젝트 중에서 어쩔 수 없이 초과 근무로 위안 삼는 것이 이해가 간다.

p.289, 팀을 죽이는 부작용들을 만들어내는 관리자들의 행동양식
- 연봉이나 실적을 공개하는 자리를 갖는다.
- 목표 관리(MBO)식 관리 기법을 사용한다.
- 뛰어난 성과를 보인 특정 직원들을 칭찬한다.
- 업무 수행 결과에 각종 상과 보너스를 건다.
- 온갖 방식으로 업무 능력을 측정한다.

p.312
전혀 변화하지 않는다면 발전은 없다.

=> 책 본문에서 나온 것 처럼 사람들은 변화를 원하지 않는다. 그리고 용기도 없을 것이다. 하지만 개개인의 노력이 회사를 조금씩 바꿀 수 있지 않을까?