컴퓨터, 독서, 학습, 그리고 사람

언제부터인지 모르지만 평생 학습이란 말이 보편화되었습니다. 그만큼 이제 공부라는 것은 학창시절로 끝이 아니라, 사회생활을 하면서도 지속되어야 하는 것이 되어 버린 것이죠.. 오죽하면 일과 공부를 병행하는 셀러던트라는 신조어가 나오기도 했습니다. 지난번 포스팅인 변화해야 산다. 에서 이야기 했듯이 프로그래밍 분야에서도 끊임없는 자기개발이 중요한 요소인 것이 사실입니다. 그렇다면, 프로그래머들은 어떻게 평생 학습을 해 나가야 할까요? 1. 꾸준히 해야 한다. 일반 수험생들에게 항상 하는 이야기이지만, 벼락치기는 전혀 도움이 안됩니다. 프로그래밍과 같은 분야에서도 마찬가지입니다. 지금 하는 공부는 당장 필요할 수도 있지만, 향후 몇년 후에 더 가치가 있을 수도 있는 겁니다. 꾸준히 그리고 천천히 계획을 가지고..

개인적으로 올 초에 Ruby on Rails를 좀 살펴봤었습니다. 10년 전에 만들어진 Ruby라는 언어와.. 일종의 프레임워크를 적용하여 웹 어플리케이션을 개발할 수 있는 환경을 제공하는 Rails라는 것이었는데요... 물론 실전에서는 한번도 써보지 못하고.. 걍 예제 프로그램 정도만 만들어 봤었죠~ 요즘은 Groovy라는 언어와 Grails라는 것을 보고 있습니다. 자바와 같은 바이트 코드를 만들어 주는 스크립트 언어인 Groovy에.. rails와 비슷한 MVC 환경을 만들어 주는 Grails가 있다고 하더군요.. 아무래도 자바 환경에서 동작하므로 ruby on rails 보다는 쓰임새가 많을 것 같아.. 살펴보고 있습니다. 오늘 이런 이야기로 시작하는 이유는.. 제 개인적인 욕심 때문입니다. -...

실용주의 프로그래머 책에 다음과 같은 이야기가 나옵니다. 요구사항이 지면에 놓여져 있는 경우는 퍽 드물다. 보통은 가정과 오해, 정치의 지층들 속 깊이 묻혀 있다. 프로젝트를 진행하면서 가장 어려운 부분이 요구분석단계라고 생각합니다. 열심히 분석하고 반영해도.. 프로젝트 진행 중에 결국 수정이 발생하는 부분이기도 하구요.. 발생한 수정에 대해 누구의 탓도 할 수 없게되는~~ 그래서 실제로 그 프로그램을 사용할 사람들과 함께 일하면서 사용자 처럼 생각해 보는 것이 도움이 된다고 이야기를 하기도 합니다. 고객과의 의사소통이 중요한 것은 다음 그림에서도 잘 표현되어 있는 것 같습니다. 예전에 데브피아에서 가져온 것인데.. 정확한 출처는 모르겠네요.. -.- 그리고 미친병아리님이 올린 다음 글도 참고해보세요~~..

얼마전 IT 개발자의 야근에 대한 글이 블로고스피어에 많이 나온 적이 있었습니다. 저도 IT 개발자들의 야근~~ 이라는 제목으로 포스트를 하나 올렸었는데요.. 오늘은 프로젝트 관리에 있어서 야근, 즉 초과근무를 어떻게 바라봐야 할 것인지에 대해서 간단히 이야기하려고 합니다. 먼저 야근을 왜 하게 될까? 하고 생각해 봤습니다~~ 첫째는 본인 스스로 눈치를 보면서 하지 않을까 합니다. 모두 야근하는데.. 나만 먼저 가면 찍히니까.. 둘째는 관리자의 압력에 의해서.. 즉, "이것 오늘까지 끝내~~" 하는 무리한 작업요청이 있을 수 있죠.. 셋째는 정말로 할일이 많아서... 딱히 할 말이 없는 경우죠. 하지만, 이런 경우는 프로젝트에서 한 두번 마감 직전에 있지 않을까 합니다. 그렇지 않다면 프로젝트의 일정관리..

요즘~ 필요하다고 생각하는 소스는 공개되어 있는 것도 많고 또.. 컴포넌트 단위로 저렴하게 구입할 수 있는 것도 많습니다. 그러므로 모든 소스를 직접 구현하겠다는 생각은 굉장히 위험한 것이라고 생각합니다. 비록 프로그래밍 코딩에 자신도 있고, 알고리즘 구현도 잘 한다고 할지라도 이미 만들어진 것을 구현하는데 들어갈 노력을... 더 나은 사용자 환경 구축이나 최적화 등에 힘쓰는 것이 바람직 하다고 생각합니다. 더 나아가 본인 스스로나 팀 내부에서 작성한 소스들도 재사용이 가능하도록 정리하려는 노력이 필요합니다. 경우에 따라, 같은 프로젝트에 동일한 일을 하는 소스가 여러군데 존재하기도 하더라구요~ 그러한 경우를 막기 위해서 재사용하기 쉽게 만들어야 합니다. 팀 프로젝트에서 소스 코드의 중복이야말로 추후 문..

프로젝트의 규모가 점점 커지면서, 소스코드의 버전관리가 중요한 요소로 자리잡아 가고 있습니다. 혼자서 단독으로 프로그래밍을 하던 시기에는 백업 파일만 잘 보관하면 됐지.. 버전관리가 왜 필요할까? 하고 생각했던 것이 사실입니다. 하지만, 협업을 하게 되면서.. 단순히 백업만 가지고서는 발생할 수 있는 문제점들을 해결하는데 어려움이 있게 됩니다. 소스코드를 누가 변경한 것인가? 현재 소스와 이전 소스의 차이점은 무엇인가? 현재 소스를 릴리스(release)에 어떻게 반영할 것인가? 동시에 동일 파일에 대한 변경이 발생할 경우, 충돌을 어떻게 해결할 것인가? 단순한 백업에서는 해결하지 못했던 것을 소스코드 버전관리를 통해서 처리할 수 있게 되는 것입니다. 그래서 어떤 프로젝트를 막론하고.. 심지어 프로토타입..

실제로 프로젝트를 진행할 때, 프로토타입을 만든다는 이야기를 많이 합니다. 이런 프로토타입(prototype)의 사전적인 의미를 살펴보도록 하죠. prototype [출처 : 네이버영어사전] ━ n. 1 원형(原型)(archetype);견본, 전형;(후대 사물의) 선조, 원조(元祖) the prototype of a character (소설에서) 인물의 원형 2【생물】 원형(原形) ━ vt. …의 원형[견본]을 만들다 원형이나 견본이라는 의미로 주로 사용되고 있는데요.. 프로그래밍에서는 언제 프로토타입(원형, 견본)을 만들어야 할까요? 당연히 이미 해봤던 것이나, 전체적인 로직과 흐름을 잘 알고 있으며, 구현이 가능한 것에 대해서는 프로토타입이 필요 없을 것입니다. 처음 시도해 보는, 이 기능이 구현될지..

상품디자이너인 데이비드 켈리는 “성공과 실패는 동등하게 보상받을 가치가 있다. 하지만 아무 것도 하지 않는 다면 벌을 줘야 한다” 고 이야기 했습니다. 실제 프로젝트를 진행할 때 일입니다. 모 프로그램에 플러그인을 개발해야 할 필요가 있었는데.. 처음에 AJAX (DWR) 을 이용해서 처리했습니다. 하지만, 원격에서 호출이 안되자. dwr 문제일까? 하고 prototype으로 바꾸어서 테스트 해 보았지만, 역시 문제가 발생했습니다. Javascript는 보안상의 이유로 cross-domain을 지원하지 않기 때문이었습니다. 그래서 이런 경우에 사용할 수 있는 이기종간의 통신을 위한 웹서비스를 사용하자고 제안했습니다. 웹서비스를 이용하여 프로그램을 구성하고 테스트를 마치고 보니.. 이런 웹서비스 내에서 우..

깨진 창문 이론(Broken Window Theory)이라는 말이 있습니다. '티핑 포인트'라는 책과 '실용주의 프로그래머'라는 책에서 인용되고 있는데요.. 요약하면, 오랜기간 수리하지 않고 방치된 창문 하나가 거주자들에게 버려진 느낌을 준다는 겁니다. 그래서 다른 창문이 하나 더 깨지고.. 낙서가 등장하고.. 심각한 구조적 손상이 시작되는 것이죠.. 결국 건물 소유주가 고치려는 의지를 넘어설 정도로 건물이 손상되고, 버려진 느낌은 현실이 되어 버린다는 겁니다. 보다 자세한 내용은 다음 블로그들을 참고하시기 바랍니다. http://www.nanael.net/48 http://blog.naver.com/chowyf?Redirect=Log&logNo=80034681435 '실용주의 프로그래머' 책에서는 실생..