July 2004 Archives

http://www.joelonsoftware.com/items/2004/03/25.html

DB가 모든 어플리케이션의 필수요소가 된 때에, SQL과 Programming Language의 gap이 아직도 크다는 점을 지적하고 Programming Language가 적극적으로 이를 메꾸기 위한 방향으로 나가야한다는 내용. 아래에 원문과 대충 번역한 내용이 있다.

Related links:

• Anders Hejlsberg - Programming data in C# 3.0: C# 3.0(정확히는 .Net langauges)이 general purpose/object oriented syntax로 data를 programmable하게 만드는데 초점을 맞추고 있다는 내용.
• Comega language: Cw is a research programming language. It can be written (and searched for) as Cw or the "Comega language". Cw is an extension of C# in two areas: 1) A control flow extension for asynchronous wide-area concurrency, 2) A data type extension for XML and table manipulation. (다음 기회에 이에 대한 포스팅을..)

March 25, 2004

Thanks to everyone who came to the open house last night. If you have pictures, send me a link!

We had an interesting conversation about how the impedance mismatch between contemporary high-level programming languages (Java, C#, Python, VB) and relational databases. Since a huge percentage of code requires access to databases, the glue (a.k.a. the connecticazoint) between the RDBMS layer and the application code is very important, yet virtually every modern programming language assumes that RDBMS access is something that can be left to libraries. In other words, language designers never bother to put database integration features into their languages. As a tiny example of this, the syntax for "where" clauses is never identical to the syntax for "if" statements. And don't get me started about data type mismatches: just the fact that columns of any type might be "null" leads to an incompatibility between almost every native data type and the database data types.

하이레벨 프로그래밍 언어에서 RDB 지원이 안되는 것에 대해 얘기를 나누었다. 많은 코드들이 DB를 사용하기 때문에 RDB와 App 코드의 접목은 중요하지만, 요즘 언어들은 전부 라이브러리에게 그 역할을 맡기고 언어상의 DB integration을 꺼리고 있다. 예를 들면 SQL의 where절 문법과 if syntax는 너무나 차이가 많이난다. data type도 마찬가지다.

The trouble with this is that the libraries (think ADO, DAO, ODBC, JDBC, embedded SQL, and a thousand others) need to be general purpose to be reusable, and yet what you really want is a mapping between a native data structure and a table row or query result row. Inevitably, you have to hand roll this mapping and wire it up manually, which is error prone and frustrating

RDB에 접근하기 위한 라이브러리들이 재사용 가능하려면 범용적이어야 하지만, 우리가 진짜 원하는건 native data type 과 table row, query result row와의 mapping이란 거다. 결국 전부 손으로 해야하고, 이런건 구리다.

I think this is a fatal flaw in language design, akin to the bad decision by the designers of C++ that it was not necessary to support a native string type. "Let a thousand CString/TString/String/string<char> types flourish," they said, and then spent more than a decade adding new features to the language until it was marginally, but not completely, possible to implement a non-awful string class. And now we have a thousand string types (most large C++ bodies of code I've seen use three or four) and a bunch of really good books by Scott Meyers about why your personal hand-rolled string class is inadequate. It's about time that a language designer admitted that RDBMS access is intrinsic to modern application implementation and supported it in a first-class way syntactically.

난 이게 언어 디자인 상의 치명적인 결함이라고 생각한다. C++에서 string type을 native로 지원하지 않은 문제와 마찬가지다. CString/TString/String/string<char> 타입들을 맘대로 만들도록 두자고 얘기하고는 새로운 기능을 추가하는데만 신경써왔다. 이제 수많은 string type들이 생겼고, 스콧 마이어 아저씨는 따로 자기가 만든 string class는 부적합하다고 말한다. 이제 언어 디자인하는 인간들이 RDB 지원은 app에 기본적인 요소이고 맨먼저 문법적으로 지원되어야 함을 인정할 때다.

Now for all the disclaimers to prevent "but what about" emails. (1) in functional languages like lisp the syntax layer is so light that you could probably implement very good RDBMS shims in ways that feel almost native. Especially if you have lazy evaluation of function parameters, it's easy to see how you could build a "where" clause generator that used the same syntax as your "if" predicates. (2) Access Basic, later Access VBA, had a couple of features to make database access slicker, specifically the [exp] syntax and the rs!field syntax, but it's really only 10%. There are probably other niche-languages or languages by RDBMS vendors that do a nice job. (3) Attempts to solve this problem in the past have fallen in two broad groups: the people who want to make the embedded SQL programming languages better (PL/SQL, TSQL, et al), and the people who want to persist objects magically using RDBMS backends (OODBMSes and object persistence libraries). Neither one fully bridges the gap: I don't know of anyone who builds user interfaces in SQL or its derivatives, and the object persistence implementations I've seen never have a particularly good implementation of SELECT.

1) functional language에선 syntax layer가 가벼워서 좋은 RDBMS shim을 만들어 거의 native하게 느낄 수 있을 거다. 특히 lazy evaluation이 있다면 if 절과 같은 문법으로 where 절 생성기를 만들기도 쉬울 것이다..

2) Access Basic/VBA는 DB access를 위한 여러가지 기능이 있지만 10%정도일 뿐이다. 아마 다른 더 좋은 언어들이 있을 것이다.

3) 이 문제를 해결하기 위한 시도에는 두가지가 있었다.

embedded SQL 프로그래밍 언어를 만들자는 쪽과 RDBMS backend를 이용해 object persistence를 만들자는 쪽.

어느쪽도 gap을 완전히 메꾸지는 못했다. SQL로 user interface를 만드는 사람을 한명도 모를뿐만 아니라 내가 본 object persistent 구현 중 SELECT를 제대로 구현한 것은 없었다.

웹서핑하고 돌아다닌 기록을 정리하기 위해 여러가지 솔루션(Wiki, Web browser의 bookmark, Link blog)들을 택해보았지만, 전부 각각의 방식의 한계점들 때문에, 실패에 가까운 것 같다. 딥뿔군의 제안에 따라 Last Mind..::Links를 운영중이었는데, 이 방식의 한계점은 링크를 등록하기가 쉽지 않다는 것이다. 그래서 최근에 또다시 browser의 bookmark를 사용하는 모드로 바뀌었는데, 마침 딥뿔군이 'Blog Links! 0.1'을 만들어 쓴다길래 나도 ruby 연습겸 console 버전으로 한번 만들어보았다.

Web browser에 integration되어서 단축키로 현재 페이지에 바로 comment하는 인터페이스 정도면 가장 좋을 것 같다. 모질라 플랫폼(XUL, ...)을 체험해볼 겸 모질라쪽 플러그인을 만들어보는 것도 재미있을 듯. 그리고 추가적으로 하루하루의 링크들에서 digest를 생성해서 본 blog 쪽에 자동 posting 해주는 스크립트 정도..가 있으면 좋지 않을까 생각이 든다.

다음은 MT의 XMLRPC interface를 이용해 link posting을 하기 위한 console 버전의 ruby script.

언뜻 봐서는 'Click Wheel'이란게 생겼고, 배터리 사용 시간이 증가한 정도?

• 20G $299
• 40G $399

란다. 약간 더 싸진 셈. 하지만, 내 경험상, 10G 이상은 큰 필요가 느껴지진 않는다. 상당한 (나를 넘어서는) 귀찮음증 환자가 아니고서야... 우리나라엔 아직 출시되지 않은 것 같다. 쳇~!

• http://www.apple.com/ipod/
• http://www.apple.co.kr/ipod/

["딥뿔군의 글":http://myruby.net/archives/002324.html]에 적혀있는 세가지 법칙을 보고 생각난 것을 적어보자면... **1. '공격적인' 스케쥴에 메인 프로젝트는 좀 더 타당한 스케줄을 따랐을 때보다 프로젝트를 끝내는 데 더 오래 걸린다.** bq. 흔히 스케줄을 일에 비해 짧게 또는 희망적으로 잡는 경우인데, 스케줄은 프로젝트 관리에 경험이 적을 수록 비관적으로 잡는 것이 좋다고 생각한다. (경험이 많아지면, 스케줄을 재조정하는 것도 프로젝트에 나쁜 효과를 끼치지 않고 유연하게 할 수 있지 않을까 생각) 그런데, 의외로 이렇게 잡아야만 열심히 일한다고 생각하는 사람이 많다. 하지만, 경험적으로 리스크가 끼어들거나 해서 시간이 부족하면 위에서는 압력이 들어오고, 당사자들은 초조해지고, 그래서 프로젝트가 방향을 잃고 좌초하는 경우도 많다. **2. 작업을 완료하는데 필요한 프로세스에 대한 자신의 직감을 모델링한다.** bq. '직감' 이런 단어가 들어가면 정말 어려운 것들이다. 책을 읽지는 않아서, 이 말이 무엇을 말하는지 정확히는 모르겠지만, 경험을 통해 직감을 성숙시키고, 이를 '모델'화하라는 말인 것 같다. 대부분의 책들은 이를 위한 의식적인 노력이 필요하다고 얘기하고 있다. 특히 '측정'을 통해, 원래의 예측이 얼마나 틀렸는지, 무엇이 원인인지 등을 파악해야한다. 난 측정까지가 아니라 원인 분석 정도에 그치고 있는데, 측정을 활용하면 좀 더 빠르게 이러한 직감에 이를 수 있지 않을까 생각해본다. **3. 하루를 잃는 데는 수없이 많은 방법이 존재하지만, 하루를 만회하는 데는 단 한가지 방법조차도 존재하지 않는다.** bq. 내 경우, 하루를 잃게 되는 대부분의 경우는, 오늘 할 일을 내일로 미루는 것이다. 프로젝트 원에게 진행상황을 물어볼 것을 오늘 하지 못하는 경우, 무엇을 확인하고 시켜야할 것을 내일로 미루는 경우, 스케줄은 하루씩 미뤄지는 것 (단축할 수 없는 것)과 마찬가지인거다.

장진 감독, 이나영, 정재영 주연의 로맨틱 코미디. 이나영은 이번에도 약간 자폐적인 캐릭터로 나왔는데, 이나영 보는 재미만으로도 이 영화 볼만한 것 같다. T_T 특별히 새롭다거나 한 것 없고, 스토리도 예상가능하고 평이하다. 재미를 의도한 것인지 모르겠지만, 주변인물의 입을 빌려 사랑에 대해 역설하는 장면들은, 그리고 회상하는 장면들은 약간, 아주 약간 짜증스러웠다. 하지만, 전체적으로 스타일 좋고, 유머들 속에 녹아있는 재치 역시 맘에 든다. 영화가 끝날 때 즈음 스토리를 되돌아보면, 동치성이 영화중의 '전봇대가 주인공인 영화'를 평했던 말과 똑같은 말을, 나도 하고 싶어졌다. 하지만 곧이어 스코어가 올라가면서, 첫사랑의 순간, 사랑을 시작하는 순간, 동치성의 함박웃음 담긴 행복함에도 동의할 수 밖에 없었다. 어느 정도 나이가 들어, 감정을 전제를 걸고 시작하고 끝내는 관계에 익숙해지다보니, '사랑'이라고 정의되는 관계에 대해서 유물론적으로 분석하는 방법도 알고, '사랑'이 내게 가져다주는 모든 이익에 대해서 충분히 이해하고 즐길 줄도 알게되었다. 하지만, 내 감정 회로는 단순해서인지 두가지 방식을 동시에 취하지는 못하는 것 같다. 각각의 방식은 각각의 방식이 적절한 상황이 있는데, 단속적으로 이 두가지 방식을 왔다갔다 하다보면, 항상 상황에 부적절한 방식을 사용하고 있는 나를 발견하게 되기도 한다. 이런걸 이해는 하고 있는 나이지만, 그렇다고 나를 변화시킬 이유도 찾지 못한다. 외부와의 타협을 거부하는 것을 제1행동원칙으로 삼는 나에게 누군가가 이러한 태도를 비판한다면 이렇게 말할 수 밖에, "So what?".

베타 테스트 중인 구글 그룹 2을 한번 만들어보았다. 메일링 리스트 형태의 초보적인 커뮤니티라고 생각하면 될 것 같다. 지인들 위주로 마음대로 초대한 후, joke 위주로 운영할 생각.

그러고보면 이 서비스 역시 메일 기반의 서비스라서 gmail과 어떤 시너지를 창출해낼 수 있을지는 미지수.

	Subscribe to Just For Fun!
	Email:
	Browse Archives at groups-beta.google.com

PIFAN 소식을 좀 늦게 접했다. 식중독과 기관지염으로 고생하느라 다른데에는 신경쓰기가 힘들었으니... 당연히도 주말에는 볼만한 것들(아무래도 관심있는 건, 단편 걸작선들과, 트로마의 작품들, 요르그 부르게라이트의 작품들이었는데...)은 이미 매진되었기 때문에, 다음주 월요일 휴가 내기로 결정, 주말에 놀면서 과감하게 네편 예매해버렸다.

영화를 좋아하면서도 널널한 인간이 주위에 드문 것 같다. 혼자 부천 구경하기도 재미있을 것 같지만, 혹시 월욜날 밥이나 같이 먹으실 분은 연락하시덩가.

082 판타스틱 단편걸작선 7

판단걸5은 내게는 덜(?) 판타스틱한 동양쪽 일색이라 판단걸7을 선택하다.
전체적으로 작품들의 분위기는 내 맘에 들법한 좋은(?) 분위기이다.

• 주차장 어페어: 선댄스 최우수 단편이라 이력이 화려하군.
• 푸콘 패밀리
• 슈퍼맨의 비애: 연필 소묘로 그려진 거란다.
• 그녀의 정원손질법
• 썬크림
• 순환: 이거 왠지 재미있을 듯하다.
• 즐거운 우리집

143 톡식 어벤저 2

트로마-로이드 카우프먼의 유명한 작품 중 하나? 톡식 어벤저 1을 안봐서 좀 뭐하지만, 아무렴 어떤가. 오랜만에 보는 하드고어, 기대기대! ㅋㅋㅋ

016 노래하는 탐정

매진이라서 선택한 안전장치다. 사실 당일 가서 '판타스틱 단편걸작선 1'을 구할 수 있으면 그걸 볼 생각이다. 아무래도 경쟁이 치열할 것 같지만~ 뭐, 그래도 볼만할 것 같다.

047 판타스틱 단편걸작선 4

판단걸7보다는 좀 떨어지는 듯 하지만...

• 프랑스식 사체유기법: '프랑스식'은 마음에 안들지만, '사체유기법'은 마음에 든다. 차라리 독일식 사체유기법같은게 더 재미있을 것 같다. 뭐 원제는 'French Killer'라서 좀 김빠지긴 하지만.
• Endless Target: 'Endless'라니 제목부터가 왠지 지루할 것 같다.
• 인비져블 1: 숨은소리찾기: 탐정물?
• 내선 21번
• 그녀의 침묵
• 원숭이의 해
• 바다의 제왕

196 판타스틱 단편걸작선 1

이건 위에서 말했듯이, 매진된 상영작이다. 현매관람을 위한 후보.
남의 떡이 커보인다고, 으으.. 제일 재미있어보인다.

• 하녀 길들이기
• 위험구역
• 차가운 열정
• 순흔: 조선시대의 동성애~
• Radio Dreams
• 돈의 흐름: 으어, 이거 재미있을 것 같다. _;
• 지구인 되기: 이것도!

링크

• Pifan 2004 공식 사이트
• Pifan 2004 ticketing 사이트

Willkommen, bienvenue, welcome,
Im Cabaret, au Cabaret, to Cabaret

발음도 익숙치 않은 뮤지컬 캬바레는 1966년에 초연을 한 역사가 오래된 공연이란다. 그리고 이번 한국 공연은 토니상 4개부문 수상에 빛나는 샘 멘더스의 93년도 리바이벌 버전이란다. 정작 '브로드웨이 팀'이라고 광고를 해대지만, 홈페이지에 cast 리스트조차도 나오지 않는 것 보면, 역시 미국의 51번째주 지방 공연 정도 수준이 아닌가 싶었다. '에로티시즘' 같은 선정적인 홍보를 할 경우에는 분명히 별 거 없다는 경험적인 예측이 이번에도 들어맞기를 기대(?)하고 광화문을 찾았다.

12일 저녁 공연을 보았다. 비가 오는 것까지는 좋았지만, 후덥지근하기까지 해서 기분이 하루종일 그다지 좋지는 않았지만, 인파를 헤치고 답답한 지하도를 벗어나서 세종문화회관에 들어서자 괜히 편해지는 기분이었다.

프로그램을 보고서 알았지만, 2002년에 한국 배우들이 출연한 뮤지컬 캬바레를 공연한적이 있단다. 약간 놀람.

공연이 시작하기 전부터, 장난스러워 보이는 남자 배우 한명, 여자 배우 한명은 무대 앞에 걸터앉아 지나가는 관객들을 붙잡고 얘기를 건다. 여주인공으로 보이는 배우는 무대 중간에 서서 담배를 피우고 있다. 신기하게 쳐다보고 있다가 드는 생각. 아, 연출이군.

무대는 2층 구조로 되어있었다. (공연이 시작되고 나서야 안거지만) 밴드가 2층에 있고, 'The Rocky Horror Picture Show' 에서처럼 나선형 계단으로 1층과 연결되어있었다. 1층에는 무대 뒤쪽과 나무재질 문 세개로 연결되어있었다.

역시 브로드웨이 뮤지컬, 시작부터 화려한 무대의 위용을 보여주며, 재치있는 주인공, 흥겨운 음악과 시작했다. 공연 내내 스토리텔러(?)와 같은 역할을 하는 Emcee라는 캐릭터가 관객들을 환영하며, Kit Kat 클럽의 멤버들을 하나하나 소개한다.

배경은 1930년대의 베를린, 얘기는 Kit Kat 클럽과, Schneider 부인의 하숙집, Shultz의 과일 상점에서 진행된다. 미국에서 소설을 쓰기 위해 온 작가 Cliff의 Kit Kat 클럽에서의 Sally Bowles와의 만남과 Shultz와 Schneider의 따뜻한 데이트 장면으로부터 두가지 스토리가 진행된다. 간간이 Kit Kat 클럽의 공연과 함께, Act 1 동안 퇴폐적인 캬바레와 행복해하는 주인공들이 그려진다. Act 1의 마지막에서 Cliff를 Kit Kat 클럽에 소개해준 Ernst가 나치당원이란게 밝혀지고, 함께 Shultz가 유태인이란 것이 밝혀지면서 불행한 결말이 예견된다.

Act 2에서 모든 행복함은 파국으로 치닫고, Kit Kat 클럽의 주인 노릇을 하던 Emcee조차 밴드도 퇴장해버린 무대를 뒤로하고 노란색 별이 달린 죄수복을 드러낸다.

사실 뮤지컬이기 때문에, 플롯은 복잡해지기 어렵기 때문에, 많은 의미를 찾아내기는 어렵다. 굳이, 정말 억지로 찾아본다면, 두가지 정도가 있을 듯 하다.

마지막 즈음, Sally Bowles가 Kit Kat 클럽에 복귀하면서 부르는 number인 'Cabaret'에서의 'Life is a Cabaret, old chum'라는 가사가 나온다. 인생은 캬바레와 같은 것, 인생은 즐기는 것 정도의 해석이 보편적이겠지만, 작품의 외부에까지 확장된, Cliff 또는 관객들의 캬바레 입장과 퇴장, 주인공들의 행복과 파국의 대칭 구조가 나에게는 인상적이었다. 인생은 캬바레를 들어가기전까지 세상사의 괴로움, 캬바레에서 그 모든 것을 잊고 즐김, 하지만, 이른 새벽 캬바레 앞에서 세상으로 다시 돌아올 때의 허무함들이 반복되는 것이라는 것이 나의 한가지 과장된 해석이다.

역시, 'Cabaret'에서는 Shultz씨와 Schneider 부인이 그토록 우리와는 상관없다던 정치나 국가가 자신들을 파국으로 밀어넣는다는 것(실제로 정치나 국가에 의해서든, 극복하지 못한 자신들의 탓이든)을 보여주고 있다. 또한, 서로 세상을 바라보는 눈이 너무 다른, 그래서 사랑을 포기하는 Cliff와 Sally의 삶을 보여주고 있다. 우리의 인생은 Kit Kat 클럽만큼이나 퇴폐적이면서도 부조리하다는 것을 또한 얘기하는 것처럼 들린다. 우리의 인생은 우리의 의지대로 마음대로 할 수도 없고, 우리의 의지인 것처럼 보이는 것들이 우리를 배신하기도 하는 것이다.

목소리나 춤동작의 일치같은 사소한 부분이 좀 걸리긴 했지만, 전체적으로 유쾌하고, 가벼운 몇가지 생각할 거리도 던져주는 볼 만한 뮤지컬이었다. 무엇보다 처음의 기대를 훨씬 넘어서는 것이었다는 것이 가장 즐거운 일이었다는 생각을 하며, 우산을 펴들었다.

Cabaret

Cabaret

Cabaret 소개 from yettz

Cabaret Lyrics

P.S. 공연장에서 이효리와 김수미를 본 것 같더니만..
http://www.stoo.com/html/stooview/2004/0712/091992000512111100.html

Mac OS X 10.4 "Tiger"에 관한 몇몇 읽을거리. ["Inside Mac OS X 10.4 'Tiger': Overview":http://appleinsider.com/article.php?id=527] ["Inside Mac OS X 10.4 'Tiger': Safari 2.0":http://appleinsider.com/article.php?id=531] ["Inside Mac OS X 10.4 'Tiger': Mail 2.0":http://appleinsider.com/article.php?id=532] ["Tiger's Help application will search web support docs":http://appleinsider.com/article.php?id=538] ["Inside Mac OS X 10.4 'Tiger': iCal":http://appleinsider.com/article.php?id=539]

우리회사에서 publish한 게임 중에 우리회사에서 제작한 첫번째 MMORPG인가? 어쨌든 어제 날짜로 Closed beta를 시작했다. 베타가 시작되기 전부터 동영상이 꽤나 선풍적인 인기를 끌어서 다들 한번씩은 봤을지도 모르겠지만, 이 캐릭터(안나) 정말 이쁘지않나? 요구르팅 댄스 분석이 나올 정도니까, 굳이 여러 말 할 필요도 없을 듯 하다. 개인적으로는 정말로 안나의 댄스 코스프레를 보고싶은데, 악취미일까나~

당연히 Closed beta에 해당하는 버전을 플레이해볼 수 있었다. 몇가지 단어로 요구르팅의 특징을 적어보자면, 학원물, 카툰 렌더링 방식, 채널 형태의 던전 방식 정도가 될 것 같다. 학교를 배경으로 하고 있고 PC들이 학생이라는 점, 선생님들이 등장하는 것들 정도가 학원물을 chracterize하는 요소들일테고... 캐릭터나 그래픽 자체는 다른 게임들에 비해서 정교하다거나 뛰어난 맛은 보이지가 않는다. 2D concept 수준에서는 좀 뛰어났을지는 모르겠지만, 게임 내에서는 별로 부각되어보이지 않는 것 같다. 아무래도 전체적인 완성도가 낮기 때문이지 않을까 하는데, Closed beta라는 이유로 국내에서는 완성도의 부재가 모두 용서되는 분위기인 것 같다. 외국 게임에 익숙한 나로서는 그다지 이해가 되지 않는 분위기. 채널 형태로 던전이 생성되는 건 아주 새로운 것도 아닌데, 학원 내 만을 배경으로 해야하는 요구르팅의 경우에는 다른 옵션이 없었을 것이다. 던전으로 들어가고 나올 때의 로딩 시간도 너무 긴편이고 그다지 매끄럽지가 못한 것 같다. 그 외에도 메인 스토리나 서브 퀘스트들이 아직은 마련되어있지 않은 듯 하다. 그 동안의 경험으로 볼 때, 클로즈드/오픈 베타의 퀄리티가 정식 버전의 퀄리티를 거의 결정했기 때문에, 앞으로도 많은 것을 기대하기는 어려울 듯 하다.

옛날에는 적시성이 매우 중요시되는 factor였기 때문에 완성도의 부재를 참아줄 수 있었으나, 이제는 quality를 따지지 않으면 경쟁할 수가 없을 정도로 MMORPG 시장은 포화된 상태가 아닌가. 다시금 '마비노기'가 정말 잘 만든 게임이라는 것을 느낄 수 있는 계기였다. 요구르팅이 그에 버금가는 게임이 되기를 원했는데, 아직은 부족한 점이 많은 것 같다. 네오위즈의 MMORPG 시장 진출, 쉽지많은 아닌 일인 것 같다. 반대로 말하면 '나도'(?) 게임 시장에 한번 뛰어들어볼 기회가 있다는 뜻일까? 뭐, 농담이다. ㅋ

기존의 MT skin이 그다지 맘에 들지 않아서, ["TatterTools":http://www.tattertools.com/]의 스킨을 가져와서 MT에 맞게 수정해보았다. 좀 노가다성이긴 했으나, 결과물을 보니 보상이 되는 듯 하다. 그 외에, MT에 글을 작성할 때, HTML을 직접 작성하기가 매우 부담스러웠기 때문에, Web Editor를 찾아다니던 도중, ["deepblue군의 조언":http://myruby.net/archives/002133.html]을 듣고 MT-Textile을 깔아보았다. 위키처럼 간단한 markup으로 formatting을 할 수 있도록 해주는 것인데, 몇가지 테스트를 해보니, 쓸만한 것 같다.

WWDC2004에서 Apple의 CEO인 Steve Jobs가 Mac OS X의 새버전인 "Tiger"를 발표했다. Mac OS X Tiger Sneak Preview ["http://www.apple.com/macosx/tiger/":http://www.apple.com/macosx/tiger/] WWDC 2004 Keynote Webcast ["http://stream.apple.akadns.net/":http://stream.apple.akadns.net/] 감동적인 애플 차세대 OS "타이거" ["http://www.zdnet.co.kr/webtv/webtv.html?id=69678":http://www.zdnet.co.kr/webtv/webtv.html?id=69678] Keynote 전체를 보지 않아서 모르겠지만, ZDNet의 동영상에서는 Spotlight와 iChat을 보여주고 있다. Spotlight는 iTunes에서도 보았던, OS상의 검색기술을 얘기한다. 이제까지의 OS 검색은 파일들의 이름이나 단순한 내용을 기준으로 찾아야만 했지만, Spotlight는 파일 또는 정보(메일, 주소록)의 meta 정보를 이용하여 쉽게 검색할 수 있도록 하고 있다. 한가지 예를 들면, "앞으로 일주일 내에 생일이 있는 사람들의 목록" 같은 것을 쉽게 생성할 수 있다는 것이다. Longhorn의 WinFS와도 관련성이 있어보이긴 하는데 어느쪽의 결과물이 더 나을지는 두고볼 일이다. iChat은 video/audio conferencing인데, 그 자체로는 새로울 것이 별로 없지만, 그 인터페이스가 정말로 Apple 답다고할 수 밖에 없는 감동을 자아내는 것이었다. Mac OS X "Tiger" vs Longhorn?