My scribbling

최근 Billboard Hot Chart 에서 1위를 차지하고 있는
Katy Perry의 노래 I Kissed A Girl 을 흥얼거리다 이노래 Anti 가 많지 않을까? 라는 호기심이 발동했습니다.

이유는 노래 내용이 매우 자극적이고 The HomoSexual 들이 기분나빠할 구절들이 조금씩 들어가 있기 때문입니다.

겉보기엔 그저 Having Fun 하고 싶어 동성과 재미난 게임을 했다는 가사지만,
Katy 가 원래 독실한 Christian 이었고, 가스펠 가수 였다는 사실은 게이나, 레즈들에게 선입견을 주는것 같습니다.

아래는 가사 중 일부인데, 게이들이 이야기하는 문제가 될 만한 부분은 Bold 처리했습니다.
구글링의 도움으로 정리된 의견을 개진한 블로그를 하나 찾았습니다. -> 클릭

이하는 1절 가사입니다.
This was never the way I planned Not my intention
I got so brave, drink in hand Lost my discretion
It's not what, I'm used to Just wanna try you on
I'm curious for you Caught my attention

I kissed a girl and I liked it The taste of her cherry chap stick
I kissed a girl just to try it I hope my boyfriend don't mind it
It felt so wrong It felt so right
Don't mean I'm in love tonight I kissed a girl and I liked it I liked it

No, I don't even know your name It doesn't matter
You're my experimental game Just human nature
It's not what, good girls do Not how they should behave
My head gets so confused Hard to obey

아뭏든 전, 이 가수 가리마는 어색하지만 목소리가 참 좋군요. ^^

프로젝트에서 탐험적 테스트(exploratory testing)라는 실천방법을 적용하며
보다 나은 동기부여를 위해 상품을 스플린트 보드에 붙여놨습니다.
참으로 자극적이지 않나요?

물론 긍정적이고 능동적인 팀원들의 참여 덕분에
10명의 구성원이 한 시간동안 80개의 버그를 찾게 됐지만,
상품또한 매우 즐거운 아이디어 였습니다. ^^

Agile 방법론을 접하고 프로젝트에 적용하면서, 누구나 한번쯤 이런 생각을 해봤을 것이다.

How Agile I'm (난 얼마나 애자일한가?)

이를 거부감없이 측정할 수 있기위해
IBM Developer group에서 소개한 자료가 눈에 띈다.

2002년부터 80 여개 팀의 경험을통해 "un-assessments" 를 테마로 Agile Evaluation Framework 이라는 개념을 만들었다.

XP, TSP, RUP 세 가지 테마로 작성되어 있다.

소개자료 보기 -> Agile Team

TDD(Test Driven Development)에 대한 지식을 접할때마다 궁금하던게 있다.

TDD는 너무나 많은 시간을 테스트에 할애하도록 만드는 것이 아닌가?

우선 TDD는 테스트 케이스를 만들고 고객 요구사항 변경에 따라 변경된 기능에 따라서 테스트 케이스를 변경시켜야 하는 작업에 많은 시간을 소비한다.

또한, TDD를 할 때 처음에 계획된 테스팅 케이스들을 만들고 테스트하는 시간을 제외하더라도,
특정 개발자가 커다란 테스트 케이스를 돌릴때 테스트 툴이 보여준 failure 에 대해, 다른 팀과 연관이 되어 있거나, 솔루션의 라이브러리를 참조하여 조치 하기때문에 많은 비용과 시간을 쏟아야 할 수도 있다.

그러면 어떤 식으로 우리는 TDD를 접근하면 좋을까?

Wikipedia 에서는 소프트웨어 테스트를 다음과 같이 말하고 있다.

" Software testing is the process of checking software, to verify that it satisfies its requirements and to detect errors "

Software testing 에는 여러 기법들이 있지만, 우리는 테스트를 일반적으로 

1. 고객의 요구사항을 만족시키는지 확인하는 행위
2. 결함을 찾아내는 행위

라고 이해한다.

우리가 알고 있는 TDD 의 테스트는 정말 테스트처럼 보인다. 자동화된 Test Tool 을 사용하고, Test Case 를 만들고, Test 를 위한 여러가지 개발자들의 테크닉이 들어간다.

하지만 일반적인 테스트는 아니다. 테스트는 기능이 에러없이 잘 돌아가는지 수행하는 활동이다.

게다가 개발자들이 만드는 테스트 케이스는 Developer & Function Friendly 하다.
Adhoc Test(개발자 직관에 따르는 테스트기업)과는 비교할 수 없겠지만, 어쨌든 개발자들이 자신이 생각한 기능에 대한 테스트 케이스를 집어 넣기 때문에, 다양한 형태의 테스트가 어렵다.

그럼 TDD는 어떤 기능을 하고 있을까? 그리고 무엇을 기대 할 수 있나?

난 TDD의 테스트는 Test를 위한 것이 아닌, 소스코드에 있는 각종 Function의 Spec 을 결정해 주는 것이라 생각한다.
전통적인 Spec 을 명시하는 방법에서 벗어나, Function의 최소 Boundary를 결정해 주는것이다.

굳이 산출물로 이야기 하자면,
프로그램 사양서나 유즈 케이스 정의서 보다 작성하는 코드에 적합한 분석과 설계 경계를 지어주는 것이 아닐까?

항상 일정에 쫓기는 운명을 타고난 우리나라 개발자들에게, 이것을 소프트웨어의 품질을 견고하게 보다 향상 시킬 수 있는 기능 Spec 정의를 위한 단계라고 하면 어떨까? 대체할 수 있는 산출물을 줄이고 말이다.

나부군님의 도움으로 Python 을 공부하게 되면서,
Python 은 Ruby 와 상당히 비슷하다는 인상을 지울 수 없었다.

구글링으로 이를 아래의 관점들에서 비교한 wiki 페이지를 찾을 수 있었는데, 상당히 재미있다.
=> PhthonVSRuby

• Heritage and Philosophy
• Popularity
• Readability
• Ease for Beginners
• Ruby Blocks and Python Lambdas
• Development Environments
• Community and Documentation
• Libraries, Platforms and Applications
• Performance

Overview 에 있는 재미난 내용중 하나가,
Ruby는 Python에 비해 more elegant 하지만, 함축성을 잘 구현하는데 꽤나 스트레스를 받을 것 같다는 것. ^^;