%ED%98%91%EC%97%85%EC%8B%9C%EC%8A%A4%ED%85%9C

요즘 객체지향에 흥미가 있는 개발자라면 대부분 들어봤을 법한 책이 있습니다. 저도 지난 6월 27일 무려 6권이 사서 회사 동료들에게 돌립니다. 아래 그 증거가 있죠. 분명히 말하지만, 저자가 지인이라서 산 것은 아닙니다. :) [caption id="attachment_23567" align="aligncenter" width="600"] 무려 6권이나 구매 (저자에게 고기 얻어 먹으려고 산 것은 아님)[/caption] 6권 구입의 나비효과 이런 경우에도 나비효과란 말을 써도 되는지 모르겠네요 [1] . 책을 나눠줬더니 한 동료...

언제였나? 암튼 커머스 혹은 유통 도메인 설계에 대한 연작 이라는 이름으로 진지하게 나만의 글쓰기 놀이를 한 일이 있습니다. 찾아보니 올해 2월까지 했네요 . 최근에 배운 일에 대한 감상을 이어서 쓸까 하다가 혼자 놀기도 그렇고... 마치 다른 사람인양 글쓰기 연습도 하기로 마음 먹고 사실에 기초한 픽션을 연재로 걍~ 해봅니다. 제목은 북경창업기 왜 그런 제목을 붙였는지 설명하기는 싫고요. 일단, 제가 북경에 살고 있고, 개발자들과 커머스 서비스와 관련해서 아웅다웅 보내면서 느낀 점 그리고, 중국이라는 외국 생활의 생소함과 다른 문화를 받아들이는 과정을 허구를 섞어 대충 써보려고 합니다. 자... 이제 픽션으로 갑니다! 그리고 반말로!...

클라우드 소프트웨어 서비스 산업이란 장르에서 아직 정제되지 않은 우리의 진보에 대해 기록하려고 한다. 이 글은 개념적으로 잘 정제된 용어나 기술을 다루는 대신에 타이밍을 다투는 비즈니스 시장에서 벌어지는 실제 이야기를 담는데 그 가치를 두려 한다. 또한, 중국시장에서 한국 개발자가 주도하여 중국 개발자들과 함께 이제 막 열리고 있는 SaaS 시장에 도전하는 우리의 과정을 알리고자 글을 쓴다. 3년을 보내고, 이제는 시즌2 Micro Service, Docker로 할 수 밖에 없었던 사연...

같은 제목의 기사가 HBR 한글판에 올라왔다. 유료 매체이니 관심있는 분들은 찾아서 읽어 보시길 바란다. 필자는 이 글에 매우 공감하는 입장이지만, 이미 오랜시간 스스로의 방법으로 이메일로 소비하는 시간을 줄여 왔다. 그래서, 기사 제목과 저자가 말하는 핵심 메시지만 빌리고, 평소 나의 활용법을 저자가 주장하는 방식에 대한 구체적인 한 가지 실천 방법으로 공유하려고 한다. 맷 플러머가 제안하는 다섯 가지 방법 필자의 이야기를 풀기 위해 기사 말미에 쓰인 맷 플러머...

이 글은 갑자기 벌어진 일상의 장면에서 나 자신이 어떻게 행동하는지 스캔하듯 돌아본 글이다. 그 과정에서 내면을 관찰하고 긍정적인 방향으로 항해 하려고 노력한 기록을 사후 해석해보는 시도이다. CostApproval (비용-결재) 이라는 이름은 적절한가? 최초의 나의 질문은 동료가 지은 이름을 검토하는 일이었다. 처음에는 영어 표현이 옳은지 살피려 했는데, 습관 적으로 위키피디아로 나아갔다. 그런 습관적 행보가 예상하지 못한 일을 만나게 한다. [1] 일단 해당 페이지가 없을 듯 하지만, 그럼에도 불구하고 동료가 만든 조어 그대로 검색한다. 유사 맥락을 포괄하여 한번에 검색 결과를 펼쳐 보려고 습관적으로 행하는 행동 패턴이다. [caption id="attachment_21123" align="aligncenter" width="600"]...

동료 유영모 가 ID로 다른 애그리게잇을 참조하라 에서 애그리게잇을 본문에서 조립물로 바꾼 사연에 대한 이야기다. 두레이로 popit 글 검토를 하는 우리회사 popit 글 검토는popit 저자들이 글을 쓰는 워드프레스 시스템 상에서 벌어진다. 그런데, 사내에서 쓰는 두레이로 우리끼리 대화를 하고 싶어서 회사안에서는 채널을 만들었다. 워드프레스는 결과물 편집은 좋지만, 의견을 주고 받기는 어려우니까. 그러던 차에 내가 검토를 요구하는 유영모 에게 아래와 같이 답했다. [caption id="attachment_21024" align="aligncenter" width="548"]...

첫 연재에서 소개한 개념 정제 후에 동료 개발자 가 해당 내용 구현에 나섰습니다. 두 계층으로 나누어 연결한 상품 개념 이전에 그린 그림을 조금 수정해서 상황에 대한 설명을 보강합니다. Product와 Item 개념 사이에 그린 두 가지 관계를 동료 개발자 가 구현한 것이 아닙니다. 그래서, 둘 사이를 연결하는 Catalog 개념을 추가하여, 그의 구현을 Catalog 개념 구현으로 바라보겠습니다. [caption id="attachment_20462" align="aligncenter" width="600"] 두 개념 사이에 카타로그 개념을 추가하기[/caption]...

얼마 전에 객체 모델링 공부하게 책 하나 추천해주세요 를 쓴 탓인지 동료의 작업에 댓글 [1] 을 달다가 문득 모델링이란 개념에 대한 생각에 빠졌다. [caption id="attachment_20220" align="alignleft" width="600"] 동료의 작업 초점을 분명하게 하는 노력[/caption] 벤 다이어그램을 왜 그리는가? 동료에게 왜 저런 제안을 했을까? 목적은 두 가지다. 하나는 작업 내역을 읽다 보니 아직 하려는 일의 초점이 불분명한데, 성급하게 코딩부터 하려는 동료 개발자를 돌려 세우기 위함이다. 먼저 표기법을 떠나 무언가 그리는 행위가...

커머스 혹은 유통 도메인 설계에 대한 연작 (지난 글) 1편. 커머스 혹은 유통 도메인 설계에 대한 연작 오랫동안 추적한 일이다. 생각으로는 금방 정리할 수 있는 내용이지만, 실제로 구현할 수 있도록 정의하는 일은 그와는 다른 일 [4] 이다. 여튼 또 기회가 왔다. 시작은 한 개발자가 엑셀 업로드 기능을 만들었는데, 동료 기획자가 마음에 들지 않는다고 했다. 아이디어를 구하기에 당장 목표로 삼을만한 범위를 그림으로 그렸다. [caption id="attachment_20064" align="alignright" width="600"]...

요즘 일상에서 가장 많이 쓰는 도구는 Dooray 서비스 다. 지난 번에 지극히 개인적인 활용을 다룬 글 을 올리긴 했지만, 두레이의 일반적인 쓰임새는 개인 작업 관리용이 아니라 협업 도구다. 약 19개월정도 써온 사용자 1) 로서 두레이를 쓰면서 이 점은 좋으니 널리 알리고 싶다 거나 이렇게 써보면 좋겠다 고 느낀 내용을 몇 가지를 써본다. 화면 기획서를 공유하며 다자간 협업 이끌어내기 하위 작업을 통해 주 단위 작업 흐름 만들기 태그 그룹을 이용해 개발 단계 표현하기...