Category Archives: 前端制作

Chrome28中已经替换为Blink引擎

Google 宣布将在未来的 Google Chrome/Chromium 中使用基于 WebKit 的 fork Web 渲染引擎:Blink。同时 Opera 表示也将跟进 Google Chrome/Chromium 的步伐。  Google Chrome/Chromium 从创始至今一直使用 WebKit(WebCore) 作为 HTML/CSS 渲染引擎。WebKit 早先由 Apple 由 KHTML 项目 fork 出来,用于 Safari 浏览器的 Web 引擎。由于宽松的协议、轻量级的设计和便捷的应用程序内嵌 API,WebKit 逐渐变得流行起来,除了 Google Chrome/Chromium 和 Safari,它在移动终端( Symbian S60,Android,iOS)到 Toolkit 集成(GTK+, Qt4) 都有不错的收获。  尽管上面一众经常被统称为 WebKit,实际上各自都使用了自己的 WebKit 分支或者编译时选项,使得最终的渲染结果也是存在一定的差异的。不过大体上 WebKit 社区内部还是比较和谐的,各个成员之间也为维持兼容性作出了努力,直到 2010 年随着 OS X Lion 一起面世的… Read More »

[zz]由12306.cn谈谈网站性能技术

12306.cn网站挂了,被全国人民骂了。我这两天也在思考这个事,我想以这个事来粗略地和大家讨论一下网站性能的问题。因为仓促,而且完全基于本人有限的经验和了解,所以,如果有什么问题还请大家一起讨论和指正。(这又是一篇长文,只讨论性能问题,不讨论那些UI,用户体验,或是是否把支付和购票下单环节分开的功能性的东西) 业务 任何技术都离不开业务需求,所以,要说明性能问题,首先还是想先说说业务问题。 其一,有人可能把这个东西和QQ或是网游相比。但我觉得这两者是不一样的,网游和QQ在线或是登录时访问的更多的是用户自己的数据,而订票系统访问的是中心的票量数据,这是不一样的。不要觉得网游或是QQ能行你就以为这是一样的。网游和QQ 的后端负载相对于电子商务的系统还是简单。 其二,有人说春节期间订火车的这个事好像网站的秒杀活动。的确很相似,但是如果你的思考不在表面的话,你会发现这也有些不一样。火车票这个事,还有很多查询操作,查时间,查座位,查铺位,一个车次不 行,又查另一个车次,其伴随着大量的查询操作,下单的时候需要对数据库操作。而秒杀,直接杀就好了。另外,关于秒杀,完全可以做成只接受前N个用户的请求(完全不操作后端的任何数据, 仅仅只是对用户的下单操作log),这种业务,只要把各个服务器的时间精确同步了就可以了,无需在当时操作任何数据库。可以订单数够后,停止秒杀,然后批量写数据库。火车票这个岂止是秒杀那么简单。能不能买到票得当时告诉用户啊。 其三,有人拿这个系统和奥运会的票务系统比较。我觉得还是不一样。虽然奥运会的票务系统当年也一上线就废了。但是奥运会用的是抽奖的方式,也就是说不存在先来先得的抢的方式,而且,是事后抽奖,事前只需要收信息,事前不需要保证数据一致性,没有锁,很容易水平扩展。 其四,订票系统应该和电子商务的订单系统很相似,都是需要对库存进行:1)占住库存,2)支付(可选),3)扣除库存的操作。这个是需要有一致性的检查的,也就是在并发时需要对数据加锁的。B2C的电商基本上都会把这个事干成异步的,也就是说,你下的订单并不是马上处理的,而是延时处理的,只有成功处理了,系统才会给你一封确认邮件说是订单成功。我相信有很多朋友都收到认单不成功的邮件。这就是说,数据一致性在并发下是一个瓶颈。   其五,铁路的票务业务很变态,其采用的是突然放票,而有的票又远远不够大家分,所以,大家才会有抢票这种有中国特色的业务的做法。于是当票放出来的时候,就会有几百万人甚至上千万人杀上去,查询,下单。几十分钟内,一个网站能接受几千万的访问量,这个是很恐怖的事情。据说12306的高峰访问是10亿PV,集中在早8点到10点,每秒PV在高峰时上千万。 多说几句: 库存是B2C的恶梦,库存管理相当的复杂。不信,你可以问问所有传统和电务零售业的企业,看看他们管理库存是多么难的一件事。不然,就不会有那么多人在问凡客的库存问题了。(你还可以看看《乔布斯传》,你就知道为什么Tim会接任Apple的CEO了,因为他搞定了苹果的库存问题) 对于一个网站来说,浏览网页的高负载很容易搞定,查询的负载有一定的难度去处理,不过还是可以通过缓存查询结果来搞定,最难的就是下单的负载。因为要访问库存啊,对于下单,基本上是用异步来搞定的。去年双11节,淘宝的每小时的订单数大约在60万左右,京东一天也才能支持40万(居然比12306还差),亚马逊5年前一小时可支持70万订单量。可见,下订单的操作并没有我们相像的那么性能高。 淘宝要比B2C的网站要简单得多,因为没有仓库,所以,不存在像B2C这样有N个仓库对同一商品库存更新和查询的操作。下单的时候,B2C的 网站要去找一个仓库,又要离用户近,又要有库存,这需要很多计算。试想,你在北京买了一本书,北京的仓库没货了,就要从周边的仓库调,那就要去看看沈阳或 是西安的仓库有没有货,如果没有,又得看看江苏的仓库,等等。淘宝的就没有那么多事了,每个商户有自己的库存,库存分到商户头上了,反而有利于性能。 数据一致性才是真正的性能瓶颈。有 人说nginx可以搞定每秒10万的静态请求,我不怀疑。但这只是静态请求,理论值,只要带宽、I/O够强,服务器计算能力够,并支持的并发连接数顶得住10万TCP链接的建立 的话,那没有问题。但在数据一致性面前,这10万就完完全全成了一个可望不可及的理论值了。 我说那么多,我只是想从业务上告诉大家,我们需要从业务上真正了解春运铁路订票这样业务的变态之处。 前端性能优化技术 要解决性能的问题,有很多种常用的方法,我在下面列举一下,我相信12306这个网站使用下面的这些技术会让其性能有质的飞跃。 一、前端负载均衡 通过DNS的负载均衡器(一般在路由器上根据路由的负载重定向)可以把用户的访问均匀地分散在多个Web服务器上。这样可以减少Web服务器的请求负载。因为http的请求都是短作业,所以,可以通过很简单的负载均衡器来完成这一功能。最好是有CDN网络让用户连接与其最近的服务器(CDN通常伴随着分布式存储)。(关于负载均衡更为详细的说明见“后端的负载均衡”) 二、减少前端链接数 我看了一下12306.cn,打开主页需要建60多个HTTP连接,车票预订页面则有70多个HTTP请求,现在的浏览器都是并发请求的。所以,只要有100万个用户,就会有6000万个链接,太多了。一个登录查询页面就好了。把js打成一个文件,把css也打成一个文件,把图标也打成一个文件,用css分块展示。把链接数减到最低。 三、减少网页大小增加带宽 这个世界不是哪个公司都敢做图片服务的,因为图片太耗带宽了。现在宽带时代很难有人能体会到当拨号时代做个图页都不敢用图片的情形(现在在手机端浏览也是这个情形)。我查看了一下12306首页的需要下载的总文件大小大约在900KB左右,如果你访问过了,浏览器会帮你缓存很多,只需下载10K左右的文件。但是我们可以想像一个极端一点的案例,1百万用户同时访问,且都是第一次访问,每人下载量需要1M,如果需要在120秒内返回,那么就需要,1M * 1M /120 * 8 = 66Gbps的带宽。很惊人吧。所以,我估计在当天,12306的阻塞基本上应该是网络带宽,所以,你可能看到的是没有响应。后面随着浏览器的缓存帮助12306减少很多带宽占用,于是负载一下就到了后端,后端的数据处理瓶颈一下就出来。于是你会看到很多http 500之类的错误。这说明服务器垮了。 四、前端页面静态化 静态化一些不常变的页面和数据,并gzip一下。还有一个并态的方法是把这些静态页面放在/dev/shm下,这个目录就是内存,直接从内存中把文件读出来返回,这样可以减少昂贵的磁盘I/O。 五、优化查询 很多人查询都是在查一样的,完全可以用反向代理合并这些并发的相同的查询。这样的技术主要用查询结果缓存来实现,第一次查询走数据库获得数据,并把数据放到缓存,后面的查询统统直接访问高速缓存。为每个查询做Hash,使用NoSQL的技术可以完成这个优化。(这个技术也可以用做静态页面) 对于火车票量的查询,个人觉得不要显示数字,就显示一个“有”或“无”就好了,这样可以大大简化系统复杂度,并提升性能。 六、缓存的问题 缓存可以用来缓存动态页面,也可以用来缓存查询的数据。缓存通常有那么几个问题: 1)缓存的更新。也叫缓存和数据库的同步。有这么几种方法,一是缓存time out,让缓存失效,重查,二是,由后端通知更新,一量后端发生变化,通知前端更新。前者实现起来比较简单,但实时性不高,后者实现起来比较复杂 ,但实时性高。 2)缓存的换页。内存可能不够,所以,需要把一些不活跃的数据换出内存,这个和操作系统的内存换页和交换内存很相似。FIFO、LRU、LFU都是比较经典的换页算法。相关内容参看Wikipeida的缓存算法。 3)缓存的重建和持久化。缓存在内存,系统总要维护,所以,缓存就会丢失,如果缓存没了,就需要重建,如果数据量很大,缓存重建的过程会很慢,这会影响生产环境,所以,缓存的持久化也是需要考虑的。 诸多强大的NoSQL都很好支持了上述三大缓存的问题。 后端性能优化技术 前面讨论了前端性能的优化技术,于是前端可能就不是瓶颈问题了。那么性能问题就会到后端数据上来了。下面说几个后端常见的性能优化技术。 一、数据冗余 关于数据冗余,也就是说,把我们的数据库的数据冗余处理,也就是减少表连接这样的开销比较大的操作,但这样会牺牲数据的一致性。风险比较大。很多人把NoSQL用做数据,快是快了,因为数据冗余了,但这对数据一致性有大的风险。这需要根据不同的业务进行分析和处理。(注意:用关系型数据库很容易移植到NoSQL上,但是反过来从NoSQL到关系型就难了)… Read More »

ios6更新,safari增加对HTML5的支持

iOS 6中Safari对HTML5的支持 iOS6发布了beta版,其中包括了新版的Safari浏览器,增强了对HTML5的支持,我们来了解下吧~~ 目前,ios 5.1中safari在HTML5test.com的测试得分是324,而ios 6中safari的分数是360。 远程调试 新的远程调试工具可以更方便的在PC/Mac上对iOS上Safari中的页面进行调试,界面类似Android上的Chrome浏览器。  终于支持这个了,可以在浏览器中上传照片文件什么的了。。。内牛满面。。。 Audio API 这个大家也期待已久了吧,不多解释 CSS3 Filter 这个我们之前有介绍过,最新的 chrome 19正式版已经实现了该功能但是默认并没有开启,你需要通过about://flags(chrome://flags)来开启。 离线存储(app cache)数据限制从5MB提高到25MB requestAnimationFrame webkit私有api,不过基本除了opera,各个最新的浏览器也都开始支持了,详情查看MDN的介绍。 横屏模式下支持全屏 也就是fullscreen api了。 其它更新 更快的Javascript 好吧,每次更新都会有这个,不算新闻了。。。 智能app banner 类似windows 8中的IE10,允许打开网站时显示app信息。一种app和网站之间的连接方法。用户在safari中浏览你的网站的时候,可以告诉他你有个原生app,他可以安装或者打开它。

写给设计师的基础色彩论 [Part2]

Color Theory For Designers, Part 2: Understanding Concepts And Terminology If you’re going to use color effectively in your designs, you’ll need to know some color concepts and color theory terminology. A thorough working knowledge of concepts like chroma, value and saturation is key to creating your own awesome color schemes. In Part 1: The… Read More »

[zz]24款非常实用的CSS3工具终极收藏

对于Web设计和开发人员来说,CSS是非常重要的一部分,随着越来越多的浏览器对CSS3的支持及不断完善,设计师和开发者们有了更多的选择。如今,用纯CSS就可以实现各种各样很酷的效果,甚至是动画。今天这篇文章向大家推荐24款非常优秀的CSS3工具,为了获得更佳的效果,请在Chrome 4+, Safari 4+, Firefox 3.6+, IE9+, Opera 10.5+版本浏览器中浏览如下在线工具。 1.CSS3 Pie 使用CSS3 Pie可以让IE6至IE8版本实现大多数的CSS3修饰特性,如圆角、阴影、渐变等等。 2. CSS3 Click Chart 非常好的CSS3效果演示,提供了示例代码。   3.CSS3 Please! 非常帅的一款CSS3工具,可修改代码,即时预览。   4.CSS3 Button Maker 一个非常不错的CSS3按钮制作工具。 5.CSS3 Generator 非常不错的CSS3代码生成器,带预览效果。 6.CSS3 Menu 非常不错的CSS3菜单制作工具。 7.CSS3 Gradients 一款非常棒的CSS3渐变效果演示工具。 8.CSS3 Cheat Sheet 一份不错的CSS3属性速查手册(PDF格式)。 9.CSS3 Selector Test 非常不错的CSS3选择器测试工具 10.CSS3 Transforms 一款强大的CSS3旋转动画效果演示工具,即时生成代码。 11.CSS3 Preview CSS3特性介绍及效果预览。 12.CSS3 Generator 一款非常不错的CSS3代码生成工具。 13.CSS3 Color… Read More »

[zz]如何做好一份前端工程师的简历?

原文连接:http://dancewithnet.com/2009/02/17/how-to-make-a-resume-of-f2e/ 春节前在蓝色理想上发了个“雅虎口碑招聘前端工程师 ”的启事,节后收到很多简历,加之HR通过专业招聘网站得到的简历和朋友同事推荐的简历,数量上是相当的多,把这些简历一一看完真是一个漫长而幸苦的体力活,何况我还要仔细认真的去提取和核查有用信息评估其能力,尽量不错过任何一个埋藏在大量简历中合适的人,这绝大部分时间并不是一个相当愉悦的过程。所以,我感觉有必要来谈谈:如何做好一份前端工程师的简历。 一、你是前端工程师 虽然简历都会有一些常规信息,但职业决定了这份简历核心内容和求职成败。所以,这份简历应该尽可能体现你自己是一个合格的前端工程师。专业的前端工程师是什么可以看看去年Nate Koechley的演讲《Professional Frontend Engineering》,前端工程师应该关注的内容可以从克军总结的“前端工程师应该关注什么”的思维导图中窥出一二,学习内容聚合可以看看陈成总结的《前端开发大众手册(包括工具、网址、经验等)》。 毫无疑问,前端工程师应该知道如何用简历体现其专业技能和职业精神,这是每个应聘者应该考虑的问题。 二、内容为王 个人信息 姓名 (必需) 性别 (必需) 年龄 (必需) 联系电话 (必需) 学历及学位 (必需) 薪资期望 个人照片 邮箱 Blog 外语能力 职业技能 HTML、CSS、JavaScript/ActionScript等 Web标准、可用性、可访问性 一门非前端脚本的语言(Java、PHP、Python、C#等) 任何有利于前端开发的技能和兴趣 职业和教育经历 起始时间、单位名、职位(学位)和收获 简而精 按照时间倒序排列 代表作品 能体现自己现在前端技能或者重要经历的作品 简而精,且可以简要附上自己在这个作品中的收获 和别人合作的作品要注明自己具体完成的内容 在线链接要测试以保证可用,如果有其他人的变更应注明,较大变更就无需提交了 提供附件要注明与之对应的文件名 按完成时间倒序排列 依据实际情况,代表作品也完全可以直接融入到职业技能和经历中体现。当然内容不仅仅是这些,可以任意增加能体现前端工程师职业素质的信息。 三、Web是平台 毫无疑问,Web才是真正的平台,当这个平台的后端逐步被云所统治时(Amazon的很多服务和Google App Engine都初见端倪),那么云端的用户代理(比如浏览器)就是前端工程师的战场。前端工程师是可以长期从事且有前途的职业。 简历作为前端工程师迈向新征途而提交的第一份作品,应该毫不迟疑的用它来体现其专业技能和职业精神,所以Web页面是前端工程师简历的最好载体。它能体现前端工程师诸多专业素质: 知道为什么选择的DTD是下面中的一个而不是其他,这是对HTML标准的理解和思考 。 < !DOCTYPE HTML PUBLIC "-//W3C//DTD… Read More »

Dreamweaver 完整快捷键大全

菜单命令 文件(F) 新建(N)… Ctrl+N 打开(O) Ctrl+O 打开最近的文件(T) 启动时重新打开文档(R) 在框架中打开(F)… Ctrl+Shift+O 关闭(C) Ctrl+W 全部关闭(E) Ctrl+Shift+W 保存(S) Ctrl+S 另存为(A)… Ctrl+Shift+S 保存全部(L) 保存到远程服务器(O)… 另存为模板… 回复至上次的保存(R) 打印代码(P) Ctrl+P 导入(I) XML 到模板(X)… 表格式数据(T)… Word 文档(W)… Excel 文档(E)… 导出(E) 作为 XML 的数据模板(X)… CSS样式(C)… Read More »

高性能移动web开发

高性能移动web开发 移动终端面临的主要问题: 网络数据传输延迟(即便是3G网络) CPU运算能力(即便是配有1GHz+的设备) 移动终端可以做的优化: 根据设备屏幕来选择加载资源 降低延迟,加快连接速度 提高处理性能 本文介绍了一些针对移动设备优化技术,特别针对高级智能系统(iOS,Android,WebOS)。 原文:http://iloves.org/2011/05/high-performance-mobile/ 译自:High-Performance Mobile 原作者:David Calhoun 请尊重版权,转载请注明来源! 针对屏幕来优化图片 移动设备有不同屏幕尺寸,分辨率,应当有针对性加载不同的图片内容。 如果你正在开发一个只有一套带有很多图形样式的站点,那就意味着无论用户用何种大小设备都会下载这些巨大的图片。 为什么一定要让移动用户下载这些为桌面用户开发的样式图片呢? 不过不用担心,现代很多设备都支持 CSS media queries(媒体选择器)了, 通过media queries 我们可以方便的针对不同设备屏幕特性来加载不同版本的样式图片。 /* Screens bigger than 480px */ @media only screen and (min-device-width: 481px) { #header { background-image: url(header-full.png); } } /* Screens smaller than 480px */ @media only screen and… Read More »