비슷한 글에는 비슷한 친구들이 댓글을 달까?

인터넷에서 글을 쓰다보면 “왠지 이 글에는 누구 누구가 댓글을 달겠구나.”하고 느낌이 강하게 올 때가 있습니다. 글 올리고 나서 열심히 10분마다 리프레시 하다가 (;;;) 누가 댓글을 딱 달면 “역시 낚였구나!” 하기도 하고.. -ㅇ-; 그렇다면 댓글을 누가 썼는지만 봐도 대략 글 내용을 추정할 수도 있지 않을까요? 그래서 오늘은 미투데이에서 댓글 쓴 친구 목록만 가지고 비슷한 글끼리 묶고 각 친구들의 성향을 분석해 봤습니다. (이제 점점 무슨 인터넷통계 블로그로 변신을 –;)

분석대상은 여러가지 요인들을 고려할 볼 겨를도 없이 그냥 한국 IT블로그계의 여왕벌 이지님의 최근 2달 글로 했습니다. ? (미리 이지님과 댓글을 쓰신 친구분들께 양해를 구하지 못한 점 죄송합니다~)

분석 과정

우선 가설은 “비슷한 글에는 비슷한 친구들이 댓글을 단다.”로 세웠습니다. 그 후의 분석과정은 생략하고 Orange의 플로우 그림으로 대체합니다. 최초 입력은 친구가 각각 해당 글에 댓글을 썼는지 여부를 0/1로 표시한 큰 행렬에서 몇 종류의 노이즈를 제거했습니다.

댓글 경향 분석 과정 (Orange)

비슷한 댓글을 다는 친구 묶음

이렇게 해서 나온 결과로 각 친구들끼리 얼마나 비슷한 글에 댓글을 달고 있는지를 보여주는 다음 그림이 나왔습니다.

비슷한 댓글을 다는 친구 클러스터
큰 그림

비슷한 경향의 친구들끼리 같은 클러스터(색깔)로 묶였는데, 파란색(1) 묶음은 다른 묶음에 비해 다양한 친구들이 묶여있고, 다른 묶음들은 각기 독특한 경향이 있습니다. 위 그림은 7가지 글에서 댓글을 달았는지 여부를 가지고 각 친구들 경향을 눈으로 잘 보이게 그림으로 그린 것인데요. 각 글(회색점, 글 내용은 흰색 네모)에 댓글을 쓴 경우에 점에 가깝게 표시되어 있습니다. 14, 39번 글에 파란색 친구들이 많이 몰려있고, 83번 글에는 빨간색 친구들이 많이 몰려 있습니다.

파란색 친구들은 대체로 누구나 쉽게 글을 달 수 있는 글에 댓글을 단 경우가 많았고요, 빨간색, 초록색 친구들은 각기 독특한 성향이 있었는데, 윗 그림에서는 잘 나타나지는 않았지만, 빨간색은 학술적인 글이 많이 포함되어 있었고, 초록색은 친한 친구들이 댓글을 달 만한 글들이 많았던 것 같네요.

비슷한 친구들이 댓글을 다는 글들의 묶음

실제 위에서 나타난 친구묶음들의 분포를 기준으로 다시 글의 분포를 구성해 보면

비슷한 친구들이 댓글을 다는 기준으로 글을 분류

그림이 글을 표시하기는 좀 빽빽해서 각 친구묶음들이 선호하는 글의 대표적인 사례 몇 가지를 뽑으면 이렇습니다. (전체 텍스트 목록)

친구묶음 1(파란색)이 좋아하는 글
친구묶음1 친구묶음2 친구묶음3 친구묶음4 댓글수 내용
0.64 0.20 0.25 0.00 44 <다찌마와 리> 시사회 티켓 득템~♬ (근데 너무 바빠서 갈 수 있을지…)
0.43 0.20 0.00 0.00 87 (삼계탕 말고) 보양식으로 무엇이 있나요?! 몸이 좀 허해진 것 같아서… 내일 좀 챙겨먹으려구요.
0.36 0.20 0.00 0.00 27 (집에서는 커피 금지령이 내린 관계로) 밤샘 작업을 위해 할 수 없이 커피를 사왔는데, 이렇게 맛이 없을 수가… 야식 배달 전문점 말고, 밤샘 커피 배달 전문점이 있다면 얼마나 좋을까…
0.14 0.00 0.00 0.00 46 이제 미투사무실 왔어요~♥
친구묶음 2(빨간색)이 좋아하는 글
친구묶음1 친구묶음2 친구묶음3 친구묶음4 댓글수 내용
0.00 1.00 0.00 0.17 40 미투데이 사례로 논문 쓰려니 힘들어요. 왜냐구요?! 자료가 너무 없어~ 조만간 미투 사무실 습격해야겠다~ 요구하는 정보 다 내놔라!
0.14 0.40 0.00 0.00 33 어떤 논문에서, “(…) frequent IM users tend to exchange shorter messages over a longer period of time, and they are more likely to engage in multitasking.”
0.07 0.40 0.00 0.17 24 어떤 논문을 보니, dodgeball 창업자는 자사 서비스에 대해 “facilitating serendipity”라고 말했더라. 이 대목에서 난 너무 웃었다. 이쯤되면, 만박 님도 한말씀 하셔야죠? 미투에 커플이 몇인데! ^-^
0.07 0.40 0.25 0.00 21 한국언론재단의 2008년도 수용자 의식조사에 따르면, 매체 영향력 및 매체신뢰도 조사 결과가… 1위 KBS, 2위 MBC, 3위 NAVER라고. (오늘 각각 1위부터 10위까지 봤는데 좀 놀라웠어요. 조사를 어떻게 했는지…)
친구묶음 3(초록색)이 좋아하는 글
친구묶음1 친구묶음2 친구묶음3 친구묶음4 댓글수 내용
0.14 0.00 0.75 0.17 48 어제 득템한 노트북~ 잘되네~♬
0.07 0.20 0.75 0.00 22 무언가를 반드시 쟁취하고자 하는 욕망, 이라는 것이 없는 사람.
0.14 0.20 0.75 0.00 37 A Grammar of the Multitude. 나에게는 이 책이 두 권 있다. 나머지 한 권으로 무엇을 하면 좋을까~?!
0.07 0.00 0.50 0.00 9 시간은 왜 항상 부족할까…
친구묶음 4(주황색)이 좋아하는 글
친구묶음1 친구묶음2 친구묶음3 친구묶음4 댓글수 내용
0.00 0.00 0.00 0.50 17 이 책을 편의점(!)에서 파는 것을 보고, “이 정도로 베스 트셀러야?!”하며 경악했던 적이 있는데. 정말 많이 팔렸구나. 울 엄마 말씀으로는, 외숙 모들도 다 읽으셨단다. (엄마도 요즘 읽고 계신다…)
0.00 0.00 0.00 0.50 19 1976년 생인 이 책의 저자는 도쿄대학교 대학원 박사과정을 “수료 후 자퇴”했다. 꾸준히 논문과 저서를 발표하고 있고, 박사논문을 포기할 상황도 아니고, 후속 연구도 정했고, 다른 직장으로 외도한 적도 없고, 지도교수와의 관계도 좋은데… 왜?!
0.57 0.00 0.50 0.83 68 2년 동안 함께 만든 책인데, <문화관광부 우수학술도서>로 선정되었어요!!! 글 쓰고, 편집하고, 섭외하고… 열심히 뛴 보람이 있구나~ㅠ_ㅜ ( “보람”이라는 단어는 이럴 때 쓰는 건가봐~)
0.14 0.00 0.25 0.50 24 이 책의 원제는 [불안형 내셔널리즘의 시대]. 그런데 역서 제목이 이렇게 뽑혀버려서~ 마치 가벼운(!) 시사평론집처럼 느껴진다. (사실은 그렇지 않 은데~ 한번쯤 읽어봐도 괜찮은 책인데~ 주위에서 이 책 구입한 사람 나밖에 없어~ㅠ_ㅜ)

각 친구묶음의 각 글에 대한 경향

위 결과에서 보면, 2, 4 묶음은 비교적 뚜렷한 경향이 있는데, 1과 3은 아주 눈에 띄지는 않습니다. 그래서, 각 친구묶음이 다른 친구들이 더 좋아하는 글들에도 댓글을 쓰는 경향이 얼마나 되는지 봤습니다. 즉, 자기 취향의 글에 대한 일편단심 충성도(?)라고 볼 수도 있겠죠.

친구묶음들이 각 다른 취향의 글에 댓글을 다는 경향

이렇게 보면 뚜렷하게, 첫번째 묶음 (파란색)은 뚜렷한 경향없이 평균적으로 모든 취향의 글에 댓글을 달고, 다른 친구묶음의 친구들은 뚜렷한 취향을 가지고 “책 관련 된 글” 또는 “행사/학술 관련된 글”에만 댓글을 달고 있다는 것을 볼 수 있습니다. (그래프의 수치는 해당 친구묶음 내의 관련 글묶음 댓글 빈도 %) 그리고, 또 특이한 것은 파란색과 초록색은 모두 일상생활 또는 사적인 감정에 대한 글들 취향이었는데, 초록색은 누구나 댓글을 쉽게 다는 파란색 취향에는 오히려 댓글을 더 적게 달았군요. ^^;

정리

대략적으로 가설에서 세웠던 것대로, 적지 않은 친구들이 뚜렷한 자기 취향을 갖고 관심 글에만 댓글을 달고 있다는 것을 확인할 수 있었고요, 이를 토대로 댓글을 단 친구의 구성만 봐도 대략적인 글 내용이나 성향을 파악할 수 있다는 것을 알게 되었습니다.

사실 뭐 누구나 이미 감으로 알고 있는 것이지만.. 그냥… 진짜 그런지 확인해 보고 싶었어요 ^^;;

덧붙임: 여기서는 k-means clustering과 빈도수 샘플링 같은 간단한 것들만 사용했는데, 실제로 이 모델을 제대로 묘사하려면 MCMC EM같은 숨은 확률을 반영할 수 있는 도구를 써야할 것 같습니다.Watch Full Movie Online Streaming Online and Download

파이썬마을 페차쿠차 – 파이썬 경험 나누기

얼마 전에 파이썬 마을 모임에 대한 얘기를 올리고 많은 분들이 관심을 보여 주셨는데, 제가 한동안 재미있는 삶에 빠져서 놀다가 깜빡해서;;
좀 정리를 해서 구체적인 일정을 정했습니다. ^_^

멍하니 있으면 순식간인 단 48분 만에 다른 12명의 파이썬 경험을 압축해서 빨아들일 수 있는 기회!

지난 번 댓글에서 파이썬에 처음 입문하시려는 분들도 많은 관심을 보여주셨지만,
아무래도 이번에는 경험공유에 강조하기로 했기 때문에, 경험만 알짜배기로 모아서
얘기를 하는 쪽으로 하고 다음에 또 다른 좀 더 큰 모임에서 튜토리얼 섹션 같은 것을
마련하는 쪽으로 마음 먹었습니다. 조만간 꼭 하겠습니다~ 🙂

참가 신청은 온오프믹스에서 모레 (수요일) 부터 받을 예정입니다.

모임의 주제는 “나는 파이썬을 이런 데 쓴다!”이고, “참가자 모두가 발표해야합니다.” 발표의 내용은 경험을 나누는 것이 주가 되며, 기술적인 상세사항이나 기술 자체에 대한 것들은 되도록이면 지양합니다. 참가 신청에 발표 제목을 꼭 표시해 주세요.

  • 일시: 8월 22일(금) 오후 7시 – 삼성동 미지리서치 본사 2층 회의실
  • 신청 기간: 8월 13일(수) 오전 10시 ~ 8월 18일(월) 오전 10시 (12명)
  • 참가대상: 파이썬으로 뭔가를 작업해 본 경험을 나누고 싶으신 분
  • 참가비: 없음 (저녁식사 제공되지 않음, 얼음물/아이스커피믹스 무한제공 ^^)
  • 모임은 모두 한국어로 진행됩니다

발표 주제의 예:

  • 나는 파이썬을 일상 생활에 사용한다.
  • 휴대전화기에 올라간 파이썬
  • 우리 온라인 게임은 서버가 파이썬으로 되어 있어요.
  • 알고보면 기상예보 파이썬으로 한답니다. (쿠당~)
  • 우리 아기 교육은 파이썬으로: 동요 따라부르기, 숫자 놀이
  • 우리 회사 서버는 파이썬을 지우면 대형사고가 난답니다.

발표형식은 경험 공유를 하다가 따분해질 수도 있기 때문에, 디자인계에서 많이 사용하는 발표형식인 “페차쿠차“를 차용했습니다.

  • 모든 발표는 슬라이드(파워포인트, 키노트, pdf 등) 12장으로 구성돼야 합니다.
  • 각 슬라이드는 20초가 지나면 발표자의 의지와 상관없이 자동으로 넘어갑니다. 되돌아갈 수 없습니다. -> 20초 * 12장 = 4분
  • 자동으로 넘어가는 것을 감안해서 슬라이드는 간결해야하고, 모임 목적이 경험 공유이기 때문에 구체적이기 보다는 개괄적이고 재미있는 경험 위주로 구성해 주시면 좋습니다. (보통은 그냥 관련 그림만 말 순서대로 쭉 붙여 넣으시면 됩니다.)
  • 발표 자료는 모임 일자 이틀 전에(8월 20일 밤 11시 59분까지) 모임 주최자에게 보내주셔야 합니다.
  • 생각보다 20초에 맞추는게 만만치 않기 때문에, 미리 연습해 보시고 오시는 것이 다른 사람들과 경험을 효과적으로 나누는 데 좋습니다. ^^

그럼 전국의 파이썬 강호 여러분을 많이 뵈었으면 좋겠네요!

파이쿠차 -오랜만의 파이썬 마을 모임!

다음 주(7월 27일-8월 2일)에 오랜만에 애자일 개발 워크샵 일로 1주일 동안 서울에 머물게 됐습니다. 그래서 서울 방문 기념으로 거의 1년 만에 파이썬 마을 모임을 한 번 하려고 합니다.

지난 번에 다른 행사의 부대행사로 파이썬 관련 세션을 하나 생각하면서, 자기가 파이썬을 쓰는 분야에 대해서 얘기하고 토론하는 걸 좀 생각해 봤었는데요. 최근에 페차쿠차라는 걸 보고 한 번 “내가 파이썬을 쓰는 곳/파이썬으로 만든 것“을 페차쿠차 형식으로 한 번 해 보면 어떨까 생각했습니다.

페차쿠차는 발표 포맷이 정해져 있는데요, 슬라이드 20장을 각 20초 씩 해서 총 6분 발표를 해야합니다. 보통 많은 사람들이 발표하는 곳 가면 거의 반 정도는 발표하는 사람을 제발 끌어내리고 싶은 유혹을 받는데 그런 걸 줄이기 위한 포맷이라고 하네요. 그래서 이번에는 20장은 보통 엄청 오래 한 분 아니라면 회사 기밀까지 나와야할 것 같아서, 12장 * 20초 해서 4분으로 하면 좋을 것 같네요. 중요한 것은 슬라이드는 자동으로 넘어가니까 한 슬라이드에서 시간을 마음대로 조절해서 쓸 수는 없다는 게 페차쿠차의 기본 원리라고 합니다. (다양한 분야에 활용하시는 분들이 참석하셔서 경험을 나누시면 좋겠습니다!)

혹시 장소나 시간에 대해서 좋은 생각이나 제안 (또는 장소제공) 등 남기실 말씀이 있는 분들은 알려주세요. ^^ 대략 인원 추산도 해야하니 참석하실 수 있는 분들 답글 남겨주시면 고맙겠습니다~

인스턴스 복사를 직접 다루기

종종 한 인스턴스를 대량으로 복제해서 약간씩 바꿔야할 일이 있습니다.
주로 진화 알고리즘 계열이나 고치기 전/후를 비교해야하거나, 엄청나게 바꾼 뒤에
롤백을 해야한다는 등의 경우가 그런데요.
파이썬에서 복사는 기본 타입들은 각각 독특한 방법이 있지만, 보통은
copy모듈을 쓰면 간단합니다.

그런데 철학적(?)인 분위기를 잡으며 경험이 조금 더 많은 사람이 쓱 나타나서
“너 깊은 복사랑 얕은 복사 알아?”라고 할 것 같은 느낌이 언제나 copy
쓸 때마다 들곤 하죠; 깊은 복사(deep copy)는 참조하고 있는 객체 모두를
복사하기 때문에 속성으로 들어있는 놈들까지 별개의 인스턴스가 돼서
완전히 떨어집니다. 얕은 복사에서는 참조는 복사하지 않고 자신만 복사하기 때문에
리스트같은 것들이 공유가 되는 특징이 있습니다. 물론 얕은 복사가 훨씬 빠르고
자원을 효율적으로 쓰겠죠.

그런데 종종 클래스를 만들다 보면 어떤 것은 깊숙히, 어떤 것은 얕게 해야할 일이
발생하는데요. 그러면 copy.copy를 쓸 수도 없고 copy.deepcopy를 쓸 수도 없고
애매한 상황이 됩니다. 결국은 얕은 복사를 한 다음에 수동으로 깊은 복사를 해 주면
되겠죠. 그래서 좀 더 복사 과정을 자세히 다뤄보도록 하겠습니다.

우선 복사를 하려면 인스턴스를 새로 하나 만들어야 합니다. 여기서 발생하는 문제!
__init__가 호출되면 복사라고 부르기가 애매하겠죠. 이미 초기화된 놈을 다시 초기화하게 되니까..
그래서 __init__는 호출하지 않고 그냥 객체만 생성하는 방법을 써야하는데,
신형 클래스(new style class)냐 구형 클래스(old style class)냐에 따라서 방법이 다릅니다.

신형 클래스는 __new__를 쓰면 됩니다.

구형 클래스에서는 types.InstanceType을 쓰거나 types 모듈 불러오기가 귀찮으면 type(s)
써서 만들 수 있습니다.

그래서 일부만 복사하는 놈을 만들어 보면

이렇게 a는 복사되고, b는 공유되는 방식 copy()를 만들 수 있습니다.

사실 파이썬 자체에서 pickle 모듈같은
곳에서 저장/복원을 위한 속성 저장법이 있는데, copy
모듈도 같은 방법을 지원합니다.

__getstate____setstate__ 중 하나만 구현해도 상관은 없는데 그렇게 하면 리턴값이나 받아오는
값이 모두 딕셔너리가 돼야합니다. 위에서는 a는 그대로 참조만 가져오고, bc는 복사하는
방식으로 클래스 복사 방법을 지정해 줬습니다. 복사와는 크게 관련은 없지만 pickle에서
저장할 수 없는 속성들 (예를 들어 소켓 같은 것)이 들어있는 클래스는 __getstate__를 지정해 주는
방식으로 특정 속성을 저장에서 뺄 수 있습니다.

파이썬 3의 한글

따로 말은 필요없고 직접 예제로!

캬~~

관련 참조:

“파이썬은 멀티코어 줘도 쓰잘데기가 없나요?”에 대한 파이썬 2.6의 대답

바야흐로 초딩도 멀티코어로 오락하는 시대가 오면서 이제 파이썬 GIL 공포가
많은 사람들을 위협하고 있었습니다. 그에 대한 해결책으로 예전부터
병렬 프로그래밍을 위한 여러가지 프레임워크, 예를 들어
MPI, CORBA, PyRO 같은 것들이 나왔지만, 다들 멋있게 모든 걸 포용하는
라이브러리를 만들다 보니 설치가 어렵거나 배우는데 한참 걸리는 게 결국 문제가
돼서 실제로 심각한 개발자 아니면 그냥 “CPU 1개면 충분해요”라고 눈을 반짝거리며
스스로 최면을 걸고 있었던 것이 사실입니다~

그래서 GIL의 파이썬 프로젝트 자체에서의 해결책으로는 공식적으로 결론에 도달한
것은 아니지만 Adam Olsen의 GIL없애기 프로젝트 같은 것도 있었는데,
이번에 몇몇 사람들의 강력한 후원으로 파이썬 2.6과 3.0부터
pyProcessing이 새 이름 multiprocessing
으로 표준 라이브러리로 들어오게 되었습니다.

pyprocessing의 다른 병렬 처리 라이브러리들에 대한 장점은
뭐니뭐니해도 표준 threading 모듈과 API가 같다는 점이겠죠. threading으로 기존에 짜 놓은
프로그램을 그냥 모듈 이름과 클래스 이름 아주 약간만 바꿔주면 쓰레딩 대신 멀티프로세싱을
사용하게 되어서 결국에는 멀티코어를 제대로 쓰는 프로그램이 됩니다. 실제로
쓰레딩같이 모든 변수를 공유하는 것은 아니고, 리턴값만 전달을 받기 때문에
정확히는 좀 다르다고 볼 수도 있지만, 뭐 “그렇게 짜면 왕변태”라고 선언하면 되겠죠. ㅎㅎ;

그래서 실제로 쓰는 모양을 보려고 옛날에 유행했던 정규식으로 소수 검사를 하는 걸 한 번 돌려 봤습니다.

보시면 threading으로 만든 모듈과 join, start, worker 등의 사용법이 같아서 그냥 쉽게 바꾸실 수 있는데, 이렇게 돌려보면 대략 시간이 듀얼코어에서는 이렇게 나옵니다.

대략 2배 정도 빨라졌죠~ 그냥 고전적인 던져주고 실행해서 리턴받는 방식 말고 보통
실제로 더 많이 쓰는 Queue 모델로 일꾼을 코어 개수만큼 돌려보면 이렇게 할 수도 있습니다.

시간은 대략 9초 정도 듭니다. 그리고 fd 넘겨주기를 지원하는 플랫폼들에서는 소켓도
받아다가 넘길 수가 있으니 네트워크 프로그램도 간단하게 멀티코어를 쓸 수 있습니다.

아주 간단하게 멀티코어를 쓸 수 있는 장점으로 표준 라이브러리로 도입이 되긴 했지만,
아직 문제가 몇 개 있는데요. 대표적으로 FreeBSD에서는 아직 POSIX 1003.1b 세마포어를 “제대로” 지원하지 않기 때문에 FreeBSD에서는 Queue나 Lock등과 관련된 것들을
하나도 쓸 수가 없습니다. (위 예제는 그래서 리눅스에서 테스트할 수 밖에 없었습니다;;)

그 외에 MPI 등의 “심각한” 분산 API들을 쓰던 프로그래머들은 이게 애들 장난이냐 하면서 없는 기능들을 지적할 수도 있는데, 아무래도 표준 라이브러리로써 아주 간단하고
기초적인 기능만 제공하는 것이 목적이고, 셋업이 복잡하거나 거대 프레임워크를 끌고 다니는 경우라면 표준에서 안정적으로 관리하기가 힘들겠죠. 그래서 multiprocessing을
도입하자 주장한 개발자는 이 모듈은 절대 다른 분산 관련 모듈을 쓰지 말라는 의미가 아니고
같이 쓰면 더욱 좋다고 강조합니다.

파이썬 매킨토시 한중일 코덱

한동안 CJK 코덱은 잊고 살았는데, 올해 초에 엉뚱하게 코덱 관련 버그가 하나 떨어졌습니다.
X-MAC-JAPANESE 코덱이 없다고 하면서 파이썬 설치가 안 돼요
라는 현상인데.. 파이썬 3.0에서는 빌드할 때 잠깐 빼고는 유니코드 코덱 없이는 소스 읽기 조차 안 될
정도가 됐기 때문에 시스템 설정에 있는 기본 인코딩이 안 맞으면 설치도 안 되고 잘 뜨지도 않는
현상이 발생된 것 같군요. 아니 무슨 90년대 유물인 MacJapanese가 아직 디폴트인지는 이해를
못하겠지만 말이죠;;

그래서 찾아보니까 다른 오픈소스 유니코드 관련 프로그램들은 전혀 지원하고 있지 않았지만,
펄이 유독 지원하고 있길래 어쩔 수 없이 펄보다는 나아야지 하는 오기로 (;;) 코덱 작업을 했습니다.
으흐 -ㅇ-;

CJK와 관련된 것은 MacKorean MacJapanese MacChineseSimp MacChineseTrad 이렇게 4가지인데
윈도우의 cp949 cp932 cp936 cp950과 마찬가지로 각각 euc-kr shift-jis gb2312 big5
확장한 방식입니다. 그런데 확장을 MS보다 더 기상천외한 방법으로 유니코드 스펙을 최대한 활용한 덕에
이런 매핑까지도 등장합니다.

2바이트짜리 글자 하나를 무려 유니코드 5글자에 매핑을 하는 데다가, JIS X 0213에서 주로 많이 써서 골탕을 먹였던 중간에 잘라먹어도 말이 되는 글자들이 등장합니다.

이런 경우에는 U+0031이 오면 0x31 한 글자, U+0031 U+20DE가 와도 0xA542 한 글자, U+0031 U+20DE U+F87B가 오면 0xA341 한 글자가 돼서 유니코드 1~3글자까지가 모두 다 2바이트가 돼버립니다.
그냥 단순 문자열에서는 별 문제가 없지만, 스트림 입출력 트랜스코딩에서는 이거 때문에 아주 미칠 지경이죠. 어흐흐;

그래서 그냥 C 코덱으로 매핑 덮어쓰기로 만들려니 너무 따분하고 이제 아무도 안 쓰는 인코딩 만들어 봐야 뭐하나 하는 생각에 예전에 생각해 뒀던, 딕셔너리 2개만 뿅 하고 던져주면 매핑 테이블을 덮어써서 새로운 코덱이 되는 방법으로 해 봤습니다. 예를 들어서

이렇게 해 주면 codec에 유니코드 a는 euc-kr에서 b로 인코딩해버리고, 유니코드 b는 모르니까
인코딩 안 해 준다고 에러내는 코덱이 나오게 됩니다. 이걸로 역슬래시 같이 논란이 있는 부분이나
용도에 따라서 좀 다르게 써야하는 만들어서 쓸 때 유용하지 않을까 생각해 봅니다~ -ㅇ-;

단, 이게 내부적으로 한 글자씩 조절을 하다보니 굉장히 비효율적이라 속도가 그렇게 빠르지는 않은
편이지만.. 그래도 요새 컴퓨터가 워낙 좋으니까.. ^_^;;

혹시 맥에서 파이썬 빌드가 잘 안 되셨던 분들은 패치를 받으셔서
한 번 해 보세요~ (아마도 별 문제가 없으면 파이썬 2.63.0에 들어갈 수 있겠죠. 펄보다는 나아야지.. ㅎㅎ;;;;;;;;;;;)

오픈룩에는 어떤 전공 사람들이 올까?

얼마 전에 친구와 얘기하다가 “내 홈페이지는 아무래도 전산과만 오지 않을까~?”라는 말을
했었는데, 그 후에 과연 진짜로 전공 분포가 어떻게 되는지 궁금해졌습니다. -ㅇ-;

그래서 간단하게 조사해 볼 수 있는 방법을 궁리해 보다가, 대전의 모 학교 내부 접속자들은 IP만 가지고도
건물 위치를 알 수 있기 때문에 웹서버 접속 로그에서 학교 건물 이름으로 전공을 추측하는 게
가능해서 그걸로 소집단이나마 해봤습니다. ^^;

전공별 접속 통계

위 그래프에서는 요청횟수가 나타나 있는데, “내 이름 어때”
최근 접속자에서 많은 부분을 차지하고 있기 때문에 별도로 분리해서 봤고, css, jpg등 부속적으로
따라오는 파일들은 제외하고 순수한 문서 요청만 셌습니다. 기간은 6월 1일부터 오늘까지 18일간이고요~
역시 전산과가 굉장히 많은 부분을 차지하는데, 의외로 전자과도 꽤 많습니다. 아무래도
내 이름 어때에서 넘어온 게 아닌가 추측이 되는데, 학부(주로 기숙사)에서는 내 이름 어때
요청만 굉장히 많은게 역시 학부생들 간의 유행 URL 전달이 대학원생들보다 활발한 것 같군요.

다음으론 요청수 말고 IP별 접속자 통계인데요. 접속자(unique visitor)에서 날짜별로 다른 날에
접속한 경우 별도 방문으로 처리한 방문횟수를 세 봤습니다. (내 이름 어때는 제외)

접속자 기준 통계

요청수는 전자과가 전산과보다 많았지만 접속자는 전산과가 더 많은데, 한 번 방문해서 눌러보는
횟수가 전자과가 더 많은 것 같군요. 아마도 로그를 대충 둘러보면 전산과는 RSS를 구독하는 경우가
많아서 접속이 거의 한 번에 1페이지씩인 경향이 다른 과보다 강한 것 같네요.

마지막으로 단골 손님 수를 전공별로 봤습니다.

단골 손님 통계

단골 손님의 기준은 18일 간 제가 글을 몇 개 안 썼기 때문에, 2번 이상 다른 날짜에 방문한 IP 수로
했습니다. 수가 적어서 신뢰도가 아주 높지는 않지만 역시 전산과가 가장 많고 전자과가 두 번째군요.
^^;

결론: 앞으로는 정상인의 블로그로 거듭나기 위해 노력하겠습니다. –;;;;

동영상(?)으로 보는 파이썬의 역사

Michael Ogawa의 code_swarm이라는
프로젝트에서 오픈소스 프로젝트의 CVS나 SVN 등 소스 저장고를 분석해서 일어난 작업들을
시각적으로 보여주는 걸 만들었습니다. 요새 UbiGraph같은
도구도 나오고 하는 걸 보면 시각화가 정말 굉장히 유행이네요~


code_swarm – Python from Michael Ogawa on Vimeo.

저는 3분 50초 쯤에 약간 왼쪽 아래에서 나타나서 잠시 머물다가 사라집니다;;; -ㅇ-;;;;;

이 영상은 미디어아트와 데이터 시각화에서 많은 관심을 모았던
Processing으로 만들었다고 하는데.. 전에 봤을 때는 괜히 어렵기만 하고 별 쓸모 없어보니더니
이걸 보니 확 땡기는군요. ^^;;

— via Python Daily URL

FreeBSD도 뒤늦게 subversion으로

대략 2004~2005년경에 수많은 프로젝트들이 CVS에서 Subversion으로 옮겨갔는데
거의 종교개혁 수준으로 다들 10년 넘게 쓰던 걸 갑자기 화아아악~ 바꾸는게 상당히 무서웠었죠. ?
파이썬 프로젝트도 마찬가지로 2005년 7월에 약간 늦게 svn으로 바꿔서 지금은
파이썬 sys모듈에 svn 리비전 번호가 문자열로 들어갈 정도로 잘(?) 운용되고 있습니다.

FreeBSD는 커널, 유저랜드 유틸리티 전체와 포트, 문서까지 포함하고 있는 거대 프로젝트이다보니
뭘 해도 쉽지가 않은데요. 역시 그래서 그 유명한 bikeshedding의 원조답게 수차례
결론 없는 토론을 거의 반년에 한 번씩 거듭한 끝에, 드디어 얼마 전에 svn으로 이주가 완전히
끝났
습니다. (링크는
svn에서 최초 커밋)

물론 이전의 토론 과정에서는 hg, git, darcs, bazaar를 비롯한 수많은 SCM들의 변호사들이 등장해서
굉장한 토론이 꾸준히 있었지만,
분산SCM들은 분산 개발의 편리를 위해서 역사가 긴 대형 프로젝트에는 적합하지 않은 면이 많고,
CVS는 그 동안 너무 문제점들이 많이 누적돼와서 결국엔 svn이 채택되었습니다.
또한 hgsvn이나 git-svn, svk 같은 툴들이 있어서 개발자들이 개인 취향에 따라 다르게 쓸 수
있다는 것도 아이러니하게 svn에 큰 점수를 줬습니다.
BSDCan에서 subversion으로 이사를 주장했던
Peter Wemm이 FreeBSD에서 내부적으로 꼭 필요한
기능 (예를 들어 키워드 자동 치환, 로그 템플릿) 들을 직접 수정해서 패치를 올리고, 일일이 변환하고
잘못된 점이 있나 확인하고, 다시 잘못된 것 수정하고, 기존 커미터들을 위한 svn 가이드도 작성한
끝에 무사히 이사가 끝났습니다.

새 저장고와 관련된 것들은 대부분 http://svn.freebsd.org
연결돼 있어서 구경하실 수 있습니다. ?

Watch Full Movie Online Streaming Online and Download