首先，成績及格了，審定書拿到了，所以確定今年能夠畢業。
另外，老師們真是好人，對每一個同學都是砲火猛烈，結果最後給大家的分數都還是頂高的說。
心得，首先投影片我很不要命的用了高橋流下去做，只有一位問我為什麼把標題和內容分開，說他覺得這樣不好，但比例比其實比我預期的來得低了。
不過這種東西我覺得還是和個人認同的簡報哲和藝術學有關吧！所以那時我心中的ＯＳ其實是：唉，你有看過簡報之神 Steve Jobs 的投影片上面有標題的嗎？
說實在，當場我很懶得回答，因為這根本就是哲學和藝術的問題，簡報和投影片的關係到底是什麼？我今天來，是來推銷我的論文的，不是來唸我的 handout 的，如果你不想聽我報告，那我還上台幹嗎？直接把整理過後的 handout 丟給你不就好了？
至於為什麼會把標題和內容分開？因為很簡單，那是一個段落。整份投影片是有段落的，不是從頭到尾都沒有主題變化的。懂嗎？就和書一樣，有分第幾章的，你沒注意到書的章節名稱比內文醒目嗎？因為那是一種分隔的提示。你傳統的投影片把標題全部放在同一個位置，能做到這樣的提示效過嗎？
我是來推銷論文的，但投影片不是我的論文，是我的重音提示，想要看正式的東西，去看論文不就好了？裡面就是按照學術論文的格式寫的。
另外，我覺得 defense 的時候，最困難的還是怎麼表達自己的目標到底是什麼，我和老師們爭了很久，結束後才發現一件事－－從頭到尾我們兩個的終極目標根本就是不同的。
於是對話完全沒有交集，我認為他提的東西對我而言不實際又只會增加使用系統時的複雜度，但他也認為我的東西太簡化，沒辦法解他的問題，於是兩個人就一直鬼打牆。
雖然在這過程，我有一直強調我們的目標，但或許他根本不認為我的目標是對的，但相同的，我也不認為他的目標是對的，於是其實從目標就開始兩人就分道揚鑣了。
因為對我而言，一個功能完整但是複雜的系統是一個無用的系統，因為沒普通人會去用。但對他而言，有一些實務的問題需要解決，而要解決這些問題，就必需要有一個複雜而完整的系統。於是，從一開始我們兩個想要解決的問題就是天差地遠了。
但是，我們的研究題目是『以 Ontology 為基礎之內容管理系統』啊！內容管理系統就不是給那些不會做網頁的人用的，是個通用性比較高的系統啊，是給一般環境和一般人用的系統啊！
真的要解特殊環境和問題，自己實作一個系統比較快吧？怎麼會去期待一個以通用性和易用性為目標的平台呢？這兩個性質和在一起，就等於宣告了一件事啊：這是一個簡化，容易使用，但沒那麼完整的系統啊！
所以，我們的目標、使用對象族群、設計理念、想解決的問題，其實根本就完全沒有交集，卻在那邊繞了有十分鐘之久。orz...
所以記得，以後論文口試，發現口試委員和自己沒交集的時候，應該先看一下，彼此的目標和想解決的問題，是不是從根本上就要不同，如果是，其實就沒有什麼好談的了，再怎麼談也不可能會有交集的，直接點出這點搞不好比較省時。
另外，我發現，『網站應用程式、資料分享』這個概念，好像還不是那麼容易被接受。我被問到了一個問題，是為什麼不把計算的部份直接放到網站裡，而要另外跳出到 shell 跑。
那時我想到的理由是安全性（因為開放使用者在 Drupal 裡跑 PHP，可以幹很多壞事的），這固然是一個問題，但後來我才用想到，還有一個更基礎的問題。
應該這麼說，從設計的一開始，我就沒打算把這部份直接放在系統裡，因為這樣絕對會被限制住。
現在的網路應用好玩的地方，就在於可以跨網站，你可以在各個不同的網站實作出好玩的 Flickr 應用程式？為什麼？因為他開放了 API 和資料讓你隨便用。也因為他不限制你只在他的網站用他的資料，你甚至可以開發出套裝軟體，在上面操作你 Flickr 的圖片。
我覺得這才是好玩的地方，這是傳統網頁程式設計，限制資料和計算都只在自己網站上算的時候，無法做到的事。雖然我的未來研究方向有寫到 Web Service 這點，但忘了強調這樣交互應用可以做出好玩的東西，好像有點可惜。
大概是用 Flickr/GMail/RSS 這些東西已經太惜慣了，總覺得把資料和 API 開放根本就是現在做這種網站的 common sense 了。:p
回響