일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
- 품의
- 안좋은기억
- 보석들
- 개인성향
- OpenCV
- 교훈들
- build
- Open Computer Vision Library
- Specification
- 페북글
- 김창준
- 직무의사유화
- 코딩 테스트
- 인사과
- Computer Vision
- 와인버그
- 스펙
- Agile
- 맥
- 원격면접
- 엔지니어
- 인간
- 회고
- Documentation
- 인사
- 개저씨
- MacOS X
- Python
- 애자일
- xper
- Today
- Total
목록분류 전체보기 (36)
세상을 놀라게 하자!
저는 작년 말에 Boardman이라는 앱을 앱스토어에 올렸습니다. 이 앱은 화이트보드 사진을 찍어주는 앱입니다. 그냥 사진을 찍는 거면 카메라 앱이 있는데 왜 만드나 하실 겁니다. 바로 아래 그림과 같은 효과를 내주는 앱이지요. 이 앱을 만들게 된 동기는 이렇습니다. 보통 그림을 그려서 설명하고 설계하는 software engineer는 화이트보드를 끼고 살지요, 저 역시 그랬습니다. 그런데 문제는 이것이 기록으로 남아서 정리가 되질 않기 때문이었습니다. 당시 제가 일하던 직장에 전자칠판이 몇개 있긴 했지만 이것이 늘 제가 쓸 수는 없는 상황이었거든요. 그러다가 camera calibration으로 유명한 Zhengyu Zhang의 논문을 발견했습니다. 한번 짜보자 싶어서 가볍게 python script..
우리는 늘 고객이 우리의 개발에 참여해야 한다라고 말합니다. 그러나 실제 우리는 어떻게 그들을 참여 시키고 있습니까? 단순히 매주 한번씩 고객과 만나는 것인가요? 아니면 제품 출시 직전에 테스트를 통해 고객과 만나나요? 최근 The lean startup으로 유명한 Eric Rise는 Nordstrom이란 Team이 벌인 Flash build라는 개발 방식에 대해 글을 올렸습니다. 이들의 실험은 지금 무언가 마땅한 제품을 기획을 해내지 못하고 있는 회사나 조직이 반드시 해보기를 권하는 일입니다. 먼저 이들의 프로젝트는 ‘1주일간 선글라스 가게에서 사용할 앱 만들기'입니다. 이게 어떻게 가능할까요? 한번 생각해보세요, 여러분이라면 어떻게 할지. 이들의 방법은 이랬습니다. '우리 모두 선글라스 가게로 가자’..
Joseph Yoder 소개 우리나라에서는 정말 만나기 힘든 ‘Architect’이신 Joseph Yoder가 한국에 다른 일정으로 오셨습니다. 이분의 주무기는 Refactoring과 Adaptive Object Model, Design Pattern입니다. http://www.joeyoder.com/ 에 자세한 이야기가 나와 있습니다만 다양한 형태의 PLoP Conference를 주관하시고 있고 소프트웨어 아키텍쳐, 설계, 구현과 같은 다양한 소프트웨어 개발에 대한 훈련, 멘토링과 컨설팅을 하고 계십니다. The Big ball of mud 특별히 이번에 진행된 Conference에서는 TDD와 Refactoring에 대한 이야기를 했습니다. 왜 소프트웨어는 가면 갈수록 점점 엉터리 코드로 엉망이 되어..
서로 다른 욕구 대부분의 경우 개발자들은 사람과 상호 작용을 다루는 일에 서투릅니다. 경영진은 사람과 친숙치 않은 사람과 일을 함께 하는데 서툽니다. 개발자들은 경영진이 쉽게 일을 생각한다 느끼고 경영진은 개발자들이 일을 성실하게 하지 않는다고 느낍니다. 그런데 정말 그것이 사실일까요? 왜 경영진은 개발팀이 보기에 촉박한 일정을 제시할까요? 경영진의 ‘욕구’를 생각해봅시다. 일반적인 경영에서는 제품의 출시로 매출이 나오면 성공이라 생각하지요. 그래서 빠르게 개발이 되어서 시장의 반응을 알고 싶어합니다. 또는 개발 기간 = 임금 비용이기 때문입니다. 즉 경영진에게 가치가 있는 일이란 가능한 적은 비용은 적게 들이고 빨리 시장에 물건을 내놓아 매출을 만드는 것입니다. 그리고 의외로 많은 시간을 고민고민해서 ..
XPER 2011년 1월 모임에서 위와 같은 주제로 발표를 하게 되었습니다. Agile approach can help computer vision research Computer vision과 Agile을 같이 이야기 할 수 있는 것이냐 한다면 사실 좀 다른 범주입니다. 하지만 Computer vision 연구 조직을 운영하는데 있어서는 Agile방법론이 많이 아이디어를 줄 수 있다고 생각합니다. 어찌보면 Software를 이용하는 다른 연구/개발 쪽에도 볼만한 아이디어들이 있다고 생각합니다. 사실 Agile도 도구에 지나지 않지요, 이 Agile뒤에 있는 '인간의 존중'이란 생각이 제일 큰 그림이라고 저는 생각합니다. 그만큼 발전을 해야 하는데 아직도 부족한 자신을 돌아보게 됩니다. 이 슬라이드는 그..
과연 개발자의 업무 평가를 제대로 하는 것이 가능할 것인가라는 주제는 논의가 많습니다. 그럼 반대로 '개발자의 업무평가를 하지 않는 것은 가능할까'라는 질문을 해보면 어떨까요? 아마도 초조해 하시는 분들은 관리자들일 확률이 클겁니다. 인사고과도 매겨야 되는데 어떻게 하란 말인가라고 말이죠. 반면에 일반 개발자들은 그냥 평범할 수도 있을 겁니다. 대부분 그런 것과 상관 없이 일해왔을 확률이 크기 때문입니다. 어떤 조직은 '일정 준수'에 대해 책임을 묻겠다는 조직이 있긴 합니다만, 하나 궁금한 것이 있습니다. 그 일정 엔지니어들이 잡은 것인가요? 책임을 진다는 것은 그 의사 결정에 참여해야 의미가 있습니다. 만약에 엔지니어가 잡지 않은 일정에 대해 책임을 지라 하고 고과를 매기겠다면 이것은 남이 변을 보다 ..
작년 상반기에 결국 Computer vision일을 다시 해야겠다는 생각으로 이직을 했습니다. 그러면서 또 많은 일이 있었지만 드디어 그 결실 하나가 나왔습니다. 제가 속한 Voxelogram은 4CAST라는 Full 3D Video시스템을 만드는 회사입니다. Full 3D Video가 무엇이냐고 물으신다면 '매 프레임마다 3D data가 있는 비디오'라고 답을 드리겠습니다. 데모 동영상이 있으니 첨부합니다. 이런 data를 어떻게 얻을까요? 바로 아래와 같이 여러 시점에서 얻은 동영상에서 3D data를 복원함으로서 만들 수 있습니다. 예상하듯이 굉장히 많은 Computer vision 알고리즘들이 들어가 있습니다. 하지만 이것보다 더 놀라운 것은 모든 개발 과정에서 Agile, Scrum에서 제안하는..
일반적으로 Computer vision을 하다보면 Pattern recognization에서 사용하는 방법들을 많이 사용하게 됩니다. 그런데 '조금' 다릅니다. 때론 '많이' 다르게 해야 합니다. 어떤 이유 때문일까요? 일반적으로 두 서너개의 집합이 있고 이에 대한 분류를 하라고 하면 Pattern recognition쪽을 하신 분들은 자연스럽게 K-Mean Clustering을 찾게 됩니다. 그런데 이것이 늘 맞을까요? 아시는 분들은 알겠지만 최소한 mean이 몇개가 어디에 있을 것이라는 것을 정해주어야만 가능하기 때문에 이것을 어떻게 정하느냐에 따라 많은 차이를 나타냅니다. 늘 맞지 않는다는 이야깁니다. 그럼 이런 분류 방식을 Computer vision에 적용해보지요. 예컨데 Thresholding..
5월 XPer정모를 다녀왔습니다. XPer는 XP 프로그래밍 방법론에 관심을 가지고 있는 사람들의 모임이고 처음 XP를 국내에 소개하신 김창준님이 주관하시는 모임입니다. 어느 모임에서 했던 회고의 내용. 이번 정모에 Gerald Weinberg가 하고 있다는 PSL( Problem Solving Leadership )에 창준님이 다녀오시고 이에 대한 소개를 했습니다. 그리고 실제 이를 해보았지요. 저희가 해 본것은 회사를 하나 설립하는 것을 모의실험 한 것이었습니다. 이에 대해서는 이 글을 좀 참조하심 도움이 되실 지 모르겠습니다. (과거 PSL에서도 이런 식으로 진행 되었나 봅니다.) 끝나고 딱 보는데 우선 소설 '파리대왕' 이 생각났습니다. 아무리 멀쩡한 사람이라도 극한 환경속에 둘 때 그 사람의 진..
서론 최근 연구결과에 의하면 실제 진행되는 정보기술 프로젝트들의 32%만이 성공( 2009 Standish group CHAOS 2009 report ) 한다고 합니다. 그럼 어떻게 32%는 이룩할 수 있었을까요? 어떤 공통된 완벽한 답은 없습니다. 각자의 길을 잘 수행한것일뿐입니다. 실제 일반적인 관리자 육성 교육 몇번 받았다고 해서 그런 사람들이 진행하는 프로젝트가 성공하지도 않습니다. 그 자리에 서 있는 사람에 따라 달라진다는 거지요. 그럼 뭐가 달라서 어떤 관리자들은 성공하고 어떤 이들은 실패할까요?이를 위해 두가지를 생각해야 합니다. 첫번째는 기술관리자가 생각하는 성공의 정의이고 두번째는 구성원들의 성향입니다. 첫번째, 기술관리자의 성공의 가장 큰성공은 무엇일까요? 자신이 관리하는 프로젝트가 성..