所幸有 Python,抓網頁、分析 HTML,以及處理 CSV 檔這些事情不會太難應付。
用來抓取網頁並轉存 CSV 的工具我放在 Gist 上,連結在此,程式不大,120 行左右,其中還有 20 幾行是直接從 Python 文件拿來用的,所以實際寫不到 100 行。
以下就程式碼做個簡單說明:
程式主要就 UnicodeWriter
, IMDbTop250HTMLParser
這兩個 Class。
UnicodeWriter
是從 Python Documentation 直接拿來用的 Class,作用是 unicode 編碼 csv 檔的輸出。
IMDbTop250HTMLParser
則是繼承自 HTMLParser
,繼承後要做的事就是覆寫 handle_starttag
, handle_endtag
, handle_data
這些個方法。比方說遇到 <tr>
就開始記錄一筆電影資料的 list,等到遇到 <\tr>
時就結束該筆記錄。
IMDb 這網站有多年歷史了,其 HTML 的撰寫也是相當原始,有許多不規範的地方。這也是撰寫這個小程式時主要遇到的困難點。例如在 IMDb Top 250 頁面的原始碼中有這麼一段:
<a href=http://www.imdb.com/games/guess/title:top_250?ref_=ch_qz>
注意,在屬性 href
之後的網址前後是沒有引號包夾的,這會造成 HTMLParser
解析時的錯誤。本來是想在 Parse 前把這個連結整個拿掉的,不過算了,這只是個小工具,不需要也不應該大費周章;所以用簡單的 hack 來解決就行。程式碼中的底下兩行有點突兀 (行號 13, 14),其實就是在幫上述連結加引號。
1 2 |
|
另一個麻煩就是 IMDb 其實並不真正支援 Unicode,畢竟是那麼多年的老網站了。所以在英文字母之外的文字都會以 ሴ
之類的形式出現。例如電影 “8½”,這兩個字實際在 HTML 中的樣子是 8½
。這邊要將十六進位碼(在本例中為 “xBD”)轉為對應的 Unicode Char,實際的作法可以看代碼中的 UnicodeWriter.handle_charref()
這個方法。
程式完成後,接著只要執行程式,就會得到以日期為檔名的 CSV 檔,本文最上方的圖片就是成果。圖片中的表格是在 Finder 快速檢視的視窗,如果想要在 Finder 中按空白鍵就能檢視 CSV 檔的內容,可以參考這篇文章。
喔,對了,寫這程式需要花多少時間?嗯…大概比寫這篇文章的時間還要少一點吧……
]]>「帕斯卡的賭注」內容如下:
我不知上帝是否存在。如果我信上帝,而上帝存在,則我會得到獎賞;而上帝不存在的話,我也沒有損失。如果我不信上帝,而上帝存在,則我會得到處罰;上帝不存在的話,我也沒有什麼好處。因此,正常趨善避惡的人都應該相信上帝。
乍聽還頗有道理。哲學哲學雞蛋糕在這篇文章中,從邏輯論證的角度來反駁「帕斯卡的賭注」。簡單的說,就是該賭注在論證的「前提」為真情況下成立,但「前提」是否為真卻無法判定。然而這論證方式稍嫌複雜,對一般人或沒有邏輯訓練基礎的人不容易說明。我這邊試著用更簡單的方式來加以反駁:
先姑且假設「帕斯卡的賭注」是正確的,如果不正確的話,自然也不用反駁了。接著我們將賭注中的「上帝」替換成「媽祖」,結論自然是我們應該信媽祖;把「上帝」替換成「閻羅王」,也會得到相信閻羅王存在的結論。綜合以上,任何趨善避惡的善男信女應該又信上帝又信媽祖同時又信閻羅王。
然而這麼一來就產生衝突了:上帝是獨一無二的,如果承認上帝,則媽祖與閻羅王不可能也是神。由於我們不知道上帝、媽祖、閻羅王甚至其他林林總總八百萬眾神是否存在,只能假設他們存在的或然率都一樣。於是從機率角度來看,我們應該信仰那些屬於多數且互不排斥的神,死後獲得獎賞的機會會比較大。
因此結論是,「帕斯卡的賭注」證明了多神論者死後上天堂的機率高於一神論者(誤)。
]]>以中國地名為道路命名純粹是命名時沒創意又不動腦筋的結果。這點古今中外皆然。
台北今日多見的「中國地名道路」,主要是在1947年所改名的。在1945年戰爭結束,日本將台灣移交中國後,台灣省行政長官公署(台灣省政府前身)將台北街道由日治時期所制定的日文名稱改為中文名稱,例如八甲街、署後街、龍山街等。
不過有去過日本的人大概知道,日本並不像我們一樣,每條道路每條街巷都有名字,他們的地址寫的都是街廓名,例如「神戶市中央區北長狹通2-5-1」裡的「北長狹通」就是街廓名,是一個區塊,像「西門町」那樣一大片,而非指一條道路。因此在1947年台灣省行政長官公署又將台北市的道路重新命名,以一條條的線形道路為單位,如同我們現在所習慣的方式。今天台北的中國地名道路,就是在那個時候取的。那時候國府還沒逃到台灣,所以當然也不是為了要反攻大陸而把道路取成漢口街、武昌街之類的。
以其他地方地名命名,在許多地方都可以見到,美國就有以英國地名命名的城市,如紐約、紐澤西、新罕布夏、麻省有劍橋市等等,以英國地名命名的道路更是多不勝數。中國許多城市也有以其他城市地方命名的街道,一個很有趣的例子是上海的南京路(今上海南京東路),雖然是以中國地名命名,但這路名卻是英國人取的,除了地名「南京」本身的涵意之外,也有紀念「某個事件」的意義。
話說南京路原本是英國租界裡的一條賽馬、跑馬的道路,1865年,英國駐滬領事向上海公共租界工部局(上海各租界自己組成的行政機構)提議要為租界內的道路重新命名;這條跑馬的道路要叫什麼名字呢?英國人想到為了紀念使上海開埠的《中英南京條約》(中國近代第一個不平等條約),因而將那條跑馬的道路命名為南京路。
說穿了,不只南京路,其實上海許多以中國地名命名的道路,幾乎都是「洋人的玩意」。怎麼說?在十九世紀清末時期,上海的英國租界與美國租界合併為「上海公共租界」,租界合併,街道名稱得統一一下,可是英美兩邊的人馬都堅持自己原有的名字,最後英國領事乾脆訂了個「上海馬路命名備忘錄」,全部規定以中國地名命名,省得吵架。「備忘錄」中明訂,南北道路以省份命名,東西道路以城市命名,因而成了今日上海市道路的模樣。
然而這份備忘錄影響的不只是上海。前面說到1947年台灣省行政長官公署將台北的道路重新命名,當時負責命名的正是一個上海來的建築師鄭定邦。可想而知,鄭定邦是以他所熟悉的家鄉道路命名方式來幫台北的道路取名字。關於這段歷史,可以參考龍應台所寫的住在一張地圖上這篇文章。
於是追本溯源,台北的「大中國地名」,這規定其實還是源自英格蘭人的點子。想想歷史也真是諷刺!
而我們今天所講的「馬路」,並不是因為古代的道路是馬在上面跑而稱作「馬路」。「馬路」一詞是近代才出現,有一說就是源自於前面所提到的上海南京路的原始稱呼。因為上海南京路原本是作為跑馬場用,因此被俗稱為「大馬路」,後來「馬路」一詞逐漸被沿用為泛指一般道路。
還有另外一說,則是指近代的築路方法是由十八世紀的英格蘭人約翰.馬卡丹 (John MarkDan) 蘇格蘭工程師約翰.馬卡丹 (John McAdam) 所設計,馬卡丹以碎石鋪路,路中為高、兩側略低,以便於排水,也方便車輛馬匹通行。這種新設計的道路傳入中國後被稱為「馬卡丹路」,俗稱「馬路」。
不過我找了一下 Wikipedia,卻不見哪邊有 John MarkDan 這人的生平事蹟或介紹,感覺像是個都市傳說。有知道這段歷史的人還請不吝告知。
在上圖中,下面的是我的舊錢包,上面是新錢包。舊的錢包鼓鼓的,可是並不代表我荷包鼓鼓的,與之相反,我窮得要死--喔,我知道你想說什麼,但我也沒有到「窮到只剩下錢」這種境界。錢包之所以鼓鼓的是因為裡面裝了一堆證件、卡片,常光顧的書店有五、六家,於是塞了這許多張會員卡;有開戶的銀行也有五、六間,同樣就有對應數量的金融卡。另外 iCash、悠遊卡、電話卡、名片等等族繁不及備載。
錢包裡卡片證件的數量,就算拿來當大祕儀塔羅牌(22張)算命都不成問題!
既然決定了要將錢包瘦身,所以我開始思考哪些卡片出門可以不要帶,希望能減低錢包的負擔。不過從這個方向思考很快就卡住了,總覺得沒有什麼是可以不要帶的。
於是我換個角度想:「有什麼東西是非帶不可的?」轉個方向果然茅塞頓開,以下是我放在皮包裡的東西:
鈔票數張
證件
卡片
雖然少了許多,但錢包中仍舊放了六張卡片,只是我再怎麼想也找不出哪張是可以放棄的,那就先這樣吧。至於其他像是會員卡之類的通通不帶,例如康是美會員卡或是星巴克的隨行卡,那些都是久久去一次的消費。我過去偶爾有用名片盒,偶爾直接名片放錢包。不過這次決定通通放錢包,名片盒多帶多費事,我每次出門就是固定放個幾張在錢包,用完就補;收到的名片也放錢包,回家就整理。
整理完了錢包,就會想要好好檢視一下出門的隨身物。
上面 Liv Tyler 的 VISA 廣告是個理想,只要在後邊口袋塞張卡片就可出門。我曾仿照廣告中,只帶張信用卡就出門,帥氣的很!不過一出了大門就後悔,我沒帶鑰匙可以回家,也沒帶電話可以求救,上一秒帥氣下一秒變遜咖。
除此之外,在台灣,光帶一張信用卡,很多地方也都不能消費。
回歸現實,出門到底要帶哪些東西?佐藤可士和在《佐藤可士和の超整理術》一書中有提到,他出門時的配備:
……各位平常工作的日子,都是帶什麼公事包出門?裡面又裝些什麼?
順道一提,我自己多半是空手。隨身物則包括:
- 行動電話
- 住家鑰匙
- 卡片收納包(內有信用卡兩張、工作室的卡片鑰匙、紙鈔數張)
- 零錢
因為東西不多,可以將它們分別收納在口袋裡。
基本上,我出門的家當也多半如此,一般男性褲子的四個口袋恰恰可以應付:
佐藤可士和並不帶筆記本,他用手機滿足筆記的需求。不過我覺得有時候手寫還是方便許多。不過要多帶枝筆真的很不方便。
不過有些時候出門要帶些文件什麼的,那就不適合空手出門了,有個包包還是比較方便。如果確定出門會買東西或拿東西回家的話,我也會帶包包,甚至包包裡再放個購物袋。接著就來看看我在包包裡會放的東西:
基本上也是盡量簡單。以前上班出門每天帶著包包,包包裡都裝了照相機和 MP3 錄音筆,總想說看到什麼有趣的可以立刻拍下,或是騎車回家時可以聽聽演講或課程。不過都是帶心安的,根本不常拿出來用。
自從輕簡錢包與包包後,我發現行為會改變態度,態度又反過來影響行為。對於一些事情我也有了與過去截然不同的觀點。
對於會員卡的慾望減低了
過去買東西時,店員常常會建議要不要順便辦張會員卡,反正不貴,甚至免費。然而我現在不想多放卡片進錢包,因此也就不需要多張會員卡來自尋煩惱。遇到店員建議我都直接回絕。
減少衝動型購買
以往看到喜歡的書往往當場就帶去結帳了。現在只帶一張書店會員卡,在其他的書店看到喜歡的書時,就會想說先記起來,下次去有會員卡的那家書店再買好了。往往經過時間這樣一沈澱,那本原本喜歡的書就會變成不需要購買的書了。
減少時不時的提心吊膽
以前錢包超大,有時候放屁股後的口袋超不舒服。於是為了這個錢包,我得特地帶上包包出門,把錢包放包包裡。而因為錢包不在自己身上,因此只要上廁所或是其他離開包包的時候,就會容易一顆心懸在半空。
對於選擇包包重點的改變
從前我買的包包都有一個共同特色,就是有很多口袋,非常強調功能性,最好是每個東西都剛剛好有個適合放置的地方,這個格子放手機、那個格子放隨身碟、前面的格子放 MP3、後面的格子放照相機這樣。
現在的話則是簡單為主,包包裡只有一個小拉鍊袋,其他都是單一空間,物品直接往裡面丟就好。當然,為了避免包包裡面過於混亂而變成黑洞,自然會避免一直丟太多東西進包包裡。
]]>
對於這樣的問題,我向來只能笑笑的回應,「不好意思,沒有呢。」然而真要說的話,我國中時剛學英文,老師就幫我取過英文名字;高中時也曾經自己跑到書店去很努力的翻英文人名辭典,挑了一個意涵自己很喜歡的名字來用;大學剛畢業不久,上法文課時也取了個法文名字。但最後出了社會,這些名字我通通沒有在用。
我沒有英文名字並不是單單只是因為「沒有取」這麼簡單,其實背後有過一番思考,只是對於初見面的朋友往往不適合長篇大論解釋,而對於熟識的朋友也不會特地解釋自己的名字。索性在這邊寫篇文章來說明我的想法。
這裡請容我引用〈為什麼我們要取英文名字?〉這篇文章的內容,列舉常見的取英文名的原因。
- 因為我們擔心別人不容易發中文音,會不知道怎麼唸我們的名字啊!
- 對西方人來說,他們並不熟悉中文名字,他們不容易記得。為了讓西方友人記得他們的名字,所以選用英文名字。
- 是一種現代社會的一種現象,一種流行! 幾乎人人都有英文名字,所以自己也要取一個。
- 因為台灣愈來愈國際化,所以取英文名字是國際化的象徵之一。
- 因為取英文名字具有匿名性,可以保護個人隱私。
- 方便登入網路帳號。
- 用英文名字和同事彼此稱呼,免去了頭銜,感覺比較親切。
- 因為所有的學生都得學習英文,老師為了讓他們更深入英文的學習環境,所以要求他們取英文名字。台灣的政府甚至規定,小學生的英文考試及格的條件之一是得會拼寫自己的英文名字!(當然,也可以選擇用自己中文名字的拼音法來寫,但幾乎所有的英文老師都沒跟學生說明這一點!)
- 個人浪漫情懷/虛榮心作祟,因為自己不能決定自己的中文名字(父母/監護人在出生時即已命名),所以想要若可以自己選個喜歡/好聽/特殊的英文名字是一件美好的事。
其實上述每個理由都不是取英文名字的必要條件。就拿第四點「取英文名字具有匿名性」來說好了,那麼我還寧願取「山新德南」或是「大中天」這樣的名字,不也同樣具有匿名性?何必非英文名不可?
其實我覺得絕大多數人取英文名字的原因很簡單,只是「因為大家都這樣做」。至少之前的我就是這樣,因為上了英文課,大家都有英文名字,所以我也取了一個,取了就成為習慣,習慣成自然,覺得每個人都要有個英文名字才是理所當然。
然而這看似常識的想法並非真的常識,對外國人而言,每個台灣人都有個英文名字反倒是很奇怪的一件事。讓我們逆向思考一下:
外商公司裡的外國人每個人都取個中文名字,這樣的公司見過沒?
沒見過吧?但在非外商的公司,甚至員工全是台灣人的公司,卻有可能上至老總下至總機每個人都有個英文名字。仔細想想,這現象豈不怪哉?
雖說我沒有英文名字,也覺得「全民取英文名字」這現象很莫名;但我對別人的英文名字倒沒任何意見。我認為這就像是古人的「字號」一樣,都是為了方便別人對自己的稱呼。像是「陶淵明,號五柳先生」,或是「蘇軾,號東坡居士」一樣。既然如此,名隨主人,主人愛取中文、英文抑或日文作為別號,自然也就悉聽尊便了。
當然,也確實有些人是因為文化崇慕或是工作因素等等原因而取外國名字。例如鉅作〈The Art of Computer Programming〉的作者 Donald Knuth 就取了個中文名,叫做「高德納」,連姓氏都中文姓名化了。如果對照當下台灣人英文名字半中不西的取法(姓氏用音譯,名字用英文單字),那麼 Donald Knuth 的中文名搞不好就會變成「克努斯德納」這樣的半調子中文名了。
既然談到中英姓名翻譯,就順便來談我自己的中文姓名英譯。我姓名的拉丁字母拼法是 Tzeng Yuxio,不是採用通用拼音或漢語拼音,拼音法的方式暫且擱一旁,我想談的是姓與名的順序。
記得有次報名一個國外活動時,我把我的姓名英譯寫給朋友,請他幫我填在網路表單上。由於姓名的欄位只有一個格子,於是朋友按照英文前名後姓的習慣,幫我填入「Yuxio Tzeng」,我當時大叫不行,堅持一定要「Tzeng Yuxio」,不過也可能是急了,沒有好好對朋友解釋。後來想想,其實要解釋的話很簡單:
Michael Jackson 的中文譯名是「麥可·傑克森」還是「傑克森·麥可」?
答案很明顯。我們並沒有因為把人名翻成中文,而順便也改變姓與名的順序,變成「 傑克森·麥可 」。注意到其中的盲點了嗎?
我這邊想要強調的是,姓名的英譯,或是翻譯成其他語言,應該保留原本文化中的姓名格式,而非單純把姓和名分開音譯後填入翻譯後語言的格式。更何況,這世界上不同文化的人名規範多的是,不是只有華文圈的「姓+名」與英文圈的「名+姓」。
就以去年 (2011) 成為頭條的「賓拉登」為例,賓拉登的全名是「奧薩瑪·賓·穆罕默德·賓·阿瓦德·賓·拉登」,這裡的「賓」字是詞綴,表示「某某的兒子」,因此「奧薩瑪·賓·穆罕默德·賓·阿瓦德·賓·拉登」的意思是「拉登之子阿瓦德之子穆罕默德之子奧薩瑪」,或是簡稱「奧薩瑪·賓·拉登」,亦即「拉登的子孫奧薩瑪」。阿拉伯的人名並不像我們或歐美有所謂的姓氏或家族名 (Family Name),所以,如果要用來指稱去年落網的基地組織首領,「奧薩瑪」其實是遠比「賓拉登」還要來得貼切的名字。
而且既然阿拉伯人名的系統與我們習慣的姓名系統大不相同,人名翻譯時按音譯即可,不需硬套進我們姓名系統的格式;推而廣之,華人姓名與歐美姓名的排列方式不同,音譯時也彼此尊重,按其文化原本方式順序翻譯即可,不必硬套入自己的格式。
想想看,早期的翻譯小說中,英美人名都是翻成郝思嘉(Scarlett O’Hara)、白瑞德(Rhett Butler),看著多少也覺得彆扭。然而現在的小說已經不這麼翻了,都按原名順序的方式音譯。既然如此,那麼為什麼你的中文名字翻成英文還要名姓顛倒呢?
請多珍惜自己的名字。
]]>上個週末,有一群熱愛遊戲的人參與了一個叫做 Game Jam 的活動,Game Jam 指的是在短時間內(通常是兩天 48 小時內)依照活動主辦者所公布的題目,快速開發出一款遊戲。上週所舉辦的 MIT Game Jam 便是台灣第一次的 Game Jam 活動。我在前幾天參加了這場 Game Jam,並且和當天第一次碰面認識的朋友們,合力完成了一款 iOS 遊戲。
我們做的遊戲叫做《Dora》,遊戲以 Objective-C + cocos2d 開發,在 iOS 上運作。活動結束後會放到 App Store 上供免費下載。除了遊戲本體外,程式碼也完全開放,兩天內兩名程式累積了 55 次 commit,有興趣的人可以點下面連結看看。不過真的是看看就好,Game Jam 時所寫的程式碼品質是非常慘不忍睹的…
44:00
到 47:00
。影片中也有其他組的成果發表。我們這款遊戲的故事,主要是說有一個叫 Dora 的超強大機器人,她在看購物頻道時,意外愛上了吸塵器這個小東西。然而製作出 Dora 的瘋狂博士卻不想看到他的 Dora 因為愛上吸塵器而不務正業(幫博士征服地球),於是派出大軍要消滅吸塵器與 Dora。
遊戲中有三個吸塵器。吸塵器會受到攻擊而消滅,不過 Dora 可以把吸塵器撿起來,裝備在自己身上,這時吸塵器不僅可以免於被 NPC 攻擊,Dora 也可以幫吸塵器回復 HP,但同時也會消耗自己的 HP。此外,裝備(保護)越多的吸塵器,Dora 的動作就會受到限制,當三個都裝備起來時,Dora 甚至無法攻擊,行動也會變得緩慢。
這種「主角很強,配角很弱;主角的目的是要保護配角,但是當保護配角時,主角本身也會因為牽絆而喪失自己的強大。」便是我們對於這次主題的詮釋。
遊戲的操作分成左右按鍵與 A, B, C 三個按鈕。左右是移動,A, B, C 則分別是「近攻」、「遠攻」與「把吸塵器抓起來」。當抓起一個吸塵器後,B 鈕的作用會變成「把第一個吸塵器拋出」;抓起第二個時,要按 A 鈕才能拋出。因此,抓越多吸塵器在身上保護,能作的攻擊選項就越少。
10:00
離集合時間還很早就已經到元智了,天氣不錯。11:00
公布題目與分組。我們組成員一企劃(橘之介)、一美術(建愷)、兩程式(Jason 和我),共四人。12:00
針對要開發的題材與類型進行討論。13:00
初步討論完後便悠閒地一起去吃午餐。吃完回來進行更細部的製作規劃,並決定以 Objective-C 作為開發語言。14:30
各組開始進行報告。16:00
有初步的角色移動,以及 UI 介面。18:00
角色的移動與 UI (Virtual Pad) 整合。加入背景與角色移動動畫。20:00
加入了產生 NPC 的功能,以及主角的攻擊動畫與操作。20:30
各組階段性成果 demo。在 demo 前我們又加上了背景音樂。還有晚餐是麥當勞。21:00
Demo 結束後,程式與企劃都回家休息,企劃因為家住比較遠,所以留在現場過夜(辛苦了~)08:00
我昨天回家後就休息了。早上比較早起來,編寫敵人的動畫演出。10:00
由於出門比較晚(程式沒寫到一個段落,不想就這樣擱著先出門),到達會場的時間差點遲到。11:00
隊友也完成了吸塵器(就是遊戲主角 Dora 要保護的對象)功能。美術今天開始將昨天所使用的圖全部重新刻一遍,企劃整理開發資料與簡報,準備下午的 present。12:00
加入了 Dora 與吸塵器的血量,還有 NPC 出現的波次。已經比較有關卡的感覺了。13:00
中午大家一起出去校外用餐,休息一下轉換心情。感謝建愷,推薦了不錯的涼麵店。下午 1 點回來後開始最後衝刺。14:00
加入 Game Over 功能。NPC 原本只會亂走一通,現在會追著主角了。15:00
更新美術繪製好的新圖檔,質感一整個提昇。加入 NPC 攻擊動作(但打了還不痛)16:00
Dora 與吸塵器會受傷了。換上新的 splash 圖檔與 icon。16:30
修正 Bug, Game Over 顯示 NPC 進攻波次與砍殺數。進入最後各組 demo。對了,吃披薩。在參加 Game Jam 之前,我原本想要用 python + pygame 進行開發,還因此在活動開始前幾天刻意熟悉了一下,不過事後發現這些都是多餘的。事前的練習與準備,對於單人隊伍的開發或許 OK,不過如果是隨機湊隊的活動,我們無法預料到會與什麼樣的隊友合作,因此拼的就是平常累積的基本功了。在這方面,好在 Jason 對於我們所使用的 cocos2d 引擎有深厚的瞭解,我許多開發上遇到的問題都可以請教,從而省下許多開發時間。也在這短短的兩天裡學了不少,也許平常一個禮拜都還沒辦法做到這麼快的熟悉吧。
另外,在 Game Jam 的過程中,休息本身--或者說,開發的疏密節奏--也是很重要的。雖然是短期開發,可是人的身體畢竟不能連續好幾個小時保持高速運轉狀態,適當的休息喘口氣,讓腦袋沈澱、身體充電,才是維持開發速度的不二法門。我第一天幾乎都忘了休息,結果第二天早上呵欠連連。
最後在這邊要感謝獨立遊戲開發者分享會 (IGDSHARE) 與元智大學舉辦了這個活動,IGDSHARE 的工作人員可是從活動前一天開始就在會場準備了,最後也順利圓滿完成了第一屆以台灣開發者為主的 Game Jam。也要謝謝我們 E 組的每個組員:Jason, 建愷與橘之介,你們真是太棒了,少了任何一個人,我們都無法在這麼短的時間內做出這麼完整的遊戲。
最後的最後,我想要感謝我的家人,謝謝你們的支持,讓我能無後顧之憂地全心投入開發。感謝你們。
]]>因此,開始有些遊戲試著將 2D 與 3D 的世界做融合,將次元(空間維度)轉換的概念帶進遊戲,藉以呈現出現實中無法體會到的神祕空間感。這類型遊戲目前數量不多,次元轉換的型態也各異其趣,以下文章便是想簡單介紹下目前筆者已知的次元轉換遊戲與形式。
這大概是最早的一款次元轉換遊戲了。剛推出時的展示非常令人耳目一新:原本 2D 橫向捲軸的瑪莉歐,在遇到無法前進的關卡時,可以轉換視角變成具有 3D 透視的畫面,藉此發現在原本 2D 橫向視角下所無法注意到的道具或路徑。紙娃娃般的質感加上新鮮的遊戲系統,讓我對這遊戲抱著非常高的期待。
不過實際玩了之後發現,遊戲的世界觀與我們所習以為常的瑪莉歐世界其實有很大的出入。根據說明書,這次瑪莉歐來到一個異世界(話說他原本所在的地方就算是異世界了啊……)這異世界裡的怪物和居民的長相老是讓我覺得我在玩的遊戲不是《瑪莉歐兄弟》的系列作。加上關卡與關卡間還有類似村莊的設計,玩家得到處找異世界的居民對話收集情報,感覺實在很沒勁,因此玩了一陣子我便放棄這款遊戲了。
嚴格來說,這款遊戲本質上是 RPG,然而他的賣點卻是在平台動作遊戲部分的視角切換,兩者相結合反倒成了一個不上不下的作品。
這款是很有名的虛擬遊戲,出現在漫畫《大東京電玩箱》裡。《大東京電玩箱》是套描寫電玩業界的漫畫,幾乎是遊戲從業人員的必看讀物,而裡面的《絕望高校》則是主角們目前正在努力開發的作品,以目前台灣單行本的進度(第 6 集)來看,遊戲目前已經開發到了可以推出體驗版供人試玩的程度了。
《絕望高校》是款捲軸射擊遊戲。一般射擊遊戲可以分成橫向捲軸和縱向捲軸,而《絕望高校》則是同時間揉合了兩種捲軸模式,可以想像成《兵蜂》與《極上瘋狂大射擊》兩者的結合。由於兩種視角有相當大的差異,因此這款遊戲的關卡設計對於開發人員是一項相當高的挑戰。
Revolver 是左輪手槍的意思,這款遊戲也正如其名,具有如手槍轉輪一般的視角調整系統。遊戲的進行如同一般 2D 橫向捲軸射擊遊戲,但是實際上卻是在 3D 空間的關卡中進行遊戲。玩家可以旋轉本機角度,藉以改變投影到螢幕上的 2D 平面,進而閃躲原本滴水不漏的彈幕攻勢。
這款遊戲與其他次元轉換遊戲相比,較為特別的一點是具有無段式的轉換。其他的遊戲都是一次旋轉 90 度的平面,但是 Revolver 360 的旋轉可大可小。遊戲的聲光效果華麗,但是關卡與敵人的設計則稍嫌單調,使得次元轉換的機制只能拿來閃閃子彈,沒有好好利用,相當可惜。
這款遊戲的玩法跟下文所介紹 Fez 接近。遊戲是像瑪莉歐一樣的 2D 橫向捲軸,玩家藉由旋轉世界,得到不同的視野平面,以找到能夠往前進的道路。
雖然 Sky Island 是在 Fez 提出概念 (2007) 之後才推出的,網路上也有認為 Sky Island 是山寨 Fez 的這種說法,不過我倒覺得不用如此看待,畢竟 Fez 當時只是個概念性想法,Sky Island 比較早出,而且在沒有前例的情況下,也做出了不錯的關卡設計。
其實在遊戲界待久了會發現,沒有什麼點子或創意是完全獨創,只有某個人才想得出來,其他人都想不到的。在業界,大家接受的資訊都差不多,能想到的也相類似,很多創意,都是同時在不同的地方被不同的人所想到;有些點子,也是在某種技術成熟之下才變得可能,於是這時候要比的就是看誰作得快,或是看誰作得完整。
Sky Island 的手腳夠快,他們交出了一個好玩的小品遊戲。而 Fez 則是做得完整,將「次元轉換」的平台遊戲發揮到一個極致,甚至到可以稱作藝術品的境界,這點我們稍後會再提到。
這邊介紹的次元轉換遊戲,遊戲方式多半都是在 3D 的空間中轉換不同的 2D 視角。不過《Nightmare Puzzle Crush》則完全不同,或者說「次元轉換系統」的描述對於《Nightmare Puzzle Crush》這款遊戲更加名符其實。
玩家平常是在 3D 的世界進行探索,探索的時候可以切換不同角度視角,例如從角色的側面看過去,或是從正上方看下去。不管是在 3D 透視下的哪個視角,只要按下 Crush 鍵,遊戲就會立刻變成 2D 平面,世界像壓扁一樣,完全沒有視野深度。所以說這是真正從三次元到二次元的「次元轉換系統」
附註。感謝 @segafankwl 提供以下資訊補充:
補充一下,CRUSH在2007年就出在PSP上了,3DS版好像是重製(關卡設定不確定,至少故事設定一樣),PSP版知名度很低,台灣也沒代理,但是很神奇的地下街出現過一片美版二手片,被我買走了XD
如果說 2012 最值得一玩的遊戲是哪一款,即便今年過還不到一半,即便 D3 才剛剛上市,我所推薦的答案毫無意外,就是接下要介紹的 Fez。Fez 的概念很簡單,跟前面介紹過的 Sky Island 一樣,就是旋轉視角,然而 Fez 充分利用了這個概念,設計出許許多多的謎題與關卡,就如同 Braid 把時間倒流這個觀念發揮到淋漓盡致一樣。甚至連介面也採用了一致的操作。
除了關卡設計外,Fez 這款遊戲也提出了一個相當完整的世界觀。這邊用來形容世界觀的「完整」兩字,並不是指創作者在這個世界裡設定了完整的曆法、完整的風土人情、完整的宗教與政治體系等等等;而是創作者的心中對於這個世界長什麼樣子有著清楚而一致的輪廓,並落實到設計上,使得玩家在探索這個世界的同時,會不斷透過蛛絲馬跡發現這個世界的輪廓,進而在遊玩過程中不停去思考:這個世界到底發生過什麼事?這又到底是個什麼樣的世界?
對於 Fez 的介紹無法以此三言兩語短暫形容。有機會的話,再作更詳細的介紹吧。
]]>然而正由於目前沒有一致性的標籤標準,人們對於標籤的使用也很隨興,所以會常常看到下面三種情形:
同一個概念以不同的詞語組合方式標籤
例如一篇文章中同時加入了 win7
, Windows 7
, MS windows 7
, windows-7
等標籤,有縮寫、有全名、有各種不同的連接詞。這種現象在以搜尋流量為主的媒體網站中尤為常見。上面的圖就是一個活生生血淋淋(?)的例子,這組關鍵字取自 Engadget 的這篇文章。
同一個概念以不同的單字形式標籤
以英文做標籤的網站中很容易發生這種情形,因為一個概念在不同的詞性表現下就是不同的單字,因而成為不同的標籤關鍵字。例如我想要加上「部落格」這個標籤,用英文寫時就可能同時把名詞、動詞、動名詞,還有單數型複數型全部通通填上去,像這樣: blog
, blogging
, blogs
。
同一個概念以不同的語言標籤
這個就是多語言使用者的苦惱了。例如像我這樣的宅宅就會因為以下 動畫
, アニメ
, Anime
, 動画
等標籤到底要用哪個好而苦惱,而最後的結果通常就是全部都用。
這三種情形都是用不同的方式去標籤同一個概念,雖然初衷是為了將來方便搜尋,但往往反而導致搜尋時的困難。考慮以下情形:假設我的一篇部落格文章用了 win7
與 Window 7
作為標籤,另一篇主題近似的文章卻是用了 Windows 7
與 win-7
作為標籤。這種不一致性會讓讀者在前篇文章中點下 win7
這個標籤連結時,無法將所有主題相關的文章列出。
另外一個問題則是製造不必要的心力浪費。因為沒有一個標準來選擇用哪個單詞做標籤,因此也不知道自己將來要回頭找資料時,會用哪個單詞來做搜尋,只好想辦法把所有自己想得到的所有相關字一股腦兒全部填入。
為了避免上述問題,雖然目前每個網站的標籤機制如同多頭馬車各行其道,制定一個自己個人使用的標籤習慣(或規範)倒是可行的一個作法。這個問題相信困擾的不只是我,上網找了一下,有兩篇值得參考的文章,第一個是 Calvin C. Yu 所寫的 Taggin Guidelines (在投影片中的第 13 頁),主要原則如下:
- 簡練
- 小寫
- 單數
另一個參考是由 Hutch Carpenter 所提出的,他認為標籤機制應該有個標準,而這個標準就是複數詞組,逗號分隔 (Multi Word, Comma Seperated)。
而我自己所使用標籤的標準如下:
簡便性
盡量簡單。
方便輸入。所以標籤時會以英文為主,例如用 browser
而不用 瀏覽器
。
自己容易想起。通常第一個想到的字詞就是了。
使用容易理解的詞。
一致性
一個概念一個詞。所以 動畫
, アニメ
, Anime
, 動画
就只剩下用一個 anime
。
小寫。同樣是為了方便輸入。
用單數,用名詞。當然,這免不了會遇到例外情況,主要還是要依照使用情境判斷。
人名的標記盡可能從主人。例如使用 菅野よう子
而非 菅野洋子
, 韩寒
而非 韓寒
。除非該人名的原始拼寫方式我不熟悉,例如我總是想不起來戈巴契夫怎麼拼,那就直接用戈巴契夫
吧。同樣是以自己方便為最高原則。
除非是自己口語常用的縮寫,不然不使用縮寫作標記。nds
win7
xbox360
都很好理解,可是用 resp
req
來做為 response
request
標籤的替代,就太過頭了。現在連寫程式都不鼓勵這種縮寫了。
格式
省略單字間空白。也就是說用 macosx
而非 mac os x
。不過英文人名是例外;日常用字如 smartphone
我們容易斷字,相對的人名如果省略空白有時候就不容易逆推。其他如果空白省略會造成歧異的話,也應該保留空白於關鍵字中。
以逗號區隔關鍵字。正確來說應該是以「逗號加空白」區隔關鍵字。
以上便是我個人使用的標籤規則。如果你有不錯的標籤習慣,也歡迎一起討論分享。
]]>原本以為 Octopress 沒辦法加,不過實際嘗試後發現並不難。要修改的地方主要有 source/_layouts/default.html
和 source/_layouts/post.html
這兩個檔案。
Octopress 內建的 twitter, google plus, facebook 三項文章分享功能如果全部打開,會佔掉約 680px 左右的畫面寬度。當文章區塊的寬度小於這個數值時,facebook 的按鈕會跳到下一行。這邊可以透過修改 source/_includes/post/sharing.html
的方式來稍微縮減 facebook 區塊的寬度,以符合需求。
同區塊另外一個問題則是在預設版面中, twitter, google plus, facebook 三者按鈕的高度不同,尤其 facebook 的位置比較偏下。這邊我參考 StackSocial 頁面最下方區塊的作法,將三個按鈕改成 ul → li
格式。
這是花最多時間與腦力的一部分,尤其是我沒有 Ruby 基礎,好在 Ruby 的程式碼不難看懂,我雖然寫不出來,但是我看現有的 code 依樣畫葫蘆,一樣生出功能。這邊主要參考了 Octopress 內建的 Category Plugin,稍作修改,便得到了標籤功能。
透過這次修改,同時也對 Jekyll 所使用的 Liquid Template System 有更深入的了解。想想要整一個 Octopress 網站也真折騰,除了要懂 HTML, CSS, JavaScript 這些基本的之外,還得會摸 Ruby, Sass, Liquid Template,滿滿都是術語與新東西,真不是件簡單任務。
話說既然加入了標籤功能,接下來就是找個時間好好整理每篇文章的「分類」和「標籤」了……嗯,這讓我想到一句老話:
]]>要改的東西太多,那就改天吧。
我很好奇每個人都是怎麼樣使用手上的智慧型手機,有時候在和朋友聊天時,往往可以發現一些自己從未想過卻很方便的小技巧。前陣子剛好看到一篇文章〈45 Unique iPhone Home Screens Explained〉,有 45 個人的 iPhone 首頁耶,身邊的好友有 iPhone 的也沒這麼多。看完這篇,真的可以發現每個人都有屬於自己獨特的使用方式。
不過光這樣看完還不過癮,我決定做個統計。雖然上面那篇是去年八月的文章了,至今過了半年,不過大部分 App 現在還都蠻流行的。統計的結果如下,可以參考看看。
最多人放在 Dock 上的 App 排名如下:
(不包含 folder 以及 folder 中的 App。括號中數字為人數)
人數在 3 以下的我就省略不列了。另外,上表中的前七名就已經包辦 45 支 iPhone 裡八成以上的 dock 空格了。
不分 dock 與否,首頁最常看到的前 20 個 App 分別是:
(不包含 folder 以及 folder 中的 App。括號數字中為人數)
再來的 App 就是少於 10 個人放在首頁的,分別是 Instapaper(9), Hipstamatic(9), Google+(7), Wunderlist(7), Evernote(7), Things(6), 天氣(6), Remote(6), iTunes(6), iBooks(6), 1Password(6), 計算機(5), Skype(5), Simplenote(5), Dropbox(5)。
低於 4 以下的我就不列出了。
你怎麼運用你的主畫面呢?有任何的點子都歡迎與大家一起分享!
]]>我不常在 BBS 上直接編輯,多半都是在習慣的編輯器上寫好再貼過去。不過問題來了,我寫文章的習慣都是一直打字一直打字,直到段落結束才換行,這樣的文字如果複製起來直接貼到 BBS 上發表,雖然還是能夠正常顯示,但在編輯與回文時就會出現過長的文字而造成如上圖般糟糕的版面效果。
所以我在把文章貼到 BBS 上前,會先進行排版,將每行的字數限制在 72 字元以下。一開始我還乖乖手動一行一行按 Enter,可是這勤勞樸實的作風太不符合以 Lazy Easy 為最高指導原則的程式設計師身分了。經過一番研究後,我用 Vim 來做為我文章自動排版的工具。
要完成任務,首先得在 .vimrc
檔案裡加入以下設定:
set fo+=Bm
set tw=72
說明一下,tw
是 textwidth
,這邊的意思是每行長度為 72,你可以依個人喜好調整數值。而 fo
則是 formatoptions
的縮寫,其中的 Bm 都是與 Multibyte 相關的選項。沒加的話,預設是會採用英文規則,也就把空白當做字的間隔,因此一連串中文文字不會被斷開,那就達不到自動斷行的效果了。
接著,為了讓事情更方便些,可以加入以下的按鍵映射:
noremap <silent> <F7> gggqG
我把 F7 按鈕對應到 gggqG
,這串指令可以分成三個部分:gg
, gq
, G
。
gg
: 將游標移至檔案最前頭gq
:從游標開始處進行格式重排G
:將游標移至檔案最尾端所以以後只要在 Vim 寫好文章,或是把寫好的文字貼到 Vim 上,再按下 F7,就可以立刻排成 BBS 所需要的格式囉。
只剩下一個問題……如果文章中有太長的連結,要是能自動縮網址那就更完美了。
]]>這小工具很簡單,按年份分別列出該年寫了幾篇文章,總共多少字數。由於 Octopress 的文章其實就是一個個 markdown 純文字檔,所以要做統計並不困難,我不用想盡辦法連到資料庫或是將網站匯出 XML 來做分析。不過這個工具使用到 *nix shell 環境,Linux 與 Mac OSX 的使用者可以無痛使用,Windows 的話可能就要安裝一下 cygwin 或其他類似套件了。
工具的代碼如下,使用前,請先自行修改代碼中 SYEAR
與 POSTPATH
這兩個變數,以符合自己的需求:
附帶一提:字數的統計是直接使用 wc -m
,也沒有去掉 YAML 檔頭,所以不是很精確,大概參考參考就好。
「標籤」功能,在今天的網站應用中,已經是極為普遍的一種機制,甚至在許多桌面的應用上也可以見到「標籤」的蹤跡。在不同的地方,標籤可能有不同的名字,例如:
tag
: Picasa, Flickr, YouTube, amazon, WordPress, 豆瓣label
: Gmail, Bloggerkeyword
: iPhoto, Aperturehashtag
: Twitter, Google+category
: Anobii, WordPress考慮到中文翻譯的話,又更加混亂:
針對以上的清單進行耙梳,我們可以得到下面幾個觀察:
這些類似的功能中,最常見的英文名字是 “tag”,中文名字是「標籤/标签」。
然而在 Google 的產品中,”tag” 通常翻作「標記」;「標籤」這詞則是用在 “label” 上(儘管他們兩者功能接近)。
hashtag 有其自有的形式:#somewordswithoutspace
, 不過其使用的方式與目的和單純的標籤(tag)並無太大差別。
有些應用服務存在著 category 與 tag 兩種機制,一個物件(例如部落格文章)可能只隸屬於單一分類(category)但可擁有多個標籤(tag)。但是現在越來越多的應用服務都可以讓使用者將單一物件同時歸屬於多個分類之下,使得分類與標籤的界線漸趨模糊。
可以從另外一個角度來釐清分類與標籤的不同:分類屬於事先規劃好的清單,標籤則是依照物件內容隨意添加的清單。
不過在只有「分類」沒有「標籤」機制的網站中(如 Anobii),「分類」的使用方式其實跟「標籤」是沒有兩樣的。
反之,只有標籤機制的網站,如 Blogger, 某種程度上也可以透過標籤來模擬分類的機制(可以參考此網站的右側選單)。
蠻混亂的,不是嗎?為了方便起見,我這邊用「分類 (category)」、「標籤 (tag)」與「Hashtag」來稱呼上面一大堆名字所代表的功能,其中「標籤 (tag)」同時也代表了 label 與 keyword。
分類、標籤與 Hashtag 三者的功能接近又互相重疊,命名也是各家網站各自為政,沒有個準。不過混亂還沒結束,讓我們針對「標籤」的部份,繼續深入研究下去。
標籤的格式牽扯的問題既廣且深,它不僅決定了使用者在輸入欄位中填入標籤的方法,也涉及到了資料儲存在資料庫中的方式。標籤的格式有以下幾個考量層面:
間隔方式
常見的間隔方式分兩種:空白與逗號。Flickr 採用空白間隔,Blogger 與 YouTube 則是逗號間隔。這邊還看不出什麼大問題,請接著看下去。
允許空白與否
基本上,大多數的標籤功能都允許標籤內含空白,我們免不了會遇到例如 "White House"
或 "Windows Vista"
這樣的標籤。這時候不同的間隔方式就會帶來不同的考量了。
以空白間隔的標籤,為了要允許空白字元作為標籤的一部分,所以必須引入引號,被引號包住的詞算做一個標籤,這是 Flickr 的作法。所以一張有「white
house
」標籤的照片,也許是張白色的房子;而一張有「"white house"
」標籤的照片,則可能是美國白宮。不過這樣會使得引號無法作為標籤的一部分,比方說「5'7"
」(五呎七吋)這樣的詞就不能拿來當標籤了。
以逗號間隔的標籤,在含有空白間隔的標籤問題上看起來比較單純。但實作上其實有一點要注意,就是真正的間隔符號並非單單只有逗號,而是逗號加上一個空白。因為人們在輸入時習慣在逗號後面加入空白,如果說空白是合法標籤字元的話,那麼為什麼只有單字間的空白才被記入,單字前後的空白都被忽略呢?
大小寫
這邊再以 Flickr 與 YouTube 為例子作比較。YouTube 對於標籤的大小寫是照單全收,所以 "TREE"
標籤點下去的搜尋就是 “TREE”,而反之全小寫標籤的搜尋文字就是小寫的,反正搜尋結果無視大小寫,所以不成問題。
Flickr 的作法稍微複雜些,除了你所輸入的之外,Flickr 還會另外將標籤簡化,然後儲存。你可以在三張照片分別使用 "TREE"
與 "Tree"
與 "tree"
這三種大小不同的標籤名,顯示時也是顯示各自不同的大小寫,然而他們都是代表著同樣的一個標籤。所以,如果你在一張照片中使用了 "TREE"
的標籤後,接著再輸入 "tree"
標籤,會發現沒有任何反應,因為標籤重複了。
內部處理
Flickr 在輸入標籤時所做的處理,除了大小寫外,也套用在空白上。因此,"White House"
, "whitehouse"
, "WhiteHouse"
這三個標籤同樣都是指向 "whitehouse"
這個內部處理的標籤。Flickr 內部運作時的標籤,是會把空白去掉並且全部轉為小寫字母。
Youtube 就不同了,如前所述,你輸入什麼標籤它就存什麼,所以 "White House"
跟 "whitehouse"
是不同的。事實上,你用這兩組字串去 YouTube 搜尋,也會得到不一樣的結果。
延伸閱讀:Tag formats: Can’t we all just get along? - Signal vs. Noise (by 37signals)
2005 年的文章。估計是 37signals 要實作標籤系統時,研究了當時幾個主流網站的標籤機制,對象包括 del.icio.us, 43things, Yahoo’s My Web, flickr 與 Amazon。這篇文章底下也有頗多值得一看的討論。文章的最後提到:
當新科技剛出現時,不一致是免不了的。然而這些不同的格式是否會持續下去,或是終將會有個標準一統天下呢?
2005 到現在,都六、七年了,標籤功能其實仍舊處於混沌未明的時代。
]]>簡單來說,這部戲的結構並不複雜:住在鎌倉的長倉家有四個兄弟姊妹,隔壁新搬來了一個東京來的單身職場女強人--吉野千明,這給原本平靜的長倉家帶來了許多生活上的變化。
於是乎劇情多半都圍繞在這兩戶人的互動上,偶爾加入些千明在電視台,或是大哥長倉和平在市公所裡的職場工作。一個是電視人,一個是公務員,從男女主角兩人的工作上,其實就反映出兩個人截然不同的個性。在電視台工作的千明,一直在接受新的觀念與新的事物,工作過程中也經常會出現意外的變卦,需要臨時調整作法。而身為公務員的和平,就是很標準的一板一眼,對許多事情的態度,說難聽點是固執,說好聽點是擇善固執。
不過就是因為有這樣的對比,故事的發展才有衝突,才有精采的過程。整齣戲的節奏還挺快的,不會拖泥帶水--除了最終話千明與和平兩個人一邊喝著調酒一邊聊天這段,這一段我看到差點睡著,感覺就像是最終話時數不夠只好多講些話充場面似的。話說回來,雖然劇情進行的節奏快,不過角色鮮明,對話也多半生動有趣,所以看起來還蠻輕鬆的。
《最後から二番目の恋》大概是我看過的日劇裡,主要演員的平均年齡最高的一部。千明與長倉家的兄弟姊妹多是四、五十歲的人了,最小的雙胞胎姊弟也是三十五歲。說起來,大哥與最小的妹妹相差有 15 歲之多,也算是蠻大的年齡差距。
主要演員裡的中井貴一與小泉今日子都是演技派,看他們倆鬥嘴實在很過癮。兩個人經常講話講著講著就拌起嘴來了,看起來像是感情不好,但某種程度上也算是一種默契吧,感情不好的人,想鬥嘴也鬥不起來。除了男女主角外,還有些演員我想提一下,第一個就是內田有紀。內田的戲我看過的只有《一個屋簷下》,好多年前的事了。雖然因為那齣戲記住了這個演員,可是當時卻覺得她演得很差,有內田出現的戲我都希望能快點結束。
然而這次內田演出的万理子卻非常的特別:頂著一頭看不見眼睛的鳥巢亂髮,講話很快又讓人摸不著頭緒,加上一付陰沈的模樣,又不時盯著自己的手機--乍看只會讓人覺得這傢伙是個怪胎,但相處久了卻讓人發現這個小妹還挺可愛的,活脫像是從漫畫中跳出的人物。在看不到眼神,只能用半張臉表情演戲的嚴苛限制下,內田完全演活了万理子這角色。
其次就是大橋母女。這對母女長得還真像,讓我一度還誤以為是找真正的母女來演出。剛看前面幾集時,我還以為女兒大橋知美只是個偶爾露臉的小配角,沒想到之後的戲份還不輕!知美的聲音很可愛,在戲裡面有提到被說很像「動畫聲優」,但知美本人很不喜歡這聲音。相反的,媽媽大橋秀子的聲音就跟女兒完全不同,相當低沈,讓我聯想到石原里美,話說媽媽和石原也有幾分神似,搞不好現在的大橋媽媽就是二三十年後石原的模樣。
再來就是替電視台寫腳本的栗山はるか老師,本來當她只是個靠美貌的美女作家,沒想到還挺有本事的,同時替兩個電視台寫腳本,而且還要兼顧家庭,早上幫小孩作便當,完全就是一副人生勝利組的模樣。和單身超熟女千明根本就是兩個不同世界的人。
《最後から二番目の恋》的主題曲是由浜崎あゆみ所唱的 〈how beautiful you are〉,雖然我偶爾也會聽步姊的歌,但她這首我真的很難接受,覺得她的歌聲變得很難聽。反倒是配樂常出現的幾首英文歌我都蠻喜歡的,尤其是 Yael Naim 所演唱的〈Far Far〉讓人最為印象深刻。
啊!最後還有件事差點忘了提,那就是千明的熟女摯友中,飾演啟子一角的是森口博子。說到森口博子,也許一般人比較少聽到這名字,不過對於動畫迷而言,森口博子所演唱過的〈水の星へ愛をこめて〉(機動戰士Z鋼彈)、〈ETERNAL WIND〜ほほえみは光る風の中〜〉(機動戰士鋼彈F91),可都是動畫歌曲裡經典中的經典呢。
]]>不過對於文章內容的解讀也不一樣,這讓我不由得想寫一篇文章來談談 “I don’t hire unlucky…” 這篇的內容。這篇文章很長,以對話小說式的方式來描述,講述如何節省 hire people 的時間與 hiring 時的考量,我懶得逐字翻譯,所以會簡單帶過故事內容。
故事可以分成上下兩部分。第一個部分有兩個主角,Bertram 和 Ernestine,Bertram 負責招募零售商店的學徒,Ernestine 的工作則是在招募軟體開發的 programmer。Ernestine 有天問 Bertram,她手上有上百份履歷,要怎麼減少不必要的電話與面試呢?
Bertram 說很簡單,他拿起一整疊履歷,丟掉一半,然後回答,「不要雇用運氣不好的人就好啦。」Ernestine 聽了之後想要試試看,於是回去問 Mark 意見,Mark 是她公司的 CFO 以及天使投資人,對於軟體產業也有些瞭解。Mark 點出了 Ernestine 與 Bertram 環境的不同。
Bert 那邊有相當多符合條件的人 (qualified people) 在應徵他的工作,假設 100 個裡面有 50 個好了,就算他刪去一半的人,平均來講,剩下的 50 個裡也還有 25 個符合條件的人可以挑選。而妳在招募的 programmer, 可能一百份履歷裡面只有一兩個符合資格的,妳如果一口氣刷掉一半的履歷,妳可能在剩下的那 50 份裡完全找不到半個合適的人。
於是 Ernestine 放棄了 Bertram 告訴她的方法。開始不斷嘗試、調整,試著去找出自己的方法。
故事來到兩年後。Oscar 是 Ernestine 公司裡的程式主管,他也有面對一堆履歷不知從何著手的問題,於是像她的上司 Ernestine 請教。
Ernestine 告訴 Oscar,首先,她不再去注意一份履歷是否「專業」,比方說履歷的格式或是文字中是否有錯字等等。因為去在意這些東西,其實跟隨機丟掉一半運氣不好的履歷,是沒什麼兩樣的。
於是 Oscar 提出質疑,Oscar 的質疑也是我們一般會有的想法:「可是從履歷的完整度,我們可以看出求職者的用心,知道對方是不是有熱誠想要進我們的公司不是嗎?」
Ernestine 的回答點出了重點。如果我們今天有 50 個不錯的人才,那我很樂意找出到底哪一半的人有進公司的熱誠,哪一半沒有。但如果我們今天的履歷裡有 99 個庸才跟一個天才,那我的首要目標是要想辦法找出這一個天才是誰,至於誰比較有進公司的熱誠則是次要的了。
Ernestine 繼續說下去,她用同樣的想法貫穿整個人才的挑選:她挑或不挑一個人,是決定於與工作技能本身相關的直接或間接衡量 (direct measurement or indirect measurement),例如學歷算是間接衡量指標。
講到這邊,Oscar 又打斷,並且說明了學歷的重要,學歷反應許多資訊,不應該只是間接衡量。Ernestine 大致上同意 Oscar 的看法:
幾乎每一個我們所雇用的都有大學學歷,但我在看履歷時不會依照他們的學位或學校排出優劣。我只是看他們的工作經驗或是提供的代碼範例。而結果就是,我們所想要的每個有經驗的人才都具有大學學歷。
但是她接下來的回答很有意思,值得令人多加思考:
然而把「關連性 (correlation)」與「因果關係 (causation)」兩件事搞混是非常危險的。而更糟糕的則是把「關連性」跟「必要性 (necessity)」搞混。如果說,有念過大學對 programmer 來說是一件好事,那麼我們在看他的經歷、程式代碼,或是與之面談時,也可以發現他的能力優秀。
所以我的理解是,念過大學可以幫助一個程式設計師成長,但這些成長會表現在他的工作經歷或是代碼上。所以經歷或是代碼是直接的衡量標準。大學教育與優秀的程式設計師有關連性,但不是必然的因果,更不是必要的條件。
Ernestine 繼續說到,當她在看求職者的 blog 時也用同樣的標準去檢視。比如說有個求職者喜歡攀岩,聽起來不錯,公司裡也有許多同事喜歡攀岩,不過 Ernestine 會忽略掉興趣這項訊息。
畢竟,如果因為興趣不對就被刷掉,是非常不走運 (unlucky) 的。而我不想僅僅只是因為一份履歷不走運就把它刷掉。
這裡有句重點:
hiring programmers, not ascetics or rock stars
Ernestine 甚至會抗拒去查看求職者在社交媒體上分享的資訊。她不想因為求職者在政治、興趣等觀點上與她志趣相投或是理念不同,而產生偏見,進而影響求職者被錄用與不錄用(這在美國也是違法的),同時這對公司也不是件好事。她雇用時,單純只考量求職者在專業技能上是否滿足條件。從招聘的觀點來看,去考慮對方是否跟你合不合得來,其實就只是種運氣的問題,而非適任不適任的問題。
Ernestine 最後提到招募廣告,她現在開始使用平舖直敘的文字廣告來招募。她之前也曾使用過「徵求忍者!搖滾巨星!」之類的誇張廣告。但她發現這類的廣告也許會吸引到喝 Dry Martini 的人(意指比較外向積極),但是那些不喝 Dry Martini 不見得就不適合這份工作。所以登「我們需要忍者!需要超級巨星!」這類廣告,跟單單只是因為不喜歡沒運氣的人而刷掉一半,其實沒什麼兩樣。
接下來的問答很有趣,programmer 應該都會有更深的體會。Oscar 問到:「要是如果忍者廣告比起直白廣告真的能吸引到更多符合條件 (qualified) 的人前來應徵呢?」
Ernestine 的回答相當妙了:「當你寫程式時,你怎麼知道哪一段 code 需要最佳化呢?」Oscar 回答:「我會去測量(measure), Premature optimization is the—Oh, I get it!」這邊 Oscar 的話雖然講到一半,但是這句話相信 programmer 都應該熟悉:
Premature optimization is the root of all evil.
過早優化是萬惡之源。
– Donald Knuth
所以 Ernestine 會有這樣的結論也是測量過後的結果。她說,登廣告找人,跟登廣告賣東西都是一樣的,你必須追蹤測量所有數據 (track & measure everything),你才能分析,知道有沒有效果。
所以,Ernestine 減少處理上百份履歷時間的方式,並不是用什麼隨機丟掉一半,把運氣不好的人排除掉。也不是什麼像下面這段所說的尋找一個點,一個感動、注意、雙眼為之一亮的點。不是尋找什麼鳳毛麟角。
作者建議,當100選1的時候,應該直接隨便看一張履歷表,看看此人是否有哪個「點」讓你感動、讓你注意、讓你雙眼為之一亮?不是想辦法刪去,而是「尋找」那個鳳毛麟角之特色。
Ernestine 的方法很簡單。今天如果我要找程式設計師,我就只專注在相關的技能、經驗或作品上。而不是看著履歷表上洋洋灑灑一大堆與適任與否無關的資訊或情報。
看完了這個故事,是不是覺得英文閱讀能力很重要呢?多培養自己的英文閱讀,直接吸收第一手資訊,才能夠間接提高自己的好運度喔!
]]>什麼叫做「不和運氣差的人合作」?
這位作者舉了一個例子,如果你是某間店的店主,現在要找店員,現在收到了 100 份履歷,但你很忙,沒有時間一個一個看。最簡單的方式就是索性從 100 份中隨機挑出 10 份,然後從 10 份中挑出一個最棒的。至於那些被過濾掉的 90 份,只能怪他們運氣不好啦!
聽起來很帥氣,不是嗎?
這過濾的方法真是簡單、漂亮又優雅--但我深深覺得還有哪裡不夠。
「你怎麼確定被挑出的代表運氣好?萬一,我是說萬一,你的店下個月突然發生意外,週轉不靈發不出薪水,那麼被挑出的反而都是倒楣的人,真正運氣好的人早在你挑的時候成為漏網之魚,從你手中逃掉啦!」
是的,華生,你突破盲點了。
我相信,運氣好的人是會互相吸引的。所以在我使用這個「隨機運氣過濾法」之前,我得要先確定一下自己的運氣到底是好是壞:如果我運氣好,那麼被我挑到的人他們也都是具有好運的;如果我生來就是不走運,那麼沒被我挑到的人才是真正運氣好的人。只要我能夠知道自己的運氣是好或壞,我就能夠知道到底我要從被我挑出的那 10 份裡面去挑人,還是從被我放棄的那 90 份裡面去挑人。
那麼要怎麼確定自己的運氣是好或壞呢?我想到兩個方法。第一方法呢,就是如法炮製,我把我的履歷寄到另外一間採用同樣「隨機運氣過濾法」的公司,如果有被挑上,那我就是運氣好;如果沒被挑上,那我就是壞運氣--等等,不對,我怎麼知道另外一間公司負責挑選員工的雇主也是好運氣呢?如果我被挑上,但是另外一間公司的雇主是壞運氣的,那不就表示我被挑上但其實是壞運氣的?這豈不成了無窮迴圈?
好吧,看來第一個方法行不通,換下一個。第二個方案就比較簡單了:去買樂透。中了就中了,沒中就沒中,一翻兩瞪眼,多乾脆。不過要是我今天運氣好,中了樂透,我索性就把店收了,退休度假去,何必還在那邊辛辛苦苦地煩惱到底要雇用什麼樣的員工呢?
每個人都想要和「運氣好」的人一起合作,但問題就出在於什麼叫做「運氣好」?成為「在 100 份履歷中被挑出的 10 份中的其中之一」就算運氣好嗎?我不以為然。即便是中了樂透,也未必是就真的是運氣好的人--對於許多心理尚未做好準備的人,中了樂透往往是人生悲劇的開始:中了樂透之後到達人生最高潮,然後朋友反目、妻離子散、揮霍度日、散盡家產這樣的故事俯拾皆是,我也懶得舉例了。所謂「塞翁失馬,焉知非福?」一件事情究竟是好是壞,其實是沒辦法從當下發生的事情本身來判斷的。
所以到底什麼算是「運氣好」的人呢?我覺得只要「有做好準備」的人,就很容易遇到好運氣。運氣這東西,不外乎就是種機率。即使單一事件成功的機率極低,然而當你準備的越多,準備的越周全,這個極低機率發生成功的可能性就越大,成功的可能性比其他人來得大,自然就可以看做是「運氣好」的人了。
讓我們這樣來看:假設開發一百款遊戲中只有一款會成功,也就是說,成功的機率是百分之一,失敗的機率是 0.99。那麼,作了 52 款遊戲的公司,至少有一款成功的機率是多少?換個角度想或許會比較簡單,52 款遊戲全部都失敗的機率是多少?
答案是,52 款遊戲都失敗的機率是 59%,所以相反的,有逾四成的機率這家公司能夠有一款以上的成功遊戲。四成跟百分之一,很大的差距不是?而只要能有一款成功的遊戲,這家公司就能夠開始踏上好運的高速公路,吸引到更多「運氣好」的員工一起加入,進入正向循環。
所以,運氣人人都有,但你準備的越多越充分,你就能夠比其他人來得更強運。
關於給六先生帶來許多想法的這篇 I don’t hire unlucky people - raganwald’s posterous,我運氣很好,剛好也看了。有一些不太一樣的解讀。可惜這裡空白的地方太小,寫不下,只好另外寫一篇來討論了。
]]>那麼,要如何輸入這些特殊符號呢?在 Mac 中很簡單,只要開啟「特殊字元」的輸入視窗。絕大多數 Mac 下的應用程式都可以在選單列的「編輯」或「Edit」最下方找到「特殊字元…」或「Special Characters…」;通常也可以透過快捷鍵「⌥⌘T」來開啟特殊字元視窗。
上面就是特殊字元的輸入視窗。到這邊已經可以輸入各種奇奇怪怪的符號了,不過如果想要輸入像「㍿」或「㊙」這類的特殊字則還不夠,得要進「自定列表」加入新的類別。點左上角的齒輪便可開啟自定列表,然後選取以下類別:
這樣子就可以輸入上文中提到的文字符號囉!
]]>上面影片中的許多元素,相信都是目前三、四十歲這一代的共同回憶。像是吹卡匣或是撥接時的噪音等等。而影片中那 8-bit 風格的美術與音效,更是所有勇者迷再熟悉也不過的場景了。看完影片後我立刻連上 Google Maps,在 8-bit 的世界中玩了好久,到處探索,就好像自己真的是個勇者一樣四處探險。
這是離我們最近,也是我們最熟悉的建築物--天空之塔。
我所在的位置。透過 8-bit 地圖看來,突然覺得有河流經過是個不錯的地方。
蕃薯島 XD
SEGA MD 大戰略一代中的「遠東(Far East)」地圖就是長這樣。
北邊大陸上除了有冰原,還有會扣 HP 的毒沼。
世界地、不,是勇者鬥惡龍三代的地圖。(對照版)
日邦格的富士山。日邦格這地方的樹木也跟別處不同,是楓紅色的。
Goolge 總部,感覺怪物很多……
剛剛發現,Google Analytics 的「造訪」按鈕旁多了個音符記號。點下去後會出現 Piano 與 Sitar 兩種樂器可以選,選了之後就會看到下方折線圖的節點會按順序一個一個亮起來,並播放與節點高低對應的音階。
可惜我的折線圖不夠精采,撥出來的音樂平平淡淡,沒有直墜谷底或是步步高昇的激昂起伏。
]]>以下按照時間順序排列:
migrate-to-octopress
from-blogofile-to-octopress
hello
ban-jia-hou-di-1pian
move-to-octopress
huan-dao-octopress
hello-octology
move-to-octopress
hello-world
hello-octopress
migrate-to-octopress
blogging-with-octopress
可以看出,幾乎每篇的標題都有 Octopress 這字出現,唯一沒有的一篇是用了 Octology 這個字。而 title 的部份,也不脫 hello / move / migrate 等單字。有趣的是,其中有兩篇是用拼音來寫 title,對於懶得想英文標題句的人,倒也不失為一個簡單省腦的方法。
]]>