可以访问：本文镜像。
为什么要用 VimWiki
个人 Wiki 个性化的程度比较严重，所以千挑万选总也找不到好用的。Vim 虽然学习成本很高，但是我想既然已经到使用个人 Wiki 了，应该不会在乎这点投资。
Wiki 形式的文档好处在于易于写作，纯文本的管理，即使是源文件也有很强的可读性，可以方便地导出规范的 HTML 文件。
Wiki 的格式也很多，比如 Markdown，reStructuredText 等等，这都被称作 Lightweight markup language，在这个维基词条上也有些简单的对比。Travis 的主页有文章对这些做了总结（文章提到，选择太多，很难总结完善）。我个人依照我的喜好选择了 Google Code Wiki，其实我也觉得，如果不是写书，其实哪种 Wiki 形式都一样，重要的是开始写，选一个喜欢的语法和实现，并且保证用的人比较多的就行。
说了半天还没有介绍 VimWiki，它是一个 Vim 的开源插件，采用类似 Google Code Wiki 的语法，所有的文档组织就是利用 Wiki 格式的纯文本。结合 Dropbox 可以轻松实现同步。我觉得 Wiki 就不用版本控制了，简单在文中标注下必要的更新说明就是。
Quick Start
为了快速上手，下面各种操作不多做解释，官方文档能提供所有的解答，也有中文文档。另外，这个软件的更新较快，网上的一些设置介绍可能过时，需要及时查阅官方的文档。
下载安装
方法一：下载 .vba 是 Vimball 的安装文件，打开后使用 :so % 即可。
方法二：也可以直接使用 zip 文件，解压复制到相应路径。
注意：Vim 中涉及到的路径最好不要含有比较特殊的字符（比如空格，括号等），以免出现各种错误。
配置 vimrc
安装官方文档的要求，需要确保 vimrc 文件中有如下的设置：
set nocompatible
filetype plugin on
syntax on
另外就是要设置个人 Wiki 库的存放地址和 HTML 模板：
let g:vimwiki_list = [{'path': 'D:\Link\Wiki\wiki\',
\ 'path_html': 'D:\Link\Wiki\html\',
\ 'template_path': 'D:\Link\Wiki\templates\',
\ 'template_default': 'def_template',
\ 'template_ext': '.html',
\ 'css_name': '',
\ 'auto_export': 1,
\ 'diary_link_count': 5}]
注意到有关模板我使用的是 Dev (2010-12-27) 版本，所以和当前的 1.1.1 的设置有所不同。 因为 VimWiki 可以定义 css，所以有一个 css_name 的设置，应该是保存在文档中定义的 css（不确定）。
使用
这部分请看VimWiki 介绍中第二节。
在 Vim 中，键入 <leader>ww 三个键即可进入第一个 Wiki 库的首页（index.wiki）。其中 <leader> 一般是 \ 字符。
在首页中就可以随意输入了，使用类似 NewPage 之类的驼峰词可以创建新页面。如果需要创建中文词条可以使用： [[中文]] 或者 [[文件名|中文描述]] 的方法。
<tab> 和 <shift> + <tab> 键可以在词条之间跳转，<enter> 可以进入词条进行编辑，<backspace> 可以返回。注意到，通常情况下 VimWiki 会自动存盘。
使用 :Vimwiki2HTML 和 :VimwikiAll2HLML 可以导出 HTML 格式的网页。
Tips
- 可配置多个 Wiki 库。访问第二个 Wiki 库可以键入 2<leader>ww，或者通过 <leader>ws 进行选择。
-
Wiki 中的 CamelCase 会自动转换为 link，按 <enter> 即可进入编辑，按 <backspace> 回到前一页。
" 不需要驼峰英文成为维基词条 let g:vimwiki_camel_case = 0
- 可以设置在存档后自动更新 HTML 文件，在 vimwiki_list 中的 auto_export 属性。
-
可以建立 to-do list，只不过默认的快捷键 <C-space> 和中文输入法切换的热键冲突，可以重新映射。比如下面映射成 <leader>tt，
:map <leader>tt <Plug>VimwikiToggleListItem
- 方便的日记功能，使用 <leader>w<leader>w 就可以开启一个以今天日期命名的 diay page，还可以结合 Calendar 插件，以日历形式显示日记。
发布
通过 HTML 模板，可以把 VimWiki 当做 Blog 和个人 Wiki 的发布工具使用，而且文档编辑简单，内容和样式分离，非常省心。 目前一个选择是使用 github 的 Pages feature。本来 github 是代码托管服务，但是允许作者发布静态的网页作为主页。
对此不再赘述，可以参考：
有的时候需要在局域网内调试 GAE 的程序，比如调试手机应用程序的时候，需要通过 WiFi 访问应用程序。
默认的 dev_appserver 使用的地址是 localhost，如果需要其他计算机也能访问，则需要再启动的时候加入参数 --address= ... 设置服务器的主机地址，使用 0.0.0.0 则允许本地主机访问和主机名访问。参见：The Python Development Server: Command-Line Arguments。
如果使用的是 GAE Launcher，则是在 Application Settings 中在 Extra Command Line Flags 中加入：
-a 0.0.0.0
本文的经验建立在理科专业并使用 LaTeX 的基础上。文献管理的软件和服务很多，我没有用过此类的收费软件，免费的也没有全部仔细试用。因为这类软件或服务的个性化太强，很难找到一个能完全符合我的喜好。本文可以当做一个对最知名的免费的文献管理软件和服务的简要介绍和主观评价。
首先是我个人的偏好：
- 不能处理中文虽然不好，但是无所谓。
- 如果带有自动获取题录的功能，最好能指定来源，获取准确和全面。
- 理想中的情况是在有多个数据来源的情况下，可以供用户选择较优的。
- 只要支持 BibTeX 就行。
- 社会化功能无所谓。
- 注释功能无所谓。
- 能否自动获取全文无所谓。
在线的文献管理服务：
- CiteULike：Richard Cameron 编写的文献管理服务。个人感觉比较好，支持网站众多，支持 tag，导入和导出都比较方便，分享功能也很完善。可以从 CrossRef 更新数据，并且提示哪些条目更改了。只不过操作不是很方便，批量处理比较麻烦。 或许研究下 API 比较好。
- Connotea： 后台是 Nature 出版集团，当然这个也说明不了什么，因为 Elsevier 旗下的 2collab 就停止服务了。Connotea 要求文献来源必须提供 URI、DOI、PMID、ASIN 这类索引性信息，但是比如早期的期刊文献并没有 DOI 数据。这对其所能管理的文献有很大的限制。
- 新科学：国内的服务，用的人不多，但是功能还不错，对于国内的数据库的文献导入支持得比较好。
注：CrossRef 的信息也不全是正确的，作者名称通常只是简称。此外使用 CrossRef 搜索题录应该是收费的，虽然可以利用 CiteULike 的数据吧...
完全本地的文献管理软件：
- JabRef：开源。只能管理 BibTeX 格式，需要 Java 运行环境，界面不好看。但这是我最终一直在使用的软件，它的自动生成 BibTeX key 的功能非常好用，另外自动查找相关文件（需要靠文件名）的功能也很有用。论功能，JabRef 完全可以满足我的所有需求。
- Bibus：开源，还是 Python 开发的。但是经历了一次安装失败，就没用...
下面介绍的是在线服务和本地客户端整合的软件，主要功能集中在客户端，网络服务上可以备份数据并提供社会化功能：
- Zotero：是 Firefox 的一个扩展，现在也有独立运行版本（感觉是基于 Firefox 剪裁的）。对惯用 Firefox 的人来说，这是非常好的一个选择。它通过 DOI 等信息获取题录应该也是来自 CrossRef。我非常喜欢的是它能标出获取的数据来源，虽然并没有提供多个来源的选择。
- Mendeley： 非常适合在积攒了大量的 PDF 文件时处理，因为这个软件可以识别 PDF 中包含的 citation 信息（虽然准确率一般般）。也可以通过 DOI 数据从 CrossRef （我猜测）获取信息。可惜不方便的地方在于，它从 DOI 更新数据的时候，没有提示就直接覆盖了之前的数据。往往获取的数据并不太好，这点使我的体验不是太好，期待之后的改进。此外，Mendeley 可以导入 CiteULike 的数据。
买了新手机、新笔记本的同学往往特别在乎电池，尤其是笔记本，喜欢用各种软件去查看电池损耗。本文希望能简要介绍一些我能所知的锂电池使用和保养的方法。物理也不怎么好，以下所有论断都是查阅资料后的判断。
首先说一下常见的误区：
- 满充满放三次，充电12小时，刻意满充满放，都是对锂电池有损害的方式，这些是对镍氢电池的。
- 充满了继续插着对锂电池没什么用，充电电路会停止充电的。
- 边充电边工作对锂电池影响不大，之所以不建议边充边工作的原因是高温环境对电池损害大。除非笔记本天天不关温度较高，去掉电池可能有点好处。一般情况下，边用边用没有问题。
正确的使用方法是随时充电，想用就用，避免过放。当然，如果有可能，遵循下面的使用方式会有些好处：
- 浅充浅放。也就是说放电和充电的程度都不要太大，所以在条件允许的情况下随手充电就是很好的习惯。
- 避免高温。
- 避免过充和过放。因为锂电池都有保护电路，所以一般情况下，这种情况也不会发生。除非长时间不用，可能就过放了。
长时间不用怎么办？
- 电量在 40%~60% 的程度保存。
- 尽量在低温环境下保存。
此外涉及到充电器的问题：
- 现在很少有把电源管理 IC 放在充电器上，一般都在锂电池上或者设备上。所以充电器只要电压符合，就可以充电。
- 至于充电器的标称电流，代表充电器的输出功率，使用多少是由电源管理 IC 控制的，所以功率大小只会影响充电快慢，使用超过设备所需的大功率充电器充电，也只会依据设备的电源管理 IC 的设置进行充电，通常也不会充得快。特别指出，用 iPad 的 10W 充电器给 iPhone 充电完全没有问题。Apple 网站和下面提供的参考资料中都有回答和验证。
- 充电器电压一般都高于 5V，浮动 0.2V 没有关系，由电源管理 IC 控制提供给电池的电压。
- 尽量不用座充，这是因为市面上的万能充不怎么好。详细介绍见下面的参考资料。
iPad 充电要求比较高，一方面是需要 10W 功率的充电器才能合理的时间充电（否则就太慢了），另一方面，Apple 的充电器的 USB 接口额外有一个识别电阻。没有这个识别电阻，可能会让 iPad 显示"不在充电"。
参考资料如下：
- Battery in a Portable World by Mr. Isidor Buchmann
- Wiki: 锂离子电池 储存电量和温度对损耗的影响
- 阿苷的博客 专业的介绍和评测
- 究竟IPAD的10W充电器能否给IPHONE4充电 大测试
- 揭露ipad只能用原装充电器的秘密
这个东西到底怎么叫呢？插线板，接线板，插排，电源转换器好多名字，英文怎么说？不管了。
为什么要选择一个好的插线板，两点考虑：用电安全和保护电器。
先说结论：
- 不在乎的用什么都行。
- 想用便宜没有过多要求的，用航嘉、公牛、可来博等等你听说过的牌子。
- 需要防浪涌等功能，就选择：APC、贝尔金、突破（保镖系列），不建议用航嘉、秋叶原、飞利浦等带防浪涌的型号，既然都在乎了，就买个好点的。比如飞利浦的低端电源做工不错，带防雷击的型号就比较差。
- 特有钱没地方花的，选择电源净化器、UPS等。
国内大部分插线板（包括品牌的），假冒伪劣（比如不接地线）的就不说了，即使能用的，在做工和用料上往往也不令人满意。设计和用材不好的插线板，自然有安全隐患。
- 线缆铜丝截面积至少应为 3×0.75 平方毫米。如果截面积太小，插线板所接电器功率过大时，线就会发热。有的插线板线很粗，但是里面铜丝确很细。
- 内部走线美观，做工精致。用铜排的当然最好，如果都用焊接方式的，走线美观也不错。一体式内芯有利于减少内阻，避免虚焊，从而降低损耗。
- 插口使用磷青铜接触弹片。使用其他材质的，多次插拔后夹持力就下降了。
- 使用银触点开关。普通铜触点开关容易引起电弧，也就是开关过程中看见的火花。煤气泄漏不要按开关就是说这个。
插线板除了基本功能以外，还有些个性化要求，比如我喜欢：
- 每个插孔独立开关的。
- 插孔间距大。
- 插孔有插入保护，可以防止儿童误插或者异物落入。
- 高阻燃、耐冲击外壳。
插线板骗我们钱，自然是从更高级的功能上来的：
- 过电压保护，过载保护，漏电保护：这些从功能上有了应该不会骗人，算是比较好检测的保护，区别就在于敏感度和承载量，不过一般有这些功能的区别不会太大。
- 浪涌保护，防雷击保护：别想着能防直击雷，对于感应雷和普通浪涌，目前的插线板都是使用压敏电阻 MOV 和放电管来保护的。区别在于用的 MOV 好不好。其实不用太在意浪涌，家用大型电器设计的时候一般都考虑了保护功能（如果没有说明电器不好...）。
- 滤波功能：防浪涌可以削弱尖峰，但是对于电源中的噪声应该无能为力。如果有一个 EMI 滤波器自然更好。如果对音响的性能比较敏感，就多花些钱买电源净化器吧。当然了，真正的HIFI烧友只用雅鲁藏布江的水电，我作为外行就不讨论了。
泡泡网有一个系列文章：帮助你了解电源，可以看看。
总不能在标题上就写如何盗链吧...
Referer 是 HTTP Header 的一个字段（wiki），包含在向服务器发送的请求中，记录访客的来源URI。
很多网站用辨识 Referer 来防止盗链，比如百度、网易相册。以猫扑上的图片为例，如果我们直接访问，或者外链到其他网站，就会显示不出。因为猫扑的服务器判断 Referer 信息，发现不是来自自身网站，就对该请求予以拒绝。
如果网站的防盗链措施只是基于 Referer 判断，可以通过伪造 Referer 来实现外链。比如 Firefox 的 RefControl 扩展。但是依据安全性（The setRequestHeader() method），不能要求用户浏览器发送伪造的 Referer。
所以早期使用 JavaScript 利用 XMLHttpRequest 设置 Referer，早期的 Flash 通过 ActionScript 构造请求的时候，自定义 Referer 的方法现在都被禁止了。
既然不能强制客户端设置 Referer，那只能通过服务器中转的方式，因为在服务器端就可以构造自定义请求了。
对于网站管理者来说，防止盗链的方式就很多了，比如利用 Session，判断 IP，生成随机码等等方式...
Python 允许通过 exec 和 eval 执行以字符串形式表示的代码片段，这体现了动态语言的特性。利用这种特性，可以让代码变得更灵活。不过一直以来，我对这种"动态"的用法不太"适应"，因为：
- 让代码引入了某些不安定因素，这些代码片段执行后可能对全局造成影响。尤其是当使用全局名称空间时，它的作用范围难以控制。
- 对执行的效率也有影响。Python 在执行代码之前也是要预编译的，比如 pyc 文件。因此这些字符串形式的代码片段在执行的时候，需要编译的过程，哪怕是使用 compile 编译后重复使用，第一次的编译是难以避免的。
很多人也倾向于避免这种用法，比如：Use of eval in Python?。
不过最近在写网站解析程序的时候，发现为了实现目的，最好的解决方案还是引入这种字符串形式的代码片段。这个问题具体描述是：我需要对一系列类似的网站进行解析。整体的解析过程是相似的，所以我建立了一个框架，使用 XML 保存每个站点各自的解析属性，通常是 XPath 和正则表达式。但是某些内容各个网站的表现方式有很大差别，这些内容想要解析出来只使用 XPath 和正则表达式是不够的。因此对这些例外情形，最好的方式是直接利用代码片段来计算。
此外，现有的项目，比如 Genshi 之类模板引擎也采用了类似的处理手段。
用户使用程序如果能执行自己的代码片段，这往往是有潜在危险的，尤其是在网络服务中，因此我们在使用的字符串代码片段的时候，要严格限制名称空间。对这个问题的讨论，可以参考 Using eval() safely in python，这里做一个简要的总结。
默认的，eval 和 exec 所运行的代码都位于当前的名称空间中，它们也可以接受一个或两个可选字典参数作为代码执行的全局名称空间和局部名称空间。
eval 的用法最严格的限制（注意对 builtins 的处理）是：
eval(user_func,{"__builtins__":None},{"x":x,"sin":sin})
如果希望允许使用某些变量和函数，可以采用下面的方法：
eval(user_func,{"__builtins__":None},{"x":x,"sin":sin})
有关使用 exec 和 eval 的注意事项，文章 Be careful with exec and eval in Python 进行了细致的讨论。首次编译是不可避免的，使用预编译后重复使用可以提高效率。另外使用局部空间因此可以加快变量的查询速度，所以执行会快。
下面还有几个需要注意的地方：
能避免使用的时候，还是应该采用其他方式，比如转换字符串的时候，使用 int() 而不是 eval()，因为如果转换的这个字符串是用户输入的，危险的情况是 eval() 会执行恶意输入的条命令。详细的解释参考：Python之eval()函数的危险。
尽量避免使用 eval 来获取变量名，想要实现动态变量名，使用 globals()，locals() 以及 vars()。
a = 123 s1 = locals()['a'] s2 = vars()['a'] print s1, s2
类似的情况也出现在 JSON 格式的解析上，参见 Running JSON through Python's eval()? 。
