google도 가격비교 서비스가 있다!!

http://www.google.com/products

네이버의 바로 그 서비스를 구글이 따라서 하고 있었네요. ㅡㅡ;;

아마존에서 원서를 괜히 비싸게 주고 살뻔 했네요. ㅡㅡ;;

거기다가 계정이 있는 사람에게는 WishList도 주고 있습니다.

이러다가 구글이 쇼핑몰 하나 차리는 것은 아닌지??

 

이 글은 스프링노트에서 작성되었습니다.

협업 지수 측량

IT에서 개발자라는 존재는 너무나도 중요한 존재 입니다.

재료나 재화가 아닌 아이디어와 정보가 소모되는 특성을 가지기 때문에

사람에서 시작되고 사람에서 끝나는 것이 IT입니다.

 

이렇게 중요한 개발자의 능력을 측량할 방법이 너무나도 부족합니다.

자격증이란 것이 있지만 개발자의 전체 능력이 아닌 일부 능력(언어 표현력,알고리즘)만

평가하여 이 사람이 프로젝트를 수행하는 데 적합한 사람인가라는 의문에 부족한 답을

줄뿐입니다.

 

그 사람이 진짜로 일을 잘해 낼 수 있는 사람이냐?? 동료들과의 협업과 커뮤니케이션을 얼마나 해내느냐는

지금의 현실에서는 전적으로 면접관의 판단에 따를 수 밖에 없습니다. 이도 중요한 개발자의 스킬인데도 불구하고 말이지요.

 

그래서 많이들 회자하는 것이 국가단체에서 객관적인 개발자 면허를 만들어달라고들 합니다.

그러나 역사를 살펴보면 이런 일들은 국가에서 주도적으로 한 것이 아니라 민간에서 조합이 결성되어

그 단체가 강력한 영향력을 가지게 됨에 따라 그 단체의 일원이 되기 위한 시험에서 태동된 사례가 적지 않음을

우리는 볼 수 있습니다.(참고: 스티브 맥코넬 저 Professional Software Development)

 

먼저 개발자들이 깨어서 후배 개발자를 테스트하는 것을 만들면 어떨지요??

 테스트 과목은 다음과 같습니다.

• 알고리즘, 디자인 패턴 적용 능력
  
  - 완성도 높은 (유지보수가 용이하고 확장가능한 성능이 높은) 프로그램을 만들기 위한 필수 능력입니다.
  
   통상 코딩 테스트이겠지요.


• 프로그램 구현 능력/언어 표현
  
  - 언어에 대한 지식을 테스트 합니다. 알고리즘이나 디자인 패턴을 알고 있어도 실제로 구현하지 못한다면 무용지물이겠지요.


• 협업
  
  - 프로젝트에서 얼마나 기여도가 높은가??어떤 행동패턴인가??


• 커뮤니케이션
  
  - 문서를 얼마나 잘 이해하는가??애매한 요구 사항을 주었을 때 얼마나 올바르게 구현해 낼 수 있는가??


• 관리 능력


• 미래 성장가능성

이렇게 테스트 해보는 것이지요.

 

그러나 이 모든 것을 한번에 테스트 할 수 있는 방법은 MOCK 프로젝트 수행

즉,개발 환경(IDE,형상 관리 툴,DOC)만 있는 상태에서 요구사항만 던져주고 과제를 완수하라고 하였을 때

얼마만큼 실행 할 수 있는지 실제 테스트를 하는 것이지요. 팀에 평가관 한명 비슷한 경력의 피시험자 5~8명 정도로 하고

평가관이 누구인지는 모르게 합니다. 이렇게 해서 협업 커뮤니케이션 발전 가능성 프로그램 구현 능력/언어 표현 알고리즘,

디자인 패턴 적용 능력 테스트가 가능하게 됩니다. 그러나 이렇게 되면 모든 테스트를 평가관의 능력에 의지해야 하기 때문에

그 이전에 필답고사를 통한 테스트도 병행해야 합니다. 그리고 개발자는 연이어 응시가 불가능하고 3년마다 한번씩만 시험쳐야 합니다.

 

이 테스트가 미칠 영향력으로는

기존에 회사가 부담해야 했던 인재 측정의 일반적인 내용은 경감 시키고 각 회사의 고유 내용만 테스트하면

되기 때문에 그에따른 비용을 줄일 수 있으며 개발자의 능력에 맞게 일을 시킬수 있어서 잦은 야근 근무,낮은 개발 품질,

개발자에 의해 프로젝트가 공중분해 되는 일을 미연에 방지 할 수 있습니다.

개발자는 개발자 자신의 능력이 어느정도되는지 스스로 점검해 볼 수 있습니다.

 

또한 이것은 좋은 비즈니스 모델이 될 수 있으리라 봅니다.

개발자를 인증해주는 일반적인 모델이 국내에서는 없었기 때문에

이 사업을 하고 이것이 민간표준으로 인정만 받는다면

거두어들일 수익은 막대하겠지요.

 

참고 : 송치형의 InnoLab

자바 초창기 때 나왔었던 기술 JINI

이 글은 스프링노트에서 작성되었습니다.

자바 초창기 때 나왔었던 기술 JINI

JINI가 무엇에 쓰는 물건인고?? http://www.javastudy.co.kr/docs/lec_j2me/jini/jini.htm

JINI의 근황 http://incubator.apache.org/river/RIVER/downloads.html

 

자바가 막 태동 했던 90년대 후반에 나온 낡고 낡은 기술이지요.

고딩 때 컴터 잡지에 나와 있어 자바의 자도 모르면서 코를 박고 읽었던 기억이 있습니다.

JINI는 Java Intelligent Network Infra-structure 라는 긴 이름의 이니셜이었습니다.

 

말 그대로 어떤 디바이스가 알아서 주위의 다른 JINI가 탑재된 다른

디바이스들과 통신하여 정보를 주고 받는다는 개념이지요.

요새 유비쿼터스로 이름만 바뀌었다 뿐이지 그 당시로서는 획기적인 기술이 었습니다.

이때 나왔던 개념이 분산 컴퓨팅 개념이었던 것으로 기억합니다. 시대를 많이 앞서 나간 기술이지요.

 

오래전 스쳐지나간 옛 애인 생각 나듯이 JINI가 생각나 한번 끄적여 봅니다.

근데 왠지 이 기술이 뜰 거 같은 예감이 듭니다. 기술은 돌고 도는 거니깐요.

 

PS: 그 당시 썬에서 JVM을 하드웨어로 구현해서 JAVA OS를 만들 었다는 기사를 컴터 잡지에서 함께 읽었었죠.

이 글은 스프링노트에서 작성되었습니다.

우주 속의 망원경

 

 http://www.munhwa.com/news/view.html?no=20080930010728322440020

 

허블 우주 망원경이 고장 났다고 한다.

우주로 보내는 인공위성이나 우주선은 고장나면 유지보수 하는데 천문학적인 예산이 소요 되기 때문에

설계에 설계를 거듭하여 각 부품들이 강한 내구성과 높은 범용성과 성능으로 작동하고 있다.

 

가끔 코드의 잡탕 속에서 헤메다 보면 우주 속을 거니듯한 착각이 들 때가 있다.

여기 저기 버그들이 여기저기 초속 수 km로 날아다니며 그와 함께 내 생각도 움직이고 있다.

한 버그가 일으킨 오류가 잘 작동하던 우리의 허블 망원경(프로그램)을 망가뜨린다.

 

그러나 다른 점은 허블 망원경은 부품만 만들어 갈아끼우면 제대로 작동하지만

프로그램은 어딘지 변수가 많다.. 내가 그런 프로그램만 접해서 그런가 보다.

정말 객체지향은 연구가들의 머릿속에서만 작동되는 개념일까??

이 글은 스프링노트에서 작성되었습니다.