2014의 게시물 표시

머리를 써라..

이미지
  열심히만 하지말고 머리를 써서해라 -_-;;; 열심히 하는넘보다 잘하는넘이 더 좋다 난...

훌륭한 프로그래머의 딜레마...

이미지
훌륭한 프로그래머는 가난하다. 그가 가난을 벗어나려면 그 "훌륭함"부터 벗어나야 한다. -------------------------------------------------------------------------------- "열심히"씨와 "훌륭한"씨는 각각 "엄청난소프트웨어회사"와 "허벌난소프트웨어회사"의 두 직원이다. 우연치 않게 두 회사에 정확히 똑같은 내용의 주문이 들어왔다. "열나어려운문제" 해결을 위한 프로그램을 작성해 달라는 것이었다. 열심히씨는 처음 예상 소요 시간인 3개월 동안 정말 열심히 일했다. 하지만 일을 하면서 예상 외의 장애를 직면했고, 밤샘 작업까지 해가면서 3개월의 마지막 날 매니져에게 이런 말을 할 수 있었다. "정말 열나게 프로그램을 짰슴다. 밤샘도 하고요. 제가 지금까지 작성한 프로그램은 2000줄입니다. 그런데, 새로운 문제가 기술적으로 불가피하게 발생했습니다. 복잡한 버그(프로그램의 오류)도 몇 가지 해결해야 하고요. 한 달 가량이 더 필요합니다." 그러고 한달 후 열심히씨는 몇 개의 버그와 더불어 나름대로 작동하는 프로그램을 매니져와 고객에게 자랑스럽게 보여줄 수 있었다. 벌겋게 충혈된 눈과 미쳐 깎지 못한 수염, 무지무지 어렵고 복잡해 보이는 2500여 줄의 프로그램과 함께. "예상보다 훨씬 더 복잡한 문제였군요. 정말 수고하셨습니다."라는 칭찬을 들으면서. 훌륭한씨는 매니져가 "의무적으로" 잡아놓은 예상 소요 시간 3개월의 첫 2달 반을 빈둥거리며 지냈다. 매니져는 훌륭한씨가 월말이 되어서 "정말 죄송해요. 아직 한 줄도 못짰어요. 너무 어려워요. 좀 봐주세요."라고 처량하게 자비를 구할 날을 손꼽아 기다렸다. 웬걸, 마지막 날 훌륭한씨는 예의 "너무도 태연스러운" 모습으로 나타났다. 150여 줄의...

Net Framework, 정말 알고 있습니까?

이미지
이철 silent1002@naver.com|유익함을 주는 모든 기술과 경험에 관심을 가지고 있으며, 특히 닷넷 기술에 묻어있는 철학에 많은 관심을 가지고 있다. 기술 공유하는 것을 좋아하며, 다수의 크고 작은 닷넷, 비주얼 C# 관련 세미나를 진행한 경험이 있다. 현재 마이크로소프트 비주얼 C# MVP, 삼성 소프트웨어 멤버십, 데브피아 C# 포럼에서 활동하고 있으며, 최근에는 평생의 반려자를 만나 인생의 또 다른 행복을 알아가는 중이다. WinFX라고 불리는 3.0 이후 버전부터 WPF, WCF등 막강한 주요 기술들의 등장으로 시작해 4.0으로 업데이트 되면서 패러렐 프로그래밍(Parallel Programming)요소를 비롯한 수많은 기능들이 추가되었고, 현시점에 닷넷 프레임워크를 이용하면 윈도우의 응용 레벨에서는 거의 모든 개발이 가능한 수준에 이르렀다. 하지만 정작 이를 접하는 사람들은 닷넷 프레임워크의 새로운 기술에는 열정적으로 목을 매면서도 닷넷 프레임워크 자체에 대해서는 많은 관심이 없다. 이런 안타까움에 필자는 지금까지 필자가 닷넷 프레임워크를 접하고 닷넷의 런타임에 대해 가졌던 의문과 그 의문을 풀어가는 과정을 이번 연재를 통해 공유하고자 한다. 필자가 프로그래밍이라는 단어를 처음 접했던 때는 대학교에 입학한 뒤였다. 대학에 입학하기 전까지는 단지 친구들과 컴퓨터 게임을 즐기거나 웹 서핑을 하는 컴맹에 가까운 컴퓨터 유저였다. 그렇게 대학에 입학해서 컴퓨터공학이라는 전공 타이틀을 달고 처음 접했던 언어는 C언어 였는데, 필자에게 C언어는 너무나 어려웠다. 알 수 없는 포인터와 더 이상 발전하지 않았던 콘솔기반의 개발은 필자를 지치게만 만들었다. 이후 접한 개발툴은 비주얼베이직(Visual Basic)이었다. 비주얼 베이직을 이용해 손쉽게 애플리케이션이 만들어지는 일련의 과정은 당시 C언어에 지쳐 있던 나에게 너무 신선한 충격이었다. 물론 그때 만들었던 애플리케이션들은 워낙 기본적인 것들이라 ‘손...

MFC 레지스트리 읽고 쓰기

2005년도인가 만들었던(짜집었던) 레지스트리 클래스입니다. 참 쉽죠잉~ /*---------------------------------------------------------------------  레지스트리로 부터 Int형 값을 읽어들이는 함수  ----------------------------------------------------------------------*/  static UINT RegReadInt( HKEY hKey,   LPCTSTR lpKey,   LPCTSTR lpValue,   INT nDefault )  {   HKEY key;   DWORD dwDisp;   UINT Result;   DWORD Size;   if( RegCreateKeyEx( hKey, lpKey, 0, NULL,    REG_OPTION_NON_VOLATILE, KEY_READ, NULL,    &key, &dwDisp ) != ERROR_SUCCESS )    return 0;   Size = sizeof( LONG );   if( RegQueryValueEx( key, lpValue, 0, NULL, (LPBYTE)&Result, &Size ) != ERROR_SUCCESS )    Result = nDefault;   RegCloseKey( key );   return Result;  } /*------------------------------------------------------------------...

c++ Pointer #2

이미지
이글은  2004.01.28 http://cafe.naver.com/headstudy.cafe  에 쓴 글을 다시 긁어 온것입니다. 사실 포인터라는게 처음에는 좀어려워 보입니다만.. 익숙해지면 포인터만큼 편한게 없습니다. 포인터를 막(?) 사용하는 저로서는 C#으로 코딩할때 포인터가 없다는게 좀 아쉽더군요(물론 비슷..한건 있습니다만..) 문자열은 포인터입니다. 위의 글을 보고 조금 의아해 하는 사람이 있을 것입니다. 하지만 이 말은 틀린 말이 아니며 또한 중요한 부분이기도 합니다. 지금부터 설명하는 내용을 차근차근 읽어 나간다면 모두 어렵지 않게 이해할 수 있으리라 생각해요. 그러면 지금부터 본격적으로 설명을 해 보도록 합시다 우싸. C의 문자열은 그 문자열의 시작 주소값을 나타내는 상수포인터의 표현입니다. 또한 C의 문자열은 문자열 끝에 문자열의 끝을 나타내는 특수문자 0을 넣어 관리됩니다. 0 은 제어 문자이므로, '\0' 처럼 표현하기도 해요. C에서 문자열의 끝에'\0'을 넣어 관리한다고 해서  '\0' 자체가 문자열에 포함되는 것은 아닙니다. 단지 문자열의 끝을 의미하는 표시로 사용될 뿐이죠. 다음과 같은 대입문에 대해서 생각을 해 voa요~   문자열은 그 문자열의 시작주소 값을 나타내는 상수포인터라고 하였으므로 pStr은 다음과 같이 선언되어야 할 것이다..   그렇다면 pStr에는 도대체 무슨 값이 들어가는가? 이쯤에서 '='(대입연산자) 의 연산순서에 대한 이야기를 먼저하죠. '='연산자의 실행순서는 연산자를 기준으로 오른쪽이 먼저 실행되고 그 다음 왼쪽이 실행됩니다. 즉 위의 pStr="Hello"; 는 오른쪽의 "Hello"; 가 실행되고 그 결과값을 pStr 에 대입합니다. 그렇다면 "Hello"; 가 실행된다는 의미는 무엇인가? 컴파일러는 문자열의 관리를 위해 미리 예약...

C++ Pointer #1

이미지
이글은  2004.01.28 http://cafe.naver.com/headstudy.cafe  에 쓴 글을 다시 긁어 온것입니다. 사실 포인터라는게 처음에는 좀어려워 보입니다만.. 익숙해지면 포인터만큼 편한게 없습니다. 포인터를 막(?) 사용하는 저로서는 C#으로 코딩할때 포인터가 없다는게 좀 아쉽더군요(물론 비슷..한건 있습니다만..) 포인터는 그 중요성을 아무리 강조해도 지나치지가 않습니다. C언어를 처음 공부하는 많은 사람들이 끝까지 공부를 마치지 못하고 중도에 포기하는 경우가 종종 발생하는데 그 이유 중에 바로 이 포인터를 제대로 이해하지 못한 경우가 대부분일거에요.. ^^;;; 1. 용어의 이해 우선 포인터를 이해하기 위해서는 주소(address)라는 용어를 이해해야 합니다. 주소는 메모리의 각각의 셀(cell)에 붙여진 일련번호를 말하는거죠. 디스크의 프로그램은 항상 메모리에 로드(load)된 다음, 실행(execute)됩니다. CPU가 메모리에 로드 되어있는 적절한 데이터를 - 이것이 변수이든, 실행 코드이든 - 가지고 와서 명령을 실행하기 위해서는 반드시 이 값(주소)을 참조해야 하죠.그러므로 메모리의 각각의 셀에는 일련 번호, 즉 주소가 붙여져 있으며, 우리가 선언하여 사용하는 변수 이름은 실제로 컴파일러에 의해 주소로 번역되는겁니다.   위의 그림은 간단한 메모리 구조입니다.. 안간단한가요?? ㅡ.ㅡ;; 위의 그림에서 메모리의 주소는 0~255 입니다. 현재 2 번지에는 100 이란 값이 들어있고, 254 번지에는 200 이 들어있죠. 여기서 여러분들은 100 이나 200 을 단순히 정수로 생각하면 안 된요. 왜냐하면 100 이나 200 은 해석하기에 따라서 정수나 실수 혹은 메모리의 주소가 될 수도 있기 때문이에요. 다음을 한번 보죠. 위의 문장은 프로그래머의 입장에서는 i 에 100 이 대입되는 것으로 생각할 수 있습니다...

팀 생산성 향상을 위한 패턴이야기

이미지
      데브피아 아키텍쳐 시삽 손영수 (아키텍트로 가는 길 - http:/www.arload.net )   팀 생산성 향상을 위한 패턴이야기 생산성 향상은 과연 개발자 개개인의 능력에만 달려있는 문제일까요 ? 생산성 높은 툴 , 언어 , 프레임워크를 이용하는 것 이상으로 , 팀플레이가 생산성에 미치는 영향력 역시 매우 큽니다 . 생산적이고 , 단결력 있는 팀을 만들기 위해선 어떻게 해야 할까요 ? 이 화두에 대한 전문가의 경험을 여러분과 함께 공유합니다 . 손영수 indigoguru@gmail.com | 데브피아 Architecture 시삽과 Microsoft MVP 로 활동 중이며 , 데브피아 소프트웨어 공학 스터디인 Eva 팀의 리더이다 . 부족한 실력이지만 지식을 나눌 때는 누구보다 ‘부자’라는 자부심을 가지고 지식 나눔에 힘쓰고 있다 . Pattern 전도사를 꿈꾸고 있으며 , PLoP 와 같은 Pattern 학회를 국내에 만들기 위해 힘 쏟고 있다 .    팀 생산성 향상은 개발자 뿐만 아니라 프로젝트 관리자에게도 관심 있는 부분일 겁니다 . 대부분의 패턴들은 소프트웨어 설계에 초점이 맞추어져 있습니다 . 그러나 독특하게 조직구조와 협력을 위한 패턴들 ( “Capable, Productive and Satisfied : Patterns for Productivity”) 이 PLOP 학회에서 발표 되었습니다 . 여기서 소개되는 패턴들과 필자의 부족한 경험과 지식을 엮어 팀 생산성 향상을 위한 패턴 이야기를 풀어보고자 합니다 . 첫 단추 잘 꿰기 (BOOTSTRAPPING) 시작부터 여러분에게 재미난 퀴즈를 내겠습니다 . “ 프로젝트가 시작될 때 , 가장 먼저 해야 되는 일은 무엇일까요 ?” 아마 대부분이 “ 팀 빌딩 ” 이라고 대답하셨을 겁니다 . 많은 프로젝트에서 ...