拖同事 LuLu 的福，今晚跑去大腕影像參加一個「電影【海角七號】導演與視覺特效的對談」，據說是要預約報名的，只有五十個名額。而且，被「記者會或座談會」嚇到了的魏導，熱情站台。到了會場，才發覺數位內容學院的人好多呀…然後也發現，原來還來了資策會副執行長許清琦!!! 我記得他在台大資工時，我還修過他的「必修課」…
去到別家動畫公司，感覺很開心，大腕算是我的第一家，因此格外地注意他們的人與四週環境。人一樣很和氣，年齡層一樣很年輕，地方小小的，所以大概是二三十人的團隊，然後攝影的小姐很漂亮（不過這不是重點）。
座談會中，有一段他們特別準備的「實拍、CG 模型、特效、光陰…到合成」的影片，感覺做得不錯。（聽說花了兩個禮拜準備）第二次看這些片段，看得比較仔細，發覺到有一些明顯的瑕疵，像是海面的反射與亮點好像可以再加強一些；船的「老舊」感，還是有太多的塑膠感，如果可以把 specular 再加把勁兒，然後再利用 reflection 來營造成海水沾在船身上的溼潤感，就又更優了。不過就像魏導和大腕負責人說的：「時間太趕」
座談會什麼時候結束我不確定，我只知道我在九點多時就溜走了。沒有聽到很多我想聽的，像是製作期多久，總共做了幾卡，rendering 資源用了多少，以及最最重要的，在預算有限下，他們怎麼處理與下決策的。不過也沒辦法，這部片子雖然有一陣子了，但實在是「台灣之光」，太多人想問問題了，這也是沒辦法的，呵。
回來後我在想，這算是一個不太成功的座談會。從大腕的角度來看，這個座談會的眾多目的之一，應該是讓更多人認識與了解大腕，進而提昇大腕的形象。必竟這是難得的一個機會，要等多久才會有一部非常賣座又很有話題的國片呢? 可惜焦點還是集中在魏導身上，實在很可惜吶~~
聽說大腕負責人只比我多兩歲，真是一位可敬的人，大家一起加油吧。好好經營每個 animation studio，讓更多人有好的工作環境，讓大家吃得飽做得開心，然後再做出更多讓人看了會開心的片子吧。
買這台 MacBook Pro 已經是去年四月的事了，算一算已經一年半了，最愛的，莫過於是帶它出門時，可以有意無意地炫耀一下，這滿足了我的小小虛容心。
最近好不容易把 Mac OS X 升級到 10.5，迫不及待地設定了一下 Google Calendar 與 iCal 的同步，一試就成功了 :D:D
Bruno 最近寫了一篇關於他在 SIGGRAPH 2008，自 Pixar 那排隊拿到的 Walking Teapot 的文章，建議去瞧瞧。
重點是，他拍得照片挺漂亮的 :)
PS. 今年我好像沒有拿到 Pixar 會場發的 walking teapot，雖然有那麼點兒小遺憾，不過這種東西，有就是運氣好，沒有其實也不會怎麼樣，就只好期待下次囉~~
PS. 上圖是竊取自 Bruno 的拍攝，版權所有皆屬 Bruno 所有，請不要亂用 XD
一直以來，我都很想把 LinkedIn 這個網路服務推薦給身邊的人，不過又不曉得怎麼做，有那麼點兒意興闌珊…
LinkedIn 是個 Web2.0 時代下的社群網站，但它一點兒都不好玩，充其量只是一個網路版的名片夾。每個人的帳戶裏頭，是簡短的工作經歷等，它以一種「履歷表單」似的方式呈現。然後每個人還有所謂的 connections/contacts，但這裏的關係比較不接近一般的「朋友/認識的人/同儕/同學…」，而是比較接近「工作夥伴/同事/合夥人」。
簡言之，這是個強調「工作上功能」的社群網站。
舉凡你想要換工作（可以透過人介紹到你想要去的地方）、成立公司（找感興趣的創頭）、挖角（看看同業的人才）、徵人（你管轄的部門面臨了一個大案子，非常缺人中）…
我為什麼覺得 LinkedIn 很有趣呢?
首先，我是在繞了一大圈，有天想說，就來去申請個小有名氣的 LinkedIn 帳號，看看裏頭賣的是什麼藥。然後赫然發現，我們當時的導演、製作人、CG Supervisor 都在上頭有帳號，而且他們的 connections 落落長。接著又發現，有不少位有名的國外教授也有（CG rendering 界的教授 Peter Shirley；去年（2007）剛得到 SIGGRAPH 新秀獎的 Takeo Igarashi 也有!!），然後連我們的超級資訊宅男 Dan Maas 也有，還有……
於是我很開心地開始用了起來。
最近因為 LinkedIn 上的這個帳號，接獲來自 NVidia Taiwan 與獵人頭公司的來電，雖然沒有聊什麼，不過也是種有趣的經驗。
我也不曉得，下一次會接到怎麼樣的來信或來電，不過總之會是以另一種「意外」的型式出現的吧~~
我的 LinkedIn :)
在整理公司的信箱時，無意間發現 2005 年寫的一篇文章，覺得挺有趣的，放上來。
程式設計師和翻譯人員，在很多方面來看，是等價的。
這樣的一個想法，在一個夜晚，台大旁的溫州街巷子裏的 Bongos ，忽地閃過腦海，像個幽魂似的。看似不見了，卻隨著時間逐漸發酵，進而影響到上班時面對工作的態度…
上班後，一般人喜歡叫我們工程師、程式設計師，或是研發人員，當然這得看他對我們的工作了解多少，比較酷一點的，會說我們是 problem solver、pioneer 或是 originator。不論怎麼被稱呼，工作中總有不少時間是花在 programming 這檔子事上（雖然，事實證明，隨著個人的發展不同，每個人都會走上開會時數慢慢唐塞掉你一週工作時數的這個過程…）。
我們的工作就是：把一個問題聽清楚後，在腦子裏或紙上，以你的 natural language (not native language all the time) 說出你的答案，接著坐到電腦前，將那個答案翻譯成另一個語言。這個語言可能是 C/C++, Java, Scripts, HTML, …。過程中反覆地檢查是否有哪文法不對（compiling bug）、語意不通順（logical bug），或是贅字過多的地方（running performance）。一邊修改（debug），一邊請別人來看看整篇翻譯文章是否讓人看得懂（end user testing）。
寫程式的過程，約莫就是這樣了。
對於翻譯這件事的掌握程度不一（programming skill）、個性上耐不耐得住一人工作的寂寞（thinking, coding and googling alone）、受不受得了要隨時學新單字與翻字典（new spec, new API and different frameworks）…等，造就出了不同性向與不同壽命的程式設計師來。「性向」指的是與其它翻譯人員之間合作的方式；「壽命」指的是能持續寫程式多少年。
印度的 programmer 舉世聞名。看了不少篇 paper ，裏頭持續提到教條式的程式寫作訓練與吃苦耐勞的合群個性。於是乎他們成了世界知名的翻譯家，從程式語言翻譯做起，進而到矽谷翻譯起了「創新行為」與「商業行為」等語言…
翻譯又有分很多不同情況。
強調速戰速決，翻過就不留痕跡的，就像國際會議裏的即時口譯人員。工作大多是實作出 prototype、解決臨時性問題，或是寫些小工具方便自己日後的工作。
要求字字正確，句句語意上都對的，就像國中與高中的英文教師。按步就班寫出有條有理的程式碼或 framework、註解完整還附上整個系統的演算法脈絡，為的是供日後跟隨或接手的人容易進入狀況。
寫程式如此，對事情的態度亦如此。有些人擅長緊急的事，不管再怎麼雜，再怎麼繁瑣，都能一個接著一個應付；有些人適合每個步驟都嚴謹，處理的過程中，已經在構思整件事要如何更有彈性，遇到什麼狀況時也先想好對策。（緊急的事先處理？還是重要的事先處理？雖然答案很明顯，但實際面對起來，並不是那麼容易就能分辨出來，更別提能自主決定以對的方式來處理了）
雖然現實是雜亂無章，意外一個接一個來的，是以沒有辦法以一種態度來面對所有的問題。而這也剛好說明了為什麼國中時會紅起來，且至今還常常被提及的 EQ 哲學。只因為你得隨時調整心態，以不同的態度與風格去面對那「工作上的事」。
因為了解到自己的身份，不過就是這麼一位得時時調整的翻譯人員，很多事情處理 起來變得順利多了，即便是在一些負面消息接踵轟炸過來的時節。
但我依然秉持著，有個遠方的目標在前頭等著，有些事得事先準備。不能就這樣讓日子一天一天的，在一個又一個工作任務中度過。
Programmer is an Interpreter。以這為出發點，仔細思考，是的確可以寫出一份程式設計師的上班求生指南的，不過天色已晚，還是早點睡吧～
今天的金馬影展，胡亂選了四部來看，其中三部是在日新的大廳 ^>^
今天聽莊永裕教授的 Digital Image Synthesis 課時，聽到一個 Cancellation Error 的東西，是個與 IEEE floating point 有關的「數值計算問題」。
投影片上如是說：
Cancellation error: devastating loss of precision when small numbers are computed from large numbers by addition or subtraction.
寫了個簡單的 c 程式親身試驗一下。
void main(){ double x1 = 10.000000000000004; double x2 = 10.000000000000000; double y1 = 10.00000000000004; double y2 = 10.00000000000000; double z = (y1-y2)/(x1-x2); printf("%f\n", z); } // output: // # 11.500000 接著我在想，Python 會不會有這個問題呢? 結果試了一下…一樣!! 看來 CPython 的 number 這個 type 真的是用 double 實作的 :o
應 Cellopoint 的邀請，給了一場 Introduction to Drupal 的 talk，時間約莫一個多小時，4+1 位聽眾，一頁投影片也沒有，就一台可以上網的筆記型電腦與一個白板。我只在前一晚想了一下要提的綱要與流程，就這樣，非常地簡易。
我是這麼想的：
透過 Drupal Taiwan 的 繁體中文網站秀 讓大家先了解一下，使用 Drupal 的台灣網站有哪一些。特別秀了苦勞網、行無礙與 PlayStation 臺灣網站這幾個不同性質的網站。 Drupal 的檔案架構，特別強調了 modules, themes 與 sites/all 這三個目錄。說明了一下，藉由把自己安裝與撰寫的模組、版型等資料放進 sites/all 裏頭，在完全不更動到 Drupal 核心的情況下，可以做到日後的「幾乎無痛升級」。 暗示一個網站的建置，流程上以先後順序分為：1) 先決定出網站的內容類型，2) 之後再去思考這些內容的呈現方式。 接著指出 Drupal 一安裝好，最最重要的幾個模組，分別是：node, taxonomy, user 與 menu，然後一一做功能上的介紹。像是幾個例子：如果你要架個 web bbs，可能會希望網站上的使用者有「未註冊」「已註冊」「板主」「小組長」「副站長」「站長」，然後有不同的權限。這時你可以透過 user 的 roles 來做到。 「好好」介紹 taxonomy 這個模組。它可以用來做 category, tags, filter, …，幾乎任何帶有「分門別類」的功能，都可以透過這一個（也幾乎只要一個）模組搞定。 接著，我們來想想「網站呈現」這麼一回事。 CCK 登場。因為 CCK，所以我們可以非常容易地實現了「客製化的內容類型」。來幾個例子吧。 Views 登場。因為 Views，我們可以以自己的喜好，任意地「撈」出想要的內容。 CCK 幫忙處理了 database 的 schema；Views 處理掉了 SQL expression。簡言之，你透過後台的「點來點去」，省去了思考這兩點的所有細節。 最後，我們來稍為聊聊 themes，看看 themable functions 是如何的優秀。 talk 結束，回家的路上，我一直在想一個問題，「究竟這樣的 talk 會有多大的效應呢?
