sosa0sa.com

변명이 궁색하다는 걸.하지만 절대적인 시간이 부족한 것 또한 사실이다.

아킬레스 건은 빨리 없애야 할 텐데

새벽 3시에서 4시 사이인 듯하다.

며칠 째 모기의 선방을 맞고 일어나서 쫓아다니는 일을 반복하고 있다.

잠을 잔 것 같지가 않다. -_-

어제 자기 전에 전에 물린 자리에 알라딘 아저씨가 소개해주고 위책임도 기능을 확인해 주신 뿡뿡이 밴드를 4개나 붙였는데 오늘 새벽에 3개 추가했다. 별이 7개 -_-

모기향을 피워야 하나. 문을 닫고 자도 어디서 모기가 생기는 걸까?

1. 아이 방을 고립시키지 마라. 아이 방의 문을 열어두거나, 방문 재질을 투명하게 바꾼다.
2. 집 안 전체를 공부방으로 만들어라. 가족들 모두의 공간인 거실, 부엌도 아이가 공부할 수 있는 환경으로 꾸며준다
3. 6개월에 한 번씩 이사하라. 6개월에 한 번 정도 가구 배치를 바꿔보자.
4. 공유할 수 있는 추억의 공간을 연출하라 한 책꽂이에 가족들 모두의 책을 꽂는 등 가족의 기억을 공유하는 공간을 만든다.
5. 어머니의 공간을 멋지게 꾸며라. 어머니가 행복하면 아이도 행복하다.
6. 아버지의 존재를 느끼게 하라. 아버지와 아이가 각자 다른 일을 하더라도 같은 공간에서 하도록 한다.
7. 종종 손님을 초대하라. 아이에게 가족 이외의 사람과 어울릴 기회를 준다.
8. 오감을 자극하는 공간을 만들라. 거울 하나에도 신경을 써서 아이의 감각을 발달시킨다
9. 글로 의사소통하라. 보드 칠판 등 아이와 글로 의사소통할 장치를 만든다.
10. 갤러리 공간을 만들어라 가족의 작품을 집에 전시한다.

좋은 공부방을 만들어주면 공부 잘하는 아이가 될 거라는 생각은 두뇌에 대한 편견에서 나온 것이다. 공부방에 혼자 틀어박혀 꼼짝도 하지 않고 공부하기보다는 다양한 수단으로 커뮤니케이션을 나누고 신체를 움직일 수 있는 환경을 조성해주는 것이 머리 좋은 아이로 키우는 비결이다. 두뇌 작용을 활발하게 하려면 몸을 움직여야 한다는 이야기는 익히 들어 알고 있을 것이다.

기종은 골랐다.

시보레 풀샥 을 골랐지만  공식적 스펙으로는 내 덩치를 버티질 못한다고 해서 Dahon Boardwalk D7으로 골랐다.

자전거도 오디오나 카메라처럼  가격대가 천차만별이라는 이야기는 일찌감치 들었다.

이번에 자전거를 고르려고 카페를 둘러보니

• 처음엔 시보레 풀샥(20만 미만)
• 키/몸무게때문에 Dahon boardwalk D7 34만원
• 샥이 있고, 스피드가 조금 더 나가는 Dahon Jetsream은 78만원
• 그것보다 더 좋은 Jetstream XP는 140만원.

헉.

거기까지만 보고  그만뒀다.

내가 타야할 자전거는  결정했으니 더 이상 눈을 높이지 않기로 했다.

괜찮은 중고가 나왔으면 좋겠는데 매물이 별로 없다. 장터 좀 둘러보다 안 되면 동네 자전거점에 부탁을 하던가 안양에 있다는 가게에 한번 가봐야겠다.

근데 색깔은 뭘로 할까? Slate ? Sage? Brick? Stone?

다소 제목이 유치하지만…

컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 짤 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다.

코드는 보기 쉬워야 하고 시스템은(process)는 사용하기 쉬워야 한다.

그렇지 않으면

내가 짠 코드를 내가 이해하지 못하고 아무리 잘 정립한 프로세스도 사용자가 그 장점을 이해하지 못한다. 왜냐하면 그저 불편한 또 하나의 규칙으로만 느껴지기 때문이다. 어제 문제 도 오늘 파트장과 상의하여 합리적인 방안으로 보완하기로 했다. “수정된 라인”은 무시하지 않고, “추가되거나 삭제된 라인 수”는 diff의 결과를 그대로 참조하기로 했다. diff의 경우 변경된 라인은 인식하지 못하고, 기존 라인이 삭제되고 새로운 라인이 추가된 것으로 해석한다.

즉

a

라는 내용을 가진 파일이 있는데 이 내용을

ab

로 변경하면 diff는

a

라인은 삭제되고

ab

라인이 추가된 것으로 인지한다.

cychong@funuy: ~ $ diff -u a a2
--- a   2007-07-13 21:54:53.000000000 +0900
+++ a2  2007-07-13 21:55:01.000000000 +0900
@@ -1 +1 @@
-a
+ab

아무렴 무슨 문제인가? 어차피 Clearcase가 버전 관리를 다 하고 있는데 뭐가 바뀌었는지 확인하고 싶으면 해당 두 개 버전을 비교하면 바로 알 수 있을 텐데, 시시콜콜 변경된 라인 수를 따로 알아야 할 이유가 없다.

(개콘의 한 코너 패러디)

A : 15년 S/W 역사를 가진 우리 팀은 S/W 품질 향상을 위해 최신 기술을 도입하고 있어요

B : 정말이예요. 그래서 이제는 소스 변경할 때마다

• 변경사유
• 추가된 라인 수
• 변경된 라인 수
• 삭제된 라인 수
• 최종 라인 수
• 추가된 코멘트 수
• 삭제된 코멘트 수
• 최종 코멘트 수

를 엑셀에 기록하라고 한다니깐요.

Clearcase는 폼인가? Diff나 Patch는 어디에 쓰려고?

속이 터지려고 한다.

추가) 알고봤더니 저런 “실행계획”을 만든 분은 Clearcase가 뭘 해주는 지를 전혀 모르고 있단다. 뭘 해주는 지 모르니 시스템을 신뢰도 하지 못하고 일일이 수기로 기록해야 모든 걸 믿을 수 있나 보다. 그런 분이 그 위치에 있으니 참 깝깝하다.

개발자가 수정하거나 새로 개발한 내용을 여러 브랜치에 적용하지 않아 발생하는 문제를 봐와서 저렇게 “관리”하고 싶은 마음은 이해하겠지만 그건 MR(Modification Request) 번호만 제대로 관리해도 쉽게 해결할 수 있는 문제다.

통상 개발자들이 코드를 수정하기 위해 MR을 따고, source 코드에 대한 unlock 요청을 한 후 해당 MR의 내용만 수정하지 않고 이런 저런 다른 내용도 수정하는 경우가 있다. 그러면 MR 사용에 대한 관리를 강화하면 된다. 해당 MR에 대한 필요한 코드 수정만 했는지, 필요한 브랜치에 해당 MR의 내용을 모두 적용했는지 등.

F.R David - I like Chopin, Gazebo - Words