本來是不太想寫這種文章的, 一來總有種攀親帶故的感覺, 好像我多熟, 二來, 在現在目前還是熱門話題的時候, 好像是來護衛什麼的, 最近有幾篇挺受熱門的文章關於李教授:

陳鍾誠給李家同的一封公開信

陳鍾誠給李家同的第二封公開信

昨天是看到人家轉貼的這篇 “我看李家同的是與非”, 才想到要寫這篇的

看了陳教授的文章, 慷慨激昂, 是對是錯, 我不是學界的人, 並沒啥資格好評論, 不過我當年博士班念一半不念, 其中一個原因就是不想為了點數汲汲於論文(另一方面也是自覺自己不適合做研究), 不過到了業界後我了解到, 我也錯了, 台灣的業界也是以"分數"在評鑑一個人的, 而不是以他的能力跟貢獻(或許有人會認為分數是客觀的, 不過我認為, 既然是人為的系統, 一定都有作弊的可能), 不過, 我並不是想針對人家給予李教授的批判做啥評論, 只是想說說在我記憶裡的李教授

我初認識李教授是在靜宜大學, 我從成大被二一退學的一年後考上了靜宜大學, 而當時他是那兒的校長, 真正比較熟悉的時候是修他的演算法課, 一般如果出去自稱你是某某的"學生", 人家常常會把某某是你的"指導教授"這種關係連結在一起(就如同是第二封公開信中, 陳教授拿來計算李教授的學生數目的方式), 但對李教授來說, 他指導過的學生就是他的學生, 不管是指導過的博碩士班學生, 上過課的大學部學生, 甚至在育幼院教過的學生, 常常會聽他說他"某某學生如何如何", 這"學生"常未必是他擔任指導教授指導的學生, 其實比較常聽到的是他在育幼院教過的學生, 古人說一日為師終身為父, 如這樣說, 倒也沒錯啦…..我修過他一年課, 我碩士甄試的推薦函, 博士班的考試的推薦函也都出自他的手, 雖然說沒照著他的期望走, 從一開始選碩士指導教授就沒照著他推薦的, 不過他一直是我非常敬重(也敬畏 :P)的人, 畢業之後, 我們當時一群修他課的學生還是會再去找他吃飯, 甚至是幾年後, 他也沒忘了我們, 也都叫的出我們的名字

一想到他, 我腦袋裡浮現的是他幾句的口頭禪, “是不是呀?”, “你說對不對呀?”, “唉呦”, “那小子"或"你這小子”, 所以每次看到他演講的影片都覺很親切, 因為他就是這樣講話的人, 在我的印象中, 他是個心直口快的老孩子, 腦袋裡常常轉著很多不同的新想法, 雖然未必一定是對的, 但總是有新的, 有時候是一些簡單的想法, 有時候是文章故事的點子, 也常常等不及的就拿出來說, 以前大學時, 有老師曾說過, 李校長(其實到現在我都還是叫校長)常常晚上打電話找人討論, 不過在我印象中, 他不是個嚴肅的人, 倒真的比較像老孩子, 他的學生(大學裡的)看上去都很敬畏他, 但幾年前的聚餐後, 隨他到育幼院, 我發現小朋友都很高興看到他, 而且沒有那種"畏"的感覺

其實他就是像個小孩子一樣的老先生, 也是會對新奇的事物感興趣, 記得他當上暨大校長那年, 我們一群學生到暨大找他, 他迫不急待的跟我們炫耀他的校長室, 我還記得當時他說"你看, 在這當校長就像當神仙一樣" (因為辦公室窗簾一打開, 外面雲霧繚繞), 然後還請我們到當時還沒震垮的涵碧樓吃飯, 一個月後, 九二一大地震發生了, 後來他也就沒當校長了, 當時有些民意代表對他有很嚴厲的批評, 但我一點也不意外他會那樣做, 他是一個對學生很好的老師, 以學生安全為優先的確是他會做的事

我看李家同的是與非"裡面說他應該是個愛碎碎念的老人家, 我看到很不自覺的點了頭 :P , 習慣他講話, 他講話就是那樣子, 之前我博士班唸到一半不念了, 不太敢讓他知道, 我是覺得有點愧對他啦, 畢竟他幫我寫了推薦函, 但後來聚餐碰到他, 他也只是念了一下"聽說你博士班後來沒念了? 你這小子…”, 或, “你們這些傢伙怎愛找女教授” (我的指導教授是女的), 聽到這個我也不覺得他有輕蔑女教授的意思(雖說我指導教授也沒很欣賞他), 他講話就這個調

他的教育理念是比較重視基礎的, 我當時修他演算法時, 他有時偏要考我們英文, 考英文不是考啥科技論文寫作這種應用面, 而是很基礎的文法, 教我們東西也不是一股腦兒的把東西塞到我們腦袋, 我還記得我被抓上去講一堂NPO complete, 但東西我自己得先準備, 陳教授文章指李教授是讓學生出社會後喪失實作能力的始作俑者, 這一點其實我是有點不以為然, 李教授很多學生是在業界不是學界, 撇開這點不說, 基礎的學習(演算法, 電磁學等等)是真正實作的根底, 根底紮實內功雄厚才不會流於花拳繡腿, 台灣可能比較功利主義, 比較著重於你能做什麼, 而不是將可以做出什麼, 出了社會, 人家問你會啥? 像是在資訊業界(以軟體來說), 面試的時候, 很多人會常問的不外乎你會什麼語言(C, C++, Java, Perl …), 開發過的平台有哪些, 但對比於國外的公司, 像是Google, Facebook這種大公司, 這些反而就很次要, 問你一個演算法, 你可以用啥語言去實作, 其實他們一點也不在乎, 語言是工具, 你可以用一種語言達到一個目的, 自然也有辦法用另一個語言達到, 即使你之前沒碰過, 但基礎卻是可以讓你之後演變出很多不同變化的零件, 你擁有的零件越少, 能變化出的東西自然越少, 那擁有在多工具的技能也無濟於事, 記得以前有個老師問我們一件事, 電腦越來越快, 那你還需不需要學演算法? 反正再爛的方式都可以靠硬體暴力來加強, 答案是需要的, 因為有了更好的硬體, 搭配更好的演算法, 你才可以做更多的事, 而不是用更好的硬體, 做的事卻一點增加也沒有, 基礎不好, 就算會設計CPU, 做同樣的功能硬是要比人多一倍的線路, 多一倍的功耗, 那就算有實作能力也是無用的, 所以我一直覺得他這觀念是對的, 只是有時候他對大眾表達出來的, 好像是沒表達出那麼的好

關於這主題, Dianne Hackborn已經在這講的很詳細了, 這邊挑了一些要點

Duo panel的設計在iPad上已經是蠻常見的了, 這設計的一個特點是, 在Landscape模式時為了充分利用空間, 把Panel切割成兩部分, 但使用者轉換成Portrait時, 則會轉換成Single panel

不意外的, 在Android上實現Duo panel的方式是可以利用Fragment的

在Hackborn的範例中, 總共有兩個Fragment (TitlesFragment, DetailsFragment) 和兩個Activity (FragmentLayout - 這邊姑且稱之為main activity, DetailsActivity), 這部份的codes可以在ApiDemos裡面找到

在main activity的layout設計上面, 為了達到Portrait是single panel而Landscape是duo panel的設計, 其實是要portrait跟ladscape分開各一種layout, 在landscape是要包含左右兩邊的Fragment, 但portrait就只能包含左邊的

因此, 在portrait mode時main activity由於不會有右邊的panel的ID, 所以必須自行偵測右邊是否存在(或是偵測目前是不是在portrait), 然後決定按下list item的行為, 如果是portrait, 就不能使用DetailsFragment去取代右邊panel, 取而代之的必須呼叫DetailsActivity來顯示, 這作法其實頗為tricky, 而且在這作法下, 懶惰的programmer再也不能overrride onConfigurationChange來偷懶了, 對於習慣不好的programmer應該是蠻容易在Orientation change這邊產生side effects

上面就是利用不同的Orientation方向判斷到底是用DetailsFragment取代右邊Panel還是呼叫DeatilsActivity, 而DetailsActivity其實就只是一個DetailsFragment一個包裝, 也就是當在landscape時, 本來就只有main activity左右兩個Fragment, 在portrait時, 這兩個Fragment被拆開成兩個Activities, 但如果這時候從portrait的DetailActivity轉回landscape要怎回到原本main activity的duo panel型態呢? 作法很簡單(也有點tricky), 在lands cape mode時, DetailsActivity就把自己給finish掉了, 不過這邊要能夠確定history stack的前一個的確是main activity, 不然也會很怪的(一般應該都會是才對)

在Hackborn的範例中, 每次都得重新建立一個新的DetailsFragment, 這樣的缺點是, 每次花在DetailsFragment初始化還有inflat layout的時間會有點浪費, 如果是在複雜的layout跟Fragment, 這樣容易造成許多不必要的垃圾, 當然能夠reuse最好, 如果把她用的replace換成這個replace, 自己給個tag, 那之後就可以用FragmentManager.findFragmentByTag將這個Fragment instance給取出重複利用, 但, Fragment是不可以被重複加入的, 你可以拿instance出來重複使用但如果試圖把這個instance重複給FragmentTranscaction, 那是會發生錯誤的

附記: 如果沒去設定target sdk version是11的話, 那這個應用程式會被當做是小螢幕的而不是一個tablet application, 此時你看到的會是在中間一個縮小版的(學iPad也不要學這麼像嘛… = =“)

不知道為啥那天看到了誠品寄來的廣告, 一時之間就想買這本書, 也顧不得剛領到公司發的金石堂禮券, 一下班就衝誠品去買, 而且居然才是當天上架的新書, 我找半天還找不到, 還拜託小姐幫我找的

See and download the full gallery on posterous

這是一本小說, 但也不全然是小說, 寓意頗深, 但卻不深奧, 藉由一個追隨一個來路不明的賣夢想的先知的追隨者的角度, 來販賣作者自己的哲學思想, 挺有哲學深度的一本小說

故事的開始是由兜售夢想的先知救了一個企圖自殺的大學教授開始, 整篇故事是以這位社會地位高, 但卻尋求不到自我的大學教授描述他所追隨的這位先知的過程, 從救了大學教授開始, 先知一個個累積了不同的"門徒", 每個人有不同的背景, 不同的"故事", 藉由這些故事來導入先知自己的哲學觀念(其實先知應該是作者本身的映射), 先知就像是耶穌一樣四處散播理念, 但這書講的不是宗教, 卻含有一種悲天憫人的思考

最近常常在思考, 自己在這裡, 在這團體裡面, 我到底是誰, 我到底是扮演什麼角色, 我的所作所為到底是為了誰? 還是為了什麼? 到底帶給人家什麼好? 又帶給人家什麼壞? 我的夢想到底是什麼? 到底我還有沒有能力實現我的夢想?

這本書, 正好跟我跟我最近一直在心裡的打的結有接軌, 雖然說沒看完後馬上就把結打開, 但還是有點心有戚戚焉的感覺

這邊分享一些書中的好句吧

“世界是一座巨大的精神病院, 而群眾是住在裡面的瘋子”

“我是個正常人, 就跟其他的正常人一樣慣於隱藏自己的瘋狂”

“即便做了蠢事還能大笑的人是幸福的人”

“社會上有很多土狼跟老鷹, 但是, 體型大的動物並不見得比較值得信賴”

“你不必恐懼人們說的話, 真正可怕的是自己的想法”

“當我們甘願渺小才能成為強者”

“什麼是典型的美麗? 不就是把一些天生基因素質比別人優秀的人拿來當做標準?”

“美麗是屬於所有的女性, 美麗不能被典型化的”

“縱然金錢本身並不能帶來幸福, 但沒有金錢可能也保不住幸福, 金錢本身並不盲目, 是我們自己對金錢的過度執著毀了平穩的生活, 沒有了錢會變得貧窮, 但是金錢的使用不當卻會讓我們淪為卑賤”

“社會以競爭為藉口, 連他們僅剩的最後一滴血也吸乾抹淨”

詳細的Fragment初階可以參考 Developer Document

Developer document裡面的Design Philosophy提到, Fragement的設計是為了讓大尺寸的螢幕(比如說Tablet), 有更動態更彈性的UI設計, 從那個範例圖來簡單的說, 就是想達到iPad上那種Multi-panel的UI設計

在實際設計上, 似乎想要把Fragment設計成一個比較通用的design, 因此看起來比較不像是把一個Activity的話面分屍切成等份, 而是把Fragment當成UI上一個個有自己生命週期的獨立個體, 因此它的實踐未必是以Multi-panel的形態, 因此也有類似像DialogFragment的存在

如果以Web design的觀點來看, Fragment可以類比成<frame>或是<iframe>, <frame>或<iframe>可以看成一個HTML document的一個pagelet, 而Fragment也是可以看成一個Activity裡面受Activity裡的FragmentManager所管理的lightweight inner Activity, 我個人其實對Fragment這設計並不是很欣賞, 如果用它來implement multi-panel UI感覺頗tricky, 尤其在landscape/portrait轉換上, 而Fragment的角色定位似乎介於View以及Activity之間, 你可以將之看成一個有生命週期的複雜View的包裝(好拗口 = =“), 也可以把它看成一個簡易到不行的Activity, 對照ActivityGroup/LocalActivityManager來說, Fragment/FragmentManager 雖然顯得相對的light, 但特別為了這些目的把FragmentManager給整進Activity內, 感覺只是肥化Activity而已

Fragment並不是implement multi-panel UI的唯一途徑, Romain Guy有一個叫做x-large demos/PhotoAlbum的範例, 在這範例中, 他實作了一個Multi-panel based的Album, 但卻沒有用到任何一個Fragment

在初看到這個API時讓我比較感興趣的是, 目前在Android market上已經有相當多的phone based的軟體了, 如果是要把自己原有的架構在Phone based的軟體轉成同時也支援Fragment架構的tablet軟體(就兩者通吃), 在code的重用性, 以及porting的effort到底大不大? 

基本上, 這也不是太大的問題, 只是要把原本Activity裡面的東西抽出變成一個Fragment來implement, Activity變成只是Fragment的封裝

例如說, 原本的layout假設是 main.xml, Activity裡面原本是以

setContentView(R.layout.main)

把原本的layout抽出獨立成另一個layout, 比如說mylayout.xml, 並新增一個新的Fragment(比如說叫MyFragment), 原本的main.xml內容改成:

MyFragment只要implement onCreateView:

這樣Activity跑起來就跟原本還沒用Fragment沒啥兩樣…呃, 那這樣還多此一舉用Fragment幹嗎? 其實這只是一個簡單的靜態範例, 新創造出來的Fragment, 還可以重複在別的Activity被使用(比如說一個for tablet 的multi-panel activity), 也可以動態被創造出來應用

糟糕, 這個應該就是指我了.. XD

會想去找這些是因為用了Android上的一個Browser - Skyfile, 覺得上面的Facebook整合很不賴, 尤其是Like和Popular, 一個可以讓你對任何的網頁使用Facebook like, 一個是讓你知道其他人對這網頁說了些什麼

當然在Chrome上也可以找到類似的Ext

1. Facebook for Google ChromeQuickrr Facebook like

第一個是把Facebook的News feed整合到那個button上, 一按下來就可以看到你最新的News feeds

而Qucickrr Facebook like則是可以讓你對任何URL說"讚"啦!

2. BuzzGrowl for Twitter and Facebook

這個是讓你知道你目前正在看的網頁, 別人對它有啥看法(Facebook, Twitter上), 基本上, 這東西比較討厭的地方就是會佔住右下角的空間