*FastRead 是什麼？
FastRead 是一個針對中文內容設計的速讀訓練工具，它可以調整每次顯示的文字長度、切換速度、文字大小，籍此訓練眼睛與大腦習慣批量且迅速的接受文字，同時提升理解程度。
線上試玩
影片展示
*為何要寫 FastRead？
主要是因為平日要看的東西實在太多(專業書籍、閒書、中英文報紙、技術文章、rss、twitter…. you name it !)，時間有限但資訊爆大量的情況下，必然得用比較有效率的方式解決這問題，因此最近又開始重溫十幾年前學過的速讀技巧，希望能有所幫助。
由於之前訓練的方式與內容都是針對英文題材，因此如果想同時加強中文的速讀能力，顯然市面上找不到現成的工具，只好自已來了，因此花了幾個小時寫了一支小工具出來，自已用了幾天覺得挺不賴，很快就找回速讀的感覺(呃，手有手感，那眼睛應該有眼感吧 XD)。
由於前後斷斷續續大概只花了五六個小時趕出來，因此程式當然還有許多問題，但想想或許可以幫助其它人做中文速讀訓練，所以就先推出讓大家玩玩，有 bug 再提交回來吧。
*速讀的原理
速讀的原理很簡單，一般就是
-把字當圖像來處理：眼睛一次看一組字(這裏的一組可能為三、四個字， 一行、兩行、四行甚至是古人傳說中的一目十行甚至一頁之類的不等)，整批送進大腦裏
-避免「心讀」(subvocalization)：一般人閱讀的習慣通常是
眼睛看 -> 心理默讀 -> 耳朵聽到 -> 大腦接收並理解
而速讀理論上是要略過中間兩個 steps，做到所謂『眼腦直映』，也就是睛眼看完文字直接進入大腦裏理解。
這兩個原則聽起來容易，但實作起來卻很困難，主要原因是
1、速讀不只是講求速度快，更重要的是理解度(comprehension) 也要提升，不然讀很快結果船過水無痕也是白搭，也因此大部份速讀術都會搭配記憶訓練之類的配套
2、大部份人從小養成的閱讀習慣就是先把字唸出來，然後才理解，因此一下子要改成不發聲(不論有無真的發音唸出來)而把文字當圖像整批往腦裏送並且要能理解，還要記起來，就顯的非常困難。
而 FastRead 可以幫上兩個忙：
1、訓練眼睛一次看一組字(例如一次四個字、八個字甚至一行)
2、加快每組文字的顯示速度，讓心沒時間音讀，而強迫大腦直接理解文字，進而達到『眼腦直映』的效果
建議一般人剛開始可以嚐試一次看4-7個字，速度大約 150ms，這個速度就差不多是眼睛來的及接受文字訊息，但心裏來不及讀完聲音的程度，有趣的是，如果非常專心，你會發現對文章的理解力其實還挺高，初學者至少也有 60% 的理解，等訓練個幾天後，相同的速度下理解程度就可提升到80% 以上，這時再搭配一些閱讀技巧訓練，整體的閱讀速度、理解程度與記憶就可以達到優秀的程度了。
不過當然速讀是門大學問，從1950年代出現至今，仍然還在不斷研究改進中，而我個人的速讀能力跟眾多專家相比，差不多只比幼稚園小班低一點，因此如果對這個主題有興趣，請參考下列資料
-Speed reading (wikipedia)
-Speed reading (wikibooks)
-Subvocalization
-SQ3R(reading skills)
*待改進之處
FastRead 目前最大的問題當然就是中文斷字的處理，而中文斷句一向是個大學問，絕非一天兩天就能搞定，幸好我正好認識一位自然語言學 大。長。輩，待有空好好請教後再來改版(出門在外就是靠長輩的啊~)
目前中文斷字主要就是依下列規則
-先依標點符號斷一次，例如，、！？之類的
-再依英文字或括號()” 之類的斷句，儘量讓整句的英文連在一起，並且播放時間會停留久一點(畢竟大部份人讀英文的速度沒那麼快)
-最後再將每個句子依 user 指定的字數分割，例如每四個字一組，當然這裏面會自動調整，有時可能會是三個字或五個字一組
-最後，則是有少量的「避頭尾」處理，儘量不讓標點符號單獨出現在一行，而是將它併入前一行裏
如果你有更好的建議，or better yet, 直接寫好一個 parser (而且還是用 as3)，那當然歡迎隨時與我聯絡吶 
*製作過程
最後聊一下這支小程式的製作過程。
我平常的工作都是寫大部頭的 enterprise application，一個案子可能跑數月到十數個月不等，製作手續也是非常詳細、完整，因此這次雖然一開始就知道只有幾個小時能投入開發，一切要從簡以快為上策。
但從平日的經驗中我瞭解到：快有快的做法，可有些關鍵 steps 不能省，例如UI的設計，因為一開始 UI 沒做好，將來開始 coding 後的修改成本就非常昂貴，並且做出來的東西也不會好用，那整件事就沒意義了。
因此還是乖乖用 Balsamiq Mockups快速畫了兩張介面稿，以方便儘快看出有無操作上的缺失，下面兩張圖大概只花了10分鐘左右，再加上一些來來回回的推敲與修改，總設計時數約30分鐘，但它已足夠確保最終的成品堪用並且沒有明顯的問題(至於其它平常後續會做的處理由於趕時間就直接略過了)。
btw, Mockups 真是一支非常實用的小工具，而 Balsamiq 這家公司與它背後的主人，則更是許多有趣的故事了，但那顯然離題太遠就先按下不表了。
總之寫這支小程式是很有趣的經驗，宛若平日工作流程的縮小迷你與超級加速版，平日要兩星期的事現在大概一小時做完，以往要來回溝通三次的決定，現在想兩秒就定案，如果以後每個客戶都這麼配合，那人生就太幸福啦 XD
最好希望大家試用 FastRead 後如果有任何意見與想法，請不吝隨時回報給我，感謝 
| by admin
看著這個新介面，不知不覺笑了出來…有人想說說妙在哪裏嗎？:P
==== Mar. 10 更新 ====
其實當初我想笑的主要原因就是那個 tab bar 移到最上方的設計，當然大部份都會一眼看出它跟 google chrome 很像，但如果再看仔細一點就會發現兩者背後的「設計意圖」其實還是不太一樣，展現的企圖心與大膽程度也不相同。
以下圖為例，chrome 的 tab bar 仍然是被一個完整的 window container 所包覆住，並且還是有 title bar 的空間，但 safari 的玩法就大膽許多，它是直接讓 title bar 與 tab bar 合而為一，這裏面值得觀察的地方就很多了，其中之一是：apple 的設計師當時的設計想法是什麼？我打賭背後一定有許多 argument 關於是否該這樣做？
總之這是一個很 controversial 的設計決定，並且在工程上要實作也不見得容易(有誰知道在 cocoa 裏要怎麼讓內建的 NSWindow 長出無限多的 tab bar ？請舉手…)
另外一個觀察則是 safari 的 tab 也可以拖離出來成為一個獨立的 window，但從 windows 的版本來看它似乎並不像 chrome 會讓每個 tab 獨立成為一個 process，在 task manager 裏看到的仍然只有一個 process 在跑，因此這可能代表著只要一個 tab 的內容掛了，就會所有 tabs 一起歡樂大滅絕 XD
關於 safari 4 其實有說不完的觀察、心得與想法，但當時我就在想，只要等的夠久，一定會有熱血青年+有識之士會看出 safari 4 有什麼問題，果然後來被我找到下面這篇，真正是完整寫出我心中的想法，尤其是關於 title bar 與 tab bar 整合的那部份，分析的非常好。
Observations, Complaints, Quibbles, and Suggestions Regarding the Safari 4 Public Beta Released One Week Ago, Roughly in Order of Importance
| by admin
(按上圖可看錄影畫面)
早上看報紙時不小心看到(實際上它就在頭版最上方，除非瞎了不然應該誰也不會錯過 XD) Apple 的新廣告，這次是主打 17″ macbook pro。
這個廣告很有意思的地方不在於它的呈現手法、版面位置甚至是背後的 campaign strategy, 有趣的地方在於它的『主訴』，完全沒提到 17″ mbp 多亮多快多威 unibody 多堅固或 Jonathan Ive 有多帥，從頭到尾只提一個重點，就是『可用五年的電池』。
注意這裏面有兩個名詞，電池，跟 五年，而 Apple 的重心不是放在強調電池容量有多大，一次可用多久(當然也沒提這電池不能自已拆換將來如果掛了還要付錢送回去請人換)，它強調的是這玩意可耐用五年，因此造成的污染比較少，對地球比較好。
也就是說，它已經不是在賣商品，而是在訴求環保這個議題，也因此，花下去大筆的鈔票，其實是在救地球，頓時動機就覺得高尚良善許多，更棒的是，還可以得到一台 laptop，這樣滿足感是不是更高呢？XD
所以這件事的心得是：與其大聲費力叫賣硬把東西塞給客人，不如訴諸情感、經驗，用反向/彎曲的方式間接把客人吸過來，效果可能更好(刷刷刷 筆記筆記)
| by admin
(click on the image to see demo video, source won’t be available for that it’s a client project, IP reserved)
As most of you know, undo/redo had long been part of the basic user experience all users would expect for pretty much every apps out there, let alone in a full-fledged RIA these days (hey “rich” ain’t there in RIA for nothing !), but this is not the case for flex/flash apps,
I’ve been wanting this for quite sometime now, to be precise, ever since flex first come out a couple of years ago I’ve been thinking why there’s no undo/redo capability for all the textfield-based component (TextInput, TextArea and RichTextEditor, that is).
and fortunately enough recently a client asked for this feature added to the app I’m working on, so I got a chance to finally have it implemented.
*Basic features include
-built against flash.text.TextField, so all text components in flex framework supported.
-has built-in UndoManager but user could supply custom UndoManager too, as long as it implements IUndoManager. (who doesn’t ?)
-unlimited level of undo and redo
-undo by single character (TextMate any one ? 
or a stream of words (a.k.a normal mode)
-correctly handle delete and backspace keys for mac
-support built-in RichTextEditor, hence all text format modifications could be handled too
-handles right-click context menu (“Cut” and “Paste”) in AIR.
-easy to use, var tm:TextManager = new TextManager( tf ); one line of code and it could undo/redo everything.
-support double-byte languages like Chinese, Korean and Japanese (this is not really a feature for that flash player support unicode natively
*Some of the problems I ran into include
1. there’s no easy way to handle cut and paste short cut keys within browser, cmd-X and cmd-V will be “eaten” by containing browser, under Stand Alone player case, the player shell will eat the event, I know this could be dealt with old-school javascript tricks but I would rather refrain from going that direction because then developers will have to remember adding that piece of junk js to the browser and handle ExternalInterface.
After playing with various keyboard events finally I find a way to handle cut and paste with a combination of key events, all native flash player event hence no js, no interface, no nothing, just drop the swf in there and magic happens.
2. right-click menu
Seems to me there’s NO WAY to handle “Cut” and “Paste” menu command in browser version, and worst yet, there’s no way to disable the menu (in flash player 10 there’s ContextMenu.clipboardMenu = false, but, it’s not applicable to textField, ouch !). I could just have my finger crossed and hope user won’t be using that right click menu.
Good news is it could be handled correctly in AIR, and better yet, the project I’m working on, is an AIR app
3. I tried to have it implemented in a strict MVC way, but the traditional textfield in flash player 9 didn’t provide some of the low-level functionalities I need, so a bunch of quick hacks were threw in, but good thing is the new text engine in flash player 10 looks real promising, let alone the Text Layout Framework(TLF), I’m looking forward to work on that sooner than later.
*What’s next ?
Some people asked is it possible to turn this into a full-blown text editor, sure you can, but there’s already Buzzword and Google Docs providing such services, and like a 1000+ editors on the desktop ( TextMate, TextWrangler, Smultron, EmEditor, NotePad++, to name a few), so I don’t really see the value in creating such thing, but I could be wrong, if so, please kindly let me know !
| by admin
＊緣起
最近因為工作需要，又再度開始接觸 Amazon EC2/S3(早在2006初這個服務剛推出不久時曾用過一次，那時是 RoR 加一堆 merb，不過後來隨著專案結束也就漸漸忘了這玩意)，結果這次隨便查了些資料卻發現 cloud 這個字似乎已無所不在泛濫成災，也讓我一時興起想瞭解一下到底現在大家口中所謂的 cloud 是在指什麼。
會這樣好奇主要的原因是在許多地方都看到有人自稱在提供 cloud service, 但這些服務間彼此的性質、形態與做法差異性卻很大，例如 ec2 與 gae 兩者就不太一樣，gae 與 salesforce 又很不同，搞到最後，似乎處處是雲端，人人在漫步…
根據 wikipedia 的定義，cloud 最寬鬆的定義是這樣的(擷錄):
It is a style of computing in which resources are provided “as a service” over the Internet to users who need not have knowledge of, expertise in, or control over the technology infrastructure (“in the cloud”) that supports them
如果你對這樣的定義沒問題，那非常好，不用再浪費時間看下去，去喝杯咖啡吧。
(紐約25街上最棒的咖啡館，三明治也值得一試)
很可惜這樣的定義在我聽來似乎寬鬆的有點誇張了，因為這樣說來，我在家裏擺幾支 iphone 跑些服務並開放 api 給人用，其實也算是 cloud 囉(還是高雅的 apple cloud哩)？XD
就因為這該死的好奇心，我花了幾天時間調查並整理了些相關資料，現在總算比較有個頭緒了。
請注意這只是我個人的心得整理，文中對於名詞的定義與詮釋，尤其是 cloud，只是我個人的想法，如果有錯歡迎各方大德賜教。
＊from hosting to VPS, is it really cloud ?
基本上如果要細究到底 cloud 是什麼，可能可以先吵上個三天三夜還沒定論，因為根據眾多前輩的說法，cloud 這個字本來就是個 buzz word, 想用的人就隨喜取用了，其實根本沒啥定義好談的啊~
因此，我打算先跳過試圖去定義這個字的破題法，從實際的 deployment 方式來看這件事。
以往一般人要 hosting，大多是去租虛擬主機，有錢一點就丟機器到機房去(co-location)，這是最常見也最傳統的手法，這個手法最大的缺點在於 – 如果臨時有大流量需求，例如辦個 campaign，很難迅速的擴充服務能量，不論是要搞到大量的機器，或無窮盡的頻寬，都是個問題。
因此，這幾年來比較流行的玩法是所謂的 VPS/VDS (Virtual Private Server)，透過類似 XEN 這樣的軟體，將一台實體 server 虛擬化(virtualization) 成多台虛擬機器然後出租，這樣一來當臨時有大流量需求時，可以很容易的加買幾台虛擬機器就撐過去了。
前面開頭談到的 EC2 就是這樣一個服務，另外這一兩年頗受好評的 Slicehost也是，在 EC2 的例子裏，每一個虛擬出來的機器叫做一個 instance，因此要應付大流量 campaign 時，可以狂開 instances 撐過去，這比狂買實體機器便宜多了。
由於 VPS 真的超方便而且很好用，因此迅速受到大家歡迎，久而久之，VPS 這樣的服務似乎也就跟 cloud 畫上了等號，但這個等號裏，有個地方卻值得進一步討論。
簡單來說，今天一個人在 ec2 買了 100 個 instances，它們並不會自動聯合起來工作，而是要靠人工去規畫，例如最常見的是在前面放個 reverse proxy 然後把 request 平均導向到這 100 台機器上(round robin load balancing)，並且，更重要的，app 本身在撰寫時就要考慮到將來能支援跑在多個分散的機器上，例如 session 要怎麼維持？global memory 如何分享？database 是否也要散聚在不同機器上？如果分散要怎麼維持資料同步？等等這一大堆相關的細節要處理，一個沒弄好，呃，就成了 twitter 第二..XD 
從這個角度看來，VPS (不論是 ec2 or slicehost)提供的其實是 virtualization 與 load balancing 服務，至於在這個基礎服務之上，user 要怎麼玩就是各顯神通。但 load balancing 與 cloud 似乎並不盡然相同呀！
＊那世界上還有其它種類的 cloud 嗎？
有，例如 google app engine (簡稱 GAE) 提供的服務。
簡單來說 gae 是由三個東西組成的，分別是 MapReduce, BigTable, GFS(google file system)，其中最重要的特色就是 MapReduce。
MapReduce 可說是一個演算法，也可說是一個 framework (看你讀的文獻來源)，但它基本上是由 map 與 reduce 兩者組合，運作方式也很簡單：
map: master node 將工作切割成許多小塊丟給 worker (child) nodes 去執行，worker node 可能會再切割工作成各多的小塊給其下的 worker node 去執行，因此這是一個樹狀的結構。當 worker nodes 完成計算後會將結果傳回給 master node。
reduce: master node 拿到 worker node 傳回的結果後，將它組合起來，就完成工作了。
對 MapReduce 有興趣又閒的發慌的朋友可以去看看 google 發表的一篇論文 與簡報(保証會睡的很香甜 )。
類似 GAE 這樣的服務，它們最大的特色就是會將工作切割成很多小塊，然後經由多台電腦聯合起來一起運算，也因為要切割，因此通常會伴隨者一個 distributed file system (在 gae 的例子裏，叫做 GFS)，通常也會有一個分散式的資料庫，例如 gae 裏叫 bigtable。
當然前面講的都是針對底層架構的設計，但對最前端的開發者來說它代表什麼意義呢？很簡單，開發者可以完全不用管它有100台或10000台電腦在運作，只要照著 gae 提供的 sdk (呼叫它的 API，操作 bigTable，或用台灣之光 ericsk 大開發的 gaeo
)開發程式 ，將來佈署到 gae 上後就會自動去調用一堆電腦(而且很有可能是分散在世界各地 data center 裏)來發功，從這個角度來說，開發者要擔心或處理的細節是比較少的，也因此理論上 time to market 也是比較短的。
＊如果不想用 gae 有其它選擇嗎？
有，Hadoop 是 Aapche Foundation 裏一個 java-based 的主要計畫，基本上可視為開源版的 gae(很多關鍵技術是依據 google 開放的學術論文來實作的，例如 MapReduce, distributed file system 等)， 目前最力挺的開發者是 yahoo，用於該公司的 search engine 上，而 hadoop 的創始者目前也在 yahoo 上班(今年紅利會不會很傷？:P)，這裏有一篇 iThome 的中文報導值得一看。
Hadoop 主要由下列三者組成(其它詳細說明請看官網)
Hadoop Core: 主要就是 implement MapReduce
HDFS(Hadoop Distributed File System)：參考 GFS 而來的分散式檔案系統
HBase: 基於 HDFS 的分散式資料庫(功能等同於 google bigtable)
＊所以 hadoop/gae 與 ec2 是互斥的嗎？
不見得，要看比較的面向為何？但實際上它們是可能合作的，其中最著名的例子是紐約時報在 ec2 上用 hadoop 轉了4TB 的 PDF (這篇文章超級精彩不看可惜)。
故事大略是這樣：
NYT 有一狗票 1851-1922 年間掃描的一千一百萬份文章要從 TIFF 圖檔格式轉換為 PDF，由於數量實在太龐大，轉換起來不但耗時甚久，也需要極大數量的機器，就算有錢如 NYT 也不想當凱子爺投資這麼多啊~(而且因為轉換時間太久，也不太可能跑去 Best Buy 刷它個幾千台 pc 回來，然後速速轉完就退回去 XD)
最後 NYT 的工程師將所有檔案傳到 s3 放著，然後到 ec2 開了 100 個 instances，再裝個 hadoop 利用這100台電腦跑分散運算，結果是只花了 24hrs 跟大約3000美金就搞定(由於處理速度實在太快，他們實際上還跑了兩次吶…)
這個例子也正好帶出下一個主題。
＊那 ec2 到底是不是 cloud ？
這要看你怎麼定義 cloud 這個字，以我而言，我傾向認為 MapReduce 與 distributed file system 是 cloud computing 的主要特色，因此在這個定義之上，EC2 並不符合首要條件。
但如果我們把問題轉成：ec2 可以成為 cloud 嗎？
那答案就是肯定的，從上面 NYT 的例子可以看出，EC2 提供100個 instances 只是基礎架構，之後再上面跑 hadoop 才是真正發功之所在。
由此我們也可以得到另一個結論：硬體本身有無 virtualization 並不重要(你可以買100台真的電腦連起來，也可以用 ec2 開100個 instance)，重要的是在其上協同運算的方式( MapReduce 是這裏的關鍵)
更簡單的二分法則是這樣：
*Amazon 只是把硬體虛擬化，然後賣 raw-level computing power
*GAE/Hadoop 則是提供分散式協同運算, packaged computing solution
因此，或許我們可以把 ec2 視為 cloud 的前奏曲，擁有它之後，要不要做成 cloud (例如裝上 hadoop) 則是個人選擇。
＊所以，何時該選 ec2 或 cloud 呢？
這是更重要也更實際的問題，而答案也很單純，主要就是考慮下列因素
1、你要解決的問題是否能符合 MapReduce 的矩陣分割方式？
或是更白話一點的講，你要做的事能不能被切割成小小的一塊塊來個別擊破？例如 log file 的分析就很適合，但 friend of friend database 就不見得適合。
如果你的問題可切割成許多小塊，那就可以考慮下一點。
2、vendor lock-in 是否是個問題？
這個主要是針對 gae 而來的，現在如果用了 gae，基本上它的 lock-in 特質非常強烈，例如一定要用 python 與 bigtable，整個資料庫欄位的規畫方式跟傳統 RDB 完全不同，操作語法也不一樣，將來幾乎無法迅速移轉到其它 hosting 上(雖然有人寫了 GAE to EC2 conversion kit, 但有沒有膽用是另回事)，喔，更別提市場上 python 的人才有多貧乏這件事，會 RoR 的人搞不好還多一點。
當然這裏可能的另一個選擇就是效法 NYT，用 EC2 + Hadoop 搞客製化分散式運算，而且用的是 java ，人才四處可得相對門檻就低一點(結果最後是死在 MapReduce 搞不定 ? )
＊那 SaaS 是 cloud 嗎？
這也是個好問題。
現在很多 Software as Service 的服務商，例如 Salesforce 也都宣稱自已有提供 cloud computing 服務，這又是怎麼回事？
我認為比較合理的看法是將 cloud 分成三個層次來看：
第一層是硬體層(100台真的電腦，或100個 ec2 instances)
第二層是 framework (hadoop, gae, ms azure)
第三層才是 service (accounting, pdf generation…)
在這樣的架構下，SaaS 是屬於第三層的 service 這個 scope。
也就是服務商先搞定第一、二層後，在其上建構自已的 domain service，例如 salesforce 的主力服務是 CRM，因此它透過 cloud 提供一系列的 CRM API 給開發者使用。舉個誇張的例子(注意，這例子是假想的)，搞不好 salesforce 也是租 ec2 然後搞了個 hadoop，接著在上面用 java 寫了一堆 api 給人 call。這時它就是三層皆備，可稱 cloud 而無愧了 XD
另外類似的例子則是像 gmail, google reader 等，這些都是 software services based on GAE (先搞定一、二層，然後建構第三層的 domain service)
＊附錄
原本我曾認為 ec2 的 virtualization 可以做到將許多台實體電腦虛擬化成一大台 server，這樣工程師就只需要針對一台『超級電腦』來寫程式即可，如果是這樣，那 ec2 其實也符合分散式運算的標準，但我查來查去只不斷看到類似下面的解釋：
EC2 is more designed for applications that scale well across many hosts, rather than larger applications that require huge resources. IMHO, the xlarge instance is quite fast. Maybe you can identify a bottleneck in the application and address that? Is it really CPU bound?
Scalability: Amazon supports easily adding or removing servers, not adding more power/memory/disk to an existing server (instance). This works well when your application is architected to scale across multiple servers to support increased load.
因此目前先初步認定 ec2 並沒有提供這方面的能力，當然如果有錯，歡迎指正。
＊後記
在研究期間叨擾了無數前輩，感謝他們犧牲週未時間情義相挺回答各種無趣的問題，在此致上最高謝意 
另外關於 ec2 vs. slicehost 的成本或用哪家比較划算這檔事，我也小小想了一下，從實際數據看來，如果只是小型的網站或是 newly startups，從省錢的角度來看，應該要選 slicehost，因為它的初始成本最低，例如花個 $20 美元就可以有頗大的空間與流量可上線 run 了。
但 ec2/s3 的好處則是安全性、穩定性與擴充性，而它最大的缺點則是成本相對較高，一個 instance 開著不用一個月就要 $72元，如果生意好流量大那要交的費用就更多。
目前台灣地區用 ec2 的的網站似乎並不多(pixnet ? 但把資料存在 s3 的站就多一點)，可能主要是連線反應時間不夠快所以接受度不高吧，但我們服務的客戶本來就多在北美，所以沒差 XD
| by admin
Next Posts
Previous Posts
