rein’s world

후배 d* 가 물어본 질문.

d |
d | 질문
d | 메신저를 개발한다고 했을 때
d | 염두에 둬야 할 점은 뭐가 있을까요?
d | 음… 일단 다른 메신저의 소스는 구해놨고, 네트워크 좀 더 공부해야 하려나…

…여기에 대한 몇몇 의견.

p | 부가기능 어디까지 지원하나요
d | 그냥 노멀하고 스탠다드한 메신저라고 가정하지요.
p | 파일전송이 되냐 안되냐, 게임(…)이 되냐 안 되냐에 따라서
p | 레이어가 차이가 있을 것 같지만
p | 저도 네트워크를 잘 아는 건 아니므로
ㅃ | 1:1 대화에서 다대다 대화가 될 경우를 염두에 두면 좋지 않을까

내 경우에는 보통 이런 결정을 내린다 — 특히 개발 기간이 짧아야 한다거나 한 경우에는 더더욱.

있는 솔루션 쓰자 — 이 경우엔 IRC 서버를.

rein | d: IRC서버 고쳐서 써
rein | …
d | …
rein | 아니 농담이 아닌데
rein | 인증이랑 초기 접속만 맞게 수정하고
rein | 나머지는 IRC / IRC query 기능이잖
rein | 잘 알려져있고
rein | 분산 서버 구현도 알려져있고
rein | 테스트되었고
rein | 뭘 더 바라는데

사실 이런 경우엔 아주 이상적인 솔루션이기도한 IRC 서버가 있다. 우리가 만들어야하는 물건 중 상당수는 이미 발명된 경우가 대부분이고 — 많은 경우 수차례 반복된다 — 그 중 적합한게 적어도 하나는 있다.

메신저 서버가 가져야할 안정성 문제 , 확장성 문제 가 해결되어있으니 그냥 쓰면 되지 않나 싶다.

재작년에 채팅 서버군 솔루션이란걸 볼 기회가 있었는데 보고나서의 내 논평은,

그냥 IRC 서버 쓰시죠

…

뭐 그러하다.

무시무시한 후배 고어핀드군에게서 넘어온 바톤입니다.

1. 블로그는 어떻게 시작하셨습니까?

블로깅을 시작한 것은 2005년 6월, 버려뒀던 홈페이지 — 잡기장 비슷한거였는데 생각해보면 그것도 역-연대기순의 블로그 비슷한 자작페이지 — 를 살릴까 하다가 블로깅툴(지금은 안쓰는 태터툴즈)을 설치해서 시작…했다가 태터툴즈의 버젼업 문제 + 인코딩문제로 현재 사용하고있는 WordPress로 넘어왔습니다.

2. 하루 포스팅 수는 얼마나 됩니까?

올해 들어서는 일주일에 10개 정도의 포스팅을 하는 중입니다 . 작년 상반기 이전에는 주당 1개(…)이하수준;

3. 블로그의 주제는 뭐죠?

이 블로그의 주제는 rein이 사랑하는 것들 — 프로그래밍, 책, 게임 — 인데 지금은 블로깅도 그 범주에 포함되어가는 상황. 가능하면 생각도 정리할 겸 현재 직업이기도하고 — 게임 개발자(서버프로그래머) — 좋아하는 일이기도 한 concurrent 프로그래밍을 다루려고 합니다.

4. 블로그 이웃들과의 사이는 어떤가요?

이 블로그에 자주 댓글을 다는 사람 중에 절반?정도가 오프라인에서도 아는 분들입니다. 물론 온라인으로만 뵙게 되는 분들도 점점 늘고 있어서 즐거워하는 중입니다

몇몇 메타 블로그에도 등록해 놓고 있긴하지만, 실제로 다른 블로그는 구독하던 블로그에서 재밌는 얘기를 꺼내는 분들을 한다리 한다리 따라가서 뵙게 되더군요. 그리곤 눈팅을 좀하다가 댓글도 쓰고 트랙백도 쓰고 그런답니다.

5. 메신저에 블로그 이웃들이 얼마나 있습니까?

오프라인으로 아는 사람을 빼면 없는듯합니다.

6. 하루에 블로깅을 몇시간씩 합니까?

회사에서 보조컴퓨터로 쓰는 애에 HanRSS를 띄워놓고 빌드 돌려놓고 와서 보거나, 댓글을 쓰거나 합니다. 집에 오면 보조 모니터 한쪽에 HanRSS를 띄워놓습니다.

시간으로는 대략 하루에 40분 ~ 한 시간쯤 되겠네요. 물론 글을 쓸 때는 한정없기도 하지만(…)

7. 블로그 이웃들중에 자신보다 나이 많은 사람과의 교류는 어느정도죠?

제 나이가 20대 중앙을 막 가로지른 참이라(작년 블로그를 뒤져보면…) 대충 1/4 ? 정도의 분들이 저보다 나이가 위인 것 같습니다.

8. 블로깅을 하면서 바뀐점이 있나요?

우선 생각을 정리하기 좋아진 것 같고, 요즘은 하루에 1개의 글은 무조건 쓰려고 하다보니 되새김질이 잘 되는 것 같다는 느낌. 그리고 잘못 알고있거나 하는 내용을 바로잡아지는 것도 좋군요.

그리고 컴퓨터/컴퓨터 프로그래밍 쪽의 용어를 한글로 쓰는 문제에 관해 고민하게 됐습니다.

9. 존경하는 블로거가 있나요?

이글루스의 꼬깔님 블로그를 무척 좋아합니다. 공룡(화석이라거나) 별 얘기를 즐겁게 읽을 수 있는 곳입니다. 꼬깔님의 진지한 모습을 존경합니다

지금은 티스토리로 옮겨가신, puzzlist님의 블로그 역시 머리를 즐겁게 해주는 곳인 것 같습니다.

마지막으로 한글이 아니긴하지만, The Old New Thing라는 Raymond Chen의 블로그도 읽다보면 저 멀리 앞서간 프로그래머의 모습을 보게 됩니다.

10. 자신의 블로그의 수준은 어느정도 된다고 생각하나요?

듣보잡을 탈출하려고 애쓰는 수준이지요.

11. 다음 바톤상대를 정해주시겠어요?

고어핀드군이 여러명을 납치(?)해간 관계로 간단히 네 분에게만.

• Dish 군 - 블로그 문답
• everclear 군
• lune 양 - 블로그 문답
• jstrane녀석(…)

이게 처음이 아니라 이런 글을 쓴다 — 엔지니어는 실패로부터 뭔가 가설을 수정할 수 있는 사람이어야 할테니.

이번에 고친 것 목록 — PHP 파일의 수정도 포함하고 있다

1. Widget 수정 — Theme 마다 고정된 자신만의 디자인을 갖는 위젯을 갖는 경우가 흔하다. 그래서 Design -> Widgets에서 적당히 수정해줘야함
2. Header.php — HTML 페이지 제목을 단조롭게 출력하는 테마가 많다. 이런 경우에 Google Webmaster Tool 같은 걸로 분석해보면 “제목이 겹친다” 정도의 오류를 여럿 보고받게 된다. 그리고 페이지 랭크도 약간 불리하게 잡힌다고 한다.(중복페이지로 간주) “智熏님의 “페이지마다 타이틀 다르게 부여하기” 의 내용을 참조해서 수정하자
3. Footer.php — 레몬펜은 다행히도 플러그인 화해서 괜찮았는데, Daum Inside(다음에서 제공하는 방문자 분석툴)는 배포 문제 때문에 플러그인에서 빼놨더니 다시 넣어야 했다.
4. Related page 출력 — 관련 포스팅을 태그 정보를 기반으로 찾아주는 플러그인을 쓰는데, 이게 출력 위치가 참 애매해서 플러그인 출력으론 잘 안되더라. 그래서 내가 직접 위치를 찾아 삽입해준다. 이건 single.php 에.
5. 블로그 전체 탐색을 위한 하단부의 Prev/Next 링크 추가 — ipkn 이 알려준 덕분에 찾았음. 전혀 생각못하고 있었는데 이게 없는 페이지들이 좀 많다 -_-;; index.php와 single.php에 각각 추가
6. 대부분의 테마들은 여러가지 템플릿 페이지 — index.php, single.php, archive.php, archives.php, tag.php, category.php … — 를 제공한다. 여기서 논리적으로 겹치는 내용이 있을 수 있는데, 잘 설계되지 않은 테마는 두 곳을 모두 수정해야하는 경우가 왕왕 생긴다. 이런 것도 날짜 별 링크, 태그/카테고리 링크, 1개만 나온 페이지, 여러개가 나오는 페이지, 검색해서 나오는 페이지 … 등을 다 봐가면서 확인해줘야한다.

대충 이런 과정을 거치고 나면 이전 상태에 가까운 — 하지만 바꾼 테마니 맘에 들어야 – 테마를 쓰기 시작하게 된다.

사실 이 글은 워드프레스를 직접 손대지 않고는 못 견디는 프로그래머의 무언가 때문에 일거리가 늘어나서 쓴 것이니 너무 걱정(?)하지 않아도 좋은 말도 많다 ~_~

1월에 이사오면서 생각했던 것을 이제야 실행하기 시작.

어제 둔촌동 가서 자전거를 지르고, 오늘 아침부터 자전거 타고 출근하기 시작했는데, 대략 이런 코스로 가보고 있다 — 뭔가 테헤란로를 최대한 피해가는[...] 코스다.

 
Image from http://congnamul.com — 콩나물에서 캡쳐한 이동 경로

…좀 돌아가는 길이긴한데(특히 COEX랑 공항 터미널 사이로 가는 것이라거나, 아시아 공원 옆으로 가는 것), 횡단보도를 건너려면 저러는 수밖에 없어서 =_=.

자전거 이동 예상시간이 11분인데, 실제로는 대충 18분? 정도가 소요된다. 중간에 횡단보도를 총 9개 — 그 중 신호 받는 것은 7개 — 를 건너야하는데 이건 뭐 어쩔 수 없는듯. 자전거에 들어간 돈이 생겼으니 최소한 7개월 간은 자전거 출퇴근해야[...]

ps. 근데 18분정도 걸리긴해도, 출발/도착 정리 합쳐서 대충 5분 정도는 소모되는데 (=합이 23분), 버스타고 출근하는게 25분쯤 걸리니 시간 차이는 거의 없게되는 것 같다. 다만 버스탈 때의 불확실성은 좀 적고 -,-

에어컨

이사온 집에 에어컨이 없는데, 여름 대책은 사실 2개.

• 안사고 버틴다. 방도 넓어졌고, 회사에서 버틴다는 방법도 있고 (학부 4년간 했던 짓….)
• 에어컨을 산다 … 돈이 좀 -_-;;

회사에서 버티면 지금 AM 9 ~ PM 6:30 정도 회사에 있던 생활이 AM 8 ~ PM 11 정도회사에 있는걸로 바뀌어야하는데 -_-;; 그럼 스피커도 사용못하는 생활로 Orz

하지만 지금 사는 집에서 올해를 포함해서 2년 정도 있을텐데 에어컨을 사는 것도 좀 애매하고; 흠;

자전거

이건 산다 쪽으로 좀 기운 상태긴하지만 — 한 달에 교통비로 6만원 정도가 나가는데, 그 중 4만원 정도가 통근에 쓰이는 돈이고, 이걸 자전거로 대체하면 대충 유지비를 포함한 가격으로 28만원짜리 자전거라고 쳐도 올 해 안에 손익분기점을 돌파…

산다면 보통의 자전거를 살지 스트라이더 류를 살지도 생각해야; 스트라이더 류는 한 번도 안타봐서 보통(?)의 자전거(뭐라고 부르지?)를 살까하는 중인데; 스트라이더가 딱히 뭐가 더 편한지를 모르니 Orz

대충 요구사항이

• 평지에 가까운 삼성역(현대백화점 근처) — 신천역 통근
• 두꺼운 책(예를 들어 CLRS알고리즘 책 정도)이나 노트북을 넣고 다니기 편하면 좋겠고
• 잔 고장이 적은

정도면 뭐가 좋으지; 가격은 엄청 중요한 요소는 아닌데, 신천이 치안이 딱히 좋은진 모르겠어서 — 적어도 취객은 매우 많음 -_-;; — 너무 비싸면 잃어버리면 괴로울테니;

그냥 동전 던질까-_-;

ps. 하지만 난 왜 지금 고민하는게 아니라 위키백과(처음엔 자전거 종류를 보려는 목적) 들어와서 자전거의 역사, 자전거 출퇴근(각 국가별 성향 등등), 군용 사용, 자전거 경주 … 등을 쭉 보고 있는걸까  orz

지난 수 개월간의 page view (PV)

하지만 그 기간 동안 댓글은,

계속 읽기: “PV와댓글의 상관관계” »

이번 주에 프로그래밍 하면서 제일 괴로웠던 부분.

일종의 비동기 작업을 실행하는 class 가 있는데, 이 녀석을 test-framework 이랑 같이 쓰는 부분에서 문제가 산적 Orz.

DLL과 TLS 문제

사실 이건 비동기라서 터진건 아니지만, 내부적으로 사용된 Windows의 __declspec(thread) 선언이 테스트가 DLL로 링크되서 실행된다는 면에서 터져서 (원본이야 그냥 실행 바이너리지만…) 일단 테스트 방법 자체를 뒤집어 엎었고..

비동기 문제

연초에 테스트를 어떻게 할지 생각하면서 내린 결정 중에,

동기화 객체들은 테스트 프레임웍이 관리하고 / 싱글 스레드로 동작해도 옳은 결과가 나온다

라는 것이 있다.

비동기 실행(asynchronus execution)이란 것 자체가 이 가정을 거의 깨버린다. 지금은 일단 비동기 모듈과 닿아있는 부분이 매우 작아서, 테스트 프레임웍에서 수동으로 비동기 실행을 동기 실행으로 바꿔서 호출해버리고 있긴한데… 상당히 불편하다. "직접 호출해 줘야 한다"라는게 더더욱 -_-;;

Persistent Fixture

xUnit 류의 모든 테스트들은 기본적으로 다음과 같은 순서로 동작한다.

1. setUp() - 테스트 환경에 대한 초기화로 fixture 를 생성한다
2. Test() - 테스트 실행
3. tearDown() - 테스트 환경을 제거(?)한다. 즉 fixture 를 지운다

Fixture는 테스트가 끝나고, 다시 그 다음 테스트가 시작되면 완전히 새로운 초기 상태 로 돌입하는 걸 가정하는데, 이게 persistent 하면 깨지기 쉬워진다. 예를 들어 단순히 초기화만 테스트하고 다시 안만드는 식이라면, 이전 테스트가 비정상적으로 끝나면 그 이후의 테스트가 다 실패한다거나 (이번 주 수목 동안 겪은 문제) 해서 무진장 괴로워진다 -_-;; — 테스트가 오류를 특정 영역에서 난걸 잘 찾아줘야한다는 TDD의 목적 중 하나가 사라지니…

Fixture가 지속적(persistent) 하면 여러가지로 문제가 되는데, 특히 tearDown()을 정의할 수 없는 경우엔 상당히 문제가 크다. 테스트가 프로그램 자체를 손대는건 여러모로 좋지 않다 — 불확정성 원리와 비슷하게 관찰이 행동을 변경 시킬 수 있다.

이에 대해 xUnit Test Patterns에서 제시하는 해결책은 Test Double Pattern이란 것인데,

• 테스트마다 (각 테스트에 맞는) 반응(?)을 돌려주는 객체(test stubs)을 만들거나,
• 아예 해당 fixture가 만드는 부분을 mock-object로 만들어내거나,
• persistent 해보이는 부분을 재생성이 가능하게 고쳐라

라는 정돈데… 일단 다 건너뛰고(…) 캐야매로 tearDown()에서 일일이 제거하는 코드를 넣고,  setUp()에선 생성되어 있으면 재 초기화는 안한다… 정도의 느낌으로 바꿔놨다.

이건 UnitTest 레벨이니까 그렇다치고, component level 테스트들에선 슬슬 비동기성 있는 일부 모듈들 — 다만 해당하는 코드 패스가 적어서 아직은 괜찮지만 — 의 문제는 고개를 내밀고 있는듯하다. 다음 주 초에는 이 문제를 잘 생각해봐야겠는데 -_-;;

Microsoft VisualStudio 2005 / .net Framework 2.0과 함께 배포되기 시작한 빌드 유틸리티로 MSBuild란 녀석이 있다. MS의 악명높은(…) 커맨드라인 빌드 유틸리티인 nmake를 대체하려는 목적도 포함한 녀석이다.

뭐 이 얘기를 다 하려는 것은 아니고 내가 프로그래밍을 시작했던 *nix환경에는 make라는 command-line 툴로 대부분의 빌드 작업이 이루어진다. 그 기능 중에 하나가 suffix rule이란 건데, 파일 확장자를 보고 일련의 법칙을 따라 자동으로 빌드를 수행하는 녀석이다.

간단하게 C source코드를 컴파일하는 규칙 은 이런 식이다.

.SUFFIXES : .o .c .s
.c.o :
    $(CC) $(CFLAGS) -c $<
.s.o :
    $(AS) $(ASFLAGS) -o $@ $<

C compiler와 assembler를 써서 컴파일 하게 된다.

nmake에서도 되긴하지만(물론 make수준은 아님), nmake자체가 좀 부족한게 많고 MS 에서도 MSBuild를 권장하는지라 — 사실 nmake는 뭔가 제대로 된 빌드툴이 아니다. MSBuild 쯤은 되야 현대적인 빌드툴이 아닐까 -_-; make따라잡는데 너무 오래 걸렸다 — MSBuild로 비슷한 구현을 해봤다.

MSBuild에는 batching이란 개념이 있는데, 그 중 가장 간단한 구현으로, 다음과 같은게 가능하다.

<Project xmlns='http://schemas.microsoft.com/developer/msbuild/2003'>
  <ItemGroup>
    <TextFile Include='*.py'/>
  </ItemGroup>

  <Target Name='All'>
    <MSBuild Projects='build.xml' Targets='Reverse'/>
  </Target>

  <Target Name='Reverse' Inputs='@(TextFile)' Outputs='%(TextFile.Filename).rev'>
    <Exec Comand='python reverse.py @(TextFile)'/>
  </Target>
</Project>

오늘 회사에서 쓰는 코드 생성기 수정하다 나온 스크립트…의 변형판인데. 입력->출력으로 가면서 .py를 .rev로 바꾸고, 내용이 수정되는 그런 의미로 썼다. .suffix rule이라면 .py .rev 정도의 모양이 될 것이다.

그리고 .suffix rule 처럼 모든 python파일에 대해 동작하도록, ItemGroup과 Include문에 wildcard (*)를 사용했다. 그리고 Targets에 Inputs/Outputs attributed을 지정해 주고(batching), 이름이 바뀌는 규칙을 부여했다. 그리곤 실행해주면 끝.

실제 사용되는 빌드 스크립트는 원래 nmake기반이었는데, 경로 관리, 출력파일에 대한 의존성 정리같은게 너무 복잡해져서 (입력보다 출력이 좀 많아서 -_-;; ), 아예 python코드에 make의 시간 비교 기능을 넣어버리고 MSBuild의 batching 으로 Exec task를 만들고, 이걸로 python을 실행하게 했다..

Python 코드에 make의 기능 일부가 중복되서 들어간건, 출력이 더 많아서였는데(덕분에 nmake가 너저분한 코드로), 이걸 python에 살짝 떠 넘기고, suffix 규칙 비슷한걸 흉내내서 상당히 간단하게(위 xml 설정이랑 거의 똑같음) 만들어낼 수 있었다.

MSBuild는 올해 초에야 제대로 쓰기 시작한 거 같은데, 이 작업으로 nmake기반의 빌드는 다 없어진듯… 다만 문서화는 아직 .bat인데, 이건 아직 안복잡(?)하니 천천히 신경써야지;