注册writely已经很长时间了，一直没有好好的去感受它的好处，因为现在每个人的机器上都有office，谁还需要一个online版的呢？今天琢磨了下，发现有几个用处。
1、如果你的机器上的word坏了，或者偶然遇到一个没有word的机器。用writely吧，它还可以。
2、当你想把word文档转换成pdf格式，而自己又不知道怎么转，或者没有安装相关的转换软件。用writely吧，它能把你的doc格式转成pdf、rtf，甚至OpenOffice的格式。
3、你的word文档实在太多了，自己都搞不清应该怎么归档，哪些是新的，哪些是旧的。你可以把他们导入到writely，给他们分别star、tag和archive，以后找起来会很快速方便。
4、当你的工作伙伴都不在身边，而你想和他们对同一个文档进行协同工作。
先想到了这么多，也许还有，比如把文档共享给其他人阅读，供其他人审阅，贴到Blog上等等。
曾经在live space上介绍过用live writer来发表live space上的日志，其实live writer可以支持很多个BSP，比如世界上最流行的myspace、wordpress、blogger、typepad等等。
live writer的好处非常多，比如你想把一篇文章发表在多个blog上，以前，你可能需要登陆每个blog去手工进行操作，现在通过live writer，这就变得异常简单和方便。
使用时，需要先添加一个blog帐户，Add Weblog Account
然后输入你的blog地址信息，和登录blog的帐户、密码，
如果网站需要通过代理访问，则可以修改代理服务器设置，接下来live writer会自动连接到服务器，下载你的blog的设置和基本配置信息
今天看到了一篇文章“MySQL vs. PostgreSQL”，讲述如何在不同的场合在MySQL和PostgreSQL之间作出正确的选择。实际上，对这两个开源产品不熟悉的人，通过这篇文章，也知道了MySQL和PostgreSQL的不同应用范围。
1、什么情况下选择MySQL
首要考虑是数据库应用的场合，如果是基于WEB的应用程序，或对数据库性能要求较高的应用，MySQL以它的快速和易于web部署将成为首选。然而，如果你的应用程序需要依赖存储过程和外键引用实现，那么还是选择PostgreSQL吧。
需要说明的是，MySQL不是完全兼容ANSI SQL标准的产品，PostgreSQL更加接近ANSI SQL标准，MySQL更加接近ODBC标准。（对于需要移植到其他数据库平台的产品来说，符合ANSI SQL标准的产品可能更好些。）
总结一下，选择MySQL比选择PostgreSQL好的理由：
a、MySQL相对PostgreSQL运算更快
b、数据库设计更加简单
c、你可以更加方便创建web站点
d、MySQL的复制技术已经完全测试通过
e、你无需对MySQL数据库做清空处理
2、什么情况下选择PostgreSQL
很少有web开发者选择PostgreSQL，因为他们觉得PostgreSQL的一些附加特色功能降低了数据库性能。但这些特色功能正是其优于MysQL的地方所在。
比如，外键、触发器、视图。他们的存在可以在应用程序中隐藏数据库设计的复杂程度，从而避免了创建一些庞杂的SQL命令。比如，很多PostgreSQL的用户都喜欢PostgreSQL的函数功能，而在MySQL里面，你可能需要用嵌套的对重、复合、复杂SQL语句来实现的功能，PostgreSQL的一个小小的函数就解决问题了。同时，PostgreSQL符合ANSI SQL规范。
总结一下选择PostgreSQL的理由：
a、可进行复杂数据库的设计
b、可以在Oracle、Sybase、MSSQL之间迁移
c、复杂业务规则的设计建立
d、服务器可以进行脚本编程（Tcl、Perl、Python等）
e、支持事务
f、支持存储过程
g、支持几何数据类型（坐标、多边形等）
h、使用了R树
阅读参考
http://builder.com.com/article.jhtml?id=u00820010815cnt01.htm
http://builder.com.com/article.jhtml?id=u00320020523dol01.htm
这段时间以来（大约一周前），Great FireWall（简称GFW）对blogspot解封，于是我重拾以前的帐号，玩起了blogger，并且已经关闭了我在live space的空间。
不过，我发现blogger里面有点小bug。当我创建blog的时，如果选择了这样的主题。
那么发布HTML的时候选择了UTF-8编码的话，在index.html这个文件头并没有加入UTF-8的标准BOM，EF BB BF，导致在IE或者以IE为内核的浏览器里面无法显示页面内容（HTML文件已经下载，但IE无法解析，用IE的查看源代码功能可以看到HTML），只有当你手工选择用UTF-8解码，IE才能正确显示，这的确是个奇怪的事情。
后来看了一些资料，说WINDOWS下解析文本文件都是按照文件头的BOM去解码的，所以就导致了这样的情况发生。不过上述情况在firefox里面却没有出现，我检查了一下，发现firefox默认是按照UTF-8解码的，故OK。不知道新版的IE7里面默认的编码格式是不是也改成了UTF-8。
尽管这个问题不是非常严重，但对于一个普通的计算机用户来说，他是无法知道页面打不开的原因的，当出现乱码的时候，我们可能会手工选择一下编码格式，但当页面是空的时候，很难让人想到是不是编码的问题。
在windows下面，我们都会用ultraedit或者hexedit等工具用16禁止模式去看一个文件。unix下怎么做呢？
unix下有一个命令hd，就可以16进制代码查看文件了，比如要查看的文件是abc.c
$ hd abc.c
0000 23 69 6e 63 6c 75 64 65 20 3c 73 74 64 69 6f 2e #include <stdio.
0010 68 3e 0a 23 69 6e 63 6c 75 64 65 20 3c 73 74 64 h>.#include <std
0020 6c 69 62 2e 68 3e 0a 23 69 6e 63 6c 75 64 65 20 lib.h>.#include
0030 3c 61 73 73 65 72 74 2e 68 3e 0a 23 69 6e 63 6c <assert.h>.#incl
0040 75 64 65 20 3c 73 74 72 69 6e 67 2e 68 3e 0a 69 ude <string.h>.i
0050 6e 74 20 66 75 6e 28 63 68 61 72 2a 2c 20 69 6e nt fun(char*, in
0060 74 29 3b 0a 69 6e 74 20 47 65 74 52 65 67 69 6f t);.int GetRegio
$
还是挺不错的。
|
 | Idetrorce on Ansi C++ keyword extensions im… |
 | lihui on Using WinPcap in C++ Buil… |
 | Kevin on Using WinPcap in C++ Buil… |
| lihui on Using WinPcap in C++ Buil… |
| Kevin on Using WinPcap in C++ Buil… |
