常用网站开发类Firefox扩展插件

　　作为一个 Web 开发人员，你几乎没有理由不喜欢Firefox，因为在Firefox下有很多专门针对开发的扩展插件，非常好用，这里就介绍一些常用的针对网站开发的FireFox扩展，供Web开发人员参考。

　　1、Firebug

　　用于调试JavaScript，修改界面HTML和CSS，一些常用的网络分析扩展也是基于Firebug的，非常好用。

　　2、YSlow

　　YSlow是Yahoo开发的，基于Firebug的用于分析网页性能的工具，可以提供如何提高网站性能的一套规则，用于优化网页的速度和建立高性能的网页。

　　3、Page Speed

　　Page Speed是Google开发的类似YSlow的工具，也是基于Firebug插件，网站管理员和网络开发人员可以使用 Page Speed 来评估他们网页的性能，并获得有关如何改进性能的建议。

　　4、Web Developer

　　Web Developer是集成了一系列Web开发工具，例如HTML、CSS校验、FORM修改等功能，拥有强大的CSS调试和Form调试能力，对页面的分析非常全面，可以禁止页面的任一内联、文档、和外部CSS，可以直接编辑当前CSS。

　　5、Live HTTP Headers

　　浏览页面同时记录所有HTTP headers，可分析各个http头的状态码。

　　6、HttpFox

　　监控和记录所有HTTP访问中发送和接受的数据，包括URL地址、HTTP头、传输参数等信息。

　　7、User Agent Switcher

　　浏览器切换器，可以让Firefox伪装为其他浏览器，伪装其他浏览器例如iPhone来访问网站。当初我提前体验Google Buzz就是利用这个扩展模拟iPhone登录来实现的。

　　8、Coral IE Tab

　　基于IETab开发的增强版本，在Firefox中模拟使用IE浏览器的引擎来访问网页。

　　9、MeasureIt

　　可以测量页面上任何选择区域的长宽。

　　10、ColorZilla

　　可以从页面，或者调色板上取色，同时可以缩放页面。

　　11、FireFTP

　　在Firefox中实现FTP的功能。

　　12、Greasemonkey

　　让你可以使用JavaScript在浏览器上实现一些特殊的定制功能，有上百个基于Greasemonkey的JavaScript代码可供使用。

　　13、View Source Chart

　　改善Firefox浏览器显示源代码的样式。

　　14、HTML Validator （based on CSE HTML Validator）

　　使用CSE的HTML验证引擎，需要安装CSE HTML Validator for Windows，有lite版本。

　　15、wmlbrowser

　　模拟WAP访问WML (Wireless Markup Language)网页。

两个重要而又容易被忽视的角色

　　我敢打赌，在中国，一半以上甚至更多的，以网站为主营业务的或者把网站很看重的公司，没有Web前端工程师和产品工程师这两个职位，甚至有些有点规模的公司也可能没有这个职位，当然，这不能包括像alibaba，sina，163这样的公司，只是指中小型公司而言。如果你们公司有，请给我留言告诉我你们公司的规模和相关的信息。

　　做得好一点的公司，一般是项目经理/部门主管+投资方（项目管理中的投资方，实际上就是老板，反正就是决定你要做什么并给你钱的人）来承担产品工程师的角色，由美工来承担Web前端工程师的角色，特别是Web前端工程师，是最容易被忽略的角色。

　　企业想挤出利润，无非两个方面，一个是开源，另一个是节流。而这两个角色，恰恰可以用开源节流来比喻，产品工程师可以设计出更好的产品，这就是开源，Web前端开发工程师可以精简网页代码，提高用户访问速度，减小企业带宽上的支出，甚至可以减小服务器上的支出，这不是节流是什么？相比有些企业，以靠克扣员工工资来实现节流，这个节流要节省得多。

　　产品工程师

　　很多公司的流程基本上是这样的，由需求部门（一个或者多个，如果公司小，可能就是老板等几个人）提出需求，提交到项目经理或者IT部门主管，然后 IT部门主管根据需求进行开发，这中间可能要判断是做还是不做，判断的依据主要是开发难不难，麻烦不麻烦，很少去考虑合不合理。各位，看到什么问题没有，很多IT的部门主管，他只是一个管理者+项目经理的组合，或者干脆就是一个项目经理。需求部门交给我的需求，我按照要求按时按质做完就OK了。但时，需求部门往往是不懂互联网的，这种情况很多公司大量存在，对于一些老板本身就是做互联网的，或者较大的公司，这种情况会比较少。

　　问题就来了，一个不懂互联网的人，根据自己的喜好或者自己的判断来提出一些需求，有些需求可能很无理，有些时候可能是自己的喜好，有些时候可能是违背互联网的基本准则的。而技术部门往往是只要没有技术难度就开发吧，反正我就按你要求做了，这个中间，没有一个懂互联网的人来把关。注意，懂互联网的人，不是懂技术的人，懂技术的人很多都是不懂互联网的。比如说我曾经见过有公司的老板要在网站的两边加一副对联，结果别人说像灵堂一样，也曾经有公司的老板要把网站做得像电视一样（不是视频网站，就是一个非常酷的过场动画这样子，想法是好的，可惜不适合大型网站，不利于访问也不利于SEO）。

　　这个时候一定要有一个产品工程师或者产品组来承担这个中间人，注意，还没有到美工的层面，他需要根据需求方的需求，再加上自己对互联网的了解，来设计这个产品。他要考虑到浏览器、带宽、用户习惯等等内容，以确定如何布置页面中的内容，确定功能之间的关联。在这个时候，如果产品工程师不懂技术，可以邀请Web前端工程师和项目经理/部门主管参与，因为某些地方为了用户体验可能要使用到一些技术，需要由这些人来确定是否要行。

　　Web前端工程师

　　相对于产品工程师，这个职位显得很加缺乏，因为产品工程师很多时候可以由项目经理或者部门主管兼任，但Web前端工程师这个职位，是很多公司都不重视的职位，很多公司是这样的，Html和CSS由美工负责，而Javascript由程序员负责。但问题是，很多美工对Html/CSS只能实现，至于规范也速度很少考虑，而程序员对Javascript就更加了，从我接触过的程序员中，绝大多数人觉得Javascript是一个比较简单的语言，没什么前途，看不起这种语言，也认为Javascript只能实现一些交互而已。

　　所以实际上，很多企业是用两个懂一点点的人，来做这个重要的工作。如果让我来选择，我愿意放弃一个，甚至两个程序员，来换一个Web前端工程师。为什么要这么做？我认为，一个网站两个非常重要的地方，就是他的交互性与速度。很多程序员喜欢划分前台与后台，他们都认为前台不重要，只要后台功能完成了，前台不是很简单的事么！不！不是这样的，前台比后台重要，为什么这么说？你想想，一个用户是通过什么接触到你的网站的，是前台，是Web页面，而不是后台冷冰冰的程序。你有再强大的功能，如果用户操作起来很复杂，那么用户也会抛弃你的，除非用户别无选择，比如说工信部的备案，但问题是，现在互联网同质化越来越厉害，抄袭也变得风行，你真的有这么高的技术壁垒让其它公司没有办法做到和你一样的产品么？

　　注意，不要钻牛角尖，我并非说后台完全不重要，你要非说就算你前台再好，我后台一个死循环出不来，那不是也没戏，这是抬杠！除了大型网站和逻辑错误，现在多数网站并不存在后台影响速度的问题，或者说影响不是那么明显。前台所带来的问题，要比后台带的问题多得多，也容易解决得多，往往是可以花少量的代价来解决大问题的，可是往往很多企业愿意去花钱买带宽买服务器租CDN以提高速度，却不愿意请一个Web前端工程师来解决这个问题。同时，请注意，就算你服务器再快你的带宽再高，用户的带宽是不变的，如果你超出了用户带宽的阀值，你所做的一切将都是豪无意义的。

　　程序员往往可以实现Javascript的功能，但是由于Javascript的特殊性，他们很难以最优化的方式来开发Javascript代码，就可能就造成他们去网上Copy一段Javascript，然后只要实现效果即可，大量重复的甚至是有Bug的代码被应用到网站中，这些代码将会影响到用户的执行效率，降低用户体验。在HTML方面，这也是程序员的弱项，他们也觉得这个东西太简单，实现起来很容易，但是HTML和Javascript都是入门易深入难的东西，如何合理地组织Html+CSS，让浏览器更快更有效率地执行，这个也是需要很多年的经验的。

　　在用户体验方面，大公司可能用UE/UI等部门，而小公司的话，一定要有Web前端工程师，美工只是设计页面，很难照顾到用户体验这个层面，当然不排除有些美工已经有这样的水平。实际上用户体验也和产品设计一样，都属于开源的一部分，因为如果用户体验好就能带来更多的用户，不是开源是什么。

　　最后，我想分析一下造成这两个职位被忽视的原因，产品工程师一职，往往被项目经理或者部门主管+投资人代替了，一般来说，做到主管级的人对行业多多少少算比较了解，所以这个职位的缺失可能不会带来大问题，但也有时候会因为这个职位的缺失而导致项目失败的安例发生，这就要求主管同时也要有产品工程师的能力。

　　Web产端工程师是最容易被忽略也是最不好招聘的职位，究其原因，是因为部门主管往往是做技术出身的，而技术人员常常会轻视或者忽视前台的工作，也正是这个原因，造成了Web前端工程的工作比较低，所以很多人不愿意去做这个职位，我就常常看到新人如果让ta学习Html/CSS /Javascript，ta就会问你，什么时候我才可以真正编程啊，这样就形成了一个恶性循环，企业不重视，工资上不去，程序员也就不愿意学习了。然后，这个职位可以给公司省下非常高的费用，可以节省数个程序员，减少带宽及服务器。不信？试试看吧！

　　来源：涂雅投稿，原文网址，转载请保留此链接，否则视为侵权。

百度推广和谷歌关键字广告

　　今天去参加了《百度营销中国行》深圳站的会议，主题演讲有《网络时代的营销变革》和《搜索改变营销》等内容，参加会议的人非常多，秩序很混乱，体验厅的业务员小姐对搜索业务也不很了解，做个几个演示，就问我什么时候签单，我怀疑这些业务员是不是做保险的转行过来的。

　　百度推广和谷歌关键字广告（AdWords）对比

　　这个《百度营销中国行》会在国内四十多个主要城市进行巡回演讲，举办的时机非常敏感，正是谷歌中国总部迁至香港之后的关键时刻，中国搜索引擎市场市场前途未卜，此时的谷歌广告用户普遍处于人心不稳的状态，谷歌的广告市场份额也出现一定程度下滑，据易观国际Enfodesk产业数据库《2010年第1季度中国搜索引擎市场季度监测》显示，百度收入市场份额从上一季度的58.4%拉升至目前的64%，谷歌收入市场份额从上一季度的35.6%下滑至本季度的31%。而其他搜索引擎如腾讯搜搜、网易有道均未有大幅变化。

　　此时百度推广的强势出击，用意非常明显，因为百度的搜索市场份额较大，因此原本百度推广（竞价排名）就比谷歌关键字广告（AdWords）有较大的优势，现在这种优势有可能将逐步拉大。

　　然而，从这次会议给我的感觉，百度目前的飞速扩张显得有些急躁了，中国目前的网络广告市场其实还处于启蒙阶段，市场规模远未成熟，据百度介绍，深圳的30万家中小企业有60%都没有自己的网站，发展潜力是巨大的。但电子商务发展不能急功近利，应该一步步来，关键字广告说好听点是精准营销、成本低廉，实际上如果设置不当，往往是个烧钱的工具。对于那些连网站都不会建立的中小企业来说，通过关键字广告进行网络营销实际上具有相当大的难度，不是几个专家忽悠了一下午就能签单这么简单的事情，百度如果真想发掘这里的市场，不如先从最基本的中小企业电子商务建站开始做起，不用先考虑赚企业的钱，而是慢慢哺育这个市场，等市场成熟发展起来，中小企业都有了自己的网站，那么网络广告推广的商机自然就成倍增长了。

　　在会议中，百度演示了一个百度商桥的工具，这是一个用于技术支持的商务沟通工具，其服务器界面和百度Hi很类似，从这个软件可以看出百度在商务领域的尝试要先于腾讯，腾讯拥有那么大的QQ装机量，为什么不能模仿“百度商桥”做一个商务沟通工具呢？

　　百度联盟和谷歌广告联盟（AdSense）对比

　　虽然谷歌关键字广告（AdWords）业务面对百度推广处于下风，但谷歌广告联盟（AdSense）业务相比百度联盟来说占据绝对优势，对于联盟网站给予高额分成比例赢得了广大中小网站的青睐，成为网站发布商的首选产品，这种优势在短期内难以撼动。

　　谷歌广告联盟（AdSense）业务之所以成功，主要有以下几点原因：

　　1、严惩作弊：谷歌广告联盟（AdSense）的计划政策是，一个用户一旦作弊，则终身停用作弊网站的帐号，这种对网站发布商近乎苛刻的审核和监控，充分保障了广告发布商的利益，同时也提高了联盟网站的整体流量水平，这种严厉的制度不仅仅赢得了广告主的好感，同时也获得了中小联盟网站的青睐，因为联盟网站可以获得更高的分成。而百度联盟在发展初期对作弊采取睁一只眼闭一只眼的态度，使得很多作弊网站则纷纷转向百度联盟，降低了百度联盟的流量质量，反而让发布商不愿意在联盟网站上投放广告。阿里妈妈则全是作弊网站在刷流量，基本上已经出局。

　　2、高额分成：谷歌广告联盟对于联盟网站的分成非常高，超过了70%，这让谷歌自己反而从AdSense获得收入很少，高额的分成吸引了大量的优质网站。而百度联盟的分成较低，相同广告商的相同广告，在两个不同联盟上会得到完全不同的收益。

　　3、定期培训：谷歌广告联盟（AdSense）从几年前就开始进行各类免费的网络培训和网络会议，通过各类培训会议，提高了各个联盟网站的广告点击率和收入。而百度从今年起才开始进行网站联盟的培训会议。

　　当然，百度在网站联盟上的收入可能和谷歌类似，也不太多，因此可能就不会在上面投太多的精力，而联盟网站的广告效果不好，会使得客户将资金投放到百度推广里，反而会增加百度的收入，因此网站联盟也逐渐形成鸡肋的发展势态。

　　总之，中国的搜索引擎广告市场规模还有很大的潜力，远远不是去年69亿那种规模，这方面的市场建设，搜索引擎（百度、谷歌）、中小企业、联盟网站三方都有一定的责任来共同发掘这个市场，一旦这个市场发展起来，那么中国的互联网广告市场必然会面临重新洗牌，这其中成功的机会就很大了。

谷歌手机地图支持中文语音搜索

　　距Google黑板报报道，早前，Google已经针对Android和黑莓智能手机用户推出了包含语音功能的谷歌地图服务。现在，使用Symbian S60和Windows Mobile操作系统的智能手机用户终于也能够体验Google地图的语音搜索了。

　　早先，诺基亚S60V3机型的用户已经可以通过“谷歌手机软件”使用网页和图片的中文语音搜索服务，但是无法进行“谷歌地图”的中文语音搜索，现在，最新版的手机谷歌地图4.1版开始支持语音搜索，用户直接对着手机说话即可进行中文地图搜索，无需输入地址和搜索条目。

　　谷歌手机地图的语音搜索支持Symbian S60和Windows Mobile手机。除了添加语音查询功能之外，谷歌地图4.1移动版的设置页面中还包含语言选择选项。

　　移动版的谷歌地图手机下载地址 m.google.com/maps

Google Buzz：机器人的世界

　　据社交媒体调查公司PostRank的报道，Google Buzz大约有九成的内容都是通过机器人自动推送的信息，这让Google Buzz的前景看起来相当迷茫。

　　该公司表示，有62.57%的Buzz内容来自于Twitter，通过RSS Feeds自动发布新闻和报道的网站内容占据了Buzz内容的26.47%，两者之和接近Google Buzz内容的九成。

　　这也是我以前曾经对Buzz表示忧虑的地方，Buzz的各项功能都完全克隆FriendFeed，但实践证明FriendFeed模式完全无法和Twitter相匹敌，用户在上面绑定信息后就再也不登录了，而是继续上Twitter发布信息，现在，Buzz正在重复Friendfeed的失败之路，并且没有从中获取任何经验教训。

　　Google的用户量、实时搜索技术都是非常优秀的，Google Buzz也有非常好的用户讨论体验，在上面讨论话题感觉非常不错，但目前Buzz上的垃圾信息实在太多，大部分信息都是由机器人自动发布的，同时Google也没有在信息过滤上解决这个问题，带来的问题就是非常严重的信息过载，这必然让用户访问Buzz的意愿降低，谁愿意把时间都浪费在机器人的海洋上呢？讨论的确是Buzz的强项，但总归要有人来讨论才行，而不是全是机器人。人们上Twitter是因为可以和“真实的人”进行互动交流，获得更多的信息，而不像Buzz这样的嘈杂的广场，有用的信息会被立刻淹没在信息海洋之中。

　　解决Google Buzz这个问题的方法其实也不难，一种方法是过滤，让用户可以选择只看从Buzz发布的信息，不看自动推送的信息；另一种方法更简单，就是停止从Twitter和Feed上的同步信息到Buzz，这样虽然减少了Buzz的信息总量，但能提高Buzz上的有效信息。

　　Google以前从来没有成功的运营过任何一款社会化产品，从Orkut到Jaiku，都是以失败而告终，从这次运营Buzz的现状看，很难对Buzz的未来表示乐观，或许Google的确不知道如何运营一个社会化产品。

　　总之，在我看来，如果Buzz再不改变现状，那么这个很有特色的社会化交互性工具将无可避免将走向失败之路。

Twitter API中文文档

　　目前的国内的微博客很多，不少微博客都提供Open API，然而，很多微博提供的API和Twitter的API有一些或多或少的差别，调用格式上并不完全相同。

　　我建议所有提供API的微博客系统，都将各自的API统一为Twitter的API调用格式，例如目前较有影响的开源微博系统StatusNet（Laconica）的API格式就完全兼容Twitter，这种统一API对于开发者和用户都有很大的好处。对于开发者，针对某一个微博的应用可以快速移植到另一个微博，节省开发时间。对于用户，用户可以自定义客户端应用程序，只要换一下API地址，就能使用同一个应用程序，来访问各个不同的微博。例如目前很多人通过StatusNet的客户端来访问Twitter一样，使用起来很方便。

　　Twitter的API具体是什么格式的呢？根据Twitter API文档和新浪微博开放平台的文档，这里提供了一个Twitter API的中文翻译文档，供开发者们参考。

　

Twitter开放API文档

　

　　Twitter通过API的方式开放一些应用接口，这篇文档用来介绍Twitter目前开放的接口，为希望开发基于Twitter服务扩展的工具或应用的开发人员提供技术和文档服务。

　　认证

　　除了部分API(如：公共时间线 ( public timeline ) )外，所有的API方法都必须要求用户认证，所有的返回都与认证用户相关。例如，尝试获取一个设置为私密的且不是您的好友的用户信息时，将会返回失败状态。

　　Twitter目前仅支持HTTP Basic Authentication验证机制。当使用HTTP Basic Authentication时，请使用您在Twitter注册的“用户名”作为Session或Cookie的“用户名”部分的内容。

　　多状态[RESTFull]结果传输

　　Twitter API力求根据用户特定的请求返回对应特定格式的数据，您可以发现我们提供的API中有一个重要的便利之处，通过简单的更改URI中的文件后缀名，您可以获得您想要的返回结果的格式，这篇文档中将说明每个方法中有哪些格式可以用。

　　Twitter目前支持以下的四种数据返回格式：XML、JSON、RSS、Atom，您可以在每次请求时使用不同的请求方法指定不同的返回结果。

　　参数

　　一些API接受可选和必须的参数，当参数可用时，我们会在接下来的文档中提到这些参数。注意：当传送复杂字串时，请一定先将字串编码为UTF-8格式，并再做一次URL编码 ( Encode )。

　　HTTP请求

　　除非特意指明，Twitter的开放API通过HTTP GET方式的调用，需要提交信息或传送私密消息时使用POST方法。

　　以下将说明API返回的信息格式的组成，一些API将返回与用户请求“内容”相关的信息，而有一些将返回与客户端发送的“HTTP头信息”相关的一些信息。例如，多数支持since参数的方法，同样会对HTTP头中的If-Modified-Since这个 HTTP头 感兴趣。需要注意的是，当某些行为既可以通过参数又可以通过HTTP头进行控制时，优先接受通过参数方式设定的值。

　　当请求返回数据时，返回数据的编码统一为UTF-8格式，且我们会将一些外部符号编码为HTML实体（&#number; 或&text）格式。

　　限制

　　每一个客户端每小时最多允许150次请求。

　　HTTP状态码

　　Twitter API会对每次请求返回合适的HTTP状态。例如，当请求一个不存在的用户信息时，API会返回404 Not Found；当一次请求没有被认证并授权时，API会返回401 Not Authorized状态。 

　　使用API的简便方法

　　如果您的系统安装有curl，您已经有了一个非常强大的使用微博 API的工具。以下是使用curl的例子，非常简单： 

　　非授权情况下访问public_timeline： curl http://api.twitter.com/statuses/public_timeline.xml

　　获取朋友的timeline, 使用认证： curl -u email:password http://api.twitter.com/statuses/friends_timeline.xml

　　仅获取头部信息： curl --head email:password http://api.twitter.com/statuses/friends_timeline.json

　　用户状态相关方法

　　statuses/public_timeline

　　返回未设置私密的用户 ( 必须有自定义的用户头像 ) 的最近20条消息，该方法不需要身份认证。

　　访问地址：http://api.twitter.com/statuses/public_timeline.format

　　支持格式(format)：xml, json, rss, atom

　　参数列表：

　　无。

　　statuses/friends_timeline

　　返回最近24小时内的最新的20条认证用户及其好友更新的消息。

　　访问地址：http://api.twitter.com/statuses/friends_timeline.format

　　支持格式 ( format ) ：xml, json, rss, atom

　　参数列表：

　　since_id: 可选参数（微博信息ID）. 只返回ID比since_id大（比since_id时间晚的）的微博信息内容。

　　示例: http://api.twitter.com/statuses/friends_timeline.xml?since_id=12345

　　max_id: 可选参数（微博信息ID）. 返回ID不大于max_id的微博信息内容。

　　示例: http://api.twitter.com/statuses/friends_timeline.xml?max_id=54321

　　count: 可选参数. 每次返回的最大记录数，不能超过200，默认20.

　　示例: http://api.twitter.com/statuses/friends_timeline.xml?count=5

　　page: 可选参数. 返回结果的页序号。注意：有分页限制。根据用户关注对象发表的数量，通常最多返回1,000条最新微博分页内容, 默认1

　　示例: http://api.twitter.com/statuses/friends_timeline.xml?page=3

　　statuses/user_timeline

　　返回认证用户最近24小时内最新更新的20条消息，同样，通过给定userIdOrName参数，可以用来请求其他用户的最近的消息更新。该API可以不认证。

　　访问地址：http://api.twitter.com/statuses/user_timeline.format

　　支持格式 ( format )：xml, json, rss, atom

　　参数列表：

　　id： 可选参数. 根据指定用户UID或微博昵称来返回微博信息。

　　示例: http://api.twitter.com/statuses/user_timeline/12345.xml

　　user_id： 可选参数. 用户UID，主要是用来区分用户UID跟微博昵称一样，产生歧义的时候，特别是在微博昵称为数字导致和用户Uid发生歧义。

　　示例: http://api.twitter.com/statuses/user_timeline.xml?user_id=1401881

　　screen_name：可选参数.微博昵称，主要是用来区分用户UID跟微博昵称一样，产生歧义的时候。

　　示例: http://api.twitter.com/statuses/user_timeline.xml?screen_name=101010

　　since_id：可选参数（微博信息ID）. 只返回ID比since_id大（比since_id时间晚的）的微博信息内容

　　示例: http://api.twitter.com/statuses/user_timeline.xml?since_id=12345

　　max_id: 可选参数（微博信息ID）. 返回ID不大于max_id的微博信息内容。

　　示例: Example: http://api.twitter.com/statuses/user_timeline.xml?max_id=54321

　　count: 可选参数. 每次返回的最大记录数，最多返回200条，默认20。

　　示例: http://api.twitter.com/statuses/user_timeline.xml?count=200

　　page： 可选参数. 分页返回。注意：最多返回200条分页内容。

　　示例: http://api.twitter.com/statuses/user_timeline.xml?page=3

　　statuses/mentions

　　显示20条最近的对用户的回复消息， ( 消息前缀为 @username ) 。该API只开放给认证用户，请求其他用户的收到的回复消息列表是非法的，无论其他用户设置私密与否。

　　访问地址：http://api.twitter.com/statuses/replies.format

　　支持格式 ( format ) ：xml, json, rss, atom

　　参数列表：

　　since_id. 可选参数. 返回ID比数值since_id大（比since_id时间晚的）的提到。

　　示例: http://api.twitter.com/statuses/mentions.xml?since_id=12345

　　max_id. 可选参数. 返回ID不大于max_id(时间不晚于max_id)的提到。

　　示例: http://api.twitter.com/statuses/mentions.xml?max_id=54321

　　count. 可选参数. 每次返回的最大记录数（即页面大小），不大于200，默认为20。

　　示例: http://api.twitter.com/statuses/mentions.xml?count=200

　　page. 可选参数. 返回结果的页序号。注意：有分页限制。

　　示例: http://api.twitter.com/statuses/mentions.xml?page=3

　　用户消息相关方法

　　statuses/show

　　返回指定Id的一条消息，返回信息中包含作者信息。

　　访问地址：http://api.twitter.com/statuses/show/id.format或者

　　http://api.twitter.com/statuses/show.format?id={id}

　　支持格式 ( format ) ：xml, json

　　参数列表:

　　id. 必须参数(微博信息ID)，要获取已发表的微博ID,如ID不存在返回空

　　示例: http://api.twitter.com/statuses/show/142277.xml

　　statuses/update

　　更新认证用户的消息，必须包含content参数，且必须以POST方式请求。 成功时按指定格式返回当前的消息。

　　访问地址：http://api.twitter.com/statuses/update.format

　　支持格式 ( format )：xml, json

　　参数列表:

　　status. 必填参数， 要更新的微博信息。必须做URLEncode,信息内容部超过140个汉字,为空返回400错误。

　　in_reply_to_status_id. 可选参数，@ 需要回复的微博信息ID, 这个参数只有在微博内容以 @username 开头才有意义。

　　lat. 可选参数，纬度，发表当前微博所在的地理位置，有效范围 -90.0到+90.0, +表示北纬。只有用户设置中geo_enabled=true时候地理位置才有效。

　　long. 可选参数，经度。有效范围-180.0到+180.0, +表示东经。

　　statuses/destroy

　　根据指定的id删除一条消息，认证用户必须是消息的作者。

　　访问地址：http://api.twitter.com/statuses/destroy/id.format

　　支持格式 ( format ) ：xml, json

　　参数列表:

　　id 必须，待删除的消息Id， 例如：

　　http://api.twitter.com/statuses/destroy/12345.json

　　或者

　　http://api.twitter.com/statuses/destroy.xml?id=23456

　　用户操作接口

　　users/show

　　显示指定用户的扩展信息，需要给定用户的id或显示名称。扩展信息包括用户的页面设置、微博次数等，因此第三方应用的开发者可以根据这些信息为用户提供合适的主题。

　　注意：本API调用请求必须发自合法微博用户，不论请求自己/他人的扩展信息。

　　访问地址：http://api.twitter.com/users/show.format

　　支持格式 ( format )：xml, json

　　参数列表：

　　id. 用户UID或微博昵称。

　　示例: http://api.twitter.com/users/show/12345.json 或 http://api.twitter.com/users/show/bob.xml

　　user_id. 指定用户UID,主要是用来区分用户UID跟微博昵称一样，产生歧义的时候，特别是在用户账号为数字导致和用户Uid发生歧义。

　　示例: http://api.twitter.com/users/show.xml?user_id=1401881

　　screen_name. 指定微博昵称，主要是用来区分用户UID跟微博昵称一样，产生歧义的时候。

　　示例: http://api.twitter.com/users/show.xml?screen_name=101010

　　statuses/friends

　　返回认证用户的朋友列表，内含每个用户的当前微博信息。这个方法同样可以用来请求其他用户的朋友列表，通过下面指明的方法传递id参数。

　　访问地址：http://api.twitter.com/statuses/friends.format

　　支持格式 ( format )：xml, json

　　参数列表:

　　id. 选填参数. 要获取的 UID或微博昵称

　　示例: http://api.twitter.com/statuses/friends/12345.json

　　http://api.twitter.com/statuses/friends/12345.xml

　　user_id. 选填参数. 要获取的UID

　　示例: http://api.twitter.com/statuses/friends.xml?user_id=1401881

　　screen_name. 选填参数. 要获取的微博昵称

　　示例: http://api.twitter.com/statuses/friends.xml?screen_name=101010

　　cursor. 选填参数. 单页只能包含100个关注列表，为了获取更多则cursor默认从-1开始，通过增加或减少cursor来获取更多, 如果没有下一页，则next_cursor返回0

　　的关注列表

　　示例: http://api.twitter.com/statuses/friends/williamlong.xml?cursor=-1

　　示例: http://api.twitter.com/statuses/friends/williamlong.xml?cursor=1300794057949944903

　　count. 可选参数. 每次返回的最大记录数（即页面大小），不大于200,默认返回20。

　　示例: http://api.twitter.com/statuses/friends/bob.xml?&count=200

　　statuses/followers

　　返回认证用户的订阅者，内含每个订阅者的当前消息。与friends一样，只需要把friends地址中的friends替换为followers即可，其余一切包括参数都不需要改变，都是一样的用法。

　　访问地址：http://api.twitter.com/statuses/followers.format

　　支持格式 ( format )：xml, json

　　参数列表:

　　id. 选填参数. 要获取粉丝的 UID或微博昵称

　　示例: http://api.twitter.com/statuses/followers/12345.json or http://api.twitter.com/statuses/followers/bob.xml

　　user_id. 选填参数. 要获取的UID

　　示例: http://api.twitter.com/statuses/followers.xml?user_id=1401881

　　screen_name. 选填参数. 要获取的微博昵称

　　示例: http://api.twitter.com/statuses/followers.xml?screen_name=101010

　　cursor. 选填参数. 单页只能包含100个粉丝列表，为了获取更多则cursor默认从-1开始，通过增加或减少cursor来获取更多的，如果没有下一页，则next_cursor返回0

　　粉丝列表 示例: http://api.twitter.com/statuses/followers/barackobama.xml?cursor=-1 示例: http://api.twitter.com/statuses/followers/barackobama.xml?cursor=1300794057949944903

　　count. 可选参数. 每次返回的最大记录数（即页面大小），不大于200,默认返回20。

　　示例: http://api.twitter.com/statuses/followers/bob.xml?&count=200

　　私信操作方法

　　direct_messages

　　返回用户的消息列表

　　访问地址：http://api.twitter.com/direct_messages.format

　　支持格式 ( format ) ：xml, json, rss, atom

　　参数列表:

　　since_id. 可选参数. 返回ID比数值since_id大（比since_id时间晚的）的私信。

　　示例: http://api.twitter.com/direct_messages.xml?since_id=12345

　　max_id. 可选参数. 返回ID不大于max_id(时间不晚于max_id)的私信。

　　示例: http://api.twitter.com/direct_messages.xml?max_id=54321

　　count. 可选参数. 每次返回的最大记录数（即页面大小），不大于200。

　　示例: http://api.twitter.com/direct_messages.xml?count=200

　　page. 可选参数. 返回结果的页序号。注意：有分页限制。

　　示例: http://api.twitter.com/direct_messages.xml?page=3

　　direct_messages/sent

　　返回用户的已发送消息列表

　　访问地址：http://api.twitter.com/direct_messages/sent.format

　　支持格式 ( format ) ：xml, json, rss, atom

　　参数列表:

　　since_id. 可选参数. 返回ID比数值since_id大（比since_id时间晚的）的私信。

　　示例: http://api.twitter.com/direct_messages.xml?since_id=12345

　　max_id. 可选参数. 返回ID不大于max_id(时间不晚于max_id)的私信。

　　示例: http://api.twitter.com/direct_messages.xml?max_id=54321

　　count. 可选参数. 每次返回的最大记录数（即页面大小），不大于200。

　　示例: http://api.twitter.com/direct_messages.xml?count=200

　　page. 可选参数. 返回结果的页序号。注意：有分页限制。

　　direct_messages/new

　　以认证用户的身份向指定的其他用户发送一条有向消息，必须包含参数user和text,请求必须使用POST方式提交。成功将返回完整的发送消息必须包含参数user和text，必须使用POST方式提交。成功将返回完整的发送消息。

　　访问地址：http://api.twitter.com/direct_messages/new.format

　　支持格式 ( format ) ：xml, json

　　参数列表：

　　user: user_id或者screen_name

　　text: 必须参数. 要发生的消息内容，需要做URLEncode，文本大小必须小于300个汉字

　　direct_messages/destroy

　　       通过给定的消息id，删除指定的有向消息，认证用户只能删除其作为接受者收到的消息。使用POST和GET方法都可以
访问地址：http://api.twitter.com/direct_messages/destroy/id.format

　　支持格式 ( format ) ：xml, json

　　参数列表：

　　id. 必填参数，要删除的私信主键ID.

　　示例: http://api.twitter.com/direct_messages/destroy/12345.json

　　好友关系操作方法

　　friendships/create

　　创建认证用户与给定的id参数指定的用户之间的好友关系；该操作执行成功时返回被加为好友的用户信息，执行失败则返回失败的状态字串。

　　访问地址：http://api.twitter.com/friendships/create/id.format

　　支持格式 ( format ) ：xml, json

　　参数列表：

　　下面的参数必须有其中一个:

　　id. 必填参数. 要关注的用户UID或微博昵称

　　示例: http://api.twitter.com/friendships/create/12345.json or http://api.twitter.com/friendships/create/bob.xml

　　user_id. 必填参数. 要关注的用户UID,主要是用在区分用户UID跟微博昵称一样，产生歧义的时候。

　　示例: http://api.twitter.com/friendships/create.xml?user_id=1401881

　　screen_name.必填参数. 要关注的微博昵称,主要是用在区分用户UID跟微博昵称一样，产生歧义的时候。

　　示例: http://api.twitter.com/friendships/create.xml?screen_name=101010

　　follow. 可选参数。暂不支持。

　　friendships/destroy

　　用来注销同指定id的用户的好友关系，当操作成功时，将返回被取消好友关系的用户，当失败时，将会返回失败信息。

　　访问地址：http://api.twitter.com/friendships/destroy/id.format

　　支持格式 ( format ) ：xml, json

　　参数列表：

　　下面的参数必须有其中一个:

　　id. 必填参数. 要取消关注的用户UID或微博昵称

　　示例: http://api.twitter.com/friendships/destroy/12345.json or http://api.twitter.com/friendships/destroy/bob.xml

　　user_id. 必填参数. 要取消关注的用户UID,主要是用在区分用户UID跟微博昵称一样，产生歧义的时候。

　　示例: http://api.twitter.com/friendships/destroy.xml?user_id=1401881

　　screen_name. 必填参数. 要取消的微博昵称,主要是用在区分用户UID跟微博昵称一样，产生歧义的时候。

　　示例: http://api.twitter.com/friendships/destroy.xml?screen_name=101010

　　friendships/exists

　　用来检验两个用户的关系是否是朋友关系或者跟随与被跟随的关系。返回相互跟随的关系结果。比如：A跟随了B。B没有跟随A。将返回对应的格式数据：如xml，<result><AFollowB>true</AFollowB><BFollowA>false</BFollowA></result>

　　访问地址： http://api.twitter.com/friendships/exists.format

　　支持格式：xml, json

　　参数列表：

　　user_a. 必填参数，要判断的用户UID

　　user_b. 必填参数，要判断的被关注人用户UID

　　friendships/show

　　返回两个用户关系的详细情况

　　访问地址： http://api.twitter.com/friendships/show.format

　　支持格式：xml, json

　　参数列表：

　　以下参数可不填写，如不填，则取当前用户

　　source_id. 源用户UID

　　示例: http://api.twitter.com/friendships/show.xml?source_id=10502

　　source_screen_name. 源微博昵称

　　示例: http://api.twitter.com/friendships/show.xml?source_screen_name=bob

　　下面参数必须选填一个:

　　target_id. 要判断的目的用户UID

　　示例: http://api.twitter.com/friendships/show.xml?target_id=10503

　　target_screen_name. 要判断的目的微博昵称

　　示例: http://api.twitter.com/friendships/show.xml?target_screen_name=williamlong

　　获取用户列表方法

　　friends/ids

　　用来获取指定的用户的朋友用户id。即自己跟随的人的id

　　访问地址：http://api.twitter.com/friends/ids.format

　　支持格式：xml, json

　　参数列表：

　　id. 选填参数. 要获取好友的UID或微博昵称

　　示例: http://api.twitter.com/friends/ids/12345.xml or http://api.twitter.com/statuses/friends/bob.xml

　　user_id. 选填参数. 要获取的UID

　　示例: http://api.twitter.com/friends/ids.xml?user_id=1401881

　　screen_name. 选填参数. 要获取的微博昵称

　　示例: http://api.twitter.com/friends/ids.xml?screen_name=101010

　　cursor. 选填参数. 单页只能包含5000个id，为了获取更多则cursor默认从-1开始，通过增加或减少cursor来获取更多的关注列表

　　示例: http://api.twitter.com/friends/ids.xml?cursor=-1 示例: http://api.twitter.com/friends/ids.xml?cursor=1300794057949944903

　　count. 可选参数. 每次返回的最大记录数（即页面大小），不大于5000，默认返回500。

　　示例: http://api.twitter.com/friends/ids.xml?count=200

　　followers/ids

　　用来获取指定的用户被跟随的用户id。

　　访问地址：http://api.twitter.com/followers/ids.format

　　支持格式：xml,json

　　参数列表：

　　id. 选填参数. 要获取好友的UID或微博昵称

　　示例: http://api.twitter.com/followers/ids/12345.xml or http://api.twitter.com/statuses/friends/bob.xml

　　user_id. 选填参数，要获取的UID

　　示例: http://api.twitter.com/followers/ids.xml?user_id=1401881

　　screen_name. 选填参数，要获取的微博昵称

　　示例: http://api.twitter.com/followers/ids.xml?screen_name=101010

　　cursor. 选填参数. 单页只能包含5000个id，为了获取更多则cursor默认从-1开始，通过增加或减少cursor来获取更多的关注列表

　　示例: http://api.twitter.com/followers/ids.xml?cursor=-1

　　示例: http://api.twitter.com/followers/ids.xml?cursor=1300794057949944903

　　count. 可选参数. 每次返回的最大记录数（即页面大小），不大于5000，默认返回500。

　　示例: http://api.twitter.com/followers/ids.xml?count=200

　　用户帐号方法

　　account/verify_credentials

　　如果用户身份验证成功则返回 http状态为 200；如果是不则返回401的状态和错误信息。此方法用了判断用户身份是否合法。

　　访问地址：http://api.twitter.com/account/verify_credentials.format

　　支持格式：xml, json

　　参数列表：

　　account/update_profile

　　自定义微博页面的参数。只会修改参数更新项。

　　访问地址：http://api.twitter.com/account/update_profile.format

　　支持格式：xml, json

　　参数列表：

　　必须有一下参数中的一个或多个，参数值为字符串. 进一步的限制，请参阅下面的各个参数描述.

　　name. 昵称，可选参数.不超过20个汉字

　　gender 性别，可选参数. m,男，f,女。

　　province 可选参数. 参考省份城市编码表

　　city 可选参数. 参考省份城市编码表,1000为不限

　　description. 可选参数. 不超过160个汉字.

　　收藏相关方法

　　favorites

　　返回授权用户的最新的20条收藏的状态信息。也可以通过id或者用户名来指定一个用户，查询他最新的20条收藏的状态信息。

　　访问地址：http://api.twitter.com/favorites.format

　　支持格式：xml, json, rss, atom

　　参数列表：

　　page： 可选参数. 返回结果的页序号。注意：有分页限制。

　　示例: http://api.twitter.com/favorites/11075.xml?page=3

　　favorites/create

　　收藏一条状态信息POST提交

　　访问地址：

　　http://api.twitter.com/favorites/create.format

　　支持格式：xml, json

　　参数列表：

　　id 必须，授权用户要收藏的状态信息id。

　　favorites/destroy

　　删除授权用户收藏的一条状态信息

　　访问地址：http://api.twitter.com/favorites/destroy/id.format

　　支持格式：xml, json

　　参数列表：

　　id 授权用户收藏的状态信息id。

网站技术分析报告之——开心网

　　读者投稿：一直在研究互联网技术，经常访问这样那样的网站，突发奇想，为什么我们不去看看这些网站的技术架构是怎么样的呢？研究一下源代码？于是便有了这个系列，首先找谁呢？还是找山寨版的开心网开刀吧，这个开心网，不是那个开心网，呵呵。

　　坦白说，我不太想注册，也不想研究太多太多，一般来说，一个网站最重要的是首页，Ok，那我们就从首页开始吧。

　　本系列文章仅仅是个人研究发布，仅供参考。

　　分析工具：各种浏览器，firebug（一个基于firefox的插件）

　　开心网首页是一个简单的登陆页，居然做到了385.2KB之大，像开心网这么大的流量，每多1kb就意味着每天N多的钱哪。我没有找到官方的pv 或独立Ip的数据，根据alexa的数据参考一下吧，估计日均独立IP为528，000，我们估计按每独立IP访问一次登陆吧，实际上可能少一些，因为很多用户可能直接在首页上登陆了（alexa的数据也不是那么可靠，供参考吧）。

　　开心网的网页每增加1k，我们需要多少带宽？算一下，我们需要528，000/1024=515MB/天的带宽，然后我们平均一下，按一天24小时用户访问很平均来计算（实际上不可能，一般峰值访问会是平均值的一倍以上），每秒需要消耗带宽是528000 / （24小时 * 60分钟 * 60秒）=6Kb，考虑到峰值，估计要到12k以上。

　　看官，像开心网这么简单的登陆，完全可以控制在100k以内的大小，为什么要这么多呢，一会儿看网页的分析就可以知道了。这是什么概念？385-100=285k，再算出带宽得出：285k * 12k / 1024 = 3.3M.乖乖，开心网每天需要添加3.3M的独享带宽。3.3M的带宽会是多少钱呢？我们就以中档的机房来举例，北京中档的3M独立带宽，怎么也得3-5万块吧，再加上CDN的带宽，估计开心网每年需要为此增加5-8万的费用。

　　分析一下开心网存在的问题：

　　1. Javascript文件直接写在了网页当中

　　开心网的登陆页有大量的javascript的代码，这样的代码一方面不利于维护，另一方面，也不利用用户加载页面。大致计算了一下，开心网登陆页一个有180余行的javascript代码，而总代码仅在336行，也就是说代码中的javascript代码占了1/2 强。

　　2. 网页没有开启gzip

　　根据文件头返回的信息可以看到，开心网应该在linux上搭建了nginx ，添加gzip应该不会是很难的事吧？而且像html及静态js/css这些文件，gzip后起码可以减少50%的传输量，当是这一项，就可以每年省下上百万的费用。

　　当然有人会反对，认为gzip会加重服务器的压力，并且客户端解压的时间与减小文件大小带来的传输速度不会有太多好处。但我认为，对于静态文件来说，可以放到独立的服务器，这个服务器可以把文件压缩后放到缓存中，这样不用去读IO，响应速度会提高。同时，虽然现在用户的带宽都已经是512k的 adsl以上了，但是为什么我不可以让用户更快的看到我们的网页呢？退一万步说，用户真的在乎这个快几秒的，那么我们为什么不可以减小带宽的压力以节省成本呢？如果把节省下的这些钱去奖励员工，没准他们可以给我带来更多的惊喜呢。

　　3. Javascript没有做任何处理

　　开心网的 javascript可真有意思，他们的开发人员代码质量还不错，起码注释写得还不错，可是问题是，你需要把这些注释都发到客户端么，难道开心网想教我们怎么写javascript代码？这样的代码发到客户端，既占带宽又会泄密网站的代码。

　　开心网的核心javascript文件xn.core.js有105k，这么大的其中注释占了不少的代码，我尝试使用yahoo和google的压缩工具进行压缩，但因为代码中有错误无法完成，所以只好放弃。但我估计这个js，最基本的压缩去除空行和注释，可以减少1/5左右的大小，如果进行一些混淆的话，应该可以在40k左右，如果再gzip的话，应该就只有15k以内了。

　　4. 图片文件过大

　　登录页有一个157k的sys-bj2.jpeg文件，天啦，这么大的。我下载这张图片一看，发现这个图片实际是同几张图片组合的。他们的设计人员其实是想减少网页对服务器的请求数，所以把几个图片合并到一块。但是，他们这种做法是错误的。

　　我们要减少请求数，一般是把小图片，一般是几k的36 px* 36px以下的小图片合并，而不是把大图片也合并。因为小图片数量多，而大图的合并，也会增加图片的大小。我将这个图片用ps再优化一下，优化到 66k，也没发现明显的失真。所以我认为，就算是大图，也可以优化到80k以内，而不是如此157k大小的图片。

　　再多一句，这个图片总量才5个合并是完全没有必要的，并且图片最大的有600px*255px，而最小的只有10px*10px以下，这种合并没有任何益处，百害而无一益！

　　总结

　　开心网作为一个访问量非常大的网站，网页结构也非常简单，理应做得更小，比如在100k以内。从我的分析中可以看出，主要问题集中在 javascript，gzip和图片上，代码质量总体还可以。当然，我们不仅只是挑刺，也应该看到一些好的地方，如下：

　　1. 首页处理得比较到位，虽然javascript也没有压缩，但总大小只有108k

　　2. 文件请求数较少，这个和开心网本身有关，开心网本来就不是一个网页结构复杂的网站，所以文件数自然会比较少了

　　3. 静态文件和网页分开部署

　　4. Javascript注释比较好，但不应该发到客户端

　　重要建议：

　　1. 开启gzip压缩

　　2. 压缩javascript及css，并将这些文件缓存起来

　　最后，这次的分析就写到这里了，就事论事而已，和任何网站及相关的人员没有任何关系，呵呵。

　　来源：读者Conis投稿，原文地址。版权声明：本文授转月光博客刊登，其他非授权网站媒体转载，需要添加作者网站地址http://iove.net，否则视为侵权。