~~ Tales Of Kalstein ~~

POSIX 스레드 동기화쪽에 보면...Readers/Writer mutex 객체가 따로 존재한다. 그런데...이게 자체 제공되지않는 시스템도 존재한단 말이지. (현재 몸담고있는...DSP쪽이라던가.)

그래서...혼자서 생각해봤는데, 와...이거 참 쉽지않다. writer끼리의 경쟁은 mutex로 정한다고 치더라도, readers와 writer의 경쟁은 어떻게 방지할 것인가?

그래서 결국은 구글신께 문의.

결과는 http://doc.trolltech.com/qq/qq11-mutex.html 여기.

아주 심플하다. ^^ semaphore랑 mutex 2가지만 시스템에서 제공하면 얼마든지 구현이 가능!!

뭐...잡담에 가까운 글이지만...그래도 책 관련 내용이니까 도서 카테고리로 낙인!

앞부분만 약간 읽기 시작했는데...오호 이거 왠지 재밌을것 같다. 뭐 IBM의 OS/2의 실패 이야기는...소싯적 아버지 회사가 IBM인지라...OS/2를 써보면서 '아...이거 WIN32만 지원하면 좋을텐데. 윈도보다 잘 죽지도 않고 좋은데' 란 생각을 했던 나에게 추억거리를 곰씹을 기회를 줄 것 같기도 하고...

솔직히 우리나라에서 프로젝트 실패 이야기는 잘 떠돌지않는다. 완전히 회사가 망하지않고서는. 하지만 '성공'한 프로젝트들 속에 많은 프로젝트가 실질적으로는 실패한 프로젝트다. 한 예로...내가 예전 산업체 다닐때 마지막으로 했던 H사의 프로젝트는...유지보수의 난해함으로 인한 실패한 프로젝트로 봐야한다. 그러나...외부적으로는 성공적인 프로젝트로 광고하겠지. ㅎㅎㅎ

그때 문제는...다중 DB를 사용하는것이었다. 그것도 속도를 위한 memory db를 사용한 수준이 아닌...10개였나? 뭐 그정도였고...DB들의 sync는 개발자가 직접-_-제작한 XML을 이용해서 제작되어졌었지. 왜냐고? 글쎄. 처음부터 아키텍쳐가 잘못 된것이고, 특히나 DB를 잘 만들어서 DB1개로 할 생각을 하지못했고 (역량이 딸려서.) 그리고 XML로 sync를 맞춘것은...TCP통신만 신뢰할줄 알았다고 해야되나. 여튼 그런식으로 하다보니...개발했던 인원이 어느정도 빠진 후에는 유지보수의 난해함으로 인해 계속 문제점은 발생하고...디버깅은 어렵고 ^^;;

나? 변명을  하자면...이미 아키텍쳐를 세운 다음에 투입되었고, 그것을 엎을만한 힘이 없었고...(계속 주장은 했었지만...) 뭐 여튼...그런 프로젝트를 했던 기억을 나게하는 책일듯 싶다. ㅎㅎㅎ

솔직히 현 회사에서도 기존에 소스를 만들었던 사람 한두사람이라도 없어지면 유지보수가 가능할지 의문인 부분이 많긴한데...하긴. 회사에 전적으로 묶인 사람들이 한둘이 아니니 괜찮으려나? (회사코앞의 집을 사고 - 집사는게 보통일이 아니니까. 돈이 넘치면 모를까 - 이만한 보수를 주는 회사가 국내엔 그렇게 많지않고. 플랫폼 잠금 이라던가 벤더 잠금..같은건 들어보긴했는데, 직장 잠금 이란말이 있나? 없으면 내가 쓰는게 최초가 될지도 하핫)

여튼 도서관에서 빌린 책이니...제시간내에 다 볼수있도록 열심히 읽어봐야겠다~

모 클럽의...시위 서포트 및 광고 모금에 동참했다.

큰 돈은 아녔지만...뭐 30만원이 한달 생활비인 나로써는 나름 큰 금액을...ㅎㅎ 여튼 중요한건 진심 아닌가!! 두둥!

주말에 방구석에서 시위 동영상만 보느라 계속 미안한 맘이었는데...이제 조금은 누그러진 느낌 ^^;

이책은...부제때문에 보게 되었다. - 개발자의 자기 게발과 경력 관리를 위한 52가지 실천 가이드 -

사실...제목은 영 안끌리지않나? ㅎㅎ 책표지도...뭔가 기존의 개발자를 위한 도서와는 영 딴판이라...처음에 도서관에 예약해놓고 받으러 갔을때 '어...이 책 맞아요?' '네 맞는데요.' 이런 상황이 -ㅁ-;;
그리고 사실...책 내용도, 부제에 가깝지, 실제 제목과는...좀 거리감이 있다.

각설하고, 경력 관리를 해야되는 개발자 뿐만 아니라, 취업을 준비하는 사람에게도 괜찮을것 같다. 자신의 스킬을 마케팅 하는 방법에 대해서 간략히 써놓고 있달까? 뭐 중요하게 느낀점 몇가지를 써보자면...

1. 역시 글쓰기는 중요하다. 언제나 간략한 정리를 하자. 멋진 포맷? 필요없다. 텍스트라고 해도 간단히 정리하자. 위키 정도의 문법이면 충분히 좋은 내용의 문서는 만들 수 있다.
2. 제자리에 서있지말자. 프로그래밍이던 영어던 그 외...뭐 자기 하고 싶은것이든. 필요하다고 생각되면 해보자. (블로깅이라도...^^) 노력하지않으면 당연히 퇴보된다.
3. 보여주기도 중요하다. 그러나 알맹이 없이 겉만 번지르르 한것은 언젠가 뒤통수를 치게 되어있다.
4. 자신을 마케팅하라. 이건 앞서말한것들이 합쳐져야 나타날 수 있다. 자신의 코드를 보여줘라. 공개하기 부끄럽다고? 부끄럽지 않도록 노력하면 되지~ 업무에 대해 다른 사람들과 부대껴라. 자신의 입지를 보여줄 수 있다면 그것만으로도 마케팅이 된다. 물론 쥐뿔도 없이 잘난척하면...뭐 마이너스.

대충 이정도?
글 중에 기억나는 부분은...'내 자리를 지키기 위해 난잡한 소스를 만들었다. 그러니까 내자리는 안전해. 짤릴 위험이 없지' 요런거? 농담반 진담 반이라지만...위험하다는거~~~ 얼핏 생각하면 맞는 말이니까 더욱 위험하다.

만약 관리자가 정말 난잡한 소스 유지보수 때문에 그 사람을 자르지않는다고 보자...솔직히...저런 사람들 치고 실력이 일취월장한 사람은 그다지 없다. (단지 유지보수때문에 안자른다면...) 그렇다면 관리자는 슬슬 저 사람을 대체할 만한 사람을 찾을 것이고, 찾는 순간 바로 잘린다. 잘리고 나면? 실력도 없는데 어쩌니? 낸들아나. 알아서 먹고 살아야지.

해결책은? 자신의 실력을 키우는것. 그리고 누구나 알기쉽도록 소스를 만드는것. 내자리를 지키는 주체가 자신의 실력이 되도록 하자는것이다. 그렇다면 회사에서 자르려고 하지도 않을것이고, 혹여 내가 회사가 맘에 안들어서 나가려고 할 때, 회사는 나를 붙잡을 껀덕지가 없다.

그 외에...저자는 글로벌 기업에 다니면서 인도에 파견되어서 일을 많이 한것 같은데...그런 경우에 현지인에 대한 마인드랄까 그런것에 대한 언급도 상당하다. 그래서인지...원제는 'My Jon went to India' 인데...왜 우리나라 제목은 저런거야? -.-;;; 뭐 여튼...그래도 읽어볼만한 책을 출판해준 Insight에게 감사 ^^