历史记录/刷新

网易邮箱的内容区不是iframe，而是一个普通div，点左侧的导航栏按钮后通过js动态向这个div插入内容，有的直接是内容有的是iframe。

这里用js控制了页面内容的跳转，但跳转后页面的网址没有任何改变，后果就是：一，无论去到那里，刷新后都是回到首页。二，无历史记录，无法使用前进后退。

Q邮箱内容区是iframe，导航栏是普通链接，自然没有这些问题。gmail是通过hash值记录所在的页面(QQ阅读也是)，通过改变hash值就产生了历史(IE需要hack)，刷新功能也可用。

作为一个web应用直接忽视掉历史记录体验不太好，不过Q空间、google calendar也是这样，不知是不是觉得没必要？但我用这两个东西时还是会在想返回的时候去点击后退按钮，点完发现去到一个不知名的地方，很茫然和不爽

ipad细节

网易邮箱ipad版是模仿gmail的，但有些细节模仿得不到位。

ipad上webapp性能是很差的，要想一个像邮箱这样比较复杂的应用很好的运行在ipad上，得处处针对它做好优化。

在网易邮箱ipad版上快速地点击各个邮件标题，点多几次就会发现页面直接卡死了，有时十几秒才缓过来。邮件的上下翻页也一样，快速点击翻页，它也会因为反应不过来而卡死。主要原因应该是在切换邮件时不断的插入删除DOM，或者不断发送ajax请求，导致ipad反应不过来。

再看看gmail怎么处理这个问题。gmail点击一封邮件时不管它之前是否已经打开过，都会先显示一个loading图标，load完再出现内容。这样快速点击时就不会太频繁地添加删除dom，不会出现卡死。而上下翻邮件的按键那里，gmail每点一次都把按钮disable，内容显示出来后才恢复可点状态，这样就防止了快速点击，很聪明啊~

先看看这篇文章，《什么是重要的》，大意就是说HTML5没什么了不起，不过是多几个API，搞这些只能给你虚荣水平没有提高，不如多去学学底层的图形学数据库等东西。

我在这篇文章留了言，不知为啥没通过审核，没显示出来，我大概说：这跟大学老师的说法是一样的，各人的学习方式不一样，应该自己选择怎样的学习方式。

确实这篇文章的论调跟大学老师是完全一样的，学好数据结构算法，学好底层编程，还怕学不会那些高层的东西？这是有道理的，而且这还是经验之谈，学编程到了一定阶段肯定会有这样的感悟，高层的语言没什么，重要的是底层的知识。但实际上这可能给你的学习指了一条艰难的道路。

“对于程序员，真正的核心竞争力是基本功。”这话显然没错，但还有更重要的，那就是兴趣。

没有兴趣的学习是痛苦的，有兴趣的学习往往是不痛苦甚至是快乐的。

我学习的第一门语言是AS，因为它可以很容易跟图形配合做出一个成品一个游戏。我为什么喜欢做前端技术，因为你可以看到用它做出来的与界面相结合的交互效果，看着自己做出来的东西感觉很爽，这是兴趣所在，我才能不断深入去学习。一开始就捣鼓能实现绚丽效果的语言并不代表以后都只停留在这一层面上，你会想为什么它能做到这样，jquery用多了你会去看它的源码，再去看看别的框架的源码，学习它的架构，最后去看浏览器的源码，层层向下深入理解，这个过程是兴趣驱动的。

而如果是自底向上的学习就不一样了，在实验室里用C++编出来的控制台里对一个数组排序，或者输出一个日历，这样的东西恐怕难以让人提起兴趣。我就是因为这样一直对C++不怀好感，但是最近我开始在补C++的知识，因为我看到chrome这么快这么爽，有兴趣去了解它的实现。

当然各人的兴趣是不一样的，有人更愿意从底层开始学起，这样感觉踏实。看过一些所谓“忠告”会说大学期间不要去接触那些太高层的语言，学好那些基础课程才最重要，甚至连JAVA的那些框架都不要去碰，这个忠告有点傻，自底向上的学习和自顶向下的学习方式都是没问题的，看个人喜好去选择。其实我之前写的《关于学习》已经写得够多了，不再重复了。

所以捣鼓HTML5这些新东西是没问题的，它绚丽的效果会提升你深入了解相关知识的兴趣。只要你不完全停留在“顶”上，捣鼓那些新技术捣鼓了几年都还停留在那个层面，就完全没有问题。

P.S 其实很多新演示产生绚丽效果的是CSS3，跟HTML5没啥关系，不过把HTML5当HTML5和CSS3这一代的统称也没啥问题~

QQ阅读终于在今天上线了 http://reader.qq.com

就不介绍它是什么，上去看看就知道了。写写整个开发过程中的事情~

完美实习时间

我觉得我的实习时间挺完美，新版QQ阅读一个半月的开发时间，刚好在我两个月实习的中间，让我可以刚进来有一个星期的时间缓冲习惯，接着参与整个新产品的开发过程，上线后还有一个星期时间收尾，运气非常好。而且QQ阅读这个新产品做起来也很爽，本来我一进来导师问我希望参与哪块的开发，我就说是阅读空间，这也是我自己感兴趣的一个产品，一直感觉自己非常幸运。

历程

QQ阅读本来不是做成这种杂志的模样的，一开始是设计成google reader那样，后来开发一个星期后allen要试试把好友日志、热文和广播变成像flipboard那样杂志的形式试试看效果如何，打算自己订阅的rss还是传统阅读方式，而这三个栏目是新的阅读方式。后来做出来了，觉得这种杂志阅读方式效果很不错，于是全部抛弃之前做的，把整个QQ阅读都做成杂志的形式，重新定义产品了。

开发

本来在原来的分工里我只负责导航栏模块，做完后再做各个订阅模块的，这个倒挺轻松。后来尝试杂志形式时就先让我实现杂志这块，再到后来全部变成杂志形式，主要的杂志渲染翻页还有打开的文章那个模块还是让我继续负责做了，这块逻辑和细节很多，做起来有时感觉挺吃力，对整个代码没有了如指掌的感觉，因为急于做出效果和代码架构能力的不足，代码写得黏性十足，一坨一坨的。

某天突然来了一个需求，翻页的形式需要改变，然后发现我当时的代码根本没法实现那样的需求，而且代码这么乱也是得梳理一下了，于是把一部分代码重构了一下，花了两天的时间终于把整个流程写得更清晰一点了，这个重构太费脑了，过程比较艰难，重构后看着有把握的代码感觉还是挺好的。但到后来这些代码随着功能和细节的不断增加现在也还是变得挺难看了。接下来得看看能怎么整理一下。

不给力的firefox

在给杂志加动画效果时，firefox让人抓狂，在IE6-8、chrome、safari下翻页都不会卡，性能没有问题，但在firefox下就卡得要命，这点我研究了挺多，是不是框架的动画函数有问题，自己用了setInterval让它做最简单的动画去动，还试了用-moz-transform属性去移动，还是一样卡，再想是不是插入dom消耗的性能多，于是延迟了1秒确保它插完dom再做动画，还是一样。后来通过firebug逐步排查才发现做动画的那个外壳去掉阴影-moz-box-shadow和圆角-moz-border-radius后动画立马就跟chrome一样顺畅了，原来是这原因。解决了这个问题感觉真爽哈。

另外firefox下还有个问题，文章的滚动条很卡，后来在群上讨论后一刚进来的帅哥说滚动条的问题背景加个颜色background:#fff就快很多了，一试还真是，firefox这什么bug来着，firefox太不给力了，接二连三出现这样的性能问题，css的-moz私有属性要慎用。

团队开发

第一次体验到团队开发，还挺顺畅的，团队开发感觉也比个人开发轻松很多，例如我不需要管js如何跟后台交互，这一块全部由yiheng负责，我只需要调用他的接口就行了。另外我也不需要管后台，不需要设计，HTML跟CSS也不用写，做好我自己那些的逻辑就行了。但这样也少了很多跟后台那些人交流的机会，而且他们都坐得很近交流很方便，我的座位离他们很远，各种不方便，导致跟后台开发的人几乎没交流，不熟悉，而且也导致我对后台的实现一无所知，无从学起~

另外美工方面，杂志的外观从一开始一变再变，挺佩服alex的，我每次都觉得，都做得很好了，不需要再修改了吧，但还是持续不断地变动，跟最初的模样差别挺大了，我觉得现在的QQ阅读UI是很漂亮的。

上线&产品定义

今天上线后大家马上在微博上跟踪反馈，大多数反响很不错，看着这么个新生儿横空出世，大家也挺激动的，包括我~哈~我自己挺喜欢这个产品，用来快速浏览无目的地看东西挺爽的，深度阅读可能不那么合适。这样的阅读方式没有了未读数，鼓励娱乐式的阅读，消除信息焦虑。它跟传统RSS阅读器定位不一样，它本身就想消除”rss”这个概念，所以如果想像RSS阅读器那样追踪某一个博客，QQ阅读并不合适，就我来说如果想随便逛逛看点东西会用QQ阅读，如果是学习性地获取资讯我还是会用GR。

接下来

接下来大家当然会致力于把QQ阅读做得更好，后台向“您的个性化杂志”这个目标前进，通过各种数据筛选出对自己权重更高的文章。前端则致力于提供更好的用户体验，现在这个版本，可优化的空间还是非常多的。

给iquery加了跟jquery差不多的动画接口animate，不过实现上是通过CSS3的transition。

效果点这里 (桌面浏览器只支持webkit内核，如chrome/safari)

iQuery源码

（更多…）

效果见这里：http://bangswork.googlecode.com/svn/trunk/lab/effect/index.html

jquery的动画总体思路是：

有一个fx类专门处理动画，fx的各个实例共享一个timers数组和一个setInterval。对每个传进来的dom的每个属性值都新建一个fx实例去处理，一个fx实例对应一个dom的一个属性的变化。fx里有个step函数，可以计算出当前这个时刻这个属性要达到什么值。

这个step会通过共用的一个setInterval每13毫秒执行一次，这就可以使得它行成动画。另外如果浏览器速度太慢无法达到13毫秒执行一次step，动画也会按时完成，因为是根据当前系统时间计算属性要达到的值的。

每一个fx实例的step都会放进timers数组，实际上setInterval是持续执行timers里的每一个函数，这样只用一个setInterval就让众多属性“一起动”了。step里判断到超过了动画运行的时间，就会返回false让它从timers里移除，timers为空时clearInterval。

下面简单实现这整个过程：
（更多…）

1.把对象变成类数组

var a = { name : "jquery" },
b = ["elem1", "elem2", "elem3"];
Array.prototype.push.apply(a, b);
alert(a)	//[Object object]

//可以像遍历数组一样遍历这个对象
for ( var i = 0; i < a.length; i ++ ) {
	alert(a[i])
}

jquery就是用这种方法把jquery对象变成类数组的，效率还很高。

2.去掉一层嵌套数组

var a = [[1,2], 3, [4,5,6]];
var b = Array.prototype.concat.apply([], a);
console.info(b) 	//1,2,3,4,5,6

concat方法：

arrayObject.concat(arrayX,arrayX,……,arrayX)
concat() 方法用于连接两个或多个数组。arrayX为n个数组or元素参数
console.info([1].concat([2,3], 4)) //1,2,3,4

apply方法：

fn.apply(obj, args)
在obj的作用域下调用函数fn，并把数组args里的第i个元素作为第i个参数传给fn
例如
fn.apply(window, [1,2,3]) 等于 fn(1,2,3) (直接调用一个函数作用域就是window)

合起来就有上面那个效果了。

3.复制数组

利用Array.splice(0)可以快速复制一个数组

var a = [1,2,3],
b = a.splice(0);
alert(b)//1,2,3
alert(a==b)//false

4.高效合并字符串

var a = [“<div>”,”<span>”,”</span>”,”</div>”];
alert(a.join(“”)) //”<div><span></span></div>”

通过这种方式合并字符串效率比 + 号高了近七八倍，因为js的机制导致每次给字符串追加内容都是抛弃原有字符串新建另一个追加后的字符串，所以效率会低。

在firefox下测试：

var a = []
for (var i = 0; i < 100000; i++) {
	a.push("<div>");
}
console.time("arr");
a.join("");
console.timeEnd("arr");console.time("str");

var b = "";
for (var i = 0; i < 100000; i++) {
	b += "<div>";
}
console.timeEnd("str");
//arr:19ms
//str:141ms

效果见这里：http://cnbang.net/lab/txwb/

由于朋友分布在不同的微博，我希望有个同步到twitter、新浪微博、腾讯微博的工具，但等这么久都没出现这样的工具，微博通似乎停工了，也不支持twitter和腾讯微博，于是想自己做个。

新浪微博和twitter都开放API，要实现同步发送很简单，腾讯微博未开放，就需要hack一下了。这次把研究过程都记录下来了，写得很长~实际上在curl实现那部分我花的时间比较多，走的弯路也多，但由于篇幅原因那部分都简省了~

（更多…）

架设网址：http://cnbang.net/sinatwitese

项目主页：http://code.google.com/p/sinatwitese/

几个月前新浪微博找我做个实现微博所有功能的开源PHP客户端，换句话说就是把twitese改成用于新浪微博，但这样似乎没什么用，新浪微博又不用翻墙上，何必用到第三方网页客户端呢，想想可能是因为要有个微博应用的代码示例。

结果我花了点时间做出来，比较麻烦的是新浪微博的评论，下了挺多功夫的，其他都差不多，当时做到基本可以用了：

后来新浪的人有尝试修改一下外观，然后又很长一段时间毫无动静，我问了后才被告知他们不用这个了，打算自己写一个了，可能发现太难修改界面了，代码里还残留有很多twitter的东西，还不如自己写个效率高。于是我这个东西就无声无息地被埋葬了，现在掘出来晒晒太阳。

在腾讯广研实习半个多月了，说点东西。

氛围

广研里技术氛围挺好的，应该有八九成都是开发人员，里面除了leader请吃饭其他时候都不会感受到上下级的关系。这段时间我跟导师还有另外两人一起做一个东西，这应该是我第一次跟人一起做东西，并没有碰到想象中的合作的苦恼，他们都很好沟通而且很照顾我这个新手(非常感谢)，这次做的东西还是我自己喜欢的，所以整个过程很愉快。

因为工作是任务制的，上下班时间比较自由，大部分人10点多上班晚上8-10点走，但有时候新版本上线前夕会加班到很晚。据闻在腾讯工作压力还是挺大的，不知其他IT公司如何。

前端

腾讯的前端开发跟业界的不一样，一般前端开发是HTML/CSS/JavaScript，但腾讯把它们分离出来了，HTML/CSS部分叫页面重构，结果前端开发只需要写Javascript。前端开发这个刚刚上路的职业，一部分是由设计师转过来的，一部分由工程师转过来的，既然只需要写JS，那腾讯里的前端自然都是工程师转过来的。js在各浏览器的差异并没有那么大，让我感觉这跟用其他前后端任何语言开发并没有多大差别。在几次开会讨论方案的时候给我很浓厚的传统软件工程开发的感觉，以前我一直一个人做东西没有过这样的感觉。

对开发一个web应用(如Q邮箱)来说，js部分是一个大工程，可以用传统的软件工程方法去开发，跟HTML/CSS这部分用的是完全不同的技能，这部分偏向设计，而且需要考虑很多的浏览器差异，不应该由工程师做，分开来是合理的。对一个用js优化体验的网页(如淘宝)来说，纯粹的软件工程方法去开发不合适，需要新的技能树，合在一起是合理的。

分享

就前端界来说，技术分享和交流上为什么很少看到腾讯的影子？一没有blog，二在类似D2这些交流会上看不到腾讯影子，三没有开源产品。反观淘宝、百度、豆瓣这些公司都有不同程度的技术分享，特别是淘宝，有UEDBlog，很多员工都有写自己的技术blog，D2里大部分是淘宝的，最近还有开源框架KISSY。我问过导师这个问题，他说因为工作忙，上面需求不断下来，根本没时间做技术分享和交流，但公司还是鼓励这些技术分享的。

忙是主要原因，其他还有很多原因，可能是因为leader觉得分享技术并不会给公司和部门带来多少好处，做好上面给的任务才是正事。其实我觉得做好技术分享还是有好处的。

最主要的就是吸引人才加入。看过淘宝那些分享和BLOG的人都会觉得淘宝是前端开发人员的最佳去处。我看过腾讯ISD博客，我都觉得，如果我是学设计的，那我一定会以进这个部门为目标。最近我们组要招好几个前端开发人员，似乎比较难招到合适的人，我在twitter上有宣传一下，有人说，“广研在哪里？你们太封闭了，资料都搜不到”。嗯，有技术分享的BLOG，还能让人更好地了解内部环境，招人会容易一点。

其次是提高口碑，程序员是一个不小的群体，很多还属于所谓的“高端用户”，Q邮箱有很多细致的功能就是为了满足高端用户，让他们去散播口碑，而分享技术也同样可以达到这样的效果。

腾讯口号“最受尊敬的互联网企业”，说实话，虽然腾讯很强大，但要做到“最受尊敬”还差很远。不开放，不分享，只赚钱(或者说只做好各种各样的产品)，很难做到“最受尊敬”。

其实广研里技术是很强的，我们组每周也有“吹水会”，里面有很多很好的技术分享，没有分享出来，可能除了上面说的之外，还有我没想到的原因，这我就不明真相了~

之前碰到的学院教务员的事，校医院的事，从各方面反应来看，似乎每个学校都这样，或者更恶劣，特别是校医院，每个学校校医院必是一个受气的地方，其他行政部门也不会对你有好的态度。在社会上更是这样，公务员不是混日子就是混官场往上爬，政府部门办事的人员态度绝不会好，容易办的事拖上你几天是正常，心情不好了拿你出气也是正常。很多公立医院也是，只要不是会死人的病，他们就会随便敷衍了事，看病者低声下气，医生趾高气扬。

以下直接拿医院来说，其他政府部门直接代入，一样。

医生在这个对外的岗位上，如果对来看病的人态度好跟态度不好都无所谓无影响，那9成的人会倾向于对看病的人态度不好，因为每天都有那么多人找他们，很多人的问题还是重复的，很无聊，有时也烦躁，特别是自己心情不好的时候，肯定会顺便发泄到那些人身上。

主要就是这个“态度好态度不好都无所谓”这点上，看病者虽然是给了钱来看病的，但在医院上钱不是直接给医生的，医生只是这家医院的员工，于是你对医生的收入没什么影响（顺便说下，对他收入有影响的是他开的药，所以都倾向于开很贵利润很高的那些药），他就算态度差他自己也不会损失什么，于是两个人关系不平等了，你没有什么权力可以制约医生对你态度好，医生却有整个给你看病的权力，于是相当于是你求他给你看病。

要解决这样的问题其实很简单，看看中国移动和某些银行营业厅怎么做，每次服务过后都有满意度调查，调查非常方便，只需要你动一下手指，而且调查是匿名的对方也不知道，总体的满意度会对他们有很大影响，给了客户一定的权力，而这个权力虽然不小但也不算大，因为如果客户态度太恶劣，服务员发飚一两次一个月只获一两个差评也不会那么大影响。于是双方关系就平等了。

应该所有政府部门和医院都有这样的评价机制，因为他们不像私营企业和个体户，需要保证客户满意才能活下去，他们什么压力都没有，需要这样的机制让客户制约他们。

那为什么他们不搞这样的机制呢，因为这对他们没多大好处。政府部门和公立医院相当于垄断行业，态度差你照样还得来办事还得来看病，我们态度恶劣你们不爽是你们的事。每个地方都装模作样地放了个投诉信箱，但有多少人真正去写，写了又会不会真正去理会真正有作用？明显装装样子罢了。能影响他们收入的，医院是给你开高价药，政府部门是巴结上级往上爬。普通人民的不满意算个屁。

其他国家怎么解决这问题呢？解决方法就是让普通人民的不满意不算个屁，算很大事。就是州长直接选举，你干不好下一届就滚蛋。那州长就得制约下面的人善待人民他才能坐好位置。在咱国家，“公仆”们干不干得好滚不滚蛋得看上面的意思而不是下面的意思。所以大体制不改，其他小问题改不了。