http://blog.csdn.net/tinydust/category/155520.aspxzh-CNFri, 28 Dec 2007 02:55:25 GMT60Tinyfoolhttp://blog.csdn.net/tinydust/archive/2005/12/30/566644.aspxFri, 30 Dec 2005 22:34:00 GMThttp://blog.csdn.net/tinydust/archive/2005/12/30/566644.aspxhttp://blog.csdn.net/tinydust/comments/566644.aspxhttp://blog.csdn.net/tinydust/archive/2005/12/30/566644.aspx#Feedback1http://blog.csdn.net/tinydust/comments/commentRss/566644.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=566644http://www.tinydust.net/prog/diary/2005/12/rss.html 客户端软件的自动更新并不是一个很难做的功能，365kit就可以自动更新。前些日子我还帮别的朋友做过他的软件里面的自动更新功能，写成了一个可执行文件。我发现自动更新功能其实和软件本身的逻辑关系往往不紧密，所以其实可以把自动更新抽出来，单独做成一个软件。这个可执行文件我打算过段时间好好做做，作为免费软件公布。当然这都是题外话。 自动更新的原理一般都是在软件启动后，从服务器下载一个版本描述文件。这样如果软件有大量用户的时候，版本描述文件一定会成为流量热点，不停地被访问，占用大量带宽和流量。那个朋友的服务器在国外，国外的托管和虚拟主机都是有流量限制的，所以流量问题更是不能忽视。 但是怎么才能降低这个流量呢？ 我想可行的方法很多，比如压缩版本描述文件，比如增加检查版本描述文件的时间间隔等等。但是似乎都只是治标的方法，很难治本。 今天我突然想到一个主意，我们可以把版本描述文件做成Rss格式，然后找一家Rss烧制公司，把这个Rss烧制一下，然后在自动更新的程序里面设定<img src ="http://blog.csdn.net/tinydust/aggbug/566644.aspx" width = "1" height = "1" />Tinyfoolhttp://blog.csdn.net/tinydust/archive/2005/11/01/520441.aspxTue, 01 Nov 2005 12:46:00 GMThttp://blog.csdn.net/tinydust/archive/2005/11/01/520441.aspxhttp://blog.csdn.net/tinydust/comments/520441.aspxhttp://blog.csdn.net/tinydust/archive/2005/11/01/520441.aspx#Feedback1http://blog.csdn.net/tinydust/comments/commentRss/520441.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=520441今天看到梦想风暴的文章“做自己的客户”，有点感受。 从我今年五月份正式开始参加365kit到现在已经有快半年光景了。到目前为止，开发的速度我还是满意的，然而Bug着实多了些，尤其是我负责的客户端Bug多了些。 我不想去解释自己为什么不能把握好我的Code，但是仅仅从分析的角度去看，我想Bug那么多有几个原因： 1、因为是利用业余时间开发，所以开发进度时紧时松，节奏很不好。 2、对通讯录和Outlook插件开发领域也是初步的进入，经验方面有些欠缺。 3、因为开发人员的数量少，没有专门测试人员，所以测试比较简单片面。 4、该死的Windows的复杂性和COM的复杂性。 跟对这些Bug的原因，解决的办法应该有： 1、尽量管理好时间，稳定开发节奏。 2、多看些资料，多做总结。 3、开始单元测试，发布版本前多做测试。 4、多学习。 然而，那些都是些客观原因。从主观上看，问题又在哪里呢？ 我想梦想风暴的文章正好可以回答这个问题，我自己还不是365kit的好用户，我用的还不够多。如果我用的足够多，很多Bug，就应该是我们自己发现的，而不是用户提出来的。 <img src ="http://blog.csdn.net/tinydust/aggbug/520441.aspx" width = "1" height = "1" />