<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>曾登高 - 技术关注</title><link>http://blog.csdn.net/zdg/category/92691.aspx</link><description /><dc:language>zh-CN</dc:language><lastUpdateTime>Tue, 08 Jan 2008 00:15:00 GMT</lastUpdateTime><ttl>60</ttl><item><dc:creator>曾登高</dc:creator><title>上周技术关注：2006 年互联网技术发展趋势</title><link>http://blog.csdn.net/zdg/archive/2006/12/25/1459986.aspx</link><pubDate>Mon, 25 Dec 2006 13:55:00 GMT</pubDate><guid>http://blog.csdn.net/zdg/archive/2006/12/25/1459986.aspx</guid><wfw:comment>http://blog.csdn.net/zdg/comments/1459986.aspx</wfw:comment><comments>http://blog.csdn.net/zdg/archive/2006/12/25/1459986.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/zdg/comments/commentRss/1459986.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1459986</trackback:ping><description>这是Read/WriteWeb 对2006年互联网发展趋势的总结。文中链接到其他一些深度讨论的文章。&lt;img src ="http://blog.csdn.net/zdg/aggbug/1459986.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>曾登高</dc:creator><title>上周技术关注：大型高并发高负载网站的系统架构</title><link>http://blog.csdn.net/zdg/archive/2006/12/19/1448982.aspx</link><pubDate>Tue, 19 Dec 2006 15:16:00 GMT</pubDate><guid>http://blog.csdn.net/zdg/archive/2006/12/19/1448982.aspx</guid><wfw:comment>http://blog.csdn.net/zdg/comments/1448982.aspx</wfw:comment><comments>http://blog.csdn.net/zdg/archive/2006/12/19/1448982.aspx#Feedback</comments><slash:comments>2</slash:comments><wfw:commentRss>http://blog.csdn.net/zdg/comments/commentRss/1448982.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1448982</trackback:ping><description>上面提供的几个解决思路在一定程度上也意味着更大的投入，并且这样的解决思路具备瓶颈，没有很好的扩展性，下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。1、HTML静态化2、图片服务器分离3、数据库集群和库表散列4、缓存5、镜像6、负载均衡一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。&lt;img src ="http://blog.csdn.net/zdg/aggbug/1448982.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>曾登高</dc:creator><title>上周技术关注：2007年web开发技术预言</title><link>http://blog.csdn.net/zdg/archive/2006/12/11/1438799.aspx</link><pubDate>Mon, 11 Dec 2006 19:38:00 GMT</pubDate><guid>http://blog.csdn.net/zdg/archive/2006/12/11/1438799.aspx</guid><wfw:comment>http://blog.csdn.net/zdg/comments/1438799.aspx</wfw:comment><comments>http://blog.csdn.net/zdg/archive/2006/12/11/1438799.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/zdg/comments/commentRss/1438799.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1438799</trackback:ping><description>2006年即将过去，这一年被广泛地看作是：在线投资新浪潮的一年；更新的web技术和技巧兴起和成长年；从未这样采用web能量的新商务模式的兴起（和衰落）的一年。根据SitePoint和Ektron这两家组织提供的调查报告，大家不妨跟随作者一起放眼遥望一下亮光周围的风景，也许你会听到自己的惊呼，请加入到对“未来”的预言中吧！尝试一下网络对趋势的影响力！&lt;img src ="http://blog.csdn.net/zdg/aggbug/1438799.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>曾登高</dc:creator><title>上周技术关注：ASP.NET AJAX under the hood secrets</title><link>http://blog.csdn.net/zdg/archive/2006/12/04/1430066.aspx</link><pubDate>Mon, 04 Dec 2006 23:51:00 GMT</pubDate><guid>http://blog.csdn.net/zdg/archive/2006/12/04/1430066.aspx</guid><wfw:comment>http://blog.csdn.net/zdg/comments/1430066.aspx</wfw:comment><comments>http://blog.csdn.net/zdg/archive/2006/12/04/1430066.aspx#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://blog.csdn.net/zdg/comments/commentRss/1430066.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1430066</trackback:ping><description>文章主要关注于ASP.NET AJAX中经常会使用到，却不太被人关注的一些功能细节，以及需要避免的一些问题。例如“Batch calls are not always faster”等，也提到了浏览器的一些特性以及限制，例如“Browsers do not respond when more than two calls are in queue”，可以说这些都是开发ASP.NET AJAX乃至Web开发所必需了解的内容。文章中也提到了一些ASP.NET AJAX在使用时的一些技巧，例如在Web Service访问时利用Cache来提高效率，而且这可不是像之前CTP的官方文档上提到的简单方法那样“普通”，它是个真正经过挖掘与实践之后得到的结论。其余部分的也提到了客户端Function.createDelegate方法的使用（这个方法我一直很喜欢，呵呵），以及在访问Web Services时HTTP GET与HTTP POST直接的对比。 
&lt;img src ="http://blog.csdn.net/zdg/aggbug/1430066.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>曾登高</dc:creator><title>上周技术关注：关于AJAX框架性能的比较</title><link>http://blog.csdn.net/zdg/archive/2006/11/27/1417697.aspx</link><pubDate>Mon, 27 Nov 2006 23:38:00 GMT</pubDate><guid>http://blog.csdn.net/zdg/archive/2006/11/27/1417697.aspx</guid><wfw:comment>http://blog.csdn.net/zdg/comments/1417697.aspx</wfw:comment><comments>http://blog.csdn.net/zdg/archive/2006/11/27/1417697.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/zdg/comments/commentRss/1417697.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1417697</trackback:ping><description>其实事实往往就是这样：现在用于比较的都是非常优秀的框架，这样的框架不太会做一些无用的事情。额外的代码，额外的数据传输应该都是有其目的的，因此单独比一个非常小，几乎不可能单独出现的Scenario往往还不够。我们还需要结合一些别的比较，例如功能的比较，或者在一个庞大，完整的Scenario下，不过这个比较就非常困难了。另外，比较太小的Scenario的结论往往也会有失偏颇，例如ASP.NET AJAX在任何“小功能”的比较时都会传输“大量”的脚本，但是这真的是劣势吗？在性能上请求一次JS时传输相差十几K真的会相差无几，何况除了第一次下载之外之后就会被缓存了。而且，优化PLT（Page Load Time）的一个Best Practice就是“尽量将所有的JS都存放在一个文件内一起下载”，这可以有效地提高性能和避免出现JS错误。因为重新发起一个Request的代价比下载代码的消耗要大不少，而且如果一个文件太小，甚至小于TCP/IP的一个Package，那么更加可谓得不偿失了。&lt;img src ="http://blog.csdn.net/zdg/aggbug/1417697.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>曾登高</dc:creator><title>上周技术关注：函数式编程另类指南</title><link>http://blog.csdn.net/zdg/archive/2006/11/20/1398640.aspx</link><pubDate>Mon, 20 Nov 2006 13:19:00 GMT</pubDate><guid>http://blog.csdn.net/zdg/archive/2006/11/20/1398640.aspx</guid><wfw:comment>http://blog.csdn.net/zdg/comments/1398640.aspx</wfw:comment><comments>http://blog.csdn.net/zdg/archive/2006/11/20/1398640.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/zdg/comments/commentRss/1398640.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1398640</trackback:ping><description>函数式编程是对阿隆左·丘奇理论的实践应用。但也并非全部 lambda 演算都被应用到了实践中，因为 lambda 演算不是被设计为在物理局限下工作的。因此，象面向对象的编程一样，函数式编程是一系列理念，而不是严格的教条。现在有很多种函数式编程语言，他们中的大多数以不同方式完成不同任务。在本文中我将就最广泛使用的源自函数式编程的思想作一解释，并将用Java语言举例。(的确，你可以用Java写出函数式的程序如果你有显著的受虐倾向）。在下面的小节中，我将会把Java作为一种函数式语言，并对其稍加修改使它成为一种可用的函数式语言。现在开始吧。&lt;img src ="http://blog.csdn.net/zdg/aggbug/1398640.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>曾登高</dc:creator><title>上周技术关注：内置.NET FX 3.0和IIS7的Windows Vista发布了</title><link>http://blog.csdn.net/zdg/archive/2006/11/13/1381578.aspx</link><pubDate>Mon, 13 Nov 2006 14:35:00 GMT</pubDate><guid>http://blog.csdn.net/zdg/archive/2006/11/13/1381578.aspx</guid><wfw:comment>http://blog.csdn.net/zdg/comments/1381578.aspx</wfw:comment><comments>http://blog.csdn.net/zdg/archive/2006/11/13/1381578.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/zdg/comments/commentRss/1381578.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1381578</trackback:ping><description>下面是2个特别让我兴奋不已的Vista内置特性：.NET Framework 3.0 (包括崭新的Avalon，Indigo，Workflow 和 CardSpace 库) IIS 7.0(包括它对ASP.NET的紧密集成) &lt;img src ="http://blog.csdn.net/zdg/aggbug/1381578.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>曾登高</dc:creator><title>上周技术关注：流氓软件及反流氓软件的技术分析</title><link>http://blog.csdn.net/zdg/archive/2006/11/06/1370315.aspx</link><pubDate>Mon, 06 Nov 2006 22:34:00 GMT</pubDate><guid>http://blog.csdn.net/zdg/archive/2006/11/06/1370315.aspx</guid><wfw:comment>http://blog.csdn.net/zdg/comments/1370315.aspx</wfw:comment><comments>http://blog.csdn.net/zdg/archive/2006/11/06/1370315.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/zdg/comments/commentRss/1370315.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1370315</trackback:ping><description>对于上面的流氓软件的方法一些驱动层下的反流氓软件工具又有点束手无策了。因为同是驱动程序相互拦截irp等于大家都无法操作，反流氓软件工具的删除irp会被拦截，或者删除函数会被替换。删除注册表函数会被替换。虽然驱动的加载有先后，但是无法保证能完全的删除流氓软件，从而出现了一些更顶级的反流氓软件，他直接发删除文件irp到文件系统.,删除注册表也直接发送到文件系统。这类流氓软件又能有效的完成了反流氓任务，但是根据我了解，这样的软件不多。现在火热的360安全卫士都还只是使用了笨办法，优先于驱动流氓软件启动，创建一个驱动流氓软件同设备名的设备，，使流氓驱动创建不成功。具我了解他优先于流氓驱动启动是把自己创建于PNP_TDI这个组下面，就是简单的ndis就能优先于360启动。如果前面的组，那360就束手无策了。所以对付这类流氓驱动只能用直接发irp到文件系统。 &lt;img src ="http://blog.csdn.net/zdg/aggbug/1370315.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>曾登高</dc:creator><title>上周技术关注：什么样的界面算是好界面</title><link>http://blog.csdn.net/zdg/archive/2006/10/30/1357587.aspx</link><pubDate>Mon, 30 Oct 2006 21:37:00 GMT</pubDate><guid>http://blog.csdn.net/zdg/archive/2006/10/30/1357587.aspx</guid><wfw:comment>http://blog.csdn.net/zdg/comments/1357587.aspx</wfw:comment><comments>http://blog.csdn.net/zdg/archive/2006/10/30/1357587.aspx#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://blog.csdn.net/zdg/comments/commentRss/1357587.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1357587</trackback:ping><description>第一，记得设计的初衷是为了解决问题。不要理所当然的觉得别人的网站都是这么设计的，我就照搬过来就行。每个细节都可能存在问题，去发现它们吧，那些用户觉得困难的，不理解的，不必要的或者是有所忧虑和顾忌的，想办法化解他们。 第二，平衡。这里说的是两种平衡： 仅仅站在用户的角度是不够的。你是用户和公司中间的桥梁。一个例子：公司说要赚钱，多多上广告！用户说广告烦，我不要看！那你要做的是什么？当然是平衡。广告要上，而你的工作是去了解和研究用户如何才能忍受广告，接受广告，可以忍受多少：） 关于用户体验，可用性的理论，不要断章取义。简洁是好，于是所有的网站都要千篇一律么？你要展示什么不同于竞争对手的品牌，决定了你的界面是时尚的，前卫的，严谨的或者可爱的。Easy to learn是好，于是，到处都是注释和提示帮助信息么？高级用户会无法忍受的。注意各个因素之间的平衡，不要走极端。&lt;img src ="http://blog.csdn.net/zdg/aggbug/1357587.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>曾登高</dc:creator><title>上周技术关注：ASP.NET AJAX Beta 1 发布</title><link>http://blog.csdn.net/zdg/archive/2006/10/23/1346016.aspx</link><pubDate>Mon, 23 Oct 2006 01:29:00 GMT</pubDate><guid>http://blog.csdn.net/zdg/archive/2006/10/23/1346016.aspx</guid><wfw:comment>http://blog.csdn.net/zdg/comments/1346016.aspx</wfw:comment><comments>http://blog.csdn.net/zdg/archive/2006/10/23/1346016.aspx#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://blog.csdn.net/zdg/comments/commentRss/1346016.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1346016</trackback:ping><description>在这个Beta版本里，开发组做了不少变动。几个比较大的变动如下： 性能和下载文件大小的优化 Safari 浏览器支持 显著改进的调试支持 UpdatePanel的改进 客户端脚本库的许多改进 与其他AJAX库更好的兼容性源码修改许可&lt;img src ="http://blog.csdn.net/zdg/aggbug/1346016.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>曾登高</dc:creator><title>上月技术关注：Google大表</title><link>http://blog.csdn.net/zdg/archive/2006/10/17/1337482.aspx</link><pubDate>Tue, 17 Oct 2006 00:11:00 GMT</pubDate><guid>http://blog.csdn.net/zdg/archive/2006/10/17/1337482.aspx</guid><wfw:comment>http://blog.csdn.net/zdg/comments/1337482.aspx</wfw:comment><comments>http://blog.csdn.net/zdg/archive/2006/10/17/1337482.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/zdg/comments/commentRss/1337482.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1337482</trackback:ping><description>bigtable是设计来分布存储大规模结构化数据的，从设计上它可以扩展到上２^50字节，分布存储在几千个普通服务器上．Ｇoogle的很多项目使用ＢＴ来存储数据，包括网页查询，google earth和google金融．这些应用程序对ＢＴ的要求各不相同：数据大小（从URL到网页到卫星图象）不同，反应速度不同（从后端的大批处理到实时数据服务）．对于不同的要求，ＢＴ都成功的提供了灵活高效的服务．在本文中，我们将描述ＢＴ的数据模型．这个数据模型让用户动态的控制数据的分布和结构．我们还将描述ＢＴ的设计和实现． 
&lt;img src ="http://blog.csdn.net/zdg/aggbug/1337482.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>曾登高</dc:creator><title>上周技术关注：prototype.js 1.4版开发者手册</title><link>http://blog.csdn.net/zdg/archive/2006/09/18/1239778.aspx</link><pubDate>Mon, 18 Sep 2006 20:36:00 GMT</pubDate><guid>http://blog.csdn.net/zdg/archive/2006/09/18/1239778.aspx</guid><wfw:comment>http://blog.csdn.net/zdg/comments/1239778.aspx</wfw:comment><comments>http://blog.csdn.net/zdg/archive/2006/09/18/1239778.aspx#Feedback</comments><slash:comments>5</slash:comments><wfw:commentRss>http://blog.csdn.net/zdg/comments/commentRss/1239778.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1239778</trackback:ping><description>万一你没有使用过大名鼎鼎的prototype.js，那么让我来告诉你，prototype.js是由Sam Stephenson写的一个javascript类库。这个构思奇妙，而且兼容标准的类库，能帮助你轻松建立有高度互动的web2.0特性的富客户端页面。如果你最近尝试使用它，你大概了解到文档并不是作者的一个强项。和在我以前使用这个类库的不少开发者一样，一开始，我不得不一头扎进阅读prototype.js的源代码和实验它的功能中。我想，在我学习完它之后，把我学到的东西分享给大家是件不错的事。 同时，在本文中，我也将提供一个关于这个类库提供的objects,classes,functions,extensions这对东东的非官方参考 &lt;img src ="http://blog.csdn.net/zdg/aggbug/1239778.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>曾登高</dc:creator><title>上周技术关注：微软推出IronPython 1.0</title><link>http://blog.csdn.net/zdg/archive/2006/09/11/1210339.aspx</link><pubDate>Mon, 11 Sep 2006 22:36:00 GMT</pubDate><guid>http://blog.csdn.net/zdg/archive/2006/09/11/1210339.aspx</guid><wfw:comment>http://blog.csdn.net/zdg/comments/1210339.aspx</wfw:comment><comments>http://blog.csdn.net/zdg/archive/2006/09/11/1210339.aspx#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://blog.csdn.net/zdg/comments/commentRss/1210339.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1210339</trackback:ping><description>经过JPython作者Jim Hugunin三年的努力，9个Beta之后，.NET平台上的动态语言IronPython 1.0终于发行了！在他的发行说明里，他说他当初写针对CLR的Python时，无非是想臭臭CLR，准备写篇名为'Why the CLR is a terrible platform for dynamic languages'的文章，但在写原型时发现Python在CLR平台上运行性能极佳，居然在很多情形下比C语言的实现CPython还快不少。使用标准的评测benchmark，IronPython居然比CPython快1.7倍！后来他加入了微软，来完成IronPython在CLR上的实现。IronPython是Python的真实实现，与.NET平台之集成天衣无缝。 &lt;img src ="http://blog.csdn.net/zdg/aggbug/1210339.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>曾登高</dc:creator><title>上周技术关注：AJAX good practices</title><link>http://blog.csdn.net/zdg/archive/2006/09/04/1176870.aspx</link><pubDate>Mon, 04 Sep 2006 20:29:00 GMT</pubDate><guid>http://blog.csdn.net/zdg/archive/2006/09/04/1176870.aspx</guid><wfw:comment>http://blog.csdn.net/zdg/comments/1176870.aspx</wfw:comment><comments>http://blog.csdn.net/zdg/archive/2006/09/04/1176870.aspx#Feedback</comments><slash:comments>2</slash:comments><wfw:commentRss>http://blog.csdn.net/zdg/comments/commentRss/1176870.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1176870</trackback:ping><description>AJAX good practices&lt;img src ="http://blog.csdn.net/zdg/aggbug/1176870.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>曾登高</dc:creator><title>上周技术关注：ASP.NET常见参考项目分析</title><link>http://blog.csdn.net/zdg/archive/2006/08/28/1133186.aspx</link><pubDate>Mon, 28 Aug 2006 17:03:00 GMT</pubDate><guid>http://blog.csdn.net/zdg/archive/2006/08/28/1133186.aspx</guid><wfw:comment>http://blog.csdn.net/zdg/comments/1133186.aspx</wfw:comment><comments>http://blog.csdn.net/zdg/archive/2006/08/28/1133186.aspx#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://blog.csdn.net/zdg/comments/commentRss/1133186.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1133186</trackback:ping><description>简单个人评价： 1. Personal Web Site Starter Kit：简单，供初学者参考之用 2. Club Web Site Starter Kit：对标准 MemberShip 的扩充值得一看 3. Classifieds Site Starter Kit：结构较为清晰，利用 DataSet 简化了大量 SQL 代码的编写 4. Commerce Starter Kit： 利用了 Provider 模型，有些小瑕疵，如界UI层有 SqlDataSource，Model 中有 DataTable 5. Duwamish 7.1：架构比较清晰，但Model 继承自 DataSet ，因此其 BuildDataTables 和 Models 中的CURD 方法较为麻烦，代码量较大 6. Jobs Site Starter Kit：简单实用，有些缺点，如 Model 的 CRUD 方法的 SqlParameter 造成 BLL 和 DAL 无法完全隔离 7. Timer Tracker Starter Kit：一种架构清晰、较好的实现模式，只是代码量稍大 8. .Text 0.&lt;img src ="http://blog.csdn.net/zdg/aggbug/1133186.aspx" width = "1" height = "1" /&gt;</description></item></channel></rss>