Life is wonder-ful

The story is well known, though the role that communities of practice played is less widely understood. At the time, Chrysler was a traditional organization typical of large manufacturing operations, with functional units such as design, engineering, manufacturing, and sales. The design department would send a new design to engineering, which would send it back for redesign a few times. The design would then go to manufacturing and be returned for reengineering until the vehicle was deemed "manufacturable." The localized focus of the various functional units limited interaction between departments and thus gave rise to these unavoidable interactions. Repeated hand-offs, duplication, and therefore slowness, were built into the system.
--Cultivating Communites of Practice

"Repeated hand-offs, duplication, and therefore slowness, were built into the system." T.T

몇 년 동안 잘 썼는데 그제부터 소리가 안나온다. 단자와 선연결 부분을 만져서 조절하면 소리가 들린다. 올 것이 왔다. 이어폰이나 헤드폰을 사면 항상 이 연결부가 망가져서 못쓰게 된다. 지금 쓰는 PX 10도 산지 얼마되지 않아서 연결부가 망가졌다. 마침 다니던 회사에 인두 등 공구가 있어서 연결부를 뜯어서 새로 납땜을 해려고 했다. 하지만 종류가 다른 납인지 일반 인두로는 녹지가 않았다. 붙어 있던 납 녹이는 것은 포기하고 다른 곳에 남땜하려 했지만 납이 붙지도 않았다. 방치해 놓고 있다가 옆에 있던 친구가 무료로 수리해준다는 곳을 발견해서 고쳐서 지금까지 잘 쓰고 있었다.



쓴지도 오래 됐고 가벼운 헤드폰을 하나 살까해서 주위에서 많이 쓰는 Bose Triport OE 가격을 물어봤더니 20만원 조금 안된단다 =.= 내 오디오 스피커 값이랑 비슷한다. 가난한 자취생이라 이십만원 짜리 헤드폰은 못산다. 어차피 금방 망가질텐데 흥. 하지만 Triport OE를 포기할 수 없는 한가지 이유. 선이 Y자형이 아니라 한 쪽에만 있는 I자형! Y자형은 선이 꼬여서 영 불편한데 한 줄만 있으니 선이 꼬일 수가 없다. PX 10으로 대강 선을 이리 저리 배치 해보니 오호 I자형으로 만들 수 있을 것 같다. 고쳐쓰기 다시 한 번 도전 해보자.

일단 프로토타입을 구현했다. 스카치 테이프로 고정해서 만들었다. 착용도 해보고, 선을 머리 위로 한 바퀴 돌리니 선이 짧다. 마침 쓰던 연장선이 있으니 선이 짧아지는 문제는 해결 할 수 있다. 이제 연결부 남땜만 다시 하면 된다.




일단 연결부 분해. 깔끔하게 플라스틱 덥개를 분리할 수 없었다. 반을 갈라서 뜯어냈다. 덥개 안에는 플러그가 선과 연결되어 있다. 덥개, 플러그, 선을 다 분리한다.


선의 끝부분을 잘라 낸다. 선이 중간 중간 끊어져 있어서 조금 많이 잘라내야 했다. 고무 피복을 벗기고 적색선과 청색선은 놔두고 동색선은 한가닥이 되도록 꼰다.


선 끝부분을 라이터로 그슬려 절연 피복을 벗긴다.


남땜하고 테스트. 원래 붙어 있던대로 청색, 적색, 동색 순으로 플러그에 납땜한다. 고정대가 없어서 두 발까지 썼다. 시간 많이 걸리고 납연기도 한가득 마셨다. 콜록. 다행히 이번에는 일반 인두로도 납이 잘 녹는다. 납땜 후에 아이포드에 연결해서 테스트 한다. 잘 들리다.


남땜이 다 드러난 상태로는 보기도 좋지 않고 건강에도 좋지 않으므로 피복을 입힌다. 어슬픈 납땜 덕분에 뚱뚱해져서 원래 플라스픽 피복은 사용할 수가 없다. 만능 글루건으로 실리콘 피복을 입히자. 글루건의 열 때문에 절연피복이 녹을 수 있으니 종이 조각을 선 사이에 넣는다.


글루건으로 실리콘을 조금씩 발라서 선과 플러그를 고정시킨다. 다 마르면 실리콘을 듬뿍 바르고 조금 기다린 다음 포스트잇으로 원통형 틀을 만들어 둘러 싼다. 마를 때까지 기다렸다 포스트잇을 떼어나면 대강 모양이 나온다. 칼로 모양을 다듬는다.


연결부 수선은 완료 되었다. 이제 가조립 해놓았던 스카치 테이브를 떼어내고 순간접착제로 선을 완전히 고정시킨다. 짜잔 완성.

선은 요렇게 되도록 티나지 않게 붙여 놓았다.


좋지 아니한가. I자형 선. 훼훼훼훼훼. 음악들으며 달리기 하러 가야지~

아................................... 오른쪽, 왼쪽 연결이 반대로 됐다. 연결되어 있던 그래도 연결했는데. 몇 년 전부터 반대였던거다. 다시 뜯어서 남땜 하기는 싫고... 그냥 듣자고 생각했으나 연장선을 빼고 시험해보니... 연장선 문제다 =.= 이런 불량 연장선 같으니라고. 깜작이야.

by Lee Lefever

늑대는 우랄 산맥으로부터 지브롤터 해협에 이르기까지 유럽 전체를 무대로 하고 있었고, 곰은 이곳의 산악지대에 살고 있었다. 도처에 늑대가 있었고 늘 늑대를 조심해야 했다는 점 때문에 늑대 사냥은 시골이든 도시이든 그 지역이 얼마나 '건강한가'에 대한, 그리고 그해가 얼마나 살기 좋은 해인가에 대한 지표가 될 정도였다. 잠시라도 주의를 늦추거나, 경제가 후퇴하거나 또는 겨울 사정이 나빠지면 늑대 수가 증가했다. 1420년 성벽의 틈새를 통해, 또는 간수가 없는 성문을 통해 늑대떼가 파리로 들어왔다. 1439년 9월에 다시 늑대가 출몰했는데, 이번에는 파리외곽의 몽마르트와 생-탕투안 성문 사이에서 사람들을 공격했다. 1640년에는 늑대가 두 강을 건너 물레방아 근처를 통해 브장송 시에 들어와서 "길거리에서 아이들을 잡아먹었다." 1520년경에 프랑수아 1세가 창설한 늑대 사냥 부대(grands louvetiers)는 영주와 마을사람들을 징발해서 몰이사냥을 했다. 1765년에 제보당에서도 "늑대 피해가 엄청나서 괴물 같은 늑대가 한 마리 있다고 믿게 되었다." 1779년에 한 프랑스 인은 이렇게 썼다: "600년 전에 영국에서 그러했던 것처럼 사람들이 프랑스에서 늑대를 멸종시키려고 하는 것 같다. 그러나 이런 것은 영국 같은 섬나라에서는 가능할지 몰라도 프랑스처럼 넓고 사방으로 열려 있는 나라에서는 불가능하다." 그러나 1783년에만 해도 상공 회의소 의원들(Députés du Commerce)은 "영국에다가 늑대를 많이 들여보내 대다수의 인구를 없애버리자"는 몇년 전에 제기된 제안을 토의하지 않았던가! 비록 늑대가 유럽 대륙의 대지에, 또 독일이나 폴란드의 먼 삼림지대에 붙박혀 있다고 해도, 프랑스는 늑대에 대해서도 교차로 역할을 하는 지리적 상황을 벗어나지 못했다. 1851년까지도 베르코르에서는 아직 늑대 피해를 입고 있었다.
--일상생활의 구조, 물질문명과 자본주의

유럽에서 늑대인간 이야기가 나올 수 밖에 없었구나. 우리나라에는 조만간 소인간(Werecow)이 등장할지도.

야구장 가서 회식했습니다. 27일 잠실 두산-LG 전. 두산 쪽에 가서 놀았는데 LG 응원 아가씨들이 더 이뻐서 두산의 역전 승리와는 상관 없이 다들 아쉬워했다는...

IEEE Software 접근 가능하신 분은 꼭 보세요.

* Morality and the Software Architect by Grady Booch

...Several readers suggested that, in light of this inevitable current, the individual can do nothing to stop it, for even if one person says no, another will take her place. On this point, I violently disagree, for history is full of stories of one person, or a small group of people, radically changing the world. Finally, others gave the usual arguments that, as a code warrior, they are “only following orders.” Well, as the phrase goes, no single raindrop believes it’s responsible for the flood, but ultimately, the flood sometimes does come. Ignoring an ethical issue is a moral position unto itself—perhaps the easiest path to take, but also the most cowardly.

직업 윤리. 최소한 스스로의 양심에 반하는 일은 하지 않기.

* Valuing Design Repair by Rebecca J. Wirfs-Brock

Because we can’t prevent certain antipatterns, we need to better plan for and perform necessary repairs. The optimal time to remedy an antipattern isn’t when a project is in crisis but when there’s a slight lull in the action, yet an urgent need to make improvements.

시간이 흐르면 소프트웨어도 낡는다. 낡은 부품은 교체하거나 수리해야 한다. 하지만 수리는 일로 인정해주지도 않는다. 게다가 낡은 소프트웨어를 고치는 일은 무지하게 어렵고 힘들기까지 하다. 하지만 고장만 부품을 방치하면 결과는 뻔하다. 괴로운 사람은 떠난다. 남은 사람은 더 괴로워 진다. 무한히 반복된다. 더 빠른 주기로.

이런 스타일 좋아한다. 화평본위도 무지 좋아했었지. 언능 개봉했으면 좋겠다.

짠하네 짠해.



양조위랑 장만옥 체격이 동급이라.



짠하네 짠해.



아저씨 제사밥 먹는 걸 보니 갑자기 배가 고파져서.

Rough visual(?) explanation of Pingback 1.0

이름 없는 목공의 이름 프로젝트 첫 번째로 현재 진행 중인 프로젝트에 RSS/Atom 피드 기능을 넣기로 했다. 다음에는 pingback을 추가해볼까 생각 중이다. 팀의 동의 없이 하는 일이므로 절대 전체 프로젝트의 복잡도를 높여서는 안되고, 언제든지 제거할 수 있어야 하는 조건이 있다. 20분 단위로 뛰어 보기로 했다.

첫 번째 뜀박질. 피드를 제공하려면 정보를 RSS나 Atom 규격에 맞게 출력해야 한다. RSS나 Atom 규격을 모르지만 지금 먼저 공부하고 만들려면 시간이 너무 많이 걸린다. 피드 제공이 목적이지 피드 규격 파악이 목적이 아니므로 적당한 라이브러리를 쓰면 된다. 입사하면 피드 리더 만들게 해준다는 낚시에 걸려서 봐둔 Rome을 사용하기로 했다. 튜토리얼의 소스 코드를 복사하고 조금 고쳐서 XyzFeed 클래스를 만들었다. 그냥 System.out으로 출력해서 결과를 확인했다.

두 번째 뜀박질. 앞에서 만든 XyzFeed를 XyzAction에서 불러 쓴다. XyzFeed의 결과를 System.out 대신에 StringWriter에 출력하고 StringWriter에 쓰여진 출력을 toString으로 뽑아서 XyzAction에서 getter로 Result에 노출 시켰다. Result는 Freemarker 템플릿을 하나 만들고 노출된 getter에서 값을 얻어 그대로 출력하도록 했다. 실행해보니 출력이 깨져서 나온다. SiteMesh 데코레이터가 적용되어서 생기는 문제다. 이 문제를 제외하고는 잘 나온다.

세 번째 뜀박질. SiteMesh 데코레이터가 적용되지 않게 하려면 content-type을 바꿔줘야 한다. 여러가지 방법이 있지만 RomeResult를 만들어 SyndFeed를 HttpServletRespnse에 바로 출력하기로 했다. RomeResult도 분명 누군가 만들어 놓았겠지. 검색하니 나온다. jar 가져와서 maven 리포지토리에 올리고 하면 골치 아프니 그냥 소스를 복사해 왔다. result 설정을 RomeResult를 사용하도록 수정하고 XyzAction에서 문자열로 포맷팅하지 않고 SyndFeed를 getter로 Result에 넘겨줄 수 있게 수정했다. 다시 실행해보니 브라우져가 피드로 인식해서 이쁘게 보여준다. 기능은 여기서 완료. 만세~

네 번째 뜀박질. URL 고민.

다섯 번째 뜀박질. XyzFeed 리팩토링. RomeResult의 테스트 추가.

여섯 번째 뜀박질. 테스트를 추가하면서 리팩토링된 RomeResult를 테스트와 함께 원래 프로젝트인 s2rome에 제출하기로 했다. SVN에서 소스를 받아서 빌드하니 안돌아간다. 필요한 라이브러리를 일일이 찾아서 lib에 넣어주고 테스트 확인했다. jMock을 썼더니 필요한 jar가 많다. 혹시 모르니 Result의 Lifecycle을 찾아보고 RomeResult에서 잘못된 부분이 없는지 확인했다. 패치 파일과 함께 이슈에 등록.

구현에는 5 * 20분 = 100분 = 1.5 시간 밖에 안걸렸다. 뭘 만들지가 분명하면 만드는데는 거의 시간이 걸리지 않는다. 구현이 병목이라고 생각하는데 아닌 것 같다. 실제 프로젝트 시에도 구현 기간의 상당 시간이 구현하면서 발견된 앞단계에서 정해진 결정의 문제점을 개선하는데 쓰이는 것 같다. 결정에서 구현, 테스트가 멀어질수록 더 멀리 거슬러 올라갔다 내려와야 하기 때문에 시간은 많이 걸릴 수 밖에 없다. 직렬(Sequential) 도랑(Ditch) 프로세스가 병목이다. 지나친 확대 해석인가?