Intel HyperThreading 보안 결함 발견

최근 FreeBSD의 미래와 관련된 무척 흥미로운 (정말로!) 얘기들이 많이 나오고 있는 BSDCan 2005에서 일이 하나 터졌습니다. 인텔의 펜티엄 연산 버그 이후로 가장 큰 문제가 아닐까 하는데, FreeBSD 커미터인 Colin Percival (freebsd-updateportsnap으로 유명한)이 인텔의 Hyper-Threading 구현의 보안 결함을 BSDCan에서 발표한 것입니다.

아직 무슨 문제인지, 고칠 방법은 무엇인지가 구체적으로 발표된 것은 아니고, BSDCan에 참가하고 있는 개발자들 간에는 활발한 토론이 이뤄지고 있는 듯합니다. 해당 문제로 인해서 영향을 받을 수 있는 것은, 다른 사용자 프로세스에 의해서 RSA키같은 사적인 정보들이 노출될 수 있다는 것인데, 아무래도 CPU상의 문제가 그런 영향을 미칠 수 있는 방법을 생각해 보면 HTT에서 같은 프로세서에 우연히 같이 올라간 프로세스가 서로 메모리 영역 보호가 잘 안 된다거나.. 알게 모르게 특수한 상황에서 레지스터가 공유돼 버리는 것이 아닌가 한번 때려 맞혀 봅니다. -.-; 그래서, FreeBSD에서는 하이퍼쓰레딩이 이제 디폴트로 꺼지는 것으로 우선 처리가 됐고, NetBSD에서는 올바른 피해가기 패치를 마련한 다음에 발표할 예정이라고 합니다. 그리고 SCO에서도 패치를 한 걸로 봐서는, OS에 큰 상관 없이 하이퍼쓰레딩을 지원하는 모든 OS에 영향을 주는 것 같군요.

흐흐흐.. 인텔 화이팅~ -O-;;;

서울 지하철 모듈

IRC 봇 SugarCube의 주요 플러그인 중의 하나였던 지하철 플러그인이 최근에 정보 싸이트로 쓰고 있던 WebSubway가 개편을 하는 바람에 안 돌아가게 돼 버렸습니다. 한동안 고치기 귀찮아~~~을 외치며 우어우어 거리고 있다가, 휴가 중 짬을 내어 봇에서 따로 쓸 수도 있게 그냥 일반화 클래스를 만들어버렸습니다.

사용법은 대충 이런식..

흐흐 일단 SugarCube에 적용해 놓았는데, 다른데 msnm 봇이나 웹사이트 같은 데 활용하실 분들은 마음껏 사용하세용~ (라이선스는 libpng/zlib 라이선스) 소스는 OpenLook Trac에서 받으실 수 있고, 소스코드 문서도 있습니다. (크크~)

모든 것이 새롭다 – rrdtool 1.2

압도적인 인기의 오픈소스 라운드 로빈 데이터베이스인
RRDTool이 1.2가 릴리스 되었습니다. 그동안의 버전이었던
1.0에서 상당히 오래 머물러 있었는데, 갑자기 1.2로 올라오고
나서는 요새 유행하는 모든 것이 새롭다 스타일이군용~ 쿠쿠~

  • 베이스 그래픽 라이브러리가 바뀌었습니다. 원래 gd 라이브러리를 사용했었기에, 국제화에 한계가 있었으며 비트맵 그래픽만 가능했었지만, 이제는 기반 라이브러리가 libart로 바뀌고, freetype으로 폰트 렌더링을 하기 때문에, 이제 anti-alias 벡터 그래픽이 가능해졌고, 트루타입 폰트 (한글도 가능!)도 지원됩니다. 와와!
  • 새로운 출력 포맷: 이제 기존 포맷 외에도 SVG, PDF, EPS가 지원됩니다.
  • VDEF 지원: 기존에 CDEF와 DEF와 LINE등을 써서는 최대값이나 평균값 같은 것을 무척 단순하게 밖에 표현할 수가 없었는데, 이제 VDEF로 그래프 전역에 있는 다른 값들을 다룰 수가 있게 되었습니다.
  • 예상값 밖으로 튀는 것 검사: Holt-Winters Forecasting 라는 것을 사용해서, 이제 원래 진행되던 것 외로 데이터가 튀는 것에 대해서 표시를 할 수 있게 되었습니다.
  • COMPUTE 데이터 타입: 이제 로깅 남길 때 데이터 타입을 지정해서 로그를 남길 때 미리 계산해서 RRD에 넣을 수 있게 되었습니다.
  • 외부 라이브러리 별도 배포: rrdtool에서는 그동안 gd라이브러리, png, jpg같이 외부 라이브러리들을 모두 소스에도 같이 묶고 static 링크를 하는 방식으로 배포하고 있었는데, 동적 라이브러리를 최대 활용하는 최근 트렌드에 맞춰서 이제 모두 외부 소스를 쓰며, 동적 링크를 하게 되었습니다. 그래서, 이제 컴파일하기가 간단하지가 않습니다. 으흐흐 -ㅇ-; 포트 없으면 이제 컴파일도 못하겠 -.,-;
  • mmap 지원: 이제 파일 I/O를 할 때 mmap을 씁니다. mmap은 lazy on-demand I/O를 하다보니 아무래도 rrd 파일을 관리할 때 좀 더 시간을 절약할 수도 있을 것 같군요.

rrdtool 1.2로 만든 anti-alias 이미지

한편, 마티즈같이 바뀌지 않은 것이 하나 있는데.. 바로 이것! 🙂

그런데, 오늘 어떤 사람이 py-rrdtool을 rrdtool 안에 넣으려고 Oetiker씨와 얘기를 하고 있다고 라이선스에 대해서 저에게 문의를 해 왔는데, 잘 되면 다음 1.2버전 부터는 rrdtool만 깔면 파이썬에서도 쓸 수 있게 되겠군용.~

파이썬에 다시 불어오는 봄바람

요새 파이썬 개발팀의 주요 이슈는 PEP-340 Anonymous Block 입니다. 거의 다른 이슈들을 완전히 누르고 하루에도 수십통씩 관련 메일이 올라올 정도로 다들 열에 올라 있는데, 이 논의와 비슷한 얘기는 이전에도 몇번 있긴 했지만 딱히 어디로 결론이 나지는 않았었습니다. (PEP-310, PEP-325) 그러나 4월 중순에 C++ 프로그래머였던 사람이 조심스럽게 질문을 한 것에 대한 답글들에서 개발자들이 열을 내기 시작해서, 귀도가 4월 27일에 직접 PEP를 쓰기에 이릅니다.

이번 PEP-340은 현재 드래프트 상태이고, 확실히 의견이 모아진 것도 아니며, 그냥 실험적으로 논의되는 상태를 정리하는 것을 위한 안이지만, 이전의 유사 주제의 PEP들에 비해 상당히 여러 분야를 한꺼번에 통합하고 있고, 신선한 개념을 많이 제공하고 있다는 점에서 뭔가 유사한 것이 약간의 부분이라도 파이썬 2.5에 들어갈 것 같은 감이 듭니다. 으흐흐~ 파이썬 2.5에는 특히 AST가 거의 들어갈 것이 확실시되고 있으니까.. 그 김에 문법도 확 -.-,;;

PEP-340에서 소개하는 Anonymous Block은 파이썬 1.5 이후의 문법 상의 가장 획기적인 변화라고 부를 수도 있겠는데, 사실 많은 수의 개발자들이 2.4까지 계속 문법 변화가 많았으니 이제 2.5부터는 문법은 바꾸지 말자하고 암묵적인 동의를 했음에도 불구하고, 이번에 예전에 수년동안 있었던 문법 변화보다 더 많은 변화가 들어가 버리니.. 파이썬 중도보수파들도 이제 파이썬의 변화에 반감을 느낄 것 같기도 합니다. 으흐~

Anonymous Block이 해결하려는 이슈를 소개해 드리자면, PEP에서 언급된 대로 “좋은 프로그래머들은 자주 나오는 코드를 재사용 가능한 함수로 분리”를 합니다. 그런데, 함수나 클래스로 쉽게 분리가 되는 경우도 많이 있지만, 어떤 경우에는 루틴의 앞부분과 끝부분, 오류처리부분과 루틴의 중간 중간이 드문드문 반복되는 패턴으로 자꾸 나오는 경우가 있습니다. 예를 들면, 공유 자원의 접근을 위한 뮤텍스라던지, DB 접근을 위한 트랜잭션 처리 블럭, HTML의 헤더/푸터나 table 앞뒤 장식, 임시 파일의 생성 등 수많은 경우가 해당이 될 수 있겠는데요. 이런 경우에는 콜백으로 빼서 클래스를 생성하자니 배보다 배꼽이 크게 되고, 그렇다고 매번 풀어쓰기에는 반복되는 로직을 자꾸 중복하게 되는 찝찝한 경우가 생기는데, 이런 경우를 극복하기 위해서 Anonymous Block (현재 파이썬 메일링에서는 그냥 “block”이라고 부르고 있습니다.)가 제안되었습니다.

즉, “block”에 진입하는 시점, 오류또는 정상 종료로 인한 이탈 시점, 반복을 하는 시점, 중간에 루프의 인자가 약간 바뀌는 시점 같은 것들을 기존의 문법인 제너레이터를 확장한 것과 짬뽕을 해서 멋지게 만들어 보자는 것이 요점입니다. 2.3부터 지원되고 있는 제너레이터는 이미 상당히 다양한 용도에 사용할 수 있는 성공한 문법이지만, next 메쏘드에 인자를 전달할 수가 없어서, 상태 관리가 매우 힘들다는 점이나 try: finally 블럭이나 try: except 블럭을 yield와 걸쳐서 사용할 수 없어서, 자원의 정상적인 해제가 불가능하다는 점에서 아쉬움이 있었는데 이러한 문제점도 여기서 완전히 해결되었습니다.

현재 상태에서 PEP-340에서 변경하는 기본 statement 변화는 이런 것들이 있습니다.

  • __next__ 메쏘드 신설: 기존의 이터레이터 프로토콜에서는 __next__가 아니라 next메쏘드를 쓰고 있었는데, 이 이름이 범용으로는 아무래도 맞지가 않았기에, __next__로 새로운 메쏘드를 신설하고, __next__에 이제 인자 1개가 None이 기본값인 옵셔널 인자로 들어갑니다.
  • __exit__ 메쏘드 신설: 이터레이터 프로토콜에 자원 해제를 위한 메쏘드가 없어서, 그동안 lock 해제 같은 것이 매우 곤란했었는데, 그 경우를 위해서 예외 발생 여부에 상관없이 항상 호출되는 __exit__ 메쏘드를 새로 만듭니다.
  • next() 빌트인 함수: i.__next__()라고 맨날 쓰기에는 너무 보기가 안 좋아서, next(i)로 사용할 수 있도록 빌트인 함수가 신설됩니다.
  • for 루프 변경: for 루프의 정의가 변경됩니다. 아래의 인자 있는 continue나 탈출 함수 호출을 위한 정의 변경이고, 예전 사용법으로 쓰는 경우는 똑같습니다.
  • continue 인자 추가: continue 키워드 뒤에 이제 인자를 붙일 수 있게 되었습니다. continue 키워드 뒤에 인자를 쓰는 경우에는 바깥에서 돌고 있는 for또는 “block” 블럭의 이터레이터에게 전달됩니다. 즉, for 루프의 본문과 이터레이터가 직접 통신이 가능하게 되었습니다.
  • Anonymous block 추가: 아직 이름이 정해지지 않은 (아직 “block”이라고 부르고 있습니다.) 새로운 블럭 키워드가 추가됩니다. 이 키워드는 for과 유사한 목적으로 사용될 수도 있지만, 이터레이터 인자를 항상 대상으로 하고 있다는 점에서 좀 다릅니다. 자세한 설명은 아래에서..
  • 제너레이터 예외 처리: 이제 제너레이터의 yield statement가 try: except 블럭 안에도 들어갈 수 있게 되었으며, try: finally 블럭 안에도 들어갈 수 있습니다.
  • yield statement 리턴값: 제너레이터의 __next__로 들어오는 인자를 받기 위해서 이제 yield statement가 들어온 값을 리턴합니다.

대충 훑어봐도 엄청난 변화임이 확실히 느껴지는데, 이게 아직 확실히 정해진 것은 아니니 허어억~ 하고 미리 놀라실 필요는 없습니다. (나중에 들어가면 그때 놀라면;; -o-) Anonymous Block을 사용하는 예제로 가장 많이 나오는 DB 트랜잭션 처리 같은 경우에는 이렇게 됩니다.

그리고, 이제 yield가 리턴값을 갖을 수 있기 때문에 유사-클로져나 유사-코루틴을 이제 쓸 수가 있게 되었습니다. 예를 들어서, 이런 코드가..

흐흐.. 결국 껍데기 부분의 루틴 분리에 획기적인 개선을 가져올 수 있는 좋은 도구가 될 수 있을 만한 것 같이 보입니다. 여전히 수많은 이슈들과 특히 키워드 이름을 무엇으로 할 것인가 등의 많은 문제들이 남아있지만, 아무래도 파이썬 2.5에 들어가면 가장 멋있을 것 같은 기능임에는 틀림이 없군요. 🙂 문법 변화라는 점에서는 원래 예정과는 좀 다르게 간다는 점에서는 약간 찝찝한 감이 있긴 하지만.. 뭐 이제 류창우님의 말씀 대로.. 파이썬도 C++이 가던 길을 걷고 있는 건지도.. (먼산)

FreeBSD에도 패키지를 자동으로!

얼마 전에 회사에서 새로운 서버를 세팅하면서, 데비안에 없는 패키지 몇 개를 깔끔하게 설치하기 위해 방법을 알아보던 중, 회사 동료인 상현씨의 조언으로 checkinstall를 이용해서 설치하게 되었습니다. checkinstall은 인스톨하는 도중에 preload된 동적 라이브러리가 파일 변경사항을 로그로 남겨서, 그 로그를 기반으로 마치 패키지를 이용해서 깐 것처럼 해 주는 도구이더군요. 물론 바이너리 패키지도 만들어 주고 해서, 패키징되지 않은 프로그램을 임시로 재빠르게 깔아야하는 경우에 매우 편리했습니다.

사실 예전에 autoplist.py라고 ktrace기반의 pkg-plist 자동 생성기를 만들었습니다. 그런데, 당시 FreeBSD의 베이스가 정적 링크되어 있었기에 LD_PRELOAD 트릭을 사용할 수가 없어서 ktrace를 기반으로하다보니 너무 부하가 심해서 mozilla같은 대형 포트를 깔 때에는 거의 5분 이상이 걸리는데다 로그를 남기는 하드디스크 용량도 너무 많이 들고 해서 아주 간단한 포트 외에는 쓰기가 힘들었습니다.

FreeBSD는 그래도 간단한 임시 포트를 만들기가 데비안에 비해서는 쉬운 편이긴 하지만, 아무래도 pkg-plist 만드는 압박이 있기에 FreeBSD에도 그런 것이 있으면 삶을 활기차게 사는 데에 큰 도움이 되겠구나. 하는 생각이 들었습니다. 🙂 이제 FreeBSD도 베이스가 완전 동적으로 되었기에, FreeBSD 사용자도 이제 젖과 꿀이 흐르는 자동 plist 생성의 세계로! 그런데, 우선 인스톨 로그를 위한 sysutils/installwatch포트가 워낙 오래된 것이어서 그런지, 5.x에서는 log 심볼의 중복이라던지 여러가지 문제점으로 계속 버스에러로 죽었는데 그 문제를 약간 추적해서 수정해서 메인테이너에게 보냈습니다. (아직 커밋되지는 않았습니다.)

그래서 그걸 이용해서 결국 주말에 pkg_trackinst와 pkg_genplist를 LD_PRELOAD기반으로 만들었습니다.
우선, pkg_trackinst는 패키징이 안 되어있는 소프트웨어를 make install할 때에 당시에 설치되는 파일들을 분석해서 자동으로 패키지로 설치한 것처럼 만들어주고 바이너리 패키지도 만들어서 다른데서도 똑같이 설치할 수 있도록 만들어주는 도구입니다.
그리고, pkg_genplist는 다른 패키징은 다 끝나고 pkg-plist파일만 생성하면 끝나는 상태에서 pkg-plist를 자동으로 생성해 주는 도구입니다.

pkg_trackinst는 오늘까지 만든 부분에서 거의 잘 돌아가고 있지만, 아직 pkg_genplist는 mtree를 사용하지 않고 있어서, 중복된 파일도 막 올려대고 특히 manpage쪽이 문제가 많이 있습니다. 그렇지만, 주말도 거의 끝난데다가.. 다른 시스템들에서도 잘 돌아가는지 보고 싶어서 일단 버전 0.1을 릴리스했습니다. (파이썬 2.4, FreeBSD 5.2이상이 필요하고, 앞에 언급된 installwatch 포트 패치가 적용되어 있어야 합니다.)

패키지 만드는 법이 귀찮지만 pkg_delete는 하고 싶은 분이나 plist 만드는 것이 귀찮아진 분들 한번씩 테스트해봐 주세용. 🙂

coreblog 트랙백을 똑똑하게 받자

어제 뽀빠이님께서 보내주신 트랙백이 장렬하게 깨져서 한참 보였었는데, 그 부분을 수정하기 위해서 코드를 좀 들여다 봤습니다. 이 부분은 아주 유명한 프로토콜 디자인 상의 오류인 트랙백의 인코딩 문제로 인해서 발생합니다. 아시다시피 트랙백을 전송하는 HTTP GET 리퀘스트에는 특별히 인코딩을 쓸 수 있는 방법이 없는데, URI/URL의 원초적인 한계성으로 인해서 HTTP GET에는 뭐가 들어오던 간에, 인코딩 이름을 직접 주지 않고서는 뭐 해결할 방법이 전혀 없는.. 참으로 답답한 경우 중의 하나입니다. 으흐~ (이 부분은 트랙백의 기반 표준을 IRI로 바꿔버리면 해결되긴 합니다.)

그래서, 결국은 아직까지는 euc-kr인가 utf-8인가를 구분하기 위해서는 그냥 디코딩해 보는 방법 외에는 딱히 방법이 없는데, 많은 블로그 소프트웨어들이 이런 경우는 고려하지 않고 작성되어 있어서~ ~ 코어블로그도 마찬가지라서.. 그냥 깨져버리고 말았네요.. 흐.. 그래서 일단은 우선 긴급 상황을 패치하기 위해 양쪽 다 시도하는 코드를 우겨넣어 보았습니다. 주말에 환경 설정에서 읽도록 바꿔야겠네요.. 🙂

FreeBSD GUI 인스톨러

FreeBSD 개발자 메일링 리스트에 새 FreeBSD기반 운영체제라고 Kylin에 대해서 메일이 올라 왔습니다. 그런데, 웹 페이지를 아무리 꼼꼼히 읽어봐도.. 딱히 FreeBSD기반도 아닌 것이.. 매뉴얼을 봐도 다 리눅스 명령어이고.. 아무래도 리눅스처럼 보이는데.. 으흐; -O-

그 메일 쓰레드에 다른 개발자가 답글로 새로운 다른 프로젝트를 찾았다고 글을 올렸는데, 바로 PC-BSD 였습니다. PC-BSD는 그래픽 인스톨러를 넣고 X 환경을 간단하도록 튜닝한 FreeBSD 배포본인 듯 합니다. 일단, 웹 사이트를 정탐해 보니까, 아무래도 웹 사이트 스타일이 FreeSBIE랑 비슷한게.. 비슷한 사람들이 만든 것일까 했는데, 그냥 다른 사람들인 듯 합니다.

아직 그래픽 인스톨러는 아직 아나콘다보다는 좀 안 예쁘기는 합니다마는, 그래도 데비안 그래픽 인스톨러보다는 예쁘(;; -ㅇ-)군요.. 흐흐흐; PC-BSD는 FreeSBIE와는 다르게, KDE를 기본으로 쓰고 있는데, GNOME 인스톨은 따로 특별히 지원하고 있지는 않은 듯 합니다. FreeSBIE는 xfce와 wmaker를 지원하고, PC-BSD는 KDE를 지원하니.. 이제 그놈 기반 인스톨러만 하나 나오면 좋겠는데.. ^_^

그런데, 기왕 BSD 인스톨러면 BSD 라이선스를 썼으면 좋았을텐데, 신비롭게도.. 인스톨러를 GPL로 해놨네요.. (그럼 그냥 젠투 인스톨러로 만들 것이지~ -O-;; =3=33)

mono의 한국어 DateTimeFormatInfo

FreeBSD에서 mono가 여전히 잘 안되는 부분이 많기에.. 고치기도 힘들고 해서 깔아놓고는 별로 안 쓰고 있었는데, 창우옹께서 날짜가 이상하게 나오는 문제가 있다기에, 주말에 날씨도 화창한데 집에서 문제를 고쳐 봤습니다.

우선, 문제는 System.DateTime.ToShortTimeString()의 결과가 “오 5:12″같이 오전/오후가 표시가 안 되는 생뚱맞은 것이었는데, MS.NET CLR에서는 “오후 5:12″로 제대로 나왔는데, mono에서만 짤려서 나오는 것이었습니다. 그래서 무슨 문제인지 추적을 해 봤는데.. 역시 구조는 여기 저기 많이 거친거라.. 한참을 “그건 우리 담당이 아니니 다른 데 가서 알아보세요”를 겪고 찾아버렸습니다. 으흐.

  • 일단은 corlib의 System.DateTime 클래스: 여기서는 ShortTimeString 메쏘드가 ToString 메쏘드를 호출하고, ToString에서는 내부적인 다른 메쏘드에서 System.Globalization.DateTimeFormatInfo 클래스의 ShortTimePattern을 참조하고 있었습니다.
  • System.Globalization.DateTimeFormatInfo을 보니까, 별다른 내용은 없고, 그냥 다른 곳에서 construct해 준 값을 그냥 단순히 받아만 주는 것 같아서, 다시 System.DateTime으로~
  • System.DateTime 구현을 자세히 보니까 System.Globalization.CultureInfo 클래스의 인스턴스를 가져오도록 되어있었는데, 그놈이 TLS에 저장되는 전역 인스턴스를 가져오도록 되어있었습니다. 그런데, 데이터를 로딩하는 부분은 construct_datetimeformat_info()라는 정의되지도 않은 메쏘드를 쓰고 있었는데, [MethodImplAttribute (MethodImplOptions.InternalCall)] private extern void 라는 데코레이트 되는 타입으로 되어있어서, 아 이게 뭔가 하고 한참을 고민했습니다. ;;
  • 결국 mono 소스 전체에서 저 메쏘드 이름을 grep해 보니까, 와와! monoruntime의 mono/mono/metadata/locale.c에서 C함수를 그 메쏘드로 매핑하고 있었던 것.. 자세히 보니까 culture-info-table.h라는 자동 제너레이트된 파일에 datetime 포맷이 기록되어 있었습니다. 근데 그놈은 또 다른 프로그램이 만든 것;
  • 휴.. 결국은 목적지에 도착! mono/tools/locale-builder라고 하는 C#으로 작성된 프로그램이 locale과 culture관련 XML파일들을 모아서 monoruntime의 C 헤더파일로 변환을 해 주고 있었습니다. mono에서는 ICU의 데이터들을 그대로 쓰고 있는데, ICU LDML와 CLI의 포맷이 다른 점을 supp/ 디렉터리 아래의 xml 파일들로 오버라이드하고 있는 바로 그 부분에서 잘못된 포맷이 있었던 것! 그래서 잽싸게 쓱싹 수정해서..
  • 버그를 질렀습니다. 으흐.. 버그질라는 왜이리 복잡하지~

그런데, 이번에 이 작업을 하면서, mono의 System.Globalization 지원 부분의 내부 구조를 잘 알게 되었는데, 생각보다는 역시 디자인이 괜찮은 것이, 파이썬에도 CultureInfo같은 것을 하나 만들어 넣고 싶어졌습니다. 지금 있는 locale 모듈은 시스템 의존적이라, 안 되는게 너무 많아서.. 으흐.. 그런데, 구글에서 찾아보니 Zope X3의 zope.i18n 쪽에서 ICU를 기반으로 한 국제화 지원이 들어가고 있었는데, 아직 구체적으로는 안 봤지만 뭔가 기대가 됩니다!

회사 PHP 코딩 규정

요새 회사가 새로운 모습으로 (9시 출근을 포함해서;;) 많이 바뀌면서, 정상적인 개발팀이라면 있어야 한다고 보통 다들 그러지만, 하루 벌어 하루 먹고 사는 빈곤 개발팀들에게는 꿈같은 것 중의 하나인 “코딩 규정 (coding standards)”를 만들었습니다.

제가 소속된 팀에서는 서버나 에이전트 같은 정적인 프로세스들은 파이썬을 사용하고 있고, 웹 인터페이스 쪽에서는 커스터마이즈를 직접 하기 원하는 고객들의 요구때문에, PHP를 사용하고 있습니다. 그래서, 파이썬쪽은 당연히 PEP-008 파이썬 코드 스타일 가이드를 따르는 것으로 간략하게 정했고, PHP 쪽에서는 딱히 생각나는 문서가 없어서 우선 떠오르는 몇가지를 글자로 옮겨 보았습니다. (원본은 회사 내부 사이트 안에 올라가 있기 때문에, 따로 OpenLook Wiki에 PHPCodingStandard 페이지로 옮겨 두었습니다.)

물론, 인덴트 크기나, {}의 위치, if () 조건문의 띄어쓰기 방법, 각 연산자 별로 어느 것은 띄어 쓰고 어떤 것은 띄어쓰지 않을 것인지, switch뒤에 case는 띄어 쓸지 아닐지 같은 것들은 상당히 종교적인 싸움까지도 갈 수도 있는 민감한 사안이기는 합니다. 그렇지만, 각자가 자기 스타일이 좋다고 그냥 코드를 제각각 써버리는 것 만큼 추한 코드 나오기 적당한 환경이 없을 것 같다는 생각이 들어서, 그냥 모두 1가지 방법으로 통일했습니다. 목표는 코드를 보고서 이게 누가 짠 것인지 모르게 만드는 것! 크크 🙂

사실 XP를 쓰지 않는 프로젝트를 하다 보면, 알게 모르게 어느 소스는 누가 잘 알고 그런 게 생기게 마련인데, 이렇게 되면 문제점 해결을 위해서 고객이 연락을 하려는 경우에 여기 저기 공무원 처럼 떠넘김을 당하고 나서는, 개발자들이 책임감이 부족하다는 것을 느끼기도 한다는 것을 고객사 담당자에게 들었는데, 변명의 여지는 있지만 그래도 못 들은 체 하기에는 맞는 면도 있는 것 같습니다. 이제 슬슬 저희 팀에서도 이제 누가 짰는지 모르는 공동생산을 본격적으로 해보려고 마음을.. 🙂

C++에 미련이 있는 사람들을 위한 call by reference

IRC에서 후배 nezy군이 C++의 &인자와 같은 참조에 의한 호출은 어떻게 하냐고 물어봐서, 오기로 한번 만들어 봤습니다. 안 될게 뭐 있어!

결과 값으로 “49 4″가 나옵니다. t와 r이 yay 함수에서 계산된 값으로 세팅된 것~ 🙂

(주의사항): 이 소스는 그냥 장난이지 실제로 이렇게 쓰시기를 추천하는 것은 아닙니다.;;;