blog.wimy.com

한참 회사 일에 여유가 있을 때 읽기 시작했는데, 갑자기 엄청나게 바빠져서 미뤄두다가, 찝찝함을 견디지 못하고 다시 읽기 시작해서 끝까지 읽게 되었다. 일단 책의 내용은 너무 와닿는다. 전혀 추상적이지 않고, 짤막한 예제들로 이루어져 있어서 술술 읽힌다. 그리고 책도 두껍지 않다;; 게임 프로그래밍을 하고 있는 입장에서는 필독서라고 불릴만한 것 같다. 다른 책들은 읽으면서 요점들을 구글 문서에 정리했었는데, 이 책은 정리할 수가 없었다. 한번 읽은 후에는 제목만 봐도 무슨 얘기를 하는지 알 정도의 자세한 설명이 있기 때문이다. 정리를 꼭 해야 한다면 책을 베끼는 수준이 될지도...; 전반적으로 패턴들을 소개하면서, 해당 패턴의 장점뿐만 아니라 단점도 소개하면서 해당 패턴을 사용할 때 어떤점들을 고려해야 ..

집에서 종종 unity 만지면서 놀다가, 유니티 클라우드 빌드를 써보기로 하고 간단히 설정해서 써봤는데, 로컬에서 빌드하면 잘 시작되는데, 유니티 클라우드 빌드에서 빌드한 apk 를 받아서 실행하면 유니티 로그 화면에서 멈추는 것이다. 이 문제로 고생하다가 해결하려고 마음 먹고 adb 로 로그를 찍어봐도 별 이상없고 해서 유니티 클라우드 빌드 웹페이지의 설정 화면을 살펴보니, 해결할 수 있었다. Config -> Show Advanced Options -> Edit Advanced Options 클릭 -> Scene List 에 본인의 Scene 파일 이름(예를 들면 Default)를 적고 Add 버튼을 누른 후 저장하자. 아마 제대로 된 경로(Assets/Default.unity)를 보여줄 것이다. 즉..

뭐 당연한 얘기일 수도 있는데, go언어를 appengine 으로 개발하면서 로컬에서 띄운 서버인데도 1초 정도 걸렸다. 너무 느려서 stackoverflow 에 질문했더니... http://stackoverflow.com/questions/33942583/too-slow-ttfblatency-with-go-language-in-appengine/ 실서버에서는 괜찮을거라고... 근데 나는 실서버에 올려도 느려서 혹시나 하고 developer console 에서 확인해보니 appengine 의 위치가 us-central 이다. 그래서 azure 를 통해서 가상 컴퓨터를 미국 중부에 만들어서 접속해보니 37ms 안에 응답이 시작되었다. 역시... appengine 을 쓸 때는 빠른 응답을 기대하고 쓰면 안되..

Google Hackfair 에 내려고 만들었는데, 안타깝게도 전시회에는 못 나가게 되었음 ㅠㅜ 마무리하는 의미로 블로그에 소개글 남겨본다. 메인 주제는 YouTube 를 통한 영어 공부를 할 때 도움이 되는 웹앱이다. 다음과 같은 기능이 있다. * 구간 반복* 속도 조절* 5초/10초 앞으로 가기* 자막 켜고 끄기* 사전 연동 소개 동영상 주소는 https://www.youtube.com/watch?v=_UVfek-zRqE 이다. 홈페이지 주소는 http://tube-english.appspot.com/ 이다. 여기서 검색 창에 YouTube 주소를 붙여넣고 검색하면 위의 화면처럼 로딩되면서 앞의 기능들을 사용할 수 있다. 크롬 웹브라우저에서는 [플러그인] 을 설치하면 YouTube 에서 동영상을 보다..

google hackfair 2015 를 준비하면서 겪었던 것들을 잊기 전에 정리해본다. 아쉽게도 전시회 명단에는 들지 못했지만 ㅠㅜ go 로 만든다고 매우 큰 속도 향상은 없었다. 연산을 많이 하는 작업은 빨라질 거라 예상하는데, 단순한 request~response 의 경우 속도가 그렇게 빠르다는 느낌은 없다. (내가 아직 잘 몰라서겠지만)오히려 단순한 작업의 경우 1,2초의 응답 속도를 보일 때가 있다. 왜 그런지는 좀 더 파악해봐야 할듯. appengine 에서 datastore 를 사용할 때 로컬에서는 문제가 없었는데 실제 서버에서 "" 이런 오류가 날 경우가 있다. 해당 쿼리문의 조합을 지원하는 복합 인덱스가 있어야 한다는 것인데, 로컬 서버에서는 문제가 없었기 때문에 좀 난감했다. 로컬 서버..

어느날 갑자기 나는 회사에서 무엇을 하고 있는가하는 생각이 들었다. 블로그가 원래 개인의 기록을 남기는 것이기 때문이기도 하고 혹시나 게임 서버 개발자가 되고 싶어하는 사람들이 궁금해할까 싶기도 하고... 대략 9시 전후로 자전거를 타고 출근을 한다. 집에서 나서서 회사 자리에 앉기까지 대략 20분 정도 걸리는 거리라서 부담이 없다. 오히려 버스를 타면, 걸어나오는 시간, 버스 기다리는 시간 등 때문에 더 오래 걸린다. 비오면 버스타야함. 9시 30분 기준으로 업무가 시작되며, 좀 늦게 와도 뭐라하는 사람은 없다. 다만, 업무시간 8시간은 다들 알아서 지킨다. 출근해서 자리에 앉으면, 어느 자리에서나 보이는, 매우 커다란 모니터에 주기적으로 개발 상태를 체크하는 CI(젠킨스)가 현재 어떤 문제가 발생했는..

누군가 코드를 만든다. 꽤 잘 만들었다. 다른 누군가 그 코드에 수정사항을 가할 일이 생겼다. 원래 코드의 의도를 100% 이해하지는 못하고 만들게 된다. 당연하다. 일정이 있고, 간단해보이는 일을 하는데, 원래 전체 코드를 다 읽고 일할 수는 없다. 하지만, 특정 함수가 길어지게 되었다. 또다른 누군가가 새로운 기능을 추가한다. 또다시 전체 코드를 모두 이해하고 작업을 하지 않는다. 하지만 새 기능은 제대로 동작하며, 딱히 고쳐야할 이유는 없다. 기존의 코드와 모양새가 다르고, 독립적인 모듈처럼 보이기도 한다. 또 새로운 기능이 추가되는데 앞의 기능과 비슷한 기능이다. 앞에서 누군가가 만든 클래스와 비슷한(복사~붙여넣기를 한) 클래스를 만들어서 하위 모듈로 추가한다. 여전히 잘 동작한다. 꽤 큰 기능인..

내가 주석으로 남겨놓은 코드는 남들에게 '이게 왜 주석처리되어 있는가, 앞으로 쓰일 코드인가?'라는 의구심을 주게 되고, 코드를 읽는데 방해를 주게 된다. 사용하지 않게 된 변수, 함수들을 남겨놓으면 그 코드를 잘못 사용하게 될 여지가 있다. 동료가 그 함수를 잘못 사용해버릴 수도 있고, 마찬가지로 더이상 사용하지 않는 변수를 비교한다든지할 수도 있고, 코드를 읽기도 힘들어 진다. 내가 A라는 작업과 B라는 작업을 동시에 진행하고 한번에 submit 하게 되면, 나의 코드를 리뷰하는 동료들은 도대체 이 submit 은 왜 이렇게 복잡한거야라면서 리뷰를 하지 않게 된다. '가나다 동작 방식을 바꿈' 이라고 적어놓은 submit log 는 '가나다 동작 방식을 바꿈. 정렬을 먼저 시킨 후에 공백을 제거함' ..

오늘 팀장님께 열심히 강의들었던 내용임... 조금은 각색해서... 다들 알다시피 프로그래밍을 할 때 이름이 중요하다. 한 눈에 알아보기 쉽고, 읽기 쉽고, 의도를 파악하기 쉽다. 뭐 대충 책에서 이런 내용들이 있고, 다들 알고 있다. 하지만 우리는 비영어권이기 때문에 늘 이름짓기를 힘들어한다. 오늘 한창 디버깅을 하고 있는데, 살짝 멘탈이 붕괴되는 상황에서, 다른 사람들이 마구 추가한 코드를 접했다. 사실 내가 추가한 것도 있겠지. 하지만 내 기억과는 먼 코드들이다. 왜 여기에 이런 코드들이 존재하는가. 팀장님이 이런 얘기를 해줬다. 자꾸 다른 사람들이 이 XXXManager 클래스에 이런저런 코드들을 넣는 이유는 이름이 Manager 이기 때문이다. 클래스 이름을 좀더 특화시켜서, Creator 라고 ..

아는 친구가 만든 프로그램에서 MFC 를 제거하고, x86에서 x64 로 전환하는 과정 중에서 생긴 버그였다. IOCP 에서 WSARecv 를 했는데, 실패하면서 에러코드를 살펴보니 10014 오류가 났다. 한글 번역으로는 '호출에 대한 포인터 인수를 사용하려는 동안 시스템에서 잘못된 포인터 주소를 감지했습니다.' 이고, msdn 에서는 lpbuffers 인자가 잘못되었다고 하고, 이래저래 검색해보면 인자의 생명 주기라든지, 다른 인자가 잘못되었느니라고 적혀있었다. 결론은 winsock2.h 를 include 하기 전에 #pragma pack (1) 코드가 있었다. 제거하니 잘된다. ㅠㅜ 아마 pragma pack 에 의해서 winsock2.h 에서 정의하는 구조체가 pack 되어버렸을 것이고, 그렇게 ..