MyStory

http://arxiv.org/abs/1111.3328 논문 요약

CECRI — Mon, 21 Nov 2011 13:26:20 +0900

양자역학에서 필수적인 파동함수를 해석하는 데에는 두가지 시각이 있다. 첫째는 파동함수가 물리적 실체라는 것이고 두번째는 파동함수 자체가 존재하는것이 아니라 파동함수는 macroscopic하게 관측을 할때 통계적으로 값을 주는 변수에 불과하다는 주장이다. 즉 이 두번째 주장은, 파동함수는 실제 통계적인 추측보다 많은것을 담고 있으므로 뭔가 정보가 더 있다는 시각이다.

이 논문은 두번째 시각이 틀렸다는것을 증명한다. 증명 자체는 간단하다. 먼저, 어떤 물리계의 실제 물리적 실체를 생각해보자. 만약 첫번째 시각이 맞다면, 실제 물리적 실체는 파동함수를 포함할 것이고 따라서 파동함수가 다르다면 물리적 실체도 다를것이다. 하지만 두번째 시각이 맞다면, 물리적 실체가 같지만 우리가 식으로 쓴 파동함수는 다를수가 있다.

예를들어 $|\phi> = \frac{1}{\sqrt{2}} (|0>+|1>)$ 의 경우 "얘는 그냥 $|0>, |1>$ basis로 관측했을때 1/2확률로 1이고 1/2의 확률로 0이 나오는 상태이다." 라는 시각이 있다고 하자. 그러면 이런 통계적인 주장은 $|\phi> = \frac{1}{\sqrt{2}} (|0>-|1>)$에도 똑같이 적용된다. 즉, 우리가 식으로쓴 파동함수가 다른것이다. 이것은 꼭 이런종류의 주장 뿐만 아니라 더 강한 통계적인 주장(파동함수에 대한 정보를 좀더 많이 담은)에 적용된다.

즉, 실제 물리계는 통계적으로 완벽히 기술되는데 반해 파동함수는 통계적인 추측보다 더 많은것을 담고있기 때문에, 뭔가 정보의 잉여가 생기고 따라서 같은 물리계를 기술할수 있는 다른 파동함수가 존재한다는 것이다. 논문은 classical analogy를 들어 설명하는데 그것도 덧붙인다.

동전을 던지는 두가지 방법이 있다고 가정하자. 만약 이때 동전을 던져서 나오는 결과의 통계적 분포가 실제 물리적인 실체고, 동전의 위치, 운동량 등은 실제 물리적인 실체가 아니라고 가정하자. 두가지 방법 모두 앞면이 나올 가능성이 0이 아니라고 하자. 그러면 동전을 던져 앞면이 나온 경우 이것이 첫번째 방법을 써서 던진건지 두번째 방법을 써서 던진건지 알수가 없다. 따라서 두가지 방법의 결과가 compatible하다.

즉, 어떠한 물리적 실체가 완벽히 통계적이라면, 그 실체의 특정한 시행에 대한 값은 이것도 가능하고 저것도 가능하다는 것이다. 여기까지 왔으면 결론은 쉽다. 이제 양자상태를 준비하자. 동전을 던질때와 마찬가지로 두가지 방법으로 양자상태를 준비하자. 첫번째 방법은 $ |\phi_0> = |0>$를 준비하고, 두번째 방법은 $|\phi_1> = |+> = (|0>+|1>)/\sqrt{2}$ 를 준비한다. 실제 물리적인 실체과 완벽히 통계적이라면, 측정 결과가 이 두 방법중 무엇을 썼는지 알수 없을 확률이 있을것이다. 그 확률을 $q$라고 하자.

그러면 준비는 끝났다. 이 준비하는 기계를 두개를 놓고 그것을 한곳에서 측정하자. 그러면 일단 측정기계에 도달했을때 상태는 $|0>\otimes|0>$, $|0>\otimes|+>$, $|+>\otimes|0>$, $|+>\otimes|+>$ 네개중에 하나일것이다. 그리고 $q^2$의 확률로 네 상태가 compatible할 것이다.

그런데 다음 basis로 측정하는 경우를 살펴보자.
$$
|\xi_1> = \frac{1}{\sqrt{2}}(|0>\otimes|1> + |1>\otimes |0>),
$$$$
|\xi_2> = \frac{1}{\sqrt{2}}(|0>\otimes|-> + |1>\otimes |+>),
$$$$
|\xi_3> = \frac{1}{\sqrt{2}}(|+>\otimes|1> + |->\otimes |0>),
$$$$
|\xi_4> = \frac{1}{\sqrt{2}}(|+>\otimes|-> + |->\otimes |+>),
$$
이때 $|-> = (|0> - |1>)/\sqrt{2}$이다. 하지만 이 경우 첫번째 상태$|0>\otimes|0>$를 basis의 첫번째 원소로 측정하면 결과는 0이다. 두번째 상태는 두번째 원소로 측정하면 0 이고 세번째와 네번째도 마찬가지이다. 따라서 모순이 발생한다. $q^2$의 확률로 우리는 네가지 상태가 모두 물리적 실체와 compatible해야 하는데 측정을 하면 우리는 무슨 state가 맞는지 알 수 있다. 따라서 물리적 실체가 순수히 통계적이고 상태벡터는 그것을 표현하는 수단이지 물리적 실체가 아니라는 주장은 잘못된 것이다.

여기까지가 논문의 앞 2페이지 요약이고 뒤에는 이것을 일반적인 상태에 대해서 일반화 시키는 내용과 실험적 오차를 고려하는 상황이다. 요 아래는 개인적인 comment.

이게 contextuallity와 별로 다른 개념은 아닌것 같은데 아직을 잘 모르겠고, 항상 양자역학이 고전적인 해석이랑 다르다는 데에는 entanglement가 관여하는 것을 봐서 뭔가 entanglement가 정말로 고전적으로 nontrivial한 것인것 같다. 뭔가 이와 관련된 공부를 좀 해봐야 할듯.

우리는 왜 독재자의 죽음을 슬퍼하는가

CECRI — Sat, 29 Oct 2011 02:40:43 +0900

제목을 보고 뜬금없다고 생각할수도 있다. 하지만 카다피 이야기가 아니다. 내가 말하고 싶은사람은 '스티븐 잡스'이다.

무슨 뚱딴지 같은 소리냐고 할지도 모르겠다. 하지만 C로 프로그래밍을 배우고 리눅스 환경에서 OS를 다뤄보았고 Mac OS 가 BSD없이는 불가능한걸 아는 사람들이 도대체 왜 잡스의 사망소식을 듣고 블로그에 애도를 표하면서 데니스 리치나 존 맥카시의 죽음에는 애도를 표하지 않는가. 다른 사람들은 모르겠다. 하지만 프로그래머가 그러면 안된다. 정말로 잡스의 죽음은 애통하고 데니스 리치는 그냥 가는 사람이라고 생각하는 개발자들은 스스로를 반성해 보자. 당신들은 스스로의 자유를 포기하였다.

IT세상에서 프로그래머는 자유를 가진 존재이다. 그들은 텍스트나 복잡한 점수입력을 처리하기 위해 스프레드시트를 여는 대신 펄이나 파이썬으로 열줄정도 되는 스크립트를 짠다. 필요한게 있으면 만들고 끼워맞춰서 쓰는게 기본 정신이다. 따라서 많은 오픈소스 프로그램들은 커스터마이징이 무한대로 가능하다. 그것이 개발자들이 좋아하는 방식이다. Compiz나 emacs는 이러한 철학을 가장 확실히 보여주는 예이다.

사실 개발자들도 편한걸 좋아한다. 복잡하고 쓸데없이 설정해야하는것을 좋아하는 사람들이 누가 있겠나. 하지만 아무리 그렇다고 해도 잡스의 철학은 아니다. 그것을 개발자의 방식이 아닐 뿐더러 누구의 방식도 되어서는 안된다. OS의 기본 파일탐색기에서 잘라내기를 지원하지 않는다. 커맨드키를 주로 쓰는 바람에 같은 프로그램도 다른 OS와 단축키가 달라진다. 내폰에 내가만든 앱을 올리고 싶은데 돈을주고 개발자등록을 해야한다. 이것 뿐만 아니라 무수히 많은 제약들이 사용자들을 옭아맨다. 애플이 제공하는것만 사용하면 쉽다. 하지만 애플이 아니라 '내가 원하는 것'을 하려면 무수히 많은 족쇄들이 옭아매기 시작한다.

그리고 이 족쇄들을 만든사람이 바로 잡스이다. 그가 원한대로 만들어진 시스템에서는 그에 맞는 프로그램만 쓸수 있고 사용자의 모든 자유는 억압된다. 이것이 잡스가 독재자인 이유이다. 일반 사용자들의 경우 많은 작업들이 기본으로 제공되기에 편암함을 느낄고 좋아할수도 있다. 하지만 프로그래머는 절대 그럴수도 없도 그래서도 안된다. 그것은 Computer Science의 기본 철학에 어긋난다. 내가 원하는 프로그래밍언어로 프로그램을 만들지도 못하고 원하는 기능을 쉽게 추가하지도 못하는 상황은 정말로 답답하게 느껴야만 정상이다.

다시한번 잘 생각해보자. 과연 자신들이 유닉스를 만들고 C언어를 처음 개발한 데니스 리치보다 감옥을 만든 스티븐 잡스의 영향을 더 많이 받았는가? 정말 그렇다고 생각한다면 OS 이론이나 프로그래밍 언어론에 대해서 다시 한번 공부해보라. 프레임워크에 대해서만 공부하지 말고 Computer Science가 무엇인지 한번쯤 생각해보는 시간을 가지는것이 어떨까?

Dennis Ritchie의 부고

CECRI — Thu, 13 Oct 2011 19:47:41 +0900

오늘 C언어의 창시자이자 UNIX시스템을 개발한 Dennis Ritchie가 사망하였다. 또한 그는 C를 좀 할줄 안다면 당연히 봤어야 할 The C Programming Language의 공저자이기도 하다. UNIX를 직접 접하지 못한 사람들이 꽤나 많을것이라 생각된다. 하지만 여러분이 가지고 있는 안드로이드 폰에는 UNIX 클론으로 시작한 Linux 커널이 기본으로 달려있고 아이폰이나 맥의 경우 UNIX의 일종인 BSD UNIX커널이 기본으로 들어있다. 사실 현대적인 운영체제의 개념을 정립했다고 보는것이 더 좋을수도 있겠다.

그리고 그런 UNIX를 만들기 위해 개발한 프로그래밍 언어 C는 요즘도 가장 많은 사람들이 처음으로 배우는 언어이자 가장 널리 쓰이는 언어중에 하나이다. 그 이후에 나온 C++이나 Java, C# 보다는 부족한 점도 있지만 아직도 성능을 위해서 C를 써서 개발되는 프로그램들이 많다. 운영체제는 말할것도 없고 Python의 수치계산 라이브러리인 NumPy도 성능이 중요한 부분은 C를 써서 만들고 있다. 게임도 요즘와서 C++이 많이 쓰이지 예전엔 모두다 C로 개발되었다. 이뿐만 아니라 시스템의 메모리를 직접 접근해야 한다던지 하는 경우는 C말고 도저히 쓸만한 언어가 없다. 즉, 아직 많은 부분에서는 C보다 나은 언어가 별로 없다는 이야기.

이뿐만 아니라 아까 언급한 Java나 C#의 경우도 기본적인 문법은 C에서 모두 빌려왔다. 결국 현대적 프로그래밍 언어의 원조격이라고 할수 있는것이 C이다. 이러니 Dennis Ritchie가 컴퓨터 역사의 발전에 기여한것이 어마어마하다고 밖에 할수 없는것이다. 시간이 갈수록 Computer Science는 발전하고 Computer Science가 발전하면서 이런 전설적인 인물도 역사의 뒤편으로 사라진다.

내 생각에는 진정한 혁신은 이런 사람에게서 발견해야 하는것이 맞는것 같다.

Dennis Ritchie를 추모하며.

물리를 쉽게 설명하기?

CECRI — Sun, 10 Jul 2011 02:17:21 +0900

최무영교수의물리학강의
카테고리	과학 > 교양과학 > 교양물리 > 물리이야기
지은이	최무영 (책갈피, 2008년)
상세보기

엘러건트유니버스
카테고리	과학 > 교양과학 > 교양물리 > 물리이야기
지은이	브라이언 그린 (승산, 2002년)
상세보기

인터넷을 돌아다니다가 "최무영교수의 물리학강의"책을 수식이 많다고 어렵다고 하면서 브라이언 그린의 "엘러건트 유니버스"나 "우주의 구조"가 수식이 없어서 쉬웠다고 하는 글을 보았다. 내가 최무영교수님의 책을 직접 읽은적은 없지만, 서점에서 쭉 훑어 보았을때는 수식이 많이 없어서 쉽겠다는 생각을 했었다. 도대체 이 두 생각의 차이는 무엇일까?

"엘러건트 유니버스"는 사실 쉬운책이 아니다. 여러가지 개념을 탁월한 비유를 들어서 설명하지만, 특수상대성이론을 이 책에서 수식없이 설명하는것만으로 이해하려면 머리가 무척 좋거나 이미 특수상대성이론에 대해 일반적인 지식을 알고 있어야 한다. 나의 생각으로는 이 책을 읽고 특수상대성이론은 이해했다는 사람 중 대다수는 겉햝기로 조금만 이해했거나 아니면 다르게 이해한것이다. 특수상대성이론만 해도 제대로 이해하려면 핵심적인 몇개의 수식과 몇몇개 이상의 문제를 풀어보아야 한다. 물론 저자인 브라이언 그린 그 자신은 똑똑한 사람이니 자신의 설명만 듣고 다 이해할 수 있을것이다. 하지만 그도 자신의 책만 읽고 사람들이 현대 물리학의 최첨단중 하나인 초끈이론을 제대로 이해하리라고 기대하진 않을 것이다.

그렇다면 브라이언 그린은 왜 수식을 아꼈을까. 답은 쉽다. 수식을 아낌으로서 많은 독자층을 확보할 수 있기 때문이다. 브라이언 그린 그 자신의 말 처럼 수식을 하나 쓸때마다 독자는 반으로 줄어든다. 과학 "교양서"를 쓰는 입장에서 독자를 줄이는 선택은 하지 않는것이 좋다. 똑같이 어려운 개념이지만 수식이 없음을 통해 뭔가 쉬워보이게 만드는 것이 교양서의 큰 덕목중에 하나니 말이다. 하지만 어려운 개념은 말로 풀어써도 여전히 어렵다. 사실 더 어렵게 된다. 이것이 내가 이 책이 쉽다고 말하는 사람들을 경계하는 이유이다. 물리학 전공자인 나도 한페이지를 여러번 읽으면서 무슨 말인지 생각하고 내가 아는 개념과 대응시키면서 읽는데 쉽다니? 아마 쉽다고 말하는 사람들은 이 책을 소설책 읽듯이 정말로 쉽게 읽었을까? 그렇다면 이 책의 물리학 개념들중에 제대로 이해한것이 하나도 없음이 자명하다.

수식을 아끼는 것이 나쁜것이 아니다. 수식을 아껴도 브라이언 그린이 책을 통해 의도했던 초끈이론의 대략적인 이해와 웅장함은 충분히 드러낼 수 있다. 다만 "대략적"이 점점 강해질 뿐이고 "웅장함"이 꾸며질 뿐이다. 이는 브라이언 그린의 입장에서는 더 좋은 결과이다.

하지만 "최무영교수의 물리학강의"는 다른 책이다. 이 책의 목적은 물리학을 잘 모르는 사람들에게 물리학을 정확하게 가르치는것이 목적이다. 즉, 정확한 개념 전달을 위해 쓴 책이라는 것이다. 그렇다면 이 책에 수식을 안쓰는 것이 좋을 선택일까? 나는 절대 그렇게 생각하지 않는다. 물론 전공자나 미적분에 익숙한 이공계생들을 위한 책이 아니기 때문에 수식이 하나 등장할때 마다 많은 인문, 사회과학 전공 학생이나 다른 일반인들이 힘들어진다는 것은 충분히 이해한다. 하지만 정확한 이해를 위해서는 수식은 필수적이다.

결국 "엘러건트 유니버스"같은 책의 물리개념을 이해하지 못했을 뿐더러 두 책의 목적이 다른것을 몰랐기 때문에 "엘러건트 유니버스"에 비해 "최무영 교수의 물리학 강의"가 수식이 있어서 어렵다는 말을 하는 것이다. 나는 오히려 "최무영 교수의 물리학 강의"가 좀더 좋은 교양서라고 생각한다. 물리학의 특정한 분야가 아닌 전 분야를 다루고 있고 "물리학"자체의 개념전달에 충실하기 때문이다.

헬싱

CECRI — Sun, 10 Jul 2011 01:02:45 +0900

헬싱
카테고리	만화 > SF/판타지
지은이	KOUTA HIRANO (조은세상, 2000년)
상세보기

소장하고 있는 만화책중에 하나이다. 이 만화책은 처음부터 끝까지 '강함'만을 이야기 한다. "주인공 흡혈귀인 '아카드'가 엄청나게 강하다"가 이 책의 모든 줄거리 요약이다. 하지만 이 강함을 풀어가는 방식이 정말로 독특하다. 열권밖에 안되니 시간이 남을때 한번 보는것을 추천한다.

Django Form 에서 동적으로 필드 수정하기

CECRI — Sun, 13 Mar 2011 23:51:55 +0900

Django 의 forms.ModelChoiceField 는 보통 ModelForm 에서 ForiegnKey 를 받기 위해 사용된다. 하지만 ForiegnKey 로 사용될 수 있는 객체가 제한적이라면 queryset 인자를 통해 선택할 수 있는 옵션을 제한 할 수 있다. 예를들어, Board 모델과 Category 모델, Article 모델이 존재한다고 해 보자. Article 은 게시판의 글을 나타내며 Board 와 Category 에 속한다. Category 는 각각의 게시판에서 존재하는 분류를 타나내고 Board 에 속한다. 이 경우 Article 을 쓰기 위해 Form 을 만들 경우 ModelForm 을 사용 할 것이다. 하지만, 이러한 경우는 모든 Category 를 선택할수 있게 하면 안된다. 현재 Article이 써지려는 Board와 같은 Board에 속하는 Category 만 선택가능하도록 해야 할 것이다. 이런 경우 동적으로 ModelForm의 category를 오버로딩 해야 한다. 이때 아랴와 같이 하면 된다.

class ArticleForm(forms.ModelForm):
    def __init__(self, board, *args, **kwargs):
        super(ArticleForm, self).__init__(*args, **kwargs)
        self.fields['category'].queryset = Category.objects.filter(board=board)
        self.fields['category'].empty_label = u"선택안함"
    
    class Meta:
        model = Article
        fields = ('category', ... blah blah ...)

사실 잘 생학해 보면 Category 에 이미 Board 에 대한 정보가 들어가 있으므로 Article 에 딱히 Board 가 필요하지는 않지만 일종의 역정규화를 시킨 것으로 이해하면 된다. 이러한 경우 위와 같이 사용하여 Category 의 선택을 제한 할 수 있다.

Mac OS X 와 Ubuntu

CECRI — Sat, 12 Mar 2011 14:23:00 +0900

나는 현재 데스크톱에 Ubuntu 10.10 버전을 사용하고, 노트북으로는 MacBook Air 13' 형을 사용하고 있다. 맥북에는 기본적으로 Max OS X가 들어가있고, 아직 MacBook Air 를 지원하는 다른 운영체제는 미흡하므로 결국 Ubuntu 와 Mac OS X 를 쓰고 있는 셈이다. 사실 두 운영체제는 크게 다르지 않다. 많은 사람들이 Mac OS X 의 화려한 화면 효과를 보고 좋아하지만, 사실 리눅스 Gnome 데스크톱 환경에서도 Compiz 를 통해 더 좋은 화면 효과를 낼 수 있다.

두 운영체제는 둘다 POSIX 기반이다. Ubuntu 는 GNU/Linux 환경의 배포판이고 Mac OS X 의 Darwin 커널은 BSD Unix 기반의 커널이다. 다만 Ubuntu는 기본적인 패키지 관리 시스템을 내장하고 있어 오픈소스 프로그램의 설치가 쉬운 편이지만, Mac OS X 의 경우 별토의 패키지 관리 시스템이 없다. 다만 시스템적으로 Ruby, Python, Perl 등의 환경은 기본적으로 제공된다. 또한 Macport 와 Homebrew 등의 다른 패키지 관리 시스템을 사용하여 GNU환경을 비슷하게 꾸밀 수 있다.

사실 이런 패키지 관리 시스템을 사용하면 개발환경이나 터미널 환경에서는 두 운영체제는 별로 차이를 느끼기 힘들다. 다만 Mac OS X 를 지원하는 게임들은 좀 있지만 GNU/Linux 환경의 게임은 별로 없다는 점, Macport 는 소스를 다운받아 빌드하는 방식이기 때문에 미칠듯이 느리다는 점이 어느정도 체감할 수 있는 차이이다. 사실 POSIX 환경에서의 터미널 환경에 익숙해 지면 MS Windows 시스템을 쓰기가 좀 힘들다. 시스템 환경변수를 바꾸기 위해서는 귀찮게 GUI환경에서 이것 저것 찾아들어가야 하고, cmd 도 사용하기 꽤나 불편하다. 사실 게임이나 여타 응용프로그램이 아니라면 MS Windows 는 딱히 데스크탑 환경으로도 별로 좋은 것 같지는 않다.

빠른 웹 개발 프레임워크 : Django vs CakePHP

CECRI — Fri, 18 Feb 2011 01:51:54 +0900

전에 CakePHP에 대한 글을 한번 쓴 적이 있다. 그때는 CakePHP를 가지고 동아리 홈페이지를 만들고 있었는데 느린 속도와 코드의 지저분함때문에 결국에는 별로 계속 코딩을 하고싶은 욕구가 생기지 않았다. 누가 돈주는 것도 아니고 결국 내 자신이 동기부여가 안되면 더이상 진행이 안되기 때문에 좀더 구조가 좋은 다른 프레임워크를 생각해 보았다.

처음에는 PHP계열 프레임워크를 알아보다가 내가 CakePHP가 싫어진 이유도 PHP자체의 문제가 한몫 한다고 생각해 아예 다른 언어 기반의 프레임워크를 찾기 시작했다. CakePHP는 클래스 상속을 통해 많은 기능을 DRY(Don't Repeat Yourself)시켜 주는데 일단 PHP가 PHP5부터 제대로 된 객체지향을 지원하지만 아직 프레임워크가 PHP4기반이라 클래스 내부 구현이 별로 이쁘지가 않다. 게다가 제일 큰 문제점은 DB에 접근하기 전에 reculsive를 설정하여 얼마나 연관된 테이블까지 가져올 것인가를 먼저 정해야하는 것이었다. 이것도 사실 객체지향형 설계를 잘해 lazy evaluation을 하면 되는 것인데 결국은 이걸 잘 못하는 PHP랑 관련되어 생긴 문제였다. 도대체 왜 객체지향형 프레임워크에서 User와 연관된 Group정보에 접근하는데 $this->User->data['Group']['field_name']을 써야 하는가. 게다가 load하기 전에 $this->reculsive = 0 정도는 미리 해 주어야 한다. 이걸 굳이 프로그래머가 생각해서 몇번째 연관된 자료까지 필요하니 $this->reculsive를 얼마로 놓아야지 라고 하는것 너무 세련되지 못하다. user->group->get('field_name')정도가 훨씬 간단하고 보기도 좋지 않은가? PHP의 개발자가 PHP는 프레임워크 없이 쓰는 것이 좋다라고 했는데 그 말이 제일 맞는 것 같다. PHP자체가 웹언어니 굳이 프레임워크 없이도 잘 쓸수 있고, 오히려 그럴때 고민을 덜하게 되는 것 같다. 익숙해 지면 물론 다르겠지만 처음 접하는 사람이 HTTP Header를 controller에서 $this->header를 사용할까 아니면 view에서 PHP 내장 header() 함수를 쓸까 고민하는 것 보다는 낫지 않을까? 물론 코딩량은 많아지겠지만...

이러한 이유때문에 다른 언어 기반인 Ruby On Rails(이하 Rails)나 Django로 바꿀 생각을 한번 해 보고 알아보기 시작했다. 사실 Perl 기반의 Catalyst나 함수형 언어 기반의 프레임워크도 생각 해 보았지만, 구할수 있는 자료가 너무 부족한 탓에 일단 Rails나 Django쪽으로 가닥을 잡았다. 일단 전에 Rails에 관련해서 살짝 본 적도 있고 해서 Rails를 선택할까 하다가도 약간은 생소한 Ruby 의 문법때문에 고민이 되었다. 그래서 일단은 Django에 대해서 한번 알아보기로 하였다. Python은 예전에 한번 본 적도 있고 해서 별 문제 없이 Django책 하나랑 Django 문서파일을 가지고 이것저것 해 보기 시작했다. 근데 생각보다 엄청 휼륭하다! 일단 내가 CakePHP에서 불편하다고 느낀 점은 하나도 발견되지 않았다. Django의 모델이 파이썬 코드 구현인 탓에 기존의 SQL을 Python코드로 옮기긴 해야 하겠지만 그건 아무런 문제가 아니었다. CakePHP처럼 Scaffolding기능이 있는 것도 아니었지만 전혀 상관없다. 그냥 할것은 모델을 만들고 간단하게 뷰 구현하고 템플릿좀 끄적여주면 페이지가 완성된다. 물론 아직 익숙하지 않아서 문서를 많이 찾아보지만, 소스 짜는것 자체가 전보다 훨씬 즐거워졌다. 확실히 CakePHP쓸때와는 다르게 쓸데없는 고민따위는 안해도 된다. 이후 Rails도 어떨까 궁금했는데 이것(https://docs.google.com/View?docid=dcn8282p_1hg4sr9)을 보니 뭐 Django보다 많이 좋을 것 같지는 않다.

하지만 Django도 아무런 문제가 없는건 아니다. 사실 Django의 모델에서 폼을 만드는 것은 사용이 그리 간단하지만은 않다. 예를들어 회원가입페이지는 User모델과 UserProfile모델에다 회원을 추가한다. 하지만 가입하기 위해 보여주는 폼(form)은 모델에서 바로 생성하기가 조금 어렵다. 물론 모델에서 생성 할 수 있지만 내가 원하는 대로 폼의 필드를 만드는 것은 사실 폼을 새로 만드는 것과 별 차이가 안난다. 아직 Django의 모든 기능을 알지는 못해서 그럴 수도 있는데 이부분은 좀 아쉽다.

간단히 요약하면 일단 PHP언어 자체와 프레임워크는 별로 어울리지 않는 것 같다. PHP6이 나오니 어떻게 변할지는 모르겠지만 일단 지금까지는 그렇다. 다른 프레임워크를 아직 많이 알지는 못하지만 Django정도면 웹에 있어서는 정말 좋은 프레임워크임에는 틀림없다. 한번 자신이 Python에 대해서 어느정도 알고있다면 웹프로그래밍을 할때 한번 Django에 도전해 보면 좋을 것 같다.

Digest Access Authentication

CECRI — Mon, 14 Feb 2011 15:19:13 +0900

보통 웹으로 로그인 폼을 통해 로그인 기능을 구현 할 때 보통의 경우 비밀번호를 그냥 보내고 서버 상에서 검증하게 된다. 하지만 이러한 방법은 패킷만 캡쳐를 하면 비밀번호를 알아낼수 있어서 매우 위험하다. 따라서 다른 여러가지 방법을 통해 비밀번호를 평문(plain-text)로 보내지 않고 다른 방법을 거쳐서 보내게 된다. 그중 하나가 MD5 Hash를 이용한 digest인증 방법이다. 이에 관심이 생겨 위키(http://en.wikipedia.org/wiki/Digest_access_authentication)를 찾아보던 중 재미난 것을 몇개 발견하였다.

일단 HTTP 스킴이 제일 처음 디자인 된 곳은 유럽입자물리연구소인 CERN이다. 그리고 MD5에 대한 보안상 문제점을 제기하는 논문중에 조금 크리티컬 한 것이 우리나라사람이 제 1저자로 쓴 논문(http://eprint.iacr.org/2006/187.pdf)같다. 우왕 신기해라~

CakePHP 후기

CECRI — Wed, 12 Jan 2011 23:30:40 +0900

일단 몇일동안 CakePHP를 써본 후기를 올린다. 아직 많이 사용 해 본것도 아니고 홈페이지를 다 만든것도 아니지만 일단 조금 아쉬운 점이 있어 올린다.

CakePHP는 유명한 웹 프레임워크인 RoR(Ruby on Rails)의 기능을 본따 php로 만든 것이다. 문제는 php자체가 루비와는 다르게 웹 언어로부터 출발하였고, 프레임워크를 염두하고 만든 것이 아니기 때문에 쓰다 보면 좋을 때도 있지만 좀 귀찮을때도 있다. 그냥 쌩으로 코딩할때는 별 고민없이 프로그래밍한걸 CakePHP내장 함수들을 써서 다듬으려니 꽤나 귀찮다. 특히 디비에 쿼리날릴때 제일 이런 느낌이 많이든다. 원래대로라면 MySQL의 내장함수들과 프로시져를 포함하게 쿼리를 날릴텐데 그걸 전부 php안에서 해야되서 제약이 많아졌다. MySQL의 강력한 기능을 못쓰는 기분.

게다가 CakePHP만의 강력한 기능들은 ajax를 구현할때는 별로 또다른 강력한 기능을 하지 못한다. 원래 기본적으로 form의 어느 필드가 문제인지 알려주는 validate 기능도 ajax에서는 실제 폼으로 전송하는게 아니니까 내부에서 validate을 하고 결과 에러메세지를 데이터로 전송해야 한다. 물론 미리 validate하였기 때문에 save하는 함수에도 validate을 하지는 말라고 알려줘야 한다. 뭐 그래도 조금은 편하긴 하지만 생각했던것 만큼 엄청난 일을 줄여주거나 하지는 않는것 같다. 관련 기능이 있는 Helper를 쓰면 나을 것 같기도 한데, 기본으로 추가되어 있는게 아니기 때문에 무슨 Helper가 좋은지도 모르겠다.

또한 다른 문제는 성능이다. 같은 기능을 생으로 구현했을때와 CakePHP를 썻을때 성능차이가 꽤나 많이 난다. 사용자가 매우 없는 상태라 원래는 누르면 바로바로 받아진 ajax데이터가 꽤나 오래건린다.

하지만 좋은 점도 많다. 일단 마음에 든건 MVC패턴과 레이아웃 기능, 그리고 validate기능이다. 딱 이정도 기능만 있고 빠른 프레임워크가 있으면 많이 좋을 것 같다. 아마 Codeigniter 가 이런데 좋은 것 같은데 알아봐야겠다.

1.1. 프로그래밍 언어 개요

CECRI — Sat, 25 Dec 2010 22:40:03 +0900

프로그래밍 언어는 크게 두가지 종류로 나뉜다. 그중 하나는 명령형 프로그래밍 언어(imperative programming language, http://en.wikipedia.org/wiki/Imperative_programming) 이고 다른 하나는 함수형 프로그래밍 언어(functional programming language, http://en.wikipedia.org/wiki/Functional_programming)이다. 사실 이것은 분류의 한가지 방법일뿐 객체지향을 중요하게 생각하는 사람이면 OOP/ Non OOP로 나눌 수도 있고, 이런 방식으로 나누면 stack을 이용하는 forth나 논리형 프로그램언어인 prolog는 자리가 애매해 지기도 한다. 하지만 내가 이러한 방식으로 프로그래밍 언어를 나눈 것은 이러한 분류방법이 컴퓨터 모델에 대한 가장 큰 두가지 방식과 일치하기 때문이다.

컴퓨터는 무엇을 계산가능할까? 또 어떤 종류의 문제들을 빨리 계산할수 있을 것인가? 이러한 의문에 답해주는 것이 계산이론(Theory of computation, http://en.wikipedia.org/wiki/Computational_theory)이다. 이것은 논리학을 가지고 컴퓨터가 어느것을 계산할수 있는지와 없는지를 알려준다. 이 이론을 전개하는 방식은 여러가지가 있는데, 그중 대표적인 두가지 방식이 튜링머신(Turing Machine, http://en.wikipedia.org/wiki/Turing_machine)과 람다대수(Lambda calculus, http://en.wikipedia.org/wiki/Lambda_calculus) 이다.

튜링머신은 앤런 튜링이라는 사람이 만든 컴퓨터의 모델로 기본적으로 무한한 메모리와 몇가지 명령어로 계산하는 컴퓨터의 수학적 모델이다. 너무 자세히 들어가면 복잡해 지니 기본적인 개념만 살펴보자. 기본적으로 튜링머신은 자신의 상태, 무한한 테이프, 다음에 읽을 테이프의 위치 그리고 입력과 상태에 따라서 다음 상태를 알려주는 상태표로 결정된다. 컴퓨터 구조에 익숙한 사람이라면 기본적인 폰 노이만 모델을 떠올릴 수 있을 것이다. 현대 컴퓨터로는 상태는 CPU의 register 값들, 테이프는 메모리, 다음에 읽을 위치는 PC, 상태전이표는 CPU명령어(어셈블리어 명령)에 대응한다. 이때 가장 중요한 특징은 순차적으고 메모리를 사용한다는 것이다. 이것은 명령형 프로그래밍 언어의 모델이된다. 즉, 메모리는 각각의 변수에 대응되고 순차적으로 상태를 바꾸는 것이 변수들의 값을 바꾸고 반복문과 조건문을 이용하는 것이 된다.

그렇다면 람다대수는 어떻게 되는 것인가? 람다대수도 튜링머신과 완전히 동등하게 컴퓨터를 묘사한다. 하지만 람다대수에는 메모리나 상태같은 것이 없다. 대신 함수를 통해 그것을 나타낸다. 또한 반복문 대신 재귀호출을 통해 연속된 것을 표현한다. 또한 함수는 가장 기본적인 형태로 함수가 함수의 인자로 들어가는 것이 매우 자연스럽다. 이것들이 가장 큰 특징이자 다른 점이다. 자세한 것을 실제 프로그래밍을 통해 알아보도록 하자.

하지만 보통의 프로그래밍 언어에서 이러한 두가지 방법이 완전히 구분되지는 않는다. 명령형 프로그래밍 언어라고 하더라도 어느정도 함수형 언어의 기능을 가지고 있고 함수형 프로그래밍 언어라고 하더라도 어느정도는 멍령형의 특징을 가지게 된다. 특히나 우리가 사용하는 컴퓨터는 튜링머신에 기반을 둔 모델로 만들어졌기 때문에 함수형 프로그래밍언어도 실행될때의 모습은 순차적인 명령형 프로그램을 수 밖에 없다.

다음부터는 Python과 Caml 프로그래밍 언어를 통해 두개의 다른 프로그래밍 언어들의 특징을 알아보도록 하자.

CGAL : Computational Geometry Librry

CECRI — Sun, 28 Nov 2010 03:43:57 +0900

http://www.cgal.org/

C++ 기반의 계산기하 라이브러리. 전에 컴과 졸업논문 쓰면서 했던게 이쪽 관련된거라 그때 한번 찾아보고 잊고 있었다. 전반적으로는 C++로 아주 잘 짜여진 수학 라이브러리이다. 소스도 공개되어 있으니 한번 분석해 보면 큰 도움이 될듯.

오늘의 삽질 : Android

CECRI — Mon, 30 Aug 2010 03:19:59 +0900

안드로이드로 주소록을 받아오는 것을 해 보고 있다. 기본적으로 이름과 전화번호를 받아 오는것을 만들고 있다. 생각으로는 단체문자하는 어플을 만들고 싶어서 모바일로 등록되어 있는 것만을 가져오고 싶다. 책에서는 People클래스를 이용하는데 deprecated되었다네. 그래서 다른 방법을 찾아보다가 발견한 페이지. http://androiddevblog.blogspot.com/2010/02/query-contacts-data.html 그래서 따라서 해 보았다.

        Cursor contacts = managedQuery(ContactsContract.Contacts.CONTENT_URI, null, "HAS_PHONE_NUMBER=1", null, null);
        MatrixCursor cursor = new MatrixCursor(new String[] {"_id", "name", "phone_number"});        startManagingCursor(cursor);
        if (contacts.moveToFirst()) {
        	String name;
        	String contactId;
        	int nameColumn = contacts.getColumnIndex(ContactsContract.Contacts.DISPLAY_NAME);
         	int idColumn = contacts.getColumnIndex(ContactsContract.Contacts._ID);
        	do {
        		name = contacts.getString(nameColumn);
        		contactId = contacts.getString(idColumn);
        		Cursor phones = getContentResolver().query(
        				ContactsContract.CommonDataKinds.Phone.CONTENT_URI,
        				null,
        				ContactsContract.CommonDataKinds.Phone.CONTACT_ID + "=" + contactId + " AND " +
         				ContactsContract.CommonDataKinds.Phone.TYPE + "=" + ContactsContract.CommonDataKinds.Phone.TYPE_MOBILE ,
        				null,
        				null);
        		if (phones.moveToNext()) {
        			String phoneNumber = phones
        			.getString(phones .getColumnIndex(ContactsContract.CommonDataKinds.Phone.NUMBER));
    				cursor.addRow(new String[] {contactId, name, phoneNumber});
        		}
        		phones.close();
        	} while (contacts.moveToNext());
        }        contacts.close();

쿼리도 두 번 뿐이고 잘 된다. 왠지 조인으로 한번에 하면 될 쿼리를 나눠서 하느나 좀 신경쓰이긴 하지만. 근데 작업 도중 Contacts 를 통해 접근해야만 하는 줄 알았던 DISPLAY_NAME이 ContactsContract.CommonDataKinds.Phone.에도 있는것을 알았다. 음? 설마 하는 마음에 다음과 같이 해 보았다.

        Cursor cursor = managedQuery(ContactsContract.CommonDataKinds.Phone.CONTENT_URI,
         		new String[]{ContactsContract.CommonDataKinds.Phone._ID, ContactsContract.CommonDataKinds.Phone.CONTACT_ID,
         			ContactsContract.CommonDataKinds.Phone.DISPLAY_NAME,
        			ContactsContract.CommonDataKinds.Phone.NUMBER},
        			ContactsContract.CommonDataKinds.Phone.TYPE + "=" + ContactsContract.CommonDataKinds.Phone.TYPE_MOBILE, null, null);
        startManagingCursor(cursor);

잘 된다... 결과도 똑같아... 난 결국 뭘한거지.. ㅠㅠ 알아서 조인해 주는듯 하다.

업뎃했으면서 변경된 사항도 예제랑 곁들여서 친절히 설명해주면 좋을것을...

윈도우 공유폴더 마운트가 안될때..

CECRI — Tue, 10 Aug 2010 17:41:58 +0900

mount -t cifs -o username=어쩌고,password=저쩌고 \\\\[윈도우 서버 아이피]\\[윈도우 서버 공유하는 디렉토리] [마운트한 경로]

로 마운트를 시도 했는데 mount error 20 = Not a directory 라면서 에러 났다.

echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled

라고 하면 된다고 한다. 그러고 나니 잘 되었다.

Linux에서 WebObjects돌리기

CECRI — Fri, 30 Jul 2010 03:39:39 +0900

http://wiki.objectstyle.org/confluence/display/WO/Installing+WO+5.3+or+WO+5.4+on+Linux

세줄요약

1) GNU자바 말고 SUN JAVA깐다

2) WOInstaller다운받아서 WebObjects라이브러리랑 쫙 깐다

3) 아파치 깔고 Adaptor설정...

JAVA JDK깔기

1. java.sun.com에 들어가서 최신버전으로 rpm.bin다운받아서 root 권한으로 실행하면 자동으로 깔린다.

2. 소프트링크로 /usr/bin/java->/usr/java/latest/bin/java(/usr/java/latest 는 자바 깔면 최신버전으로 걸리는 링크)

ln -s /usr/java/latest/bin/java /usr/bin/java

3. PATH설정. /usr/java/latest/bin추가 해 주면 된다. 즉 ~/.bash_profile에

PATH=$PATH:/usr/java/latest/bin

export PATH

추가

WebObject깔기


wget http://webobjects.mdimension.com/wolips/WOInstaller.jar

한 다음


sudo /usr/java/jdk1.5/bin/java -jar WOInstaller.jar 5.4.3 /opt


sudo groupadd appserveradm
sudo useradd -g appserveradm appserver


chown -R appserver:appserveradm /opt/Local
chown -R appserver:appserveradm /opt/Library
chmod 750 /opt/Library/WebObjects/JavaApplications/JavaMonitor.woa/JavaMonitor
chmod 750 /opt/Library/WebObjects/JavaApplications/wotaskd.woa/Contents/Resources/SpawnOfWotaskd.sh
chmod 750 /opt/Library/WebObjects/JavaApplications/wotaskd.woa/wotaskd


[root@ ~]# su - appserver

appserver계정의 .bash_profile에 NEXT_ROOT=/opt; export NEXT_ROOT 추가


[appserver@ ~]$ $NEXT_ROOT/Library/WebObjects/JavaApplications/wotaskd.woa/wotaskd &
[appserver@ ~]$ $NEXT_ROOT/Library/WebObjects/JavaApplications/JavaMonitor.woa/JavaMonitor -WOPort 56789 &

Apache깔기

개인적으로 컴파일해서 까는걸 추천. 이는 구글 검색 ㄱㄱ configure때 --enable-so 옵션을 주는게 나을듯. 이미 깔려있고 apxs까지 있으면 상관 없음 ㅇㅇ

HTTP Adaptor

WebObjects 아답터를 위한 아파치 모듈을 설치해야함

wget http://webobjects.mdimension.com/wonder/Wonder-latest-Source.tar.gz

이 안의 Utilities/Adaptor 에서 make를 해야 하는데 설정을 좀 바꿔줘야 함 make.config에서 ADAPTOR_OS를 LINUX로 바꾸고 make할때 옵션 좀 줘야 함. apxs가 기본적으로 PATH에 들어 있으면 상관 없는데 아니면 경로를 지정 해 줘야 함.

[root@ Adaptors]# make CC=gcc APXS="/usr/local/apache2/bin/apxs"
[root@ Adaptors]# cd Apache2.2/
[root@ Apache2.2]# apxs -i -a -n WebObjects mod_WebObjects.la
[root@ Apache2.2]# cp -rp /opt/Local/Library/WebServer/Documents/WebObjects /usr/local/apache/htdocs
[root@ Apache2.2]# cp apache.conf /usr/local/apache/conf/extra/webobjects.conf

요럼 Adaptor설치 완료.

Apache설정 바꾸기

http://wiki.objectstyle.org/confluence/display/WO/Installing+WO+5.3+or+WO+5.4+on+Linux#InstallingWO5.3orWO5.4onLinux-ApacheConfiguration

그냥 똑같다.

WOTaskd랑 WOMonitor자동시작

http://wiki.objectstyle.org/confluence/display/WO/Installing+WO+5.3+or+WO+5.4+on+Linux#InstallingWO5.3orWO5.4onLinux-AutoStartWOTaskdandWOMonitor

이것도 다를게 없다.

다음에는 standart deploy를 통해 실제 WebObjects 웹페이지를 돌리는 것을 보도록 하자.