關于個人文檔管理 － 電子書2

上一篇文章里面說到，手里的電子書，大體可以分成經典、手冊、喜歡的、教材、普通的書、消遣、難懂的書、別人推薦的書、騙人的書這么幾個類別。

那么針對這幾個類別該怎么區別對待呢？

1、對于經典的、手冊類型的書：對于這種經常會用到，而且極有價值的書，要放到最容易獲得的地方。通常每個人的這種書都不多。把它們管理好（后面會說怎么管理）后，做一個鏈接放到桌面上或者桌面上的文件夾里。——當然，在Mac下還有更好的方式，不過在Windows和Linux下，按上面的方式來做就足夠了

2、對于經常喜歡看的、消遣的書：如果可能，放到手機、MP3里面吧。那樣你就什么時候都能看了。呵呵。

3、對于教材、普通的書：分門別類的管理好。給你正在看的書建個鏈接放到桌面上。看完了怎么處理后面再說

4、對于難懂的和別人推薦的書：扔掉它吧。再好的書，不看也是垃圾一堆。不要擔心你可能會有真正想讀的時候，一般來說，技術類書籍，你現在不想讀，你永遠都不會想讀的。而且，如果是經典的話，你想讀的時候自然會找得到。

好了。有了上面的對電子書區別對待的前提后，我們來開始討論如何在計算機上管理電子書吧。

首先，我要先說一說我認為電子書管理中最重要的兩個前提：
1、CPU的時鐘周期不值錢，你的時間值錢。
2、硬盤的容量不值錢，你的大腦容量值錢。

有了這兩個前提，就可以說說我在電子書管理方面的經驗啦。我的經驗大體如下：
1、不要建立過多、過深的文件夾：
一般來說，除了該死的java程序，你的文件夾都不要建到5級以上。因為即使每個文件夾里面只有兩個文件夾，你就會有32個文件夾。你的大腦容量是有限的，你不需要記住這些文件夾的，一般人也記不住。
你終究會發現，為了找到一個文件，你總是在不同的文件夾中跳躍。

2、集中管理：
不要告訴我你的文檔散布在多個分區（C:、D:、E:...）的多個文件夾下。相信我，那絕對是一個噩夢。你可能會反駁我說，我把所有的雞蛋都裝到了一個籃子中，會有風險。實際上，你只有一個文檔文件夾的話，備份和同步是一件非常容易的事情。

3、要搜，不要找：
當你的文檔越來越多的時候，你就會發現在文檔文件夾里找到你想要的文檔是多么麻煩的一件事情了。現在的操作系統都有可以進行全文檢索的高性能搜索引擎了。畢竟機器要比肉眼精確，你的時間要比CPU的時鐘周期更值錢

4、利用元數據
在這一點上，Mac是做得最好的。它提供了Spotlight注釋這個完美的東西。你可以以注釋的方式來為文檔添加搜索的元數據。這也是我現在進行電子書管理的精髓所在。Google Desktop好像沒有這個功能。

總結一下，通過在電子書管理的兩個前提下，靈活的使用鏈接、搜索的功能。是我管理電子書的手段。

我會在下一篇文章里，說說我管理電子書的方式。

posted @ 2008-09-01 14:37 guitarpoet 閱讀(553) | 評論 (0) | 編輯 收藏

關于個人文檔管理 － 電子書

posted @ 2008-08-31 17:46 guitarpoet 閱讀(918) | 評論 (2) | 編輯 收藏

關于個人文檔管理 - 電子郵件2

這是關于電子郵件管理的最后一篇。

我的郵件管理心得大概可以分成下面幾個點：

1、即看即管理：收到郵件之后，如果沒有處于不可打斷的狀態下，就要立即開始處理，處理方式大概分成下面幾種
    *如果是無用的郵件，立即把它刪掉
    *如果郵件很長，或者郵件中鏈接比較多（比如訂閱的期刊），而時間有限，把郵件設置成為未讀，留待有時間的時候讀
    *如果郵件跟工作有關，而沒有時間處理，給郵件打上旗標，留待有時間的時候處理
2、周期性管理：每天都需要整理該天的郵件（這也是務必做到當日事，當日畢的工作態度），處理掉未讀的和加注旗標的。對于期刊，未必一定要讀完。加注旗標的工作，則需要進行工作管理了。
3、階段性梳理：在到達階段性的時間點時（如一個項目結項，每個月的第一天或者最后一天）。需要對這一階段內的工作和相關材料進行梳理。電子郵件也是其中之一。
4、善用搜索：在充分的維護元數據之后，你就會發現搜索的好處了。比如，在你為項目干系人建立聯系人組之后。相關時間跨度內的項目相關的郵件一個相關查詢就足夠了。如果你的郵件客戶端支持在查詢的結果上查詢的功能。通過聯系人、主題等等信息，一般說來，找到你想找的郵件，不會非常困難。
5、保存常用的搜索：我有幾個常用的搜索，以智能文件夾的方式保存起來了。這些常用的搜索是：
    *To Read：所有的未讀郵件
    *Today：當天收到的郵件
    *Flagged：所有加旗標的郵件
    *Has Attachment：所有有附件的郵件
6、充分利用郵件客戶端的特色功能：有的郵件客戶端（如GMail和Apple Mail）都可以根據話題進行郵件自動分組。GMail的類似論壇帖子的方式是更加優雅一些。按話題自動分組郵件，可以極大的減輕利用郵件討論一件事情的負擔。尤其是在多人討論的時候。
7、充分利用郵件的處理規則：很多郵件的管理和處理都可以采用規則進行自動化的處理。比如，可以把所有來自家里人的郵件打上綠色的標簽。便于和工作郵件區別開來。或者把相關郵件拷貝到相關的文件夾中（GMail的對應操作是為這個郵件打上標簽）。
8、利用搜索引擎技術：不要用OutLook自帶的查找。那樣查找效率太低了。可以利用MSN Toolbar或者Google Desktop這種搜索工具來幫助你。我用的是Mac OSX，Spotlight已經很好用了。

好了，關于電子郵件的管理，就說到這么多吧。下一篇里，我將會討論電子書的管理。

posted @ 2008-08-25 21:57 guitarpoet 閱讀(386) | 評論 (0) | 編輯 收藏

關于個人文檔管理 - 電子郵件

好吧，我承認，我的上一篇文章沒有提到跟電子郵件管理相關的事情。呵呵。

無論你使用什么郵件客戶端（GMail除外，GMail屬于比較奇怪的，待會兒再提）。郵件的管理操作都可以簡單的看成是對只讀文件的操作。

郵件就是一個個的只讀郵件，你通過文件夾（可以分級——也就是文件夾套文件夾）來分類的管理它們。

你可以通過郵件的元數據（收件人、發件人、抄送、發送時間、接收時間、重要程度、是否已讀、所在郵箱、內容。。。）來檢索、排列和查找郵件。

下面，我來列舉幾個我所見過的郵件管理方式（我在這里只列舉我所見到的方式，使用技巧打算在下一篇文章里寫）：

1、日期型：
這類的郵件管理方式，一個最大的特點就是每個月都建立一個新的文件夾。文件夾的名稱就是當月的年份和月份，如2008-02。當月收到的郵件都從收件箱中拷貝或者直接轉移到該文件夾中（這個規則應該很好寫）。

以一天平均收到100封郵件的頻度來算（如果是普通工作郵件的話，已經算是非常多了，以我的經驗來說，平均一天20～50封是正常的）。在一個工作月內，可以收到2200封郵件。在一個文件夾內并不難管理（何況你還會刪掉一些無意義的郵件，并且還可以在這個基礎上進行分組和過濾）。

如果你確實有精益求精的追求，你可以在這個文件夾下再分成工作細類。這樣看起來更漂亮。

這種管理方式很適合短期雜事很多的人（比如HR）。這種方式的優點是，月底進行個人統計的時候非常方便。而且做查詢也比較方便（直接用眼睛看）。

當然，這種方式缺點也非常明顯。你肯定不能從一串數字上看出你這個月都干什么了（當然你愿意在其下花力氣分成細類，這一點就容易一些）。對于經常并行的進行有時間跨度工作（比如多個項目的平臺技術支持）的人而言，這一管理方式明顯效率低下。

2、項目型：
即使是進行項目型的管理，仍然需要通過時間來劃分郵件（為了歸檔和寫年終總結方便）。但是時間的劃分往往會比較長，比如用一季度、半年或者一年來劃分。

項目型管理的最大特點就是按項目分組管理郵件。舉例來說吧。

假設我是一個平臺軟件工程師，我支持著公司在廣東、山東、北京、上海這四個項目。

我會在今年（2008）的文件夾下建立四個文件夾分別是廣東電力、山東社保、北京移動、上海聯通。我會在我的聯系人里建立這四個組。然后建立四個規則，把所有在收件箱中這四個組中聯系人發的郵件分別拷貝或者移動到這四個文件夾中。

項目型的方式，適合于對多個項目（子項目）進行并行工作的人。在項目相關的文件夾中可以通過基于時間的查詢查找到相應的郵件。可以很一目了然的看出你在某一年都做了哪些項目。而且，通過按照時間的查詢，仍然可以查出你在某個月的工作郵件。

如果你的雜項工作很多或者大多數都是沒有規律的工作，這種方式就不一定合適。

3、區別對待型：
區別對待型的精髓，就是看人下菜碟。以我的經驗，在營銷的人員中采用的比較多。不過也有技術人員采用。呵呵。

區別對待型就是按照聯系人的組來安排郵件。比如可以建這么幾個文件夾：領導、山東社保項目組、朋友、其他。

說真的我沒看出來這種管理方式的優點。我覺得這種方式跟沒管理沒啥區別。真的。

4、狀態分類型：
按照郵件所關聯的工作的狀態進行分類。可以分成：待辦、正在處理、已經處理、已經延遲和其他幾個部分。

有的項目經理是采用這種方式來管理郵件的。所有的未讀郵件都是待分類的郵件。之后通過手工揀選的方式來進行管理。

這種方式，不是很便于存檔和查詢（試想，過了一段時間之后，已經處理這個文件夾里面會有多少郵件？）。

總結一下：
1、郵件會越積越多的。相信我，真的會越積越多的
2、郵件對工作非常重要，所以郵件的歸檔、保存和檢索都非常重要
3、從目前的效果上看，郵件客戶端仍然無法被GMail的Ajax客戶端代替
4、最好要根據自己的工作性質，決定出一個適合自己的郵件管理風格。在這個基礎上還可以應用很多的技巧。機器不怕重復，但是人都害怕復雜

好了，下一篇里，我將把我所知的郵件管理的技巧都寫出來。也作為一個存檔。留待以后接著完善吧。

另外，關于電子郵件寫得太多，未免開始離題了。再寫一篇，就要開始寫電子書/文檔的管理（我打算把這個方面重點寫一寫）了。

posted @ 2008-08-24 10:26 guitarpoet 閱讀(596) | 評論 (0) | 編輯 收藏

關于電子郵件

關于電子郵件

好了，今天來討論電子郵件。

電子郵件是非常優雅和浪漫的交流方式——郵件的電子表示方式。它擁有前輩的很多優點，在某些方面上甚至超出了前輩。

但是，你雖然可以把信紙換成薰衣草的顏色，你卻無論如何也無法發出有薰衣草香氣的信來。有時候，歪歪扭扭的手寫字，要比你選擇的任何字體都能代表你的心意。——你休想拿電子郵件寫出完美的情書來。呵呵。

好了，言歸正傳，我們先列舉一下電子郵件的特性吧。

1、只讀：電子郵件的只讀特性與它的前輩一樣，你無法改掉別人發給你的郵件，你只能選擇保留還是扔掉它。因為這一點，電子郵件是有法律上的證據意義的。以我的了解，世界上某些國家——包括中國，都可以用電子郵件存根作為證據。
2、異步：異步的消息發送方式，使得非同時工作（時區差異、地區差異等）變得容易，而且使得個人工作的安排和調度方式更加靈活（你可以選擇何時去收郵件，收到郵件后何時進行處理）。
3、高效：雖然，相對于前輩，電子郵件的發送和接收都容易了很多。但是，由于電子郵件仍然是郵件。在書寫電子郵件的時候，仍然需要經過一定的構思。務必達到條理清晰、言簡意賅的程度。雖然不能實現實時的溝通，在很多的情況下反倒會比實時的溝通有更高的溝通效果。
4、安全：基本上，所有的電子郵件服務器都采用了傳輸層加密了吧？如果再加入個人的公、私鑰加密的話。應該說郵件信息的安全還是比較容易得到保證的。
5、檢索容易：當然，這也和電子郵件的管理方式有關。不過，無論如何，電子郵件都比IM的聊天記錄容易檢索。比無法進行記錄和檢索的語音聊天要高更多
6、溝通方便：靈活的使用電子郵件，可以非常方便的實現網絡異步會議室。實現非常好的溝通效果（比如Apache的Malling List或者Google Groups——不得不說，Google Groups是基于電子郵件的非常優雅的應用之一）。另外，通過靈活的使用CC。也可以非常大的提高溝通的效率。;)
7、使用方便：電子郵件已經逐步的移動化，不管是iPhone還是藍莓，電子郵件都是非常重要的功能之一。在現在如果你愿意，你可以隨時訪問你的郵箱，發送、查看和管理郵件

好啦，就寫到這里吧。先在這里總結一下。下一篇再討論我的電子郵件管理方式。

1、良好的電子郵件溝通是高效工作的重要組成部分。Apache就是靠這個成功的，相信它吧。
2、電子郵件的異步和檢索容易的特性，對電子郵件的管理提出了很高的要求，在這一點上，有好的電子郵件管理方式要比沒有工作效率高很多
3、你終究會發現可以在任何時間、任何地點、任何機器上管理你的郵件是多么重要的一件事情。所以，放棄POP3，擁抱IMAP吧。

posted @ 2008-08-22 20:38 guitarpoet 閱讀(472) | 評論 (0) | 編輯 收藏

關于個人文檔管理－圖片和視頻文件

昨天又寫了一篇又臭又長的文章。從今天起，篇幅力圖達到短小精悍。

我不是一個攝影愛好者（所以到現在還沒有數碼相機），也不是一個很愛拍照的人。我自己拍得最多的就是每周一次用筆記本拍的減肥效果記錄。

由于電影一般看完就刪、很多音樂視頻都可以在網上看，而我又不愛看電視節目，所以我的視頻簡直屈指可數。

視頻和圖片的最大的特點就是它們都是大把吃掉硬盤的怪物。舉例來說，一個SRV的Live from Austin Texas就吃掉了我700M的硬盤。我的工作區中所有的文檔大小的總和都不及它的一半。

我對待視頻的策略，仍然是我用的最熟的大抽屜策略：最常看的和馬上要看的視頻（比如最新的電影），放到Movies文件夾中。其他需要保留的經典，刻盤保存（太大了，裝它們移動硬盤吃不消）。

由于我再看它們的可能性不是非常的大，所以刻盤保存的風險我可以接受。

我使用iPhoto來管理我的圖片。用iPhoto來管理相片的體驗，和用iTunes管理音樂差不多。只不過播放列表變成了相冊。我自定義了一個關鍵字“減肥日記“（開始是想每天照，可是我實在太懶，呵呵），我每周拍的減肥效果記錄都會加上這個關鍵字。在這個基礎上，我建立了一個查詢，列出所有關鍵字為”減肥日記“的相片。這樣，我的減肥效果就可以一目了然了。哈哈。

總結一下：

1、視頻由于體積大，收看次數較少。可以考慮采用刻盤歸檔的方式。但是一定要預留一些空間使用大抽屜原則（常用的東西放到最容易找到的地方）。在使用刻盤保存的時候，一定要考慮為所有的光盤建立可供檢索和查詢的索引（光盤的編號、光盤的內容、光盤的存檔時間）。對于個人而言，這些只要一個Excel表格足矣，不需要什么額外的軟件。
2、圖片的管理方案與音樂異曲同工。因為除了媒介和使用方式有所不同外。二者的根本都是大的二進制文件 ＋ 圍繞這個文件的一系列元數據。而且，與音樂一樣圖片數據的備份和查看也被iPod很好的支持。

關于我的圖片和視頻的管理方式，就到這里吧。下一篇需要討論的，是對工作非常重要的，電子郵件的管理。由于它太重要了，而且涉及到的技巧也太多了（很多人都有很優秀的經驗）。如果一篇寫不完，可以考慮多寫幾篇。:-)

posted @ 2008-08-19 09:32 guitarpoet 閱讀(1174) | 評論 (2) | 編輯 收藏

關于個人文檔管理 — 個人音樂管理

好了，接著昨天的話題，說一下我的音樂文件管理。

托生在中國的福，我只花了很少的代價，就聽到了很多高質量的音樂（誰都知道是怎么回事，呵呵）。

對于我這種須臾離不開音樂的人來說。找到自己今天、現在想聽的音樂。并不是一件非常容易的事情。

說起個人的音樂管理，我打算從革命的傳家史開始。

我的音樂管理可以分為下面幾個階段。

1、卡帶 ＋ 錄音機：
    所有的卡帶都放到寫字臺的大抽屜里。大抽屜放不下后，則把所有的音樂分成兩批：常聽的、不常聽的。不常聽的放到寫字臺的柜子里。常聽的放到大抽屜里（對，就像當時賣卡帶的店一樣，不過是按照個人好惡來排序的，最愛聽的，放到最外面）。
   
    當我要開始聽音樂的時候（也就是寫作業或者看書的時候），我會拿出五盤卡帶（要知道5 × 45，時間也不短了，呵呵）。作為最終手頭的音樂。

2、卡帶 ＋ 隨身聽：
    我有了第一個隨身聽的時候，終于可以實現邊走路邊聽歌的欲望了。從那個時候起，我的書包里開始放卡帶。不過，雖然設備升級了，我還是用以前的管理方式。

3、CD ＋ CD隨身聽
    我在有CD隨身聽之前就開始聽CD了（托VCD流行的福）。開始我的CD不多，沒過多久就有PC了（大學的時候）。所以，這個階段乏善可陳。

4、PC ＋ 播放器 ＋ MP3（硬件設備，呵呵）
    有了CD、PC和MP3之后，卡帶對我就已經成了歷史，我成功的以不算太低的價格（2元一盤？）把我所有的卡帶都甩了出去，除了幾個實在舍不得的（比如魯道夫的貝多芬鋼琴奏鳴曲、布魯諾的馬勒第九）。當時用的播放器是Windows Media Player、金山影霸（多難聽的名字？）。文件管理也很簡單，每個CD一個文件夾。而且，沒有任何的元數據，全是Track1.wma、Track9.wma，呵呵。

    我的第一個MP3小得可憐，128M。放我從CD抓的WMA文件，只能放一張專輯多（放交響曲的話，最多也就是兩個）。只能每天都在曲庫（一個文件夾——跟我管理的卡帶的大抽屜異曲同工）里挑——真的是精挑細選。

    之后是刪除、拷貝操作。然后是打開MP3的循環播放。

    在PC上，我有幾個常用的播放列表。這樣在使用WMP的時候，就可以很容易找到自己想聽的歌了。

    這種方式非常差勁，我經常會丟掉我的元數據、播放列表，尤其是在重裝系統的時候。

5、PC ＋ iTunes ＋ iPod——現在
    經過多年，我還是入了Apple的賊船，進入了iPod的圈套。好了，我來仔細的講一下我現在的音樂管理吧。

我現在的音樂管理方式：

1、所有音樂集中管理：
    我盡可能的把我所有的音樂都集中的管理起來（目前是幾百張專輯吧——不多），十幾個G的音樂統一的交給iTunes來管理。我之后買的所有的CD，全都是在用iTunes抓軌之后收藏。只聽iTunes管理的音樂。

2、收集和整理音樂的元數據：
    對于音樂，iTunes可以支持的元數據有：名稱、表演者、年份、歌詞、專輯表演者、軌道編號、BPM、專輯名、專輯圖、光盤編號、風格、作曲、歸類、注釋、評價、音量、均衡器、播放次數。
   
    其中后面的歸類、注釋、評價、音量、均衡器、播放次數這些元數據是可以自行定義的，而前面的元數據則是可以通過各種方式來獲取到的。

    我在抓取CD的時候，一定會保證iTunes能夠正常的連接到互聯網。讓它通過互聯網替我找到唱片的元數據。并把這些元數據保存在抓取的文件以及曲庫中。我也盡我最大的能力把其余欠缺的元數據補充上（從網上下載的音樂，一般說來，元數據都損失得很大——有的下載站確實太過分了，把所有的元數據都刷成它們的網址）。

3、建立播放列表
    要想時刻找到想聽的音樂，播放列表是必不可少的（尤其對iPod而言）。我機器上建立的播放列表，基本上都是以精選為主（比如On my way、On my way II等），因為我在坐車、船、走路的時候，更多的是聽podcast或者是聽隨機播放。只有在某些嘈雜的場合（比如飛機上或者聽podcast聽累了）或者是不便于操作iPod的時候（比如騎自行車的時候）才會改聽精選。我的精選是我精心的挑的高頻段比較明顯，并且旋律一般都處于高頻段的音樂，這樣可以盡量的避免周圍環境噪音對音樂的干擾，卻可以讓我能夠盡可能的聽清周圍的聲音。

4、建立并保存查詢
    iTunes的查詢能力做得很不錯，而且你可以把查詢作為動態的播放列表保存。這個概念很讓人受用（尤其在音樂的元數據得到良好的維護之后）。我的智能播放列表不多，列舉幾個吧：Ragtime（我的所有風格是Ragtime的音樂列表）、JS Bach By Gould（我的所有由Gould演奏的作曲家為JS Bach的音樂列表）、My Favorite not played since last week（所有我的評價在四星以上并且至少有一周沒有播放過的音樂列表）

5、隨機播放
    對于我來說，我有數千個音樂文件（肯定會有人比我更多，比如我的一個朋友，光CD就數千），天天從中挑想聽的音樂，是一件很乏味的事情，而且會造成過度的挑食。更有趣的是，有時候我都會忘記我有某個專輯。而有的專輯我抓進我的曲庫之后，一次都沒有聽過。而且，不同的時候、不同的情緒，聽不同的音樂也有不同的感覺。

    所以我的策略是一般的情況下，我都是用隨機播放。如果這首歌不喜歡，就給個差評，跳到下一首。讓iTunes來幫我記錄播放次數。這個元數據對我管理音樂和評價音樂也有很高的應用價值。而iPod能夠很好的支持這個元數據。僅為這一點，我就離不開iTunes和iPod了。

6、下載和管理podcast
    聽/看Podcast真是一件讓人上癮的事情。iTunes把Podcast區別對待的方式，是我最舒服的方式（因為我就是用了iTunes后開始聽Podcast的，第一印象永遠是最有力的）。

    我訂閱了二十幾個podcast，到現在只有二百多個文件，而且，podcast的最大特點就是時效性特別強，一般是聽完、看完一遍就刪掉了，所以不存在管理的問題。

7、其他格式的音樂
    iTunes支持播放的音樂格式很少。為了統一的管理所有的音樂，我把所有的其他格式的音樂都轉成了MP3。

8、iPod移動方案
    我的由iTunes管理的音樂（Podcast ＋ 音樂 ＋ iPod能播放的視頻）總共不到20G。裝在我的30G的iPod中綽綽有余。我每次出門都會帶著我所有的音樂。我在使用iPod之前絕對會認為這是不可思議的。

9、備份管理
    我的所有音樂都在我的MacBook里。MacBook是源。我的30G iPod與MacBook完全同步，是第一手備份。我還有一個120G的專有備份移動硬盤（用來備份我的Home文件夾，當然，同時也就備份了音樂、和iTunes元數據——以后會說）是第二手備份。我覺得我有足夠的信心相信這三個設備不會同時壞掉，只要有一個備份，我就能恢復我所有的音樂。我不刻盤，盤刻多了不好管理。而且，光盤更不好保存，不如硬盤——起碼我覺得，當然了，我買不起磁帶機。

回顧到現在，我覺得這么多年來，我仿佛在音樂管理方面沒有任何進步，進步的只是技術。呵呵。

總結一下：

1、我認為，個人的音樂應該統一的交給一個軟件來統一的進行管理 —— 原因，使用和備份都方便。能夠實現一套元數據是最好的
2、音樂應該是隨機的聽的
3、音樂的元數據非常重要，尤其是在你對音樂要求很高或者你的音樂非常多的時候
4、要善用音樂管理軟件的自定義查詢功能，能夠發揮個人的創意就更好了

當然，現在網絡的音樂電臺也是聽音樂的一個非常不錯的選擇。不過極其可惜的是Pandora并不面向大陸開放。而感覺大陸的網絡音樂電臺中我想聽的音樂并不是很多。

我很看好網絡音樂電臺。試想，如果能夠實現網絡 ＋ PC ＋ 手機的無縫結合。保證可以隨時聽到想聽的高質量的音樂，并且系統可以統一的管理所有你相關的音樂的元數據。又可以免去管理、維護音樂文件的煩惱。是多么愜意的事情？

我愿意為這個服務付費，因為我每天都要聽音樂，所以即使是每天10元（也就是每年4K的服務費，我也可以接受——因為我還省去了購買專輯和維護CD的支出）。

posted @ 2008-08-18 12:49 guitarpoet 閱讀(703) | 評論 (0) | 編輯 收藏

關于個人文檔管理

 這幾天開始整理個人文檔。整理的過程中，感覺到有必要把我在個人文檔管理中的一些經驗總結一下。

誠然，一個人的文檔管理風格，跟一個人的性格和能力有很大的關系，跟他的臥室（如果是結婚了的話，那就看辦公室吧）也有很大的關系。:-)

其實，優秀的個人文檔管理的精髓就是能夠在需要的時候找到需要的東西（當然，是自己的東西）。不管你用何種方式，不管你采用何種手段。

首先，我打算區分一下個人電子文檔的類別。

所有的個人電子文檔都可以就需不需要進行變更管理分成兩類：需要進行變更管理的和不需要進行變更管理的。

不需要進行變更管理的最典型例子就是郵件。一旦閱讀完畢，它就變成了歷史，只有查閱和轉發的功能了。各種電子書、電子文檔、媒體文件（音樂、視頻、圖片等）等，它們和電子郵件的情形基本一樣，對一般人來說也都是不需要進行變更管理的。

需要進行變更管理的文檔，我把它們一律稱之為工作文檔。關于工作文檔的管理，我打算在討論完不需要進行變更管理的文檔以后再討論。

那么，不需要進行變更管理的文檔。怎樣進行管理比較好呢？

我先說說我自己的經驗吧。

我把我的不需要進行變更管理的文檔分成5種類型：音樂、視頻、圖片、Email和電子書。

我打算在下一篇的blog里，寫寫我的音樂文件的管理方式。

posted @ 2008-08-17 09:10 guitarpoet 閱讀(1562) | 評論 (2) | 編輯 收藏

關于基于JavaSript的RIA客戶端數據處理（下）

一、引子

上一篇討論了關于客戶端數據處理的一些問題，以簡單的用例場景的方式描述了出來。很明顯，要想實現一個功能完整的Rich客戶端的話，必須能夠滿足上述用例場景的需求。能否根據這些需求做出合理的設計，是一個挑戰。尤其對于設計而言，不同的人有著不同的風格，而且由于背景不同，也會有不同的見解。本文中，我只是陳述出自己的一些想法和設想，更多的是希望能夠拋磚引玉，通過在這個方面的討論也能增進我的理解。呵呵。

很顯然，blog的形式更適合作為思路的介紹以及探討的平臺，而不是詳細設計的文檔。而且很明顯這一篇文章是承載不了所有的詳細設計的。我爭取把我在各個細化的方面的想法在后續的文章里面發出來。如果時間允許的話，整理出初始的文檔和代碼，建立一個小的開源項目未嘗不可（因為如此，所有的JS都是采用英文來注釋──其實還有一個原因是練習英文 :)）。這都是后話了。

二、縮略語

1. RIA：Rich Internet Application的縮寫。RIA是擁有傳統本地應用的功能和效果的Web應用。RIA一般把UI相關的處理交給了Web客戶端，但是大量的數據（包括應用的狀態、數據等）還是交給服務端處理

2. Ajax：又寫為AJAX，是"Asynchronous JavaScript and XML"的縮寫。是一種使用瀏覽器技術進行RIA開發的技術

3. Prototype：開源的優雅的Ajax以及JavaScript基礎擴展框架。由于被Rails采用而聞名，使用相當廣泛
4. jQuery：功能類似Prototype + script.aculo.us的開源Ajax框架。據我所知，Google用得比較多
   
5. Ext：對YUI的一個擴展的UI構件庫。經過改進后，可以使用jQuery或者Prototype作為基礎。目前好像正在完善自身的基礎Ext base。以優秀的構件聞名。雖然目前仍然屬于商業構件庫，但是License相對寬松，一般的商業應用可以免費使用
   

6. dojo：由dojo foundation管理的一個開源JavaScript框架。提供了很好的JavaScript擴展，目前被IBM和Sun等大公司支持和使用

7. Json： JavaScript Object Notation的縮寫。它是一種純文本的數據對象傳輸協議，在Ajax的應用中被廣泛采用

8. CRUD：Create（創建）、Retrieve（獲取）、Update（更新）和Delete（刪除）這四種簡單的數據操作的縮寫

9. Form：本文中的Form指的是經過Ajax擴展的簡單的HTML電子表單。表單內部可以擁有很多如ComboBox、TextBox等構件。一般來說，一個表單對應著一個業務的數據對象

10. Tree：樹形顯示結構化數據的構件，由于數據是高度結構化的，往往可以采用懶加載等技術來提高性能

11. Grid：以表格形式顯示和編輯數據的UI構件。一般分為表頭（標題欄）、表身（數據列表）和表尾（合計、狀態顯示等）三個部分。其中，表頭可以是復合的表頭，而表身可以是復合的格式（Tree、Grid、ComboBox、CheckBox等）。一個Grid可以有一個復雜的Grid定義

12. Enhanced Grid：下面簡稱為EGrid，是Grid的擴展。在Grid的功能基礎之上提供了數據獲取和數據持久化的能力，可以大大的減少開發應用的時間（Ext中的Grid可以認為是一個簡化了的EGrid）

13. CodeList：代碼表，一般用在下拉列表數據處，在系統的實現中，由于性能以及標準的要求，下拉列表一般都是采用代碼保存數據，但是用戶在填寫表單的時候需要看到正常的文字而不是代碼，這就需要系統通過CodeList進行文字和代碼的轉換

14. LRU：Least Recent Used的縮寫，是一種簡單的緩存策略，如果緩存已滿，那么就釋放最近最少使用的那個緩存數據

15. REST：是REpresentational State Transfer的縮寫，是一種基于輕量級WebService協議

16. JDBC：是Java DataBase Connectivity對縮寫，是基于Java的數據庫連接規范。

三、基礎

既然決定采用Ajax，就最好采用一個基礎，在這個有很多優秀的Ajax框架可供選擇的時代，誰要是還要赤手空拳的來寫Ajax應用，就未免有點兒過于勇敢，而近于魯莽了。這篇文章不是Ajax框架對比文章，我不打算在這里一一列舉各個流行的Ajax框架的優缺點，我只拿下面幾個進行討論，dojo、Prototype、jQuery、Ext。

先提需求，框架應該：

1. 以一種形式支持面向對象（畢竟開發人員多數都是Java程序員，更有可能的是，他/她只對Java熟悉）
2. 以一種方式來支持命名空間和分包機制（開發企業應用與開發網站不同，復雜的不是技術而是業務。沒有命名空間和分包支持，對于大型應用，基本不可控制。──設想一下如果Java沒有package關鍵字會怎樣）
3. 有完善的模塊封裝與管理規范或者最佳實踐，能夠自動處理模塊間的依賴則更好（模塊的定義不在這里解釋了，一個例子說明吧，一個Jar就是一個模塊。模塊化和構件化是實現、維護和管理大型應用的重要手段）
4. 提供豐富的調優選項，使得對復雜的應用調優是可能的（這一點對于UI層尤為重要，因為它直接面對使用者）
5. 便于調試（這一點對于開發者致關重要）

綜合上面幾點，我選擇dojo作為基礎。Sorry Prototype。

四、整體構架

整體構架如下圖所示（為了便于理解UI構件與其對關系，我把需要數據處理的UI構件也加了上去，圖中藍背景色的部分就是）：
一目了然，整個客戶端數據處理由3個部分構成，DataSource、DataSet和DataStore。下面分別進行簡單的介紹。

五、DataSet

DataSet的概念很簡單，就是數據對象的集合。它的構架如下圖所示（注意：DataSet只是一套標準的API，可以有不同的實現——比如XML形式的）：

如圖所示，DataSet由四個部分構成，Record Set（數據集合）、Change Tracker（數據變更追蹤）、Meta Data（數據對象源信息）和Cursors（游標API）。

分別介紹如下：

1. Record Set：Record Set就是Record的集合，一個Record就是一個數據對象，它由一系列的屬性（Property）構成，屬性是一個簡單的字符串，其對應的值可以是任意類型。Record提供屬性讀寫的方法，可以直接在Record上對屬性進行讀寫，并且，Record會為寫操作提供一個事件。Record Set內部的元素必須是Record，Record Set支持對內部Record的CRUD操作。并且會有相應的事件觸發
2. Change Tracker：ChangeTracker為DataSet提供所有寫操作的追蹤，可以通過配置選擇Change Tracker是否記錄修改，如果記錄修改，采用的是針對每一個Record記錄增加、刪除以及針對每一個屬性記錄First和Last修改的策略
3. Meta Data：提供DataSet中Record的元數據（屬性名、屬性對應類型、其他自定義數據——校驗、Form Label信息、表頭信息等）以及DataSet的元數據（在全部數據中的位置等）。
4. Cursors：Cursor其實就是Record的迭代器，可以通過對dataset查詢（一般都是非常簡單的filter或者range）得到，推薦通過Cursor進行Record訪問，而不是通過Index，因為通過迭代器訪問Record，DataSet擁有更多的能力。雖然通過Cursor完全可以訪問所有的Record及其中的數據，但是由于DataSet擁有MetaData，所以還是采用DataSet作為數據綁定的主體

DataSet是整個客戶端數據處理構架的核心，所有的數據訪問都應該通過DataSet的API。這樣客戶端的數據處理才是統一的一個整體。

解決的用例問題：

• 數據綁定：Form綁定、Grid綁定
• 數據變更追蹤：Grid變更提示、數據集合變更追蹤、Form修改的追蹤
• 數據訪問：數據對象元數據信息訪問、數據寫操作的統一事件定義、統一的數據讀取方式

六、DataSource

DataSource的功能是提供對數據進行查詢以及數據的持久化（持久化到客戶端或者服務器端）。與DataSet一樣，不同的格式數據就會有不同的DataSource，一種DataSource代表了一種客戶端與服務端的數據傳輸協議。但是由于DataSource的邏輯與結構過于復雜（事實上，DataSet的實現也完全依賴DataSource的實現，可以類比JDBC），不應該對每一種格式都重新實現一個DataSource，由此，DataSource不應該是一套標準的API，而是使用了Adapter模式，來滿足不同的數據來源，其構架如下圖所示：
看上去很簡單？實際上這是最復雜的部分，關于這個部分，至少可以再寫3篇文章來詳細探討，在本文中，就不過度討論了。:)

如圖所示，DataSource由Cache、Query、Persist以及Providers構成，分別介紹如下：

1. Cache：Cache的概念在前面已經闡述了，不在這里多說了。在這里簡單的介紹一下客戶端Cache的策略以及技術，由于基于瀏覽器的數據緩存技術非常重要，擬在后續的文檔《客戶端的緩存策略與相關技術》中對其進行詳細討論
• 緩存策略（這一方面客戶端數據的緩存與服務端的數據緩存考慮的問題應該是類似的，唯一的區別是，客戶端的數據緩存不必考慮集群支持。:)）
• LRU：基礎的Cache算法，如果緩存已滿時，根據最近很少使用算法來確定哪些對象需要被清除
• Priority：按照優先級高低來清理緩存空間的策略，當緩存已滿時，按照優先級高低來確定哪些對象需要被清除，可以與LRU算法共存
• Refreshable：有時效性的數據，或者在運行時有可能會被修改需要同步或者刷新的數據。可以設置數據過期時間，到時間則數據處于stale狀態，再度訪問該數據時，如果不能重新獲得該數據，則報錯
• Expireable：臨時性數據，可以設置失效時間，到時間則數據失效，在緩存需要清理時，緩存會清理掉這些失效的對象
• 緩存持久化（屬于高級的緩存策略，依賴客戶端基于JavaScript的數據存儲技術）
• Save（持久化）：把緩存當中的數據持久化到本地或者服務端，其用處如下
• 通過把數據持久化可以增加Cache的容量
• 數據本地緩存提供了離線表單填寫的能力
• Retrieve、Delete：對緩存中數據的基本操作
• Sync：離線緩存的本地數據，可以與遠程服務端進行同步，從而實現離線表單提交以及實現離線CodeList等功能
• 緩存技術
• Client
• 內存引用
• Cookie
  
• Google Gear
• Server（服務端協助客戶端做一些緩存，這在傳統的B/S下是匪夷所思的設計，在RIA的情況下卻未嘗不是一種手段）
• WebService或者REST
• Post + Get
2. Query：其實Query只是一個方法，由于有可能會向服務端發XmlHttpRequest，所以這個方法需要回調方法。其參數應該是一個Query對象，一個配置對象，有一些事件的關鍵字（onBegin、onError、onSuccess等）。Query對象以及配置對象的格式在本文中就不詳細說明了，留給以后慢慢說（因為這個部分是我最喜歡的部分）。很明顯，如果查詢成功，查詢的結果應該是DataSet，一般來說，DataSource是DataSet來源。不同的DataSource，查詢的語言未必相同。不一定所有的查詢對象都支持SQL語法（比如可以支持HQL或者XQuery啊），而且我最推薦采用的是服務端提供一個服務抽象層，接受Json格式的查詢請求，并返回Json格式的數據
3. Persist：數據持久化。只是Save和Update兩個方法。接受DataSet和配置對象作為參數（這兩個方法也應該是異步的）。如果DataSet里面沒有足夠的元數據信息，需要在配置對象里面提供這些信息。這個部分不比Query部分復雜
4. Providers：數據的來源，提供了Query和Persist API的實現，是DataSource的底層實現，它使DataSource的實現可以跨不同協議而使用。給DataSource提供不同的Provider，DataSource就可以支持不同的數據傳輸協議。

DataSource是數據查詢和持久化的核心，所有的客戶端的數據查詢和持久化基本都應該采用DataSource，從而獲得DataSource提供的強大而靈活的特性。

解決的用例問題：

• 數據緩存：離線運行的CodeList、離線表單填寫、性能考慮
• 數據查詢：樣本查詢、模糊查詢、Range查詢、邏輯查詢、自定義查詢
• 數據處理：數據處理事件、過濾、排序

七、DataStore

DataStore基于DataSource和DataSet的實現，實現了dojo的data api。這樣既實現了對需要dojo api的dojo構件的支持，又滿足了類似Tree、EGrid這種既需要綁定又需要數據來源的高級構件的要求。總體來說，DataStore只是薄薄的一層接口，實際的實現完全依賴于DataSource。

解決的用例問題：

• 數據綁定、查詢、處理：Tree綁定、ComboBox數據源、EGrid綁定

八、待討論的問題

客戶端的數據處理事實上要比我想象得還要復雜，我還有一些設計決策沒有確定，列舉下來以供討論吧。

8.1 客戶端的事務處理？

由于很多數據處理都放在了客戶端。客戶端的數據處理操作相應增多而且復雜，是否應該在DataSource中添加寫事務的處理？以便對數據操作進行更細粒度的管理，而不是僅僅停留在Query、Save和Track階段？

8.2 權限數據的來源

如果可以連接到服務端，用戶在向服務端登錄后，服務端會返回用戶的權限信息列表。客戶端接收后，可以相應的提供權限控制。但是，如果客戶端離線運行，用戶無法向服務的登錄，權限信息列表無從獲得，怎么提供權限控制？

探討方案1：離線客戶端無須登錄，由于沒有權限控制列表，默認擁有系統最低權限（固定的配置在客戶端），由系統開發人員決定用戶在離線時可以進行何種操作。用戶在線提交數據的時候，服務端也要根據相應的權限進行驗證以防止越權的數據操作

探討方案2：離線客戶端仍須登錄，權限控制列表使用用戶在線登錄時緩存的數據。其余與在線方式相同。如果用戶沒有在線登錄過，那么離線應用無法使用。

8.3 跨域數據的來源

由于瀏覽器的安全性策略，JavaScript無法向除本身域之外的其他服務器發送請求。也就是說，對于JavaScript而言，所有的數據必須來源于同一個域的服務器。對客戶端進行集成非常不利。

探討方案1：服務端提供一個服務接入層，接受如Spring Bean、EJB、JMS、WebService等形式的服務，并且把所有的服務都轉化成為一種固定格式的協議與客戶端交互。所有的服務集成與協議轉化都交給服務端，對客戶端完全透明。

探討方案2：服務端提供一個簡單的Proxy，通過一定的協議把請求和回復轉發給客戶端，處理交給客戶端來做

九、小結

雖然到了這里，但是對于基于JavaScript的RIA客戶端數據處理的討論卻才剛剛開始，還需要很多后續的展開討論。但是，上午已經過去了，需要去吃午飯了。:)

posted @ 2007-12-15 13:15 guitarpoet 閱讀(1438) | 評論 (2) | 編輯 收藏