Star Wars Episode 3: Revenge of the Sith

스타워즈와 같은 흥행예상작들을 개봉일 근처에 보기는 힘들다. 금방 매진이 되어버리고, 설령 표를 구할 수 있다고 하더라도, 자리가 그다지 좋지 못하고, 결정적으로 나는 좋은 표를 구할 수 있을 정도로 성실하지는 못하기 때문에, 그런 영화들은 개봉 후 2-3주 후에나 보는 편이다. 그래서 난 개봉일을 가상적으로 늦출 수 있는 능력을 지니고 있다. 이번에도 역시 시간 왜곡 드라이브를 가동중이엇는데, 마침 여자 친구에게 열받은 친구 녀석이 보여준다고 해서 좋다거니 따라나섰다. 대전 CGV 5관이었고, 지난 목요일 심야 23시 30분 프로였는데도, 사람들이 꽉 들어찼다. 자리는 역시 그다지 좋은 편은 아니었다. 그렇다고 친구의 성의를 무시하고 나와버릴 만큼 나쁜 것도 아니어서 다음번에 한번 더 보면 되겠거니 하고 참고 봤다.

스타워즈 팬은 아니더라도 (팬을 자처하는 사람들이 너무 많아서 그렇게 불리기도 싫다), 어느 정도 스타워즈에 대해서는 관심이 있는 편이기 때문에, 3편의 스토리도 어느 정도 알고는 있었다. 3편에서 기대한 것은, (2편에서 이미 예고한) 우주에서의 함대 전투, 사건의 세부적인 전개 상황과, 다쓰 베이더의 탄생 장면이었다.

도입부를 장식하는 것은 분리주의자들과 공화국의 우주 함대전이다. 기본적으로는 오비완과 아나킨의 침투 장면이지만, 그 배경을 장식하는 함대전은 그야말로 시리즈 중 최고의 비주얼을 선보였다. 다시 한번 스타워즈를 볼 기회가 생긴다면, 비주얼에 집중해서 봐야할 듯하다.

한편, 제다이 원탁 회의에서 염려하고 있었듯이, 아나킨은 팰퍼틴 의장에 의해 다크 사이드의 유혹을 지속적으로 조금씩 받고 있었고, 거기에 파드메의 죽음에 대한 예견이 더해져 자신의 선택에 대해 조금씩 의심을 가지기 시작한다. 아나킨의 변절 장면에서도 아나킨은 어느 쪽을 결정했다기보다는 흔들리고 있는 처지였다. 주어진 상황이 어쩔 수 없이 아나킨의 결정을 요구했고, 그는 (결과적으로) 윈두를 죽인 후 외친다. "What I’ve done!". 그 한순간의 결정에 따른 상황의 변화가 아나킨의 미래를 지배해버렸다. (마치, 약혼자를 죽일 계획으로 약혼자를 데리고 차를 몰고 있었으나, 아직도 마음이 흔들리고 있는 도중, 의도치 않은 자동차 사고가 나고 약혼자는 죽어버렸다는 식.) 그 순간에 아나킨은 팰퍼틴을 죽이고 자신의 실수를 인정할 수 있었을까. 아니, 그렇지 않다. 자연주의(naturalism) 소설에서 자주 등장하는 레퍼토리. 하지만, 이 장면에서 아나킨이 몇초 가량 괴로워하다가 바로 팰퍼틴에게 무릎을 꿇는 것은 매우 부자연스러워 보였다. 다만 아나킨이 약삭빨라서인가.

강력한 포스를 가지고 있으면서도 라이트 사이드와 다크 사이드 사이에서 갈등한다는 아나킨의 캐릭터의 설정 자체는 좋다고 생각한다. 하지만, 좀 더 설득력있게 그리고 매력적으로 그릴 수 있었을텐데, 아나킨의 심리를 보여주는 방식에 뭔가 부족한 느낌이 든다.

다쓰 베이더의 탄생 장면은 그야말로 팬들의 탄성을 절로 자아내게 하는 장면이었을테다. 어디서든 다쓰 베이더의 그 숨소리만 들려도 팬들은 즐거워할텐데, 그 첫번째 숨소리라니! 다쓰 베이터의 탄생 장면을 보면서 깨달은 것은 이 영화는 바로 다쓰 베이더의 탄생을 위해서 만들어졌다는 것이었다. 다쓰 베이터의 탄생을 설명하기 위해 너무나 많은 스토리를 짧은 시간 내에 담으려고 허겁지겁 스토리를 진행한 느낌이 많이 들었다. 무엇보다도 캐릭터들의 진실성이나 매력이 와닿지 않았고, 그것은 캐릭터의 감정이나 심리를 표현하는데 충분한 장면을 할당하지 못했기 때문에, 충분한 감정이입이 이루어지지 못했기 때문이라고 생각한다. 그런 몇 장면을 꼽아보자면, 일단 방금 얘기했던대로 아나킨의 변절 장면에서의 아나킨의 급격한 심리 변화는 납득하기가 힘들었다. 또한, 아나킨과 오비완의 결투 장면에서도, 싸움을 하면서 나눈 몇마디 대화가 아나킨과 오비완의 심정을 포용하지 못하는 느낌이 들었다. (오비완이 아나킨을 이길 수 있었던 이유도 너무나 허술하지 않은가.) 후일의 영웅이 될 쌍둥이들을 출산하는 파드메의 장면에서도 마찬가지였다. 연출력이 모자란 것인지 연기력이 모자란 것인지.

덧붙여, 그리버스라는 캐릭터도 반동 캐릭터로서는 너무 부족한 느낌이 들었다. 전투를 좀 잘하는 드로이드일 뿐 그 이상의 매력은 없었다. C3PO나 R2D2의 인간미 넘치는 캐릭터라든가 인간이면서도 제다이와 대결이 가능한 장고펫 같은 캐릭터와는 대조적이다.

한 마디로 이번 영화를 평하자면, 친구에게도 얘기했듯이, 비주얼은 역대 최고, 드라마는 역대 최악이다.

Star Wars Episode 3: Revenge of the Sith 더 읽기"

황우석

황우석을 바라보는 일관된 방법
http://yeinz.pe.kr/blog/index.php?page=3
황교수 논문 있는그대로 보기!
http://goodking.new21.net/bbs/rgboard/view.php?&bbs_id=0002&page=&doc_num=400
과학기술의 덫에 갇힌 언론
http://www.greenreview.co.kr/archive/80KangYanggu.htm

황우석 더 읽기"

Is PHP A Bad Programming Langauge? (Part 2)

Hatred for PHP

대부분의 사람들은 PHP가 표방하는 PHP의 철학에 동의한다. 그렇다면 무엇이 싫단 말인가? 웹 검색을 통해서 다음과 같은 글들을 발견할 수 있었다.

이 사람들은 PHP를 미워하고 있다. 그 이유는? 어느 정도 유효하고 중요한 내용들만 내 생각들과 함께 정리해보았다.

Language Syntax

  • No namespaces: 어느 정도 복잡한 product를 만들 때, 불편한 점 중의 하나는 함수 이름이나 변수 이름이 중복되는 것이다. 이 문제에 대한 해결책으로, 모든 함수나 변수들의 이름에 prefix를 붙여서 namespace를 구분하거나, 클래스를 namespace의 대용으로 사용하는 방법이 있다. C와 같은 다른 언어들을 생각해보면, 분명히 namespace가 없이도 커다란 프로덕트를 만드는 것은 가능하다. 하지만, 최근에 나온 대부분의 언어가 namespace를 가지고 있음에도 불구하고 PHP 5에 namespace가 들어가지 않은 것은 상당히 아쉬운 부분이다.
  • Arrays are ordered maps: PHP의 array는 기본적으로는 key, value pair의 집합인 ordered map이다. PHP의 array는 이러한 map의 용도 뿐만 아니라 여러 용도로 전용된다. integer를 key로 하는 전통적인 array를 비롯하여, list, queue, stack 등으로 사용될 수 있다. 이러한 사실은 array function들을 ë³´ë©´ 알 수 있다. 언어가 단순해지고, 여러가지 데이터형으로 활용함으로써 얻는 편리한 점도 있겠으나, 프로그래머가 array라는 데이터형에 대한 명확한 모델을 머리속에 그리지 못하게 하고, 또한 프로그래머가 실수를 할 가능성을 높힌다는 측면에서 그리 좋지 못하다고 생각된다. 많은 언어들이 array와 map을한다. 하지만, 그렇다고 string 만으로 array를 지원하는 언어들을 무시할 수는 없다. 어떤 데이터형을 지원하는가 하는 문제는 언어의 단순성과 프로그래머의 편이성 사이의 trade-off 문제라고 생각한다. 어떤 언어가 어떤 데이터형을 지원하느냐는 ê·¸ 언어의 철학에 달린 일이고, 정답이 있는 것은 아니다.
  • Does not enforce the declaration of variables: PHP는 선언 또는 정의되지 않은 변수이더라도 참조가 가능하다. (물론 warning은 발생한다.) "<? print $undeclared_variable; ?>"라는 PHP 코드와 "print undeclared_variable"이라는 Ruby 코드를 실행해보라. PHP에서는 아무렇지 않은 듯이 조용히 실행되지만 Ruby에서는 "undefined local variable or method"라는 에러가 발생한다. 비교적 작은 프로그램, 모듈, 또는 함수에서는 큰 문제가 되지 않지만, 코드가 길어지고 복잡해질 수록 버그를 발생시킬 가능성이 높아지고, 이 버그를 발견하는 것도 힘들어진다. PHP에서는 옵션을 통해 정의되지 않은 변수 접근에 대한 경고를 켤 수 있다.
  • No real references: reference가 아니라 name alias일 뿐이기 때문에 여러가지 문제가 발생한다. http://www.php.net/manual/en/language.references.php
  • No chained method call: $foo->bar()->op() 같은 문법이 불가능했었다. PHP 5에서 가능해졌다.
  • No closure, not even anonymous functions
  • shortcut behavior: 다른 언어들과는 달리 shortcut의 결과값이 boolean 값이다.
  • call-time pass-by-reference deprecation: PHP에서 reference를 사용하는 문법은 매우 이상했다. function을 정의할 때 파라미터에 reference임을 나타낼 수도 있고, 실제로 호출을 수행할 때도 reference임을 나타낼 수 있었다. 이 점은 기존 PHP 문법이 상당히 불완전함을 나타내는 증거라고 ë³¼ 수 있는 것 같다. (예를 들어, function 정의의 파라미터에도 reference라고 명시하고, 호출 시 아규먼트에도 reference라고 명시한다면 어떻게 될 것인가. reference의 reference? 답은, 그냥 reference다.) 결국은 호출 시 reference 명시는 deprecated 되었다. 문제는 이 deprecation으로 기존에 할 수 ì
    žˆì—ˆë˜ 일을 할 수 없게 되어버렸다는 것이다. PHP 5에서는 모든 variable을 reference semantic을 가지도록 바꾸었기 때문에 더이상 이런 문제는 없을 것이다.

Language Implementation

  • Template: 대부분의 언어들은 templating을 언어의 구현과 분리해놓지만, PHP의 구현에는 완전히 합쳐져있다. 웹 어플리케이션의 규모가 커지면서 프리젠테이션과 로직의 분리가 중요해진 지금 시점에는 그다지 좋지 않은 방법이다.
  • Register Globals: Register Globals는 CGI를 통해 들어오는 리퀘스트 변수들을 전역 변수로 만들어주는 기능이다. namespace를 가지지못한 PHP로서는 전역 namespace를 더럽히는 것은 엄청나게 해로운 일이다. 물론 여기에는 "웹 프로그래머의 편이"라는 언어가 만들어지던 당시의 고려가 담겨있다. 하지만, 웹 어플리케이션의 규모가 커지면서 이 기능은 PHP를 해치는 기능이 되어버렸다. 최근에는 이 기능을 켜고 끌 수있는 옵션의 기본 값이 "끄는 것"으로 바뀌었다.
  • Bad recursion support: 스피드를 위해서 stack에 저장하는 데이터가 많기 때문에 recursion에 좋지 않다.
  • Not thread-safe: 구현을 ë³´ë©´ thread safety를 위한 노력을 하고 있으나, 실제로 thread-safe 하지는 않다.
  • Magic quotes: Magic quotes는 PHP가 사용하는 데이터에서 특정 문자들을 자동으로 escaping 해주는 기능이다. 프로그래머가 직접 하더라도 크게 불편하지 않은 작업을 굳이 자동으로 해주어서 복잡도를 증가시키는 것은 좋지 않은 기능인 것 같다.

Standard Library/3rd-party Library/Framework

  • Inconsistency: PHP에서 기본으로 제공되는 라이브러리에 들어있는 함수들의 이름이나 파라미터들은 상당히 일관성이 없다. 다음 링크 참조.
  • no crucial XXX library: html parser, MIME builder, WWW library, consistent database API, gd를 제외한 graphics library가 없다는 것을 불만스러워하고 있다. PEAR에서 어느 정도 해결되기를 기대해본다.
  • no CPAN: 현재는 PEAR가 공식적인 extension repository가 되었으나, CPAN 처럼 사용하기에 편리한 것은 아니다.

People

  • Knowledgeable people are in a serious minority: 외국의 PHP 커뮤너티조차도 수준이 낮다는 지적을 많이 받고 있는데, 내가 보기에는 국내의 PHP 커뮤너티ë
    „ 크게 다르지 않은 것 같다. 가장 유명하다는 PHPSCHOOL에 가보라.

Is PHP A Bad Programming Langauge? (Part 2) 더 읽기"

셔플에 불여우 설치하기

요즘 들어 휴강이 많아져서, 월/수요일 같은 경우에는 4시간 가량의 공백이 생긴다. 과 전산실에서 웹브라우징을 하는데, 탭브라우징을 지원하는 불여우(Firefox)를 사용하다가 IE를 사용하려니 너무 불편했다. 과 전살실의 컴퓨터에서는 일반 사용자가 프로그램을 설치할 권한이 없다. 문득 USB 드라이브에 불여우를 설치해서 사용한단 얘기가 생각나서 셔플(Shuffle)에 설치해보기로 마음먹었다.

USB 드라이브에 불여우를 설치하는 방법은 두가지가 있는 것 같았다. PC의 불여우 설치본을 그대로 복사하는 방법USB 드라이브에 설치하는 용도로 따로 만들어진 패키지를 이용하는 방법이다. 나는 전자를 선택하기로 했다.

이 방법을 간단히 설명하면,

  1. 그냥 PC의 불여우 디렉토리를 그대로 셔플에 복사하고,
  2. 불여우의 프로파일 디렉토리도 복사한 다음,
  3. 불여우를 실행할 때 프로파일 디렉토리를 지정해주는 배치 파일 하나를 만들어주는 것이다.

난 프로파일 디렉토리를 복사하지 않고, 그냥 빈 디렉토리만 만들어주고 배치 파일에 그 상대 경로를 넣어주었다. 아무 문제 없이 디폴트 프로파일이 생성되었다.

역시 탭브라우징을 사용할 수 있게 되니, 웹브라우징이 훨씬 편리했다.

한가지 문제는, USB 드라이브 상의 불여우의 정보 – 북마크를 어떻게 PC와 Sync 하느냐 하는 것이다. 이 문제는 회사와 집 두군데에 정보를 분산해놓는 문제와 같은 것이다. 그 문제에 대한 내 해결책은 인터넷 상에 정보를 두는 것이었고, 이번에도 같은 방식으로 해결하면 될 것 같다.

셔플에 불여우 설치하기 더 읽기"

Refactoring traditional web application with MVC pattern (Part 1)

Introduction

어떤 practice가 보편화되어있고 그것을 보조하는 툴이나 생각의 장치들이 잘 발달되어 있다면, 오히려 그 practice의 장점이 무엇인지 파악하는 데에는 방해가 되기도 한다. 어떻게 보면, 생산성을 높히고자 하는 우리의 노력이 때로는, 각 개인의 능력을 키우는 데에는 방해가 될 수도 있는 것이다.

예를 들어, 잘 만들어진 소프트웨어 프로세스 환경에만 익숙한 개발자는, 그러한 프로세스가필요없다고 주장하는 사람에게, 그것이 왜 필요한지 제대로 설명하지 못할 것이다.현대의 특정 프로그래밍 언어에만 익숙한 사람은, 자신이 활용하고 있는 수많은 언어적 장치들의 이점을 제대로 이해하고 있지 못할 가능성이 높다.

마찬가지로, 잘 만들어진 Model-View-Controller(이하 MVC) 프레임워크에만 익숙한 사람이라면, 그 패턴이 가지고 있는 유용성이나 의미를 발견하지 못할 가능성이 높다. 대부분의 웹 어플리케이션 개발자들은, 프리젠테이션과 로직이 뒤섞인 기존의 웹 어플리케이션에만 익숙하거나, MVC 프레임워크 웹 어플리케이션에만 익숙하다. 기존의 웹 어플리케이션이 MVC를 사용함으로써 어떤 점에서 좋아질 수 있는지는 전자나 후자의 프로그래머들 모두 알지못할 가능성이 높다.

이 글의 목적은 기존의 웹 어플리케이션에 MVC 패턴을 적용하면서 리팩토링하는 과정을 보임으로써, MVC 패턴의 유용성을 재발견하는데 있다.

Galaxy

Galaxy는 개인적으로 개발중인, RSS를 주기적으로 받아와서 사용자에게 보여주는 웹 어플리케이션이다. 이 글에서 예로 들 부분은 Galaxy의 admin 모듈이다. 이 모듈의 기능은 다음과 같다.

  • 사용자는 자신이 구독할 RSS Subscription을 등록, 삭제하거나 조회, 수정할 수 있으며,
  • 각각의 Subscription에는 Category를 할당할 수 있다.
  • 이 Category 역시 등록, 삭제, 조회, 수정될 수 있다.
  • 그리고, 사용자는 전체 Subscription을 수동으로 업데이트할 수 있다.

Galaxy in traditional-web-application style

일단 Galaxy의 첫번째 버전에서는 Subscription을 등록하는 기능만 제공하기로 결정했다고 가정해보자. 자, 먼저 Subscription을 등록하는 폼을 보여주고 사용자가 정보를 입력하고서 폼을 submit하면 Subcription 정보를 DB에 저장하는 로직을 처리하는 어플리케이션을 생각해보자.

자신을 Perl CGI나 PHP, ASP 등을 사용하는 웹 어플리케이션이 막 퍼지기 시작하던 시절의 웹 프로그래머라고 가정해보자. 필요한 기능은 그다지 많지 않고 로직도 단순하다. 그 시절에 방명록 따위를 심심풀이로 짜본 경험이 있다면, 금방 감이 올 것이다. 파일 이름은 admin.rb라고 하자. (Galaxy는 Ruby 어플리케이션이므로, 예제 역시 Ruby 언어를 사용한다. 간단한 템플리팅(templating)을 위해 eruby를 사용한다고 가정하자.) 웹어플리케이션이라는 신기술을 다룰 줄 아는 우리가 생각해낸 코드는 아마 다음과 같을 것이다.

Traditional-web-application-style Galaxy

즉, ‘mode’ 리퀘스트 파라미터가 없을 때는 Subscription 등록을 위한 양식(form)을 보여주고, 이 양식이 submit되면 ‘mode’ 리퀘스트 파라미터가 설정되어 Subscription 등록을 처리하는 방식이다.

이 코드에 어떤 문제가 있는가? 그렇지 않다. 문제는 없어 보인다. Subscription 등록이라는 단순한 기능을 수행하는 목적의 어플리케이션으로서 이 이상의 무언가를 필요로 한다면, 그게 더 이상한 것이다.

이제 다시 질문을 하겠다. 이 코드에 어떤 문제가 있는가? 그렇다. 이 어플리케이션은 현재는 Subscription 등록이라는 단순한 기능밖에 없지만, 앞으로 위에서 언급했던 여러 기능들을 모두 넣어야하는 미래를 가지고 있다. 자 여기서 약간의 상상력이 필요하다. 이 기능들을 하나씩 추가할 때마다, 리퀘스트 파라미터에 따라 분기하는 if-else-end 구문은 엄청나게 길고 복잡해져갈 것이다.

그리고, 이 어플리케이션은 웹 어플리케이션임을 기억해야한다. 위의 예에서는 html이 별로 사용되지 않았지만, 실제 서비스에 적용하기 위해 웹 디자이너가 던져준 화려한 페이지의 html 마크업은 훨씬 복잡할 것이다. 기존의 웹 어플리케이션은 프리젠테이션을 위한 html 마크업과 도메인 로직을 위한 코드가 복잡하게 뒤섞이는 경향이 있다.

웹 어플리케이션의 또 한가지 중요한 특징은, 로직의 변경 빈도와 프리젠테이션의 변경 빈도가 현저히 차이난다는 것이다. 커다란 리뉴얼부터 자잘한 수정까지 html 마크업은 코드에 비해 자주 변경된다. 문제는 html 마크업과 코드가 뒤섞여있음으로 인해, 잦은 html 마크업의 변경은 필연적으로 코드, 그 중에서도 가장 중요한 도메인 로직의 버그 가능성을 낳게 된다.

결국, 우리에게는 프리젠테이션과 도메인 로직의 분리(decomposition)가 필요하다.

Extracting domain objects

위의 예에서 도메인 로직은 어떤 부분인가? 바로 "Subscription을 등록하는 것"이다. 도메인 로직을 프리젠테이션으로부터 분리해내는 방법에는 여러가지가 있겠지만, 우리는 객체지향언어를 사용하고 있으므로, 도메인 로직을 도메인 객체(domain object)의 형태로 분리해내는 방법을 채택하자. "Subscription을 등록하는 것"에서 도메인 객체는 무엇일까? 바로 Subscription이다.

Subscription 객체를, 우리가 사용하고 있는 Ruby로 표현하기 위해서는 클래스를 사용하면 되겠다.

Subscription class as domain object

그리고, 기존 코드는 Subscription 객체를 사용하도록 바뀔 것이다.

Using Subscription object

이로써 원래 코드에 있던 도메인 로직 부분을 몽땅 하나의 클래스로 분리해낼 수 있게 되었다. 변경된 admin.rb에는 클래스 하나와 훨씬 간단해진 나머지 코드가 남게되었다. 또한, 프리젠테이션을 자주 변경해도 DB에 도메인 정보를 저장하는 걸 빠뜨리거나 할 가능성은 훨씬 줄어들게 되었다.

MVC 패턴에서는 도메인 정보를 나타내거나 그것을 처리하는 역할을 하는 도메인 객체를 Model이라고 부른다.

Refactoring traditional web application with MVC pattern (Part 1) 더 읽기"

MovableTypeWriter with XStandard

제가 만든 MovableType의 클라이언트인 MovableTypeWriter를 약간 손봤습니다. 에디터로 사용하던 mshtml전에 한번 언급했던 XStandard로 바꾸었습니다.

MovableTypeWriter with XStandard (Visual editing)

MovableTypeWriter with XStandard (XHTML editing)

바꾸는 작업은 그리 어렵지 않았습니다.XStandard Lite를 설치하는 것부터, 프로젝트에 XStandard COM component에 대한 Reference를 추가해주고 10라인 정도의 코드를 수정하는 작업까지 어저께 오전 1-2시간 만에 끝났습니다. 그리고, Doodle Bug부터 지금 쓰는 글까지 모두 새로운 MovableTypeWriter를 사용해서 작성했죠. XHTML 1.0 표준에 호환되는 코드를 생성하는 것을 확인하니 매우 기분이 좋더군요.

어떤 분들은 이 블로그의 오른쪽 메뉴바에 XHTML 1.0 표준 호환 배너가 달렸다는 것을 눈치채셨는지도 모르겠습니다. (무려 XHTML 1.0 Strict 입니다.) 배너에 해당 페이지의 Markup Validation Service가 링크되어있으니, 호기심이 많으신 분들은 테스트해보셔도 되겠습니다. (그러고보니 XHTML 1.1이 아니라 왜 XHTML 1.0일까요? 기본 템플릿의 Doctype이 XHTML 1.0으로 되어있었던 모양입니다. 이것도 손봐야겠군요.)

덤으로 MT의 템플릿과 최근 글 내용들이 표준에 호환되도록 좀 손봐주었습니다. 표준에 호환되지 않는 예전 글들이 많아서, 손으로 일일이 바꾸기 보다는, 적당한 툴을 사용해서 한번에 손봐야할 것 같습니다.

MovableTypeWriter with XStandard 더 읽기"

Firefox extension: SessionSaver and Adblock

SessionSaverAdblock은 최근에 쓰기 시작한 Firefox extension입니다.

뉴스 사이트에서 읽을 거리를 탭으로 먼저 열어놓은 다음 하나씩 읽는 스타일이기 때문에, Firefox를 닫아야만 하는 상황일 때, 남아있는 탭은 골칫거리입니다. Firefox의 시작 페이지 기능을 (시작페이지를 현재 페이지를 설정하면 모든 탭이 저장되죠.) 사용해보기도 하고, 북마크로 일일이 저장해주는 방법도 사용했었습니다만, 불편한 건 어쩔 수 없었습니다. SessionSaver는 Firefox를 닫을 때 자동으로 탭들을 저장해주고, 다음에 Firefox를 시작할 때 복구해줍니다. 특히 여러 Firefox 인스턴스가 떠 있을 때, 윈도우를 종료하더라도, Firefox를 띄우면 원래대로 복구되더군요. 여기에 더해서 현재 세션(탭 상태)을 따로 저장하거나 저장된 세션을 간편하게 복구할 수도 있습니다.

Adblock인터넷 한겨레가 개편되면서 많아진 Flash 광고를 제거하기 위해서 쓰기 시작했습니다. (IE에서 보면 Flash 위치가 제대로인데, Firefox에서 이상한 위치에 나타나는 경우가 여러 사이트에서 종종 보이더군요.) URL의 패턴을 사용해서 이미지나 링크 등을 막을 수 있습니다. 특히, 페이지 상의 Flash에 마우스를 갖다대면, 그 옆에 “Adblock” 이라는 버튼이 나와서, 패턴을 사용하지 않고도 바로바로 막을 수 있도록 하는 기능을 제공하고 있습니다. 상당히 편리하고 유용합니다.

Firefox extension: SessionSaver and Adblock 더 읽기"

"무진기행"에 관한 노트

무진은 어디에 있는 도시인가? 안개가 많은 도시라는 것을 볼 때, 바닷가 근처거나 호수가 있는 내륙지방(강원도)의 느낌이 난다. 읽다보면, 호남지방인가 하는 생각도 잠시 든다. 어디에 있는 도시인가는 별로 중요하지 않고, 오히려 별로 알려지지 않은 점이 중요한 것인가? 도시로부터의 도피처? 실락원?
영화 “생활의 발견”와의 관련성. 지방 도시에서 만난 여선생과의 정사라는 스토리라인. “우리 서로 솔직해지기로 해요”라는 대사.
서울과 무진의 공간적 대비. 서울은 이성이 지배하는 공간. 무진은 욕망이 지배하는 공간. 자의식과 무의식. 욕망(비이성)에의 옹호? 주인공의 이중성 자체도 비이성?
부조리극. Camus. 타인의 속물적 행동에 대한 비판과 주인공 자신의 속물적 행동.

"무진기행"에 관한 노트 더 읽기"

르네 지라르와 악마

“문학의 이해” 수업 시간에 전봉관 교수님(황금광시대의 저자)이 르네 지라르의 욕망의 구조 분석에 관한 얘기를 잠깐 언급하셨다. 간단히 말해서, 욕망의 대상으로의 욕망은 욕망의 매개와의 관계 속에서만 형성된다는 얘기다. “삼각형”이 나오는 걸로 봐서는 구조주의 쪽의 사상으로 보인다. 과학적 근거가 제대로 있는지는 궁금하지만, 일변 설득력이 있는 흥미로운 얘기다.
제프리 버튼 러셀의 “악마의 문화사”라는 책도 언급하셨다. 이 책의 저자는 악의 이해를 통해서, 선을 이해하려는 노력을 하고 있다고 한다. 저자는, 하느님이 악마를 창조한 것은 하느님의 전능성을 부정하는 것이 아니냐라는 주장에 대한 “반박” 중, 아퀴나스의 설명을 가장 설득력 있는 것으로 언급하고 있단다. 그 설명이란, 하느님이 “악”을 창조한 것이 아니라, 어떤 상황에 놓여있는 인간의 상대성이 선과 악을 창조한다는 것이다. 난 중세철학을 폄하하는 선입견을 가지고 있었는데, 그것은 순전히 무지로부터 나온 것인 듯 하다. 공부해볼 것.

르네 지라르와 악마 더 읽기"

Ronald Baker – Doodle Bug

어저께 학교를 돌아다니며 Shuffling을 하다가 발견한 곡입니다. 아무리 우울하더라도, 이런 흥겨운 곡을 들으며 하루를 시작하면 기분이 좋습니다.

Ronald Baker – Doodle Bug

날씨도 한 몫 하는군요. 더구나 날씨는 이번주 내내 좋을 것 같구요.

주말엔 우울했는데, 음악과 날씨 덕분에, 즐겁습니다! 오늘부터 축제도 시작한다지요.

KAIST

Ronald Baker – Doodle Bug 더 읽기"