Sunday, December 25, 2005

[talk] 聆聽的藝術 The Art of Listening

I was invited by Taiwan Women, a group which members are interested in gender issues, to lead a workshop, The Art of Listening, in the winter of 2005. I asked the audience not to take any notes so they could concentrate on listening at the moment. This handout is probably more meaningful for the participants but I hope it stills inspires somebody else. This handout is mostly in Chinese but I'll translate it in English in the near future.

This workshop is a shorter version of another 3-day workshop which will be held in Ocean Lotus Farm on May 5-7, 2006. It will be led in English or bilingually (English+Chinese), depending on the participants' lingusitic backgrounds.

我受台灣查某之邀(台灣查某是一個關心性別議題的團體)在她們2005的冬令營中帶一個工作坊。主題是「聆聽的藝術」。工作坊中,我要求參加者練習當下專心聽,不要分心作筆記。這份簡要的大綱大概對參加者比較有意義,但我放在這,希望對沒參加的人也或多或少有點助益。

這個活動是另一個三日工作坊的精簡版。那個工作坊將於2006年5月5日至7日於海蓮山莊舉行。該工作坊將視參與者的語言背景,以英語或中英雙語進行。

聆聽的藝術

The Art of Listening

2005/12/27 Tsan-Kuang Lee

前言 Preface

拜各暢銷書所賜,今天大部份的人都知道,聆聽對於有效的溝通,有決定性的影響力.

然而,有了火星/水星雙語秘笈,我們是否就不再彼此不解?有"芝麻開門,耳朵開竅"神咒的加持,我們是否真的就能聽得真切如實?

這個課程以實際練習的方式,讓我們重新檢視自己的聆聽能力,並找出影響自己聆聽的種種因素.針對這些因素,我們學習建立新的聆聽習慣,打破過去無效溝通的惡性循環.

講者:李璨光

高中時受典型理工訓練,大學時轉讀文學,研究所攻語言學及計算機.因緣際會受助於多位音樂家,目前以編作曲與軟體工程為專業.近年來以禪修方法重新認識自我,從家庭關係中學習溝通與反省之道,也深深體會這些看來容易的功課沒有紮實地下功夫是修不過的.

Thanks to the best-sellers, almost everybody today knows that listening plays an essential role in effective communication. However,being proficient in Martian and Venusian does not seem to guarantee better understanding. While we try very hard to listen, we still hear something very different from what's intended or even what's said. How do we fill the gap between theory and practice?

In this activity,we will re-evaluate our listening ability and investigate the factors that hinder it. Then we learn to establish new listening habits to break from the bad cycle of bad communication that we were so used to.

Speaker:Tsan-Kuang Lee

Trained to be a scientist in high school, turning to literature in college, but ending up studying linguistics and computer science in graduate school, with several established musicians' help, Tsan-Kuang is now working as a composer/arranger and a software developer. In recent years, he has been learning to re-exam himself by means of Zen practice; he also has learned great lessons in communication and self-adjustment from the relationship with his families. He realizes that while those lessons may sound cliche', mastering them is never easy yet so crucial in all kinds of relationship.

課程介紹 Intro

Another 3-day workshop: 音樂、語言、心靈

The quotationized word:「心靈」(spiritual)

現代教育的層次與順序:外而內

自然的歷程:內而外

靜坐練習

3-5-minute sitting meditation (simply follow the instruction without judging)

  • 建築物外圍(可以很遠,到世界各地)
  • 房間內部背景聲音
  • 身旁人的聲音
  • 自己的呼吸、心跳、血管聲
  • 內在的聲音(可以很深)

有沒有judgment, doubts, or any other emotion / thoughts?

Practice In Practice

先不要筆記或要錄音,練習當下聽

個人經驗,聽音樂或聽課

在當下轉化

Activity 1

先想三分鐘,再開始用3句話(或20秒)講出:

  • 家中(或朋友中)最難溝通的人(同性、異性);
  • 最難溝通的事;
  • 為什麼不能順利溝通

我們是不是能平心靜氣聽別人講話,還是只對主講者的話有興趣,或只對自己的話有興趣(找舞台表現)

影響聆聽的因素可能有哪些?

  • 特殊身心狀態(太累、生病)
  • 緊張(無意地只在乎自己)
  • 我慢(有意地只在乎自己)
  • 習慣性分心(注意力無法集中)
  • 認為已經知道,不需要用那麼多的注意力(試試看能不能回答出所有其他人觀察到的現象)

Listening難在那裡?

  • Impure intention 貪
  • False Judgment / interpretation, obsession 痴
  • Emotion 嗔

貪 (Impure) Intention

different degrees of attention:

  • 完全沒聽
  • 假裝聽 (眼睛看旁邊)
  • 假裝先聽,只在等著講(以溝通之名來行說服、命令之實)
  • 半聽 (為了要找語病): 一個不能講錯話的社會(unforgiving society, e.g. 政客間互相抓話柄), 吵架的特色(生氣對方不願了解只想攻擊)
  • 專心聽 (需要給對方與自己一大段時間來完全表達與完全消化);放下速成的期待(因為表達者非完美,會有情緒)

嗔 Emotion

自己的情緒

  • 有能力覺察與承認自己的情緒 (情緒也是事實的一部份) (沒有速成法、但隨時可練習;把握 每次練習的機會)
  • 真正要溝通 (記住溝通是幫助了解與幫助表達),要能容許對方講錯,容許對方改錯 (help make clear):盲人(情緒、觀點上的)過街的故事
  • 了解自己掌控情緒的能力與限度;給對方暫停溝通的 signal
  • 嗔 Emotion

對方的情緒

  • 對方的情緒也是事實的一部份,對方對事實的認知也是事實的一部份
  • 給對方充分表達的空間與時間 ("讓我先放個屁",再問觀眾當下的反應與情緒,是不是願意容許人家先把最難過的關卡渡過)
  • 情緒表達出來以後比較可能溝通

痴 Judgment、obsession

什麼是事實,是事情表面上的?言語上的?還是情緒上的?

別人表達的,是別人的覺受,對當事人來講,就是真的;在了解對方感受前就反應,不會有幫助

帶著錯誤的假設去聽,是自找麻煩

很多時候我們故意曲解對方的意思,故意認為對方在傷害我們 -> why?

最沒效的溝通方法就是 intellectual approach (清官難斷家務事)

對於自己熟悉的事物特別無法接受不同的看法或方式

  • 上課方式
  • 「知識」的架構、「科學方法」、「邏輯」
  • 方法學

如何練習:Practice In Game

Rule of Game: Paraphrase whatever is said by the person who speaks before you. If the next person makes a mistake in paraphrasing our speech, we paraphrase the mistake we think before we make corrections. Before we speak, we give a gentle signal (e.g. bring palms together).

Principles of paraphrasing: semantics不多不少,不加情緒;不judge對錯

先想再講,不要馬上回。給對方時間想。

Activity 3

Paraphrasing rules apply here.

練習討論:先全體練習一下,再分組練習(4-6人一組)

全體練習時,有沒有人因為害怕、害羞、不屑而放棄發言?

Discussion Topic 1:Gender in Language

Is gender a made dimension in research?

Word frequency vs. pragmatic domains

  • 「我同事和老婆領養了一個五歲的孩子;兩年以後,我同事被告性侵這位小女孩」。請問我同事的性別?
  • 溝通時對性別/種族的預設:作家/女作家,詩人/女詩人,醫師/女醫師,護士/男護士,工人/女工,清道夫/女清道夫?總統/女總統?
  • 例子:長得很漂亮的女作家把照片印在書皮上,在受訪時卻強調不希望自己的性別被當做賣點(既得利益者vs.「社會正義」)

女性是否真的比男性容易說出較屬於私領域的話題?為什麼?

"Gay talk": phonologically difference 不可察;用字與發音是文化及外在(external)的現象(instead of phonological): fabulous, beautiful, pretty; 和流行與次文化比較有關。舉例: 「學ㄒㄧㄠ/問」,「文化水平」;有其conotation;文化賦與語詞新義

對token的看法(醫生、教授):當token的人會不會覺得自己只是因為是少數才被用?怎樣的態度才好?

PC (political correctness) 的意義

  • You "guys" 你們/ you "gals" 妳們 (避免使用 girl;如果避免使用「『小』姐」);如果不知道或是混合時該怎麼辦?他/她 你/妳 您/(女字旁您) 的必要性;s/he she/he her/his him/her... 她/他
  • 文法中的詞(字)格(der,die,das):indo-european;語格:日文。這是文化的?中性的?還是無法分割的?
  • 符號只是符號,任何的詮釋都是外在的詮釋?有沒有純中性、無辜的符號?
  • awareness for/of whom? 是否為了顯示自己的文化教育水準?
  • 只有 awareness 卻沒有真正的尊重:程式設計的書用she來寫常犯的錯誤;心理學課本用she皆指病人

Labov的研究

  • 女性在語言變化上較不主動;但上班族女性則不同
  • 性(別),死亡 是最容易引起興趣的話題

Discussion Topic 2: 宗教中的女性角色

壓迫者來自女性

  • 婆媳、修道院修女(或尼眾)
  • 朋友(女)的例子:對男性容易覺得很棒,對女性成功者則充滿批評

佛教

  • Ani Tenzin Parmo (修行人)的觀察
  • 女轉男身(今日男轉女身);性別只是某世的生心理的呈現。只是心性。(lesbian in a man's body (sisterhood))

基督教

  • 夏娃的錯?

回教

Is listening enough?

溝通的目的(成功的溝通)是什麼?

  • 了解彼此想法、情緒、能力:溝通,就是因為彼此不了解;要先承認這點
  • 成功溝通->妥協、協調、配合->相處、解決問題
  • 如果沒有尊重與誠意,就很難溝通

Listening techniques 只是魚,釣竿是覺照力:這裡因應速成的社會,讓大家趕快吃幾條魚

溝通中,listening 只是一半功夫,另一半(expressing, voicing) 還需要更強的覺察力(on external situation and internal emotion)

Meditation或任何清楚的自省方法都可以訓練覺察力

如何溝通

要事先準備(介紹茶禪):內容、心情、氣氛

總長要短:考慮到體力,專注力,情緒的容量

學習講話實在(不妄語);妄語:損己不利人

  • 朋友的例子:心虛時就賣弄(自己也不懂的)專有名詞,讓對方聽不懂->為什麼?

建立好習慣

  • 長期關係中,我們隨時造新的業種;我們漸漸塑造彼此的溝通習慣與模式(天平的比喻) (again, 把握每次練習的機會)
  • 願力;以不造更大的業為原則(對自己也算造業);自己的根性遲早要面對,但要衡量自己的能力

Conclusion

佛教觀點

  • 別忘了觀世音菩薩就是以聽的方式來渡眾的
  • 「學」佛:“learn about” or “learn from” Buddha?
  • 我們聽的時候,若帶著慈悲心,就比較能把能量花在幫助他人,轉化當下困境上,而不會放在挫折與情緒上。
  • 觀世音菩薩在觀世聲時,聽到很多不合理的要求,會不會起嗔心?

工具是拿來讓自己生命更美好,而不是拿來攻擊對方的(我們願不願意讓自己的兩面刃其中一面,在我們死的時候沾滿血腥?或是讓能載舟覆舟的水面上浮滿屍體?)

  • 自己第一次練習失敗的例子:要有耐心,要先拿出誠意。以退為進。有正當的目的。
  • 朋友的例子:生氣起來就講英文讓對方招架不住。只會招致反效果。
  • 自己不厚道的例子:喜歡戳破他人的牛皮 (為什麼我們會覺得這樣很過癮?「包青天」情結?別忘了清官難斷家務事)
  • 吵架時攻擊對方不相關的弱點,純粹玩弄工具。

Thursday, December 1, 2005

About this blog 關於本網誌

If you are a first time visitor, you'll find some helpful notes here about the history, structure, policy, system, etc. ofthis blog.

如果您是第一次來,可以參考本篇。這裡會介紹本網誌的歷史、結構、規則、系統等背景。 (中文翻譯見後)

Welcome

Welcome to my blog. Here's why I started blogging. And here's why I choose to use weblog among other voicing media.

Categories

On your right you can find a box titled "Category", in which you'll find my postings categorized. If you use other blog systems, please note the difference here: each category is independent, e.g. articles categorized under category "Mozart" will not appear under category "Music", although "Mozart" seems to be a sub-category of "Music". You can also click on the question mark in front of each category name to read the general entry for that particular category.

Languages

Mostly I write in both English and Chinese, but sometimes when I cannot afford the time to translate, I'll try to use the one that is more relevant to the content and particular audience.

Unfortunately this particular blog system's support for multi-lingual entries is not satisfying (see the section of my comments on Serendipity's multi-lingual support here). Currently both English and Chinese are written in the same entry. You may want to scroll down to see the language you are familiar with.

Revision

I don't write much, so I should be able to use the saved time to go back to edit my old writings. When several relevant articles are mature enough, they will be compiled together for easier access.

Article Dating

There are many old articles in this blog. Obviously they were written before blog systems appeared. However, I still date those articles according to the time they were written. Some timestamps are accurate to seconds but not all.

Each article entry has a line saying "last modified on xx". I'm working on a plugin to sort entries according to that info so visitors can find recently added old articles.

Policy on Visitors' Comments

I probably won't be able to respond to all comments I get, but I will at least try to carefully read what's written to me. Also, for the sake of readibility and structure, I reserve the right to delete/edit/compile visitors' comments. Of course, I will respect visitors' privacy and copyright.

This Blog System

This blog is powered by Serendipity (s9y). I pay my high respect to the open source community.


歡迎

歡迎來我的網誌。我重新提筆,其來有自。我選擇用網誌發表,也是經過考慮的。

文章類別

在頁面的右邊可以看到文章類別的選單。每一篇文章都有分類。如果您用過其他的網誌系統,請注意在本網誌中,每一個類別都是獨立的。比方說,雖然「莫札特」看來像是「音樂」的子類別,但「莫札特」類別的文章,並不屬於「音樂」。您可以點擊每個類別前的問號來閱讀關於該類別的說明。

語言

有時間的話,我大多會寫中英兩個版本。不過,如果時間不許可,我儘量選擇對該篇內容與讀者較有利的語言寫作。

很可惜,本網誌系統對多語的支持不盡人意(參考我另一篇文章中對Serenpity多語支援的評論)。目前我只好暫時將中英文混寫在同一篇中。如果文章開頭不是您使用的語言,可以試著往下捲。

修訂

我寫得不會太多,所以我應該能用省下來的時間來把我已寫下的東西修改得好一點。等到幾篇主題相關的文章都改得夠成熟了,我會集合起來,以供方便尋找。

文章日期與時間

很顯然許多早期的文章是在網路時代之前。我仍文章寫作完成日期來標示。有些時間會精確到秒,大部份只精確到日。

每篇文章會有另一個「最後修訂時間」。目前我正在寫一個可以按那個時間來排序的外掛程式,讓訪客可以知道最近又增加了哪些舊文章。

訪客留言規則

我大概不可能對每一個留言與評論做出回應,但至少我會試著用心閱讀寫給我的評論。為了網誌的可讀性與結構,我保留對訪客留言的刪除/編修/彙整權。當然,我會尊重訪客的隱私與著作權。

本網誌系統

這個網誌是用Serendipity (s9y)架的。我對開放原始碼的社群表達我的崇高的敬意。

Monday, November 28, 2005

Why choose blog 為什麼選用網誌

Among so many publishing platforms (Static Web Page, CMS, Wiki, BBS/Forum, blog, etc.), I chose blog after a lengthy trial-and-error process. Here I share my own considerations behind the choice. It is a bit technical but still highly relevant.

我用過許多出版平台(內容管理系統, 維基, 靜態網頁, 佈告欄, 討論群組, 網誌等), 最後選擇用網誌來做個人出版. 我在這裡分享我的考量過程. 雖然以下內容稍偏技術性, 但我認為這些考量的確很重要.

(註:中文部份尚未翻譯完畢)

Please note that I write those with my personal need and personalexperience in mind; therefore, if your need and background is differentfrom mine, please be aware that these comments are unavoidly subjective.

以下評論完全是依我個人經驗及所需而發的。若您有意參考以下評論,請記得這些評論難免落於主觀而不具代表性。

Static Web Page 靜態網頁

Pros 優點Easy to setup. 易安裝
Light and fast for server load. 對伺服器負擔小;速度快
Flexible structure and document flow. 網站文件結構具彈性
Cons 缺點File upload hassels. 上傳檔案麻煩
Off-line HTML editors are inconvenient. 必須使用不方便的離線HTML編輯器
Searching not provided. 沒有內建的搜尋功能
Directory / file structure may become messy. 檔案目錄結構容易混亂
Unable to auto-date changes 無法自動標上日期

The traditional static web page is still the major authoring and publishing way because of its simplicity and flexibility.

One the server side, no database or file system writing permission is needed. A basic web server will handle static pages very well. It is also the fastest way to serve pages, compared to database and script driven systems. Simple HTML files are very easy to archive and backup as well. The idea of "one article, one HTML file" makes it easy to send the articles via email or to print.

However, managing many static HTML articles on one site is not easy at all. Adding, removing, or modifying a new article requires editing of the index file, and there is the file uploading hassle. I used to have a local copy of the website and the HTML editor will upload only the modified files to the website whenever I make some changes. After a while, the requirement of a specific HTML editor became very inconvenient for me. Whenever I see a typo on my page, I'll have to wait until I have access to that specific installation of HTML editor. Although it's possible to create HTML files with simple text editors, saving keystrokes become important after I started to have slight RSI problem.

The organization of directories and files can be hard. Both putting everything under one directory (wide tree) and making a complex tree structure (deep tree) have their problems in searching. A wide tree is bad for the author to quickly locate a specific file; a deep tree is harder for index file creation.

Auto-datingmay sound unimportant; however, I find it very crucial since Iconstantly update the contents but would like to keep track of oldupates for historical references.

Therefore, I know I need a database driven (thus implying script driven) system.

CMS (Content Management System)

ProsRich features.
Easy to extend or customize.
Modular design makes it easy to manage.
ConsResource hungry.
Potential security holes.

CMS is a great answer to webmasters who need to provide a community many different services, such as discussion boards (or forums), news, specific content driven pages, messaging system, event calendar, polls, or any other specific services (bug tracking system, auction system, family tree, community dictionary, etc.). A centralized management system makes the webmasters life so much easier.

On the other hand, a generic CMS system is usually resource hungry. The higher level a framework is, the more abstract layers it has, and the slower it runs.

That makes CMS a perfect solution to build sites for small- to mid-sized communities (less than 50 users). I personally have had very nice experience with Xoops and phpBB. Both have great features and I think phpBB's forum is faster than Xoops' newbb 2.0 (as of year 2004). However, probably because of its long history, the code of phpBB was a bit messy in my opinion, so I ended up choosing Xoops to build sites for several communities. I became very familiar with the Xoops framework and was able to write customized modules.

However, for a personal webpage, which consists of mostly static pages (completed articles, in my case), the constant database access becomes a waste. A caching system helps, but then we still have the speed of the content-feeding script to consider. Some accelerating methods do exist and they do achieve reletively good results (by caching the compiled script (e.g. eAccelerator), residing codes in memory (e.g. fast-cgi), or some other optimization). Nevertheless, the resources needed for this purpose in exchange for speed are not completely justified in my case.

Wiki

ProsGood for authoring colaboration.
Simpler and cleaner than HTML.
Article version/history control.
ConsSyntax not totally standardized.
Weak in access control.
CamelCase compromises appearance and conciseness.

When I first learned about Wiki, I knew it right away that this is the answer to several of my needs:

  1. My first webpage back in 1994 already had a "My Dictionary" section, in which I tried to explain terms that were very sub-cultured. That saved me a lot of foot notes. However, creating the same links whenever I encountered those specific terms is very tedious.
  2. I had several chances to colaborate with several editors/translators and the version control system for codes didn't really turn out to be a good solution for non-technically-oriented writers.
  3. No matter how fluent one can be with HTML or any marked-up langauge, a clean layout and effective seperation of the content and the tags help the creative process a lot. I have worked in a linguistic project in which I had to be very fast in tagging lots (and I mean lots) of text. Having a quick and simple method to author, edit, and publish contents is very much called for.

While the concept of Wiki really appealed to me, searching for a good implement was harder than I thought.

CMS + Wiki mod

I thought it'd be nice to have both CMS and Wiki, so I tried Tikiwiki and several Xoops Wiki mods.

Tikiwikiis nice and powerful, but it's too slow and the code was too messy formy taste (as of year 2004), although I do like the easiness of writingmy own mods. Another thing I really like Tikiwiki is its great supportin multilingual posting. One can easily add another language for aspecfic article.

The Xoops Wiki mods were not bad in efficiency and tidiness, but most only provide simplified Wiki functions. phpWiki is ported as Xoops mods, but to combine its sign-in function with that of the CMS is a headache. There must be other good Wiki mods but I didn't get a chance to try them all since I alerady have a Wiwi mod (very nice work, by the way) installed on one of my Xoops sites and porting the contents to other systems would be tedious.

Again, CMS + Wiki mod isn't a good solution for simple personal webpage application, mainly because of the CMS part is too heavy.

Standalone Wiki systems

Erfurtwiki is very nice, particularly its flexibility in integration into existing systems. MediaWiki is very attractive in its look right out of the box. I think I would use one of the two, if I ever choose to use Wiki. Unfortunately, I didn't have enough time to try others.

Syntax

One big problems of Wiki systems are that Wiki syntax is not standardized. It means one Wiki article would always need a particular system to look right. Converting one Wiki article to another isn't hard, but converting a set of articles to another system is a pain.

Another thing I don't like is CamelCase. While CamelCase makes it super fast in making links, I think there are at least two drawbacks. First, it doesn't look natural. The problem is not only the lack of space, but also the lack of freedom in using lowercase in a keyword. For example, ThisIsALink is so much less natural than "This is a Link". Second, programming languages use mixed caes in variable names and CamelCase makes it very confusing if the article happens to mention variables in programming langauges.

BBS/Forum

ProsEasy for group discussion.
Most people are familiar with forum systems.
ConsSlow.
Discussion, by nature, is less organized than articles.

I have written and established several Bullitin Board Systems (ranging from unix BBS (from scratch) to dial-in PC BBS under DOS) and have posted many long articles. However, after a while, it became very difficult to find particular postings because they were buried with casual comments, discussions, and chats. BBS/Forum is for the community to talk to each other; it simply isn't for personal publishment. The other problem is that I often find it necessary to customize the forum systems, but
it's really too demanding for me alone to maintain and development my own system. This became very important when I started to realize my time and energy limitation.

Blog

ProsSimple to manage.
Easy to add new articles.
Easy to find old articles.
ConsInflexible indexing/structure.

Blog is by default a convenient substitution for traditional static webpage authoring. The on-line wysiwyg HTML editors make it possible for me to edit my articles any time, any where. Adding a new article is very simple and the indexing is automatically done. With the help of database, one can quickly find specific articles. It is simpler, thus faster, than CMS and BBS/Forum, in most cases.

On the other hand, the automatic indexing does have its drawback. For me, date wouldn't be my first choice of the main index. For my audience, exactly which date I wrote some article isn't all that important. Blog (web log), however, implies things are written daily, like a diary or a journal. The primary logical index is chronological. In that case, one may click on December 1 and find an article on Mozart; December 2, on Jazz; December 5, on Meditation before Improvisation; December 9, on Linux file server optimization; and then December 15, an article comparing Mozart and Jazz. The problem here is we have three articles related to each other on December 1, 2, and 15, but there are two irrelevant ones (December 5, and 9) in between.

Of course blog developers were smart enough to realize the problem and they give each article a category, a tag, or a keyword, or visitors to easily find things. However, again, within one category (tag, keyword), the same problem still exists. The articles are still listed chronologically, instead of logically, or prosodically.

An obvious solution would be adding static page support in the blog system, but that would sort of destroy the overall organization. It's a trade-off problem.

Choosing Blog Systems

I have used and customized several systems for friends and families. Among them, WordPress and pLog remained in action. I chose WordPress for its elegant design and rich module choices, but it was a lot of work for me to add access control into that system. pLog is very nice and it has several very dedicated contributors in Taiwan, but I still had to do a lot just to integrate an wysiwyg HTML editor and an image editor into the system. I think things should be different by now.

However, in looking for my own blogging system, I hoped to find something more ready to use. The fact that Serendipity has an out-of-box Media Management system and an wysiwyg HTML editor was very attractive to me due to my previous experience. I also like the clean code of Serendipity. The cleaner code used to mean the ease of modification for me, but now that I decide to do as little job as possible in modifying the system, what it matters more to me now is actually security. I believe cleaner code suggests the coders are more organized and have better coding habits, thus less likely to leave security bugs.

Onecomplain I have, though, is its awkward multi-lingual support. For theinterface, it's good, but for contents, there hasn't been a satisfyingsolution yet.  Now I write different languages into the sameentry; this is not easy for readers.  Writing translations intodifferent entries makes management a pain.  As mentioned before,one reason I really like about Tikiwiki is its great support in thisissue.  Serendipity does have a multi-lingual plugin, but thatplugin stores the additional language into each entry's "additionalfields", thus increasing the searching load.  I'd prefer a neatersolution, i.e. different languages of the same 'entry' should bedistinguished by language id and identified by, say, posting id. (Unfortunately we have to use 'entry' instead of 'article' here;otherwise, I think an 'article' can have different 'entries' indifferent languages.  Perhaps we can say one 'entry' has several'tongues' in different languages. : ) ) 

In addition, Serendipity is said to be very slow, especially compared to WordPress + LightPress, which I have very good impression and experience (now that I don't need the user level access control for my blog). It was a bit hard for me to choose. I must admit that my choice of Serenpidity was mainly my hope for an even cleaner code than WordPress, and that, to be fair, is very subjective.

Alternatives

The home of Serenpidity is powered by coWiki, an excellent idea in my opinion. However, I hesitate because its development doesnt seem very active.

Thursday, November 24, 2005

Blogging without Bragging

I used to write a lot and publsh a lot (web pages, public forums, mailing lists, or paper publication for communities), until one day I realized that it's so easy for everybody to voice nowadays that very few people have the time to listen. Then I decided to stop writing and start reading.

我以前寫過不少東西(網頁、論壇、群組、社刊、系刊等)。有一天,我突然發現每個人都在寫,卻很少人有時間來讀。所以我從那天起停筆,然後開始閱讀。

I read others' works, and read my own early works. And I learned a lot about others as well as myself. I realized that most of my writing was just to impress instead of to contribute. Even when what I wrote happens to be helpful for somebody, I would be so eager to take the credit, fearing those helped forget to be thankful or show respect to me.

Such attitude didn't make one truely happy after all. However, my habit of wanting to impress others has been so rooted that the ego of mine has always rationalized and found excuses for me. It took me many years to realize that I have this habit, then it took me a long time to be able to admit that I have this habit, and it took me even longer to really see why it's no good for myself.

Now I start to write again, and I hope this time, I am more aware of what I write and why I write.

我讀其他人寫的東西,也讀自己以前寫的。這過程讓我更瞭解人,也更瞭解自己。我發現自己以前大部份寫的東西,大部份是為了讓人覺得我很行很棒,很少真的寫出對別人有用的。即使真的寫出一點剛好對別人有益的東西,我也急忙要別人記得東西是我寫的,深怕別人忘了謝我。

這樣的態度終究沒讓我得到真正的快樂。不過,長期養成自我膨脹的習慣,並不容易改。我內在的那個小精靈,總是幫我找藉口來合理化自己寫作的動機。我花了好多年才看到自己這一點;然後我很長的時間才敢承認自己有這個習慣;最後,經過一段更長的時間,我才真正體會出這樣的習慣對我的傷害何在。

現在我再度提筆。希望這一次,我寫的時候,能知道自己寫什麼,更知道自己為什麼寫。

(Update 更新 2006/09/15: I found this How-To interesting, although I don't totally agree what's said there. 我發現這個 How-To, 雖然我不完全同意其觀點,但頗為有趣。)

Tuesday, April 19, 2005

[QA] 共濟會與與魔笛

...自從去年讀了《達文西密碼》這本暢銷大作之後,對於「共濟會」(freemasonry)這個組織頗感興趣(當然我曉得書中描述不全然真實),但因為我之前就知道關於「兄弟會」,後來得知歷史悠久的共濟會,會員中有許多赫赫有名的人物,政治人物、各種類別的藝術家等等,莫札特也是...

xxx wrote:

李老師您好,

我是一位xxx,對歷史及音樂頗感興趣,自從去年讀了《達文西密碼》這本暢銷大作之後,對於「共濟會」(freemasonry)這個組織頗感興趣(當然我曉得書中描述不全然真實),但因為我之前就知道關於「兄弟會」,後來得知歷史悠久的共濟會,會員中有許多赫赫有名的人物,政治人物、各種類別的藝術家等等,莫札特也是,關於這點很感興趣,我欣賞過他著名的歌劇《魔笛》,稍微了解到《魔笛》與共濟會似乎有些關聯,我找了一些書,答案仍不詳盡,在網路世界中發現貴網,您似乎是各莫札特專家,因此冒昧寫信向您提問題,我喜歡讀書,有問題總想了解透徹,也學習小提琴五六年(抒憂解悶、充實心靈以應付xxxx生涯..),小提琴音樂、歌劇,各類型音樂劇都是我喜愛的部分。關於共濟會與魔笛可否請李老師為我解惑或者提供相關連結和書籍,打擾您了!!謝謝!!

xxx

xx您好,

我認為共濟會和美國校園的「兄弟會」(fraternity)實有異曲同工之妙。有特殊的儀式,信條,語言等次文化。近年來幾部好萊塢電影都在兄弟會或姐妹會(sorority)的文化上著墨許多。"The Circle" 算是我印象較深刻的一片。其他如"Sorority Boys","Legally Blonde 2",也都讓人對這類結社有所認識。如果您有機會看到這些片,應該不難想像為什麼會員們為什麼大多是赫赫有名的人物。我們比較常聽到的獅子會,也許也有點類似。獅子會會員彼此在經濟階級上相近,亦因亦果。

共濟會的儀式性,與魔笛裡的試煉場景,讓我不禁想到很久以前看過的片子 Young Sherlock Holmes (如果沒記錯的話,中文翻成「出神入化」 )。

比起莫札特其他歌劇,魔笛通俗多了;我猜想莫札特特別以他的社團經驗寫這個歌劇,也許是在窮途末路時,希望引起共濟會會員的共鳴吧。

以上純綷是我個人依所知所做的推測。如果您要找更精確的資料,可以參考這個網頁

希望對您有幫助。

璨光