Technology


Dec4

iTunes Match使用心得

做为在内测时就开始使用iCloud中的iTunes Match的一员,有必要写一篇blog来介绍这个值得推荐的Apple服务。 关于iCloud和iTunes match的介绍就不多说了,apple的官网上已经介绍的很清楚。对于我来说,iCloud真的很赞,因为我截止今天,已经拥有五台Apple设备(iPad、iPhone、Macbook Pro、Mac mini以及上周公司刚发的Macbook air),一直以来,我都很苦恼保持这些设备上的数据同步,直到iOS 5和lion出现,事情有了一些转机:iOS可以wifi同步,有了iCloud备份,有了photo stream,而前段时间出现的iTunes match终于一举解决了我听音乐的问题。 我的音乐库在家里的Mac mini,一共100多G,全是由iTunes管理的,之前我根本没法真正保证公司使用的MBP和家里的音乐库同步,只能靠手动拷贝。而iTunes match能帮我建立一个云端的音乐库,只要有网络,我就可以随时在音乐库里选择我想听的歌。而且它可以把盗版歌曲“洗白”,并提高音质到256kbps,只要在iTunes商店中有相应的歌曲即可。 简单介绍一下使用过程: 购买iTunes Match需要US信用卡,可以参考本文,购买并开启以后,首先是读取你iTunes库中的歌曲信息。 接下来是将歌曲信息上传到iTunes商店进行匹配。这两步的时间都不长,耐心等待即可。 而第三步就比较漫长了,它会将没有匹配到信息的歌曲上传到iCloud,我有将近2000首歌需要上传,花了一天多时间才搞定。上传完毕以后就大功告成了,你可以在另外一台机器上登陆账号开启iTunes match,就会看到库中所有歌曲。 另外,告诉大家怎么把音乐“洗白”。其实很简单,选中一首你需要“洗白”的音乐,选择删除本地歌曲即可。 这时你可以重新下载,就变成了265kbps的正版歌曲。不过,音乐的信息仍然是原来的样子,因此,想借助iTunes match来整洁曲库的朋友就死心吧。此外,在iOS上开启iTunes match以后,也能随时在线播放iCloud曲库中的歌曲。 总的来说,如果你有一个比较大的曲库,并且有多台Apple设备,选择iTunes match能帮你解决音乐同步的问题,$25的价格很物有所值。

trackback Tags: 评论 (4)

Jun2

如何做到API兼容

本文主要介绍什么是API,以及API兼容的重要性,最终给出方案如何评估API,以及如何做到API兼容。 What’s API? API的全称是application programming interface。 而很多时候,程序开发者仅仅把函数、类的接口做为API的一部分,而忽略了其他重要的编程接口。 事实上,在前端Javscript编程中常见的API包括: 函数、类接口,包括参数,返回值,函数对外部对象(常常是DOM)的具体操作等 网络接口协议,如和后端交互的JSON、XML数据格式,或者script回调中的函数名 样式以及HTML接口 外部依赖(对浏览器具体特性的依赖) 一些无意泄露的内部实现 越往后的API,越隐晦,越不容易受到重视,但是一旦这些API发生变化,可能会导致调用方出现不符合预期甚至程序直接报错的情况。 Why API cannot be changed? API是程序协同开发的重要保证,API的用户希望API的提供方提供的是一段功能明确、接口明了的程序。更重要的是,用户更期望在程序升级以后,他们能够“不经思考”地升级这些第三方代码。 一旦上述提到的5个API中的任何一个发生变化,可能会给他们带来巨大的代价,用户需要排查所有调用的代码,需要更改一些协议,需要调整所有与之相关的部分,这些工作对他们来说都是额外的,在预期之外的。如果辛辛苦苦完成这些以后,还在测试过程中发现了相关的bug,那对用户的打击就更大了。 如果API经常发生变化,用户就会失去对这段程序的信任,他们会更倾向自己获得源代码以后,按照自己的需求进行修改,自行维护一个内部的API比调用一个不断发生变化的外部API要容易接受的多,虽然这样做和我们协同开发、模块化开发的初衷是完全相悖的。 最后,我们为什么要修改API呢?为了API看起来更加漂亮?为了提供更多有趣的功能?还是仅仅我们觉得到了改变了时候了?对于用户来说,他们更愿意使用一个稳定但是看起来不那么时髦的API,而不是使用一个很时髦,但是会经常变动的API。在这个问题上,项目开发者是实用派。但这并不意味着我们不再改进API了,在后面,我会具体介绍如何能让API保持稳定的同时,让API持续改进。 Quality of API 在正式说兼容性之前,首先要明确一下,什么是好的API,因为导致API的不兼容的根源总是来自一个想法:“期望通过这次改变把API变得更好”。 容易理解 如果一个API不能让大多数使用者快速学会,这一定不是一个好的API。 比如iOS的滑动解锁,老人和小孩都能都能一次解锁,而Nokia的经典两键解锁,你懂的。 一致性 一致性能大大降低用户的学习和使用成本,用户过去的努力学习,能持续的收效。 容易查找和学习 API必须要有文档,并且介绍清晰,提供尽可能多的示例和可copy-paste的代码,降低用户的使用门槛。 提供简单的方案 API要能解决复杂的问题,提供很多可配置项,但是对于那些最常见的case,如果有一个简单的方案供给用户使用,这样能大大提高API的可用性 保护用户在API上的已有工作 用户过去在调用API、基于API开发所做的工作,这样才能给用户带来价值的同时,不破坏他们过去的劳动成果。 如何保证API的兼容 采用良好的设计思路 在设计过程中,如果能按照下面的方式来进行设计,会让这个API生命更长久 面向用例的设计,收集用户建议,把自己模拟成用户,保证API设计的易用和合理 保证后续的需求可以通过扩展的形式完成 第一版做尽量少的内容,由于新需求可以通过扩展的形式完成,因此尽量少做事情是抑制API设计错误的一个有效方案 对外提供清晰的API和文档规范,避免用户错误的使用API,尤其是避免API(见第一节)靠后级别的API被用户知晓与误用 除此之外,下面还列出了一些具体的设计方法: 方法优于属性 工厂方法优于构造函数 避免过多继承 避免由于优化或者复用代码影响API 面向接口编程 扩展参数应当是便利的 对组件进行合理定位,确定暴露多少接口 提供扩展点 有效的API评审 […]

trackback Tags: 评论 (2)

Apr18

百度前端的七巧板 - infoQ百度技术沙龙第13期

上周六做为infoQ百度技术沙龙讲师,给大家分享了《百度前端的七巧板——Tangram JavaScript库》,讲的是在设计Tangram的时候,我们有过什么样的考虑,采用了怎样的解决方案,契合这次沙龙的主题:“JavaScript库的设计与应用”的前半部份。但是由于这个slide是第一次讲,准备不够充分,比预计时间提前十分钟就结束了。其实还有很多重要的细节和有意思的东西没有介绍到。 不过,来参加沙龙的朋友中,很少有在企业和团队中做通用技术的研发工作的人。后面QA时间,我收到了20多张提问纸条,大多是问一些技术细节和功能实现方面的问题。而事实上,做为一个开源项目,所有的细节都可以在 http://tangram.baidu.com里面找到。 大家可以去SlideShare上看到我的slide。 如果大家还有什么问题或看法,欢迎在下面留言讨论。

trackback Tags: 评论 (1)

Dec30

Tangram base的设计

上周,Tangram开源了,有不少人阅读代码后提出了自己的意见、对Tangram的期望,很感谢这些热心的朋友的支持。与此同时,也看到了一些对Tangram设计的疑问,因此想在周末写一篇小文来介绍一下,但由于恰逢年底,小组内一堆杂务要处理,加上咳嗽很严重,一直延到今天。 这篇文章主要是介绍在设计Tangram base时的一些考虑,以及它适合做什么事情。 细粒度拆分 只要看过Tangram文档或源码的人,一定会发现它拆分粒度够细。将每一个方法独立写成一个文件,用户可以通过codeSearch功能,获得定制好的Tangram,然后基于其开发业务组件和逻辑。 在百度来说,前端工程师一直都很关注流量和加载性能,按需定制可以最大程度的节省带宽、加快页面的加载和渲染速度。 同时,Tangram面向的产品跨度广,从搜索产品到社区产品到商业产品,而工程师动手能力都很强,他们能很轻松的基于Tangram提供的方法集,封装一套适合自身的产品底层库。不同的产品间,封装差异会比较大,但是由于底层库相同,交流沟通并不会产生多少障碍。 静态方法,无污染 除了拆分粒度细之外,Tangram库名字空间整洁,所有的方法都是静态的,对环境的污染很小。 一些老产品中总会有一些匪夷所思的代码,而且很多产品中会有第三方代码,为了最大程度的避免冲突,Tangram仅仅暴露一个变量到window中,而且用户完全可以把Tangram放在闭包中使用,这样即使页面上出现两套Tangram,他们之间也不会有任何冲突。 复杂的RIA产品需要一个开发框架时,采用Tangram做为底层库也很有优势,因为Tangram是静态的,封装和覆写都特别方便,如果发现在自身环境下对某些函数有特别的要求(如性能要求极高),可以自己编写新函数覆盖。函数是独立而且简单的,开发人员也可以很方便的对其进行研究,了解原理进而更好的使用。 上面的内容大多是Tangram针对产品团队的设计考虑。而对于一些通用组件开发者,基于Tangram开发时,他可以把Tangram当成一个函数库,仅仅选取他需要的部分,保证组件的体积精简。同时不必遵从Tangram的封装方式,可以按照需求,封装出自己想要的风格然后release。事实上,百度内已经有数个以这种形式存在的通用组件。 改进 Tangram一直都在不断升级,简单说说我们接下来要做的几件事情: 修改库中方法调用的baidu前缀,这件事情会在下一个版本发布前完成,做为一个开源项目,它应该保持自己的独立性。 Codesearch整理后,也会被随项目放出,这样大家就能很方便的在本地选取任何一个版本的Tangram代码了。 我们会不断整理Tangram的设计细节,开发规范,工具,并且在社区和blog中发布,即使你不使用Tangram,也完全可以参考和借鉴我们的思路。 不断完善文档,良好的中文文档也是Tangram相对其他库的一个优势。 开发团队 在百度FE,我所在的小组叫通用组,负责包括Tangram的所有前端通用技术的研发与维护,同时所有工程师都可以贡献代码到Tangram。开源后,Tangram将接受更多来自百度外部的意见,保持Tangram的不断成长和进步。欢迎前往github的network(base,component)围观我们每天的代码提交,更欢迎各位fork,为Tangram提供想法和代码。 小结 这篇文章介绍了Tangram base的设计特点、面向场景等,做为一个基础函数库,Tangram base很容易被封装和扩展,你也可以很放心的使用它来进行二次开发。 Tangram的文档地址是:http://tangram.baidu.com,你也可以前往github查看最新的源码(dev分支) 我们基于Tangram base,开发了Tangram component,这是一个组件库,它的设计考虑和实现方式就更复杂了,这部分留到下次再谈,如果你关注Tangram,欢迎订阅我的blog。

trackback Tags: 评论 (4)

Dec22

Tangram Javascript库开源了!

2009年中旬,百度FE开始系统的整理、开发自己的前端Javascript库,从那时起,Tangram这个名字就诞生了。Tangram是”七巧板”的英译,选择Tangram(读音)这个词,是因为我们希望这个JS库,能够自由地组合到各个百度产品中,通过七巧板搭建出丰富多彩的产品。 经过一年多发展,Tangram已成为公司内部产品基础库的首选,近20个百度产品线已经使用Tangram做为其基础库。而现在,我们决定将这个库开放给整个互联网,希望有更多的团队和公司,通过Tangram搭建出自己的产品。 一方面我们希望能通过开源,促进国内前端开发者的交流,更重要的是促进自身的成长和进步。业界通行的开源工作方式的引入,来自社区的反馈和建议,都能让Tangram更加完善。 Tangram的目标是成为一个容易扩展和定制,集轻巧和高效于一体的团队开发类库。 我们的开源站点是:http://tangram.baidu.com,上面有详细的文档,DEMO和一些使用介绍。Tangram遵循BSD授权协议,你可以自由的使用他。你可以从github上获取源码,欢迎大家fork和pull。 Tangram分作两个部分,Base和Component。 Base部分是基础工具库,现包含200多个基础接口,已经发展到1.3版本,代码比较稳定; Component部分是组件库,现包含20余个UI组件和行为,19个动画特效,现在仍处于beta状态,我们还在不断的完善和改进。 除了现在已经开源的Base和Component部分,Tangram系还包括Tangram Editor(在线编辑器)和Tangram Mobile(移动设备库)。Tangram Editor已经使用在百度空间、百度百科、百度经验等产品线上,正在不断完善;Tangram Mobile集合了百度产品移动版的通用功能,仍在紧张开发中。这两部分我们也会择期开源,希望百度FE能不断地给中国前端带来惊喜。

trackback Tags: 评论 (3)

Dec11

中国velocity web性能与运维大会 – part 2

第一天晚上 最后一个session结束以后,还在问魏博士一些问题的时候,百姓网的人过来请他去参加晚上的一个交流沙龙,同时也邀请了我们。我看时间还早,就一起上了他们的大巴,在车上,我很累就睡了一会,结果一睁眼发现居然到石景山了。 到了咖啡店,大家先拿了一些东西各自吃完,然后轮番自我介绍,沙龙就开始了。我后面的一个隔断就坐着蒋博士,我看刘江老师站起来了,于是赶紧霸占了他的位置,一群人就开始围着他问起来。 最开始大家都会问一些技术问题,比如bigpipe的一些实现细节啦,pagelet的调用方式啦。他很惊讶我们在根本没有看到实现的情况下,就能提出一些细节性的问题,尤其是浏览器差异的问题,我们的一致答案是,因为经常都在处理这些问题,尤其是IE6的问题。然后我问他,facebook的用户,IE6占多少比例。他说之前应该在5%左右,最近经过一些推动,已经降到2%左右了。当知道国内浏览器份额和原因的时候,他连连惊叹,居然还有这么多的原因。 后面渐渐大家都比较放松了,话题也慢慢的聊开,他也会问我们一些国内互联网的情况。其实他们这类人最想知道中国互联网的状况,想找机会回来。因为已经在国外呆了这么多年,如果不想在大公司养老,回国就是他们的最佳选择了。有大公司的招牌,财富也积累的差不多了,中国又是一个正在成长的市场,到处都是机会。 快到结束的时候,百姓网还给他们的一个同事庆祝了生日,貌似这是他们的一项例行活动。他们现在只有10个技术人员,公司一共30人,规模很小,但是这次大会却给大家留下了比较深的印象。在第一天入场的时候给所有的参会者一瓶饮料,下午可以再领一瓶。饮料上有他们的广告,这样绝大多数人都知道了这是一个什么样的公司。他们的摊位也和其他赞助商不同,其他的都是广告视频+宣传册,几乎没有人停下来,而他们是一个叠杯子游戏,4秒以内可以赢一个鼠标,这样就吸引了很多人去玩,摊位背后的大海报浏览量应该不小。 第二天 第一个session是九点开始,于是我起了个大早,8点半就到达会场,抢了一个第二排的好座位。 卷土重来:服务器端JavaScript 这是老道在这次大会上的第二个session,主要讲的是nodejs这个服务端JS环境,因为我一半年前就用过nodejs,里面的概念都很熟悉,包括event loop的好处,服务端js能配合本地js,在一些比较老旧的浏览器上用服务端js直接返回数据,现代浏览器用客户端js等。 但是据我的使用,nodejs仍然是不稳定版本,之前我使用的时候,库特别少,而且接口不稳定,会发生比较大的变化。不知道现在情况如何了。 Facebook: 一个可持续发展的高性能网站 经过第一天facebook的两个很有内容的session以后,大家都对这个session充满期待,而实际上魏博士也没有让大家失望。前面两个sesssion主要是分别介绍了facebook的两套系统,而这个session说明了他们采用什么样的思路构建这样系统的,如何保证优化的可持续性。 他首先提出了一个观念:fast by default,facebook成长的速度很快,如何才能让它一直保持快速呢?答案是用一个小的团队,关注性能和前端架构,用架构来保证优化。 然后提出了性能优化的四个周期:系统架构 - 测量数据- 分析理解数据-优化。过去我们可能只关注最后的优化结果,而不关注数据的来源和分析,更不关注系统的架构。在08年的时候,扎克发现facebook很慢,于是成立了一个专门的20小组来解决这个问题,一个多季度以后,问题被解决了,同时他们还得到了一个结论:如果我们的系统不能保证优化,以后网站还是会变慢的。于是成立了一个3-4人的专门小组,来关注系统架构问题,直到现在。 系统架构主要包含三个重要的事情: 做一件事情只有一个办法 有清楚的最佳实践可以让工程师follow 开发的时候不用关心性能 其实就是让系统做好所有的事情,工程师只需要按照给定的方式去写代码,一定是最优的。 其中举了一个很有意思的例子:facebook的cookie曾经很大,大到居然有2K,对网站的速度影响很大,最终,他们将cookie精简到了400bytes,但是他们还发现,cookie就像野草一样,是拔不干净的,工程师永远会写新的cookie,找到他的时候,他说,我的项目很紧急,就要上线了,你让我上线以后再修改吧。但代码上线以后,他又会说,我现在还有很多事情要做,cookie这个事情我真的没法安排。 最后,他们在开发环境中部署了一个小程序:“cookie monster”,如果有人写了他们不认识的cookie,这个程序就会把cookie在传输的过程中直接删除,并且给页面返回一个消息“这个cookie很好吃,我吃掉了”。这样以后,工程师在发现问题的时候,就会主动来找他们,他们会告诉工程师如何使用服务端cookie来做同样的事情。 接下来就是让数据说话,其实就是将数据记录和分析系统化,报表自动生成,在上线以后进行分析。 最后是让所有人都参与优化,他们认为,速度是产品的一个目标,而不是额外的东西。因此所有工程师和产品团队都需要理解和关注这件事情,在新人培训时有专门的课程进行培训,在新产品上线之前,他们会进行指导,保证性能优化。 facebook的系统架构提醒了我,很多时候我们如果仅仅关注目的,和与之紧密相关的部分是不够的,只要底层架构优化了,一些上层的改变就是轻而易举的事情。 这个session以后,又是很长的广告时间,我趁机到会场外面找人聊聊天,接着发现魏博士也在,前一天晚上没有和他聊过,于是又获得了一些其他的信息,包括facebook前端系统的开发,测试,部署步骤等。内容比较多,我将在后面的blog中单独发出,欢迎订阅我的blog获得更新消息。 下午全是国内公司的交流,而且大多和前端关系不大,听了淘宝的商品详情页面的优化实践以后,就坐同事的车回公司了。 这次大会收获很超出我的预期,facebook的两位博士介绍的东西很实在,交流起来也很坦诚,问到一些具体的细节的时候,都能不厌其烦的一一告诉我们;Youtube的那个session也给我现在的实际工作带来了不少启发;Douglas和steve的session嘛,就当联系英语听力了罗。 如果你也参加了本次大会,或者你对上面的内容的细节有兴趣,欢迎在下面留下你的评论,或者follow我的twitter进行进一步交流。

trackback Tags: 评论

Dec10

中国velocity web性能与运维大会 – part 1

这周二、周三是中国velocity web性能与运维大会,一位同事因故不能参加,于是我代替他参加了本次会议。 会议在西四环的世纪金源酒店,第一天早上是九点半开始第一个session,因为对路况预测不够,早上八点半才从甘家口出门,一路堵车很厉害,九点二十才到达会场。而此时门口排队check in的人还很多,把酒店楼梯都塞住了,场面比较混乱。不过幸好排了不到几分钟队后,一位会务MM说,因为会议快要开始了,大家可以现在先入场。 第一个session是steve的WPO产业已经到来,其实就是一个开题演讲,因为大会所有的主题就是围绕着web性能来说的。 而接下来的三个session就是赞助者的广告时间罗,淘宝、基调网络、网宿轮番上台。 Facebook网站的Ajax化、缓存和流水线 上午最后一个session,是facebook蒋博士的“Facebook网站的Ajax化、缓存和流水线”。在主持人用英文介绍完他,他thank you以后,第一句话就是“其实我能说中文的”,把全场都逗笑了。整场也逗是用中文进行演讲,理解起来毫不费力。 他首先介绍了一个很重要的衡量网站用户体验的指标:TTI(time to interact),也就是页面主体部分加载完毕的时间。有了这个指标以后,他们可以将有限的资源优先分配到对用户体验有利的部分上。 Facebook网站的用户行为统计也是他们做性能优化的数据基础,他们的用户往往要一口气访问十几个甚至几十个页面,而且往往在3-5个页面以后会回到自己的个人主页。 接下来主要介绍了三个用来加速facebook的前端技术:quickling,pageCache,bigpipe。 quickling技术是一个使用异步请求代替页面跳转的技术; pageCache就是一个自动将页面缓存在客户端的技术,只有结合quickling的无刷新技术才能实现。 bigpipe是一个采用流水线串行处理技术,将所有页面非核心部分,通过ajax异步传输到客户端的技术。 quickling quickling技术用异步请求代替页面跳转以后,服务端不用拼接整个页面,而是只传送页面中改变了的部分到浏览器,不但服务器压力减轻了,而且传输量也减少了。数据显示,使用了这个技术以后,加载时间降低了10-30%,生成时间降低了20-30%。 pagecache pageCache技术会将页面缓存在客户端,做缓存往往要面对实时性和数据一致性的挑战。比如说,如果cache了某个页面,等用户回来的时候,这个页面上的内容已经被其他用户改变了,cache的页面就不是实时的了;或者用户在cache的页面上进行了一些操作,下次再访问这个页面的时候,如果再使用cache中的页面,数据就不一致了。 为了解决实时性,facebook增加了一个服务端的事件回调,如果发现本地页面和远程页面不一致,就刷新缓存;为了解决数据一致性,在客户端发生的任何操作都会被记录下来,下次返回到这个页面的时候回放操作。 bigpipe bigpipe会对页面所有非核心部分进行异步流水线处理,这时候TTI就派上用场了,bigpipe处理的是与TTI无关的模块,这些模块可以异步加载,为了不加重服务器的负担,facebook没有采用并行加载,而是采用了流水线式的串行加载。同时,创造了一个编程模型,可以很方便的创建和添加一个模块到页面上。 上午这个最后的压轴还是很精彩的,会后还有很多人围着蒋博士请教一些细节问题。facebook的这些手段其实在我们的产品中也有零散的用到,但是完全没有这样成体系,有一套基础架构和前后端统一的框架来保证。 下午第一场是Douglas的“更好的使用javascript”,都是大家熟知的一些东西,如果你看过老道的书,就会发现这些东西在他的书里都有。 YouTube的前端性能改进:逐步增强与超越 第二场是Youtube Alex的“YouTube的前端性能改进:逐步增强与超越”,他主要介绍了四个东西: 把js放在底部(确切的说是合理的位置) 预加载video连接 产品方面,采用了lightweight version来照顾一些网络情况不好的用户 UIX widget系统 比较有意思的是后面两点。 lightweight version 轻量版本这是一个从产品方面做出调整,来满足产品的性能要求的一个手段,youtube将原来160K的页面瘦身到18K,保证网络情况不好的用户能顺利加载。 而如何找到这些用户呢?两个手段:通过ip地理分布定位;通过客户端js代码判断加载速度定位。 UIX widget系统 这是一个UI组件框架,主要思想是: 基于行为 统一的事件处理,整个UIX widget只有一套事件,挂载在document上 class matching,js通过class找到要渲染的DOM元素,将他们渲染成widget 随时注册,渲染组件。 这和百度内部的一套UI框架思想有些类似。不过如果进行统一的事件管理,一般来说,这样只适合页面上几乎没有第三方脚本代码的产品,我不知道Youtube是否已经解决了与第三方脚本兼容的问题,而会后Alex给我的答案是,Youtube中几乎没有第三方代码,他们可以放心的接管所有事件。 下午的第三个session是Yahoo的构建Yahoo下一代Mail,但是我的笔记本没有电了,跑到墙壁的角落去蹲着充电,很多要点听的不是很清楚。只是发现Yahoo mail也实现了一套前后端模板统一技术,和公司内部的一些想法不谋而合。 静态网页资源的管理和优化 下午最后一个session是facebook魏博士的“静态网页资源的管理和优化”,这个session介绍了一个全方位的静态资源管理系统,这个系统中他们会将产品中的所有静态资源进行智能化打包。 什么是“智能化打包”呢?开发产品的时候,我们往往要进行模块化开发,比如说个人主页上有很多个模块:搜索框,广告,推荐好友,提醒模块等等,这些模块有自己独立的js文件和CSS文件,在上线的时候我们要把这些文件打包到一起。这个系统能帮工程师自动打包这些静态资源。 […]

trackback Tags: 评论 (4)

Oct30

百度前端技术交流会

敝公司前端技术交流会第一次对外开放,有幸被邀请成为嘉宾上台交流。 我分享的主题是:百度前端基础平台分享。提前放出Keynote下载 //update@10.31 根据 @catchen 的建议,把keynote放到了slideshare上。 另外,Q&A环节里面,有一个问题:你在开发这个基础平台时,最先要考虑的是什么? 我的答案:需求,公司产品线的需求。技术方案不是第一要考虑的,所有技术方案都应当基于产品线需求来设计。就像pm做决策一样,不是用户嚷嚷要什么,就应当要给什么,而是要深入分析产品线特点,站在通用的角度上去考虑,我应该提供什么。我的keynote的每一个部分都是从公司现状讲起,然后到设计,到解决方案。没有现状和需求谈设计和方案是没有什么意义的。看着Yahoo,google的方案,自己山寨一套,不考虑公司情况,也一定是不适用的。 基础平台,没有最好,只有最适合。

trackback Tags: 评论 (16)

Jun20

l2tp vpn搭建总结(linode ubuntu)

前段时间开始,公司的vpn开始不太好用了,因此我也逐步感觉到墙的力量。 恰好@Zealot有一个linode的vps,之前他搭了一个pptp的vpn,但是联通3g又不能使用pptp vpn,于是尝试自己捣鼓一个l2tp的vpn,断断续续尝试了几次,终于在今天成功了。 参考了很多网上的文章,发现网上的文章都没有涵盖到我碰到的种种问题,因此在这里针对我的案例,写一篇总结性的文章。 首先,按照apple4us的文章,安装一系列软件,写配置: sudo aptitude install openswan vim /etc/ipsec.conf config setup nat_traversal=yes virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12 oe=off protostack=netkey conn L2TP-PSK-NAT rightsubnet=vhost:%priv also=L2TP-PSK-noNAT conn L2TP-PSK-noNAT authby=secret pfs=no auto=add keyingtries=3 rekey=no ikelifetime=8h keylife=1h type=transport left=222.222.222.222 leftprotoport=17/1701 right=%any rightprotoport=17/%any 注意,ipsec.conf对格式要求很严格,缩进一定要有。 vim /etc/ipsec.secrets 222.222.222.222 %any: PSK “fan1qiang” 这里的psk要解释一下,这个是你在连接l2tp vpn时,需要填写的secret。 此外,别忘记把222.222.222.222替换成你自己服务器的ip(一共两处)。继续: for each in /proc/sys/net/ipv4/conf/* do echo 0 > $each/accept_redirects echo […]

trackback Tags: 评论 (2)

Apr16

iphone上的网游:we rule

最近一直在玩we rule,一个iphone上的网络游戏,app store中可以免费下载。 基本介绍 简单的说,这是一个让玩家建设和发展自己的王国,同时能和其他玩家进行互动的网游。 一开始的时候,玩家只有一个城堡和一点金钱,游戏有一个简单的任务系统,引导玩家开始建造农田,通过生产农作物赚钱、发展,建设民居获取税收,建设矿山等来生产物品获得收益。 王国是有等级的,可以通过建造店铺或者生产物品来获得经验值,然后升级。级别越高,王国能建造的东西越多,不但包括更多农作物,更多可以给王国带来收入的店铺,还包括各种装饰物,如树木、河流、雕像等等。 玩家可以按照自己的设想,打造属于自己的王国,比如我围着城堡建了一圈护城河,护城河内部有一些民居,护城河左边是农田,右边是很多裁缝店。 操作时间设定 不管是生产,还是建造,都是需要时间的。比如农作物,最短的是小麦,45秒就可以成熟,而也有成熟时间长达1天的豆子。因此玩家可以灵活按照自己的时间安排来种作物,因为不及时收获的农作物是会腐烂在农田里面的,这样就没有任何收入了。 时间设定是这样的小型网游最基本的要素,这样玩家的一次游戏过程不会太长,不容易厌烦,同时有一个时间限定后,玩家心理上不由自主的会想着这件事情,到时间回来看看。 巧妙的玩家共赢 稍微升几级,玩家将可以建造矿山、裁缝店这样的设施,这些东西本身是可以赚钱的,但是速度很慢,让收益最大化的方法是和其他好友进行交易,这样双方都能得到更大的利益: 某玩家的王国中有一个空闲的的店铺,他的follower就能在这里下订单,订单能给店铺的所有者一定的金币和经验,同时,下订单的玩家能得到店铺的产出物,他能用这些产出物“愉悦自己的子民”或者“建设城市”,也能得到一些经验值和金币。 因此,互相交易是一个只赚不亏的事情!相比开心农场的“偷菜”而言,这一招要高明的多了,玩家不会因为自己的店被人占用而有半点损失,他们会很乐意地添加好友,在论坛和blog上宣传自己。因为好友越多,自己王国里面的店铺的空闲率越低,收益也就越大。 看看一个订单完成的流程: A玩家来到B玩家王国中,下订单 B玩家接受订单 若干小时后,物品生产完毕 B玩家将物品交给A玩家(如果订单完毕一段时间后,B玩家仍然没有进行此操作,这个订单将失效。) 很明显的可以看到,订单的完成需要两个玩家操作三次,这样也就增加了游戏的黏性,玩家会不时的上来看看,家里是否有新的订单,是否有物品已经生产完毕。 下面的图可以看到,我的裁缝店有一些订单已经生产完毕,还有一些新来的订单。 这时候,可能你想到了,我加很多很多好友,然后到他们家里去下订单,我就可以很快的升级了。但是其实we rule有个限制,如果一个玩家在外面下的订单过多,那他自己王国里的店铺将不能接受其他人的订单。让自己王国里的店铺空着显然不是什么好事,因此玩家在下订单的时候就会尽可能选择一些性价比高的店铺。 我的ID是 cnberg,如果你也玩这个游戏,欢迎加我为好友哦。 一些问题 最大的问题是游戏速度太慢,不排除有网络连接的因素,但是如果能减少一些不必要的loading或者能压缩传输数据,游戏体验将更流畅。很多时候我需要等上好几分钟才能进入游戏,甚至就直接放弃了。游戏稳定性也存在一些问题,经常出现服务器无法连接或者数据混乱的bug。 其次,游戏到25级以后就没有任何盼头了,因为那个时候将无法升级,没有更多建筑物可供建造。而事实上,我达到20级以后,就觉得游戏性大大降低了。 此外,在游戏的设定上也有一些问题,比如说税收在游戏中的作用太小,一个民居只能每三小时提供4个金币。 总结 现在iphone上类似spymaster和开心农场类的网络游戏激增。在移动设备上进行这类操作简单的游戏实在很方便,用户不需要一直打开游戏,因为服务器的消息能及时被用户收到(push服务或者后台进程),而且由于设备一直在身边,玩家也可以随时掏出设备玩几分钟,不像PC游戏需要开机、上网等一系列麻烦的操作,同时还能和手机特性结合达到PC上无法实现的效果,如重力感应操作,基于位置的玩法等等。 摩根斯坦利最近发布的报告称2015手机互联网将超过桌面,手机上的游戏一定也会在最近飞速发展,颠覆传统的游戏方式。

trackback Tags: 评论 (1)