학교에서 컴퓨터 공학을 배우면서, 소프트웨어에 대해서 쓸 고객에 대해서 정말 고민한적이 있나요? 이 소프트웨어는 이러 이러한 것들을 제공하기때문에, 정말 좋아요. 라고 컴퓨터를 모르는 사용자가 알아들을 수 있게 가치를 설정하고 전달하도록 고민해 본적이 있을까요? 아마 우리는 공돌이기 때문에 이러한 것들을 몰라도 된다고 위안을 삼고 싶겠지만, 여실하게 대기업에서도 전 이 문제점과 부딪혔습니다. 실제 고객을 한번도 만나보지 않고 기획이나 …
카테고리 보관물: My Thinking
Joel Test보다 먼저 해야 하는 것들..
조엘 온 소프트웨어에 나온 하나의 글이 돌아다니기에 생각을 적어봅니다. 정말 오랜만에 개인의 생각을 적어본 글이네요… 더 나은 코딩을 만들기 위한 12단계 라는 주제로 아래와 같은 지침을 제시하고 있습니다. Source Control(소스 컨트롤)을 사용하십니까? 한번에 빌드를 만들어낼 수 있습니까? daily build(일별 빌드)를 만드십니까? 버그 데이타베이스를 가지고 있습니까? 새로운 코드를 작성하기 전에 버그들을 잡습니까? up-to-date(최신) 스케줄을 가지고 있습니까? spec(설계서)를 …
안드로이드 오픈소스 어플리케이션 블록 발표자료
지난 12/14일 있었던 “안드로이드 오픈소스 어플리케이션 블록” 에 참여해 주셔서 감사합니다. 뜨거운 열기와 함께 잘 마무리 하였습니다. 많은 후배들과 좋은 팀들이 만든 자료라 더 뜻 기쁜거 같습니다. 어플리케이션 블록 어플리케이션 블록 이라는 것은? 기존 Framework들을 더 쉽게 잘 쓸수 있게 추상화 놓은 Block으로 보시면 됩니다. .NET에서 Enterprise Library가, Java진영에서는 Spring이 좋은 예 입니다. 어플리케이션 블록이라는 단어를 …
스터디 그룹을 위한 패턴 언어 – Role(역할)편
스터디 그룹을 위한 패턴 언어에는 총 4개의 파트로 구성되어 있으며, 정신(Spirit), 분위기(Atmosphere), 역할 (Roles), 관습(Customs) 으로 나뉜다 . 스터디 그룹을 위한 패턴 언어 – Sprit 편 ‘Spirit(정신)’ 부분에서는 1. (숫자는 해당 패턴 번호를 의미한다.) 스터디를 왜 해야 하는지, 2. 토론의 중요성에 관해, 3. 집중할 수 있는 분위기에서 진행하기, 4. 꾸준히 하기, 5. 인맥형성 부분이 있다. …
[97 Programmer] 프로그래머가 알아야 할 97가지 – 출간!!
드디어 또 하나의 작품이 출간되었습니다. 아키텍트가 가 알아야 할 97가지에 이어 프로그래머가 알아야 할 97가지가 드디어 출간되었습니다. 여러 지인들이 의기투합해서 만든 작품으로, 오랜 시간이 걸려 드디어 빛을 보게 되었습니다. 정말 많은 분들이 고생을 해주셨구요. 10명이 넘게 번역 작업을 하느라 정말 고생이 많았습니다. : 특히 일정한 퀄리티가 나오도록 어려번 검수를 해주시느라 고생해 주신, 김수현 , 최현미 …
안드로이드, 오픈소스 그리고 패턴
지난 주말 (2012년 5월 20일) 코엑스에서 스마트 개발자 협회가 주관하는 글로벌 커뮤니티 써밋에 EVA 커뮤니티 연사로 발표를 했습니다. 먼저 이번 발표에 많은 도움을 준 소프트웨어 마에스트로 멘티인 오유환, 강미경, 김나래, 손윤정 4 멘티에게 감사드립니다. 이 4명이 아니였다면 이러한 좋은 자료는 나오지 못했을 겁니다. 프리젠테이션이 다루는 내용은 다음과 같습니다. Android 이해 구글이 꿈꾸는 Android의 미래 (Modu …
또 하나의 지표 – Bob 삼촌의 Instability, Abstractness
지표란 직접 경험을 하지 않아도 현재의 상황을 알수 있는 도구를 말합니다. 옛날 제주도에서는 식수가 귀해 빗물을 식수로 사용을 했습니다. 빗물의 오염도를 파악하기 위한 지표로, 개구리 (숫놈끼리만 넣거나, 암놈끼리만 넣거나)들을 넣었다고 합니다. 개구리 들이 벌레들을 잡아먹어 물이 항상 청결한 상태를 유지할 수 있었으며, 또한 개구리의 생존 여부로 물 오염도를 파악을 할수 있기 때문입니다. 일전에 소프트웨어 품질을 …
고객은 그들이 무엇을 말했는지를 모른다. (Your Customers Do not Mean What They Say)
저는 원하는 것을 말하지 않아도 될만큼 만족하고 있는 고객을 만나본 적이 없습니다. 대부분 그들은 엄청나게 세세한 부분까지 이야기 합니다. 문제는 고객들이 항상 모든 진실을 이야기하지 않는다는 것입니다. 그들은 보통 거짓말을 하지 않습니다만, 고객의 관점에서 말할 뿐 개발자의 관점으로는 이야기 하지 않습니다. 그들은 그들만의 용어를 사용합니다. 그들은 중요한 세부사항들은 생략합니다. 그들은 마치 여러분도 그들처럼 그 …
Domain Driven Design 적용에 대한 고민들
얼마전 이대엽님이 도메인 주도 설계 (Domain Driven Design) 라는 명서를 번역해 주셨습니다. 저 역시 구매를 했었고, DDD가 가져오는 철학이나 사상은 정말 훌룡합니다. 왜 이런 명서가 이제 번역될수 밖에 없는지 현실을 알고 있지만, 정말 슬픕니다. POSA나 DDD와 같은 명서들은 번역을 한다는 것의 거의 희생에 가깝습니다. 사실 역자 입장 에서는 적절한 어휘 선정과, 국내 개발자의 시선에 맞게 레벨을 …
[PLoP] Deployment Pattern 저자 워크샵
이번 저자 워크샵은 정말 힘든 강행군의 연속이었습니다. PLoP 2011의 의장인 Lise Hvatum 과 2일에 거쳐 패턴을 같이 다듬었습니다. 사실 이번 PLoP에는 저희가 바쁜 일정에 논문을 잘 쓰지 못해서 논문을 같이 다듬는 Writing Group으로 배정을 받았는데, 오히려 많은 것을 배운거 같습니다. 같이 논문을 써준 김 지원님이 같이 간 덕분에 외롭지 않고, 이래 저래 정리한 내용도 2배로 늘어났습니다. …
