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

这张图片是让我心底最为之一震的一个镜头 没有逃走的人，聚集在里面，悄无声息的聚集，当小鬼子打开门的一瞬间，那是一双双最没有感情的眼睛，他们的眼中已经没有了惧怕，没有了求生欲望，而当举起双手，我心里就一句话：小鬼子欠了我们太多了，这段历史不应该被遗忘，这笔帐终归要清算。 看完整个电影之后，更是感受到电影不应该给20岁以下的人看，不应该给没有历史教育的人看，电影太商业化了。 刚专门跑豆瓣上去看影评了，摘录如下：

技术和需要产生矛盾往往是因为两种情况。一是需求不清晰（如细节未考虑）、或者提出的方案不合理。这种情况下，技术会对需求方的方案做补充和修缮；如果从技术角度想到更好的解决方案，也会提出来。在不影响商业价值或用户的体验的前提下，需求方大都会认同，从而解决矛盾。 第二种情况是需求合理清晰，但是从技术实现成本过高或周期过长。这需要站在技术的角度重新考虑各种替代方案。如果替代方案既能满足需求又没有成本周期问题，则矛盾得以调解。比如阿里软件开发的一款外贸软件产品中，有着模糊搜索的要求。直接通过数据库来处理，性能是非常差的；通过搜索引擎，则成本太大；但如果不提供，从需求方来说就是没有达到要求。后来技术团队将多种方案综合，通过适当降低友好度，来实现这个功能的高效性。但有些时候未必能找到合适的替代方案，叶伟认为此时应当从商业价值、性价比等角度来考虑‘变更需求’，而且必须提交给上级经理或者产品会议作决定。 调节技术与需求之间矛盾的方法有很多种，但是原则却是大同小异。阿里软件研发总监叶伟结合自己十多年的带领团队开发经验总结了三个原则：

标记：本文是自己在项目中思考的一些东西，应用范围或许很有限 有时候开发出来的东西并不能够解决所有人的问题，而即使解决，效果可能并不理想，甚至有时候会违背起初开发的意愿，没有经验的开发者往往就会面临这样的问题，我最近在工作中就遇到过这样的问题，甚至是有重复修改开发一个功能的低效率情况出现，简单总结之后，概括如下： 1、开发需求清晰明朗，并且事先通知所有参与人员，开发中谨遵需求。 所谓的开发需求不是说必须有相关的文档或者数据出来，而是开发者对需求理解的相当准确，开发出来的东西，即使有瑕疵，最起码在结构和逻辑上符合需求，那么我们即使在后期需要完善或者修改的时候，也能够很清楚的搞清楚这块东西的处理原则、方式、方法，而不至于走弯路，去重新写。 2、代码的初步优化 我想应该是两个方面，一是程序代码逻辑的优化[包含算法优化]，一是代码一定要排版清晰，并且有相应的注释。

几乎所有博客都提供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; }

ps”这个是优酷上的视频，youtube估计还在“墙”外边呢。 05年的超级女生里边，发展最好的应该就是张靓颖了吧