페이지

2006년 6월 27일 화요일

월드컵 이야기

2002 Worldcup

안타깝게도 우리나라는 16강에 오르지 못했다. 하지만 우리는 원정 첫승을 거두었고 프랑스와 대등한 경기를 펼쳤다. 무엇보다 지칠줄 모르는 우리의 투지를  확인할 수 있어서 좋았다.

월드컵은 분명 상업적이다. 많은 사람들의 이해 관계가 얽혀있고 때론 그것이 승부에 영향을 미치기도 한다. 좀 더 민주적인 시스템이 도입되어 진정한 스포츠 정신을 느끼고 싶다.
하지만 그런 모든 것을 떠나 잠시나마 많은 사람들이 하나가 된 것, 지구에 사는 많은 사람들이 함께 평화롭게 웃고 즐기고 때론 안타까워하는 모습을 통해 월드컵에서 좋은면을 찾고 싶다.

누군가는 월드컵이 국가주의, 민족주의를 불러일으킨다고 하지만 그래도 우리가 토고, 세네갈 이런 나라를 기억하게 되는 것은 순전히 월드컵을 통해서 가능한 것이다.

그렇다 월드컵은 지구촌 최대의 축제다. 그리고 모두에게 희망은 있다. 우리도 강팀이 될 수 있다는...

2006년 6월 19일 월요일

201가지 소프트웨어 개발 원칙



이 가운데 쓸만한 몇가지 원칙을 뽑아 본다면..

일반원칙

  • 품질이 제일이다.

  • 사후에 품질을 만들어 넣으려하지 마라.

  • 성능보다 신뢰성이 더 중요하다.

  • 시제품을 고객에게 빨리 보여준다.

  • 처음 시도하는 것은 폐기할 작정으로 개발한다.

  • 보면 볼수록 더 많은 것을 원한다. (변경에 대비하자)

  • 개발중의 변경은 피할 수 없다.

  • 가능하면 개발하기 보다는 구매한다.

  • 사용자 메뉴얼이 간단하게 되도록 소프트웨어를 개발한다.

  • 아무리 복잡한 문제라도 해결책은 있다.

  • 소프트웨어 도구는 우수한 개발자에게 제공한다.

  • 대세를 따를 때는 주의해야 한다. (신기술대한 맹목적 수용은 위험)

  • 문서표준을 사용한다

  • 모든 문서에 용어정의를 한다.


요구사항 원칙

  • 요구사항이 불명확할수록 비용예측이 어렵다.

  • 시제품으로 사용자 인터페이스 선정의 위험을 줄인다.

  • 요구사항의 우선순위를 정한다.


설계원칙

  • 설계산출물에서 요구사항을 추척한다.

  • 문서가 없는 설계는 설계가 아니다.

  • 캡슐화한다.

  • 가능하면 재사용한다.

  • 단순하게 개발한다.

  • 특수한 경우를 많이 만들지 않는다.

  • 변경이 쉽게 설계한다.

  • 효율적인 알고리즘을 사용한다.

  • 뛰어난 설계는 뛰어난 설계자가 한다.

  • 무모한 값을 입력하면 적절한 오류 메시지를 출력하도록 한다.


코딩원칙

  • 글로벌 변수를 사용하지 않는다.

  • 의미있는 명칭을 사용한다.

  • 사람을 위한 프로그램을 작성한다.

  • 최적의 자료구조를 사용한다.

  • 코드를 완성하기 전에 주석을 작성한다.

  • 코딩을 시작하기 전에 문서화한다.

  • code 검토를 실시한다.

  • 너무 깊이 중첩시키지 않는다.


시험원칙

  • 시험에서 요구사항을 추척한다.

  • 시험하기 훨씬 이전에 시험을 계획한다.

  • 자신이 개발한 소프트웨어는 자신이 시험하지 않는다.

  • 블랙박스 시험과 화이트박스 시험을 실시한다.

  • 항상 스트레스 시험을 한다.

  • 단위시험이 끝나기 전에 통합하지 않는다.

  • 소프트웨어에 특정한 시험용 코드를 내장시킨다.


관리원칙

  • 뛰어난 관리는 뛰어난 기술보다 중요하다.

  • 고객의 우선순위를 알아야한다.

  • 많은 사람보다는 소수정예요원이 낫다.

  • 항상 기대치를 높이 가진다.

  • 능숙한 의사소통 기술은 필수적이다.

  • 인력과 시간은 대체할 수 없다.

  • 소프트웨어 개발자의 능력차이는 크다.

  • 불가능한 것은 피한다.

  • 적절한 프로세스 모델을 사용한다.

  • 직면한 위험을 이해한다.

  • 방법론이 당신을 구제해 주지는 못한다.


제품보증 원칙

  • 형상관리 절차를 조기에 확립한다.

  • 모든 중간산출물에 명칭과 버전 번호를 부여한다.

  • 기준선을 통제한다.

  • 모든 것을 보존한다.

  • 변경관리를 해야 한다.


진화원칙

  • 소프트웨어는 계속 변화한다.

  • 증상이 아닌 근본적인 문제를 수정한다.

  • 최악의 구성요소는 처음부터 다시 개발한다.

  • 변경한 후에는 반드시 회귀시험을 실시한다.

  • 비구조적인 코드는 구조화해도 개선되지 않는다.


이상입니다~

2006년 6월 11일 일요일

Flickr Pro

flickr_pro

지난 5월 31일 Flickr Pro 유료 계정을 구입했습니다.

놀라운 거금 24.95$을 썼습니다. ^^;
웹서비스를 돈을 주고 사용하게 된 것은 이번이 두번째입니다. 지금은 사라졌지만 스트리밍 뮤직 서비스를 유료로 사용했던 적이 있습니다. 이 회사(neoviz)는 너무 빨리 서비스를 시작했고 서비스가 궤도에 오르기 전에 성급히 유료화를 시도하는 바람에 문을 닫은 듯 보입니다.

하여간 결국 돈을 쓰게 만드는 Flickr의 사진 앨범 서비스는 정말 강력합니다. 그 동안 많은 온라인 사진 앨범 서비스가 있었지만 용량의 제한, 웹에서만의 업로드 방식, 폐쇄적인 구조 등으로 그다지 큰 환영을 받지 못해습니다.

Flickr는 Open API를 제공하여 자신의 블로그에 앨범을 추가할 수 있고 사진 앨범 관리 소프트웨어인 iPhotoPicasa에서도 손 쉽게 사진을 업로드할 수 있습니다.

무엇보다도 Flickr는 열린 Community를 지향하여 가능하여 회원 뿐만 아니라 누구와도 사진을 공유할 수 있도록 하고 있습니다. 게다가 원본 크기 이외에도 여러 크기로 사진을 제공하고 있어서 자신의 홈페이지나 블로그에 연결하기 좋습니다.

안타까운 것은 아직 한글 서비스가 안된다는 부분과 인화나 DVD로 구워주는 서비스는 국내에서 안되는 부분입니다. 야후에서 flickr을 인수하였으니 언젠가 국내에서 지역화된 flickr서비스를 맛볼 수 있을 것 입니다.
하여간 인터넷이 발전한 우리나라에 이런 사진 앨범 서비스가 없다는 것이 아쉽습니다. 특정 서비스 보다 포털을 지향하다 보니 이런 서비스가 발전하기 힘들고 자기들만의 닫힌 공간을 지향하다 보니 다른 웹서비스나 애플리케이션과 연동하는 부분이 약하기 때문에 발전의 폭도 적었던 것 같습니다.

이외에도 zooomr와 같은 사진 앨범 서비스도 있습니다. flickr와 비슷한데, Google Maps과 연동하여 사진 찍은 위치를 표시할 수 있습니다.

2006년 6월 9일 금요일

단순함의 미학

Google의 검색 페이지와 Apple의 iPod의 공통점과 성공요인은 무엇일까요?

그것은 단순함에 있습니다.

google.png

처음 구글 검색 페이지를 봤을 때, "도대체 이 회사는 광고도 없이 무엇을 먹고 사나" 이런 생각이 들었습니다. 하지만 그들은 모두가 포털을 추구할 때, 검색 엔진의 성능에만 집중함으로써 많은 사용자를 끌어들일 수 있었습니다. 그리고 검색 입력창만 있는 단순한 구성을 통해 사용자게는 편리함과 기술력에 대한 신뢰를 줄 수 있었습니다.

ipod-prod1.jpg

Apple의 iPod는 HW적 측면을 볼 때, 저장공간이 큰 것 빼고는 다소 부족해보입니다. 국내 MP3 Player에서 기본적으로 제공하는 녹음과 FM라디오 기능이 없습니다. 하지만 꼭 필요한 음악을 듣고 MP3 파일을 관리하는 기능은 아주 뛰어납니다. 특히 컨텐츠 관리 측면에서 보면 iTunes Music Store와 연동 기능과 넓은 화면 그리고 특유의 브라우징 휠의 편리함은 다른 MP3 플레이어가 넘어서기 힘든 부분입니다.

HW적으로 부족한 부분을 SW적으로 해결했다고 볼 수 있고 FM라디오, 녹음 기능은 악세서리를 이용하면 가능하기 때문에 꼭 그 기능이 필요한 사용자에게는 별 문제가 안됩니다. 게다가 Apple은 이와 같은 악세서리 판매로도 많은 수익을 창출하고 있습니다.

꼭 필요한 기능만으로 사용자가 원하는 핵심에 다가서는 단순함과 집중성!
Apple과 Google의 성공 비결인 듯 싶습니다.