2008年9月1日 #

关于个人文档管理－电子书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 阅读(541) | 评论 (0) | 编辑收藏

2008年8月31日 #

关于个人文档管理－电子书

作为一个软件开发人员。电子书、文档基本上是每天都要看的。手头都会有一些电子文档或者电子书。

管理好这些电子书，却远比想象得要复杂得多。为什么呢？因为它涉及到了书。它不仅仅是简单的文档管理，而是个人的学习资料、知识管理。我们来分析一下吧。

一般而言，根据个人的查看方式，电子书可以分成这么几类。

1、有些书下载了，却未必会看

由于下载的方便性，以及电子文档的特殊性，使人容易忽略电子书的信息量。

很多电子书，同样的信息量，换成纸质文档，书本的大小就会让很多人望而却步。但是，变成电子文档后，使很多人忘记了这一点。

只是觉得可能会有用，就下载下来了。其实根本就不会去看。又舍不得删掉，成了电子垃圾（不要跟我说有什么收藏价值，那是自己安慰自己罢了，没人看的电子书就是电子垃圾）。

2、有些书需要反复的看

有一些书（比如设计模式），是典型的手册型书。你会发现，你可能会经常性的

而且，往往会有一些书值得反复阅读，或者用来当作手册来时常查阅。

3、有些书看一遍就可以扔掉了

重构就是这种类型，不是说这本书不好。而是你看完了之后，你就理解了它的思想。在日常的工作中，你会经常的遇到这些问题，使用这些方法。你不会忘记它的教诲了，因为它已经成为了你工作的一部分了。这种书可以比喻成电器的说明书，一般你只在刚刚买到的时候看一下，之后就扔到一边去了。

还可以从另外一个方面来看，就是信息量的方面，电子书可以分成下面几类

1、大信息量型

有的书的内容有很大的信息量（比如存粹理性批判），需要采用精读甚至反复读的方式来进行理解和消化。往往每天只能读和消化几页（有的时候几页就不错了）。

2、中等信息量型

一般的技术文章或者刊物、书籍，都属于这种类型。这种书籍的阅读效果最好。Martin Fowler深谙此道。写的书往往比较易读。

3、低信息量型

比较差的技术类书籍属于此等类型。篇幅很大，但是有价值的内容乏善可陈。或者供娱乐使用的书。比如某些网络小说。

通过这两个分类，可以通过一个表格把电子书分类。

反复看看一遍未必看

==========================

大|经典教材、经典难懂的书

中|手册普通的书别人推荐的书

小|喜欢的消遣骗人的书

没把大部头加上去，因为大部头的定义不是很清晰。

好了，总结一下。

我们可以按照书的信息量和自己是否看把自己的书分成下面几个分类：

经典、手册、喜欢的、教材、普通的书、消遣、难懂的书、别人推荐的书、骗人的书

下一篇文章，我就会针对这些分类开始讨论电子书的管理方式。

PS：当然，这这是我的分类。你可以有其他更好的分类方式。

posted @ 2008-08-31 17:46 guitarpoet 阅读(901) | 评论 (2) | 编辑收藏

2008年8月25日 #

关于个人文档管理 - 电子邮件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 阅读(369) | 评论 (0) | 编辑收藏

2008年8月24日 #

关于个人文档管理 - 电子邮件

好吧，我承认，我的上一篇文章没有提到跟电子邮件管理相关的事情。呵呵。

无论你使用什么邮件客户端（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 阅读(583) | 评论 (0) | 编辑收藏

2008年8月22日 #

关于电子邮件

关于电子邮件

好了，今天来讨论电子邮件。

电子邮件是非常优雅和浪漫的交流方式——邮件的电子表示方式。它拥有前辈的很多优点，在某些方面上甚至超出了前辈。

但是，你虽然可以把信纸换成薰衣草的颜色，你却无论如何也无法发出有薰衣草香气的信来。有时候，歪歪扭扭的手写字，要比你选择的任何字体都能代表你的心意。——你休想拿电子邮件写出完美的情书来。呵呵。

好了，言归正传，我们先列举一下电子邮件的特性吧。

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 阅读(461) | 评论 (0) | 编辑收藏

2008年8月19日 #

关于个人文档管理－图片和视频文件

昨天又写了一篇又臭又长的文章。从今天起，篇幅力图达到短小精悍。

我不是一个摄影爱好者（所以到现在还没有数码相机），也不是一个很爱拍照的人。我自己拍得最多的就是每周一次用笔记本拍的减肥效果记录。

由于电影一般看完就删、很多音乐视频都可以在网上看，而我又不爱看电视节目，所以我的视频简直屈指可数。

视频和图片的最大的特点就是它们都是大把吃掉硬盘的怪物。举例来说，一个SRV的Live from Austin Texas就吃掉了我700M的硬盘。我的工作区中所有的文档大小的总和都不及它的一半。

我对待视频的策略，仍然是我用的最熟的大抽屉策略：最常看的和马上要看的视频（比如最新的电影），放到Movies文件夹中。其他需要保留的经典，刻盘保存（太大了，装它们移动硬盘吃不消）。

由于我再看它们的可能性不是非常的大，所以刻盘保存的风险我可以接受。

我使用iPhoto来管理我的图片。用iPhoto来管理相片的体验，和用iTunes管理音乐差不多。只不过播放列表变成了相册。我自定义了一个关键字“减肥日记“（开始是想每天照，可是我实在太懒，呵呵），我每周拍的减肥效果记录都会加上这个关键字。在这个基础上，我建立了一个查询，列出所有关键字为”减肥日记“的相片。这样，我的减肥效果就可以一目了然了。哈哈。

总结一下：

1、视频由于体积大，收看次数较少。可以考虑采用刻盘归档的方式。但是一定要预留一些空间使用大抽屉原则（常用的东西放到最容易找到的地方）。在使用刻盘保存的时候，一定要考虑为所有的光盘建立可供检索和查询的索引（光盘的编号、光盘的内容、光盘的存档时间）。对于个人而言，这些只要一个Excel表格足矣，不需要什么额外的软件。
2、图片的管理方案与音乐异曲同工。因为除了媒介和使用方式有所不同外。二者的根本都是大的二进制文件＋围绕这个文件的一系列元数据。而且，与音乐一样图片数据的备份和查看也被iPod很好的支持。

关于我的图片和视频的管理方式，就到这里吧。下一篇需要讨论的，是对工作非常重要的，电子邮件的管理。由于它太重要了，而且涉及到的技巧也太多了（很多人都有很优秀的经验）。如果一篇写不完，可以考虑多写几篇。:-)

posted @ 2008-08-19 09:32 guitarpoet 阅读(1162) | 评论 (2) | 编辑收藏

2008年8月18日 #

关于个人文档管理 — 个人音乐管理

好了，接着昨天的话题，说一下我的音乐文件管理。

托生在中国的福，我只花了很少的代价，就听到了很多高质量的音乐（谁都知道是怎么回事，呵呵）。

对于我这种须臾离不开音乐的人来说。找到自己今天、现在想听的音乐。并不是一件非常容易的事情。

说起个人的音乐管理，我打算从革命的传家史开始。

我的音乐管理可以分为下面几个阶段。

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 阅读(686) | 评论 (0) | 编辑收藏

2008年8月17日 #

关于个人文档管理

这几天开始整理个人文档。整理的过程中，感觉到有必要把我在个人文档管理中的一些经验总结一下。

诚然，一个人的文档管理风格，跟一个人的性格和能力有很大的关系，跟他的卧室（如果是结婚了的话，那就看办公室吧）也有很大的关系。:-)

其实，优秀的个人文档管理的精髓就是能够在需要的时候找到需要的东西（当然，是自己的东西）。不管你用何种方式，不管你采用何种手段。

首先，我打算区分一下个人电子文档的类别。

所有的个人电子文档都可以就需不需要进行变更管理分成两类：需要进行变更管理的和不需要进行变更管理的。

不需要进行变更管理的最典型例子就是邮件。一旦阅读完毕，它就变成了历史，只有查阅和转发的功能了。各种电子书、电子文档、媒体文件（音乐、视频、图片等）等，它们和电子邮件的情形基本一样，对一般人来说也都是不需要进行变更管理的。

需要进行变更管理的文档，我把它们一律称之为工作文档。关于工作文档的管理，我打算在讨论完不需要进行变更管理的文档以后再讨论。

那么，不需要进行变更管理的文档。怎样进行管理比较好呢？

我先说说我自己的经验吧。

我把我的不需要进行变更管理的文档分成5种类型：音乐、视频、图片、Email和电子书。

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

posted @ 2008-08-17 09:10 guitarpoet 阅读(1550) | 评论 (2) | 编辑收藏

2007年12月15日 #

关于基于JavaSript的RIA客户端数据处理（下）

一、引子

上一篇讨论了关于客户端数据处理的一些问题，以简单的用例场景的方式描述了出来。很明显，要想实现一个功能完整的Rich客户端的话，必须能够满足上述用例场景的需求。能否根据这些需求做出合理的设计，是一个挑战。尤其对于设计而言，不同的人有着不同的风格，而且由于背景不同，也会有不同的见解。本文中，我只是陈述出自己的一些想法和设想，更多的是希望能够抛砖引玉，通过在这个方面的讨论也能增进我的理解。呵呵。

很显然，blog的形式更适合作为思路的介绍以及探讨的平台，而不是详细设计的文档。而且很明显这一篇文章是承载不了所有的详细设计的。我争取把我在各个细化的方面的想法在后续的文章里面发出来。如果时间允许的话，整理出初始的文档和代码，建立一个小的开源项目未尝不可（因为如此，所有的JS都是采用英文来注释──其实还有一个原因是练习英文 :)）。这都是后话了。

二、缩略语

RIA：Rich Internet Application的缩写。RIA是拥有传统本地应用的功能和效果的Web应用。RIA一般把UI相关的处理交给了Web客户端，但是大量的数据（包括应用的状态、数据等）还是交给服务端处理
Ajax：又写为AJAX，是"Asynchronous JavaScript and XML"的缩写。是一种使用浏览器技术进行RIA开发的技术
Prototype：开源的优雅的Ajax以及JavaScript基础扩展框架。由于被Rails采用而闻名，使用相当广泛
jQuery：功能类似Prototype + script.aculo.us的开源Ajax框架。据我所知，Google用得比较多
Ext：对YUI的一个扩展的UI构件库。经过改进后，可以使用jQuery或者Prototype作为基础。目前好像正在完善自身的基础Ext base。以优秀的构件闻名。虽然目前仍然属于商业构件库，但是License相对宽松，一般的商业应用可以免费使用
dojo：由dojo foundation管理的一个开源JavaScript框架。提供了很好的JavaScript扩展，目前被IBM和Sun等大公司支持和使用
Json： JavaScript Object Notation的缩写。它是一种纯文本的数据对象传输协议，在Ajax的应用中被广泛采用
CRUD：Create（创建）、Retrieve（获取）、Update（更新）和Delete（删除）这四种简单的数据操作的缩写
Form：本文中的Form指的是经过Ajax扩展的简单的HTML电子表单。表单内部可以拥有很多如ComboBox、TextBox等构件。一般来说，一个表单对应着一个业务的数据对象
Tree：树形显示结构化数据的构件，由于数据是高度结构化的，往往可以采用懒加载等技术来提高性能
Grid：以表格形式显示和编辑数据的UI构件。一般分为表头（标题栏）、表身（数据列表）和表尾（合计、状态显示等）三个部分。其中，表头可以是复合的表头，而表身可以是复合的格式（Tree、Grid、ComboBox、CheckBox等）。一个Grid可以有一个复杂的Grid定义
Enhanced Grid：下面简称为EGrid，是Grid的扩展。在Grid的功能基础之上提供了数据获取和数据持久化的能力，可以大大的减少开发应用的时间（Ext中的Grid可以认为是一个简化了的EGrid）
CodeList：代码表，一般用在下拉列表数据处，在系统的实现中，由于性能以及标准的要求，下拉列表一般都是采用代码保存数据，但是用户在填写表单的时候需要看到正常的文字而不是代码，这就需要系统通过CodeList进行文字和代码的转换
LRU：Least Recent Used的缩写，是一种简单的缓存策略，如果缓存已满，那么就释放最近最少使用的那个缓存数据
REST：是REpresentational State Transfer的缩写，是一种基于轻量级WebService协议
JDBC：是Java DataBase Connectivity对缩写，是基于Java的数据库连接规范。

三、基础

既然决定采用Ajax，就最好采用一个基础，在这个有很多优秀的Ajax框架可供选择的时代，谁要是还要赤手空拳的来写Ajax应用，就未免有点儿过于勇敢，而近于鲁莽了。这篇文章不是Ajax框架对比文章，我不打算在这里一一列举各个流行的Ajax框架的优缺点，我只拿下面几个进行讨论，dojo、Prototype、jQuery、Ext。

先提需求，框架应该：

以一种形式支持面向对象（毕竟开发人员多数都是Java程序员，更有可能的是，他/她只对Java熟悉）
以一种方式来支持命名空间和分包机制（开发企业应用与开发网站不同，复杂的不是技术而是业务。没有命名空间和分包支持，对于大型应用，基本不可控制。──设想一下如果Java没有package关键字会怎样）
有完善的模块封装与管理规范或者最佳实践，能够自动处理模块间的依赖则更好（模块的定义不在这里解释了，一个例子说明吧，一个Jar就是一个模块。模块化和构件化是实现、维护和管理大型应用的重要手段）
提供丰富的调优选项，使得对复杂的应用调优是可能的（这一点对于UI层尤为重要，因为它直接面对使用者）
便于调试（这一点对于开发者致关重要）

综合上面几点，我选择dojo作为基础。Sorry Prototype。

四、整体构架

整体构架如下图所示（为了便于理解UI构件与其对关系，我把需要数据处理的UI构件也加了上去，图中蓝背景色的部分就是）：

一目了然，整个客户端数据处理由3个部分构成，DataSource、DataSet和DataStore。下面分别进行简单的介绍。

五、DataSet

DataSet的概念很简单，就是数据对象的集合。它的构架如下图所示（注意：DataSet只是一套标准的API，可以有不同的实现——比如XML形式的）：

如图所示，DataSet由四个部分构成，Record Set（数据集合）、Change Tracker（数据变更追踪）、Meta Data（数据对象源信息）和Cursors（游标API）。

分别介绍如下：

Record Set：Record Set就是Record的集合，一个Record就是一个数据对象，它由一系列的属性（Property）构成，属性是一个简单的字符串，其对应的值可以是任意类型。Record提供属性读写的方法，可以直接在Record上对属性进行读写，并且，Record会为写操作提供一个事件。Record Set内部的元素必须是Record，Record Set支持对内部Record的CRUD操作。并且会有相应的事件触发
Change Tracker：ChangeTracker为DataSet提供所有写操作的追踪，可以通过配置选择Change Tracker是否记录修改，如果记录修改，采用的是针对每一个Record记录增加、删除以及针对每一个属性记录First和Last修改的策略
Meta Data：提供DataSet中Record的元数据（属性名、属性对应类型、其他自定义数据——校验、Form Label信息、表头信息等）以及DataSet的元数据（在全部数据中的位置等）。
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构成，分别介绍如下：

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

Query：其实Query只是一个方法，由于有可能会向服务端发XmlHttpRequest，所以这个方法需要回调方法。其参数应该是一个Query对象，一个配置对象，有一些事件的关键字（onBegin、onError、onSuccess等）。Query对象以及配置对象的格式在本文中就不详细说明了，留给以后慢慢说（因为这个部分是我最喜欢的部分）。很明显，如果查询成功，查询的结果应该是DataSet，一般来说，DataSource是DataSet来源。不同的DataSource，查询的语言未必相同。不一定所有的查询对象都支持SQL语法（比如可以支持HQL或者XQuery啊），而且我最推荐采用的是服务端提供一个服务抽象层，接受Json格式的查询请求，并返回Json格式的数据
Persist：数据持久化。只是Save和Update两个方法。接受DataSet和配置对象作为参数（这两个方法也应该是异步的）。如果DataSet里面没有足够的元数据信息，需要在配置对象里面提供这些信息。这个部分不比Query部分复杂
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 阅读(1420) | 评论 (2) | 编辑收藏

2007年12月8日 #

关于基于JavaSript的RIA客户端数据处理（上）

一、引子

这个blog已经荒废将近一年了，久也不写，自然有很多的理由，但更多的怕是懒吧。不说闲话了，转入正题。

关于基于JavaScript的RIA客户端数据处理这个话题，我打算分成两篇文章来写，一篇陈述我所总结出的基于B/S结构的RIA客户端数据处理的问题，另一篇则陈述针对这些问题我所提出的技术解决方案构架。

二、RIA？RIA！

关于RIA尤其是基于Ajax的RIA怕是屡见不鲜了吧？尤其是在Google推手之后，文字处理、表格处理、幻灯片放映这种看起来非常客户端的应用，都可以采用Ajax的技术来实现了。作为一个关注企业级应用开发的技术人员，一个很自然的想法就会产生，是否可以采用这种技术来改进我们基于Java EE技术开发的B/S结构的企业应用呢？

先说有没有必要，答案是肯定的。B/S被广为诟病的一个问题就是降低了最终用户的操作效率，以我的经验来说，用户虽然普遍的感到基于浏览器的界面要漂亮得多，用鼠标操作也很直观，但是却实在比以前的界面复杂而且操作困难。而且每次页面提交后的等待也实在是对工作效率的一个降低。当然，我这里也没有必要意义列举B/S在客户端的缺点，实际上这个问题是被广泛认同的。

再说可行性，可行性分为两种：技术上的可行性以及工程开发上的可行性。

技术上的可行性就无须验证了，Google Reader、Gmail、Google Docs的稳定运行都是非常好的证明。

但是它是否一定适合时间要求相对比较严格的工程开发呢？

这就需要一个非常稳定的平台来进行支持，而且由于工程开发的特殊性，最好还要有可视化的开发和调试环境才更有说服力。目前看来是没有非常完善的，但是很多的Ajax框架，如Ext、GWT、Tibco GI以及服务端框架Struts2、JSF等，都在以自己的方式实现着。关于这个方面的探讨我打算放到下一个系列《基于MDA的企业应用RIA解决方案》里面讨论，不在这里多费口舌了。

技术上是可行的，而如果又一个非常稳定和成熟的平台支持的话，在工程开发上也是可行的，那么这个平台怎样才算是稳定和成熟的呢？本系列讨论的就是其中的一部分，客户端的数据处理。

三、定义、缩略语

下面是本文中使用的技术名词的定义以及缩略语简介。

RIA：Rich Internet Application的缩写。RIA是拥有传统本地应用的功能和效果的Web应用。RIA一般把UI相关的处理交给了Web客户端，但是大量的数据（包括应用的状态、数据等）还是交给服务端处理
Ajax：又写为AJAX，是"Asynchronous JavaScript and XML"的缩写。是一种使用浏览器技术进行RIA开发的技术
ECMA Script：由European Computer Manufacturers Association（欧洲计算机制造商协会）维护的一个脚本语言标准。当前最通行的版本是ECMA-262 Edition 3，通常也被称为JavaScript 1.5
dojo：由dojo foundation管理的一个开源JavaScript框架。提供了很好的JavaScript扩展，目前被IBM和Sun等大公司支持和使用
Json： JavaScript Object Notation的缩写。它是一种纯文本的数据对象传输协议，在Ajax的应用中被广泛采用
CRUD：Create（创建）、Retrieve（获取）、Update（更新）和Delete（删除）这四种简单的数据操作的缩写
Form：本文中的Form指的是经过Ajax扩展的简单的HTML电子表单。表单内部可以拥有很多如ComboBox、TextBox等构件。一般来说，一个表单对应着一个业务的数据对象
Tree：树形显示结构化数据的构件，由于数据是高度结构化的，往往可以采用懒加载等技术来提高性能
Grid：以表格形式显示和编辑数据的UI构件。一般分为表头（标题栏）、表身（数据列表）和表尾（合计、状态显示等）三个部分。其中，表头可以是复合的表头，而表身可以是复合的格式（Tree、Grid、ComboBox、CheckBox等）。一个Grid可以有一个复杂的Grid定义
Enhanced Grid：下面简称为EGrid，是Grid的扩展。在Grid的功能基础之上提供了数据获取和数据持久化的能力，可以大大的减少开发应用的时间（Ext中的Grid可以认为是一个简化了的EGrid）
CodeList：代码表，一般用在下拉列表数据处，在系统的实现中，由于性能以及标准的要求，下拉列表一般都是采用代码保存数据，但是用户在填写表单的时候需要看到正常的文字而不是代码，这就需要系统通过CodeList进行文字和代码的转换
LRU：Least Recent Used的缩写，是一种简单的缓存策略，如果缓存已满，那么就释放最近最少使用的那个缓存数据
REST：是REpresentational State Transfer的缩写，是一种基于轻量级WebService协议

四、客户端数据处理的技术场景

在本部分里将会针对下面六个分类对客户端数据处理的技术场景进行概述

数据绑定（Data Binding）
数据变更追踪（Data Change Tracking）
数据访问（Data Access）
数据缓存（Data Caching）
数据查询（Data Query）
数据处理（Data Processing）

4.1 数据绑定（Data Binding）

概念：

以非常简单的声明方式实现Form、Grid这种数据填写、修改构件与数据之间的对应关系。

场景：

Form绑定：把一个Form与一个数据对象通过声明的方式绑定，使得Form的修改直接可以体现在数据对象中，而数据对象的修改也可以马上由Form体现出来
Grid绑定：把一个Grid和一个数据对象集合通过声明或者设置数据源的方式绑定，使得在Grid上的写操作都可以体现在数据对象集合中，而数据对象集合的操作也可以马上由Grid构件体现出来
Tree绑定：由于Tree的特殊性，与其说Tree与一个数据对象集合绑定，不如说Tree使用了一个可以根据查询提供数据的数据来源更合适。当然，由于Tree有可能被可视化的修改（如组织机构管理），所以这个数据来源必须支持对数据的写操作
其它：如菜单的绑定等，相对于上述三个都属于非常用的绑定，而且如果上述绑定能够实现，那么其他的绑定也可以采用同样的技术实现

4.2 数据变更追踪（Data Change Tracking）

概念：

对数据的整个生命周期进行追踪。主要的目的就是可以通过记录看出数据做了哪些改变，然后根据这些改变做出相应的处理，其使用场景有Grid的变更提示、Form修改的追踪等。

场景：

Grid变更提示：在Grid中以明显的方式提示用户做了哪些修改
数据集合变更追踪：根据变更的效果，可以有选择的发送合适的数据给服务端进行处理
Form修改的追踪：为用户在提交Form时提示用户哪些重要的字段进行了修改提供支持

4.3 数据访问（Data Access）

概念：

服务端与客户端数据传输的格式未必相同，而且数据对象属性的类型等信息也需要一些Meta Data API来进行支持。所以，抽象出一个抽象的拥有Meta Data的数据访问层是有意义的。

场景：

数据对象元数据信息访问：可以通过这些元数据信息了解数据对象的各个属性以及对应的数据类型（这一点对于Json格式的数据传输尤其重要，因为Json规范里面没有DateTime类型）
数据写操作的统一事件定义：通过Data Access API来访问数据，所有的写操作都会有统一的事件定义，在JavaScript 1.5中，普通的JavaScript对象是做不到的
统一的数据读取方式：不管数据是XML格式的还是Json格式的，访问数据的方式都是统一的

4.4 数据缓存（Data Caching）

概念：

数据缓存是指把获得的数据以一定的策略缓存起来，以备使用的技术。Cache是客户端数据处理中涉及到功能和性能的重要部分，原因请见下面的场景

场景：

离线运行的CodeList：系统如果需要离线运行，那么CodeList肯定需要客户端缓存
离线表单填写：如果允许用户离线填写表单，那么需要采用客户端缓存策略保存用户的数据
性能考虑：向服务端发请求，服务端查询并返回属于非常耗费资源和时间的操作，所以对于服务端的数据，客户端应该有一定的缓存以及同步策略

4.5 数据查询（Data Query）

概念：

数据查询的概念非常简单，根据用户的查询条件向服务端发送查询请求，得到服务端返回的数据对象集合。

但由于数据查询是系统中最常用的功能，所以，数据查询需要非常强大的功能。简单列举如下。

场景：

样本查询：给出一个样本，比如{age : 20, gender : 'male'}，返回所有符合样本的结果
模糊查询：用户可以提供非明确的查询参数（如李？？，查询所有姓李的，名字为三个字的人），返回结果供用户进一步的筛选
Range查询：根据Start Index和Count返回整个大数据集中的一部分，一般用在分页查询处理方面，当然也可以用在其他的需要整个数据集的一部分的地方
逻辑查询：采用逻辑操作对数据进行过滤查询，比如（employee中所有满足age < 40 && age >30 && gender = ‘male’ && married条件的员工——年龄大于30且小于40的已婚男员工），实际上上面所说的查询都可以以某种方式归为逻辑查询的一种，之所以明确的提出来，是因为查询的语法有可能有所不同，并且有些构件或者服务会对某些查询有特别的需求或者加强的支持以简化开发的难度，提高开发的效率
自定义查询：根据用户的需要可以对上面的查询进行有机地结合