js动画框架设计

题记: 当你不再依赖JQuery时,当你已经厌倦了引入js类库实现一些动画效果的方式,当你想实现一个简单而实用的动画框架……下面介 绍下愚人设计的动画框架:支持动画缓动算法函数,如Linear、Cubic、Back、Bounce,支持改变高度,宽度,透明度,边框,外边距的基本 动画,支持动画的回调函数,如开始、暂停、完成的callback等。     Section One   游戏动画,Flash动画里一个比较重要的概念是帧频,即每秒播放多少帧动画,一般动画是30帧/秒,单位为fps(frames per second)。   对于匀速运动来说:如果一个动画的持续时间duration为500ms,帧频frequence为30fps,则总帧数frames为(500/1000)*30 = 15,即该动画过程有15个“画面”,每走一帧,都计算出一个画面:画面当前位置 = 开始位置… Read More

PHP错误类型及屏蔽方法

程序只要在运行,就免不了会出现错误,错误很常见,比如Error,Notice,Warning等等。之前我们介绍过《易犯的PHP小错误及相应分析》《为开发者准备的10款错误报告和追踪工具》,这篇文章具体说一下PHP的错误类型和屏蔽方法。在PHP中,主要有以下3种错误类型。 1. 注意(Notices) 这些都是比较小而且不严重的错误,比如去访问一个未被定义的变量。通常,这类的错误是不提示给用户的,但有时这些错误会影响到运行的结果。 2. 警告(Warnings) 这就是稍微严重一些的错误了,比如想要包含include()一个本身不存在的文件。这样的错误信息会提示给用户,但不会导致程序终止运行。 3. 致命错误(Fatal errors) 这些就是严重的错误,比如你想要初始化一个根本不存在的类的对象,或调用一个不存在的函数,这些错误会导致程序停止运行,PHP也会把这些错误展现给用户。   不同的错误种类包括: E_ERROR:通常会显示出来,也会中断程序执行。 E_WARNING:通常都会显示出来,但不会中断程序的执行。 E_NOTICE:在脚本正常运行下发生的代码错误。 E_PARSE:语法解析错误。 E_CORE_ERROR:在PHP启动时发生的致命错误。… Read More

深入理解JavaScript系列:根本没有“JSON对象”这回事!

前言 写这篇文章的目的是经常看到开发人员说:把字符串转化为JSON对象,把JSON对象转化成字符串等类似的话题,所以把之前收藏的一篇老外的文章整理翻译了一下,供大家讨论,如有错误,请大家指出,多谢。 正文 本文的主题是基于ECMAScript262-3来写的,2011年的262-5新规范增加了JSON对象,和我们平时所说的JSON有关系,但是不是同一个东西,文章最后一节会讲到新增加的JSON对象。 英文原文:http://benalman.com/news/2010/03/theres-no-such-thing-as-a-json/ 我想给大家澄清一下一个非常普遍的误解,我认为很多JavaScript开发人员都错误地把JavaScript对象字面量(Object Literals)称为JSON对象(JSON Objects),因为他的语法和JSON规范里描述的一样,但是该规范里也明确地说了JSON只是一个数据交换语言,只有我们将之用在string上下文的时候它才叫JSON。 序列化与反序列化 2个程序(或服务器、语言等)需要交互通信的时候,他们倾向于使用string字符串因为string在很多语言里解析的方式都差不多。复杂的数据 结构经常需要用到,并且通过各种各样的中括号{},小括号(),叫括号<>和空格来组成,这个字符串仅仅是按照要求规范好的字符。 为此,我们为了描述这些复杂的数据结构作为一个string字符串,制定了标准的规则和语法。JSON只是其中一种语法,它可以在string上下文里描述对象,数组,字符串,数字,布尔型和null,然后通过程序间传输,并且反序列化成所需要的格式。YAML和XML(甚至request params)也是流行的数据交换格式,但是,我们喜欢JSON,谁叫我们是JavaScript开发人员呢! 字面量 引用Mozilla Developer Center里的几句话,供大家参考: 他们是固定的值,不是变量,让你从“字面上”理解脚本。… Read More

深入理解JavaScript系列:闭包(Closures)

介绍 本章我们将介绍在JavaScript里大家经常来讨论的话题 —— 闭包(closure)。闭包其实大家都已经谈烂了。尽管如此,这里还是要试着从理论角度来讨论下闭包,看看ECMAScript中的闭包内部究竟是如何工作的。 正如在前面的文章中提到的,这些文章都是系列文章,相互之间都是有关联的。因此,为了更好的理解本文要介绍的内容,建议先去阅读第14章作用域链和第12章变量对象。 英文原文:http://dmitrysoshnikov.com/ecmascript/chapter-6-closures/ 概论 在直接讨论ECMAScript闭包之前,还是有必要来看一下函数式编程中一些基本定义。 众所周知,在函数式语言中(ECMAScript也支持这种风格),函数即是数据。就比方说,函数可以赋值给变量,可以当参数传递给其他函数,还可以从函数里返回等等。这类函数有特殊的名字和结构。 定义 A functional argument (“Funarg”) — is an argument… Read More

WordPress:如何判断登录用户的角色

过去判断登录用户的角色我喜欢用current_user_can(),比如判断当前用户是否是作者用current_user_can(‘author’),记得WordPress官方文档中给的例子也是这样用,不过今天看了一下文档,貌似用法变了,传递角色作为参数不再可靠,正确的用法是传递$capability,那么该如何判断用户角色呢?   注:以下内容在WP 3.4+上测试通过 current_user_can()的正确用法 current_user_can()文档中有一句话要注意一下 Do not pass a role name to current_user_can(), as this is not… Read More

wordpress获取当前登录用户信息的方法

1). get_currentuserinfo(); 此函数将当前登录用户信息赋给全局变量$current_user以及一些单独的用户信息全局变量例如$display_name, $user_email等。 如下: <?php global $current_user, $display_name , $user_email; get_currentuserinfo(); //全局变量$current_user echo 'Username: ' . $current_user->user_login… Read More

WordPress页面、文章、分类等的条件判断的标签集合

is_home() //判断是否为首页. #The Front Page 首页头版消息设置 is_front_page() //判断是否为首页头版消息. (无论是日志或是页面).当系统显示博客主页且管理面板的设置>阅读菜单下 “主页显示为”选项设为最近发表的文章”,或者’设置>阅读菜单下”主页显示为”选项设为且”主页”是当前被显示的页面时,is_front_page() 标签返回TRUE。 #The Administration Panels 管理控制面板 is_admin() //判断是否为后台管理控制面板. #A… Read More

网站优化:浏览器缓存控制简介及配置策略

每次访问网页,通常浏览器会从服务器下载所 需的资源,例如 HTML 文档、图片、CSS、JavaScript,甚至包括字体文件等。这里面的许多文件(例如图片)都是很少变动的,如果每次都要从服务器重新下载,会不必要 地增加网页载入时间,同时也会对服务器造成一定压力。通过合理配置缓存策略,可令浏览器以某种方式把这些静态的文件缓存起来,下次请求同一资源时,直接使 用本地存储的副本,而不是从服务器重新下载。 启用缓存至少有两点显而易见的好处: 减少页面加载时间 减少服务器负载 浏览器是否使用缓存、缓存多久,是由服务器控制的。准确来说,当浏览器请求一个网页(或者其他资源)时,服务器发回的响应的「响应头」部分的某些字段指明了有关缓存的关键信息。 Cache-Control Cache-ControlHTTP 响应头是 HTTP 1.1 协议新增的指令,每个资源都可以通过设定 Cache-Control 来建立缓存策略。通常,可为它指定一个max-age,表示缓存的最长时间,单位为秒。例如,若设定Cache-Control:… Read More

关于大型网站技术演进的思考(一)–存储的瓶颈(1)

前不久公 司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训,两天12个小时信息量非常大,知识的广度和难度也非常大,培训完后我很难完整理出全部听 到的知识,今天我换了个思路是回味这次培训,这个思路就是通过本人目前的经验和技术水平来思考下大型网站技术演进的过程。 首先我们 要思考一个问题,什么样的网站才是大型网站,从网站的技术指标角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标,懂点行的人也许会 认为是网站在单位时间里的并发量的大小来作为指标,如果按这些标准那么像hao123这样的网站就是大型网站了,如下图所示: 其实这种网站访问量非常大,并发数也非常高,但是它却能用最为简单的web技术来实现:我们只要保持网站的充分的静态化,多部署几台服务器,那么就算地球上所有人都用它,网站也能正常运行。 我觉得大型网站是技术和业务的结合,一个满足某些用户需求的网站只要技术和业务二者有一方难度很大,必然会让企业投入更多的、更优秀的人力成本实现它,那么这样的网站就是所谓的大型网站了。 一个初建 的网站往往用户群都是很小的,最简单的网站架构就能解决实际的用户需求,当然为了保证网站的稳定性和安全性,我们会把网站的应用部署到至少两台机器上,后 台的存储使用数据库,如果经济实力允许,数据库使用单台服务器部署,由于数据是网站的生命线,因此我们常常会把部署数据库的服务器使用的好点,这个网站结 构如下所示: 这个结构 非常简单,其实大部分初建网站开发里往往业务逻辑没有企业级系统那么复杂,所以只要有个好的idea,建设一个新网站的成本是非常低的,所使用的技术手段 也是非常的基本和简单,不过该图我们要准备三台服务器,而且还要租个机房放置我们的服务器,这些成本对于草根和屌丝还是非常高的,幸运的是当下很多大公司 和机构提供了云平台,我们可以花费很少的钱将自己的应用部署到云平台上,这种做法我们甚至不用去考虑把应用、数据库分开部署的问题,更加进一步的降低了网 站开发和运维的成本,但是这种做法也有一个问题,就是网站的小命被这个云平台捏住了,如果云平台挂了,俺们的网站服务也就跟着挂了。 这里我先讲讲自己独立使用服务器部署网站的问题,如果我们要把网站服务应用使用多台服务器部署,这么做的目的一般有两个:… Read More

关于大型网站技术演进的思考(二)–存储的瓶颈(2)

上篇里我讲到某些网站在高并发下会报出503错误,503错误的含义是指网站服务端暂 时无法提供服务的含义,503还表达了网站服务端现在有问题但是以后可能会提供正常的服务,对http协议熟悉的人都知道,5开头的响应码表达了服务端出 现了问题,在我们开发测试时候最为常见的是500错误,500代表的含义是服务端程序出现了错误导致网站无法正常提供服务,500通常是服务端异常和错误 所致,如果生产系统里发现了500错误,那么只能说明网站存在逻辑性的错误,这往往是系统上线前的测试做的不到位所致。回到503错误,我上文解释为拒绝 访问,其实更加准确的回答应该是服务不可用,那么为什么我会说503错误在高并发的情况下90%的原因是数据库所致呢?上文我做出了详细的解释,但是今天 我回味了一下,发现那个解释还不是太突出重点,问题的重点是在高并发的情况整个网站系统首先暴露出问题的是数据库,如果我们把整个网站系统比作一个盛水的木桶,那么木桶最短的那个板就是数据库了,一般而言网站的服务应用出问题都会是解决存储问题之后才会出现。 数据库出现了瓶颈并不是程序存在逻辑性错误,数据库瓶颈的表现就是数据库因为承受了太多的访问后,数据库无法迅速的做出响应,严重时候数据库会拒绝进一 步操作死锁在哪里不能做出任何反应。数据库犹如一把巨型的大锁,很多人争抢这个锁时候会导致这个大锁完全被锁死,最终请求的处理就停留在这个大锁上最终导 致网站提示出503错误,503错误最终会传递到所有的客户端上,最终的现象就是全站不可用了。 上文里我讲到session共享的一个方案是将session数据存储在外部一个独立的缓存服务器里,我开始说用一台服务器做缓存服务器,后面提到如果 觉得一台服务器做缓存不安全,那么采用分布式缓存服务器例如memcached,那么这里就有一个问题了,为了保证web服务的可用性,我们会把web服 务分开部署到不同的服务器上,这些服务器都是对等关系,其中一台服务器不能正常提供服务不会影响到整个网站的稳定性,那么我们采取memcached集群 是不是可以达到同样的效果了?即缓存服务器集群中一台服务器挂掉,不会影响到用户对网站的使用了?问题的答案是令人失望了,假如我们使用两台服务器做缓存 服务器来存储session信息,那么如果其中一台服务器挂掉了,那么网站将会有一半的用户将不能正常使用网站,原因是他们的session信息丢失了, 网站无法正常的跟踪用户的会话状态。我之所以提到这个问题是想告诉大家以memcached为代表的分布式缓存和我们传统理解的分布式系统是有区别的,传 统的分布式系统都会包含一个容灾维护系统稳定性的功能,但实际的分布式技术是多种多样的,例如memcached的分布式技术并不是为了解决容灾维护系统 稳定性的模式设计,换个说法就是memcached集群的设计是没有过分考虑冗余的问题,而只有适当的冗余才能保证系统的健壮性问题。分布式技术的实现是 千差万别的,每个优秀的分布式系统都有自身独有的特点。… Read More

关于大型网站技术演进的思考(三)–存储的瓶颈(3)

存储的瓶颈写到现在就要进入到深水区了,如果我们所做的网站已经到了做数据库垂直拆分和水平拆分的阶段,那么此时我们所面临的技术难度的挑战也会大大增强。 这里我们先回顾下数据库的垂直拆分和水平拆分的定义:   垂直拆分:把一个数据库中不同业务单元的数据分到不同的数据库里。   水平拆分:是根据一定的规则把同一业务单元的数据拆分到多个数据库里。 垂直拆分 是一个粗粒度的拆分数据,它主要是将原来在一个数据库下的表拆分到不同的数据库里,水平拆分粒度比垂直拆分要更细点,它是将一张表拆到不同数据库里,粒度 的粗细也会导致实现技术的难度的也不一样,很明显水平拆分的技术难度要远大于垂直拆分的技术难度。难度意味着投入的成本的增加以及我们需要承担的风险的加 大,我们做系统开发一定要有个清晰的认识:能用简单的方案解决问题,就一定要毫不犹豫的舍弃复杂的方案,当系统需要使用高难度技术的时候,我们一定要让自己感受到这是迫不得已的。 我是以 java工程师应聘进了我现在的公司,所以在我转到专职前端前,我也做过不少java的应用开发,当时我在公司的前辈告诉我,我们公司的数据库建模很简 单,怎么个简单法了,数据库的表之间都没有外键,数据库不准写触发器,可以写写存储过程,但是存储过程决不能用于处理生产业务逻辑,而只能是一些辅助工 作,例如导入导出写数据啊,后面听说就算是数据库做到了读写分离,数据之间同步也最好是用java程序做,也不要使用存储过程,除非迫不得已。开始我还不 太理解这些做法,这种不理解不是指我质疑了公司的做法,而是我在想如果一个数据库我们就用了这么一点功能,那还不如让数据库公司为咋们定制个阉割版算了, 不过在我学习了hadoop之后我有点理解这个背后的深意了,其实作为存储数据的数据库,它和我们开发出的程序的本质是一样的那就是:存储和计算,那么当 数据库作为一个业务系统的存储介质时候,那么它的存储对业务系统的重要性要远远大于它所能承担的计算功能,当数据库作为互联网系统的存储介质时候,如果这 个互联网系统成长迅速,那么这个时候我们对数据库存储的要求就会越来越高,最后估计我们都想把数据库的计算特性给阉割掉,当然数据库基本的增删改查我们是 不能舍弃的,因为它们是数据库和外界沟通的入口,我们如果接触过具有海量数据的数据库,我们会发现让数据库运行的单个sql语句都会变得异常简洁和简单, 因为这个时候我们知道数据库已经在存储这块承担了太多的负担,那么我们能帮助数据库的手段只能是尽量降低它运算的压力。… Read More

关于大型网站技术演进的思考(四)–存储的瓶颈(4)

如果数据库需要进行水平拆分,这其实是一件很开心的事情,因为它代表公司的业务正在迅猛的增长,对于开发人员而言那就是有不尽的项目可以做,虽然会感觉很忙,但是人过的充实,心里也踏实。   数据库水平拆分简单说来就是先将原数据库里的一张表在做垂直拆分出来放置在单独的数据库和单独的表里后更进一步的把本来是一个整体的表进一步拆分成多张表,每一张表都用独立的数据库进行存储。 当表被水平拆分后,原数据表成为了一个逻辑的概念,而这个逻辑表的业务含义需要多张物理表协同完成,因此数据库的表被水平拆分后,那么我们对这张表的操作 已经超出了数据库本身提供给我们现有的手段,换句话说我们对表的操作会超出数据库本身所拥有的处理能力,这个时候我就需要设计相关的方案来弥补数据库缺失 的能力,这就是数据库水平拆分最大的技术难点所在。 数据库的 水平拆分是数据库垂直拆分的升级版,它和垂直拆分更像继承机制里的父子关系,因此水平拆分后,垂直拆分所遇到的join查询的问题以及分布式事务的问题任 然存在,由于表被物理拆解增加了逻辑表的维度,这也给垂直拆分里碰到的两个难题增加了更多的维度,因此水平拆分里join查询的问题和分布式事务会变得更 加复杂。水平拆分除了垂直拆分两个难题外,它还会产生新的技术难题,这些难题具体如下:   难题一:数据库的表被水平拆分后,该表的主键设计会变得十分困难;   难题二:原来单表的查询逻辑会面临挑战。 在准备本篇文章时候,我看到一些资料里还提到了一些难题,这些难题是:   难题三:水平拆分表后,外键的设计也会变得十分困难;   难题四:这个难题是针对数据的新增操作的,大致的意思是,我们到底按什么规则把需要存储的数据存储在拆分出的那个具体的物理数据表里。 难题三的 问题,我在上篇已经给出了解答,这里我进行一定的补充,其实外键问题在垂直拆分就已经存在,不过在讲垂直拆分时候我们没有讲到这个问题,这主要是我设定了 一个前提,就是数据表在最原始的数据建模阶段就要抛弃所有外键的设计,并将外键的逻辑抛给服务层去完成,我们要尽全力减轻数据库承担的运算压力,其实除了 减轻数据库运算压力外,我们还要将作为存储原子的表保持相对的独立性,互不关联,那么要做到这点最直接的办法就是去掉表与表之间关联的象征:外键,这样我… Read More