버그는 프로그래머의 숙명이다. 그 섬세하게 만들려한 IOS, OS X에도 버그는 종종 있으며, 사실 많은 사람이 M$라 부르지만 나의 경우는 매우 감사하고 있는 MS의 경우에도 버그는 많다. 구글도 예외는 아니고. (구글 apps 초창기 패치할 때 마다 언어 관련, IME 관련 문제를 겪게 했던 일은 나름 유명한 일화다.) 이러한 회사는 분명히 업계의 엘리트가 모여있을 텐데 어째서 이렇게 버그가 나오는걸까? 어찌보면, 버그는 당연한 숙명이다. 하나의 어플리케이션을 작성하기 위해, 잘 작성된 위지윅 툴을 사용하더라도, 버그가 없다고 단정 지을 수 없다. 하물며, 코드가 들어가고, 각종 코드를 재사용하고, 다른 코드를 얹는 과정에서는 복잡도와 결합도는 증가하고, 당연히 버그가 생길 여지도 많아진다. 자 그렇..
꽤나 많은 상황에서 우리는 기존 코드를 분석해야 한다. 빌드업이라 불리는 프로젝트에 필요한 기능들을 만져나가는 과정에서도 우리는 라이브러리나, 오픈소스 코드등을 통해서 기존 코드를 분석해나가야 한다. 물론 이 과정은 섬세하게 만져나갈 여지가 있고, 그간의 결합도를 조절해나갈 여지가 있으므로 상대적으로 코드 분석의 여지가 적다. 심지어 사용하는 라이브러리들이 익숙하거나, generic하게 구현되어있다면 더더욱이 쉽고. 사실 가장 곤욕스러운 과정은 프로젝트 dependency 한 코드를 분석하게 될 때이다. 이 과정에서, 코드간의 결합도를 낮출려고 노력해온 흔적이 있는 경우는 그래도 상대적으로 쉬운 편에 속한다. 예를 들어 패킷으로만 다른 티어와 통신을하고, 패킷 핸들링 코드가 명확하다면 기존 코드가 난해하..
내가 코드를 작성할 때 신경쓰는 코딩 규약들을 정리해본다. 소유권 객체의 소유 주체는 (생성과 소멸의 관리 주체는) 하나로 규정한다. 객체의 생성,소멸 스레드도 하나로 규정한다. 다른 클래스에서 호출되어야만 하는 메소드를 만들지 말라. Has a 관계가 명확하다면, 이 관계를 혼란 시킬 수 있는 메소드는 절대 만들지 마라. 진입점 진입 점은 명확하게. 한곳으로 관리하자. 만약 다양한 진입 점이 있을 수 밖에 없다면, 다른 각각의 진입 점에서 왔음을 알 수 있게 하라. 중복 중복을 허용하지 말라. 단일 규칙 두 가지 이상의 규칙을 허용하지 말라. 새로운 규칙을 도입하고 싶다면, 기존 규칙대로 작성된 전부를 고쳐라. 두 가지 이상의 규율이 존재하는 것은, 코드 작성/분석 등 모든 과정에서 해가 된다. 전치 ..
지난해 10월, 미국의 북동부 지역은 어딜 가나 아셀라(Acela) 광고 천지였다.아셀라란 암트랙(Amtrak)이 워싱턴-보스턴간 노선에서 운행할 새로운 초고속열차의 이름. 끊임없이 쏟아지는 TV 광고와 전광판 광고, 도처에 나붙은 포스터들을 보면서, 누구라도 이 정도의 물량 공세라면 이 새로운 초고속열차 서비스에 대한 수요 창출에 상당히 기여했으리라 생각했을 것이다. 글쎄, 그랬는지도 모르지. 하지만, 정작 암트랙사는 이를 확인해 볼 기회가 없었다. 아셀라 프로젝트가 계속 지연되는 바람에 상용서비스가 개시되지도 않은 상태에서 광고 캠페인만 진행되고 있었던 것이다. 어떤 회사의 신제품 시판을 한달 앞두고 이 제품이 우수한 평가 등급을 받자 마케팅 책임자가 했다는말이 떠오른다. “대단한 홍보 효과야! 이럴..
내 첫 IDE는 MS-DOS용 터보-C 2.0이다. vi 정도는 아니었어도, 윈도우 기반 요즘 IDE와는 비교도 안될만큼 불편했다. 그런 환경에서 Visual Studio 5.0을 썼을때의 환경은 말그대로, 환호가 절로 나왔으며, MFC의 App Wizard는 신이 내린 하사품 같았다. 그렇다보니 GUI환경에 대한 동경은 갈수록 커져만갔을 뿐... 글씨만 줄창 보게되는 CUI (Console User Interface)에 대한 내 이미지는 "직관적이지 않고 어렵다" 였다. 알바 경험, 외주 경험을 다 제끼고 나면 나는 온라인 게임만으로 일해왔다. 내가 상업적인 프로젝트에 외주가 아닌, 직원으로 일한 것은 싸이미디어사의 믹스마스터였다. 당시 서버는 리눅스 서버였는데, 클라이언트 프로그래머였던 나로썬 점검시..
서버의 부하를 줄일 수 있는 부하 조절 정책으로, 블리자드의 디아블로2팀이 조치한 방법이 어떤 방법인지 알아보자. 1. 서버에 요청하는 액션이 일정 횟수 이상 반복되면 Trouble 유저로 판단.* 방 입장/퇴장 반복* 방 생성 후 일정 시간 이내에 빠른 퇴장* 로그인/로그아웃 반복 2. Trouble 유저 (계정)로 판단시 해당 캐릭이 사용된 IP를 차단.* Trouble 유저가 일정 시간내에 다른 IP에서 재사용된다면 그 IP도 차단.* 한번 Trouble 유저로 인식되면 문제가 된 Trouble 사유가 아니더라도 (예: 방생성/퇴장 반복) 로그인만으로도 IP차단. 3. 빠른 방생성 입장/퇴장의 경우 ProcessID도 인식하는 것 같음. (정확하지 않음)* 배틀넷 로그아웃후에 로그인을 통해 방 입장..
1. 개체 단위 lock. 개체 수와 종류가 늘어날 수록 헬. dead-lock 위험성도 매우 크다. 상위 개체 단위로 lock을 잠글 수도 있는데, 이마저도 상호 연관 이벤트가 늘어나면 헬이다. 사실 lock만으로 멀티스레드 로직을 구현한다는 것은 사실상 불가능에 가까운 복잡도를 만들어 낸다는 것을 이미 여러 프로젝트가 증명했다. 2. 데이터 사본 연산 그룹마다 (방 혹은 채널, 존) 스레드를 따로 생성하고 데이터 사본으로 연산 한 후 연산 결과를 이벤트로 다시 던져, 다음 턴 수행 전에 적용하는 방식이다. 기본적으로 턴(프레임이라 불리기도 하는) 단위를 잡고, 해당 단위마다 로직이 돈다는 것을 전제로 삼을 수 있어, 여러가지 계측의 기준점이 되기도 한다. 여러 그룹에서 동시 다발적인 변화가 발생해, ..
1. Through-put 초당 소화 가능 이벤트. 이는 DB나 연결된 기능들과의 교신/처리가 포함된 계측 이어야 한다. 분산 가능한 특정 이벤트들은 지정된 서버와의 교신 (P2P스러운 접근)만으로 처리함으로써, 비용을 분산 시킬 수 있다. 일반적으로 다음 두가지 측정이 이루어지면 된다.- 프레임워크 (네트웍 엔진이라 불리우는) through-put.- 로직 through-put. 2. Through Pipe-line 파이프라인이란 이벤트 처리를 위해 거치게 되는 과정을 표현한 것을 말한다. 구현 별로 다른 어떤 과정에서도 wait-free 방식으로 구현하는 것이 좋다. 어쩔 수 없는 상황이라면 해당 작업 전용 스레드를 할당 받는 것이 좋고. Through Pipe-line은 스레드 디자인과 큰 연관이 ..
- Total
- Today
- Yesterday
- Rails
- 디버깅
- TraceRoute
- NDC2013
- CppSQLite
- 디자인 패턴
- TDD
- SDL
- Ruby on Rails
- 좋은 프로그래머
- perfmon
- RoR
- 조엘 온 소프트웨어
- EzShortcut
- MS-SQL
- 리버스 엔지니어링
- 임백준
- 게임개발포에버
- SQLite Spy
- EasyExec
- c언어
- ruby
- 멀티스레드
- 루비
- svn
- 루비 온 레일즈
- 게임데브포에버
- 엘키
- ftp
- 바로가기 프로그램
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |