<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>DBA Notes</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/" />
    <link rel="self" type="application/atom+xml" href="http://www.dbanotes.net/atom.xml" />
   <id>tag:www.dbanotes.net,2011://1</id>
    <link rel="service.post" type="application/atom+xml" href="http://www.dbanotes.net/cgi-bin/mt-atom.cgi/weblog/blog_id=1" title="DBA Notes" />
    <updated>2011-07-16T15:41:41Z</updated>
    <subtitle>SELECT blog FROM Fenng.Thoughts 
 WHERE subject IN (&apos;Startup&apos;, &apos;Database&apos;, &apos;Web Arch&apos;, &apos;UNIX&apos;, &apos;Web 2.0&apos;, &apos;OPENSOURCE&apos;) ; 

     
        Weblog
                 JobsDigg
CNOUG
                 Delicious
Twitter
                                  Articles
                 About
               </subtitle>
    <generator uri="http://www.sixapart.com/movabletype/">Movable Type 5.06</generator>
 

<entry>
    <title>关于页面字体</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/Web_font.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/cgi-bin/mt-atom.cgi/weblog/blog_id=1/entry_id=1484" title="关于页面字体" />
    <id>tag:www.dbanotes.net,2011://1.1484</id>
    
    <published>2011-07-15T10:40:00Z</published>
    <updated>2011-07-16T15:41:41Z</updated>
    
    <summary>关于 Web 页面字体这方面，我是门外汉，弄不出来长篇大论 -- 这样也没必要，从观察统计上简单分析一下看看就够了。

几个页面字体适配度比较好的，HTML body 字体的定义：


	Google: font-family: arial,sans-serif;
	Twitter：font: 13px/1.5 Helvetica Neue,Arial,Helvetica,&apos;Liberation Sans&apos;,FreeSans,sans-serif
	豆瓣：font: 12px/162% Arial,Helvetica,sans-serif;
	新浪微博：font-family: Arial,Helvetica,sans-serif;
	Apple中国：font: 12px/18px &quot;Lucida Grande&quot;,&quot;Lucida Sans Unicode&quot;,Helvetica,Arial,Verdana,sans-serif;
	知乎: font: 13px/22px &apos;Helvetica Neue&apos;,Helvetica,Arial,Sans-serif;
	Facebook: font-family: &quot;lucida grande&quot;,tahoma,verdana,arial,sans-serif;
	Google+: font: 13px arial,sans-serif;


结论：Arial,Helvetica,San-serif 这个组合适配性是最好的,也是最保险的. 可选:Helvetica Neue . 知乎的定义几乎可以直接照用. 

其它：


	微软中国: font-family: Segoe UI,Tahoma,Arial,Verdana,sans-serif;
	淘宝：font: 12px/1.5 tahoma,arial,宋体; //看过淘宝同学写过的很棒的字体文章，估计页面不是统一定义的.
	百度：font: 12px arial;
	QQ: font-family: &quot;宋体&quot;,&quot;Arial Narrow&quot;;
	新浪：font-family: &quot;SimSun&quot;,&quot;Arial Narrow&quot;;　//最烂


结论：用了宋体的，都比较烂 ... 中文网站要想页面视觉稍微好一点，直接去掉 CSS 中的宋体. 

--EOF--

Updated: 对于个人站点，字体可以尽情发挥。

Updated 2: 新浪的同学解释说，之所以用宋体，是因为&quot;宋体的半角字符是等宽字体（1/2个全角），长度的标题不会因出现英文或数字而折行&quot;。估计是历史原因吧，相信这个问题总是有解的，看怎么解决罢了。</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>关于 Web 页面字体这方面，我是门外汉，弄不出来长篇大论 -- 这样也没必要，从观察统计上简单分析一下看看就够了。</p>

<p>几个页面字体适配度比较好的，HTML body 字体的定义：</p>

<ul>
	<li>Google: font-family: arial,sans-serif;</li>
	<li>Twitter：font: 13px/1.5 Helvetica Neue,Arial,Helvetica,'Liberation Sans',FreeSans,sans-serif</li>
	<li>豆瓣：font: 12px/162% Arial,Helvetica,sans-serif;</li>
	<li>新浪微博：font-family: Arial,Helvetica,sans-serif;</li>
	<li>Apple中国：font: 12px/18px "Lucida Grande","Lucida Sans Unicode",Helvetica,Arial,Verdana,sans-serif;</li>
	<li>知乎: font: 13px/22px 'Helvetica Neue',Helvetica,Arial,Sans-serif;</li>
	<li>Facebook: font-family: "lucida grande",tahoma,verdana,arial,sans-serif;</li>
	<li>Google+: font: 13px arial,sans-serif;</li>
</ul>

<p>结论：Arial,Helvetica,San-serif 这个组合适配性是最好的,也是最保险的. 可选:Helvetica Neue . 知乎的定义几乎可以直接照用. </p>

<p>其它：</p>

<ul>
	<li>微软中国: font-family: Segoe UI,Tahoma,Arial,Verdana,sans-serif;</li>
	<li>淘宝：font: 12px/1.5 tahoma,arial,宋体; //看过淘宝同学写过的很棒的字体文章，估计页面不是统一定义的.</li>
	<li>百度：font: 12px arial;</li>
	<li>QQ: font-family: "宋体","Arial Narrow";</li>
	<li>新浪：font-family: "SimSun","Arial Narrow";　//最烂</li>
</ul>

<p>结论：用了宋体的，都比较烂 ... 中文网站要想页面视觉稍微好一点，直接去掉 CSS 中的宋体. </p>

<p>--EOF--</p>

<p>Updated: 对于个人站点，字体可以尽情发挥。</p>

<p>Updated 2: 新浪的同学解释说，之所以用宋体，是因为"宋体的半角字符是等宽字体（1/2个全角），长度的标题不会因出现英文或数字而折行"。估计是历史原因吧，相信这个问题总是有解的，看怎么解决罢了。</p>]]>
        
    </content>
</entry>

<entry>
    <title>新的技术产业：Web Performance Optimization </title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/web_performance_optimization.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/cgi-bin/mt-atom.cgi/weblog/blog_id=1/entry_id=1467" title="新的技术产业：Web Performance Optimization " />
    <id>tag:www.dbanotes.net,2011://1.1467</id>
    
    <published>2011-01-01T14:09:55Z</published>
    <updated>2011-01-13T04:57:23Z</updated>
    
    <summary>在 O&apos;Reilly Velocity China 2010 大会上，业界最有影响里的 Web 性能技术专家 Steve Souders 宣告 Web Performance Optimization (WPO) 时代已经到来。这是个颇为重要的主题演讲，要知道，Google 已经开网站载入时间纳入到搜索排名因素之中(refer)，或许 Web 性能优化，商业网站要考虑作为一项战略来对待了。

我们看一组数据（信息来源）:

Amazon: 增加 100ms 延迟将导致收入下降 1%；
Google: 400 ms 延迟将导致每用户搜索请求下降 0.59%；
Yahoo!: 400ms 延迟会导致流量下降  5-9%；
Bing: 2 秒的延迟将导致收入降低 4.3%/用户(请问，首页用个那么大的背景图干啥?);
Mozilla 将下载页时间缩短 2.2 秒之后下载量增加 15.4%;
Google Maps 将文件大小减少 30% 后请求增加了 30%；
Netflix 在服务器端启用 gzip ，页面快了 13-25%，节省了 50% 的网络流量；
Shopzilla 将页面载入时间从 7秒缩减到 2秒，转化率提升了 7-12%，页面请求增加 25%，只用一半服务器就够了


要注意，这些只是数据，实际上，我们没有办法验证这些数据的真实性。但是可以肯定的是，网站访问速度过慢，一定对用户有负面影响。严重一些的，国外有 Friendster 因为网站访问过慢而导致的用户流失可以作为前车之鉴；网站访问速度快也可以增加竞争优势，比如Tumblr 一骑绝尘而将竞争对手 Posterous 甩在后面。国内这方面的例子比如优酷，斥重金改进用户访问速度，很大程度上保持了竞争优势。

相比投资在硬件上，我个人认为技术团队在 WPO 上的投入是可以用来评估团队技术能力的。有一次在和一位投资人聊起国内的分类网站哪个技术团队更具优势，我毫不犹豫的说看好百姓网，为何？访问一下同类网站，比较一下最终页面访问速度就知道了。这是体现一个技术团队意识和能力的地方。

当前最需要 WPO （甚至有些落后的) 的可能要数电子商务网站以及那些依托于大型 C2C 站点上的网店了。很多电子商务网站负责人非常重视 SEO，但在 SEO 已经快成为一种伪技术的今天，被忽视许久的 WPO 更应该引起重视。举例来说，可能绝大多数淘宝上的大卖家都不懂 Web 相关技术，当然也就无所谓什么 Web 性能优化了。我曾经见过有的卖家首页上一个页面放置几百个图片，一个页面动辄 7-8 Mb，用户访问速度可想而知，如果用户正常浏览都无法做到的话，要想购买产品恐怕也就无从谈起了。如果能对这一部分用户进行有针对性的处理，投入产出的价值还是显而易见的。说起图片来，可能这是最影响电子商务网站访问速度的一个因素，没有针对 Web 优化的图片、过大的尺寸或是失真的压缩图片比比皆是，无疑会严重影响用户体验与购买欲望(这里推荐做电子商务的朋友不妨关注一下 Yupoo.com 专门针对用户的这个需求而推出的图片管家服务)。

WPO 的好处？增加网站营收，降低运营开销，提升访问量，进而提升竞争力。

WPO 做起来其实并没有那么难，通过一些特定的准则(比如 YSlow 14条, refer)即可取得一些卓有成效的改进。期待 WPO 能早日成为 Web 工程师必备的常识。也建议每一个技术团队的负责人应该将 WPO 作为一项战略来抓，而不是只是一两个技术人员的事情。从现在就开始吧。

--EOF--

补充：&quot;快比慢好&quot;，Google 把这句话作为十大价值观之一(refer)。而 Facebook 从创立至今，也一直将提升页面访问速度作为一项重要的策略。

补充一篇必读文章：WPO - Web Performance Optimization</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>在 <a href="http://velocity.oreilly.com.cn">O'Reilly Velocity China 2010</a> 大会上，业界最有影响里的 Web 性能技术专家 <a href="http://stevesouders.com">Steve Souders</a> 宣告 Web Performance Optimization (WPO) 时代已经到来。这是个颇为重要的主题演讲，要知道，Google 已经开网站载入时间纳入到搜索排名因素之中(<a href="http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html">refer</a>)，或许 Web 性能优化，商业网站要考虑作为一项战略来对待了。</p>

<p>我们看一组数据（<a href="http://blog.yottaa.com/2010/11/secret-sauce-for-successful-web-site-web-performance-optimization-wpo/">信息来源</a>）:</p>
<ul>
<li>Amazon: 增加 100ms 延迟将导致收入下降 1%；</li>
<li>Google: 400 ms 延迟将导致每用户搜索请求下降 0.59%；</li>
<li>Yahoo!: 400ms 延迟会导致流量下降  5-9%；</li>
<li>Bing: 2 秒的延迟将导致收入降低 4.3%/用户(请问，首页用个那么大的背景图干啥?);</li>
<li>Mozilla 将下载页时间缩短 2.2 秒之后下载量增加 15.4%;</li>
<li>Google Maps 将文件大小减少 30% 后请求增加了 30%；</li>
<li>Netflix 在服务器端启用 gzip ，页面快了 13-25%，节省了 50% 的网络流量；</li>
<li>Shopzilla 将页面载入时间从 7秒缩减到 2秒，转化率提升了 7-12%，页面请求增加 25%，只用一半服务器就够了</li>
</ul>

<p>要注意，这些只是数据，实际上，我们没有办法验证这些数据的真实性。但是可以肯定的是，网站访问速度过慢，一定对用户有负面影响。严重一些的，国外有 <a href="http://www.Friendster.com/">Friendster</a> 因为网站访问过慢而导致的用户流失可以作为前车之鉴；网站访问速度快也可以增加竞争优势，比如<a href="http://Tumblr.com">Tumblr</a> 一骑绝尘而将竞争对手 <a href="http://www.Posterous.com/">Posterous</a> 甩在后面。国内这方面的例子比如优酷，斥重金改进用户访问速度，很大程度上保持了竞争优势。</p>

<p>相比投资在硬件上，我个人认为技术团队在 WPO 上的投入是可以用来评估团队技术能力的。有一次在和一位投资人聊起国内的分类网站哪个技术团队更具优势，我毫不犹豫的说看好百姓网，为何？访问一下同类网站，比较一下最终页面访问速度就知道了。这是体现一个技术团队意识和能力的地方。</p>

<p>当前最需要 WPO （甚至有些落后的) 的可能要数电子商务网站以及那些依托于大型 C2C 站点上的网店了。很多电子商务网站负责人非常重视 SEO，但在 SEO 已经快成为一种伪技术的今天，被忽视许久的 WPO 更应该引起重视。举例来说，可能绝大多数淘宝上的大卖家都不懂 Web 相关技术，当然也就无所谓什么 Web 性能优化了。我曾经见过有的卖家首页上一个页面放置几百个图片，一个页面动辄 7-8 Mb，用户访问速度可想而知，如果用户正常浏览都无法做到的话，要想购买产品恐怕也就无从谈起了。如果能对这一部分用户进行有针对性的处理，投入产出的价值还是显而易见的。说起图片来，可能这是最影响电子商务网站访问速度的一个因素，没有针对 Web 优化的图片、过大的尺寸或是失真的压缩图片比比皆是，无疑会严重影响用户体验与购买欲望(这里推荐做电子商务的朋友不妨关注一下 <a href="http://www.yupoo.com/">Yupoo.com</a> 专门针对用户的这个需求而推出的<a href="http://v.yupoo.com/">图片管家</a>服务)。</p>

<p>WPO 的好处？<strong>增加网站营收，降低运营开销，提升访问量，进而提升竞争力</strong>。</p>

<p>WPO 做起来其实并没有那么难，通过一些特定的准则(比如 YSlow 14条, <a href="http://www.dbanotes.net/web-performance.html">refer</a>)即可取得一些卓有成效的改进。期待 WPO 能早日成为 Web 工程师必备的<strong>常识</strong>。也建议每一个技术团队的负责人应该将 WPO 作为一项战略来抓，而不是只是一两个技术人员的事情。从现在就开始吧。</p>

<p>--EOF--</p>

<p>补充："快比慢好"，Google 把这句话作为十大价值观之一(<a href="http://www.google.com/intl/en/corporate/tenthings.html">refer</a>)。而 Facebook 从创立至今，也一直将提升页面访问速度作为一项重要的策略。</p>

<p>补充一篇必读文章：<a href="http://www.stevesouders.com/blog/2010/05/07/wpo-web-performance-optimization/">WPO - Web Performance Optimization</a></p>]]>
        
    </content>
</entry>

<entry>
    <title>《实战 Nginx》 读后</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/Practice_Nginx.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/cgi-bin/mt-atom.cgi/weblog/blog_id=1/entry_id=1412" title="《实战 Nginx》 读后" />
    <id>tag:www.dbanotes.net,2010://1.1412</id>
    
    <published>2010-04-20T00:55:17Z</published>
    <updated>2010-04-21T08:55:15Z</updated>
    
    <summary>拿到这本 《实战 Nginx》 有几天了，休假期间将感兴趣的几章阅读完毕。作者张宴是国内 Nginx 最早的技术传播者之一，产生的影响也最大，他的一系列 Nginx 实战的文章相信让很多 Nginx 用户受益良多。

尽管之前已经在他的网络文章或者 PPT 里看到过这本书里包含的一些内容，我还是要说一下第六章中的架构图是这本书中非常有参考价值的内容(至少对我如此)，作为网站维护者，即使不用 Nginx，这几张图也非常值得分析一下。对于从 Apache 迁移到 Nginx 的用户，第七章关于 Rewrite 规则的讲解则不可错过。

这本书的最大缺点或者说不够严谨的地方，我觉得主要是体现在某些章节上关于设置项的说明缺少足够的阐释，比如&quot;优化 Linux 内核参数&quot;、&quot;MySQL 5.1 配置优化&quot;等内容如果添加足以让读者查找更多信息的注释就更好了。另外，从章节的安排上，如果多一节专门讲述 Nginx 优化的内容或许也会不错。

对于没有 Nginx 经验或者是想进一步了解 Nginx 的系统工程师，这本书是值得一读的。这本书的定价不过是一张电影票的价钱，如果可以解答你在工作中的几个技术问题，你说是否值得购买呢? 

--EOF--</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>拿到这本 <a href="http://book.douban.com/subject/4251875/">《实战 Nginx》</a> 有几天了，休假期间将感兴趣的几章阅读完毕。作者<a href="http://blog.s135.com/">张宴</a>是国内 <a href="http://www.nginx.net">Nginx</a> 最早的技术传播者之一，产生的影响也最大，他的一系列 Nginx 实战的文章相信让很多 Nginx 用户受益良多。</p>

<p>尽管之前已经在他的网络文章或者 PPT 里看到过这本书里包含的一些内容，我还是要说一下第六章中的架构图是这本书中非常有参考价值的内容(至少对我如此)，作为网站维护者，即使不用 Nginx，这几张图也非常值得分析一下。对于从 Apache 迁移到 Nginx 的用户，第七章关于 Rewrite 规则的讲解则不可错过。</p>

<p>这本书的最大缺点或者说不够严谨的地方，我觉得主要是体现在某些章节上关于设置项的说明缺少足够的阐释，比如"优化 Linux 内核参数"、"MySQL 5.1 配置优化"等内容如果添加足以让读者查找更多信息的注释就更好了。另外，从章节的安排上，如果多一节专门讲述 Nginx 优化的内容或许也会不错。</p>

<p>对于没有 Nginx 经验或者是想进一步了解 Nginx 的系统工程师，这本书是值得一读的。这本书的定价不过是一张电影票的价钱，如果可以解答你在工作中的几个技术问题，你说是否值得购买呢? </p>

<p>--EOF--</p>]]>
        
    </content>
</entry>

<entry>
    <title>1e100.net，来自 Google</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/1e100_dot_net_google.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/cgi-bin/mt-atom.cgi/weblog/blog_id=1/entry_id=1385" title="1e100.net，来自 Google" />
    <id>tag:www.dbanotes.net,2010://1.1385</id>
    
    <published>2010-01-20T13:13:43Z</published>
    <updated>2011-12-11T06:54:46Z</updated>
    
    <summary>在 Alexa 上观测最近的一些数据的变化，发现了一个奇怪的域名: 1e100.net ，全球排名 45 。乍看上去，这个域名非常山寨，不过查询一下，发现这居然是 Google 的域名。Google 的名字是 Googol 这个单词拼错得来的，而 Googol 就是 10100 这个大数。1e100 = 1x10^100 = Googol  (refer)。Twitter 上也有网友对此进行了提示。



这么看来，1e100 这样的域名风格倒是很 Google 化。从网上的反馈看，Google 有不少服务都在使用 1e100.net 这个域名，最多的应该是 Google Chrome 浏览器的 Safe Browsing 特性对地址的使用(对 Firefox 也有影响)，而且会启用较多的并发连接，所以会有网站对此带来的压力无法承受而屏蔽 Google 的这个服务(refer)，此外也让我想起以前 Google Chrome 早期的版本解析 DNS 多少有点慢，不知道是否有相关因果关系。Google 的其它产品包括 Google Toolbar、Google Analytics、YouTube 、FeedBurner 等服务也用这个域名。也有人发现 Google IPV6 地址也是通过这域名在进行测试。不过直接访问 1e100.net 是访问不到的，Google 通过子域名的形式进行使用。

按理说，这种不对外提供服务的地址，Alexa 没必要统计流量的，或许是他们的小失误倒是让我们了解到 Google 的一点有趣的信息。

--EOF--

更多参考：


	Why is goog using 1e100.net?  解释了为什么不是 10e100.net 。
	Google 的 Project 10100 项目。
	Google doppelgänger casts riddle over interwebs


更新：最新的消息说是 Google 不同数据中心间用来&quot; identify servers, hinting that reverse DNS plays a role&quot; ，关键词&quot;Spanner&quot;。

Google 现在有官方解释了：What is 1e100.net?
用于标记Google网络中的服务。主要有两个目的：1) 保持简单性; 2) 加强安全。</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>在 Alexa 上观测最近的一些数据的变化，发现了一个奇怪的域名: 1e100.net ，全球排名 45 。乍看上去，这个域名非常山寨，不过查询一下，发现这居然是 Google 的域名。Google 的名字是 <a href="http://en.wikipedia.org/wiki/Googol">Googol</a> 这个单词拼错得来的，而 Googol 就是 10<sup>100</sup> 这个大数。1e100 = 1x10^100 = Googol  (<a href="http://superuser.com/questions/75841/what-is-1e100-net-and-why-do-i-have-tcp-ports-open-to-it">refer</a>)。Twitter 上也有网友对此进行了提示。</p>

<p><img alt="1e100.net.png" src="http://www.dbanotes.net/Images/1e100.net.png" width="400" height="220" class="mt-image-none" style="" /></p>

<p>这么看来，1e100 这样的域名风格倒是很 Google 化。从网上的反馈看，Google 有不少服务都在使用 1e100.net 这个域名，最多的应该是 Google Chrome 浏览器的 <a href="http://www.google.com/tools/firefox/safebrowsing/">Safe Browsing</a> 特性对地址的使用(对 Firefox 也有影响)，而且会启用较多的并发连接，所以会有网站对此带来的压力无法承受而屏蔽 Google 的这个服务(<a href="http://kingofgng.com/eng/2009/08/29/why-the-fool-blocks-google-safe-browsing/">refer</a>)，此外也让我想起以前 Google Chrome 早期的版本解析 DNS 多少有点慢，不知道是否有相关因果关系。Google 的其它产品包括 Google Toolbar、Google Analytics、YouTube 、FeedBurner 等服务也用这个域名。也有人发现 Google IPV6 地址也是通过这域名在进行测试。不过直接访问 1e100.net 是访问不到的，Google 通过子域名的形式进行使用。</p>

<p>按理说，这种不对外提供服务的地址，Alexa 没必要统计流量的，或许是他们的小失误倒是让我们了解到 Google 的一点有趣的信息。</p>

<p>--EOF--</p>

<p>更多参考：</p>

<ul>
	<li><a href="http://www.webmasterworld.com/google/4050443.htm">Why is goog using 1e100.net?</a>  解释了为什么不是 10e100.net 。</li>
	<li>Google 的 <a href="http://www.project10tothe100.com/">Project 10<sup>100</sup></a> 项目。</li>
	<li><a href="http://www.theregister.co.uk/2010/02/08/google_mystery_domain/">Google doppelgänger casts riddle over interwebs</a></li>
</ul>

<p>更新：最新的消息说是 Google 不同数据中心间用来" identify servers, hinting that reverse DNS plays a role" ，关键词"Spanner"。</p>

<p>Google 现在有官方解释了：<a href="http://support.google.com/bin/answer.py?hl=en&answer=174717">What is 1e100.net?</a>
用于标记Google网络中的服务。主要有两个目的：1) 保持简单性; 2) 加强安全。</p>]]>
        
    </content>
</entry>

<entry>
    <title>消除小型 Web 站点单点故障(Single Point of Failure)</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/web_single_point_of_failure.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/cgi-bin/mt-atom.cgi/weblog/blog_id=1/entry_id=1264" title="消除小型 Web 站点单点故障(Single Point of Failure)" />
    <id>tag:www.dbanotes.net,2009://1.1264</id>
    
    <published>2009-11-26T12:08:34Z</published>
    <updated>2011-05-19T05:06:02Z</updated>
    
    <summary>针对小型站点的技术普及信息，中大型网站的牛人不用看，耽误您的时间我负不起这责任。用 Windows 做网站的也别看了，不适合。

说起单点故障(Single Point of Failure，SPOF)，倒是可以想起电影 《2012》中，一把焊枪把齿轮卡住，从而导致整个舱门无法关闭，进而整个引擎无法发动。这是个有点生动的例子--如此庞大的一个系统，居然因为一把小小的焊枪而险些毁于一旦。投入巨大人力物力生产的救命方舟居然做不到高可用(High availability)，这是致命的事情。

大脑对与人来说，就是一个单点，大脑损坏，人也完蛋；手是不是单点? 一只没了，另一只还能日常生活，从这个角度来说，不是单点。消除单点的最常见的做法：增加冗余。比如，人有两只手。其次，层次化。当然，分层的目的是便于隔离问题。电影 《2012》 中的这个问题，不知道谁是总架构师，看起来，隔离做得不太够 :) 

一般来说，只要系统能够比较清楚的分出层次来，要消除单点故障还是有章可循的事情。比如，一个网站，从基础的硬件层，到操作系统层，到数据库层，到应用程序层，再到网络层，都有可能产生单点故障。如果要有效的消除单点故障，最重要的一点是设计的时候要尽量避免引入单点，而随着架构的变化，定期审查系统潜在单点也是有必要的。

有人或许会问，假设一个起步中的站点，只有一台服务器，什么东西都在一个盒子里，到底要怎么做呢? 这里的建议是先抛开主板、CPU 、内存这些，首先必须考虑硬盘(存储层)的问题，如果机器只有一块硬盘，即使你备份计划再完善(不要说你的备份也是备份在这块硬盘上的)，还是建议你起码再弄一块。做镜像，让出错的概率降低，这是划算的投入，当然消除单点，成本几乎不可避免的要增加。如果硬盘多，或者有其他备份机制，可选的方法就更多，别刻舟求剑。

第二个要考虑网卡与网线的单点问题。先说网线，如果要问一个系统里面最容易物理损坏的是哪个组件，答案恐怕非网线莫属，对于网线这样多数时候因为距离需要定制的东西，总是购买成品还是有成本的，从我观察到的情况来看，各个 IDC 的网线使用手工制作的比例不小，这个质量几乎很难控制，一根线，两个水晶头，哪一个出问题都不能正常传输。怎么办? 想办法提升网线整体质量还是弄两根网线放在那里? 解决办法早都有了，网卡绑定 (NIC bonding)一个很简单很通用的办法(refer)，但是问题是并非很多人在用。多数 PC 服务器应该都是配置了多块网卡，如果是自己攒服务器，记得网卡多一块成本没多大，但是用处会有很多。如果耐着性子看到这里，先别急着去 Google，还有问题呢，两根网线如何接到上行交换机，什么样的交换机支持绑定，如何确定绑定是真正生效的? 答案是，尝试一下。

然后是什么? 是跑多个数据库，还是跑两个 Web 服务器，一个不行用另一个顶? 对于单台服务器，其它能消除单点的地方恐怕收效也不会特别大，现在少做无用功，或许要重点考虑如何备份，如何优化，以及出现问题的时候如何做到快速恢复。有一个或许会引起争议的建议是，除了 SSH 登录之外，要不要留一个 Telnet 登录的服务呢? 毕竟 SSH 服务器端守护进程不是百分百靠谱的事儿，如果 IDC 距离较远，需要斟酌一下。好吧，网站有了一点发展，用户量也增加了，感觉需要增加服务器了。再增加一台服务器，抗风险能力一下子加强了许多，毕竟一台机器质量再好，也有出错的时候。现在，Web 服务器、DB 服务器可以考虑引入 HA 的方案，如果单台服务能力够，主备模式也不错。随着网站的发展，服务器数量继续增加...

随着服务器数量的增加，到了必须要自己购买网络设备的时候了。同样的设备，一买恐怕就要买双份，原因无它--一台总要出错，哪怕是电源被拔错--而这样的情况实际上并不少见。如果预算不够，那就再等等，但是要记住，定期审查，有可能的话，进行弥补总不会错。

到现在，所有的服务器都还在一个 IDC 呢，IDC 本身也是个单点啊，服务器被黑怎么办? 机房光线被施工工人挖断怎么办? 机房停电怎么办? 找第二个机房吧。现在选 IDC 首先要考虑什么? 中国特色的互联网问题总要考虑吧，&quot;南北互通&quot;怎么样...或许在选择第一个机房的时候已经遇到了类似的问题，或许现在正在受到这个问题的困扰。选好 IDC 之后，首先计划一下数据如何备份过来，然后，网站的配置信息如何同步或备份过来(这是保证第一个 IDC 出了致命问题之后的最基本的恢复要求)。多个 IDC 之后不得不提上议程的要算 DNS 这个事儿了。你的 DNS 解析商靠谱么? 如果域名提供商遭受攻击，对自己的网站影响能承受么?

更多的服务器，提供更多的应用，更多的用户，更多的收入... 接下来该怎么办呢? 现在，您所面对的已经不是一个小型 Web 站点了，可以不用看这篇文章了。

到现在，我还没说人的问题，如果这些信息只有一个人知道，万一这个人出了点事情怎么办? 作为老板，还要考虑人的单点问题。

--EOF--

Updated: DNS 的健康程度检查重要性应该提升一些。如何检查？有很多在线的工具可供使用，简单直接。

</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<pre>针对小型站点的技术普及信息，中大型网站的牛人不用看，耽误您的时间我负不起这责任。<br />用 Windows 做网站的也别看了，不适合。</pre>

<p>说起单点故障(Single Point of Failure，SPOF)，倒是可以想起电影 《2012》中，一把焊枪把齿轮卡住，从而导致整个舱门无法关闭，进而整个引擎无法发动。这是个有点生动的例子--如此庞大的一个系统，居然因为一把小小的焊枪而险些毁于一旦。投入巨大人力物力生产的救命方舟居然做不到高可用(High availability)，这是致命的事情。</p>

<p>大脑对与人来说，就是一个单点，大脑损坏，人也完蛋；手是不是单点? 一只没了，另一只还能日常生活，从这个角度来说，不是单点。消除单点的最常见的做法：<strong>增加冗余</strong>。比如，人有两只手。其次，<strong>层次化</strong>。当然，分层的目的是便于隔离问题。电影 《2012》 中的这个问题，不知道谁是总架构师，看起来，隔离做得不太够 :) </p>

<p>一般来说，只要系统能够比较清楚的分出层次来，要消除单点故障还是有章可循的事情。比如，一个网站，从基础的硬件层，到操作系统层，到数据库层，到应用程序层，再到网络层，都有可能产生单点故障。如果要有效的消除单点故障，最重要的一点是设计的时候要尽量避免引入单点，而随着架构的变化，定期审查系统潜在单点也是有必要的。</p>

<p>有人或许会问，假设一个起步中的站点，只有一台服务器，什么东西都在一个盒子里，到底要怎么做呢? 这里的建议是先抛开主板、CPU 、内存这些，首先必须考虑硬盘(存储层)的问题，如果机器只有一块硬盘，即使你备份计划再完善(不要说你的备份也是备份在这块硬盘上的)，还是建议你起码再弄一块。做镜像，让出错的概率降低，这是划算的投入，当然消除单点，成本几乎不可避免的要增加。如果硬盘多，或者有其他备份机制，可选的方法就更多，别刻舟求剑。</p>

<p>第二个要考虑网卡与网线的单点问题。先说网线，如果要问一个系统里面最容易物理损坏的是哪个组件，答案恐怕非网线莫属，对于网线这样多数时候因为距离需要定制的东西，总是购买成品还是有成本的，从我观察到的情况来看，各个 IDC 的网线使用手工制作的比例不小，这个质量几乎很难控制，一根线，两个水晶头，哪一个出问题都不能正常传输。怎么办? 想办法提升网线整体质量还是弄两根网线放在那里? 解决办法早都有了，网卡绑定 (NIC bonding)一个很简单很通用的办法(<a href="http://www.cyberciti.biz/tips/linux-bond-or-team-multiple-network-interfaces-nic-into-single-interface.html">refer</a>)，但是问题是并非很多人在用。多数 PC 服务器应该都是配置了多块网卡，如果是自己攒服务器，记得网卡多一块成本没多大，但是用处会有很多。如果耐着性子看到这里，先别急着去 Google，还有问题呢，两根网线如何接到上行交换机，什么样的交换机支持绑定，如何确定绑定是真正生效的? 答案是，尝试一下。</p>

<p>然后是什么? 是跑多个数据库，还是跑两个 Web 服务器，一个不行用另一个顶? 对于单台服务器，其它能消除单点的地方恐怕收效也不会特别大，现在少做无用功，或许要重点考虑如何备份，如何优化，以及出现问题的时候如何做到快速恢复。有一个或许会引起争议的建议是，除了 SSH 登录之外，要不要留一个 Telnet 登录的服务呢? 毕竟 SSH 服务器端守护进程不是百分百靠谱的事儿，如果 IDC 距离较远，需要斟酌一下。好吧，网站有了一点发展，用户量也增加了，感觉需要增加服务器了。再增加一台服务器，抗风险能力一下子加强了许多，毕竟一台机器质量再好，也有出错的时候。现在，Web 服务器、DB 服务器可以考虑引入 HA 的方案，如果单台服务能力够，主备模式也不错。随着网站的发展，服务器数量继续增加...</p>

<p>随着服务器数量的增加，到了必须要自己购买网络设备的时候了。同样的设备，一买恐怕就要买双份，原因无它--一台总要出错，哪怕是电源被拔错--而这样的情况实际上并不少见。如果预算不够，那就再等等，但是要记住，<strong>定期审查</strong>，有可能的话，进行弥补总不会错。</p>

<p>到现在，所有的服务器都还在一个 IDC 呢，IDC 本身也是个单点啊，服务器被黑怎么办? 机房光线被施工工人挖断怎么办? 机房停电怎么办? 找第二个机房吧。现在选 IDC 首先要考虑什么? 中国特色的互联网问题总要考虑吧，"南北互通"怎么样...或许在选择第一个机房的时候已经遇到了类似的问题，或许现在正在受到这个问题的困扰。选好 IDC 之后，首先计划一下数据如何备份过来，然后，网站的配置信息如何同步或备份过来(这是保证第一个 IDC 出了致命问题之后的最基本的恢复要求)。多个 IDC 之后不得不提上议程的要算 DNS 这个事儿了。你的 DNS 解析商靠谱么? 如果域名提供商遭受攻击，对自己的网站影响能承受么?</p>

<p>更多的服务器，提供更多的应用，更多的用户，更多的收入... 接下来该怎么办呢? 现在，您所面对的已经不是一个小型 Web 站点了，可以不用看这篇文章了。</p>

<p>到现在，我还没说人的问题，如果这些信息只有一个人知道，万一这个人出了点事情怎么办? 作为老板，还要考虑人的单点问题。</p>

<p>--EOF--</p>

<p>Updated: DNS 的健康程度检查重要性应该提升一些。如何检查？有很多在线的工具可供使用，简单直接。</p>]]>
        
    </content>
</entry>

<entry>
    <title>网站优化应重视 DNS 预获取(DNS Prefetching)</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/dns_prefetching.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/cgi-bin/mt-atom.cgi/weblog/blog_id=1/entry_id=1321" title="网站优化应重视 DNS 预获取(DNS Prefetching)" />
    <id>tag:74.207.252.114,2009://1.1321</id>
    
    <published>2009-07-12T12:41:03Z</published>
    <updated>2009-11-23T10:07:18Z</updated>
    
    <summary><![CDATA[网站优化技术总是在进化。今天重新阅读了一下以前的前端优化笔记，发现对于 YSlow 优化 34 条准则关于减少 DNS 查找 (Reduce DNS Lookups)的部分或许应该修正一下了。

DNS 作为互联网的基础协议，其解析的速度似乎容易被网站优化人员忽视。现在浏览器厂商已经有在针对 DNS 进行优化，典型的一次 DNS 解析耗费 20-120 毫秒，减少 DNS 解析数是个优化的方式，而能够缩减 DNS 解析的时间也是有经济效益的事情。这就是浏览器厂商重视 DNS Prefetching 的主要原因。DNS Prefetching 对于性能的收益可以简单的用"DNS 同步请求到异步"来解释，也就是具有此属性的域名不需要用户点击链接就在后台解析，而域名解析和内容载入是串行的网络操作，所以这个方式能减少用户的等待时间，提升用户体验。

Google Chrome 内置就有 DNS Prefetching 技术(注意之前有几个小版本因为这一特性反而带来了性能问题) ，而 Firefox 3.5 也引入了这一 新特性。至于 IE 8，暂时还看不到有什么举措(或许是我没注意到?)。 

对于一个网站来说，如果希望能充分利用用户浏览器端的这个功能，可以在页面添加 link 属性的锚点来做到。类似：

&lt;link rel="dns-prefetch" href="http://www.google-analytics.com/"&gt;


另外还有这个 x-dns-prefetch-control 也有必要适当用一下。对于某些站点引用了 Google 的某些服务脚本，可能这尤其有用。

另外一种加速 DNS 的途径是考虑使用 pdnsd 之类的缓存 DNS 代理服务器来加速某些 DNS 请求。

在 Chrome 中，可以通过在地址栏输入 about:histograms/DNS 来观测一些有趣的 DNS 性能数据。

--EOF--]]></summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>网站优化技术总是在进化。今天重新阅读了一下以前的<a href="http://www.dbanotes.net/web-performance.html">前端优化笔记</a>，发现对于 <a href="http://developer.yahoo.com/performance/">YSlow 优化 34 </a>条准则关于减少 DNS 查找 (Reduce DNS Lookups)的部分或许应该修正一下了。</p>

<p>DNS 作为互联网的基础协议，其解析的速度似乎容易被网站优化人员忽视。现在浏览器厂商已经有在针对 DNS 进行优化，典型的一次 DNS 解析耗费 20-120 毫秒，减少 DNS 解析数是个优化的方式，而能够缩减 DNS 解析的时间也是有经济效益的事情。这就是浏览器厂商重视 DNS Prefetching 的主要原因。DNS Prefetching 对于性能的收益可以简单的用"DNS 同步请求到异步"来解释，也就是具有此属性的域名不需要用户点击链接就在后台解析，而域名解析和内容载入是串行的网络操作，所以这个方式能减少用户的等待时间，提升用户体验。</p>

<p>Google Chrome 内置就有 <a href="http://blog.chromium.org/2008/09/dns-prefetching-or-pre-resolving.html">DNS Prefetching </a>技术(注意之前有几个小版本因为这一特性反而带来了性能问题) ，而 Firefox 3.5 也引入了这一 <a href="https://developer.mozilla.org/En/Controlling_DNS_prefetching">新特性</a>。至于 IE 8，暂时还看不到有什么举措(或许是我没注意到?)。 </p>

<p>对于一个网站来说，如果希望能充分利用用户浏览器端的这个功能，可以在页面添加 link 属性的锚点来做到。类似：</p>

<pre>&lt;link rel="dns-prefetch" href="http://www.google-analytics.com/"&gt;
</pre>

<p>另外还有这个 x-dns-prefetch-control 也有必要适当用一下。对于某些站点引用了 Google 的某些服务脚本，可能这尤其有用。</p>

<p>另外一种加速 DNS 的途径是考虑使用 <a href="http://members.home.nl/p.a.rombouts/pdnsd/index.html#aboutpdnsd">pdnsd</a> 之类的缓存 DNS 代理服务器来加速某些 DNS 请求。</p>

<p>在 Chrome 中，可以通过在地址栏输入 about:histograms/DNS 来观测一些有趣的 DNS 性能数据。</p>

<p>--EOF--</p>]]>
        
    </content>
</entry>

<entry>
    <title>登陆框的密码遮盖问题以及其他</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/stop_password_masking.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/cgi-bin/mt-atom.cgi/weblog/blog_id=1/entry_id=1320" title="登陆框的密码遮盖问题以及其他" />
    <id>tag:74.207.252.114,2009://1.1320</id>
    
    <published>2009-07-10T00:35:34Z</published>
    <updated>2009-11-23T10:07:18Z</updated>
    
    <summary>几天前看到的这个关于密码遮盖（Password Masking) 问题的讨论，顺着链接有找到了一些讨论来看，继而发现相关文章已经有人翻译了(refer)，但中文技术社区好像很少见到讨论(也可能是我孤陋寡闻)。

这是个令人印象深刻的话题，因为挑战的是习惯性的设计方式。放眼看去，所有需要输入密码才可登录的网站都是遮盖密码的。密码遮盖带来的坏处是显而易见--用户的输入成了盲区，不知道自己输入的是否对，点击登录变成了变相的试错操作，产生比较多的再次登录操作，对给用户造成非常糟糕的使用感受。然而似乎很少有人如何去考虑改进这个现状。关注别人视而不见的问题才会带来革新与创新，要不怎么说人家 Jakob Nielsen 是用户体验方面的大牛呢，要从别人口中出来这个论断可能会被人笑话，而大牛就敢于挑战常规，弄个问题就给大家带来思考了--扯远了。

似乎多数人赞同添加一个额外的检查框（CheckBox），安全性要求不高的应用，默认不遮挡，用户输入完毕之后，再选择旁边的检查框对密码进行遮挡；对于安全性要求比较高的应用，默认密码遮挡，但可以选择显示一下密码明文一下，方便用户检查是否有拼写错误。

如果你用过苹果的产品，比如 iPhone 新 OS 3.0 的版本，你会发现密码的处理又进了一步，密码输入时是显示明文的，方便用户确认没有输错，在几秒钟后或者输入下一个字符的时候再对这个字符遮盖。(很多移动厂商好像现在都这么设计了)


(截图有点喧宾夺主，对付着看吧)

这个想法真的很让人欣赏，对于手持设备能够比较有效的防止了窥探(peeking over your shoulder)，也减少了用户输入错误的频率。只是不知道是不是已经被手机厂商申请了专利。对于大屏幕显示器来说，窥探的可能性有多大？缺乏数据支持，很难说明。或许，这里的安全专家的分析对质疑者也会有点帮助。

其实我觉得密码遮盖问题在用户初次注册的时候带来的问题尤其严重。在这个环节如果添加一个 CheckBox 要用户知道自己连续两次输入的密码是什么应该是有必要的(有人举手同意麽?) ，否则的话，用户要的密码可能不是自己输入的，短时间内连续两次输入，出现键入错误的几率并非不存在。 

好吧，现在开始审视一下自己的网站登录框设计以及注册页面吧...新的问题或许是，你有勇气做点修改麽?



如果觉得上面说的都是废话，那么不妨考虑这两个问题：


	为什么我们之前就没考虑到这一点?
	如何才能先于别人一步想到这一点?


--EOF--

延伸阅读：Better Password Inputs, iPhone Style</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>几天前看到的这个<a href="http://www.webmasterworld.com/accessibility_usability/3939513.htm">关于密码遮盖（Password Masking) 问题</a>的讨论，顺着链接有找到了一些讨论来看，继而发现相关文章已经有人翻译了(<a href="http://www.yeeyan.com/articles/view/%E5%8D%9A%E8%B4%A4/48166?orgin=top">refer</a>)，但中文技术社区好像很少见到讨论(也可能是我孤陋寡闻)。</p>

<p>这是个令人印象深刻的话题，因为挑战的是习惯性的设计方式。放眼看去，所有需要输入密码才可登录的网站都是遮盖密码的。密码遮盖带来的坏处是显而易见--用户的输入成了盲区，不知道自己输入的是否对，点击登录变成了变相的试错操作，产生比较多的再次登录操作，对给用户造成非常糟糕的使用感受。然而似乎很少有人如何去考虑改进这个现状。关注别人视而不见的问题才会带来革新与创新，要不怎么说人家 <a href="http://www.useit.com/jakob/">Jakob Nielsen</a> 是用户体验方面的大牛呢，要从别人口中出来这个论断可能会被人笑话，而大牛就敢于挑战常规，弄个问题就给大家带来思考了--扯远了。</p>

<p>似乎多数人赞同添加一个额外的检查框（CheckBox），安全性要求不高的应用，默认不遮挡，用户输入完毕之后，再选择旁边的检查框对密码进行遮挡；对于安全性要求比较高的应用，默认密码遮挡，但可以选择显示一下密码明文一下，方便用户检查是否有拼写错误。</p>

<p>如果你用过苹果的产品，比如 iPhone 新 OS 3.0 的版本，你会发现密码的处理又进了一步，密码输入时是显示明文的，方便用户确认没有输错，在几秒钟后或者输入下一个字符的时候再对这个字符遮盖。(很多移动厂商好像现在都这么设计了)</p>

<p><span class="mt-enclosure mt-enclosure-image" style="display: inline;"><img alt="iPhone_Password_Masking.png" src="http://www.dbanotes.net/Images/iPhone_Password_Masking.png" width="480" height="320" class="mt-image-none" style="" /></span><br />
<p>(截图有点喧宾夺主，对付着看吧)</p></p>

<p>这个想法真的很让人欣赏，对于手持设备能够比较有效的防止了窥探(peeking over your shoulder)，也减少了用户输入错误的频率。只是不知道是不是已经被手机厂商申请了专利。对于大屏幕显示器来说，窥探的可能性有多大？缺乏数据支持，很难说明。或许，这里的<a href="https://blogs.sans.org/appsecstreetfighter/2009/06/28/response-to-nielsens-stop-password-masking/">安全专家的分析</a>对质疑者也会有点帮助。</p>

<p>其实我觉得<strong>密码遮盖问题在用户初次注册的时候带来的问题尤其严重</strong>。在这个环节如果添加一个 CheckBox 要用户知道自己连续两次输入的密码是什么应该是有必要的(有人举手同意麽?) ，否则的话，用户要的密码可能不是自己输入的，短时间内连续两次输入，出现键入错误的几率并非不存在。 </p>

<p>好吧，现在开始审视一下自己的网站登录框设计以及注册页面吧...新的问题或许是，你有勇气做点修改麽?</p>

<hr />

<p>如果觉得上面说的都是废话，那么不妨考虑这两个问题：</p>

<ul>
	<li>为什么我们之前就没考虑到这一点?</li>
	<li>如何才能先于别人一步想到这一点?</li>
</ul>

<p>--EOF--</p>

<p>延伸阅读：<a href="http://css-tricks.com/better-password-inputs-iphone-style/">Better Password Inputs, iPhone Style</a></p>]]>
        
    </content>
</entry>

<entry>
    <title>关于团队 BLOG 这件事</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/team_blog.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/cgi-bin/mt-atom.cgi/weblog/blog_id=1/entry_id=1284" title="关于团队 BLOG 这件事" />
    <id>tag:74.207.252.114,2009://1.1284</id>
    
    <published>2009-06-02T10:12:11Z</published>
    <updated>2010-01-11T14:09:31Z</updated>
    
    <summary>现在网络上已经可以看到很多公司的团队对外的 BLOG ，关于这个话题，在这里记录一下我的一些个人看法。当然贵团队如果已经开博或者即将开博的话，毋须照搬，这不是什么指导。

明确团队开博目的

首先必须确定要传递哪些信息给读者? 宣传公司团队文化? 技术宣传? 产品宣传? 还是兼而有之? 如果只是为了跟风，那就没必要的。实际上，我相信大部分团队 BLOG 不过是跟风而已，不过跟风跟的好，也能起到不错的作用。如果能认真经营 BLOG ，它就能给你带来价值，超乎你想象的价值。

一般而言，建议对外开博前，可以在内部先试运行一下，给大家熟悉网络环境一个缓冲期。

不与业绩指标挂钩 

据说很多团队的 BLOG 居然和 KPI 挂钩的，这是非常不适合的做法。很明显这会导致一个现象：到了接近考核的时候，团队每个成员都流水帐一样连发多篇文章凑数，对读者来说，是一种信息轰炸，起不到什么正面作用，对团队多数成员来说，也觉得这样圆满完成任务也不错嘛，势必影响真正用心写文章的成员。当然我相信很多人看了我这个帖子后会改变 KPI 的设置方式，比如&quot;每月要发布几篇&quot;... 简言之，本末倒置。

控制文章发布频率

团队 BLOG 管理员(没错，应该有个管理员)应该控制文章正式发布的频率。细水长流，尤佳。记住，节奏最有力量。

控制频率的另外一点是要做好长期性准备，不要几天热乎劲儿过去之后就乏于更新。如果潜在读者偶尔访问过来，发现最近一篇更新是一年前，或许就会留下负面印象。

不要强制团队成员

必须要认清的一件事情是，一个团队中，肯定有些人员的确不善于文字表达，如果要他写一篇文章，可能比杀了他还更难受。如果强制性的压着他憋文章，恐怕只能适得其反。好的方式是发起者能够引导团队成员中的那些低调者，使他觉得这事情有意思，可以尝试一下，能够更多锻炼自己。比如针对技术人员来说，写文章过程中如果熟悉一下 HTML 基本语法，在日常工作中也不无裨益。

不要堆砌垃圾文章

这里面的一条铁律是：不要转贴那些网上随处可见的&quot;心得&quot;，&quot;感悟&quot;之类的心灵鸡汤文章，那些文章不能改变外界对你团队的正面看法(当然有可能增加负面看法)。适当的转载关于自己团队或者公司的第三方文章是可以接受的。

记住，垃圾信息和网站质量成反比的。信息不是越多越好。

内容格式非常重要

内容是团队向外展示的载体，固然重要，可如果文章不经过很好的格式化，就好比一块好田地长满了庄稼也同样长满野草一样让人讨厌。这是如此简单的一点，但我们还是能看到有许多团队对此熟视无睹。一篇连段落都不分的技术文章内容再好，也不会有更多技术人喜欢看。

不但 Web 页面要注重格式化，对 RSS 输出也同样也要注意，甚至应该更加以重视。至于输出全文，那是必须的。团队 BLOG 不要在乎什么 PV 之类的事情，那是非常土鳖的做法。内容是否有价值，不在于有多少人看了这篇文章，而是有多少目标读者从中得到收益。

--待续-</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>现在网络上已经可以看到很多公司的团队对外的 BLOG ，关于这个话题，在这里记录一下我的一些个人看法。当然贵团队如果已经开博或者即将开博的话，毋须照搬，这不是什么指导。</p>

<h4>明确团队开博目的</h4>

<p>首先必须确定要传递哪些信息给读者? 宣传公司团队文化? 技术宣传? 产品宣传? 还是兼而有之? 如果只是为了跟风，那就没必要的。实际上，我相信大部分团队 BLOG 不过是跟风而已，不过跟风跟的好，也能起到不错的作用。如果能认真经营 BLOG ，它就能给你带来价值，超乎你想象的价值。</p>

<p>一般而言，建议对外开博前，可以在内部先试运行一下，给大家熟悉网络环境一个缓冲期。</p>

<h4>不与业绩指标挂钩 </h4>

<p>据说很多团队的 BLOG 居然和 KPI 挂钩的，这是非常不适合的做法。很明显这会导致一个现象：到了接近考核的时候，团队每个成员都流水帐一样连发多篇文章凑数，对读者来说，是一种信息轰炸，起不到什么正面作用，对团队多数成员来说，也觉得这样圆满完成任务也不错嘛，势必影响真正用心写文章的成员。当然我相信很多人看了我这个帖子后会改变 KPI 的设置方式，比如"每月要发布几篇"... 简言之，本末倒置。</p>

<h4>控制文章发布频率</h4>

<p>团队 BLOG 管理员(没错，应该有个管理员)应该控制文章正式发布的频率。细水长流，尤佳。记住，节奏最有力量。</p>

<p>控制频率的另外一点是要做好长期性准备，不要几天热乎劲儿过去之后就乏于更新。如果潜在读者偶尔访问过来，发现最近一篇更新是一年前，或许就会留下负面印象。</p>

<h4>不要强制团队成员</h4>

<p>必须要认清的一件事情是，一个团队中，肯定有些人员的确不善于文字表达，如果要他写一篇文章，可能比杀了他还更难受。如果强制性的压着他憋文章，恐怕只能适得其反。好的方式是发起者能够引导团队成员中的那些低调者，使他觉得这事情有意思，可以尝试一下，能够更多锻炼自己。比如针对技术人员来说，写文章过程中如果熟悉一下 HTML 基本语法，在日常工作中也不无裨益。</p>

<h4>不要堆砌垃圾文章</h4>

<p>这里面的一条铁律是：不要转贴那些网上随处可见的"心得"，"感悟"之类的心灵鸡汤文章，那些文章不能改变外界对你团队的正面看法(当然有可能增加负面看法)。适当的转载关于自己团队或者公司的第三方文章是可以接受的。</p>

<p>记住，垃圾信息和网站质量成反比的。信息不是越多越好。</p>

<h4>内容格式非常重要</h4>

<p>内容是团队向外展示的载体，固然重要，可如果文章不经过很好的格式化，就好比一块好田地长满了庄稼也同样长满野草一样让人讨厌。这是如此简单的一点，但我们还是能看到有许多团队对此熟视无睹。一篇连段落都不分的技术文章内容再好，也不会有更多技术人喜欢看。</p>

<p>不但 Web 页面要注重格式化，对 RSS 输出也同样也要注意，甚至应该更加以重视。至于输出全文，那是必须的。团队 BLOG 不要在乎什么 PV 之类的事情，那是非常土鳖的做法。内容是否有价值，不在于有多少人看了这篇文章，而是有多少目标读者从中得到收益。</p>

<p>--待续-</p>]]>
        
    </content>
</entry>

<entry>
    <title>Nutch 正式发布 1.0 版本</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/nutch_version_1.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/cgi-bin/mt-atom.cgi/weblog/blog_id=1/entry_id=1280" title="Nutch 正式发布 1.0 版本" />
    <id>tag:74.207.252.114,2009://1.1280</id>
    
    <published>2009-03-29T06:08:01Z</published>
    <updated>2009-11-23T10:07:11Z</updated>
    
    <summary>看到消息说 Nutch 正式发布 1.0 版本。这个 Lucene 的衍生项目，现在已经孵化长大。

很早以前我无聊的时候记录过一点使用 Nutch 的笔记(一、二)，现在还有人搜过来 :)  时过境迁，已经没啥用啦。

Apache 基金会下面的几个搜索项目应该说是极大解放了生产力，让搜索引擎这个看似高深莫测的东西走入寻常百姓家。很多公司自己的搜索引擎都参考了 Lucene 和 Nutch 不少吧。

--EOF--

几年前我说：
不久的将来，有 Nutch 支持的个人搜索引擎或是主题搜索引擎会大行其道。到了那个时候，或许 Google 这种垄断式搜索巨头的影响力已经不再！
原来只是痴人说梦。</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>看到消息说 <a href="http://lucene.apache.org/nutch/">Nutch</a> 正式发布 <a href="http://lucene.apache.org/nutch/#23+March+2009+-+Apache+Nutch+1.0+Released">1.0 版本</a>。这个 <a href="http://lucene.apache.org/">Lucene</a> 的衍生项目，现在已经孵化长大。</p>

<p>很早以前我无聊的时候记录过一点使用 Nutch 的笔记(<a href="http://www.dbanotes.net/web/nutch.html">一</a>、<a href="http://www.dbanotes.net/web/nutch_1.html">二</a>)，现在还有人搜过来 :)  时过境迁，已经没啥用啦。</p>

<p>Apache 基金会下面的几个搜索项目应该说是极大解放了生产力，让搜索引擎这个看似高深莫测的东西走入寻常百姓家。很多公司自己的搜索引擎都参考了 Lucene 和 Nutch 不少吧。</p>

<p>--EOF--</p>

<p>几年前我<a href="http://www.dbanotes.net/web/nutch_apache.html">说</a>：</p>
<blockquote>不久的将来，有 Nutch 支持的个人搜索引擎或是主题搜索引擎会大行其道。到了那个时候，或许 Google 这种垄断式搜索巨头的影响力已经不再！</blockquote>
<p>原来只是痴人说梦。</p>]]>
        
    </content>
</entry>

<entry>
    <title>有道阅读的技术信息</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/youdao_reader.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/cgi-bin/mt-atom.cgi/weblog/blog_id=1/entry_id=1273" title="有道阅读的技术信息" />
    <id>tag:74.207.252.114,2009://1.1273</id>
    
    <published>2009-03-06T10:44:35Z</published>
    <updated>2009-11-23T10:07:10Z</updated>
    
    <summary>最近北京奇遇花园咖啡馆举办了一场 &quot;Beta 技术沙龙&quot;, 关于&quot;有道阅读器产品设计&quot;的话题。

在杭州也没办法过去参加，倒是第一时间看到了 PPT。又问了以下，PPT 可以进行传播。所以截取了两张图(版权属于有道)学习一下。先是交互易用性问题。有道的数据库缓存策略是把当天的数据缓存起来，用 Memcached ，不知道改造过过还是默认方式使用。有道的 Ajax 交互的响应速度相对比较快。也是 用 JQuery  -- 几乎快成了居家旅行必备 JavaScript 库了。



用 YSlow 分析了一下有道前端的一些策略，发现大部分都做得不错，挺专业。Web 服务器是 Apache (不是 Nginx )，不过大部分图片设置为一周过期有些问题，太保守了，其实图片不过期也没啥问题，RSS 阅读器中的静态文件其实几乎不变化--除了用户的头像。应该说，判断一个网站是否合格，看看前端优化做得如何就可以了，如果做的不好，要么是太有钱，不担心带宽和计算资源的浪费，要么是根本不考虑用户的使用感受。



对于抓取的数据全部保存的问题，我不知道有道对 Feed 抓取过的内容更新问题如何处理。谁让咱没去现场呢，等下次有机会再了解一下吧。最后一点期望：有道什么时候能把订阅数让 FeedBurner 正确识别? 相信对大一点的网站 Google 多少能重视一点吧 ? 

--EOF--

今年以来，一些小型但有针对性的技术沙龙逐渐活跃起来了，嗯，杭州，在 5 月份之后也将开搞，敬请期待。

肯定有人问哪里有 PPT ?  访问 Club.blogbeta.com 

另参见：霍钜的 《关于有道阅读的beta技术沙龙》</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>最近北京<a href="http://storygarden.me/">奇遇花园咖啡馆</a>举办了一场 "<a href="http://club.blogbeta.com/">Beta 技术沙龙</a>", 关于"有道阅读器产品设计"的话题。</p>

<p>在杭州也没办法过去参加，倒是第一时间看到了 PPT。又问了以下，PPT 可以进行传播。所以截取了两张图(版权属于有道)学习一下。先是交互易用性问题。有道的数据库缓存策略是把当天的数据缓存起来，用 Memcached ，不知道改造过过还是默认方式使用。有道的 Ajax 交互的响应速度相对比较快。也是 用 JQuery  -- 几乎快成了居家旅行必备 JavaScript 库了。</p>

<p><span class="mt-enclosure mt-enclosure-image" style="display: inline;"><img alt="Youdao_Data_Interactive.png.png" src="http://www.dbanotes.net/Images/Youdao_Data_Interactive.png.png" width="455" height="311" class="mt-image-none" style="" /></span></p>

<p>用 YSlow 分析了一下有道前端的一些策略，发现大部分都做得不错，挺专业。Web 服务器是 Apache (不是 Nginx )，不过大部分图片设置为一周过期有些问题，太保守了，其实图片不过期也没啥问题，RSS 阅读器中的静态文件其实几乎不变化--除了用户的头像。应该说，判断一个网站是否合格，看看前端优化做得如何就可以了，如果做的不好，要么是太有钱，不担心带宽和计算资源的浪费，要么是根本不考虑用户的使用感受。</p>

<p><span class="mt-enclosure mt-enclosure-image" style="display: inline;"><img alt="Youdao_Data_Security.png" src="http://www.dbanotes.net/Images/Youdao_Data_Security.png" width="455" height="311" class="mt-image-none" style="" /></span></p>

<p>对于抓取的数据全部保存的问题，我不知道有道对 Feed 抓取过的内容更新问题如何处理。谁让咱没去现场呢，等下次有机会再了解一下吧。最后一点期望：有道什么时候能把订阅数让 FeedBurner 正确识别? 相信对大一点的网站 Google 多少能重视一点吧 ? </p>

<p>--EOF--</p>

<p>今年以来，一些小型但有针对性的技术沙龙逐渐活跃起来了，嗯，杭州，在 5 月份之后也将开搞，敬请期待。</p>

<p>肯定有人问哪里有 PPT ?  访问 <a href="http://Club.blogbeta.com">Club.blogbeta.com</a> </p>

<p>另参见：霍钜的 <a href="http://blog.devep.net/virushuo/2009/03/09/betasalon_youdaoreader.html">《关于有道阅读的beta技术沙龙》</a></p>]]>
        
    </content>
</entry>

<entry>
    <title>Lighttpd 的 spawn-fcgi 成为独立项目</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/lighttpd_spawn-fcgi.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/cgi-bin/mt-atom.cgi/weblog/blog_id=1/entry_id=1266" title="Lighttpd 的 spawn-fcgi 成为独立项目" />
    <id>tag:74.207.252.114,2009://1.1266</id>
    
    <published>2009-02-19T04:01:24Z</published>
    <updated>2009-11-23T10:07:09Z</updated>
    
    <summary>收到邮件说 Spawn-fcgi 成为独立项目，并且预发布了 1.6 版本。

原来很多人都用 Lighttpd 的 Spawn-fcgi 进行 FastCGI 模式下的管理工作，不过有不少缺点。而 PHP-fpm 的出现多少缓解了一些问题，但 PHP-fpm 有个缺点就是要重新编译，这对于一些已经运行的环境可能有不小的风险(refer)。

原来  spawn-fcgi  版本也比较乱的，期待独立后的项目能更稳定一些。这会给很多 Web 站点带来便利。

--EOF--</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>收到邮件说 <a href="http://blog.lighttpd.net/articles/2009/02/18/prerelease-of-spawn-fcgi-1-6-0-rc1-r16">Spawn-fcgi 成为独立项目</a>，并且预发布了 1.6 版本。</p>

<p>原来很多人都用 Lighttpd 的 Spawn-fcgi 进行 FastCGI 模式下的管理工作，不过有不少<a href="http://none.at/phpfm/docs/current_php_fastcgi_problems_en.html">缺点</a>。而 <a href="http://php-fpm.anight.org/">PHP-fpm</a> 的出现多少缓解了一些问题，但 PHP-fpm 有个缺点就是要重新编译，这对于一些已经运行的环境可能有不小的风险(<a href="http://www.dbanotes.net/web/php_fastcgi_phpfpm.html">refer</a>)。</p>

<p>原来  <a href="http://redmine.lighttpd.net/projects/spawn-fcgi">spawn-fcgi</a>  版本也比较乱的，期待独立后的项目能更稳定一些。这会给很多 Web 站点带来便利。</p>

<p>--EOF--</p>]]>
        
    </content>
</entry>

<entry>
    <title>Web Analytics 方法</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/web_analysis_method_compare.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/cgi-bin/mt-atom.cgi/weblog/blog_id=1/entry_id=1263" title="Web Analytics 方法" />
    <id>tag:74.207.252.114,2009://1.1263</id>
    
    <published>2009-02-12T11:01:02Z</published>
    <updated>2009-11-23T10:07:09Z</updated>
    
    <summary>在 Web Analytics 的几种方法中，分析 Web 服务器日志(Logfile Analysis) 与页面标记方法(Page Tagging/JavaScript Tagging, 也有称之为&quot;打点&quot;)相对更常见一些。今天发现一个关于二者的对比表格，感觉还是挺有帮助的，粗翻了一下，留作参考。 


(点击可看大图)

Page Tagging 的方式对业务控制(比如特定业务预警)更为灵活一些。其他的方法比如 Web Beacons(Web Bug) 的方法在 Web 1.0 的时候还是挺普遍的，对付当前的各种新型  Web 应用已经无能为力。

在设计 Web 应用的初期架构师就应该考虑 Web 分析的方法接口，就像在程序中预置性能调试接口那样，早点考虑，会少许多麻烦。

关于 Web Analytics，仍然存在许多误解与误用。冷暖自知吧。

--EOF--</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>在 <a href="http://www.dbanotes.net/web/web_analytics_an_hour_a_day.html">Web Analytics</a> 的几种方法中，分析 Web 服务器日志(Logfile Analysis) 与页面标记方法(Page Tagging/JavaScript Tagging, 也有称之为"打点")相对更常见一些。今天发现一个关于二者的<a href="http://www.advanced-web-metrics.com/blog/wp-content/uploads/2007/10/hyrids.gif">对比表格</a>，感觉还是挺有帮助的，粗翻了一下，留作参考。 </p>

<p><span class="mt-enclosure mt-enclosure-image" style="display: inline;"><a href="http://www.dbanotes.net/Images/Web%20Analysis%20Compare.png"><img alt="Web Analysis Compare.png" src="http://www.dbanotes.net/assets_c/2009/02/Web Analysis Compare-thumb-500x292-177.png" width="500" height="292" class="mt-image-none" style="" /></a></span><br />
(点击可看大图)</p>

<p>Page Tagging 的方式对<strong>业务控制</strong>(比如特定业务预警)更为灵活一些。其他的方法比如 Web Beacons(Web Bug) 的方法在 Web 1.0 的时候还是挺普遍的，对付当前的各种新型  Web 应用已经无能为力。</p>

<p>在设计 Web 应用的初期架构师就应该考虑 Web 分析的方法接口，就像在程序中预置性能调试接口那样，早点考虑，会少许多麻烦。</p>

<p>关于 Web Analytics，仍然存在许多误解与误用。冷暖自知吧。</p>

<p>--EOF--</p>]]>
        
    </content>
</entry>

<entry>
    <title>关于移动 Web 设计的闲言碎语</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/mobile_web_design.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/cgi-bin/mt-atom.cgi/weblog/blog_id=1/entry_id=1252" title="关于移动 Web 设计的闲言碎语" />
    <id>tag:74.207.252.114,2009://1.1252</id>
    
    <published>2009-01-15T07:06:28Z</published>
    <updated>2009-11-23T10:07:08Z</updated>
    
    <summary>前几天 3G 牌照下来，一时间 Buzz 信息很多，不过关于 3G 对 Web 技术影响的分析倒是并不多见。今天再次读了一遍这篇 2009 移动 Web设计趋势 (Mobile Web Design Trends For 2009)，加上这几天在分析使用 iPhone 上的某些 App 设计，还是记录一点笔记吧。

这篇文章提到了如下五点：

简单的可选项(Simple options) 如无必要，勿增实体。基本的、核心功能就行了。
留白(White space)  我觉得 UCWeb 针对 iPhone 的设计就很一般，完全是把 iPhone 当成小屏幕显示器设计的。堆砌的网址站看起来不方便，点击起来并不方便，倒是应该弄个 LOGO 或许更好。
少用图片(Lack of images) 这倒是和上一条矛盾。能少用就少用，而不是不用。而用了图片，如果方式不合适，还不如不用。
用子域名而不是用 .mobi 域名(Sub-domains instead of .mobi or separate domains) 精简域名长度，精简！用 &quot;i.&quot; 就很好，别用 &quot;mobile. &quot;。
内容优先(Prioritized content) 只有设计是没有用的。

我的额外建议：

可点击的目标锚点一定要大。因为你的手指肚更大 :) 如果一个手指尖范围内还有其它可点击目标，很容易误点。最简单的方式就是看看 iPhone  自己桌面菜单设计。而我之所以说 Taobao 商城 iPhone 版设计的不错，也是因为这一点考虑得很地道。Gmail for iPhone 的设计上，用户浏览邮件内容的时候，那个 &quot;Inbox&quot; 的按钮就设计的非常不好。很容易误点击到 &quot;Archive&quot; 按钮上。
分页设计   对于分页的链接，一定要隔开一些，如果&quot;上一页&quot;、&quot;下一页&quot;挨在一起，用户会很困扰。毕竟，手持设备没有鼠标，用户不可能具备&quot;精确点击&quot;的能力。
登录框设计  在 iPhone 上登录某些站点是非常痛苦的一件事情。可考虑的事情：如果用户 ID 是邮件地址的话，是否考虑无需用户输入&quot;@&quot; 字符? [iPhone 2.2 固件已经改进了许多]

另外，2009 移动 Web设计趋势 (Mobile Web Design Trends For 2009) 还提到了设计中的常见挑战以及需要慎重考虑的地方，这篇文章信息量还是挺大的。

--EOF--

唠叨完了，发现基本上是针对 iPhone 说事儿的，我还不是标准的移动互联网用户。</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>前几天 3G 牌照下来，一时间 Buzz 信息很多，不过关于 3G 对 Web 技术影响的分析倒是并不多见。今天再次读了一遍这篇 <a href="http://www.smashingmagazine.com/2009/01/13/mobile-web-design-trends-2009/">2009 移动 Web设计趋势 (Mobile Web Design Trends For 2009)</a>，加上这几天在分析使用 iPhone 上的某些 App 设计，还是记录一点笔记吧。</p>

<p>这篇文章提到了如下五点：</p>

<ul><li><strong>简单的可选项(Simple options)</strong> 如无必要，勿增实体。基本的、核心功能就行了。</li>
<li><strong>留白(White space) </strong> 我觉得 UCWeb 针对 iPhone 的设计就很一般，完全是把 iPhone 当成小屏幕显示器设计的。堆砌的网址站看起来不方便，点击起来并不方便，倒是应该弄个 LOGO 或许更好。</li>
<li><strong>少用图片(Lack of images)</strong> 这倒是和上一条矛盾。能少用就少用，而不是不用。而用了图片，如果方式不合适，还不如不用。</li>
<li><strong>用子域名而不是用 .mobi 域名(Sub-domains instead of .mobi or separate domains)</strong> 精简域名长度，精简！用 "i." 就很好，别用 "mobile. "。</li>
<li><strong>内容优先(Prioritized content)</strong></li> 只有设计是没有用的。</ul>

<p>我的额外建议：</p>

<ul><li><strong>可点击的目标锚点一定要大</strong>。因为你的手指肚更大 :) 如果一个手指尖范围内还有其它可点击目标，很容易误点。最简单的方式就是看看 iPhone  自己桌面菜单设计。而我之所以说 Taobao 商城 iPhone 版设计的不错，也是因为这一点考虑得很地道。Gmail for iPhone 的设计上，用户浏览邮件内容的时候，那个 "Inbox" 的按钮就设计的非常不好。很容易误点击到 "Archive" 按钮上。</li>
<li><strong>分页设计</strong>   对于分页的链接，一定要隔开一些，如果"上一页"、"下一页"挨在一起，用户会很困扰。毕竟，手持设备没有鼠标，用户不可能具备"精确点击"的能力。</li>
<li><strong>登录框设计</strong>  在 iPhone 上登录某些站点是非常痛苦的一件事情。可考虑的事情：如果用户 ID 是邮件地址的话，是否考虑无需用户输入"@" 字符? [iPhone 2.2 固件已经改进了许多]</li></ul>

<p>另外，<a href="http://www.smashingmagazine.com/2009/01/13/mobile-web-design-trends-2009/">2009 移动 Web设计趋势 (Mobile Web Design Trends For 2009)</a> 还提到了设计中的常见挑战以及需要慎重考虑的地方，这篇文章信息量还是挺大的。</p>

<p>--EOF--</p>

<p>唠叨完了，发现基本上是针对 iPhone 说事儿的，我还不是标准的移动互联网用户。</p>]]>
        
    </content>
</entry>

<entry>
    <title>Cookie, iframe 与 P3P 的那点事儿</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/cookie_p3p.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/cgi-bin/mt-atom.cgi/weblog/blog_id=1/entry_id=1251" title="Cookie, iframe 与 P3P 的那点事儿" />
    <id>tag:74.207.252.114,2009://1.1251</id>
    
    <published>2009-01-13T04:57:13Z</published>
    <updated>2009-11-23T10:07:08Z</updated>
    
    <summary>且说我使用有些网络服务的时候常常能遇到比较怪异的问题。昨天在某个页面遇到个 Redirect Loop 错误提示：

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

同样的问题，同样的页面，同样是 Firefox 浏览器，以前就遇到过，提交给相关负责人之后没了响应，后来也忘掉了。同事说是我浏览器版本的问题，后来发现这和&quot;是否接受第三方 Cookie&quot; 的设置有关：

[x] Accept cookies from sites
    [ ] Accept third-party cookies

我的浏览器不接受第三方 Cookie。设置接收后该页面显示正常。

搜索了一下，发现之所以该页面是这样，还是因为页面用了 iframe 而导致的问题，比较通用的办法是设置 p3p http header 。

这个 P3P(Platform for Privacy Preferences Project)，要搞明白，可真是有点小孩没娘，说来话长。简单的说，就是个协议，通过其声明它是好人，允许我收集浏览器用户行为吧... 可现实中，大家都可以说自己是好人，背地里没准儿干啥坏事呢。这就是其分歧所在。[参考] 国内多数网站，都不关注这个 P3P。隐私问题可能没国外(微软的隐私声明)重视吧。

再说 Firefox ，过去的几个大版本中，对 Cookie 的处理方式还是有很大变化的。

这个问题影响最大的还是 Facebook 等开放平台的应用，使用了 iframe 就会遇到(eg: FriendFeed 遇到过，估计还比较头疼)。

对于浏览器来说，第三方 Cookie ，默认情况下，浏览器接受与否，是个大问题。如果不接受，会给很多用户带来混淆，如果接受，则在隐私问题上，有很大的挑战。

实际上，Firefox 的开发者在这个地方的处理方式也在摇摆当中(参见), 不过能确定的是 &quot;the ability to make decisions based on p3p policies was removed for firefox 3&quot;。

各家浏览器在这个地方都可能有 Bug。比如 IE7 曾经有的 Cookie 问题，IE8 Beta 也有类似问题。

或许，最好的办法就是别去种这个 Cookie 了...  网站开发者，你们愿意么? 

--EOF--

更多阅读：Windows Internet Explorer (Pre-Release Version 8) Privacy Statement微软 Cookie 说明

另请参见文本后面 axis 同学的留言。</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p>且说我使用有些网络服务的时候常常能遇到比较怪异的问题。昨天在某个页面遇到个 <strong>Redirect Loop</strong> 错误提示：</p>

<pre>Firefox has detected that the server is redirecting the request for this address in a way that will never complete.</pre>

<p>同样的问题，同样的页面，同样是 Firefox 浏览器，以前就遇到过，提交给相关负责人之后没了响应，后来也忘掉了。同事说是我浏览器版本的问题，后来发现这和"是否接受第三方 Cookie" 的设置有关：</p>

<pre>[x] Accept cookies from sites
    [ ] Accept third-party cookies</pre>

<p>我的浏览器不接受第三方 Cookie。设置接收后该页面显示正常。</p>

<p>搜索了一下，发现之所以该页面是这样，还是因为页面用了 iframe 而导致的问题，比较通用的办法是<a href="http://viralpatel.net/blogs/2008/12/how-to-set-third-party-cookies-with-iframe.html">设置 p3p http header</a> 。</p>

<p>这个 <a href="http://en.wikipedia.org/wiki/P3P">P3P</a>(Platform for Privacy Preferences Project)，要搞明白，可真是有点小孩没娘，说来话长。简单的说，就是个协议，通过其声明它是好人，允许我收集浏览器用户行为吧... 可现实中，大家都可以说自己是好人，背地里没准儿干啥坏事呢。这就是其分歧所在。[<a href="http://www.oreillynet.com/lpt/a/1554">参考</a>] 国内多数网站，都不关注这个 P3P。隐私问题可能没国外(<a href="http://www.flickr.com/photos/fenng/3193001715/">微软的隐私声明</a>)重视吧。</p>

<p>再说 Firefox ，过去的几个大版本中，对 Cookie 的处理方式还是有很大<a href="http://kb.mozillazine.org/Network.cookie.cookieBehavior">变化</a>的。</p>

<p>这个问题影响最大的还是 Facebook 等开放平台的应用，使用了 iframe 就会遇到(eg: <a href="http://friendfeed.com/e/1e78f47b-92a3-48da-8244-1f2b218b246c/If-you-uncheck-Accept-third-party-cookies-Firefox/">FriendFeed 遇到</a>过，估计还比较头疼)。</p>

<p>对于浏览器来说，第三方 Cookie ，<strong>默认情况</strong>下，浏览器接受与否，是个大问题。如果不接受，会给很多用户带来混淆，如果接受，则在隐私问题上，有很大的挑战。</p>

<p>实际上，Firefox 的开发者在这个地方的处理方式也在摇摆当中(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=417800#c11">参见</a>), 不过能确定的是 "the ability to make decisions based on p3p policies was removed for firefox 3"。</p>

<p>各家浏览器在这个地方都可能有 Bug。比如 <a href="http://aspnetresources.com/blog/frames_webforms_and_rejected_cookies.aspx">IE7 曾经有的 Cookie 问题</a>，IE8 Beta 也有<a href="http://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=369240">类似问题</a>。</p>

<p>或许，最好的办法就是别去种这个 Cookie 了...  网站开发者，你们愿意么? </p>

<p>--EOF--</p>

<p>更多阅读：<a href="http://www.microsoft.com/windows/ie/ie8/privacy/ieprivacy_8.mspx">Windows Internet Explorer (Pre-Release Version 8) Privacy Statement</a><br /><a href="http://support.microsoft.com/kb/260971/zh-tw">微软 Cookie 说明</a></p>

<p>另请参见文本后面 <a href="http://www.dbanotes.net/web/cookie_p3p.html#comment-72283">axis</a> 同学的留言。</p>]]>
        
    </content>
</entry>

<entry>
    <title>精通 Web Analytics</title>
    <link rel="alternate" type="text/html" href="http://www.dbanotes.net/web/web_analytics_an_hour_a_day.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.dbanotes.net/cgi-bin/mt-atom.cgi/weblog/blog_id=1/entry_id=1247" title="精通 Web Analytics" />
    <id>tag:74.207.252.114,2009://1.1247</id>
    
    <published>2009-01-06T04:34:59Z</published>
    <updated>2009-11-23T10:07:07Z</updated>
    
    <summary>没看这本书之前我以为我懂 Web 分析，看了之后才发现之前其实并不明白。
算起来，用 AWstats 做了几年的小实验，尽管一些基本的东西是有所了解，但如果要详细说明背后的含义，还是并不清晰。这可能不是我一个人的感受吧? 我遇到过一些做 Web 分析的同仁，整天看网站数据报表，也看不出什么东西来。尽管我们常看到 Web 分析工具的更新，但国内互联网的 Web 分析思路似乎并没有&quot;与时俱进&quot;。 不管承认与否，毕竟是现实一种。


普及这本书，我想能有效避免 Web 分析中的一些误区，以 PageView 为核心的 Web 分析时代应该已经过去。结合自己的实际业务，通过数据去了解客户，真正做点能起到&quot;正反馈&quot;的事儿，而不是到了节假日弄一些无聊活动疯狂弹出一些用户烦透的垃圾页面。这对你们公司也是莫大的损失。

负责网站数据分析的主管啊经理啊总监啊都把这本书偷着买回去仔细读两遍，然后整点靠谱的针对 Web 的 KPI 出来，也让下面的员工心里服气你还算个合格的管理者。把这本书当作了解 Web 的另一面镜子(如果是从传统行业过来的话)，通过另一个角度(数据)观察 Web。

此书翻译质量一般...但我想不影响阅读。

Web Analytics，An Hour a Day ，不需那么多，只要一点点。

--EOF--

作者 Avinash Kaushik ，感兴趣的话还可以观看他的相关采访视频。更多信息访问豆瓣上的 精通Web Analytics页面，如果买书直接点击豆瓣上的链接去买吧，也算支持豆瓣了 :)

又及：这本书也被我列入豆列 Web 2.0 网站架构不可或缺的图书。</summary>
    <author>
        <name>Fenng</name>
        <uri>http://www.dbanotes.net</uri>
    </author>
    
        <category term="Web" />
    
    <content type="html" xml:lang="en" xml:base="http://www.dbanotes.net/">
        <![CDATA[<p><span class="mt-enclosure mt-enclosure-image" style="display: inline;"><img alt="Web Analytics  An Hour a Day" src="http://www.dbanotes.net/Images/WebAnalytics.jpg" width="168" height="240" class="mt-image-right" style="float: right; margin: 0 0 20px 20px;" /></span>没看这本书之前我以为我懂 Web 分析，看了之后才发现之前其实并不明白。</p>
<p>算起来，用 <a href="http://awstats.sourceforge.net/">AWstats</a> 做了几年的小实验，尽管一些基本的东西是有所了解，但如果要详细说明背后的含义，还是并不清晰。这可能不是我一个人的感受吧? 我遇到过一些做 Web 分析的同仁，整天看网站数据报表，也看不出什么东西来。尽管我们常看到 Web 分析工具的更新，但国内互联网的 Web 分析思路似乎并没有"与时俱进"。 不管承认与否，毕竟是现实一种。
</p>

<p>普及这本书，我想能有效避免 Web 分析中的一些误区，以 <a href="http://en.wikipedia.org/wiki/Page_view">PageView </a>为核心的 Web 分析时代应该已经过去。结合自己的实际业务，通过数据去了解客户，真正做点能起到"正反馈"的事儿，而不是到了节假日弄一些无聊活动疯狂弹出一些用户烦透的垃圾页面。这对你们公司也是莫大的损失。</p>

<p>负责网站数据分析的主管啊经理啊总监啊都把这本书偷着买回去仔细读两遍，然后整点靠谱的针对 Web 的 KPI 出来，也让下面的员工心里服气你还算个合格的管理者。把这本书当作了解 Web 的另一面镜子(如果是从传统行业过来的话)，通过另一个角度(数据)观察 Web。</p>

<p>此书翻译质量一般...但我想不影响阅读。</p>

<p>Web Analytics，An Hour a Day ，不需那么多，只要一点点。</p>

<p>--EOF--</p>

<p>作者 <a href="http://www.kaushik.net/avinash/">Avinash Kaushik</a> ，感兴趣的话还可以观看他的相关<a href="http://www.youtube.com/watch?v=Qmxh9bD367A">采访视频</a>。更多信息访问豆瓣上的 <a href="http://www.douban.com/subject/3260737/">精通Web Analytics</a>页面，如果买书直接点击豆瓣上的链接去买吧，也算支持豆瓣了 :)</p>

<p>又及：这本书也被我列入豆列 <a href="http://www.douban.com/doulist/176732/">Web 2.0 网站架构不可或缺的图书</a>。</p>]]>
        
    </content>
</entry>

</feed> 

