Walleve | 理想就像内裤,要有,但不能逢人就去证明你有

几乎所有博客都提供RSS feed，有的网站甚至将整站都输出xml格式来方便其他人使用，而我们如何在自己的博客或者网站上调用自己的或者其他人的RSS 输出的文章呢？ 方法有两个 1、利用feedsky的feed托管 进入feed管理，有JS输出选项 2、magpierss MagpieRSS是一个PHP编写的RSS解析器。它支持RSS0.9和1.0,以及部分RSS2.0.MagpieRSS是一个简单的面向对象的末端，它包含了自动的解析RSS缓存来降低外部Web站点的负载。[理解其中的部分rss2.0？且略，支持wordpress的rss解析就行，而且研究wordpress会发现，它自身已经集成了magpierss，所以足见magpierss还是挺不错的] 具体使用方法如下： A、下载magpierss集成包 B、只保留extlib文件夹和四个inc文件，其它文件删除掉即可(等详细分析此rss解析器时再做分析) C、调用方法如下： require_once(’magpierss/rss_fetch.inc’); define(’MAGPIE_CACHE_DIR’, ‘/tmp/mysite_magpie_cache’); define(’MAGPIE_CACHE_ON’, 1); define(’MAGPIE_CACHE_AGE’, 1800); $rss = fetch_rss(’http://www.newsforge.com/index.rss’); echo "<a href=".$rss->channel[’link’]."><B>".$rss->channel[ ‘title’]."</B></a>"; foreach ($rss->items as $item) { $href = $item[’link’]; $title = $item[’title’]; $desc = $item[’description’]; echo "<P><a href=$href>$title</a><BR>"; if($desc) echo $desc; }

wordpress简洁主题推荐 名称：Simplex 来源：Walleve 演示：本博客当前主题[2008-04-22] 说明：任意修改使用,无版权限制 下载：点击下载 附加：wordpress模板函数

在换到wordpress最初的一段时间，每日的评论数量都很正常，质量还都比较高，可是当我去了一次wordpress.com上宣传自己的blog之后，几乎是两天之内，出现了近百条的垃圾评论，全部是那种加了AD连接的E文评论，相当恼火，第一时间想到的当然是去.org上down一个验证码的插件下来装上去一切完事，可是测试了三个验证码，均不是太符合心意，虽然都相当不错，甚至有一个的DIY功能相当强大，可是一个小验证码，搞那么复杂,有啥用呢，所以就自己搞了一个结合品(验证码生成机制参考的sablog1.6中的验证码，所以取名seccode)，起初并没有写插件，测试了两天，感觉还可以，就写成了插件形式的，方便安装使用。 PS”图片比弄这个插件的时间还长，算是理解那些美工的苦处了.. 从这里下载

三，缓存：Cache 空间换取时间，缓存永远计算机设计的重中之重，从cpu到io，到处都可以看到缓存的身影，web架构设计重，缓存设计必不可少，关于怎样设计合理的缓存，jbosscache的创始人，淘宝的创始人是这样说的：其实设计web缓存和企业级缓存是非常不同的，企业级缓存偏重于逻辑，而web缓存，简单快速为好。。 缓存带来的问题是什么？是程序的复杂度上升，因为数据散布在多个进程，所以同步就是一个麻烦的问题，加上集群，复杂度会进一步提高，在实际运用中，采用怎样的同步策略常常需要和业务绑定 老钱为搜狐设计的帖子设计了链表缓存，这样既可以满足灵活插入的需要，又能够快速阅读，而其他一些大型社区也经常采用类此的结构来优化帖子列表，memcache也是一个常常用到的工具 钱宏武谈架构设计视频 http://211.100.26.82/CSDN_Live/140/qhw.flv Cache的常用的策略是：让数据在内存中，而不是在比较耗时的磁盘上。从这个角度讲，mysql提供的heap引擎（存储方式）也是一个值得思考的方法,这种存储方法可以把数据存储在内存中,并且保留sql强大的查询能力,是不是一举两得呢? 我们这里只说到了读缓存，其实还有一种写缓存，在以内容为主的社区里比较少用到，因为这样的社区最主要需要解决的问题是读问题，但是在处理能力低于请求能力时，或者单个希望请求先被缓存形成块，然后批量处理时，写缓存就出现了，在交互性很强的社区设计里我们很容易找到这样的缓存 四，核心模块一定要自己开发：DIY your core module 这点我们是深有体会，钱宏武和云风也都有谈到，我们经常倾向于使用一些开源模块，如果不涉及核心模块，确实是可以的，如果涉及，那么就要小心了，因为当访问量达到一定的程度，这些模块往往都有这样那样的问题，当然我们可以把问题归结为对开源的模块不熟悉，但是不管怎样，核心出现问题的时候，不能完全掌握其代码是非常可怕的 五，合理选择数据存储方式：reasonable data storage 我们一定要使用数据库吗，不一定，雷鸣告诉我们搜索不一定需要数据库，云风告诉我们，游戏不一定需要数据库，那么什么时候我们才需要数据库呢，为什么不干脆用文件来代替他呢？ 首先我们需要先承认，数据库也是对文件进行操作。我们需要数据库，主要是使用下面这几个功能，一个是数据存储，一个是数据检索，在关系数据库中，我们其实非常在乎数据库的复杂搜索的能力，看看一个统计用的tsql就知道了(不用仔细读,扫一眼就可以了) select   c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(select   count(Id)   from   review   where   Reviewid=a.Id)   as   countNum   from   Creativity   as   a,User_info   as   b,class   as   c,class2   as   d   where   a.user_id=b.id   and   a.Creativity_Class=c.Id   and   a.Creativity_Class_2=d.Id select   a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id)   as   countNum   from   Creativity   as   a,User_info   as   b,class   as   c,class2   [...]

@转载 http://blog.csdn.net/21aspnet/archive/2008/12/19/3558455.aspx 一，不要过设计：never over design 这是一个常常被提及的话题，但是只要想想你的架构里有多少功能是根本没有用到，或者最后废弃的，就能明白其重要性了，初涉架构设计，往往倾向于设计大而化一的架构，希望设计出具有无比扩展性，能适应一切需求的增加架构，web开发领域是个非常动态的过程，我们很难预测下个星期的变化，而又需要对变化做出最快最有效的响应。。 ebay的工程师说过，他们的架构设计从来都不能满足系统的增长，所以他们的系统永远都在推翻重做。请注意，不是ebay架构师的能力有问题，他们设计的架构总是建立旧版本的瓶颈上，希望通过新的架构带来突破，然而新架构带来的突破总是在很短的时间内就被新增需求淹没，于是他们不得不又使用新的架构 web开发，是个非常敏捷的过程，变化随时都在产生，用户需求千变万化，许多方面偶然性非常高，较之软件开发，希望用一个架构规划以后的所有设计，是不现实的 二，web架构生命周期：web architecture‘s life cycle 既然要杜绝过设计，又要保证一定的前瞻性，那么怎么才能找到其中的平衡呢？希望下面的web架构生命周期能够帮到你  [attach=43] 所设计的架构需要在1－10倍的增长下，通过简单的增加硬件容量就能够胜任，而在5－10倍的增长期间，请着手下一个版本的架构设计，使之能承受下一个10倍间的增长 google之所以能够称霸，不完全是因为搜索技术和排序技术有多先进，其实包括baidu和yahoo，所使用的技术现在也已经大同小异，然而，google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的 –待添加