요즘 어떻게 지내시나요?

[Joon Soo Kang]

어느정도 예상은 했지만, 개강하고는 이러저리 정신이 없네요.
특별히 바쁜 것도 없는데, 왜 이렇게 시간은 잘 가는지...

며칠 동안 집에서 irc 서버 세팅 시도했지만 계속 실패했어요.
집에 myLG070 인터넷 전화를 쓰는데, 포트포워딩이 제대로 안 되는지...
근데 오늘 종텐 님 미투를 통해서 웹irc 서비스 되는 곳이 있다는 것을 알았어요.
없다고 들었는데, 괜한 삽질만 했네요.

오늘부터 다시 열심히 달려야겠네요.
종텐 님도 개강해서 이것저것 바쁘실거 같고,
민희 님은 오늘 야근이신거 같네요.
우승 님은 몸이 좀 나아지셨는지요?


--
blog - http://xpkang.tistory.com/
me2day - http://me2day.net/xpkang/

[Hong MinHee]

네, 저는 요즘 회사 일이 좀 바쁘네요. 적어도 다음주까지는 계속 야근을 해야할 것 같습니다. 우승 님은 퇴원하셨다고 하네요.

저처럼 IRC 죽치고 있지 않는 이상 인클 웹 IRC 정도가 적절하죠. 처음에 알려드렸던 것 같은데 전달이 잘 안됐나봐요.

2009년 3월 5일 (목) 오후 3:14, Joon Soo Kang <joonso...@gmail.com>님의 말:

[jong10]

죄송합니다. 중요한 일이 생겨서, 토요일에 못나갈 것 같습니다.

일요일에 뵙겠습니다.

[jong10]

3월 8일 일요일에 모임 하나요?

[Joon Soo Kang]

사실 제가 이번 주에 어떤 진척도 하지 못해서 주말에는 좀 더 집중할 시간을 가지는게 좋지 않을까 합니다.

어쩌면 반대로 오프라인으로 만나야 좀 더 진척을 할 수 있을 것 같기도 하고요.

일단 저는 이번 주는 진행할 시간을 가졌으면 좋겠습니다.

이동 간에 시간 소모가 커서요.

그리고 다음 주는 금, 토, 일 모두 제가 서울 가서 적당한 모임 장소에서 계속 진행했으면 좋겠습니다.

이 부분에 관해서 어떻게 생각하시는가요?

2009년 3월 7일 (토) 오후 12:38, jong10 <jon...@gmail.com>님의 말:

3월 8일 일요일에 모임 하나요?

[Hong MinHee]

저도 이번 주말에는 집에서 작업을 하고 싶네요. 다음 주말은 어떻게 될지 잘 모르겠는데 적어도 하루 정도는 시간을 낼 수 있을 것 같습니다.

2009년 3월 7일 (토) 오후 5:20, Joon Soo Kang <joonso...@gmail.com>님의 말:

[김우승]

예... 저는 그간 죽고 살았습니다. 오늘은 낮동안 내내 죽어 있었고요.

내일 만남에 대한 이야기는 말 안하셔도 아시리라 믿습니다... (T.T)

2009년 3월 7일 (토) 오후 5:25, Hong MinHee <m...@dahlia.pe.kr>님의 말:

[김우승]

여전히 죽고 살고 있는 중입니다. 많이 좋아지긴 했는데... 아직은 좀 그렇군요.

어제는 아무 것도 안 했었고...

 

예전에 제가 정리해서 보냈던 e-mail의 Resource 구조에 대해서 오류가 있습니다. 홍민희님과는 이미 이야기를 해뒀는데...

setattr 부분에서 제가 제대로 Python의 특징을 파악해두지 않았더군요. 저는 class 정의에서 self.a = ...는 그냥 객체 member a가 될 거라 생각했는데 이것도 setattr을 호출하더군요. class 정의 내에서도 self.set_member(...) 형태는 기존의 Python 형태를 너무 무너뜨리기에 결국 제 생각은 Resource 구조를 따라갈 때는 그냥 첨자 연산자 "[...]"를 쓰자는 것으로 정리됩니다. setattr은 전혀 그런 동작을 하지 않는데 getattr에서 객체 member가 없을 때 Resource member로 생각하는 것은 너무 일관성이 없는 것 같아 이것도 포기입니다. 그런데 홍민희님은 자신이 생각해뒀던 것과는 다르다고 해서 일단 손을 놓은 상태입니다. 첨자 연산자를 쓰자는 것이 "놀라운 생각!"이라고 말하긴 했습니다만 어떤 형태가 될지는 모르겠군요. CherryPy는 이름충돌문제를 회피하는 기법을 FAQ에 기술하고 있습니다만 완전히 회피하는 것은 아니기에 별로 맘에 들지는 않습니다. 물론 첨자 연산자를 쓰는 것도 기존의 attribute 연산자를 쓰는 것에 비해 보기 좋지는 않습니다만 제 생각은 이 형태가 그래도 가장 좋다고 보고는 있습니다. 하여간 홍민희님이 자신의 생각을 정리해서 message를 보내겠다고 하셨으니 기다리고 있는 중입니다.

 

현재 저는 Request의 URI 부분을 공부하고 있는 중입니다. 절대경로(path)만이 아니라 절대URI도 가능하다고 RFC에 나와있기에(아마도 proxy를 위한 것으로 보입니다.) 고민 중이고요. 그리고 질의문자열에 대해서 어떻게 처리해야 하는지도 고민하고 있습니다. 홍민희님 말대로 URI 질의와 message 본문질질의는 통합되어야 한다고 생각합니다만 그  interface에 대해서 고민하고 있는데요. 현재는 def get(self, request): ... 형태가 좋을 것 같다고 생각합니다. request에 다양한 정보가 포함되어 있을테고 그걸 활용할 수도 있고, 중요한 질의는 request.query["..."] 형태가 좋은 것 같고요. 그 의외 request를  통해 pretty URL 처리 등을 위하여 /blog/post/1 일 겨우 post가 중간에 처리를 할 때 뒤의 1을 처리하기 위하여 requeset.path.back_component 정도를 생각하고 있습니다. 이 부분은 web.py를 참고하려고 합니다.

 

최종열님. 협상 header의 best_match를 max를 사용하는 형태로 바꿨습니다. max가 key를 판단하는 함수를 받아들일 수 있게 되어 있더군요. 아직 commit, push 하지 않으셨기에 말씀드립니다. 제가 commit, push할 때 충돌할테니까요.

 

할게 많은 것 같네요. 그간 standup 회의를 가지지 않았기에 이렇게 message를 보냅니다. 강준수님 금토일 만나자는 것은 좋은데 다른 분들이 어떤지 모르겠네요. 특히 금요일은 홍민희님과 최종열님 두분다 어려울 것 같네요.

[Hong MinHee]

금요일에 제가 곤란하다는 것은 어떻게 아시고... 흐흐; 수정된 사항은 일단 푸시해주세요. (체인지셋 선물보따리를 준비하진 않으셔도 됩니다. ;)

back_component에 관한 얘기인데, 전에 말씀드렸다시피 우리가 API 수준에서 이전 컴포넌트를 참조하는 것까지 제공할
필요는 없다고 봅니다. 오히려 그렇게 되면 객체간 의존성이 높아져서 웹 애플리케이션 단위의 테스트를 할 때도 신경쓸 게
많아집니다.

class Blog(Resource):
def __getattr__(self, post_id):
return Post(id=int(post_id))

class Post(Resource):
def __init__(self, id):
self.id = id

이 정도 수준으로 전달 가능하니 기존 설계에 크게 문제는 없다고 봅니다. 반대로 웹 애플리케이션이
request.path.back_component를 참조해서 프로그래밍을 하도록 유도한다면, 테스트를 작성할 때는 메서드만
호출하는 게 아니라 적절한 back_component를 가지고 있는 가짜 request 객체를 만들어서 함께 줘야하기 때문에
문제가 있습니다.

자세한 이야기는 별도 쓰레드로 논의하는 것이 좋겠습니다.

2009년 3월 10일 (화) 오후 5:06, 김우승 <lohas...@gmail.com>님의 말: