블로그 이미지
Every unexpected event is a path to learning for you. blueasa

카테고리

분류 전체보기 (2794)
Unity3D (852)
Programming (478)
Server (33)
Unreal (4)
Gamebryo (56)
Tip & Tech (185)
협업 (11)
3DS Max (3)
Game (12)
Utility (68)
Etc (98)
Link (32)
Portfolio (19)
Subject (90)
iOS,OSX (55)
Android (14)
Linux (5)
잉여 프로젝트 (2)
게임이야기 (3)
Memories (20)
Interest (38)
Thinking (38)
한글 (30)
PaperCraft (5)
Animation (408)
Wallpaper (2)
재테크 (18)
Exercise (3)
나만의 맛집 (3)
냥이 (10)
육아 (16)
Total
Today
Yesterday

UniPython

Unity3D/Plugins / 2013. 10. 6. 20:25


Link : http://forum.unity3d.com/threads/190418-UniPython-Python-Scripting-in-Unity3D-based-games

반응형

'Unity3D > Plugins' 카테고리의 다른 글

Mobile Movie Texture  (0) 2013.12.03
원격 로그 플러그인  (0) 2013.11.20
IronPython  (0) 2013.10.06
iOS 플러그인 제작  (0) 2013.09.15
Prefactory: Free PoolManager / PoolObject System  (0) 2013.08.28
Posted by blueasa
, |

Sorting

Programming/C# / 2013. 10. 2. 17:46


링크 : http://support.microsoft.com/kb/320727/ko

링크 : http://www.codeproject.com/Articles/42839/Sorting-Lists-using-IComparable-and-IComparer-Inte

링크 : http://www.dotnetperls.com/sort-string-array

반응형
Posted by blueasa
, |








출처 : 진격의 거인 20화 중..

반응형
Posted by blueasa
, |

프로그래머 죽이기

Thinking / 2013. 9. 26. 00:03

출처 : http://www.mrlatte.net/2013/09/blog-post.html



어떤 글이 사람들에게 주목을 받기 위해서는 제목이 중요하다. 하지만 너무 자극적인 제목을 사용하면 처음에는 사람들의 관심을 받을 수 있겠지만, 내용이 기대에 못 미친다면 아마 끝까지 읽게 하기는 힘들 것이다. 그렇다고 너무 뻔하고 무난한 제목을 선택한다면 관심조차 받지 못할 것이다. 이처럼 제목의 선정이란 참으로 고민되는 일이다. 짧은 블로그 게시물은 물론이고 많은 노력이 들어간 책의 긴 글의 경우는 더욱 그러하리라 생각한다. 

최근 피플웨어(Peopleware)[1]라는 책을 읽었다. 나는 이 책을 읽는 내내 소프트웨어 분야에 종사하는 관리자라면 꼭 읽었으면 좋겠다는 생각이 들 정도로 이 책은 소프트웨어 분야의 명서로 꼽을만하다. 나는 이 책을 읽고 어떻게 하면 소프트웨어 개발자로서 일을 잘할 수 있는지에 대해 글을 써보기로 결심했다. 하지만 제목은 여전히 고민스러운 문제였다. 그런데 이 책의 한 단락에서 아이디어를 얻을 수 있었다. 피플웨어는 내용도 좋지만, 단락의 제목을 짓는 기술이 특히 인상적이다. 수학적 증명 방법에 비교하면 아마 귀납법[2]보다는 간접 증명법[3]에 가까울 것이다. 여기서 아이디어를 얻어서 본 글의 제목을 간접증명법의 "프로그래머 죽이기"로 하기로 결심했다.



내가 생각하는 프로그래머를 죽이는 방법은 3가지인데 다음과 같다. “짜장과 짬뽕 모두 좋아하는 관리자", “제임스 본드(James Bond)[4] 관리자", “스티븐 잡스(Steven Jobs)[5] 프로그래머"이다. 세 가지 항목 모두 비유를 통해서 의도하는 바를 더 효과적으로 설명하려고 한다.

프로그래머를 죽이는 방법의 첫 번째는 "짜장과 짬뽕 모두를 좋아하는 관리자"가 필요하다는 것이다. 이 관리자는 마치 중국집에서 짜장을 먹을까? 짬뽕을 먹을까? 고민하다가 결정하지 못하고 안절부절못하여 결정이 늦거나 짜장면을 시킨 후에 짬뽕을 먹을 걸 하면서 계속 후회하곤 한다. 실제 업무에서 의사 결정을 할 때도 마찬가지이다. 구글의 래리 페이지(Larry Page)[6]는 빠르고 좋은 결정은 있지만, 느리고 좋은 결정은 없다고 했다. 이런 유형의 관리자는 빠른 결정을 못 함은 물론이고 프로젝트 결정을 진행하고 있는 도중 프로젝트에 대한 성공 여부를 확신하지 못하여 그 프로젝트를 적극적으로 지원해 주지도, 프로젝트 팀원에게 비전도 제시하지도 못함으로써 결국 프로젝트와 참여한 프로그래머들을 망치게 된다.

다음으로 프로그래머를 죽이기 위해서 “제임스 본드 관리자"가 있어야 한다. 007[7] 영화에서 보듯이 제임스 본드는 비밀 작전을 수행하는 요원이다. 그에게 내려진 지령은 엄격한 비밀에 부쳐지고 몇 초 내에 파괴되기도 한다. 실제 프로젝트에서도 마치 자신이 007 요원이나 된 듯이 프로젝트에 대한 정보를 공유하지 않고 비밀로 하는 관리자가 있다. 때로는 어떤 정보는 프로젝트 팀원에게 좋지 않은 영향을 미치는 정보일 수 있다. 하지만 그렇다 하더라도 프로젝트에 관한 모든 정보는 공유돼야 한다. 프로젝트 팀원들은 공유된 정보를 바탕으로 때로는 의욕적으로 또 때로는 위기 상황을 같이 해결하는 단결력과 협동심의 팀워크를 발휘함으로써 프로젝트를 성공적으로 이끌 수 있기 때문이다.

마지막으로 “스티븐 잡스 프로그래머"가 프로젝트 팀에 존재해야 한다. 위 제시한 두 가지 사항은  관리자가 프로그래머를 죽이는 원인이었다면 이 항목은 프로그래머 자신의 문제이다. 스티븐 잡스 같은 프로그래머라니? 스티븐 잡스가 얼마나 성공적으로 애플(Apple)을 이끌었는지, 얼마나 혁신적인 사람이었는지 몰라서 하는 말이 아닐까? 라고 생각할지 모르겠다. 하지만 이것은 스티븐 잡스의 업적을 두고 하는 말은 아니다. 바로 그처럼 일 중독에 걸린 것처럼 일하는 프로그래머를 두고 하는 말이다. 스티븐 잡스는 업무 적으로는 큰 성공을 거뒀지만, 가정과 개인의 삶에는 상대적으로 소홀할 수밖에 없었을 것이다. 비슷한 내용을 다룬 영화 "클릭"[8][9]이 있으니 아직 못 보신 분들이 있다면 보기를 추천한다.

프로젝트 팀에 일 중독의 프로그래머가 많다면 프로젝트는 성공할 수 있을지는 몰라도 결국 프로젝트가 끝나면 프로그래머가 모두 떠나거나 떠나지 않더라도 정신적으로 큰 상처를 받은 상태가 지속될 것이다. 이에 따르는 비용을 계산하면 결국 프로젝트는 실패한 것으로 판단할 수 밖에 없다.

프로그래머는 창의적인 직업이다. 그들은 공학적으로 시스템을 만들고 있지만, 창의적인 아이디어도 역시 필요한 직업이다. 같은 맥락으로 심지어 최근 프로그래머들의 소양 중에 인문학도 포함되고 있지 않은가? 창의적인 아이디어는 매일 몰아치는 업무 속에서는 나올 수 없다. 창의력은 충분한 휴식에서 나온다는 벤자민 베어드(Benjamin Baird)의 연구 결과도 이미 알려진 바 있다. 우리는 구글(Google)의 지메일(Gmail), 파이썬(Python), 최근 깃헙(Github)의 수많은 프로젝트들이 프로그래머들의 잉여 시간으로 탄생하였고 운영되고 있다는 사실에 주목해야 한다. 프로그래머들은 과도하게 업무를 수행하기 보다는 조금 느슨하게 그리고 여유 시간에는 현재 프로젝트의 심도 있는 고민과 새로운 프로젝트를 위한 재창조의 시간으로 보내야 한다.

우리나라 뿐만 아니라 소프트웨어의 선진국이라고 생각되는 미국에서 조차 회사의 조직을 정비하고 프로그래머들이 속해있는 각 조직과 프로젝트를 성공적으로 이끄는 것은 쉽지 않은 문제라는 것을 책 "피플웨어"를 통해 알 수 있었다. 그리고 이 책이 미국의 현실을 바탕으로 쓰여 있긴 하지만 우리나라의 현재 소프트웨어 기업들의 현실과 전혀 다르지 않다는 것도 놀랄만한 일이다.

나는 미국의 프로그래머는 연봉이 10만 달러가 넘는다는 기사를 보고 부러워했던 적도 있다. 하지만 실상 막대한 세금과 기본 생활비를 제외하고 나면 실제 쓸 수 있는 것은 우리나라보다 적을 수도 있다는 사실은 상대적으로 열악한 환경에 있는 우리에게 매우 고무적인 사실로 들린다. 

내가 1999년 대학에 처음 입학했을 때 10년 후인 2009쯤 되면 소프트웨어 개발자들이 더 이상 할 일이 없을 만큼 소프트웨어 개발이 자동화 될 것으로 생각했었다. 하지만 지금 현실은 어떠한가? 아직도 대부분의 소프트웨어 개발을 프로그래머가 직접하고 있다. 오히려 1999년 보다 지금이 플랫폼이 다양화되고 스마트 기기가 확산됨으로써 프로그래머가 해야 하는  일들이 오히려 더 많아졌다.

소프트웨어 개발은 사람이 직접 수행하고 그 과정에서 사람과의 관계가 중요할 것은 앞으로 영화 터미네이터(The Terminator)[10]에서 등장했던 스카이넷(skynet)[11]이나 메트릭스(The Matrix)[12]처럼 스스로 코드를 생성해 낼 수 있는 뛰어난 인공지능 컴퓨터가 나오기 전까지는 계속될 것이라고 생각한다. 그리고 지금의 인공지능 발전 속도를 감안하면 아마 내 일생 동안 앞으로 70년 이상은 계속되리라 예상해본다. 결국 앞으로 꽤 오랜 시간 동안 소프트웨어 개발에 있어서는 사람과의 관계는 매우 중요한 요소로 자리 잡고 있을 것이며 이를 어떻게 잘 해결하는 지가 소프트웨어 프로젝트의 성공을 결정할 것이다.

프로그래머를 죽일 수 있는 방법은 본 글에서 제시한 것 외에 훨씬 더 많이 있을 것이다. 우리는 이러한 프로그래머를 죽이는 상황에 처했을 때 이것을 인지할 수 있는 능력을 길러야 한다. 인지할 수 있는 것과 전혀 인지하지 못하는 것은 매우 다르기 때문이다. 인지할 경우 바꿀 수 있는 기회는 아직 남아있다는 뜻이다. 프로그래머들은 지금 또는 앞으로의 상황들을 인지하고 바꾸고자 노력해야 한다. 마지막으로 "피플웨어"에 있는 내용을 하나 인용하면서 글을 마치고자 한다. 이러한 상황에 처했을 때 "우리는 회사를 바꾸거나 우리가 회사를 바꾸거나 둘 중에 하나는 꼭 해야 한다."



Reference


[1] (2012). Peopleware: Productive Projects and Teams (Second Edition): Tom ... Retrieved September 7, 2013, from http://www.amazon.com/Peopleware-Productive-Projects-Second-Edition/dp/0932633439.
[2] (2007). 수학적 귀납법 - 위키백과, 우리 모두의 백과사전. Retrieved September 7, 2013, from http://ko.wikipedia.org/wiki/%EC%88%98%ED%95%99%EC%A0%81_%EA%B7%80%EB%82%A9%EB%B2%95.
[3] (2009). 2장 증명. Retrieved September 7, 2013, from http://sungkyul.edu/~choiym/class/Fundamental_Mathematics_for_Multimedia/pdf/media_lecture2.pdf.
[4] (2006). 제임스 본드 - 위키백과, 우리 모두의 백과사전. Retrieved September 7, 2013, from http://ko.wikipedia.org/wiki/%EC%A0%9C%EC%9E%84%EC%8A%A4_%EB%B3%B8%EB%93%9C.
[5] (2005). 스티브 잡스 - 위키백과, 우리 모두의 백과사전. Retrieved September 7, 2013, from http://ko.wikipedia.org/wiki/%EC%8A%A4%ED%8B%B0%EB%B8%8C_%EC%9E%A1%EC%8A%A4.
[6] (2007). 래리 페이지 - 위키백과, 우리 모두의 백과사전. Retrieved September 7, 2013, from http://ko.wikipedia.org/wiki/%EB%9E%98%EB%A6%AC_%ED%8E%98%EC%9D%B4%EC%A7%80.
[7] The Official James Bond 007 Website | Home. Retrieved September 7, 2013, from http://www.007.com/.
[8] (2005). Click | Sony Pictures. Retrieved September 9, 2013, from http://www.sonypictures.com/movies/click/.
[9] (2011). 라떼군 이야기 (Mr.Latte Story): 영화 클릭(Click). Retrieved September 9, 2013, from http://www.mrlatte.net/2009/09/click.html.
[10] (2010). 터미네이터 (영화) - 위키백과, 우리 모두의 백과사전. Retrieved September 9, 2013, from http://ko.wikipedia.org/wiki/%ED%84%B0%EB%AF%B8%EB%84%A4%EC%9D%B4%ED%84%B0_(%EC%98%81%ED%99%94).
[11] (2006). 터미네이터 - 위키백과, 우리 모두의 백과사전. Retrieved September 7, 2013, from http://ko.wikipedia.org/wiki/%ED%84%B0%EB%AF%B8%EB%84%A4%EC%9D%B4%ED%84%B0.
[12] (2003). The Matrix - Wikipedia, the free encyclopedia. Retrieved September 7, 2013, from http://en.wikipedia.org/wiki/The_Matrix.


반응형
Posted by blueasa
, |

Link : http://www.venturesquare.net/524146

"나는 에버노트의 직원 누구도 일을 하면서 내가 왜 이것을 해야하는지 모르는 일이 없기를 바랍니다.
 나는 누구도 자기가 해야할 일을 하면서 “이건 위에서 시켜서 하는 거야. 한심한 일이지만 말이지”라고 
여기는 일이 없기를 바랍니다. 모든 직원이 자신의 일을 열심히 하면서 자기가 왜 그 일을 하는 것인지 
제대로 이해하기를 바랍니다. 보스가 시켜서 자신이 어쩔 수 없이 시간낭비를 하고 있다고 여기지 않기를 바랍니다.”



반응형
Posted by blueasa
, |


링크 : http://unitystudy.net/bbs/board.php?bo_table=dustin&wr_id=402&page=0&sca=&sfl=&stx=&spt=0&page=0&cwin=#c_406

반응형

'Unity3D > Plugins' 카테고리의 다른 글

Mobile Movie Texture  (0) 2013.12.03
원격 로그 플러그인  (0) 2013.11.20
IronPython  (0) 2013.10.06
UniPython  (0) 2013.10.06
Prefactory: Free PoolManager / PoolObject System  (0) 2013.08.28
Posted by blueasa
, |

링크 : http://devkorea.co.kr/bbs/board.php?bo_table=m03_site&wr_id=100&currentId=47

반응형

'Unity3D > Photon' 카테고리의 다른 글

Photon Cloud 강좌  (0) 2013.07.16
Posted by blueasa
, |
[http]'프로젝트가 서쪽으로 간 까닭은'중에서 '아드레날린 중독증' 패턴이 있다. 너무 미친듯이 바쁘다보니 장기적인 비전없이 끊임없는 야근속에서 눈앞에 보이는 문제만 해결하다가 프로젝트가 실패하는 패턴이다. 물론 같이 야근하지 않으면 왕따를 당한다. 아꿈사 모임에서 이 패턴에 대해 토론을 하던 중에 '한국 IT 현실에서는 어쩔 수가 없지 않느냐' 는 얘기가 나와서 한 소리 쓴다.
이런 자조적인 이야기 너무 많이 들어서 이제는 지겹다. 나도 예전에는 꽤나 야근을 했었지만 4년 전부터 거의 야근을 하지 않았다. (물론 지각은 거의 하지 않는다. 근태는 직장인의 기본 예의라고 생각한다.) 이런 점에서는 정말로 회사가 고맙고, 지금까지 참여한 프로젝트와 팀 동료들에게 고맙다. 심지어 평가도 그다지 나쁘지 않았다. 중간 정도 평가를 받았을 때도 있었고, 분에 넘치는 높은 평가를 받은 적도 있다. 하지만 평가를 잘 받던, 못 받던 일만 제대로 한다면 세상은 크게 달라지지 않는다.
평가를 잘 받기 위해서 자기개발 할 시간없이 프로젝트에 몰두하면서 스스로를 소모하다가 건강과 가족관계를 망친 후에는 일에 집중할 수가 없어서 무기력해지는 경우를 주변에서 꾸준히 보아왔다. (이거 [http]우리나라만의 얘기가 아니다.) 그러지 말자. 할 일이 없는데도 야근을 하지 않는다고 평가를 안 좋게 주는 관리자가 위에 있다면 '안 좋은 평가를 받아들이거나', '다른 곳으로 이직하면' 된다. 애당초 개발자를 그런 식으로 평가하는 관리자 밑에서 제대로 된 프로젝트가 나올지도 의심스럽다. 그래도 프로젝트가 성공하는 경우를 많이 봤다고? 같이 일하는 개발자가 불행한 프로젝트가 성공한 프로젝트라고 할 수 있을까? 솔직히 평가를 좋게 못 받으면 또 어떠냐. 그깟 연봉 1-5% 더 올리겠다고 스스로의 개발철학을 포기하는게 바람직한 삶인가?
당당하게 살기 위해서는 열심히 살아야 한다. 훌륭한 개발자는 당장이라도 회사를 그만둘 수 있어야 한다. 당장 회사를 그만두더라도 다른 회사를 골라서 갈 수 있도록 스스로를 벼린다. 물론 저축도 해 놔야겠지. 그래야 '짤리는' 것에 대한 공포를 이겨내고 잘못된 관행을 나서서 고칠 수 있다. (김용민은 [http]'나는 꼼수다 뒷담화'에서 잘리는 것에 대한 두려움을 버린 것이 자신의 최대 경쟁력이라고 했는데 많이 공감한다.) 좋은 소식은 개발자 품귀 현상은 계속 이어질 거라는 점이다. [http]이택경 프라이머 공동대표도 한 얘기지만 개발자가 부족하기 때문에 개발자의 몸값은 꾸준히 올라갈 것이다.
우리 사회에는 젊은 개발자가 보고 배울 수 있는 늙은 개발자가 필요하다. '강한 놈이 오래가는 것이 아니라 오래 가는 놈이 강한 거더라' - [http]영화 '짝패'


PS : '일이 너무 재미있어서' 개발에 몰두하는 사람은 예외로 두자. 여기에서 얘기하는 사람들은 '힘들어 죽겠는데 위에서 시켜서 어쩔 수 없이 야근하는 것에 불만만 있고 고쳐볼 생각을 못해보는 사람들'에게 하는 얘기다.
PS (2) : 저 회사 그만 두는거 아니예요. 우리 회사, 우리 프로젝트 짱 좋습니다. ㅋㅋ


출처 : http://parkpd.egloos.com/3775792

반응형
Posted by blueasa
, |

링크 : http://blog.naver.com/nonthink89/110175364708

반응형
Posted by blueasa
, |


링크 : http://myevan.cpascal.net/articles/2013/unity_ngui_pixel_perfect.html

반응형
Posted by blueasa
, |