No Overtime

리눅스 커널의 라우팅 캐시(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가 들어가 있네요.

우선 내적 품질과 외적 품질을 구분해보려고 한다.

- 외적 품질은 시스템을 사용하는 사람들이 인식하는 품질이다. 느리고 직관적이지 않은 사용자 인터페이스는 낮은 외적 품질의 예라고 할 수 있다.

- 내적 품질은 대개 사용자들에게는 직접 드러나지 않지만 시스템을 유지보수하는 데 지대한 영향을 미칠 수 있는 것을 지칭한다. 시스템 설계의 일관성, 테스트 커버리지, 코드의 가독성, 리팩토링 같은 것과 관련이 있다.

일반적으로 내적 품질이 높은 시스템이라 하더라도 외적 품질이 낮을 수 있다. 하지만 내적 품질이 낮은 시스템에서 높은 외적 품질을 기대하기란 힘들다. 부실한 기초 위에 멋진 건물을 짓기란 어려운 법이다.

나는 외적 품질을 범위(scope)의 한 부분이라고 본다. 예를 들자면, 우선은 다소 불편하면서 느린 사용자 인터페이스라 하더라도 시스템을 출시한 다음 나중에 깔끔한 버전을 출시하는 것이, 경우에 따라서는 비즈니스 관점에서 보았을 때 전혀 문제가 없는 결정일 수 있기 때문이다. 나는 이와 같은 트레이드오프를 [footnote]Scrum 에서 Product Owner[/footnote]에게 맡겨둔다. 범위를 결정하는 것이 바로 그의 책임이기 때문이다.

반면, 내적 품질은 논의의 대상이 될 수 없다. 어떠한 상황에서도 시스템의 품질을 유지하는 것이야말로 팀이 책임져야 할 사항이며, 이것은 두말할 필요 없이 그냥 협상의 대상이 아니다. 절대로.

 - 스크럼과 XP 에서

그간 일정에 맞추기 위해, 또는 성과를 빨리 내기 위해서 어쩔 수 없다고 스스로에게 최면을 걸면서 코드의 품질을 희생해 왔던 일들이 얼마나 많았는지..

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/

아이팟 터치의 캘린더와 연락처를 구글 캘린더와 지메일의 주소록과 싱크할 수 있는 방법이 생겼습니다.




http://www.google.com/mobile/apple/sync.html

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

스크럼에 대한 프리젠테이션입니다. 깔끔하게 설명이 되어있네요.


프리젠테이션을 만든 사람은 Presentaion Zen 이라는 책을 보고 프리젠테이션 작성법에 대해서 영향을 받았다고 하네요. 어떤 책인지 한번 읽어보고 싶어집니다. 아마존 서평 별 네개 반 짜리네요.