No Overtime

라우팅 캐시 구조체

2009-08-04T15:46:05+09:00

리눅스 커널의 라우팅 캐시(Routing cache) 관련 구조체 struct rtable 은 다음과 같은 구조를 가지고 있습니다. struct rtable 구조체 안에 struct dst_entry 라는 자료구조를 포함하고 있는데 dst_entry 는 라우팅 후 패킷을 포워딩하기 위한 정보들을 담고 있는 구조체로서 하나의 rtable 마다 하나의 dst_entry를 가지게 됩니다. rtable 구조체는 커널 2.6.20.21에서 다음과 같은 모양을 하고 있습니다. include/net/route.h struct rtable { union { struct dst_entry dst; struct rtable *rt_next; } u; struct in_device *idev; unsigned rt_flags; __u16 rt_type; __u16 rt_multipath_alg; __be32 rt_dst; /* Path destination */ __be32 rt_src; /* Path source */ int rt_iif; /* Info on neighbour */ __be32 rt_gateway; /* Cache lookup keys */ struct flowi fl; /* Miscellaneous cached information */ __be32 rt_spec_dst; /* RFC1122 specific destination */ struct inet_peer *peer; /* long-living peer info */ }; 코드에서 보는 바와 같이 rtable 안에 dst_entry 구조체와 rtable의 next 포인터가 union으로 선언되어 있기 때문에 rtable 의 구조체의 포인터나 dst_entry의 포인터중 어떤 것을 알고 있더라도 상호참조가 가능합니다. ps. 최근 커널에서는 union이 사라지고 rtable 구조체의 필드로 dst_entry가 들어가 있네요.

글 전체보기

왜 품질은 협상의 대상이 아닌가?

2009-07-07T07:39:43+09:00

우선 내적 품질과 외적 품질을 구분해보려고 한다. - 외적 품질은 시스템을 사용하는 사람들이 인식하는 품질이다. 느리고 직관적이지 않은 사용자 인터페이스는 낮은 외적 품질의 예라고 할 수 있다. - 내적 품질은 대개 사용자들에게는 직접 드러나지 않지만 시스템을 유지보수하는 데 지대한 영향을 미칠 수 있는 것을 지칭한다. 시스템 설계의 일관성, 테스트 커버리지, 코드의 가독성, 리팩토링 같은 것과 관련이 있다. 일반적으로 내적 품질이 높은 시스템이라 하더라도 외적 품질이 낮을 수 있다. 하지만 내적 품질이 낮은 시스템에서 높은 외적 품질을 기대하기란 힘들다. 부실한 기초 위에 멋진 건물을 짓기란 어려운 법이다. 나는 외적 품질을 범위(scope)의 한 부분이라고 본다. 예를 들자면, 우선은 다소 불편하면서 느린 사용자 인터페이스라 하더라도 시스템을 출시한 다음 나중에 깔끔한 버전을 출시하는 것이, 경우에 따라서는 비즈니스 관점에서 보았을 때 전혀 문제가 없는 결정일 수 있기 때문이다. 나는 이와 같은 트레이드오프를 [footnote]Scrum 에서 Product Owner[/footnote]에게 맡겨둔다. 범위를 결정하는 것이 바로 그의 책임이기 때문이다. 반면, 내적 품질은 논의의 대상이 될 수 없다. 어떠한 상황에서도 시스템의 품질을 유지하는 것이야말로 팀이 책임져야 할 사항이며, 이것은 두말할 필요 없이 그냥 협상의 대상이 아니다. 절대로. - 스크럼과 XP 에서 그간 일정에 맞추기 위해, 또는 성과를 빨리 내기 위해서 어쩔 수 없다고 스스로에게 최면을 걸면서 코드의 품질을 희생해 왔던 일들이 얼마나 많았는지..

글 전체보기

7 Solid Tips for Making Decisions Easier

2009-04-29T10:48:12+09:00

7 Solid Tips for Making Decisions Easier 1. 한 번에 하나의 결정만 하라. 여러가지 결정을 하나로 만들지 말라. 각각의 결정을 분리하고 따로 떼어내어 각각을 개별적으로 다룰 수 있게 하라. 그렇게 하는 것이 촛점을 좁혀서 토론을 쉽게하고 결정을 빨리 내릴 수 있게 한다. 2. 공개하라. 공개적으로 논의하라. 성공적인 조직은 밝은 곳에서 결정을 내린다. 비밀스런 결정은 추측을 부채질하고 결정사항에 합의하지 못하게 만든다. 3. 정보를 제공하라. 적극적으로 필요한 정보를 먼저 모아라. 데이터에 기반한 결정은 무리 없이 부드럽게 진행이 되며, 결정 과정을 혼란스럽게 만드는 감정의 이입을 막는다. 사람들은 조사자료이든, 예산이든, 스케쥴이든 데이터를 원한다. 그들이 나중에 되돌아와 자료를 요구를 할 필요가 없도록 미리 데이터를 제공하라. 4. 참여자를 최소로 하라. 결정 과정에 필요한 사람들을 포함시켜라. 만약 다른 사람이 그에 대해 관심을 갖는다면 자료를 복사해 줄 수는 있지만 논의에 참여시키지는 마라. 만약 그 사람의 반대가 결정에 영향을 미치게 될지 스스로에게 질문해보고, 그렇지 않다면 그들을 참여시키지 마라. 5. 말을 줄여라. 제안사항을 전달하는데 필요한 최소한의 말만 하라. 당신의 팀은 모든 말을 받아들이고 이해할 수 있지만, 외부 사람은 주의가 분산되고 당신 말의 핵심을 놓치게 될 수도 있다. 6. "Yes" 가 무엇을 의미하는지 명확하게 하라. 이 말은 당연하게 들린다. 하지만 제안을 할 때는 제안을 하도록 해라.(원문이 무슨 뜻인지 모르겠습니다.) 분명하게 요청하고 액션 가능한 표현을 사용해라. 이것은 일반적으로 저지르는 실수이다. 핵심 문장과 그 메시지 자체에 집중하고 필요하다면 격식을 차려라. "이 프로젝트를 승인하시겠습니까?"라는 의미로 "어떻게 생각하십니까?"라고 말하지 마라. 7. 결정 사항을 기록하라. 이것은 쉬워보이지만 실천하기는 어렵다. 특히 이메일로는 더욱 그렇다. 이사회에서 의사록을 기록하는 데는 이유가 있다. 사람들은 결정사항이 공공의 장소에 기록된다는 사실을 알면 신중하게 결정하고 그것을 따르게 된다. 합의사항이 기록되는 인트라넷이나 웹 상의 폴더나 문서에 대해서 생각해보라. 비록 그 내용을 보게 되지 않더라도 기록된 합의사항이 존재한다는 사실을 아는 것은 강력한 압력과 책임감을 만들어낸다. 원문 http://zenhabits.net/2009/03/the-fine-art-of-decision-making-%E2%80%93-7-tips-for-getting-decisions-made-easier/

글 전체보기

아이팟 터치와 구글 캘린더 싱크

2009-05-12T13:06:46+09:00

아이팟 터치의 캘린더와 연락처를 구글 캘린더와 지메일의 주소록과 싱크할 수 있는 방법이 생겼습니다. http://www.google.com/mobile/apple/sync.html 그 동안 구글 캘린더와 연동되는 어플리케이션을 찾아봤지만 별로 만족스럽지 못했는데 깔끔하게 싱크할 수 있게 되었네요. 만족스럽습니다. 싱크를 하게 되면 아아팟의 연락처는 지워지기 때문에 아이튠즈를 이용해서 미리 백업을 해 놓고 지메일 주소록과 연동하라고 합니다. 저는 그 동안 아이팟의 연락처는 사용하고 있지 않아서 그냥 싱크를 해봤는데 지메일의 주소록을 깔끔하게 가져오는군요.

글 전체보기

The Zen of Scrum

2009-02-26T07:49:18+09:00

스크럼에 대한 프리젠테이션입니다. 깔끔하게 설명이 되어있네요. The Zen of Scrum 1.0 View more presentations from Jurgen Appelo. (tags: projectmanagement development) 프리젠테이션을 만든 사람은 Presentaion Zen 이라는 책을 보고 프리젠테이션 작성법에 대해서 영향을 받았다고 하네요. 어떤 책인지 한번 읽어보고 싶어집니다. 아마존 서평 별 네개 반 짜리네요.

글 전체보기

달기리를 말할 때 내가 하고 싶은 이야기

2009-01-30T19:01:33+09:00

그저 묵묵히 시간을 들여 거리를 뛰어간다. 빨리 달리고 싶다고 느껴지면 나름대로 스피드도 올리지만, 설령 속도를 올린다 해도 그 달리는 시간을 짧게 해서 몸이 기분 좋은 상태 그대로 내일까지 유지되도록 힘쓴다. 장편소설을 쓰고 있을 때와 똑같은 요령이다. 더 쓸 만하다고 생각될 때 과감하게 펜을 놓는다. 그렇게 하면 다음 날 집필을 시작할 때 편해진다. 어니스트 헤밍웨이도 아마 비슷한 이야기를 썼던 것으로 기억하고 있다. 계속하는 것- 리듬을 단절하지 않는 것. 장기적인 작업을 하는 데에는 그것이 중요하다. 일단 리듬이 설정되어지기만 하면, 그 뒤는 어떻게든 풀려 나간다. 그러나 탄력을 받은 바퀴가 일정한 속도로 확실하게 돌아가기 시작할 때까지는 계속 가속하는 힘을 멈추지 말야야 한다는 것은 아무리 주의를 기울인다고 해도 지나치지 않다. 무라카미 하루키 - 달리기를 말할 때 내가 하고 싶은 이야기 中 리듬을 잃지 않는 것. 개발자로서 열정을 잃지 않고 오래 일하고 싶다면 역시 새겨 둘 만한 이야기입니다.

글 전체보기

Project Planning A Step by Step Guide

2009-08-04T15:46:04+09:00

프로젝트 계획에 관한 좋은 글이 있어서 소개합니다. 번역이 좀 어설픕니다. 이상한 부분은 원문을 참고하시기 바랍니다. http://www.projectsmart.co.uk/project-planning-step-by-step.html Project Planning A Step by Step Guide by Duncan Haughey, PMP 프로젝트 계획은 프로젝트를 성공으로 이끄는 핵심이다. 어떤 종류의 프로젝트를 맡게 되더라도 가장 먼저 해야 할 일은 프로젝트 계획을 만드는 일이다. 종종 프로젝트 계획은 무시되기도 한다. 하지만 많은 사람들은 프로젝트 계획이 시간과 비용을 절약하고 문제를 해결하는데 도움이 된다는 것을 깨닫지 못한다. 이 글은 간단하고 실용적인 프로젝트 계획법에 대한 내용이다. 이 글이 끝나면 당신은 프로젝트에 사용할 수 있는 올바른 계획법을 가지게 될 것이다. Step 1 프로젝트 목표 프로젝트는 이해관계자의 요구사항이 충족되었을 때 성공할 수 있다. 이해관계자란 프로젝트에 직접 혹은 간접적으로 영향을 주는 모든 사람을 말한다. 첫 번째 단계에서 중요한 것은 프로젝트의 이해관계자가 누구인지 아는 것이다. 프로젝트의 이해관계자를 찾는 것이 항상 쉬운 일은 아니며, 간접적인 이해관계자가 누구인지 찾는 것은 더욱 어렵다. 이해관계자는 다음과 같은 사람들이다. 프로젝트 스폰서 프로젝트 산출물을 받는 고객 프로젝트 결과물의 사용자 프로젝트 관리자나 프로젝트 팀 일단 이해관계자가 누구인지 알고 나면 그 다음 단계는 그들의 요구사항을 확인하는 것이다. 요구사항을 확인하는 가장 좋은 방법은 당사자와 인터뷰를 하는 것이다. 인터뷰를 통해서 실제로 도움이 되는 진짜 요구사항을 끄집어내기 위한 시간을 가져라. 그들은 종종 프로젝트에 도움이 되지 않거나 프로젝트와 관계가 없는 요구사항에 대해서 이야기할 것이다. 그런 요구사항들은 기록을 해 뒀다가 가장 낮은 우선순위를 할당할 수도 있다. 다음은 모든 인터뷰를 실시하고 나서 모인 요구사항에 우선순위를 매긴다. 우선순위가 매겨진 요구사항 리스트로부터 쉽게 측정할 수 있는 목표를 정해라. 요구사항으로부터 목표를 정하는 방법으로 SMART 원칙을 이용하여 요구사항을 검토하고 목표를 정할 수 있는데 이는 언제 목표가 달성되는지 확인하기 쉬운 방법이다. 일단 일련의 명확한 목표를 정하고 나면 그 목표를 프로젝트 계획에 기록해야한다. 또한 프로젝트 이해관계자들의 요구사항과 기대치를 프로젝트 계획에 포함시키는 것도 유용하다. 이제 프로젝트 계획의 가장 어려운 부분이 끝났다. 다음으로 넘어가서 프로젝트 산출물을 살펴보자. Step 2 프로젝트 산출물 첫 번째 단계에서 정의한 목표를 이용하여, 목표를 만족하기 위해서 프로젝트의 결과로 전달해야 할 것들의 목록을 만들어라. 목록의 각 아이템이 언제, 어떻게 전달되어야 할지 명기해라. 프로젝트 산출물을 인수할 추정일을 프로젝트 계획에 포함시켜라. 일정이 진행됨에 따라서 더 정확한 추정일이 정해질 것이며, 다음 단계는 이것에 대해서 알아본다. Step 3 프로젝트 일정 두 번째 단계에서 정의한 각 산출물을 만들기 위한 작업 목록을 만들어라. 각각의 작업에 대해서 다음과 같은 사항을 정해야 한다. 작업을 완료하기 위해 필요한 시간 작업을 수행할 사람 각 업무의 작업량을 결정했다면, 작업을 완료하는데 필요한 시간과 좀 더 정확한 인수 일자를 추정할 수 있다. 프로젝트 계획의 인수 추정일을 더 정확한 날짜로 수정해라. 현재 시점의 계획에서 프로젝트 일정표를 만들기 위해서 Microsoft Project 같은 소프트웨어를 사용할 수도 있다. 아니면 무료로 제공되는 많은 템플릿 가운데 하나를 사용해도 좋다. 모든 산출물과, 작업, 작업시간, 작업을 수행할 사람을 입력해라. 현재 단계에서 일반적으로 생기는 문제는 프로젝트 일정이 당신이 추정한 실제적인 일정이 아니라 스폰서에 의해서 강제로 정해지는 것이다. 이런 상황을 알게 되었다면 프로젝트 스폰서와 즉시 만나야 한다. 이런 상황에서 당신이 가질 수 있는 선택은 다음과 같다. 데드라인을 재협상한다. (프로젝트 연기) 인원 보충 (비용 증가) 프로젝트 범위 줄이기 위외 내용 중 하나를 선택하는 것을 정당화하기 위해서 작성한 프로젝트 일정표를 사용하라. Step 4. 지원 계획 이번 섹션은 프로젝트 계획 과정의 일부로 반드시 만들어야 하는 계획을 다룬다. 이것은 계획에 직접 포함될 수 있다. 인적 자원 계획 프로젝트에서 중요한 역할을 하는 사람과 조직의 이름을 확인하고, 그들의 역할과 의무를 프로젝트 계획에 명시하라. 그리고, 프로젝트를 수행하는데 필요한 인력의 수와 종류를 명시하라. 각각의 인력에 대해서 작업 시작일, 추정한 작업 기간, 그들을 구하기 위한 방법을 기록하고 이 모든 정보를 한장의 시트로 만들어라. 의사소통 계획 프로젝트에 대해서 누가 정보를 가지고 있기를 원하고, 그들이 어떻게 정보를 얻을 수 있는지를 문서로 만들어라. 가장 일반적인 방법은 월간/주간 진행보고서를 이용하는 것인데, 이 보고서에는 프로젝트 수행과정, 진행된 마일스톤, 다음 기간에 작업할 내용 등을 기록한다. 위험요소 관리(Risk Management) 계획 위험요소 관리는 프로젝트 관리의 중요한 부분이다. 종종 간과될때가 있지만, 프로젝트에 발생할 수 있는 위험요소를 가능한한 많이 찾고, 나쁜 일이 일어날 것을 대비하는 것은 중요하다. 프로젝트가 가질 수 있는 일반적인 위험요소들은 다음과 같다. 너무 낙관적으로 시간과 비용을 추정한다. 고객 리뷰와 피드백 주기가 너무 길다. 예상하지 못한 예산 삭감 명확하지 않은 역할과 의무 이해관계자의 의견을 구하지 않거나 그들의 요구사항을 제대로 이해하지 못한다. 프로젝트가 시작된 후에 요구사항이 변경된다. 프로젝트가 시작된 후에 요구사항이 추가된다. 의사사통의 부족으로 인한 오해와 품질 문제, 그리고 재작업 작업자의 헌신 결여 위험요소는 단순한 위험요소 로그를 통해 추적할 수 있다. 확인된 각각의 위험요소를 위험요소 로그에 추가하고 위험요소가 실현되지 않도록 하려면 무엇을 해야하는지, 실제로 발생했을 때 무엇을 해야하는지를 기록하라. 위험요소 로그를 프로젝트 기간동안 주기적으로 검토하라. 위험요소를 무시한다고 해서 위험요소가 사라지지 않는다는 것을 기억해라. 축하한다. 모든 단계를 거쳤다면, 당신은 훌륭한 프로젝트 계획을 가졌을 것이다. 프로젝트를 진행하면서 프로젝트 계획을 갱신하는 것을 잊지말고, 계획에 비추어 프로젝트 진행을 측정해라.

글 전체보기

svn log --stop-on-copy

2008-11-17T18:11:58+09:00

svn 을 사용할 때 branch 를 위해서 copy 를 하고 작업을 하는 경우가 자주 있습니다. 작업이 끝난 후 trunk에 merge를 하기 위해서 copy 한 revision을 찾으려고 로그를 뒤지는 경우가 있는데 이때 유용한 명령어가 있었네요. svn log --stop-on-copy svn log 명령에 --stop-on-copy 옵션을 사용하면 로그를 보여줄 때 마지막에 copy한 revision까지의 로그만을 보여줍니다. 이 옵션을 왜 이제서야 발견했는지 모르겠네요. 이제 더 이상 언제 copy 했는지 몰라서 로그를 한참 뒤질 일은 없겠습니다.

글 전체보기

socket buffer 관련 함수

2009-08-04T15:46:04+09:00

skb 관련 함수 중 헷갈리는 것이 몇 가지 있습니다. skb_put(), skb_push(), skb_pull(), skb_reserve() 인데요. 생각난 김에 정리해봅니다. skb_alloc(size) 직후 skb 구조체 모양 (a)skb_put (b)skb_push (c)skb_pull (d)skb_reserve 출처: Understanding Linux Kernel Internal

글 전체보기

전문연구요원 복무만료

2009-08-04T15:46:04+09:00

병역특례로 일한지 이제 3년이 다 되갑니다. 만료일까지 약 20일 정도 남았네요. 며칠 전에 병무청에서 전문연구요원 복무만료 통지서가 날아왔습니다. 주위 사람들이 좋겠다고 하는데 뭐가 좋은지 아직은 잘 모르겠습니다. 그런데 마침 복무 만료일부터 여름 휴가가 시작입니다. 일부러 맞춘 건 아닌데 그렇게 됐습니다. 기념여행이라도 다녀와야 할 것 같네요.

글 전체보기