pycrust는 wxpython에 따라오는 ( wxtools 에있음 ) interactive python shell로 ipython을 쓰기 전에 잘 쓰던 것이었습니다. 최근 ipython 이 살짝 이상해진 관계로 다시 pycrust를 쓰고 있는데 역시 wide 화면에서 가로 분할 윈도우는 짜증 나는 관계로 수정을 시도 하였습니다. 패치가 이루어진 다음엔 과 같이 와이드 화면에 어울리게 된 것을 볼 수 있습니다. /usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/py 에 존재하는 crust.py 내의 self.SplitHorizontally(self.shell, self.notebook, -self.sashoffset) 를 self.SplitVertically(self.shell, self.notebook, -self.sashoffset) 로 바꾸면 됩니다. ( 두번 나옵니다. , _CheckShouldSplit 와 ToggleTools 함수 )

앞으로도 자잘한 수정들은 있겠지만 큰 변화나 추가는 없을 듯 합니다. 이번에 twisted 버전을 작업하면서 오랫만에 다시 twisted를 만져 봤는데 예전에 테스트한 기억 보다 많이 빨라진 듯 합니다. twistedtest.py를 보면 테스트 할 때 사용한 코드가 있습니다만 비록 echo 서버긴 하지만 초당 10만 패킷을 넘게 처리 하는 군요. ( intel 2500, pypy 사용, Int32StringReceiver 프로토콜, epoll reactor 사용.) 이 정도면 거의 대부분의 서버에서 필요한 성능을 충족시킬 수 있을 것 같습니다. epoll reactor를 사용할 경우 6만 정도의 동시 커넥션 상태에서도 6만 패킷/초 이상을 꾸준히 처리 할 수 있습니다.

새로 바뀐 스크린 샷 client/server 실행법 서버는 인자없이 그냥 실행하면 됩니다. python wxgame2server.py 또는 이번 C/S 분리의 목적중 하나인 wxpython 코드 제거로 wxpython코드가 서버에는 없기 때문에 pypy를 사용할 수도 있습니다. 클라이언트 실행 python wxgame2client.py -s serverip -t teamname -s 는 접속할 서버의 주소, port는 고정입니다. -t 는 클라이언트 AI의 팀 이름 -t 옵션이 생략되면 서버에 observer mode로 접속합니다. ( 서버가 보내주는 정보를 화면에 표시만 하는 모드 ) 각 팀은 랜덤한 teamcolor를 가지며 그 color대로 표시됩니다.

사진 설명 - 서버에 네개의 네트웍 클라이언트를 접속하여 실행 중인 화면. 이전 글들 이후로 개인적 여유 시간을 대부분 투자하여 ( 아직 버그가 좀 남아있긴 하지만;) wxgame2 의 네트웍 버전을 거의다 만들었습니다. github의 코드 를 보시면 알게 되겠지만 기존 wxgame2 코드의 상당부분이 재 작성 되었으며 네트웍 쪽 코드도 수차례 재 작성하였습니다. 정식 MMORPG처럼 모든 판단은 서버에서 이루어지며 각 클라이언트는 시각화와 클라이언트 AI 만 작동하는 형태 입니다. 서버 사이드 AI도 존재 하는데 이것은 서버의 NPC를 시뮬레이션 하는 것입니다.

이전 글 이후에 강의 준비를 하면서 코드를 보니 코드가 오래 되기도 했고 또 설계상의 결정들이 맘에 들지 않아 전체적인 재 정리를 해야겠다고 생각하고 있었습니다. 지난 주부터 시간 되는 대로 작업을 진행해서 로직을 수행하는 wxgame2server.py와 서버로 부터 받은 정보를 시각화하는 뷰어인 wxgame2client.py 로 만드는 것을 일정부분 끝냈습니다. 현재까지는 네트웍으로 데이터를 주고 받는 것은 안되어 있으며 간단하게 file/pickle 을 상용해서 서버-> 클라이언트간 정보를 전달하고 있습니다. 코드를 작성하다 보니 구조가 맘에 들지 않아 거의 뜯어 고치게 되었습니다.

고려 대학교 고공 겨울학기의 한 꼭지로 게임 프로그래밍 이란 주제로 2시간 짜리 강의를 진행했습니다. 원래는 4일간 2시간씩 총 8시간 짜리 강의지만 첫날 2시간만 제가 하고 이후는 능력 좋고 경험 많은 후배가 강의를 진행하고 있습니다. 이전에 썼던 글 게임프로그래밍이라는 주제로 과 예전에 파이썬으로 만들었던 게임프레임웍을 github에 올렸습니다. 을 사용해서 강의를 진행 했으며 강의에 사용했던 프리젠테이션은 https://docs.google.com/presentation/d/1fNa2hY5qGE_bGnsT0NhmnVQQC6kjLuUb4i3HtQATJCI/edit#slide=id.p 에서 볼 수 있습니다. 전산 실습실에서 진행해서 실습과 병행하여 진행할 생각으로 실습 준비를 해갔으나 생각만큼 잘 되지는 않은 것 같습니다.

파이썬과 wxpython을 사용해서 간단한! 2d 슈팅게임을 만들 수 있는 프레임웍과 예제 삼아 만들어본 AI만 있는 게임?을 github에 올렸습니다. 코드 내부의 주석을 보니 2011년에 만들어둔 것이군요. 그 동안 python홍보용으로 잘 써먹었던 프로젝트입니다. ( 파이썬으로 이런 게임도 만들 수 있어. 너도 배워 보지 않을래? 등 ^^ ) 원래는 더 일찍 공개하려고 했으나 코드 정리등이 귀찮아서 미루다가 모 후배의 압박으로 대충 정리해서 올립니다. 관심 있으신 분은 https://github.com/kasworld/wxgame2 에서 받으면 됩니다. 원래 코드는 제가 개인적으로 만들어 사용하고 있는 kaswlib이란 것을 사용하도록 되어 있는데 github에 올리려니 서로다른 두개의 프로젝트가 되고 또 참조를 하려면 import path를 설정하는 것도 해야 해서 쓰기 불편할 듯 하여 아예 프로젝트 내부에 wxgamelib 파일에 사용하는 코드만 복사해 넣었습니다.

지인으로 부터 뜬금 없이 “게임프로그래밍"라는 주제로 특강을 해달라는 부탁을 받아서 ( 아직 할지 말지는 미정이긴 하지만 ) 이런 저런 생각이 들어 적어보고 있는( 즉 아직 작성중인 ) 문서입니다. “게임을 만든다는 것은 무엇일까?” 게임이란 무엇일까? 게임의 정의를 논하는 것은 프로그래머 입장에선 쓸데없는 것일 테니 무시하기로 하고 ^^;;; 게임을 만드는 회사를 10년 넘게 다녔던 프로그래머로서 게임을 만든다는 것을 생각해보면 게임을 만들기 위한 직능을 준비하고 그 실무를 진행하는 것으로 정의해볼 수 있을 것 같습니다.

회사 세미나용으로 http://web2py.com/books/default/chapter/29/09/access-control 을 요약한 내용 입니다. 접근제어 access control web2py 는 Role Based Access Control 제공 (RBAC) 역할을 기반으로하는 접근제어로 context-based access control (CBAC) 과는 다르다. ( message의 context에 따라 달라지지 않는다, 상태, 혹은 데이터 ) user - role - job function 형태 web2py 에서는 Auth class를 통해서 구현된다. 아래와 같은 테이블이 필요한데 프로젝트를 만들때 자동으로 코드가 생성된다. auth_user : 유저이름 , email , 암호 , 상태 (등록 대기, 완료, 블럭됨 ) auth_group : 유저의 그룹(롤) 정보 , 이게 role ( 사용자 역할 ) auth_membership : group - user link table , user - group의 다대 다 연결.

버럭! 한 사람이 어디 저 뿐만이겟습니까만;; ^^ 저 역시 소식을 접한 후부터 계속해서 대안을 찾고 있기는 했습니다. 일단 feedly로 임시 도피를 해서 살고 있긴 합니다. 쓰는 소감을 말하자면 뭐 그냥 그냥..이란 느낌입니다. 최근 집에 오래된 노트북으로 서버를 구축하고 그를 중심으로 사용 패턴을 정리해서, unison 으로 개인 파일들을 반자동 sync 한다던지 하는 설정을 하다 보니 , 외부 서비스를 점점 사용 하지 않게 되더군요. 그래서 다음 클라우드,box.com,그리고 dropbox 마져도 더이상은 사용하지 않고 살게 되었습니다.

회사에서 세미나 용으로 작성한 글인데 쓰고 보니 이것 만으로도 web2py의 소개 용으로는 충분 할 것 같아서 그리고 블로그에 올려도 좋을 듯한 내용이어서 올려 봅니다. 원문은 http://web2py.com/books/default/chapter/29/03 이며 번역을 한 것이 아니고 업무에 필요한/필요할 것 같은 것들을 정리한 글이라 원문과 같이 놓고 보셔야 이해가 될 듯 합니다. 제가 맡은 부분인 Overview 부분 만 입니다. ^^ web2py 개요 - overview ** ** 시작하기 - startup web2py는 윈도우와 맥에선 실행 프로그램으로도 제공되기 때문에 따로 python 이 필요하지 않다.

간단한 팁입니다만 기록을 위해서 적습니다. 전 윈도우건 리눅스건 환경을 거의 통일 시켜놓고 작업을 하는 편입니다. 이 환경의 통일에서 상당히 중요한 역할을 하는 것이 gvim 인데 http://www.vim.org/download.php 주 에디터/뷰어로 항상 gvim을 사용하도록 세팅해 놓으면 chrome/firefox와 더불어 종종 “내가 지금 윈도로 부팅한 상태인가?” 를 헷갈릴 정도로 일관된 환경을 유지 할수 있습니다. ( 과장이 좀 많이 있지만요. ^^) 아무튼 vim을 쓰고 있는 시간이 많아지니 이런저런 플러그인 들도 설치하게 되고 http://kldp.org/node/125263 설정들도 이렇게 저렇게 하곤 합니다.

세월이 하수상하지만 ( 정치건 it 판이건 ) 곰곰히 생각해보니 python을 실무에 적용해서 써 온지도 어느덧 10000시간이 넘어간듯 합니다. 얼마전 아는 후배가 첫 8bit kid들이 아직 프로그래밍을 하고 있으면 대충 30년이 되었다고 하는글을 올렸는데 그 글을 보면서 만감이 교차 하더군요. 정말로 30년이 된겁니다. ㅠㅠ 살아온 시간의 3/4 이상을 컴퓨터와 함께 지낸거지요. 그래서 생각해본 언어별 투자? 시간입니다. ( 중복 시간이 있으니 총합은 30년이 넘을수 있습니다 ) basic ( apple soft ) : 5년 Assembly : ( 6502 ) : 3년 ?

uwsgi 사용시 (http://projects.unbit.it/uwsgi/wiki) post data를 처리 하고 싶으면 결과 return/yield 를 내보내기 전에 읽어 와야 한다. 그렇지 않으면 메롱한 에러를 내는 경우가 왕왕 생긴다. ( 검색해보니 알려진 버그인듯. ) 이것때문에 오늘 시간좀 소비 했음. 아 그리고 web service 개발할때 curl 이 정말 편하다. command line으로 http post를 할수 있으니 코드 테스트가 정말 편하게 이루어지더라. ;;; 역시 인간은 검색을 생활화 해야 하는 것이었다 ;;;

를 하기전에 ^^;;; web server : apache , lighttpd, nginx , cherokee, cherrypy, simplehttpserver(python) web app protocol : static file, wsgi , uwsgi web app frame work : node, cherrypy, django , web2py, 중 어떤 조합을 사용할지를 결정해야 해서 그동안 써왔던 것을 모두 점검하는 의미로 간단/대충 벤치마크를 해봤음. 즉 이글은 그 기록을 남기기 위한 글. ^^ 기본적으로 다 hello world 를 리턴하는 static file 또는 print 코드 를 사용 해서 테스트 했습니다.

시간 날때마다 집에서 간단한 슈팅 게임? 을 만들고 있습니다만.. ( 엄밀히 말하면 2D 게임을 위한 프레임웍 ) 전 게임을 하는 것보다 구경하는 것을 더 좋아하는 편이기 때문에 대신 플레이해줄 AI들을 몇가지 만들고 있습니다. 몇종의 AI를 만들고(허접하지만) 각각의 AI끼리 대전을 시켜보며 구경을 하고 있는데.. 만든 입장에서 더 실력이 좋을 거라고 생각하면 만든 AI 보다 대충 머리수 채우기로만든 AI가 더 점수가 좋은 경우가 꽤 있군요. 그러면 다시 코드를 보면서 이유를 생각하고 그 결과를 다시 반영해보고 하면서 즐기고 있습니다.

개인 취향에 따라 언어 취향도 갈리는지.. php,python,perl,ruby를 공부 하다보면 기능의 강력함과 별도로 언어의 철학이 취향에 맞는지가 신경쓰이더군요. 전 C의 단순함과 강력함은 좋아 하지만 perl의 자유분방함은 적응이 안되었고 pascal의 딱딱함은 싫어 하지만 python의 단정함은 매우 맘에 들었습니다. ;;; smalltalk의 순수성은 이해를 못해도 ruby의 oo에 대한 고집은 공감하게 됩니다.