doortts / blog Goto Github PK

View Code? Open in Web Editor NEW

0.0 0.0 0.0 0 B

blog's People

Watchers

blog's Issues

Blog2Book 자바 성능을 결정짓는 코딩 습관과 튜닝 이야기

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-05-04 일요일 오전 12:41 | Books | 원본

})

우선 우리나라에서 이런류의 책의 발간되었다는 사실에 약간 감탄하였다.

몇몇 비슷한 책이 출간되었었지만,

아직까지는 가장 마켓팅에서 성공한 책이지 않나 싶다.

내용은 저자가 현장에서 고생을 많이 했고,

단순히 고생으로만 끝내지 않고 공부도 적잖이 했다는 것을 알려준다.

다만,

구성에 있어서 다소 산만한 경향이 있다.

하나의 주제에 대해서 직접건드리기 보다는,

관련내용부터 시작하는지라 약간 뜸을 들인다고 해야 할까?

그런 덕분에 분량에 비해 하고자 하는 이야기가 다소 약해진감도 없잖아 있지만,

쉽게 숙숙~ 읽을 수 있는건 장점이기도 하다.

자, 그럼 나름 몇개 항목으로 정리해 보면~

전문성 : ★★★☆☆

책구성 : ★★★☆☆

난이도 : ★★★☆☆

흥미도 : ★★★★☆

--- attachments ---
zrclip_003n2e37d968.png

Eclipse 3.3 에서 왜 help system 이 extension 으로 정상 동작하지 않는가?

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-04-24 목요일 오후 5:50 | 이클립스 RCP | 원본

org.eclipse.help.toc

extension을 추가하는 것 만으로는 help 메뉴가 동작하지가 않는다.

현재 논의 되고 있는 차기 3.4 버전에서 이 help 지원이 향상될거라고는 하는데 어쨌든 우선은 아래와 같은 plugin 들을 target platform 에 넣어주어야 한단다. (그걸 어찌 알수 있었겠소!!!)

https://bugs.eclipse.org/bugs/show_bug.cgi?id=202160

})

Comments

흙내음이나오.
당신이 삽질한 이 대지에서...

M-o-N | 2008-04-24 목요일 오후 11:59

--- attachments ---
zrclip_009n42125b77.png

Firefox 3 드디어 출고!

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-06-19 목요일 오전 10:11 | 이생각 저생각 | 원본

})

280번만 더 다운 받아서 5만건이 넘었으면 좋았을텐데 하는 말 그대로의 숫자에 대한 살짝 아쉬움이 든다.

그래도 하루만에 전 세계적으로 천만건에 육박하는 다운로드를 기록하다니, FIREFOX도 대단한 것 같다.

우리나라도 하루빨리 Browser Independent day 가 왔으면 좋겠다.

*아래는 쿵푸팬더의 스승님인 Red Panda... Firefox의 마스코트가 여우가 아니라 이 Red Panda 였다는군요..

})

--- attachments ---
zrclip_001n3257c6b1.png
zrclip_002n72f095bd.png

JAVA 5 생명주기 종료 적응기간

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-06-15 일요일 오후 10:34 | 이생각 저생각 | 원본

})

JAVA 5 가 지난 4월 8일부로 EOL (End of life)의 적응기간에 들어갔다. 최종적으로는 10월에 기술 서비스가 종료된다. 저번달 부터 사람들에게 이야기를 했지만 그다지 큰 반응은 없다. 현장에서는 여전히 1.3, 1.4 1.5가 두루두루 쓰이고 있고, 1.5(JAVA 5) 보다는 (안타깝게도) 1.4가 더 많이 쓰고 있다고 한다.

1.5 (JAVA 5)를 쓰더라도 WAS에 따라 쓸 뿐이지 Annotation 이라던가 auto-boxing, 향상된 loop 기능을 적극 쓰는 사람은 많지 않은 듯 하다. (아키텍터들은 좀 반성해야 한다!) 뭐, 업무의 성격상 New Technology 를 적용한 구현 보다는 stable service 쪽에 더 관심이 맞춰줘 있기 때문이라고 (개인적으로 납득하기위해) 생각한다. 그리고 그에 더해 자사 개발 Framework 지원 문제가 관련되어 있는 것도 JDK 버전업을 어렵게 하고 있다. (JAVA JDK가 상위로 올라가면 동작이 이상해지는 - 그렇게 만들려고 해도 쉽지 않을 터인데 참 - 놀라운 자사 프레임웍에게 경의를!!)

여기까지는 잡담이고...

등돌리고 외면하던 작업(..)을 다시 시작하려고 오늘 HOME PC의 eclipse 아이콘을 눌렀더니 에러가 났다.

})

아! 맞다! PC 를 포맸했었지!!

핑계김에 오늘 부로 JAVA 6를 써 보려고 한다. java.sun.com 사이트에가서 JAVA 6 New Feature 를 보니, 적지 않은 내용이 있더군. 게다가 JAVA 6 가 update 6 에 update 10 beta 까지 나와있더군. 사무실에 계신 분들, JAVA 5 New Feature 도 모르시는데, JAVA 6까지 봐야 한다는걸 알면 어떤 반응을 보일까?

어쟀든 팀내 스터디(=교육)진행을 위해 나라도 먼저 봐 두어야 겠다.

--- attachments ---
zrclip_002n3fac77cd.png
zrclip_001p249d4ccf.png

1st

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-03-26 수요일 오후 4:17 | 이생각 저생각 | 원본

동욱의 도움으로
티스토리 입점.

기술적인 이야기를 해보려고 고민중임.(얼씨구)

Comments

얼씨구-
조타!

이런 저런 이야기 주저리 주저리 해보는 아이디어 좋다.
IT이야기 만담 식으로는 어때?

우리 대화를 재밌어 할 사람들이 www에는 있지 않을까...
없음 말구 OTL

M-o-N | 2008-03-27 목요일 오후 7:26

오랜만이 글을 쓰려고 보니까 '굉장히 힘든 일'이라는걸 알게 되었어! 도둑질도 해 본 놈이 한다고 (응?) 조금씩 쓰다보면 나아지지 않을까?

doortts | 2008-03-28 금요일 오후 1:56

Eclipse Europa 로 RCP 만들기, 부제 : 좌절금지

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-04-24 목요일 오후 4:20 | 이클립스 RCP | 원본

내가 아는 한 세상에 나온 본격적인 RCP 책은 단 한 권뿐이다.

})

바로 이책이다.

2006년에 원서로 스터디를 하다가, 팀원들 다 좌절드시고 혼자 버둥대다가, 작년에 번역서가 나오면서 올해 다시 시작하고 있는데, 참 잘 쓴 책이란 생각이 든다. (정말 개발 많이 해본 사람이 쓴 책이라는걸 설명도 없이 지나가는 부분에서 문득문득 느끼곤 한다.)

다만 아쉬운 점이 하나 있는데 바로 이클립스 3.1 기준으로 쓰였다는 점이다.
(책 겉면에도 'eclipse 3.1의 새로운 RCP 기능 어쩌구 하는 문구가..)

현재 3.3 (유로파) 이 대세이고 곧 3.4가 나오며 e4( eclipse 4) 준비 중인 시점에서 3.1로 시작하는건 좀 아니지 않냐? 라는 이상한 자존심에 3.3으로 어찌어찌 진행중인데 곳곳에 함정이 기다리고 있다.

특히, 근래에 겪은 extension 을 인식하지 못하는 상황은 나를 심히 좌절시켰었다. 문서도 없고, 논의글도 없어서 정말 어렵게 어렵게 try and repeat 형태로 우회하는 방법을 알아내었지만, 영 찜찜함이 그지없었다.

그냥 3.1로 깔로 착실하게 책대로 가야 하나 하는 고민에까지 빠져들게 했는데..

})
(뜬금없는 엄한 사진..)

그러다 이틀전!

문득 떠오른 생각 하나! 혹시 버그 아니삼? (-,-);;;

})

업데이트를 해 보았다.
})

잭일슨!!! eclipse.org download 에도 없는 3.3.2 버전으로 update 가 되면서 문제가 사라진 것이다!! 어쩐지 논리적으로 말이 안되더라 싶더니만.. 업데이트(패치)로 해결이 되다니...

아는 사람도 없고, 해당 부분을 하는 사람도 없으니 구굴에서 문제제기를 하는 사람도 없고.. (몇몇있는데 그들도 못찾고 뻘짓중이더라..)

어쨌든 그리하여 또 한 고비를 넘겼다. 최종적으로 스터디를 마치게 되면 그간 고생한 내용을 정리해서 공유해야 겠다는 생각 뿐이다.

힘들구나~ 힘들어~~

--- attachments ---
zrclip_001n5795bc63.png
zrclip_006n71660c6d.png
zrclip_007n494c4dc1.png
zrclip_005n27432a13.png

1장 - 테스트주도개발 Test Driven Development

@doortts (doortts) 님이 작성한 이슈입니다.
---

이전: "TDD 실천법과 도구" 책 전체를 PDF 공개합니다
다음: 2장 - JUnit and Hamcrest

안내: 본문을 읽지 않고 아래의 코멘터리만 읽는 걸 가정해서 작성하진 않았습니다.

1장 본문

01-테스트주도개발.pdf

읽기전에

우선 목차에 있던 어떻게 읽을 것인가를 보고 자신이 어떤식으로 읽어야 시간절약이 될 지 확인 필요합니다.

편하고 빠르게 읽기를 바랍니다.
TDD에 대한 필요성과 의욕이 확실하다면 skip scan 으로 읽으세요.
TDD를 배우는 사람 입장이라면 1장의 계좌(Account) 예제는 눈으로 그냥 읽는 것과 실제 타이핑해가면서 실행해서 보는것과의 차이가 극단적으로 매우 큰 예제입니다.

도전과제

Javascript나 TypeScript로 실습을 따라갑니다

보충 설명

각 장마다 첫 페이지에 실패에 관한 격언들을 담았습니다. 그 당시 좋아했던 문장이었던 지금은 흑역사의 감독이 되어버린 우디 앨런의 문장으로 시작했습니다.

만일 당신이 때때로 실패하지 않는다면, 그건 안이하게 살고 있다는 확실한 증거다.
- 우디 앨런

이 장에서는 TDD의 아주 기본적인 접근 법을 소개 하고 있습니다.

현재의 흔한 개발방식의 문제점과 TDD가 좋다는 식으로 표현하고 있는데, 어떻게 보면 이 인간 약을 팔고 있구나!라고 생각이 들 수도 있습니다.
좋다는 이야기와 약판다는 이야기 둘 다 틀린이야기는 아닌데요 다시 쓴다면 강조하는 관점을 좀 다르게 둘 것 같습니다.

이를테면..

좀 더 개발을 잘 하기 위해 우리는 다양한 노력을 하고 있습니다. 그리고 개발자 자신도 스스로를 다양한 방식으로 진화시키기 위해 노력하고 있죠.

그 와중에 소위 발하는 개발 실천법(practice)이라는 이름으로 여러가지 기법이나 방식들이 등장했습니다.
익숙해짐과는 별개로 우선 바로 배워서 시작할 수 있는 실천법들로는

디자인패턴(Design Patterns)
리팩터링(Refactoring)
객체지향 설계분석(OOAD, Object-oriented analysis and design)
CI(Continuous Integration)
코드리뷰(Code Review)
짝 프로그래밍(Pair Programming)
종이 프로토타이핑(Paper Prototyping)
종이와 연필 설계(Pen & Paper design)

등등이 있습니다. 그리고 그 중간 어딘가쯤에 마찬가지로 자동화된 유닛테스트(Automated Unit Test)와 TDD(Test Driven Development)가 포함되어 있다고 생각하시면 좋겠습니다.

즉, TDD를 (잘) 한다는 것이 곧 좋은 SW를 만들어 낸다던가 뛰어난 개발자가 되는/된 척도가 되는건 아니라는 거죠. 그냥 practice 중 하나이고 다른것보다 좀 더 어렵고 대신 조금 더 강력하게 동작할 수 있는 기법일 뿐입니다.

좀 더 강조 되었어야 했다고 생각하는 부분

아주 간단한 sum 에 대한 예제에서도 사전설계가 먼저 되었고 요구사항을 확인해서 무언가 문서로 만들었다는 점에 주목해주세요
- 이 부분에 관한 이야기는 뒷 챕터에서 좀 더 자세히 이야기 할게요
TDD의 목표는 TDD 하는 개발자가 아니다.
은행잔고 예제가 너무 쉽고 비현실적이라고 생각하실 수 있습니다만 목표를 보셔야 합니다.
- 개인적으로 지금은 IntelliJ로 전환한지 오래되었.
작성된 테스트를 기반으로 계속 정제하고 있다는 점
그리고 테스트가 만들어졌으면 더럽더라도 무조껀! 최대한! 빨리! 테스트를 통과시키는 연습을 해야 합니다.
- 그래야 리팩터링과 다음 코드 작성으로 이어지는 부분을 더 리듬감 있게 진행할 수 있습니다.
저자 한마디를 놓치지 마세요. TDD를 떠나 매우 중요한 내용입니다.

생각이 살짝 바뀐 부분

자신이 얼마나 설계를 못하고 의존적이며 즉흥적인 코딩을 하고 있는지 (=엉터리 개발자인지) 알게 된다.

깨알

2장 예고. JUnit과 Hamcrest

--- attachments ---
01-테스트주도개발.pdf
269-20187-18-1916-38.png
33-20187-18-1916-56.png
704-20187-18-1923-47.png
830-20187-18-1925-40.png
919-20187-18-1929-24.png
246-20187-18-1933-35.png
306-20187-18-1932-50.png
83-20187-18-1946-10.png
889-20187-18-1947-12.png

Java 언어로 배우는 디자인 패턴 입문(개정판)

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-05-04 일요일 오전 12:19 | Books | 원본

현재 상태 : WANTED

})

예전에 이 책의 2편(쓰레드)을 옆 동료한테서 살짝 빌려서 본 적이 있었는데, 꽤 괜찮았었던 걸로 기억한다.
새로 개정판이 나왔다고 하는데 봐야겠다는 의지가 살살 생긴다.

Head First : Design Pattern 책이 워낙 잘 나왔었기에 (= 개인적으로는 읽고서는 쇼크상태까증..-,-) 과연 어떨까 싶은데, 우선 연습문제라는 것들이 있어서 나름 자극이 되지 않을까 싶다.

Comments

이 책 초판하고 헤드 퍼스트 둘다 봤었는데요..
초판은 절판으로 빌려서 봤었어요.
이 책이 더 이해가 쉬운듯 하네요..ㅋ
아마도 영어번역 보다는 일어 번역이 더 쉽기도 하고..
헤드퍼스트는 약간.. 그림 난발이자나요 ㅋ.

루비시안 | 2008-05-21 수요일 오전 11:15

그 옆 동료... -_-;;
응 이 책 참 잘썼던겄같아. (내가 개정 이전의 판본을 봐서 이리 애매한 표현밖에...)

M-o-N | 2008-05-24 토요일 오전 1:23

--- attachments ---
zrclip_001n294b57f4.png

일기장

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-05-13 화요일 오전 10:58 | 이생각 저생각 | 원본

내가 내 인생의 4년이란 세월을 쏟은 전공(과목)이란 것을 버리고 이 업계를 향했을 때, 내 마음은 순진 그 자체였다. 컴퓨터를 가까이 하고, 그 걸 통해 무언가를 만든다(create)는 사실에 대단히 흥분해 있었다. 그리고 아주 소박한 개인목표를 하나 가졌었는데, 그건 내가 만든 일기장으로 일기를 쓰는 것이었다. 다만, 거기엔 조건이 하나 있었는데 그 일기장은 웹이 아니라 클라이언트 프로그램이여야 한다는 것이었다.

})

7 years passed away..

세상이 변했다. 나도 변했다. 많은 기술을 접했고, 그리고 그 만큼이나 잊었다.

하지만 난 아직 일기장을 만들지 못했다.

블로그에 글을 매일 올리면 되지 않느냐? 웹 사이트도 하나 갖고 있지 않느냐?

반문할 수 있는데, 사실 그건 사기꾼 소리조차 듣지 못할 유치한 변명일 뿐이다.

JAVA 가 창궐했을때, 자바로 만들면 어떨까? 생각했었는데, 그 충격적인 Desktop application speed에 손을 놓았다. (정신은 이미 한참전에 놓고 살았던지라 그건 놓고 말고도 없었고..-,-)

흠흠.. 어쨌든 상황도 많이 바뀌었고, JAVA 가 느리다는 것도 어디까지나 상대적인 이야기이지 desktop application 으로 충분히 쓸만한 시절이 되었다. 덕분에 요새 들어 다시 한번 일기장 만들기의 꿈이 살살 올라오고 있다. 어쩌면 지금이 기회가 아닐까? 싶기도 하다. 시도해 볼까나?

--- attachments ---
zrclip_006p78b59378.png

페이스북과 블로그

@doortts (doortts) 님이 작성한 이슈입니다.
---

페이스북을 잘 안하게 된지 몇 년 되었다.
이유는 SNS의 이면성에 대해 질린부분도 있고,
현실에서 옆에서 보면 도덕적으로나 행동이 SNS에서의 사람들의 선망과 좋아요와 너무나도 다른경우가 종종 있고, 그런 불일치의 괴리를 SNS에서 보면서 여러가지 회의감이 들었기 때문이다.

자신에 대한 반성과 두려움도 함께 가지게 되었고.

그럼에도 지나고 보니 내가 바쁘게만 살고 남기는 것을 하지 않는건 기억력이 낮은 내 입장에서는 아쉬움도 커서 소소하게라도 다시 뭐라도 조금 적어봐야겠다는 생각이 든다. 사실 바쁘기로는 여지없이 바쁜 시절이지만.

글도 안써버릇하니 잘 못쓰겠다.
하하하.

IT (=In This?) World

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-04-21 월요일 오후 1:14 | 이생각 저생각 | 원본

'사람들의 삶의 질을 향상시킨다'다는 기치 아래 존재하는 이 세상(IT)은
매우 아이러니 하게도 그 참여자들의 삶은 곧잘 어지간한 3D는 저리 가라 하는 수준밖에
되질 않곤 한다.

밤낮없이 자신의 Life meter 를 줄여가면서 일하지만,
그 결과 누리게 되는 댓가는 무엇인가?

})

좀 더 나은 시스템과 종사자들을 위한 신기술은 끊임없이 나오고 있지만,
열심히 따라가려 노력해도 그 성과가 눈이 쉽게 보이는 일은 잘 없다.

기술들과 그에 바쳐진 사람들의 피와 땀은 결국
시스템을 팔팔하게 살리지만, 정작 본인들은 그 장소에 환멸을 느끼곤 한다.

나 또한 청소차만 지나다니는 새벽길을

'내가 무슨 큰 부귀영화를 누리겠다고 이리 살고 있나?'

하며 눈물 주륵주륵 흘리며 출근하던 시절이 있었다.

그런시절을 겪으면서도,
여지껏 내가 이 업계에 남아 있는 이유는,

별것 아닌 오기 한 점,

조그마한 바람 한결에 지나지 않더라도
업계의 삶을 바꾸어보리라, 내 주변 만이라도 다른 세상의 아침을 맞이하게 하리라 하는
치기어린 목표가 있어서이다.

실력을 키우고, 힘을 키워
어떻게든 노력해보고 물러나도 물러나야하지 않겠나... 하고 생각하고는 있는데,

지금처럼 해서 과연 그런 날이 올까?

싶은 생각에 마음 한켠이 살짝 시려온다.

--- attachments ---
zrclip_001n7950a51b.png

프로그래밍 수련법

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-05-04 일요일 오전 12:47 | Books | 원본

})

서점에 봤을때는 사실 눈에 잘 안들어 왔는데, 서평이 나쁘지 않아서 다시금 관심이...

--- attachments ---
zrclip_004n7fb407e0.png

Agile Day 참석 후기

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-06-26 목요일 오후 10:21 | 잊기전에 회고 | 원본

Session1.

김창준 애자일컨설팅 대표님의 agile 소개 강연을 들었다. 실제 본건 두번째, 강연을 들은 건 첫 번 째다.

간결하고 전문적이다. 특별한 군더더기 없는 글자와 심플한 그래프 몇 개로 하고 싶은 말을 다 하더라. (멋지다!)

가급적 적극적으로 행사에 임하자! 주의 인지라 질의응답시간 때 제일먼저 질문했다.

질문은 "agile 은 소규모 프로젝트에서 큰 효과를 발휘한다고 알고 있는데, 큰 규모의 기업에 해당 방법론을 적용하기 위해서 고려되어지거나 변경되어지는 부분은 무엇인가?" 였고 대답은 요약하면 "일부를 변경하던가 하는 식으로 실천방법을 좀더 유연하게 적용한다" 였다.

이후 몇 가지 질의 응답이 이루어졌다.(노트를 두고와 못 적었더니 기억이 전혀...-,-)

중간 쉬는 시간에 쉬시는 김창준님을 내가 곁에가서 질의 응답으로 괴롭혀 드렸던것 같다. (화장실도 못가게 테러를... (죄송합니다!) )

좋은 이야기를 많이 들을 수 있었던것 같다. (쉽게 미소짓는 얼굴은 아니시지만, 친절하시다!)

Session2.

agile 방법론을 발표한 자사 발표자가 다소 거세게 공격당했다.

내 생각엔

'agile쓰라는데말야, 그러려면 뭐뭐뭐가 문제일텐데 어떻게 해결할거야?' 라며 되물음 당하기 보다는

'아! 저걸 적용하면 저렇게 이득을 얻으수 있는거군!! agile을 적용해야겠는걸!!이 프로젝트에서 쓰려면 뭐뭐뭐가 문제니까 어떻게 해결해서 agile 을 적용시킬까?' 라고 스스로에게 자문하게 만들었어야 하지 않았나 싶다.

난 이번에도 질문을 했는데, (튀고 싶진 않았지만 어쨌든..-_-)

휴대용 CD Player 제품경쟁 시대에서 튀어나온 MP3플레이어 이야기를 들어가며 나름 기대하고 있는 방법론이란 이야기를 꺼냈고,

이어서 너무 많은 질문이라 답변대신 질문만 한다며 아래와 같은 질문을 했다. (집에와서 메일로 발표자에게 보냈다)

1. Agile 에 경험있는 one man hero 가 팀을 끌고가는 식이 되버리기 쉬울듯 한데 어떻게 생각하시는지?
2. 프로젝트 참여 구성원의 자질로 요구되는 것이 있는지?
3. 신규 구성원들의 agile 에 대한 이해 및 적응 부분은 어떻게 해결한 것인지?
4. Agile 방법론에 대한 학습곡선 효율증진을 위한 전략은 있는지?
5. 방법론의 전파(전개)계획은 어떻게 세우셨는지?
6. Benchmarking 하였거나 혹은 agile 적용 결과나 수치 등을 제시할 수 있는 국내외 그룹(회사)이 있는지? (가급적 국내로)

....

이하 생략

....

세미나 종료 후

중간 쉬는 시간에 김창준님을 괴롭혔기에, 이야기 도중 끊겨버린 이야기는 차마 이어서 묻지 못하고 집에 가려는데, 뒤에서 먼저 선듯 말을 걸어주신 김창준님! 안그래도 평소 고마운 마음이 있었는데 짧게나마 음료수 한잔 대접해 드리며, 잠시나마 이런저런 좋은 이야기를 조금 더 나눌 수 있었다. (감사합니다!) 그리고 Sten 에서 진행하는 교육 이야기를 했더니, 이야기해서 3일차 만이라도 참석해 보라고 권해 주셨다. 다음에 기회가 닿으면 좀더 많은 이야기 나눌 수 있었으면 좋겠다.

한가지 더!

회사 동료 도움으로 또 하나의 좋은 인연을 만났다. 흔치 않은 분야에 대한 공통 관심사를 가진 사람을 만난다는건 생각보다 쉽지 않은법인지라... 다만, 곧 한국을 떠날거란 사실은 못내 아쉬움이 남았다.

Comments

그 MP3는 (사실 나는 당신에게 그 비유를 세번째 정도 들었던 것 같아 --;) 너무 나도 통쾌했다오!
우흐흐

M-o-N | 2008-07-01 화요일 오후 10:34

이런 글을 읽다보면, 내 머리가 너무 텅 비어있다는 생각이 드니.. 이거 참..

김은혜 | 2008-10-26 일요일 오전 1:44

eclipse 3.4에 탑재된 equinox p2에 대한 시끄러움들

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-06-01 일요일 오후 12:45 | 이생각 저생각 | 원본

eclipse 3.4에 탑재된 equinox project2 (이하 p2)에 대한 갑론을박 이야기가 끊이지 않고 있다.

처음에는 몇몇 사람들의 eclipse update 에 대한 불만정도로 이해했었는데, 광범위하게 이야기가 번져서는 p2 프로젝트 팀원들에 대해 일종의 분노(?)까지 나타내는 사람들이 늘고 있다. (참조 : planeteclipse.org)

대략 이야기는 p2를 적용하면서 software update 가 완전히 바뀌는 바람에 **'적응이 대략난감!'**이라는 형태인것 같다. 사실난 아직 3.4로 올라갈 생각이 없기 때문에 뭐라 하긴 어렵지만, 많은 사람이 불편하다고 말할 정도면 불편한건 맞는것 같다.

P2 팀에서는 좀더 유연하고 확장 가능한 형태로 update 를 바꾸었다고 말하고 있는데, 글쎄..
(사용자 적응의 문제인건가? 아니면 개발이 잘못 가고 있는건가? )

현대의 SOFTWARE에서 눈여겨 봐야 할 부분은 Flexibility = Cost 이기 때문에 둘 사이의 균형이 중요한 것 같다.

어떻게 될런지는 좀더 지켜봐야 겠다. (그때까지는 eclipse 3.4로의 upgrade 는 이런저런 이유로 잠시 보류!)

})

Software updates를 선택하면..

})

이런 화면이... -,-;;;

결국 머리속에 드는 생각은.. '음.. 업데이트는... next time으로 미루..'

--- attachments ---
zrclip_002n3b2969b.png
zrclip_001n2a80682e.png
zrclip_003ncb28ec7.png

세렌게티 초원에는 물소들만 날뛰고... (응??)

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-04-10 목요일 오후 2:52 | 이생각 저생각 | 원본

})

팀 내에는 좋은 책들이 (이미) 많고,
또 적절히 좋은 책들을 들여오고 있는데,

다행히도 '우왓!' 할만한 좋은 책이 들어와도
읽기 위해 팀내에서 경쟁(?)을 하지 않아도 된다.

이런 기쁜 상황에 눈물이 앞을 가린다.

흑흑..

ps. 이 글을 쓰려고 맘 먹은 순간 뒤에 앉은 모 군이 신간 책 하나를 인터셉트(인터럽트?) 해갔다.

나야 차차 읽으면 되는지라 '천천히 읽지 뭐~' 하지만
그래도 이게 얼마만에 일어난 경쟁(...)인가 하는 생각에
이상스레 가슴이 뭉클..

하지만 그 인간도 얼마 뒤면 딴데로 간다는 생각에
한번 더 가슴이 뭉클..

Comments

지금 와서 말하는데 그 Effective Java는 아무리 생각해도 복사본이야.
어딘가에서 돈이 새고 있어...

그게 ほんもの일리가 없다구! 어따 숨켜써!

M-o-N | 2008-04-10 목요일 오후 10:10

--- attachments ---
zrclip_008p3fb7e291.png

켄트 벡의 구현 패턴 : 읽기 쉬운 코드를 작성하는 77가지 자바 코딩 비법

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-05-04 일요일 오전 12:26 | Books | 원본

현재상태 : WANTED

})

서점에 가서 잠깐 봤는데, 우선 책이 얇다. 그리고 얇은 거에 비해서는 가격은 얇지 않다. (-,-);

다만 고민하면서 읽어 볼만한 내용이 있어서 약간 흥미가 가긴 가는데, 내돈 주고 보기는 사실 살짝 아까운 감이... (^_^);;

그래도 기회가 닿으면 읽어보고 싶은내용.

PS. 번역이 좀 부실하다는 이야기가 서평으로 약간 들려온다.

Comments

요즘 우리 "벡"씨가 같은 뼈로 사골국물을 100번도 더 우려낸다는 소문이...

M-o-N | 2008-05-24 토요일 오전 1:22

--- attachments ---
zrclip_002n3f6a1b3.png

Professional 이란?

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-07-12 토요일 오후 8:9 | 이생각 저생각 | 원본

토요일의 99%는 늦게 일어나는데, 오늘은 아침부터 부산을 떨어서 9시까지 신촌 토즈를 갔다. 왜냐하면 O모 사이트 운영자이신 K모님이 junit 과 TPTP에 대해 유료 세미나를 진행한다고 해서이다. 평소 무료세미나도 잘 안가는데, 내 돈까지 내고 참석했다는건 개인적으로는 대단한 일이다.

그리고 참가비 2만원은 (매우 안타깝게도) 내게 결코 적은 돈은 아니었다. (사고싶던 책 접고 가는 데다가 마늘(garlic2)님께 빌린 돈이기까지 하다.)

토즈는 처음가봤는데, 시설도 좋았고, 환경도 쾌적한 편이었다.

하지만 안타깝게도 정작 '세미나'는 그러하지 못했다.

오전 9시~12시까지 시간은 세시간. 참석자는 10여명 남짓. 좋은 시설 아래에서 길진 않지만 많은 것을 주고 받을 수 있는 조건이었다.

하지만 결국 얻은 것은 무엇인가? 라는 의문만 남았다.

TDD 자료 30분만 읽으면 알 수 있는 테스트케이스 작성(아주아주)기초, 이클립스 단축키 몇 가지, 그리고 30분도 채 안되는 시간동안 본 TPTP, 거기다 TPTP는 본인도 자세히는 모른다고 하시니...

개인적으로 k모 님을 좋아하지만 이건 좀 아니라는 생각이 들었다. 쓴소리가 되겠지만, 애정어린 마음으로 몇가지 이야기를 해 보려고 한다.(이상하게 들리겠지만 난 k모 님이 잘 되기를 바란다. 프리랜서들이 롤 모델로 삼을 수 있는 사람, 영향력을 발휘할 수 있는 star player가 되어 주었으면 하기 때문에 더욱 그러하다. 왜냐하면 나는 결코 그리 되지 못할것이기 때문이다. )

우선 Professional 이란 무엇인가?

professional 이란 말은 흔히 쓰는 말인데, 일반적으로 "a.전문적인, n.분야 전문가" 등의 의미로 알고 있다. 좀 더 정확한 정의를 알기위해 반대말을 한번 보자.

})

내가 영어를 잘해서 한영사전 놔두고 영영사전을 꺼내든게 아니라, 한영사전에는 단순 어휘로만 치환되어 있기에 '의미'를 느끼기 어려워서이다.

첫 줄(1번)을 보자.

아마추어란 명사로, 운동이나, 여흥, 기타 취미활동을 하는 사람이라고 되어있는데 마지막 부분에 중요한 말이 나온다. 그런 활동을 하되, 바로 without being paid for it 인거다. 따라서 반대말인 professional 은 바로 with being paid for it! 인거다.

큰 돈은 아니지만 돈은 받고 강연을 했으니 k모 님은 오늘 전문가(professional)로서 앞에 서신 것이고, 따라서 참여자들에게 그들이 들인 시간에 대한 가치, 혹은 비용 지불의 가치를 제공해 줄 의무가 있다.

하지만 정말 안타깝게도, 돈도 시간도 모두 다 아까웠다. 아침잠 포기하고 간것도 억울하고, 돈 2만원도 억울했다. 그나마 책을 받으신 분은 조금 나으셨을까? (비론 전혀 다른 분야의 책들이긴 하지만.)

내가 이리 쓴소리를 내는 이유는, 반대급부로 '나 잘났소!'하자는게 결코 아니다.

3시간이란 시간은 정말 짧은 시간이기에 강연자가 준비를 많이 하지 않으면 순식간에 끝나는 분량의 시간이다. 따라서 기승전결을 미리 고민하고, 시간 분배를 해서 체계적으로 진행하지 않으면 농담 몇개에 화면 몇개 보다가 끝나는 것도 요원한 일이 아닌 시간인거다.

그럼 오늘 세미나는 어떠했나?

시간 분배계획을 미리 공지 하지 않고, 진행하면서 소요되는 데로 시간을 사용했다.
교재라던가 유인물이라던가, 아니면 그 흔한 ppt 하나 없이 자신의 site에 올린 글들과 웹 검색에서 찾은 페이지로 혼란스럽게 진행하였다.
참석자들의 참여를 끌어내지 못해서, 강의도 아니고, 세미나도 아닌 어중간한 형태가 되버렸다.
결과적으로 들인 노력에 비해 얻은 것이 거의 없다.

왠지 몹쓸사람 만든것 같아 미안한 마음이 더 크지만, 사람은 발전해 나가는 거고, 그러기 위해서는 걸림돌이 있어줘야 하는 거라 믿는다. 등뒤에 묻은 먼지는 등을 때려주는 사람이 없으면 계속 남아 있는 법이니까!

부디 다음에는 좀 더 Professional 한 모습을 보여주시길 기대한다.

Comments

이제야 글을 봤습니다.
쓴소리 달게 받겠습니다. 시간이 좀 지나서 자료를 만들어서 공개하고 있습니다.
http://okjsp.tistory.com/tag/tptp
물론 턱없이 부족한 내용입니다만 앞으로도 계속 추가하도록 하겠습니다.
제 강의의 자유분방함과 체계없음은 앞으로도 계속될 것 같습니다.
솔직한 마음은 제 경험을 나누고 싶어서입니다.
만약 이클립스라는 주제로 강의를 했다고 하면 이미 10여번 강의를 했기 때문에 프로페셔널한 모습을 조금 보여줬을 수 있을 것 같습니다.

사실 허명이 되지 않기 위해서 노력은 합니다만, (국내 자바 사이트 남은 게 없어서 제 사이트에 많이들 오시기 때문에 실력보다 이름이 많이 유명해진 듯 합니다) 강의에 임하는 자세는 아직 많이 부족합니다.

죄송합니다.

kenu | 2008-07-28 월요일 오후 1:2

--- attachments ---
zrclip_001n3635a0d4.png

Eclipse Plugin Project 생성시 Rcp option 의 의미

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-04-24 목요일 오전 1:21 | 이클립스 RCP | 원본

})

Rich Client Application

RCP를 만들려면 org.eclipse.core.runtime.applications 확장을 가져야 한다.

거기다가 만일 Branding 을 원하면 org.eclipse.core.runtime.products 확장이 있어야 한다.

--- attachments ---
042308_1619_1.png

3장 - TDD 좀 더 잘하기

@doortts (doortts) 님이 작성한 이슈입니다.
---

이전: 2장 - JUnit and Hamcrest
다음: 4장 - Mock 을 이용한 TDD

안내: 본문을 읽지 않고 아래의 코멘터리만 읽는 걸 가정해서 작성하진 않았습니다.

3장 본문

03-DoingBetterTDD.pdf

읽기전에

"3.1 테스트 케이스 클래스의 위치" 부분은 Java 기준으로 "#6. 메이븐(Maven) 스타일"만 읽으면 될 것 같습니다.
전반적으로 짧은 챕터입니다. 시간들일 가치도 별로 크지 않으니 휙~ 보세요.

보충 설명

"3.2 테스트 메소드 작성 방식" 은 봐둘만 합니다.
- 특별히 추가 테스트가 필요 없는 기본 동작 테스트시에는 "테스트 대상 메소드와 이름을 1:1로 일치"
- 몇 가지 조건절 테스트가 필요한 경우에는 "테스트 대상 메소드의 이름 뒤에 추가적인 정보를 기재"
- 여러 메소드를 조합해서 테스트가 필요한 business 로직 테스트에는 "테스트 시나리오에 집중" 방식을 씁니다.
- 현재도, 그리고 javascript 기반 개발시에도 BDD(Behavior Driven development) 사용 유무와 별개로 위 세 가지 스타일 중 필요한 방식으로 사용해서 개발하고 있습니다.
접근제한자(private/protected 메소드)의 경우 아무리 public 에서 테스트가 같이 된다고 해도 '역시 테스트 안하고 넘어가긴 찜찜하다' 싶은 사람들은 PowerMock을 사용하더군요.
- 접근제한 메소드의 테스트가 필요한 경우 전 보통 public 만들어서 테스트 하고 끝나면 private 등으로 변경하고, 테스트 케이스는 @ignore 지정하고 끝냅니다.
- 보통 다른거(junit, mockito 등) 쓰다가 private 메소드 테스트 하겠다고 powermock 도입하는 경우가 많은데 그것도 세팅하고 사용법 배우려면 시간대비 효용이 얼마나 큰지는 잘 모르겠다고 생각하거든요.
"3.4 TDD의 한계" 에서는 기술적 관점에서 한계만 다루고 있습니다.
- TDD의 사회적인, 그리고 심리적이며 환경역학적인 한계에 대해서는 뒷 부분에서 따로 다룰 예정입니다.

도전과제

(별다른 기대는 안합니다만) 본인에 만든 테스트 케이스의 이름들이나 스타일을 주변 사람에게 공유하고 어떤지 물어보세요.

4장 예고

오늘은 금요일입니다. 전 벌써 고기를 몇 점 먹었다죠! 다음 업로드는 주말 건너뛰고 월요일에 이어집니다. 그럼 TGIF(Thank God It's Friday) 되세요~

--- attachments ---
03-DoingBetterTDD.pdf
29-20187-20-2037-3.png

Guide to Greener Eclectronics

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-07-01 화요일 오후 9:5 | 이생각 저생각 | 원본

그린피스에서 발표한 레포트에서 발췌. 소니, 역시 일본기업이고 일류기업 답다고나 할까? 삼성은 규모면에서 Sony를 앞질렀을지 모르지만, 글로벌 선두기업으로서 가지는 정신은 아직 다소 부족한듯.

몇가지 특이할만한 점은 Nokia는 5.8로 선두였는데, 몇가지 문제(take-back문제와 recycle practice 부분)로 인해 1점이나 감점되어서 3위가 되었다는 점. 그리고 LG전자(LGE)는 한참 멀었다는 사실, 그리고 닌텐도는 그린피스가 보기에는 거의 악의축(...)기업이라는 거다.

관심있는 사람은 한번 받아 보시던가요.

})

Comments

그리너 에클렉트로닉스- 우헤헤
오우~ developerWorks 여기도 있었다
같이 플젝하는 정지X과장님은 이벤트도 당첨되었더라구! (칙셔-)

M-o-N | 2008-07-01 화요일 오후 10:34

뭣! 정X범 과장이었던거야!!! (우소!!!)

doortts | 2008-07-02 수요일 오전 12:20

이 싸람들이~~!!

X지X 과장 | 2008-09-09 화요일 오후 5:23

--- attachments ---
zrclip_001pc3451e1.png

[번역] Neil Bartlett: What is OSGi for??

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-06-09 월요일 오후 7:45 | 이클립스 RCP | 원본

})

이클립스 OSGi p2가 요즘 욕을 먹다먹다 별 소리를 다 듣고, JAVA.NET의 Editor's Daily Blog로는 OSGi가 대체 뭐냐? 너무 장황하게들 설명하는데 뭔소린지도 모르겠고, 과연 모듈 시스템이 필요한거냐? 라는 질문까지 나와서는 한 무리를 형성하자 Neil Bartlett 이라는 사람이 아래와 같은 글을 올렸다. 뭐, 개인 의견이니까 심각하게 볼 건 없지만, 몇 가지 이야기는 들어볼 만 하다 생각되어서 번역해서 올려본다.

영어가 딸리다 보니, 의역을 넘어 창작(...)의 영역까지 가는것 같지만, 그냥 그런가 보다 하고 읽으시길..

| | Neil Bartlett: What is OSGi for?? | 2008-06-07 | |

java.net 일일 업데이트에서 Chris Adamson은 OSGi의 늘어난 탁월함에 대한 글을 썼다. 그러나 그와 동시에 OSGi를 사용하지는 않고 있다고 시인했는데, 이건 비단 그 만의 경우는 아닌것 같다. OSGi 커뮤니티에 속해 있고, OSGi의 끝내주는 기능들에 대해 설명하는데 열성적인 우리들은, OSGi가 무엇이고 왜 중요한지에 대해 설명하는데는 크게 노력해오지 않았던것 같다.

요약하자면, OSGi는 자바를 위한 모듈시스템이다. 그렇지만 그게 실제로 의미하는 것은 무엇인가?

하나의 배포 유닛으로써 모듈의 주요 기능 중 하나는... 무언가를 (직접) 만들거나 아니면 우리의 어플리케이션의 기능성을 확장하기 위해 내려받아 설치 할 수도 있다는 거다.

자바에서의 표준 배포 유닛은 JAR 파일이다. 우리가 JAR 파일들을 가져다 클래스패스 경로 위에 놓아두면, 경우에 때에 따라, 우리의 프로그램이 동작한다. 왜 단지 어떤 경우에만 인가? 왜냐하면 JAR 파일이란건 모듈이 아니라, 단지 임의의 코드 덩어리이기 때문이다. 또한, 실행시에 JAR 파일을 읽어들일때 그 즉시 (JAR파일이란 건) 존재하지 않게 되버린다. : "클래스경로" 라는 건 단지 긴 클래스들의 목록일 뿐이다. 클래스경로위에 놓은 JAR파일은 그 목록에 기여하지만, 실행할 때에는 JAR 파일들 사이의 경계들이 사라져버린다.

이런게 만들어내는 현상 중 하나는, JAR들이 사용자들로부터 구현패키지들을 숨길 수 있는 길이 없다는 것이다. 그리고 또 다른 한가지 현상으로는, JAR파일들의 클래스들은 클래스경로상에서 최초 사용가능한 위치에서 읽어들여지는데, 그 경로란게 항상 맞는건 아니라는 거다. 예를 들면, JAR 파일 하나가 org.foo.A 와 org.foo.B라는 두개의 클래스를 포함하고 있고, A 는 B에 의존하고 있다고 가정해보자. 우리는 이 두개의 클래스들을 JAR 파일 하나 안에 넣어 놓을 거다. 하지만 A는 같은 JAR 파일안의 B가 필요하다는 걸 강하게 나타낼 방법은 없다. 만일 다른 org.foo.B 를 제공하는 JAR 파일(혹은 동일 Library의 old 버전)이 있고, 그 JAR파일이 클래스경로에서 앞쪽에 위치하는 일이 발생한다면 항상 그 다른 B 클래스를 취한다. (결과적으로) 악질적인 클래스로딩 에러들이 잇따라 일어나게 된다.

진정한 모듈이란 단지 구현코드 만이 아닌 설명이 적힌 메타데이터 - 이를테면 (첫째) 이 모듈의 목적은 무엇이고 제공자가 누구인지 등등. (둘째) 이 모듈의 의존성은 어떻게 되는지, 그리고 (셋째) 이 모듈이 다른 모듈에게 제공하는 건 무엇인지 - 와 함께 구성된다. 또한, 진정한 모듈 시스템에서는, 각각의 모듈에 대해 독립된 네임스페이스를 만들고, 통제되어지고 명확하게 정의된 방식으로만 교차 모듈 로딩을 허용한다.

종속관계로 의미하고자 하는 것은 무엇인가? 쉽게말해서, 프로그램이나 코드 블럭이 동작하게 될 환경에 대한 일련의 가정들인 것이다. 예를들면, 어떤 자바 클래스는 JAVA 5에서 동작하고, 아파치 Log4J 라이브러리에 접근할 거라고 가정할 수 도 있다. 이런 가정들이란 암시적이고, (따라서) 잘못된 환경에서 처음으로 실행하려고 하기 전까지는 그런 가정이 있는지 조차 알 수 없다는 걸 의미한다. 다시말해, Java 1.4 환경에서 실행하려다 어긋나는 광경을 처음 목격하기 전까지, 이 코드는 Java5 에서 실행된다고 가정되어 있다는 사실을 (역어셈블링을 제외 하고는) 알 수가 없다는 거다. 마찬가지로 Log4J가 클래스경로에 없는 상태에서 처음 실행되어서 NoClassDefFoundError 를 보기전까지는 Log4J를 호출한다는 사실을 알 수가 없다.

그래서 우리는 어떤 클래스가 특정환경에서 동작할지 어떨지를 실행해 보기 전까지는 제대로 알 수가 없다. 그리고는 심지어 문제점들을 즉각 발견 못할 수 도 있다. 왜냐하면 특정 실행경로가 뒤따르지 않으면 문제가 발생하지 않기때문이다.

반대로, OSGi는 명시적이고 선언적인 의존정보를 우리에게 제공한다. JAR의 MANIFEST.MF 에 헤더를 추가함으로써, JAR 파일이 동작하게 될 환경이 어떻게 되는지 정확하게 명세화 할 수 있다.
Import-Package: org.apache.log4j Bundle-RequiredExecutionEnvironment: J2SE-1.5

우리는 검증할 책임이 있고 독립된 모듈로 (해당부분을) 읽어들이는 프레임웍(=OSGi 구현체,equinox등)을 가지고 있다. 만일 우리가 Java 1.4에서 이 JAR 파일을 설치한다면, (클래스파일들로)"해체"되지 않을 것이고, 왜 그런지 확실한 메시지를 얻게 될것이다. 만일 Log4J 모듈이 아직 설치되지 않은 어플리케이션에 이 JAR 파일을 설치한다면, 다시 한번, 빠진것이 무엇인지 설명해주는 명시적인 에러 메시지를 보게 될 것이다. 이런 제약조건들때문에, 만일 적절하게 조립된 번들이 분해된다면, 결코 ClassNotFoundException 나 NoClassDefFoundError 가 발생하지 않으리란 걸 확신할 수 있다. (뭐, Class.forName() 등을 사용해서 동적으로 클래스를 읽어들이는 코드나 비슷한 경우에서의 이슈꺼리가 여전히 있긴 하지만, 그럴때는 또 거기에 따른 다른 처리방법이 있는거고... 대부분은 그렇다는 거다)

더욱이, 우리는 이런 모든 종속성을 실제로 배포하거나 어플리케이션이 동작하기 한참 전에 정적(방식)으로 검사할 수 있다. 모든 종속성 정보는 눈에 보이는, 선언적인 형태로, MANIFEST.MF 안에 바로 들어 있다. 이건 어플리케이션의 동작이 누락된 JAR 파일때문에 실패하지 않게 도와주는 완벽한 툴이다. 또한 서드파티 모듈을 가져와서 우리 어플리케이션에서 동작할지 어떨지, 그리고 만일 동작하지 않는다면 동작하기 해서 다른 어떤 모듈이 필요한지 즉각 확인할 수 있다

이건 단지 겉을 긁어대는 수준이지만, 적어도 Chris의 "왜 모듈 시스템을 필요로 하고 원하는가?"라는 질문에 답이 되길 바란다. 쉽게말해, 모듈 시스템이 없으면, 자바 어플리케이션들의 제작과 배포는 너무많은 오류를 손쉽게 일으킬 수 있다. 자바 프로그러머들은 10년 넘게 "JAR 지옥" 과 "클래스경로 지옥", 그리고 숨겨진 의존성들의 고통을 반복해왔다. (결국)우리는 그것에 익숙해져서 그 고통을 더 이상 의식적으로 자각하지 못한다. 그러나 그 고통이 사라진다면 (제길) 당신은 잘 알게 될거다!

덧붙여 말하면, 위 모든 것들은 모듈 시스템을 사용하는것에 대한 논증이지, 반드시 OSGi를 사용하라는것은 아니다. 예를들면 NetBeans 플랫폼과 Glassfish V1,V2에 들어있는 HK2(=V3에서는 4년전쯤에 OSGi로 대부분 교체되었다), 그리고 (만들어진 적이 있는지는 알수 없는)JSR 277, 예전 Eclipse 모듈 시스템(=4년쯤 전에 OSGi로 교체되었다)과 같은 다른 모듈 시스템들도 주변에 널려 있다. 만일 당신이 어떤 정치가들에게 당신의 투표권을 사용하기에 알맞은지 어떤지를 묻는다면, 그들 하나같이 그렇다고 할거고, 왜 그들의 정당에 투표해야만 하는지 설명할 것이다. (=즉 어떤 주장을 하는 사람들에게 그들의 주장이 옳은거냐고 묻는다면, 누구나 다 그렇다고 말 할 것이고 그 이유에 대해서도 설명하려 들 것이라는 이야기) 난 자바에 있어서 사용가능한 어떤 다른 모듈시스템보다 왜 OSGi를 사용해야만 하는지, 그 이유에 대한 설명은 다른 사람들(혹은 나중 글을 통해 스스로)에게 남겨둘까 한다.

--- 이하 원문 --

| Neil Bartlett: What is OSGi for?? | 2008-06-07 |
|

2008-06-07 00:02 작성

In his daily update at java.net, Chris Adamson writes about the increasing prominence of OSGi. But also admits that he just doesn't "get" OSGi, and it seems he's not the only one. Perhaps we in the OSGi community, in our enthusiasm for explaining the cooler features of OSGi, have not done a great job of explaining what OSGi is and why it matters.

In a nutshell, OSGi is a module system for Java, but what does that really mean?

One of the main functions of a module is as a unit of deployment… something that we can either build or download and install to extend the functionality of our application.

The standard unit of deployment in Java is the JAR file. We take these JAR files and put them on our classpath and, some of the time, our application runs. Why only some of the time? Because a JAR file is not a module, it is merely an arbitrary chunk of code. Also, when we load a JAR file at runtime it immediately disappears: the "classpath" is merely a long list of classes. JARs that we place on the classpath contribute to that list, but at runtime the boundaries between the JARs dissolve.

One symptom of this is that JARs have no way to hide implementation packages from users. Another is that classes are loaded from the first possible location in the classpath, which is not always correct. For example, suppose a JAR file contains two classes, org.foo.A and org.foo.B, and A depends on B. We ship these two classes together in a JAR, but there is no way for A to insist that it gets the B from the same JAR. If another JAR happens to provide org.foo.B (e.g. an older version of the same library) and that other JAR is listed earlier on the classpath, then we will always get that other B. Evil classloading errors ensue.

A real module consists not just of implementation code, but also metadata that describes: (a) What this module is for and who provides it etc (b) What dependencies it has, and (c) What it provides to other modules. Also in a real module system, we create an isolated namespace for each module, and only allow cross-module loading to occur in a controlled and well-defined way.

What do we mean by a dependency? Simply, it is a set of assumptions made by a program or block of code about the environment in which it will run. For example, a Java class may assume that it is running on Java 5 and that it has access to the Apache Log4J library. These assumptions are implicit, meaning we don't know they exist until the first time we try to run the code in an environment where they are false. In other words, we don't know (except by disassembling) that the code assumes it is running on Java 5 until we first try running it on Java 1.4 and watch it crash. Likewise we don't know that it makes calls to Log4J, until the first time we run it without Log4J on the classpath and see a NoClassDefFoundError.

Therefore we have no real idea whether a class will work in a particular environment except by trying it out. Even then we may not immediately discover problems, because they don't occur until a particular execution path is followed.

By contrast, OSGi makes us provide explicit, declarative dependency information. By adding headers to the JAR's MANIFEST.MF, we can specify exactly what environments that JAR will run in:Import-Package: org.apache.log4j Bundle-RequiredExecutionEnvironment: J2SE-1.5

We then have a framework that is responsible for validating and loading this as an isolated module. If we install this JAR on Java 1.4, it will not "resolve", and we will get a clear message telling us why not. If we install this JAR in an application that does not have a Log4J module already installed, then again we will get an explicit error message explaining what is missing. Because of these constraints, we can be confident that if a properly constructed bundle resolves, it can never throw a ClassNotFoundException or a NoClassDefFoundError (well, almost… there is still the issue of code that does dynamic class loading using Class.forName() or similar… there are different mechanism to handle this).

Even better, we can do all of this dependency checking statically, long before actually deploying or running an application. All of the dependency information is visible, in declarative form, right in the MANIFEST.MF. This is perfect for tools, whicht can help us to construct applications that never fail due to a missing JAR. We can also take a third-party module and immediately identify whether it will work in our application, and if not what other module we need to obtain in order to make it work.

This just scratches the surface, but I hope it at least answers Chris' question "Why would you want or need a module system?". Simply, without a module system, the construction and deployment of Java applications is just too error-prone. Java programmers have been coping with pain - with "JAR hell" and "classpath hell" and hidden dependencies - for more than ten years. We've got so used to it that we don't consciously notice the pain any more. But you damn well notice when the pain goes away!

Incidentally, all of the above is an argument for using a module system, not necessarily for using OSGi. There are other module systems around - such as the one in NetBeans platform, and HK2 in Glassfish V1 and V2 (which is largely replaced by OSGi in V3), and JSR 277 (if it is ever built), and the old Eclipse module system (which was replaced with OSGi around four years ago). If you ask any politician whether it's good to use your vote, they will unanimously agree that it is, and then they explain why you should use it to vote for their party. I will leave it for others (or myself in a later post) to explain why you should use OSGi rather than any of the other module systems available for Java.

--- attachments ---
zrclip_001p1e4f0077.png

우리나라 대부분의 SI 프로젝트는 실패해야 한다.

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-09-06 토요일 오전 1:37 | 이생각 저생각 | 원본

우리나라 대부분의 SI 프로젝트는 실패해야 한다고 생각한다.

다소 과격하게 들리고 공격적으로 느낄수도 있겠지만 내 생각은 그러하다.

(skip)

오늘 회사 후배가 찾아왔다.
내가 봤을때 정말 맡은 일 열심히 하는 후배다.
오늘 퇴근 시간즈음에 나를 부른건, 퇴직인사를 하기 위해서다.

가슴이 착찹하다.

(또 skip)

우리나라의 SI 프로젝트는 너무 성공한다.

말도 안될만큼 성실하게 일하는 사람들이 있기 때문에,
집버리고 여자친구 남자친구, 아내 남편 버리고,
프로젝트가 의례 그렇다는 듯이 막판이 다가오면 다가올 수록, 마치 자신의 잠재능력의 끝을 보여주고 싶기라도 한것마냥
가속화된 형태로 자신들의 삶을 쏟아붓는 사람들이 있기에,

어떻게든 성공시켜 버린다.

(그리고 일련의 사람들은 그렇게 하기 위해 곧잘 책임감이라고 하는 덕목을 비겁하게 이용하곤 한다.)

제때 즈음에 오픈하고, 큰 사고(= 사람 쓰러지는 건 사고로 치지 않는다. 핵심은 돈이다)없이 얼마간 지속되면 프로젝트 성공했다고 한다. (그리고 심할 경우 성공사례 발표 같은 짓까지도 서슴없이 일삼는다.)

아마 모르긴 몰라도 전세계 SW 프로젝트의 평균 성공률이 30%정도 쯤이라면,
우리나라는 (announced percentage로) 80%쯤 되는게 아닐까 싶을 정도다.

다시 한번 말하지만,

현재 우리나라 대부분의 SI 프로젝트는 실패해야 한다.

어쩌면 나보고 '아이고 맙소사! 이거 Stone child 아냐?' 할지도 모르겠지만,
프로젝트가 끝나고 참여자들에게 설문을 받아서,

이번 프로젝트와 같은 프로젝트에 다시 참여하고 싶습니까?

혹은

프로젝트를 진행하는 동안 본인과 본인의 삶이 존중받았다고 생각합니까?

라는 질문에 대한 응답을 프로젝트 성공 여부에 포함시켜야 한다고 생각한다.

고객과의 계약, 그리고 이 설문, 둘 중 하나라도 만족 못시켰으면,

프로젝트 실패건으로 카운트하고 다들 한 방에 모여앉아 반성 또 반성해야 한다.

시스템은 살고 사람은 죽어나는게 무슨 성공적인 SI인가? 시스템이란게 대체 누구를 위한 것인가? 주객이 전도된 현상이라고는 생각되지 않는가?

몸도 마음도 피폐해져서는 떠나는 사람이 속출해도,
납기에 맞춰 물건을 넘겼으니 프로젝트가 성공이라고 믿는 사람들이 있기때문에,

안타까운 사연들이 넘쳐나는 업계가 되는거다.

제발 실패하자.

그래서 반성에 반성을 하게 하고,

사람을 기계나사, 컨베이어 벨트 라인처럼 최대한 가동시켜 생산성을 극대화시키겠다는 (혹은 그럴수 밖에 없다는) 어리석은 생각을 되돌리고,

일정과 사람과 환경에 대한 잘못된 가정과 운용이 무엇인지 찾아내서

개선시킬 수 있도록, 기회를 주자.

제발 그렇게 좀 하자.

Comments

나 또한, 그렇게 되기 위한 많은 시나리오를 상상해봤는데...
정리 결과 문제 제기가 어찌 되느냐에 따라 방법이 많이 나뉘더군.
(근거를 좀 대면서 쓰려다가, 벙찐 설명했다가 당했던 아픈 기억이 있어서 걍 쉽게 썼어..--;)

시간이 흘러가면서, 많은 문제가 야기되고
다수 개발자들의 이민, 이직 등의 직업 기피로 인해 결국은 개발자의 삶의 질을 고려.
사회적 이슈 제기. 헌법 소원 혹은 노동 쟁의를 통한 사회적 반향을 불러 일으킴
경제적 이슈 제기. 개발자들을 잘 대우하고, 또 개발자들이 선호하는 회사가 큰 성공을 불러일으킴
상대업체는 경쟁을 위해 개발자들의 삶을 보장하게 됨

근데 중요한 것은 1,2,3 번이 모두 너무 씁쓸하다. 다른 방안은 없어?

M-o-N | 2008-09-06 토요일 오후 11:57

음.. 글쎄.. 현대차 노조 영입? ㅎㅎㅎ

doortts | 2008-09-07 일요일 오전 2:23

근데 시스템이라도 살믄 참 다행이군요..
제가 경험해본 SI는 대부분 (저만의 판단으론)시스템도 실패한 경우인데...

vizitors | 2008-09-30 화요일 오후 3:59

본문에 연장해서...

얼마전, TMIN(?) Room Door(?) 만들어 내기 위하여,
몇 명의 직원이 이혼을 하기도 했다고 자랑스럽게 말씀하시던 그 분의 모습에서
60-70년대, 허리띠 졸라매고 우리도 한 번 잘살아 보세를 외쳤던 모습이 떠오르네요.

우린 아직도 그 시절 그 마인드에 머물러 있는게 아닐까 싶네요.

PS: 여의도 in 애자일은 연재가 완료 된건가요?
뭔가 제대로 흘러가는 프로젝트를 보는 것 같아,
대리만족을 느꼈었는데 더 이상 글이 없네요. :(

proxies | 2009-07-19 일요일 오후 5:40

곰플레이어(Gom player)개발자들의 마인드 중 배울점

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-09-10 수요일 오후 1:34 | 이생각 저생각 | 원본

곰 플레이어 업데이트 알림이 떳다.

})

언제 부턴가 이런식으로 업데이트 알림이 뜬다.

별것 아닐수도 있지만, '업데이트가 있습니다 하실래요?' 식의 메시지 보다 얼마나 더 고객 친화적인가?
(보통은 업데이트가 끝나고 나서야 뭐뭐가 업데이트 되었음. 이런식으로 나오는데 말이다)

업계에서 기술은 쉽게 모방해도 이런 마인드는 쉽게 배우기 어려운 법이다.

--- attachments ---
zrclip_001p3692ca0d.png

"TDD 실천법과 도구" 책 전체를 PDF 공개합니다.

@doortts (doortts) 님이 작성한 이슈입니다.
---

2010년 6월에 출간되었던 "TDD 실천법과 도구" 책 전체를 PDF로 공개합니다.

책소개: http://naver.me/GaYZCDjD

Updated

1장 - 테스트주도개발 Test Driven Development - 18.07.18
2장 - JUnit and Hamcrest - 18.07.19
3장 - TDD 좀 더 잘하기 - 18.07.20
4장 - Mock 을 이용한 TDD - 18.07.23
5장 - DbUnit - 18.07.23
6장 - Unitils 단위 테스트 지원 라이브러리 - 18.07.24
7장 - 개발 영역에 따른 TDD 작성 패턴 - 18.07.26
8장 - TDD에 대한 다양한 시각 - 18.07.31
9장 - 자주 접하게 되는 질문들, FAQ - 18.08.02
10장 - 실습 예제 - 18.08.15 🇰🇷
11장 - 테스트 자동화와 커버리지 - 18.08.15 🇰🇷

5년 계약기간이 끝났을때 갱신을 하지 않았고 출판사에 절판을 요청했습니다. 그러자 조금씩 팔리는데 왜 절판하냐, 차라리 2판을 내면 어떻겠느냐라는 제안이 있었지만 그냥 절판을 원하다고 했습니다.

2년전인 2016년 이맘때쯤 절판요청이후 1년이 지나서야 최종 절판이 되었다고 출판사로부터 연락을 받았었죠.

절판 요청 이유는 이랬습니다.

그로부터 다시 2년이 지났습니다.

간간히 관련해서 메일을 받았고 절판후에는 책을 구할 수 있냐는 문의를 드물게 받곤 했었습니다.
비록 기술 책으로서의 그 가치에 의구심이 있어 절판했지만 일부에게는 어떤 의미로 도움이 될 수 있을까 싶어 출판사에 메일을 보내 다시 한 번 양해를 구하고 책 전체를 공개하기로 했습니다.

여유가 된다면 각 장 별로 바뀐 생각이나 추가 코멘트를 조금씩 붙여서 올려볼까 합니다.

아래는 표지와 목차 추천사 베타테스터들의 목록입니다.

00-표지-목차-추천사-베타테스터.pdf

두 줄의 저자 서문에는 제 마음이 담겨 있었습니다.

그래서 길게 쓰지 않고 그저 한 자라도 더 읽어주었으면 했습니다.

그리고 무려 25분의 베타 리더가 참여해 주셨습니다.

네 그렇습니다. 이 책은 제 책이라고 할 수 없는 책입니다. 주변의 동료와 책안의 스승과 리더로 참여해 주신분들이 썼고 저는 보고 느낀걸 타이핑을 했다고 보는 편이 더 맞는 책입니다.

그럼 이제 내일부터 한 챕터씩 천천히 시작해 보겠습니다.

1장 예고)

깨알

이 책의 편집은 무려..

깨알2

조연희 편집자님은 어렸지만 최고였죠.

깨알3

사실 처음엔 농담을 정말 많이 넣었는데 거의 다 잘렸습니다. 개인적으로는 아쉽습니다만 생각해보면 보통 제가 농담을 하면 대개 저만 좋아했고 전체적으로 설문이나 평가가 안좋았었기 때문에 (...) 조연희 편집자님이 요령있게 잘 잘랐다고 생각은 하고 있습니다.

--- attachments ---
209-20187-17-2231-21.png
931-20187-17-2233-6.png
00-표지-목차-추천사-베타테스터.pdf
269-20187-17-2240-5.png
458-20187-17-2250-36.png
494-20187-17-2250-39.png
179-20187-17-2255-55.png

Zoundry Raven = Blog Writer

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-04-24 목요일 오후 3:37 | 이생각 저생각 | 원본

블로그에 글을 쓰는데, 사실 온라인 상에서 써도 별로 불편한 건 없다.

왜냐하면 이미 computer = network 라는 공식이 성립되어 있기 때문에,
어디를 가든 온라인 어플리케이션(blog)를 편하게 쓸 수 있다.

하지만 한가지 불편한게 있는데, 바로 그림을 올려야 할 경우이다. (특히 캡쳐해서 그걸 올릴려고 할때는 캡쳐 -> 그림판 -> 저장 후 updload -> 이미지 지정 등등등)

이럴때 전용 wirter 를 쓰면 상당히 편해진다. 현재 내가 아는 수준에서 alt - print screen 으로 캡쳐 -> 붙여넣기 후 자연스럽게 이어서 글쓰기가 가능한 툴은

MS OFFICE 2007
MS Live Writer
그리고 오늘 알게 된 Zoundry Raven

이다.

안타깝게도 Open office 계열에서는 지원해 주지 않는다. (심지어 개발자 버전의 open office 3.x 대에서도 마찬가지로)

MS OFFICE 는 무겁기도 하거니와 현재 업무상 쓰는 office 2003을 바꿀수 없어서 PASS

MS LIVE Writer 는 써보니까 괜찮긴 하던데(msn 계정과 연동가능!!) 디자인과 편의가 개인적인 욕심수준(?)에 미달,

지금 쓰고 있는 Zoundry Raven 이 당첨! 되겠다.

http://www.zoundryraven.com/

})

원하는 기능은 다 되고, 느리지도 않고 편하고 좋다.

이미 올린 글들까지 볼 수 있고 수정도 가능하니 더더욱 좋지 아니한가?

개인적으로 강추 한방 날린다.

})

Comments

오오 내가 원하던 그런거야! thx~

M-o-N | 2008-04-25 금요일 오전 12:16

--- attachments ---
zrclip_004p5e20ea83.png
zrclip_003p74d02e8e.png
zrclip_002p2e8b7bff.png

Mock Object를 사용하여 쉽게 테스트하기 part 1

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-08-31 일요일 오후 11:53 | Better SW Development | 원본

테스트 작성이 쉽지 않은 경우,

그 중에서도 DB가 필요하다면서 테스트를 꺼리게 될 경우,

Mock Object 를 사용해서 어떻게 테스트가 가능한지 살펴 보고자 한다.

전체 2부로

1부 : Plain mock object 을 이용해서
2부 : Mock Object Framework 을 이용해서

계획되었으나 이러저런 이유로 현재 1부 먼저 공개하게 되었다.

Mock Object 를 이용한 테스트(클릭)

"테스트 케이스 작성 어렵다 말고, 방법을 생각해 보자"

라고 말하고 싶다. (^_^);

- 추가 부연 설명 -

Mock Object 라는건 무엇일까요?

예전에 자동차 만드는 CF에서 자동차 모양을 나무로 깍아서 디자인 원형을 만드는 것을 보신 분도 계실것니다.

말하자면 디자인으로 제품원형을 만들때 모양을 조각하기 쉬운 나무를 이용하는 것을 생각하시면 되겠습니다.

그래서 겉 모양만 실제와 비슷하게 보이는 가상 객체를 만드는 것을 Mock Object 라고 보시면 되겠습니다.

본 예제에서는 JDBC 중 흔히 사용되는 세가지 인터페이스 Connection, Statement, ResultSet 을 구현(implements)하는 Mock Object 를 만듦으로써 DB 없이 어떻게 테스트 가능한 클래스를 도출해 낼 것인가에 대해서 살펴보고 있습니다.

- 나중에 추가 --

제가 작업한 내용을 다시 보니 말도 어색하고,

무엇보다 긴장한 나머지 틀린 단어에, 딴소리(...)까지

전혀 서슴없더군요. -_-;;

혹 들으신다면, 부디 적당히 걸러서 들으세요. (죄송)

Comments

혹시 강사 경력이 있으신가요? 동영상에 맞춰 설명을 잘 하시네요. :)

이국진 | 2008-09-03 수요일 오전 12:7

안녕하세요? 어떻게 알고 들르셨는지요? 블로그 주소라도 남겨 주셨으면 인사드리러 갔을텐데 아쉽습니다.
부끄럽습니다만, 남겨주신 코멘트는 칭찬이라 생각하겠습니다.
감사합니다.(^_^);

doortts | 2008-09-06 토요일 오전 12:36

Mock 사용이 익숙치 않았는데 좋은 자료 만들어 주셔서 감사합니다.

CoolGuy | 2009-01-23 금요일 오전 8:52

그리 말씀해 주시니, 저도 감사합니다. 평안한 설 연휴 되세요. :)

doortts | 2009-01-23 금요일 오후 2:44

이클립스 기동시에 발동되는 View 목록과 특정 View 감추기

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-08-03 일요일 오후 4:25 | 이클립스 RCP | 원본

이클립스 기동시에 발동되는 View 목록 (part의 id 와 name) 을 살펴봤다.

IWorkbenchPage page = PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage();
IViewReference [] view = page.getViewReferences();
for (IViewReference viewReference : view) {
System.out.println( viewReference.getId() + " : " + viewReference.getPartName() );
}

결과 -

org.eclipse.jdt.ui.PackageExplorer : Package Explorer
org.eclipse.jdt.ui.TypeHierarchy : Hierarchy
org.eclipse.ui.views.ProblemView : Problems
org.eclipse.jdt.ui.JavadocView : Javadoc
org.eclipse.jdt.ui.SourceView : Declaration
org.eclipse.ui.views.ContentOutline : Outline
org.eclipse.mylyn.tasks.ui.views.tasks : Task List
org.eclipse.ui.internal.introview : Welcome

즉, 특정 VIEW 를 찾아서 접거나 열고 싶으면 (이를테면 welcome 같은)

IViewPart view = page.findView("org.eclipse.ui.internal.introview");
if (view != null)
page.hideView(view);

형태로 작성하면 된다.

이클립스 Version Numbering 체계

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-07-04 금요일 오전 11:41 | 이클립스 RCP | 원본

기존에 사용되던 Version Numbering을 3.2부터 정제된 형태로 사용되고 있다.

다른데에 적용해도 괜찮을 만큼 꽤 체계적이라고 생각된다.

http://wiki.eclipse.org/index.php/Version_Numbering

})

| First development stream

1.0.0

Second development stream

1.0.100 (indicates a bug fix)
1.1.0 (a new API has been introduced)
The plug-in ships as 1.1.0

Third development stream

1.1.100 (indicates a bug fix)
2.0.0 (indicates a breaking change)
The plug-in ships as 2.0.0

Maintenance stream after 1.1.0

1.1.1
The plug-in ships as 1.1.1
|

Comments

음, 너무 복잡해서 잘 이해가 안되네.

산사랑 | 2008-08-08 금요일 오후 5:37

--- attachments ---
zrclip_002p593788e1.png

8장 - TDD에 대한 다양한 시각

@doortts (doortts) 님이 작성한 이슈입니다.
---

이전: 7장 - 개발 영역에 따른 TDD 작성 패턴
다음: 9장 - 자주 접하게 되는 질문들, FAQ

8장 본문

08-various-views-of-TDD.pdf

읽기전에

문장이 다소 만연체라 속도감이 떨어지고 밀도가 조금 낮기는 한데 전반적으로 한 번은 읽어볼만 합니다.

보충 설명

글쎄요. 특별히 따로 할만한 보충 설명은 별로 없네요. 다음장 FAQ 에서 좀 더 다뤄볼게요.
TDD 가 마법도 아니고 개발자의 레벨을 구분짓는 잣대도 아니라는 걸 한 번 더 말하고 싶네요
물론 그 반대로 TDD 없이도 잘 살아왔어! TDD 따위 흥~ 쓸데없어~ 망해라! 할 필요도 없습니다.

생각이 바뀐 부분

일부 문장의 어조가 상당히 강하고 단정적이라 지금보니 거부감이 조금 든다

좀 더 강조했어야 하는 부분

TDD의 리듬을 이렇게 유지하는걸 추천한다.
1. 시간을 들여서라도 테스트 코드를 문맥에 맞게 잘 짠다.
2. 코드가 더럽더라도 최대한 빠르게 테스트 코드를 통과하는 비즈니스/로직 코드를 작성한다. (매우 중요!!)
3. 리팩터링을 한다.(2번 만큼이나 역시 매우 중요!!!)
- 아주 강력하다! 학습효과도 매우 우수!! 하지만 히키코모리 같은 우리내가 넘기엔 마찬가지로 큰 산.

깨알

못 짠 코드를 표현하고 싶었댔더라도 이건 너무 지나치게, 심하게, 못 짠 코드인거다

깨알2

젠장 2018년의 지금, 핸드폰 노키아는 망했다구!!

깨알3

지금 치킨 먹으면서 올리고 있어요. 밤 11시 40분이네!!!!

9장 예고

--- attachments ---
08-various-views-of-TDD.pdf
993-20187-31-2324-18.png
454-20187-31-2325-11.png
635-20187-31-2326-49.png
947-20187-31-2329-59.png
679-20187-31-2335-12.png
710-20187-31-2337-58.png
314-20187-31-2339-14.png

Where will life take you

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-03-29 토요일 오후 4:42 | 이생각 저생각 | 원본

재능과 안목에 무릎꿇고 앉아서 좌절할만한 루이비통의 광고 영상

Louis Vuitton's Where will life take you? (Directed : Bruno Aveillan)

Comments

ㅇㅇ.. 가격과 마케팅에 무릎 꿓고 앉기도 한다우. OTL

M-o-N | 2008-03-31 월요일 오전 1:30

9장 - 자주 접하게 되는 질문들, FAQ

@doortts (doortts) 님이 작성한 이슈입니다.
---

이전: 8장 - TDD에 대한 다양한 시각
다음: 10장 - 실습 예제

9장 본문

09-TDD-related-FAQ.pdf

안내: 본문을 읽지 않고 아래의 코멘터리만 읽는 걸 가정해서 작성하진 않았습니다.

Answers, Side B.

다음 내용들은 기존 책에 적힌 내용이 틀려서가 아니라 다른 시각의 의견이라고 생각하고 읽어주세요. 일부는 농담입니다.

저희는 이미 충분히 많은 기능 테스트를 하고 있습니다. 그런데도 따로 단위 테스트 케이스 를 만들 필요가 있을까요?

이미 훌륭합니다. 뭘 더 바래요?

개발 시에 결과값을 미리 예상할 수 없는 경우에는 그럼 어떻게 TDD를 진행하나요?

결과값을 미리 알 수 없는 경우는 어떤 대상에 대해 학습중이거나 외부 API를 호출하는 경우가 많은데, expected 값을 아무값이나 넣어 놓고 나중에 결과가 나왔을때 실패하는 actual 값을 복사해서 그 시점에 expected 로 맞춰서 테스트를 성공시키시는 것도 방법입니다. 전 이 방법을 종종 씁니다.

저희는 특정 객체 생성 시 사용되는 값이 랜덤 값입니다. 이런 랜덤 값에 대한 테스트는 어 떻게 만드나요?

산술적 랜덤일 경우는 책에 나온대로 하시고, 논리적 불규칙성일 경우에는 contains one of them ? 으로 체크하거나 삼각 측량식으로 다른 논리값으로 비교를 하세요.

만일 팀 내에 TDD를 통한 단위 테스트 케이스를 작성하지 않고도 이미 높은 수준의 코드를 작성하고 있다면 어떻게 해야 할까요?

축하드립니다. 팀 정신을 살려 계속 정진하시면 됩니다.

단위 테스트 케이스 코드를 작성하기가 여전히 어렵습니다. 옆 동료를 보니까, 전 잘 이해 할 수 없는 코드를 이용해 어떻게든 테스트 코드를 만들면서 진행하고 있던데, 저는 어떻게 해야 할까요?

옆 동료를 멀리하세요. 그리고 해당 코드를 넘겨 받지 않도록 최선을 다하시길 기원합니다.

저희는 대부분의 코드를 TDD 방식으로 개발했습니다. 그리고 커버리지 100%의 자동화된 테스트도 갖고 있답니다. 자, 이젠 QA팀을 해체해도 되겠죠?

어디서 지금 약을 파시는거죠? 대체 QA팀의 누가 싫은거죠?

왜 이클립스의 각종 기능과 단축키 등을 사용해야, 혹은 배워야 하나요? 전 울트라 에디터 (UltraEditor)나 심지어 때로는 메모장(notepad)으로도 충분히 잘할 수 있다구요! (게다가 TDD 랑 무슨 상관?)

방문을 환영합니다! 참! 과거 몇 년도에서 오신거죠?

저희는 화면 UI가 매우 중요합니다. 그중에서 이미지 관련한 부분이 특히 중요합니다. 고정 이미지도 있고, 어도비 플래시를 이용한 움직이는 이미지도 있습니다. 이럴 경우에는 어떻게 TDD를 진행할 수 있나요?

반갑습니다! 조금전에 친구분이 먼저 오신것 같던데.
이미지 라이브러리나 알고리듬 개발이 아니라면 굳이 이런 UI TDD는 하지마세요.

private 메소드도 테스트 케이스를 만들어야 하나요?

만들면 좋구 안만들어도 뭐라고는 안할게요.

사용자가 직접 수행하는 수동 테스트와 자동화된 테스트, 굳이 TDD에 한정하지 않고 봤을 때, 어느 것이 더 중요한가요?

어느게 더 중요하다기 보다는 가각 비용을 따져보시고 결정하면 되겠습니다.

TDD를 적용하기 어려운 대표적인 이유는 무엇입니까?

설계 지식과 경험이 먼저 어느정도 갖추어져야 좀 더 잘 할 수 있는데 그렇지 못하기 때문에 제일 큰 원인이라고 생각합니다.

이러저러한 노력에도 불구하고 TDD가 잘 안 되고 서툽니다. 어떻게 해야 하나요?

하지마세요. 안잡아갑니다. 코드를 작성하고 나서 테스트를 작성해도 충분합니다.
아.그럼 테스트 코드를 안만들어도 된다는 의미신거죠?
- 아니요. 레거시프로젝트가 아니라 새로 시작하는 프로젝트라면 테스트 코드는 꼭 만드세요.

저는 SI 프로젝트 위주로 일하고 있습니다. SI에서 TDD를 적용하는 것이 바람직할까요?

바람직하다라... 흠. 어렵네요. 모르겠어요.

TDD는 개발 기법으로 봐야 하나요? 아니면, 테스팅 기법으로 봐야 할까요?

TDD는 개발 (실력 자랑) 기법으로 보시면 됩니다. (농담~ 농담~)

TDD를 하면 TDD를 하지 않은 경우에 비해 확실히 품질도 좋아지고, 개발도 빨라지는 거, 맞죠?

통계적으로는 그렇긴 한데, 왜인지 저에게는 통계분포 그래프상 다수 그룹 밖에 위치하는 일들이 곧잘 일어나더라구요.

테스트 케이스를 최대한 정교하게 작성하려고 노력하고 있습니다. 그런데, 그러다 보니 테 스트 대상 객체나 코드가 조금만 변경이 일어나도 테스트가 와장창 깨져서 유지보수하는 데 비용이 많이 듭니다. 이젠 솔직히 TDD에 대한 회의가 들 정도에요. 뭐가 잘못된 걸까요?

"제가 짠 코드는 요구사항 하나만 바뀌어도 고쳐야 하는 모듈이 여러개에요~"와 유사한 상황이라고 생각하시면 됩니다.
테스트 코드도 유지보수해야 하는 개발 코드의 일부로 간주해서 지속적으로 개선해야 합니다.

면접 시에 TDD에 대해 물어보는 건 어떻게 생각하시나요?

물어본 사람은 진지하게 해본적이 없거나 자랑하고 싶어서 빨리 다시 내가 말할 차례가 되었으면 좋겠다고 생각하는 상황, 둘 중 하나라고 생각합니다.

팀에 TDD를 도입하고자 할 때 초반에 TDD 외에 다른 어떤 활동을 같이 하면 좋을까요?

Pair Programming과 Code Review

팀에서 여전히 JDK 1.4 버전을 쓰고 있어서 짜증이 나요. JUnit 4는 저 하늘 멀리 있고요, 스프링의 최신 버전 기능도 못 쓰고, Google Guice8도 못 쓰고, 심지어 FindBugs 최신 버전 도 전혀 쓸 수가 없어요. 그런데도 이 인간들은 “꼭 Java 5를 써야 해?”라든가, “기존 시스템 이 JDK 1.4를 쓰는데 같이 쓸려면 어쩔 수 없어. 1.4 쓰자!”라고 말합니다. 제가 보기엔 다 핑 계이고요, Java 5의 신기능(맙소사! 이미 썬에서는 Java 5의 서비스 지원종료 전환기간에 돌 입했다구요!)을 공부하기 귀찮아서인 게 뻔하다구요. 정말이지 개발할 의욕이 안 난다니깐요 (JUnit 4 쓰고 싶단 말이에요). 여기까지는 넋두리고요, 이제 진짜 질문입니다. 팀에서 별로 달 가워하지 않는데도 굳이 TDD를 쓰자고 계속 주장해야 할까요?

아! 친구분들 아까부터 먼저 와 계세요.

보통 이야기할 때 TDD와 단위 테스트를 혼용해서 쓰는데, 둘이 같은 거 맞죠?

음. 우선 노트나 메모장을 준비하세요. 그 다음, 방금 그 말을 한 사람 이름을 잘 적어두시고 좀 더 시간을 두고 관심있게 그 분을 지켜 보시는게 좋겠습니다.

저희는 옆 팀처럼 바보같이 테스트 커버리지 100%에 도전하고 있지 않습니다. 저희 팀은 큰 부담 없이 작성할 수 있는 비율이 80%라는 걸 알고 살짝 도전적으로 85%를 목표로 잡았습 니다. 잘하고 있는 거겠죠?

어느 회사입니까? 이렇게 경쟁적으로 커버리지를 높이기 위한 노력을 하다니 감동적이네요.

TDD로 개발을 진행해나간다고 하면, UML은 언제 쓰나요?

UML 이라면 Universe Modeling Language 를 말하는거 맞죠?

전 C++ 개발자인데요, 추천할 만한 테스트 프레임워크는 없나요?

C++ 월드에 들어가실 예정이시라면 요즘엔 Catch나 Boost.Test 나 Google Test 3파전입니다.

깨알

“우물쭈물하다가 내 이럴 줄 알았다.” - 버나드 쇼(George Bernard Shaw)의 묘비명에서 발췌

원래는 그렇게 남기진 않았다고 하네요.

10장 예고

꽤 괜찮은 챕터입니다.

--- attachments ---
09-TDD-related-FAQ.pdf
884-20188-2-2357-53.png

Aged engineer

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-03-26 수요일 오후 9:3 | 이생각 저생각 | 원본

직장동료가 이야기를 들려줬다.

embeded software 업체에 있던 친구가 있는데 그만두고 한전에 취직했다고 한다. 전공이 전기쪽이었다고는 하는데, 어쨌든 수년간의 경험과 지식을 버리고 한전에 간 셈이다.

그런데 그 친구가 말하길,

IT 쪽에서 일하다 나이를 먹으면 기술과 시류에 뒤떨어져서는 결국 찬밥신세인데,
한전에 와보니 여기 사람들은 시간이 지나면 지날수록 기술과 연륜이 쌓여서
오히려 정년 퇴직을 한 사람들을 데려다 쓰질 못해서 안달이라는 거다.

엔지니어라면, 그리고 오랫동안 한 분야에서 갈고 닦는다면 한전 기사 같은 형태가 되어야 맞는데, 이바닥(IT)은 당췌 어케 살아남는가 만이 화두가 되기 십상인 BLOOD RED OCEAN 인 거다.

그래도 열심히 살면 되겠지? 뒤떨어 지지 않도록 노력하면 같이는 가겠지? 싶기도 한데,

사실 하는 일에 익숙해지다 보니, 어느샌가 새로운 일이 두려워져 버려 움추려드는 사람이 되어 자신만의 살길(?)을 찾아 자기 정당화 내지는 합리화의 논리를 펼쳐버리게 되기도 한다.

바로 기술자와 관리자로 나뉘는 거다.

기술에 빠져들어 점점 안드로메다로 가시는 젊은 분들은 곧잘
'기술은 1g 도 모르는 것들이 위에서 말만하며 관리가 고급기술인 줄 착각하며 우릴 무시한다' 며 비난하고

'중요한건 기술이 아니야. 사업의 방향성과 그 안에서 사람을 어떻게 다루느냐 인거야. 뭘 모르는 새파란 것들' 이라며 기술자를 나무라는 윗분들의 모습은 참 마음이 답답하게 만든다.

그 와중에 사람좋고 착하고 그저 성실하다보니,
그렇게나 능력좋고 총기있던 사람들이 소위 말하는 **'시스템'**이라는데 적응해 버려서는
그저 워드/엑셀/파워포인트에만 열중하는 모습을 보며

참 아쉬운 마음이 크게 든다.

Comments

그래.. 한전 알았어..

M-o-N | 2008-03-27 목요일 오후 7:45

이래서 어려운거다

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-07-23 수요일 오후 6:13 | 이클립스 RCP | 원본

JFace 를 이용해서 개발할 때 사용하는 ContentProvider와 LabelProvider .

IContentProvider를 구현하는 클래스들을 보라. (스크롤바가 반 정도라는 것도 감안해서..)

})

LabelProvider는 또 어떻고...-_-;;

})

이러니 어려운거고 이러니 여차하면 삽질하는 거다. -_-;

Comments

무식하게 --;; RCP의 start 부터 중단점을 찍고 시작해보았는데, --;;이거는 머 거의 시작할 때까지 얼마나 걸렸는지..
후미.. 결코 만만하게 볼만한 내용은 아닌것 같습니다 ^^;

승진이 | 2009-07-29 수요일 오후 5:25

--- attachments ---
zrclip_003p4af307c6.png
zrclip_002n6238dbbf.png

REST API 기반에서 리소스를 업데이트 할때는 POST, PUT, PATCH 어떤걸 써야 하나요?

@doortts (doortts) 님이 작성한 이슈입니다.
---

업데이트 할때는 POST? PUT? PATCH?

Summary

HTTP PUT은 create or replace 할 때 쓰는 메서드
리소스의 부분 수정은 POST나 PATCH 쓰세요
PATCH 쓸때는 관련 rfc 문서들이 있으니까 필요하다면 참고하세요

TL;DR

REST 기반의 API 서버를 만들다보면 애플리케이션의 기본 상태관리에 해당하는 CRUD 처리를 각각 HTTP의 POST, GET, PUT, DELETE 메서드로 대응해서 생각하기 쉽습니다.

이중에서 UPDATE 에 사용하는 PUT에 대해 이야기 해보려고 합니다.

예를들면 직원A의 전화번호를 변경해야 하는 경우의 예시입니다

PUT /employees/nl10216 HTTP/1.1
Host: navercorp.cm
Accept: application/json
Content-Length: 68

{"employeeNo":"nl10216", "mobilePhone":"010-9557-8181"}

사번과 전화번호 말고도 여러가지가 제 사원정보에 존재하는데 당연히 다 보낼 필요가 없고 uid에 해당하는 사번과 변경이 필요한 핸번만 본문으로 보냅니다. 아쉽지만 REST 를 잘 지키려고 POST 대신 PUT 쓴건데 이건 오히려 REST 스타일을 위반합니다.

HTTP PUT 메서드의 RFC 문서상 정의는 이렇습니다.

The PUT method requests that the state of the target resource be
created or replaced with the state defined by the representation
enclosed in the request message payload.[주1]

즉, PUT 메서드는 요청시에 담아 보내는 데이터(message payload)를 이용해서 새로운 리소스를 생성(create)하거나 이미 존재할 경우 대체(replace) 하라는 명령입니다. 다시말해, HTTP 명령 대상 URI 의 Resource 부분을 업데이트 할때 사용하는 메서드가 아닙니다.

실제로 PUT의 정의대로라면 navercorp.com/employees/nl10216 에 PUT으로 보냈으니 둘 중 하나가 되야 합니다. 없다면 생성하거나 있다면 교체하거나.

그렇다면 UPDATE로는 뭘 써야 하나?

리소스의 일부 수정일 경우 POST 나 PATCH 를 사용합니다.

그리고 고민되면 그냥 POST 쓰면 됩니다. POST로 리소스를 업데이트하는건 오히려 REST 스타일을 잘 지키는 겁니다.

원래 POST가 그런 애매한 메서드입니다. 정의자체도 "리소스를 생성하거나 기존 리소스에 추가하거나 혹은 의미에 맞게 잘 쓰세요" 같은 식으로 애매한 부분들이 있습니다. 이건 HTTP가 GET 과 POST 두개만 있어서 'GET은 읽기 나머지는 다 POST!' 이런 시절이 있었기 때문입니다.

'부분 업데이트? 뭐 POST 쓰면 되지~ 이전에도 그랬는데 뭐~ 그리고 리소스의 네트워크상의 특정 위치에 존재하는 정보라 수정보다는 새걸로 갱신(replace) 하는 게 더 atomic 한 처리에도 좋을것같아(PUT)' 같은 식으로 생각했던걸지도 모르겠습니다. (마치 파일시스템의 file update의 atomic lock과 비슷한 식?)

PATCH 가 더 멋져보이는데?

PATCH 메소드는 나중에 따로 만들어진 스펙입니다. PATCH Method for HTTP (번호도 외우기 쉬운 5789. 이런식으로 낭비되는 내 뇌 메모리)

The PATCH method requests that a set of changes described in the
request entity be applied to the resource identified by the Request-
URI.

'이제부터 업데이트는 PUT이 아니라 PATCH 쓰겠어!' 라고 마음먹고 나면 이제 주의해야 할 부분이 있습니다.

특성(property) 측면에서 PUT 메소드는 'safe 하지는 않지만 idempotent' 합니다. 즉, 리소스의 변경을 일으키지만 여러번 실행되어도 1번 실행된것과 동일한 결과를 가져야 한다(더 어려운 말로 멱등성)입니다. PATCH는 'safe 하지 않고 idempotent 하지도 않는 메서드'라고 가정되어 있습니다. 그래서 여러번 실행되면 결과가 계속 달라질 가능성을 가정합니다. 그래서 신경쓸 부분이 상대적으로 많아집니다. 문서를 보면 알겠지만 PATCH 메소드를 사용하려면 Etag의 조합과 더불어 MUST, MUST NOT, SHOULD NOT 시리즈의 제약 내용들이 펼쳐집니다.

이런 저런 스펙내용을 떠나 기본적으로 리소스의 부분수정이라 충돌에 대한 상황이 고려되어야 하는 것도 필연적입니다.

관련해서는 고민해야 할 것들이 많은데 다행히/당연히 사람들이 미리 고민해서 관련 표준문서들을 만들어 놓았습니다.

다음 두 개를 참고하면 됩니다.
JavaScript Object Notation (JSON) Patch
Detecting the Lost Update Problem Using Unreserved Checkout

주의
HTTP PATCH 메소드를 사용하고 Message Body로 JSON 을 사용한다고 해서 반드시 JavaScript Object Notation (JSON) Patch 나 JSON Merge Patch 등을 구현해야 한다는 뜻은 아닙니다. 컨텐츠 수정에 대해서는 Detecting the Lost Update Problem Using Unreserved Checkout 같은 문제들과 상황들을 고려해야 하는데 위에 적힌 스펙기반으로 JSON PATCH 를 사용하면 그런 문제들에 대해 고민해 놓았으니까 쓰기만 하면 됩니다! 같은 이야기입니다.

그런데 읽다 보면 음.. 그냥 POST 쓰자..라는 생각이 들지도 모릅니다. (REST 스타일 잘 지켜서 API 서비스 만들기 어렵네)

각주

[주1] message payload: HTTP 통신때에 실어 보내는 본문(Message Body)은 곧잘 Enclosed Entity 혹은 Message Payload 라고도 부릅니다.

참고자료:
Wikipedia의 REST 정의
Roy Fielding논문중 Experience and Evaluation 부분 - 진지하게 경험담 듣고 싶으면 일독을 권합니다

.
.
.
.
.
.
.
.
.
One more thing...

아는 동생이 물어보면 아는척 대답해 줄 때 쓰는 REST 설명

우선 REST는 REST Architectural style 혹은 RESTful 이라고 불러야 합니다. 그리고 다음의 두 가지를 기반으로 가정하고 있습니다

비상태 프로토콜(Stateless protocol)과 표준명령들(Standard operations)

RESTful 웹 서비스에서는 비상태 프로토콜로 HTTP 를, 표준명령어로는 HTTP Method를 사용합니다. 이 두가지를 기반으로 자원(Resource)의 위치를 가르키는 네트워크 고유 주소(URI)와 자원의 상태 변이를 다루는 방식을 RESTful 웹 서비스라고 말합니다.

정확하게 쓰려고 하다니 말이 불필요하게 어려워졌네요.

다시 돌아가서, REST는 HTTP 표준 명령어(Methods)를 상황과 URL 에 맞게 잘 써야 더 RESTful 한 서비스가 된다는 이야기 입니다.

'이봐! 목적이 그게 아니잖아! 좋은 서비스나 앱을 만드는것이 목적이지 더 RESTful 해지는것이 목적이 아냐!' 라는 말이 당연히 나오는데요, 사실 더 RESTful 하려는 목적은 더 RESTful 할 수록 더 성능도 좋고 안정적이고, 재사용을 통해 성장하는 시스템이 가능해질거라 믿기 때문입니다.

RESTful systems aim for fast performance, reliability, and the ability to grow by reusing components that can be managed and updated without affecting the system as a whole, even while it is running.

RESTful 의 지향점이 그렇다는거지 RESTful 하면 무조껀 좋아요..는 당연히 아닌거겠죠.
하지만 기술적 이상에 한없이 다가가려는 노력, 그 노력과 수정, 그리고 넘어섬과 반복.

그게 어제보다는 1 mm라도 더 나아진 엔지니어가 되는 길이 아닐까 생각해봅니다.

네. 뭐. 그렇습니다.

7장 - 개발 영역에 따른 TDD 작성 패턴

@doortts (doortts) 님이 작성한 이슈입니다.
---

이전: 6장 - Unitils 단위 테스트 지원 라이브러리
다음: 8장 - TDD에 대한 다양한 시각

7장 본문

07-TDD-Patterns.pdf

읽기전에

그나마 시절을 덜 타는 챕터입니다. 하지만 역시 좀 올드하네요.
7.2.2 뷰 TDD는 통채로 스킵하셔도 무방합니다.

보충 설명

테스트는 정말 필요한 부분부터 시작하세요.
- 익숙하지 않으면 쉬운것부터 만들어보세요.
규칙에 얽매이기보다 이 부분에 테스트 코드가 필요한가 생각해보세요.
테스트 코드가 복잡하면 뭔가 잘못된겁니다.
- 의존성이 높게 설계가 되어 있거나
- 지금 본인이 뭘 테스트하려는건지 혼란스러운 상태이거나
테스트 커버리지를 위해서, 혹은 '테스트 코드'를 위한 테스트 코드는 작성하지 마세요.
- '테스트 코드'를 위한 테스트 코드 = 왠지 테스트 코드를 작성해 놓으면 뿌듯할 것 같은 느낌
- 테스트 커버리지를 위한 테스트 = 우리는 테스트 커버리지 90% 이상!! 이런 느낌의 목표
근래에 새로 시작되는 웹 기반 프로젝트는 보통 React, VueJs 등의 SPA(Single Page Application) 기반과 Java 기준으로는 Spring Boot 로 시작하는 추세입니다. 양쪽 다 조금만 검색해보시면 다양한 예제와 설명을 찾을 수 있습니다.
- 이 경우, 블로그 글 검색보다는 official site 의 testing 항목을 참고하시는걸 추천드려요.
- 예) Spring Boot testing React Test utils
테스트 코드 자체도 업무 코드처럼 지속적으로 가다듬는 노력이 필요합니다. (관련 이야기는 8장때 좀더)

생각이 바뀐 부분

데이터 베이스 테스트에 대해서 현재는 다소 비판적임. 할 필요가 있나.
- 자칫 테스트라는게 JDBC가 잘 동작하는지 하이버네이트(hibernate)는 잘 동작하나 같은 테스트가 될 가능성이 있습니다.

좀 더 강조했어야 하는 부분

꼭 읽으세요! 두 번 읽으세요!

깨알

이거 너무 좋지 않나요? ㅎㅎ~

8장 예고

--- attachments ---
07-TDD-Patterns.pdf
391-20187-26-2159-59.png
692-20187-26-221-14.png
376-20187-26-223-51.png
145-20187-26-224-33.png
729-20187-26-226-29.png
216-20187-26-227-34.png
779-20187-26-2214-29.png

Code for whom

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-05-13 화요일 오후 4:53 | 이생각 저생각 | 원본

이바닥에서 키보드 좀 쳤다 하는 사람이라면, 흔히 인용되는 문구 중에 파씨 형님(=Martin Fowler)이 말한

})
컴퓨터가 이해하는 코드는 어떤 바보라도 짠다. 좋은 프로그래머는 사람이 이해하는 코드를 짠다

라는 글을 본 적이 있을거다.

참, 좋은 글귀다.

또 Software 칠판에 선좀 그었다 하는 백형(=Kent Beck)은

})
내가 사용하는 비용 절감 전략은 모든 프로그래머가 커뮤니케이션하기 쉬운 코드를 짬으로써, 유지 비용을 줄이는 것이다.

라고 말했다고 한다.

역시 좋은 글귀다.

어디선가는

당신이 타인의 코드를 쉽게 잘 이해했다면 당신이 뛰어난 것이 아니라 코드를 작성한 사람이 뛰어난 것이다

라는 글귀도 본것 같다.

자, 그러면 이것들이 공통적으로 의미하는 것은 무엇인가?

혼자 방에 앉아서 커피를 홀짝이며 짜서는 결국 혼자만 쓰는 프로그램이 아니라면, 혹은 키보드에 손을 대는 순간 의식을 읽어 왜 이렇게 짰는지 알아버린다는 사이코메트리(Phychometry)와 함께 작업하는게 아니라면,

돌고래와 IQ경쟁을 벌이는 범인들도 소설책을 보듯 읽을 수 있어야 하고,

적어도 이게 날자는 건지 헤엄치자는 건지는 누구나 제대로 이해할 수 있게 프로그램을 작성해야 한다는 소리다.

얼마전에 읽은 어떤 글은

'Email은 누구의 것인가? 쓴 사람(writer)의 것인가? 읽을 사람(receiver)의 것인가? '

라며 커뮤니케이션에서 상대 배려의 중요성을 말하고 있었다. (신 문명의 총아로 인정받다 이제는 쓰레기통처럼 변해 버린 Email 이지만 어쨌든.)

마찬가지로 협업프로그래밍에 종사한 사람은 자신이 작성하는 코드는 누구를 위한 코드인가? 에 대해서 진지하게 고민해 봐야 한다.

개인적으로 생각하는 아름다운사람의 기본 조건은 자신에 대한 존중만큼이나 타인에 대해 배려를 할 줄 아는 사람이라 생각한다. (특히 약자에 대해서는 더욱더!)

그런 의미에서 getNmc() 가 getNameCode 인지 getNativeMachineCode 인지 읽는 사람의 상상력을 한껏 자극해 들판으로 뛰나가고 싶게 유도하는 짓은 미국산 소고기만큼이나 비추인 거다.

Comments

내 언젠간 이 글에 Trackback 한 번 달 것 같네!
내가 요즘 <모모모 TFT>에 있잖아. 참 진취적이고 도전꺼리여서 좋은데...

사람들이 왜 패턴도 많이 알고, 책도 많이 읽은 똑똑한 사람들이 그 쉬운 "기본 조건" 문제는 소홀하게 대하는 걸까?

M-o-N | 2008-05-24 토요일 오전 1:19

공감하며 읽다가, Email 얘기에선 가슴이 뜨끔하네... 난 그래도 나 하고싶은대로 떠들며 살고 싶어.... 읽기 싫으면 말라지...쳇....--;;;

yarrie | 2008-07-02 수요일 오후 11:6

--- attachments ---
zrclip_001n77050d56.png
zrclip_002p37700e20.png

14 Rules for Faster-Loading Web Sites

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-05-02 금요일 오후 5:30 | Better SW Development | 원본

14 Rules for Faster-Loading Web Sites

참조 : http://stevesouders.com/hpws/rules.php

Comments

Faster-Loading Web Sites!!
오메!
이런 건 내 분야인줄 알았는데..

M-o-N | 2008-05-24 토요일 오전 1:24

FireFox vs Chrome 이제는 TraceMonkey vs V8 엔진의 싸움?

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-09-10 수요일 오후 2:29 | 이생각 저생각 | 원본

FireFox vs Chrome 이제는 TraceMonkey vs V8 엔진의 싸움?

요즘 IT 호사가들은 구글 크롬의 자바스크립트 엔진인 V8 엔진이 빠르다고 난리다.

파이어폭스(이하 파폭) 스폰서인 구글에서 브라우저를 내보냈으니, 파폭측도 예민해 졌나 보다.

시기도 묘하게 나온 V8엔진.(IE 8 beta 가동중에 나왔다)

파폭3.1에 탑재될 차세대 엔진인 TraceMonkey 개발진도 즉각 대응 발표를 하였다.

뭐, 예상했겠지만, 한마디로 '우리께 더 좋다!'라는 내용이다.

하지만, 이미 나와서 쓰고 있는 제품(크롬)과 알파 단계인 제품(파폭3.1)은 경쟁이라고 하기 어렵다고 본다.

winner get them all 방식의 세계에서 늦으면 이미 한 수 접고 가는 것이기 때문이다.

(이하 TraceMonkey 팀의 발표자료)

})

Comments

Grease Monkey, Trace Monkey ...
원숭이 이름 들어간 것이 점점 많아져.. 가만, V8은 야채주스 이름이잖아!

M-o-N | 2008-09-15 월요일 오후 1:10

V8도 이젠 맛이 세 가지나 있게 되었다구!

doortts | 2008-09-16 화요일 오전 12:39

--- attachments ---
zrclip_001n49afa708.png
zrclip_002n50f68c3b.png

10장 - 실습 예제

@doortts (doortts) 님이 작성한 이슈입니다.
---

이전: 9장 - 자주 접하게 되는 질문들, FAQ

10장 본문

10-working-practice.pdf

읽기전에

이 챕터는 세월의 흐름과 무관하게 여전히 유효합니다. TDD를 학습할때 한 번씩 시도해볼만한 챕터라고 생각합니다.

도전과제

본인이 현재 사용하는, 혹은 학습하고 있는 언어로 과제를 읽고 먼저 만들어보세요.
그 다음 글쓴이의 접근 방법과의 차이점을 살펴보시면 더 도움이 될 겁니다.

보충 설명

요구사항(requirements)을 정제하는 과정은 매우 중요합니다. 지금 시점이라면 저는 사용자 스토리 방식으로 정제 할 것 같습니다.

생각이 바뀐 부분

자판기 예제에서는 테스트 코드를 바로 만들기 시작했는데 사전 설계 부분이 빠져 있습니다. 사전 설계를 미리 했었어야 합니다.

좀 더 강조했어야 하는 부분

실제 업무에서는 To do 리스트 정도로 개발하기보다 작업할 내용을 이슈로 등록하고 이슈 본문에는 어떤식으로 개발을 진행할 것인지에 대해 설명을 적고 진행하는것이 좋다.
IDE와 컴파일러의 도움을 적극 받는 것이 시간 절약에 큰 도움이 됩니다.

깨알

봄싹. 그리운 이름이군요. 그런데 svn 을 썼었네요.

11장

본문: 11-Test-Automation-and-coverage.pdf

지금 시점에서는 11장은 통째로 걷어내도 무방한 챕터가 아닌가 싶어요.

What's the next?

제목 그대로의 '본 책보다 더 가치 있을 수도 있는 부록'이 마지막으로 남아 있습니다. 지금봐도 꽤 괜찮은 내용들이 들어 있습니다.

해당 내용은 이미 2011년부터 공개되어 있는데요 여기에서 보실 수 있습니다.
책 일부 공개: 테스트주도개발 : TDD실천법과 도구

--- attachments ---
10-working-practice.pdf
70-20188-15-2314-59.png
11-Test-Automation-and-coverage.pdf
698-20188-15-2322-21.png

이클립 RCP 5번째 생일

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-04-26 토요일 오후 7:30 | 이클립스 RCP | 원본

5년전 bugzilla 에 앞으로 이클립스를 non-IDE 형태의 독립형 Rich Client Application 으로 만들어달라는 요청이 처음으로 등록되었고, 현재에 이르렀다고 한다.

이제 RCP 도 equinox p2 프로젝트와 함께 조만간 업그레이드 된다고 한다. (두근두근)

아직은 대중성에서 다소 부족하지만, 새로 거듭나는 모습에서는,

현재의 인기없는 JAVA GUI DESKTOP Application 의 category killer 가 되어 주길 바란다.

Happy birth day rcp!

4장 - Mock 을 이용한 TDD

@doortts (doortts) 님이 작성한 이슈입니다.
---

이전: 3장 - TDD 좀 더 잘하기
다음: 6장 - Unitils 단위 테스트 지원 라이브러리

안내: 본문을 읽지 않고 아래의 코멘터리만 읽는 걸 가정해서 작성하진 않았습니다.

4장 본문

04-TDD-with-mock.pdf

읽기전에

Mock Framework는 다 건너띄고 Mockito 만 보세요. 충분합니다.

도전과제

Jest 기반에서 Javascript나 TypeScript로 실습을 따라갑니다

보충 설명

생일 역설 (Birthday Paradox)은 교양으로 읽어보세요
요즘엔 Test Double 이라는 용어도 잘 안쓰고 그냥 Mock 객체, Mock을 만드는걸 Mocking 이라는 표현을 더 많이 씁니다.
- 하지만 알아두면 구분해서 표현할때 좋습니다.
- 생각해보면 XUnit Test Patterns 책은 내용이 너무 끝까지 간 느낌이 있어요. (그걸 어떻게 다 봐!!)
Test Spy는 요즘도 종종 쓰게 되는것 같아요.
- js 에서는 Sinon을 이 용도로 많이 썼습니다만 요즘은 대부분의 경우 Jest 가 Mock 이며 Spy 기능이 잘 되어 있어서 Jest 이외엔 따로 쓸 필요도 못 느끼는것 같습니다.
Snapshot 테스팅이라는 것도 있는데 보통 equals(expected) 나 toEqual(expected) 같은 assert구분을 쓸때 expected 를 일일히 다 미리 표현하기 어려운 경우 최초 실행시 result를 expected로 저장(실제로 파일등으로 저장)해 놓고 다음 실행시부터는 이전 snapshot과 동일한지 비교하는 방식의 테스팅입니다.
- 참고: https://jestjs.io/docs/en/snapshot-testing

Property-Based Testing, PBT

최근에는 property-based testing (PBT) 도 등장해서 조금씩 사용되기 시작했습니다.
- 예제기반 테스트에서도 예전엔 삼각측량이라는 표현으로 multiply(3, 3) = sum(sum(3, 3), 3) 과 같아야 한다는 방식으로 테스트코드를 작성하길 추천하는 스타일이 있었습니다. (sum은 신뢰가능한 함수라고 가정)
- 하지만 이것도 예제기반으로 사람이 케이스를 작성하는 것이었다면 PBT는 시스템의 range 기반 auto generation 과 randomizing 을 기반으로 기계적으로 값을 검증하고 fail 케이스를 찾아내는 방식입니다.
- 참고:
  - Js world 에 계신분은 이쪽을 https://hackernoon.com/property-based-testing-4330e3e77381
  - Java world 이신분은 https://www.leadingagile.com/2018/04/step-by-step-toward-property-based-testing/
JUnit 쪽에서도 이미 예전에 Parameterized Test 와 Theory 라는걸 지원하고 있었습니다.
- 관련 내용은 appendix에 담아 놓았고 해당부분의 PDF는 이미 2011년도에 공개해 놓았었습니다. 관련글은 여기

좀 더 강조 되었어야 했다고 생각하는 부분

챕터 뒷부분에서 저자 한마디로 표시할 것이 아니라 예제 소스에서 시작부터 // Given // When // Then 주석을 사용했어야 했다.
Mock 사용 시 유의사항은 꼭 읽어보세요.
- Mocking을 할때는 대상이 되는 서버나 API, 데이터는 자주 변하지 않는 대상이 되어야 합니다.
- 즉, 서버도 한창 개발중이라 api 가 계속 바뀔때는 layering 에 대한 mock 기반 테스트는 현실괴리만 높이는 경우가 생깁니다.

깨알

책 쓸 때(초안 2008년)만 해도 MD5를 예제에서 쓸만 했는데 이젠 SHA1도 충돌이 문제되는 시절이네요.

5장 예고

5장은 PDF 파일만 올릴 예정입니다. 할말이 없어요.

이유는...

어잇쿠! 마우스 드래그 실수로 여기 이미 올렸네요! (거짓말)
05-DbUnit.pdf

6장 예고

--- attachments ---
337-20187-23-2229-17.png
05-DbUnit.pdf
786-20187-23-2230-51.png
691-20187-23-2231-59.png
717-20187-23-2233-33.png
633-20187-23-2233-54.png
444-20187-23-2235-56.png
793-20187-23-2236-30.png
438-20187-23-2236-53.png
04-TDD-with-mock.pdf

이름없는 액션은 허공에 발길질

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-05-02 금요일 오후 6:43 | 이클립스 RCP | 원본

확장을 이용하지 않은 사용자정의 Action 은 반드시 ID 를 지정해 주어야 한다.

아니면 regist( someAction) 시에 에러가 발생한다.

ActionBarAdvisor Class ...

})

Assert 로 id 가 없을경우 run 실패를 만들어 버린다.

그리고 Action Class 에 final static String 으로 ID를 설정해 놓아도 setId 안하면 말짱 황!

})

--- attachments ---
zrclip_002p1259502b.png
zrclip_003n262e77b2.png

JAVA ONE Wrap-up seminar 회고

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-06-25 수요일 오전 12:11 | 잊기전에 회고 | 원본

지나면 잊으니까, 잊기전에 회고!

장소 : 이화여대 이화삼성관 103호
시간 : 6.21 토, 오후 1시 ~6시

느낀점과 ToDo (세미나 내용과 도중에 떠오른 개인생각의 혼합)

신상철 JAVA evangelist 씨의 강연은 역시 굿 (희끗한 머리... 나이가 얼마나 되셨을까?)
- javapassion.com 이 이분 사이트였을 줄이야.. (사이트에는 주인이 "상신" 이라고 나옴)
JAVAFX 를 엄청 미는 느낌?
netbeans와 glassfish 의 통합도도 굿! (넷빈즈, Ruby 연습할때 이외에 쓰지는 않지만 볼때마다 느끼는건 대단하다는 생각뿐)
JAVA 6 - Modularized JRE 로 변모
synchronized -> atomic keyword로!
허광남 - 생각보다 잘 생겼네.. 그리고 나이에 비해 동안이네. (자기반성 中 -_-);
SW는 그 기조가 건축이면서 요구사항은 건축물과 다르다는걸 생각하자.(=잦은 변경을 요한다)
TDD를 좀더 봐야겠다. (coverage 라던가, Mock object, automated test case generation)
DATA OBJECT, 특히 collection type data의 Test에 대해서 좀 더 고민(reflection을 이용하면 되지 않을까?

6장 - Unitils 단위 테스트 지원 라이브러리

@doortts (doortts) 님이 작성한 이슈입니다.
---

이전: 4장 - Mock 을 이용한 TDD / 5장 DbUnit
다음: 7장 - 개발 영역에 따른 TDD 작성 패턴

6장 본문

06-Unitils.pdf

읽기전에

현 시점에서의 Unitils의 가치와 현실은 아래 구글 트랜즈 스샷을 보면 이해가 될겁니다.
테스트코드를 만들때 이런 고민들이 발생하는구나 정도로 이해하고 슥 읽고 넘어가면 되는 내용들입니다.

보충 설명

동치성과 동등성은 지금도 구분해서 테스트 해야 하는 내용입니다.

깨알

10년 전 쯤에는 "프레임워크(Framework)와 라이브러리(Library)의 차이가 뭘까요?" 퀴즈놀이가 한창이었습니다.

7장 예고

7장은 나름 볼만합니다! 할말도 쏠쏠히 있네요.

--- attachments ---
742-20187-24-2036-48.png
712-20187-24-2041-48.png
999-20187-24-2042-28.png
975-20187-24-2045-48.png
06-Unitils.pdf

프리젠테이션 젠

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-06-29 일요일 오후 4:49 | Books | 원본

})

Presentation Zen: Simple Ideas on Presentation Design and Delivery

외국에서는 꽤 유명한 책이라고 한다. (Amazon 평점 5/5 ) 특히 저자 가르 레이놀즈는 presentationzen.com 사이트를 운영하고 있으며, 이 책으로 파워포인트나 키노트로 하는 기존 프리젠테이션 방식에 일대 변혁을 불러일으킬 것이라는 평을 듣고 있다.

아래 내용은 테크니컬 에반젤리스트인 구의 가와사키의 이 책을 나타내는 소개 PT 다.

이것 만으로도 배울 내용이 있고, 더욱더 책을 끌리게 만들고 있다.

})

Comments

저말 진짜예요? 저 책 사봐야 되겠는데, 비싼건 아니겠지? 실망하면 책임지세요~~ㅋㅋㅋ

yarrie | 2008-07-02 수요일 오후 10:58

--- attachments ---
zrclip_001p1f96139f.png
zrclip_002n62cfb3c.png

오늘 받은 '프리젠테이션 젠', 포장 정성에 놀라다

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-07-15 화요일 오후 11:31 | Books | 원본

처음 받았을때 생각보다는 얇은 책 두께에 놀랐다.

그러나 정말 놀란것은 겉 포장 박스를 뜯었을 때이다.

})

세상에나! 예쁜 포장지로 포장을 해서 보내주신 거다! (!!!!)

})

어찌보면 별것 아닐 수도 있지만, '에이콘 출판사'를 다시 보는 계기가 되었다고나 할까..

})

사진으로는 잘 표현이 안 되었지만, 겉 표지도 질감이 예사롭지 않다. 꽤나 고급스러운 느낌을 주기에 충분하다.
(관련업무 종사자에게 선물용으로도 손색이 없을 듯)

})

책 자체도 미려한 편집과 높은 품질의 사진들로 채워져 있었다. 내용은 차치하더라도 적어도 구매자가 책 값이 아깝다는 생각이 들지는 않을게 분명하다.

평소에도 에이콘 출판사의 책들이 꽤 품질이 높다고 여겼었는데, 어떤면에서 이번 책, 프리젠테이션 젠은 당분간 그 정점에 있는 책이 되지 않을까 생각된다.

더불어 좋은 책 보내주신 '에이콘 출판사'분들에게 감사의 마음을 전하고 싶다.

Comments

음 포장지를 보기 전까지 그렇게 탐나지 않았던 책이었는데,
지금은 이 말이 하고 싶어

"줘!"

M-o-N | 2008-08-08 금요일 오전 9:5

--- attachments ---
IMG_3942.JPG
IMG_3941.JPG
IMG_3939.JPG
IMG_3938.JPG

XUnit Test Patters

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-08-03 일요일 오후 11:46 | Books | 원본

})

http://xunitpatterns.com/

아쉽게도 영문책뿐이지만, 우리나라에도 번역되어 나왔으면 좋겠다. 아쉽게나마 위 사이트에 가보면 책 내용을 사이트에서 살펴볼 수 가 있다. (거의 대부분의 내용이 오픈되어 있는 듯 한데...)

그 양이 적지 않아 보려면 시간이 좀 걸릴 듯 하지만, 그만한 가치는 있을 것 같다.

Comments

곧나올껍니다;;ㅋ 누가 지금 번역작업중에 있거든요;;ㅋ

HelolS | 2008-12-30 화요일 오후 11:29

--- attachments ---
zrclip_001n19bcc4bd.png

Nihilistic punch line?

@doortts (doortts) 님이 작성한 게시글입니다.
---

doortts | 2008-04-22 화요일 오후 11:30 | 이생각 저생각 | 원본

인생의 행복을 타인의 시선에서 찾는다면
그래서 남들이 어떻게 생각하느냐에 따라

스스로가 가슴뿌듯 행복하게,
때로 부끄러움에 비참해하는 삶을 산다면

자신의 인생을 어찌 내 것이라 말할 수 있겠는가?

행복은

현재 자신의 상황이 아니라
현재 자신의 마음가짐에 달린거라는걸

잊지 말자.

Nihilistic punch line
: 허무주의의 멋들어진 농담

재미있는 단어라서 그냥 뜻없이 써본다.

2장 - JUnit and Hamcrest

@doortts (doortts) 님이 작성한 이슈입니다.
---

이전: 1장 - 테스트주도개발 Test Driven Development
다음: 3장 - TDD 좀 더 잘하기

2장 본문

02-JUnit-and-Hamcrest.pdf

읽기 전에

지금은 JUnit 5를 쓰는 시절이라 말그대로 개정이 필요한 챕터입니다. 절판의 이유 중 하나가 된 챕터이겠네요.
- Java 개발자라면 https://junit.org/junit5/docs/current/user-guide/ 를 참고하시는 편이 나을 것 같습니다.
- See: https://www.ibm.com/developerworks/library/j-introducing-junit5-part1-jupiter-api/index.html
Hamcrest 는 단순히 몇 개의 assertXXX 시리즈로 동작하던 Junit의 assertion 을 좀 더 확장해서 읽기 편하기 만들어주던 유창한 비교 표현식(Fluent Assertion) library 였습니다.
요즘엔 이런 Fluent Assertion 라이브러리로 구글의 Truth 도 많이 쓴다고 들었습니다. http://google.github.io/truth/
다시 본다면 저는 테스트는 정직한 Junit 으로만 작성하던가 아니면 Kotlin + Truth 조합으로 할 것 같습니다.
책 출간 당시 기준으로 꽤 유용했던 부분은 Juni4의 Rule 들이었습니다.
라이브러리와 도구 사용법이 위주였던 이 챕터의 현재 시점에서의 의의는 마지막 저자 한마디쯤이 아닐까 싶습니다.