내 일상의 잡설

간만에 한시간 넘게 아무 생각 없이 인터넷의 블로그들을 탐방해 봤다
재밌다 ㅋㅋ
우찌 모든 사람들은 말도 그렇게 재미나게 잘 할까 ㅋㅋ
알지도 못하는 사람의 관심도 없는 분야의 글을 읽으면서도 재미가 느껴지다니...

사실 지금 이, 나의 블르그는 단순히 정말이지 개인적인 공간으로밖에 생각하지 않아 왔다
누가 볼것 같지도 않고 누가 봐주기도 바라지도 않는다
단지, 그때 그때 기록하고 싶은 몇 가지들을 기록하여
미래에 추억으로 되새길 수 있는 공간으로 생각해 왔다. 물론 지금도....

대충 블로그 들을 훓어 보니 사람들의 블로깅 성향이 몇 가지로 나누어 지는 것 같다

1. 그냥, 자기자신에게 말 하듯이 하는 사람
2. 개인 블로그라기 보다는 누군가에게 들려 주듯이 말하는 사람
3. 여기저기서 막 퍼오기만 하는 사람

다 재밌다 .ㅋㅋ
개인적으로는 1번 성향의 사람의 블로그기 제일 재미있는 것 같다

3번은 말할 것도 없이 큰 재미를 느낄 수 가 없고,
그리고 2번 성향의 블로그는 개인 블로그라기 보다는 공용 커뮤니티 같은 성격을 띄고 있어서
단어가 적당히 정제되어 있고 여러 부분에서 공식성(?)을 띄고 있는 경우가 많아 자신만의 개성이
묻어 나질 않아서 1번보다 재미는 없다...

물론 순전히 개인적인 재미가 기준이다

반면 내 블로그는 머지???
대체로 1번에 가깝긴 하나 재미있지는 않다 ㅋㅋ

오늘 재미있는 블로그를 발견했다
http://blog.daum.net/effortless
우연히 알게 되었는데  상당히 흥미로운 블로그이다

이 블로그에 올라온 아래의 글은 대표적으로 흥미로운 글이다
http://blog.daum.net/effortless/1077624
http://blog.daum.net/effortless/695361

대부분의 프로젝트는 개발자의 자질과 상당히 강한 의존성을 가지고 있다.
 
프로젝트는 초기 구축할 명확한 목표와 구축방법 및 적절한 용도를 위해 탄생한다.
이러한 프로젝트의 고유한 성격을 미리 계획하고 이에 적합한 개발자를 투입하는 것을 원칙으로 한다.
 
그러나 대부분의 프로젝트는 초기 목적과는 달리 개발자의 기술역량과 같은 자질에 구현 방법이
바뀌거나  우회하는 경우가 다반사이다.

이것은 단순한 기능적 요소 뿐만 아니라 비 기능적 요소의 변경도 초래하게 된다.
예를 들어, A 라는 개발자는 프로젝트에 필요한 기능을 구현하기 위한 자질이 충분하지 못할 경우
다음과 같은 오류를 범하기 쉽다.
 
1. 유사하게 기능은 구현하되 버그 발생률이 상당히 내재되어 있다.
    어찌어찌 하여 해당 기능을 꾸역꾸역 구현은 했고 한 두번의 테스트를 해 본 결과 잘 돌아가는 듯 하다.
    그러나 개인이 몇 번 테스트 할 때와 실제 환경에서 사용될 때는 그 환경이 확연히 달라 질 수있다.
    이에 대한 배려(?)를 하지 않으므로 결국 실제 환경에서는 버그 투성이의 기능이 되며
    결국 사용자는 해당 기능의 신뢰도가 완전히 사라져 쓸모없이 구색만 갖춘 기능이 되어 버린다.
  
2. 해당 기능과 유사한 기능으로 대체해 버리고 이를 클라이언트에게 설득한다
    해당 기능 보다는 유용하지 않지만 다른 방식으로 처리하도록 살짝 유도해 버린다.
    클라이언트는 '뭐 대충 돌아가지요' 하면서 받아 들이는 경우가 많다   
 
3. 기능요소를 뺄 수 있는지 (눈치껏) 확인 한 후 과감히 배제해 버린다
    자신이 사용하는 특정 언어에서 api 로 지원되지 않음을 확인 하고 구현이 불가능하다고 판단해 버린다.
    그리고 환경이 허락한다면 모르는 척 해당 기능을 배제해 버리거나, 최대한 늦추거나, 기술적으로
    구현하기 어려운 것이라 말해 버린다
 
 
물론, 제대로 관리되고 진행되는 프로세스 상의 프로젝트는 이러한 오류를 범하지 않을 것이다.
그러나 실제 현업에서는 이와 유사한 경우가 허다하다고 보여진다.
 
개발자는 자기 코드에 자존심을 걸어야 한다.
대충 API 에서 제공하는 것 이외에는 구현할 수 없다로 일관한다면 더 이상 개발자라 할 수 없다.
그냥 API User 일 뿐이다.
 
물론 방대한 API 를 잘 알고 적절히 선택할 수 있고 유용하게 응용할 수 있는 능력은 아주 중요하다.
중요한 것은 '그리고' 가 있어야 한다.
API 에 대한 지식과 응용력 그리고 창조적 개발이 그것이다
 
 
개발자의 자질때문에 프로젝트가 좌지우지 될게 아니라 프로젝트의 목적에 맞는 개발자를
투입하거나 필요한 교육을 통해 적합하도록 유도해야 할 것이다

개선의 3단계
 
인식(인지) -> 교육 -> 체화(습관화)
 
우선, 무엇이 필요한지 인지하고
어떻게 갖출것이지 찾아보고 공부하고
완전히 내것으로 만드는 과정이 완료되어야 비로써 개선이 되는 것이다.
 
가장 문제가 있는 인간은 도대체 현재 나에게 뭣이 필요한지 인지도 못하는 사람이며,
의지가 나름 있는 사람도 대부분 교육의 단계에서 멈춘다.
 
교육의 단계까지 가서 만족스러운 정도의 교육을 마쳤다면
완전히 내것이 되도록 체화 시켜야 한다.
그렇지 않으면 힘들게 교육만 마친 것이 너무나도 아까울 것이다.
체화 시키지 않는다면 시간이 흐를 수록 하지 않은 것과 별반 다를 것이 없게 된다.
 
필요한 것을 찾아보고 공부하고 배우고 이해 했으면, 완전한 내것으로 만들기 위한 극도의 반복활동을
통한 체화를 실현하자 ....
이것은 공부 뿐만 아니라 일상의 습관 만들기에도 같은 원리로 적용될 것이다.

Wingding 이라는 글꼴이 있음을 오늘에야 알았다.
그리고 노트패드의 911 예언도 이제서야 알았다.ㅋㅋ
 
911 테러당시 쌍둥이 빌딩을 들이받은 비행기의 번호는
 
Q33N 을 윙딩으로 변환하면...

신기신기...
 
 
굉장한 윙딩...
아래 그림은 윙딩 글꼴 매핑표이다.
 

"코딩만 할 수 있는 사람은 개발자라고 할 수 없다. 그런 사람에게 많은 연봉을 줄
사람은 그 어디에도 없다"
 
1. 끊임없는 공부하고 변화에 대비하라
    '개발자는 공부와 변화를 두려워하지 말아야 한다'
    첨단 기술을 다루는 개발자에게 새로운 기술을 기피하고 학습을 게을리 하는 일은 자신을
    퇴보시키는 일이다.
 
2. 기본기를 갖춰라
    기본과 기초는 분명히 다르다.
    야구선수나 축구선수, 농구 선수 등은 모두 다른 운동을 하지만 모든 운동선수는 달리기부터 시작한다.
    또 발이 빠른 선수는 종목을 바꾸더라도 쉽게 적응하기도 한다.
    운동에서는 하체의 힘과 달리기가 중요한 기본요소로 작용하는 것처럼 개발에 있어서도
    기본을 갖춘 개발자와 그렇지 않은 개발자의 성장 속도는 다를 수밖에 없다.
 
3. 지식의 포트폴리오를 유지하라
    '계란은 한바구니에 담지 말라'
    주식 투자에서도 안정적인 주식과 수익률이 높은 주식에 분산투자를 하듯이 자신이 주력으로 사용하는
    기술은 더욱 깊에 파고들면서, 넓은 지식을 갖출 필요가 있다
 
4. 개발을 즐기라
    개발은 그 어떤 직업보다 많이 공부해야 하고 깊게 생각해야 하며, 많은 체력 소모를 필요로 하는 직업이다.
    이런 직업인만큼 개발 자체를 즐기지 못한다면 그는 행복한 개발자가 될 수 없다.
 
흔히 개발자는 일당 잡부에 비교하곤 한다.
하지만 10년 전 일당 잡부였다가 오늘도 일당 잡부인 사람이 있는가 하면, 오늘은 공사반장이 되어 있는
사람이나 건설회사 사장이 되어 있는 사람도 있다.
개발자도 자신의 노력여하에 따라 10년 후의 모습이 지금처럼 암울할지, 아니면 자신의 손으로 만들어진
프로그램이 세상을 변화시키고 있을지가 판가름 나게 될 것이다.
 
- 마이크로소프트웨어 김명호 박사 기고글 중에서 -