一种新的图片验证方式。。
原文来自：http://www.cnbeta.com/articles/82206.htm
新闻来源:CNET
Internet上一个持久的问题，就是如何屏蔽掉一些自动软件，如自动注册帐户然后发送垃圾邮件或垃圾回复以提高站点的搜索排名。Google一直致力于这方面的研究，已经在尝试新的方法让bot退散。
目前的测试方法被称为Captcha(全自动区分计算机和人类的图灵测试)，新的Captcha方法的原理是，人类通常能区分出图片的哪个方向是朝上的， 而电脑不能。Google发布了一项新的研究成果，提出了一种区分电脑与人类新的测试方法。这种方法要求受验证者旋转给定的图片，使其直立。 
怎样才算是直立的？Google的测试依赖于寻找人类容易识别而电脑很难做到的图片。
Captcha目前已经被广泛使用，经常出现的形式是一些人类还能阅读的污损扭曲的字符 。对于这一方面的研究已经有很多，包括识别3D图片以及区分猫和狗。
如下是来自Google的作者Rich Gossweiler, Maryam Kamvar和Shumeet Baluja在他们的论文中对图片取向技术的描述（论文PDF下载）：
这项任务要求对图片常见复杂内容的分析，对于人类而言一般很简单，而对机器则很难。
给定大量的图片库，如网页图片搜索结果，我们使用一个自动方向识别器识别出那些很容易被识别出是直立的图片，然后我们通过社会反馈机制来确定剩余的图片是否直立对于人类而言是易于识别的。
这种Captcha方法和传统的文字识别方法相比具有很多优势：独立于语言、不需要字符输入并且开创了除文字扭曲以外的另一种Captcha生成方法。这种Captcha能快速的实现，并且有着几乎无限的图片来源。
我们进行的大量的实验就这种方法的可行性进行调查，人类在识别的时候具有很高的成功率，而bot的识别率很差。由于不需要文字输入，其用户体验也比文字类Captcha要好。
有些图片的直立方向的识别对人类也很困难。一次500人的测试的结果显示，受试者对左图的直立方向有着很大的分歧，而右图则不然。
最困难的一点是，如何在难易程度上找到一个平衡点。有些图片对于人类而言很难确定方向，而有些图片暗藏着线索（脸、文字、蓝天、绿草）可以让电脑找出直立的方向。
为了解决这个问题，除了向用户提供已知的易于识别的图片以外，也会加入一些新的图片。如果这些图片经常难以被正确识别出直立方向，就会自动从图片库中去除。
研究者喜欢这种方法的部分原因是图片不需要污损或扭曲，不像Google当前使用的文字Captcha。但图片Captcha在bot与网站之间的军备竞赛中，也不能保证一直有效。
“随着图片方向检测系统越来越先进，我们用于筛选图片的方法也跟着升级，以避免将会被机器出来的图片呈现给用户。”研究人员说，”最终也许我们还是要用到图像扭曲。”
mysql proxy 终于有一个release版本了。只是我最近还用不到这个。纯记录一下
MySQL Proxy 0.7.0 is finally released:
The full ChangeLog is a bit longer as 0.7.0 was more than a year in the works. To make it short: it is faster, better and more flexible.
Binaries will be release at http://dev.mysql.com/downloads/mysql-proxy/index.html shortly.
For everyone who just wants to update from 0.6.1 to 0.7.0 you should just see a major speed improvement.
- A bug in the
connect()-phase that caused to leave the Naggle-algorithm enabled caused a unneccesary high latency.
- We also changed the buffering of result-sets to only buffer them if the scripts really ask for them with
resultset_is_needed = true, see the examples.
Please keep in mind that 0.7.0 isn't a drop-in replacement for 0.6.1. We changed a few objects inside the lua layer which need some small changes to your Lua scripts:
proxy.backends.* is now proxy.global.backends.*proxy.connection.client.address is now proxy.connection.client.src.address full description- the resultset is only available in the resultset handler if
proxy.queries:append(id, packet, { resultset_is_needed = true })
Our focus for the way to 1.0 will be around threading to remove this scalability bottleneck. A first code-drop is already available at launchpad: threaded-io
这个实现方式有点妖。
原文是用asp.net实现的。我也没有改，因为，json数据的获取在PHP中真是太简单了。拿到数据后json_encode一下就全有了。。
想看的就做个参考吧。我还是觉得妖
这里只是把主要的代码贴出来，不再进行过多的说明，重要的地方以注释的方式进行说明。
XML/HTML代码
- <div id="pubDiv" style="background-position: #9999FF; font-size:12px; display:none; z-index:0; overflow:auto; position:absolute; border:#EDEDED 0px solid;background:#EDEDED;"></div>
- <script type="text/javascript" language="javascript">
- // 注意下面的等号右面，不能是“<%=BuildJson() %>”，因为JSon整体不能是字符串，同时最后也不能加分号：“;”
- var strJson = <%=BuildJson() %>
-
- function ShowBdzDiv() {
- var dept = document.getElementById("<%=ddlDeptEdit.ClientID %>").value;
- // 构建要下拉选择的内容
- var strHtml = "<table border=0px cellpadding=0 cellspacing=0 width=120px><tr>";
- for (var key in strJson[dept]) {
- strHtml += "<tr><td onclick=SetBdz()>" + key + "</td></tr>";
- }
- strHtml += "</table>";
- var oBdz = document.getElementById("<%=txtBdz.ClientID %>");
- var oDiv = document.getElementById("pubDiv");
- oDiv.innerHTML = strHtml;
-
- // 设置显示的位置，并显示
- oDiv.style.top = "99px";
- oDiv.style.left = "100px";
- oDiv.style.display = "block";
-
- }
- // 当点击选择一个内容时
- function SetBdz() {
- var oBdz = document.getElementById("<%=txtBdz.ClientID %>");
- // 把选择内容设置到TextBox上，并隐藏下拉选择项
- oBdz.value = event.srcElement.innerText;
- HiddenDiv();
- }
- // 隐藏下拉选择项
- function HiddenDiv() {
- var oDiv = document.getElementById("pubDiv");
- oDiv.style.display = "none";
- }
- </script>
- 。。。
-
- <asp:TextBox ID="txtBdz" AutoCompleteType="Disabled" onfocus="ShowBdzDiv()" runat="server"></asp:TextBox>
这里要说明的是，这里只实现了下拉选择项的点击选择，不能使用键盘操作。
来自dbanotes的文章，不多介绍了。我很多文章来自于dbanotes和sanotes网站
原文地址：http://www.dbanotes.net/arch/small_site_arch.html
原文如下：
到处都是什么大规模啊，高流量啊，高性能之类的网站架构设计，这类文章一是满足人们好奇心，但看过之后也就看过了，实际收益可能并不大；另外一个副作用是容易让人心潮澎湃，没学走先学跑，在很多条件仍不具备的情况下，过度设计、过度扩展(高德纳大爷也说过，"过早优化是万恶之源")，所以，这里反弹琵琶，讨论一下小规模、低性能、低流量的网站该如何搞法。
如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。
拥抱熟知的技术
动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成 的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。
架构层次清晰化
起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。
Web Server <--> (AppServer)<-->Cache(eg. Memcached)<-->DB
层次清晰化的一个体现是(以 LAMP 架构为例)：即使只有一台机器，也应该起个 Memcached 的实例，效果的确非常好--一般人儿我不告诉他...不要把什么都压到 DB 上，DB 一旦 I/O 压力走到磁盘上，问题要暴露出来是很快的。没错，DB 本身也会利用自己的 Cache，但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。
数据冗余? 有必要
很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型 Web 站点遇到的一个头疼事儿，一个小小的应用搞了几十个表... 忘掉范式这个玩意儿! 记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。
前端优化很重要
因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人)，用户看个页面半分钟都打不开，你说咋发展? 先把基本的条件满足，再去研究前端优化。
功能增加要谨慎
不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销，反而收效甚微。记住，小站点，最有价值的是业务模式，而不是你的技术有多牛。技术是为业务服务的，不要炫技。
有些网站不停的添加功能，恰恰是把这些新功能变成了压死自己的稻草。
从开始考虑性能
这一点是可选的，但也重要。设计应用的时候在开始就应考虑 Profile 这件事情。一套应用能否在后期进行有效优化和扩展，很大的程度限制在是否有比较合适的 Profile 机制上。需要补充的是，对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。
好架构不是设计出来的
这是最后要补充的一点。好的架构和最初的设计有关系，但最重要的是发展中的演化：
发展-->发现问题-->反馈-->解决问题(执行力)--> 改进->进化到下一阶段--新问题出现(循环)
有些站点到了某个阶段停足不前，可能卡在执行力这个地方，来自用户的反馈意见上来了之后，没有驱动力去做改进。最后也是死猪不怕开水烫了。
这篇文章有浓重的山寨风格，所以，你不要太认真。如果在用短平快的方式构建某些山寨网站的话，可参考其中对你有益的点，不赞同的地方可以直接忽视掉，就没必要费力留言进行争论了。
--EOF--
