分类目录归档:前端

JS-使用AOP思想实现统计函数时间

平时在做开发的时候,有的时候会看到介绍说这个方法没有那个方法效率性能高,那么到底怎么高呢,大多数只是猜猜或者看书上介绍的原理而已。但是我们如何做到定量统计某个函数或者方法的性能呢。

例如往页面中插入大量dom元素的时候,我们一般会用createElement然后再append,然后如果你查资料你会看到建议你使用createDocumentFragment, 因为这个是先见元素插入到内存你中,然后再一次性插入到dom中,避免了频繁重绘。按道理来说确实是这样,那我们怎么亲自见证一下呢。

所以有个方法就是统计函数的执行时间,例如

最后可以得到函数的输出的时间,但是这种方法有个缺点就是侵入性太大了,用起来也不是太方便。总不能每个函数都要这样吧。

所以来正题了,使用aop的思想,aop又叫切面函数 Aspect-oriented programming  从侧面函数侧面出发,不去侵入函数内部,来做一些相应的统计或者非核心逻辑的功能。 继续阅读

使用RSA和AES加密传输数据 js到php

感觉写这篇还挺是时候的,虽然本应该在上一篇之后就应该写这篇的。一直拖到现在,拖到了网易”被拖“。

上篇中说到使用aes加密,但是无论如何他还是很容易破解的,而且可以说无难度破解,首先如果想在传输过程中破解,就算你是传输的加密的数据,但是他只要同时劫持到你的js,看一下加密的方式,就可以反向破解出来,是没有任何难度,那么你加密不加密都是没有意义的。原因主要是因为aes本身采用的是对称加密方式,所以会产生上面的结果。所以我们使用rsa加密,但rsa加密过程计算量比较大,比较慢,可以用它来加密小量信息,所以我们可以用它来加密aes的key,然后在用aes加密,这样就算劫持到破解难度也增加到了破解rsa加密上去了,理论上还是很有难度的。如图:

rsa aes

rsa aes

继续阅读

使用AES加密传输数据 js到php

会写hello world 的都应该知道明文传输敏感信息是非常不好的一个习惯。这两天要做个东西,使用的是AES加密算法,但是遇到了一些坑。这里总结整理一下。

前端是用js,后台用php,分别使用的是:cryptoJsmcrypt

使用aes加密,所以考虑的加密解密一致性需要考虑的就有mode,和padding。 继续阅读

css网站变灰色调

当别人受到伤害的时候,我们所能做的就是冷静理智的去做自己力所能及的事情。

   今天临时接到通知,说天津爆炸,网站尽量保持灰黑色调,而且今天中午之前完成。so,本以为会很麻烦的事情,而且以前也没有做过在网上找了一下方案,发现并不是想象中的那么难。
其实只需要在外部html加上一个滤镜效果即可。

 

上面代码加了兼容的,亲测在ie789 chrome,ff可行,但是ie10不行不知道为什么。
现在仍然找不到原因。
最后一个利用svg的其实是用来兼容火狐的。
很简单的一个效果,然而”万能的PM”变成灰色之后导航不好看,要让颜色做一下更改。
好,我改。
就是把颜色改一下不就完,然而不支持的ie10,11怎么办呢?
我做过ie css hack 但是没有做过专门高版本的hack呀。
查了一下,\9 是专门ie10,9,8,7的hack方式,但是不支持11呀,最后再万能的爆栈上找到了一个方法:

ok,解决了。

ps: 当时说要做这个效果的时候我还在想,是不是要重新写一套css呀,像更换主题一样,更换css。当时另一个产品线的pm,说了句以前没做过滤镜,我当时看到这句都没反应过来,现在回想,PM真的是万能的。

如何成为一名卓越的前端工程师

本文全文引用勾三股四的翻译,感谢译者与作者。读后感想颇多,遂转载之,文末附有自己的一些感悟。原文链接

以下为原文:

译自 Philip Walton 的博客

看过之后非常有感触,很多观点都是自己长期非常坚持和认同的,所以翻译出来分享给更多的前端同学!


最近我收到一封读者来信让我陷入了思考,信是这么写的:

Hi Philip,您是否介意我问您是如何成为一名卓越 (great) 的前端工程师的?对此您有什么建议吗?

我不得不承认,我很惊讶被问这样的问题,因为我从来不觉得自己是个很卓越的前端工程师。甚至我入行头几年时并不认为自己可以做好这一行。我只确定自己比自己想象中还才疏学浅,而且大家面试我的时候都不知道从何问起

话虽这么说,我到现在做得还算不错,而且成为了团队中有价值的一员。但我最终离开 (去寻求新的挑战——即我还不能够胜任的工作) 的时候,我经常会被要求招聘我的继任者。现在回看这些面试,我不禁感叹当我刚开始的时候自己在这方面的知识是多么的匮乏。我现在或许不会按照我自己的模型进行招聘,即便我个人的这种经历也有可能成功。

我在 web 领域工作越长时间,我就越意识到区分人才和顶尖人才的并不是他们的知识——而是他们思考问题的方式。很显然,知识在很多情况下是非常重要而且关键的——但是在一个快速发展的领域,你前进和获取知识的方式 (至少在相当长的一段时间里) 会比你已经掌握的知识显得更加重要。更重要的是:你是如何运用这些知识解决每天的问题的。

这里有许许多多的文章谈论你工作中需要的语言、框架、工具等等。我希望给一些不一样的建议。在这篇文章里,我想谈一谈一个前端工程师的心态,希望可以帮助大家找到通往卓越的道路。

别光解决问题,想想究竟发生是什么

很多人埋头写 CSS 和 JavaScript 直到程序工作起来了,然后就去做别的事情了。我通过 code review 发现这种事经常发生。

我总会问大家:“为什么你会在这里添加 float: left?”或者“这里的 overflow: hidden 是必要的吗?”,他们往往答道:“我也不知道,可是我一删掉它们,页面就乱套了。”

JavaScript 也是一样,我总会在一个条件竞争的地方看到一个 setTimeout,或者有些人无意中阻止了事件传播,却不知道它会影响到页面中其它的事件处理。

我发现很多情况下,当你遇到问题的时候,你只是解决当下的问题罢了。但是如果你永远不花时间理解问题的本源,你将一次又一次的面对相同的问题。

花一些时间找出为什么,这看上去费时费力,但是我保证它会节省你未来的时间。在完全理解整个系统之后,你就不需要总去猜测和论证了。

学会预见未来的浏览器发展趋势

前后端开发的一个主要区别在于后端代码通常都运行在完全由你掌控的环境下。前端相对来说不那么在你的掌控之中。不同用户的平台或设备是前端永恒的话题,你的代码需要优雅掌控这一切。

我记得自己 2011 年之前曾经阅读某主流 JavaScript 框架的时候看到过下面这样的代码 (简化过的):

在这个例子中变量 IE6 为了判断 IE 浏览器版本是否是 6 或更低的版本。那么在 IE10 发布时,我们的程序判断还是会出问题。

我理解在真实世界特性检测并不 100% 工作,而且有的时候你不得不依赖有 bug 的特性或根据浏览器特性检测的错误设计白名单。但你为此做的每一件事都非常关键,因为你预见到了不再有 bug 的未来。

对于我们当中的很多人来说,我们今天写的代码都会比我们的工作周期要长。有些我写的代码已经过去 8 年多了还在产品线上运行。这让人很满足又很不安。

阅读规范文档

浏览器有 bug 是很难免的事,但是当同一份代码在两个浏览器渲染出来的效果不一样,人们总会不假思索的推测,那个“广受好评”的浏览器是对的,而“不起眼”的浏览器是错的。但事实并不一定如此,当你的假设出现错误时,你选取的变通办法都会在未来遭遇问题。

一个就近的例子是 flex 元素的默认最小尺寸问题。根据规范的描述,flex 元素初始化的 min-width 和 min-height 的值是 auto (而不是 0),也就是说它们默认应该收缩到自己内容的最小尺寸。但是在过去长达 8 个月的时间里,只有 Firefox 的实现是准确的。[1]

如果你遇到了这个浏览器兼容性的问题并且发现 Chrome、IE、Opera、Safari 的效果相同而 Firefox 和它们不同时,你很可能会认为是 Firefox 搞错了。事实上这种情况我见多了。很多我在自己 Flexbugs 项目上报的问题都是这样的。而且这些解决方案的问题会在两周之后 Chrome 44 修复之后被体现出来。和遵循标准的解决方案相比,这些方案都伤害到了正确的规范行为。[2]

当同一份代码在两个或更多浏览器的渲染结果不同时,你应该花些时间确定哪个效果是正确的,并且以此为标准写代码。你的解决方案应该是对未来友好的。

额外的,所谓“卓越”的前端工程师是时刻感受变化,在某项技术成为主流之前就去适应它的,甚至在为这样的技术做着贡献。如果你锻炼自己看到规范就能在浏览器支持它之前想象出它如何工作的,那么你将成为谈论并影响其规范开发的那群人。

阅读别人的代码

出于乐趣阅读别人的代码可能并不是你每周六晚上会想到的娱乐项目,但是这毫无疑问是你成为优秀工程师的最佳途径。

自己独立解决问题绝对是个不错的方式,但是这不应该是你唯一的方式,因为它很快就会让你稳定在某个层次。阅读别人的代码会让你开阔思维,并且阅读和理解别人写的代码也是团队协作或开源贡献必须具备的能力。

我着实认为很多公司在招聘新员工的时候犯的最大错误是他们只评估应聘者从轮廓开始写新代码的能力。我几乎没有见过一场面试会要求应聘者阅读现有的代码,找出其中的问题,并修复它们。缺少这样的面试流程真的非常不好,因为你作为工程师的很多时间都花费在了在现有的代码的基础上增加或改变上门,而不是搭建新的东西。

与比你聪明的人一起工作

我印象中的很多前端开发者 (相比于全职工作来说) 都是自由职业者,有同类想法的后端开发者并没有那么多。可能是因为很多前端都是自学成才的而后端则多是学校里学出来的。

不论是自我学习还是自我工作,我们都面对一个问题:你并没有机会从比你聪明的家伙那里学到什么。没有人帮你 review 代码,也没有人与你碰撞灵感。

我强烈建议,最起码在你职业发展的前期,你要在一个团队里工作,尤其是一个普遍比你聪明而且有经验的团队里工作。

如果你最终会在你职业发展的某个阶段选择独立工作,一定要让自己投身在开源社区当中。保持对开源项目的活跃贡献,这会给你团队工作相同甚至更多的益处。

“造轮子”

造轮子在商业上是非常糟糕的,但是从学习的角度是非常好的。你可能很想把那些库和小工具直接从 npm 里拿下来用,但也可以想象一下你独立建造它们能够学到多少东西。

我知道有些人读到这里是特别不赞成的。别误会,我并没有说你不应该使用第三方代码。那些经过充分测试的库具有多年的测试用例积累和已知问题积累,使用它们绝对是非常明智的选择。

但在这里我想说的是如何从优秀到卓越。我觉得这个领域很多卓越的人都是我每天在用的非常流行的库的作者或维护者。

你可能不曾打造过自己的 JavaScript 库也拥有一个成功的职业发展,但是你从不把自己手弄脏是几乎不可能淘到金子的。

在这一行大家普遍会问的一个问题是:我接下来应该做点什么?如果你没有试着学一个新的工具创建一个新的应用,那不妨试着重新造一个你喜欢的 JavaScript 库或 CSS 框架。这样做的一个好消息是,在你遇到困难的时候,所有现成的库的源代码都会为你提供帮助。

把你学到的东西都记录下来

最后,但丝毫不逊色的是,你应该把你学到的东西记录下来。这样做有很多原因,但也许最重要的原因是它强迫你更好的理解这件事。如果你无法讲清楚它的工作原理,在整个过程中它会推动你自己把并不真正理解的东西弄清楚。很多情况下你根本意识不到自己还不理解它们——直到自己动手写的时候。

根据我的经验,写作、演讲、做 demo 是强迫自己完全深入理解一件事的最佳方式。就算你写的东西没有人看,整个过程也会让你受益匪浅。

Footnotes:

  1. Firefox implemented the spec change in version 34 on December 1, 2014. Chrome implemented it in version 44 on July 21, 2015, which means Opera will get it shortly. Edge shipped with this implemented on July 29, 2015. A Safari implementation appears to be in progress.
  2. You can refer to Flexbug #1 for a future-friendly, cross-browser workaround to this issue.

以下为个人感想:

别光解决问题,想想究竟发生是什么 。知其然更要知其所以然,虽然你需要花费更多的时间去知其所以然,但是对于你接下来的工作或者项目甚至个人发展都是节约了几倍的时间的。而且对于项目本身或者一些未知的bug,你会更快的时间去修复。

阅读规范文档。 这句话深有体会,遇到问题,你在网上去搜,去问别人,但是那些答案,或者别人给你的答案也只能是从官方文档上延伸来的,如果你的理解能力还算正常,那么就去自己读文档去吧。

阅读别人的代码。这个对于我来说应该是最需要做的,因为本身前端大都是自己学的,没有系统的指导,然后实习也是半导师状态,从没有人review过我的代码,所以真的很想有人看一下我的代码呀,因为很难找到自己的代码中的不足。当然在没人给你review的情况下,你就要多看别人的优秀代码,去学习他们的思考方式。

与比你聪明的人一起工作。影响你的思维习惯。

“造轮子”。对基础知识有深层次的了解,造轮子并不一定是拿来用,可能让你对知识体系以及一些思想上有了更深一层的认识,是对能力的一种提高和检验。

 

 

豆瓣面试(二)

    在学校约的是7号的面试,还没有面对面面试过,还有点小激动,约的下午两点半,查了地铁也就1个多小时,提前两个多小时去坐车,想着还可以有一个小时简单准备一下,如果说一面还在学校可以说准备了一天,而这个几乎一个小时都没有准备,在学校一直复习,几乎一个月没写代码了,所以心里还是挺没底的,所以唯一准备的希望就放在了地铁上还提前去的这一个小时,然而一向找不到方向的我,这次也不例外,下车后,照着地图沿反方向走了一大圈,转了一个多小时,最后实在要迟到了,打了个的过去的。然而过去发现,距离地铁五分钟都不到,我竟然找了几乎一个多小时,当时真的好佩服我自己。找到豆瓣之后就已经两点二十多了。然后找前台妹子说明情况,前台妹子把我带到了一个小的会议室,倒了杯水,说一会有人过来,然后我等的过程中,看了一下豆瓣的员工,竟然如此多的妹子。

现在是晚上21:42马上要下班了,所以闲话少说,进入正题吧。

既非意料之中,也不是意料之外—豆瓣面试

前言:

上周四无聊逛v2ex的时候看到一篇帖子,一个豆瓣招聘的,发现是招前端的,其实和我关系并不是太大,虽然比较想去豆瓣,但是因为现在还在百度那边估计也要九月才可以结束(虽然拿到百度的offer应该是可以的),但是看到下面回复里面,竟然招九月的实习生,就心动了,因为最近老是学不下去,而且也在想大学四年不能就只面一个百度然后留在那里了,也太无味了,应该多经历一些,起码应该多经历一些失败,所以就以一个必败的心态去投了简历(还是当初投百度的那份简历),周四投完之后,当天晚上还看了几遍邮件,没有回复有点失望。就碎啦。

第二天上完课后,突然收到一个北京的座机电话,第一反应是百度那边有事找我,第二可能是广告或者是自如租房那里。很有礼貌的接了之后,对方说是豆瓣,心里还有那么一点开心。一个声音还挺好听的妹子,然后就大体说了一下约了面试时间为下周一下午,挂掉电话之后,我竟然感觉妹子有点紧张 -:D,

然而挂掉电话之后,才意识到,我下周一晚上还有一门没有复习的考试(我可是一学期都没有上过这门还比较难的课),而且好像还没有说明我现在没有在北京,所以下午两点打过去电话,告诉对方没在北京可以电面吗? 对方很亲切的答应了下周一下午两点半电话面试。然后晚上回宿舍之后知道,考试时间是周一下午四点(当时心情有点糟糕),问题总是要解决的,就想着周一上午十一点给对方说明情况,协调到周二。周一上午在自习室给对方打了电话,把时间总算是确定好了。然而我并没有准备面试的知识,毕竟我只面过一次,还是去年11月左右。所以完全是抱着找虐的新去的,最近比较懒散学不下去,想着能够打击一下自己。所以我早就想好这篇总结的名字了,如果没过就是“意料之中的失败”,过了就真的是”意料之外的收获“,然而为什么会是现在的标题下面会有原因的。

接下来考完试之后准备去大活看一下面试的东西,可是各种原因,在没人生日的情况下去西苑吃了一个蓝色的海绵宝宝的蛋糕,准备面试的时间就这样没啦,这样看来自己真的应该是被打击打击啦。就算是去被打击去的也要经全力去准备呀,最后也就在周二上午三四节课准备了一下下。

面试过程:

约的两点半,等到三点才打了过来(如果是以前我一定会感觉对方不守时,但在百度工作这段时间发现真的不是这样的,对方可能会很忙很多事情,确实会抽不开身的)。

接了电话,对方介绍了一下自己,说是负责豆瓣用户产品的前端开发,就是我们所看到的豆瓣的前端。听起来很厉害的样子。

     进入正题,问的大体东西,只记得了一部分了。

先让我介绍了一下两次实习的所做的工作,就大体讲了一下两次实习的所作的工作,然后问了一下工作中的东西,cordova 问了一下cordova用了哪些插件以及插件实现机制大体描述了一下。然后问了一下promise,大体讲了一下,然后又问了为什么是promise/A+, 这个真的没有答出来,当时看过,没有放心上。

后来又问了一下个人项目Share就大体讲了一下,只讲的产品,没有讲技术上的东西,这个自己回答还算满意, 因为每次给别人将这个都会很开心,虽然很少给其他人讲过全部思想。

接下来就问了一些非简历上面的东西了,例如:

     平时开发所用到的库,这个真的没有用过很高端的,就回到了jq和underscore。
     问:开发所用的工具和环境
     答: 工作中和工作环境保持一致,平时开发ubuntu + vim
     看我简历有webapp开发经验,就问了一下我webapp开发所需要注意的地方
     这个问题完全是自己随口答的,自己并不是太满意。当时回答是:
     首先最重要的是要考虑性能优化,兼容问题(不同系统的不同版本的不同浏览器),以及尽可能发挥其移动浏览器的优势,一些比较有用的特性。
     问:是否使用预编译js
     这个没有听清楚,当时也不是太懂这个概念,问了一下是不是ejs,jade之类的,他说是例如coffee之类的,然后我就明白了,说用coffe,比较喜欢coffee的那种书写方式。
     问:是否使用css预编译例如sass,less
     答: 使用sass
     问:平时是否用打包工具
     答: 使用grunt
     这个的回答自己并不是太满意,因为只是用过,但其实自己并没有去研究过打包工具原理和使用细节,这几天补一下。
     问:用过哪些h5的特效
     答:pushstate, localstorage,readFile, canvas,image, 最后又想起来一个websocket(这个就用过一次)。
     最后一个干货问题,
     设计一个弹窗组件需要传入哪些参数
     答:

唤起整个组件的元素,高宽,是否模态,关闭按钮。但是就回答了这些,然后对方说,就这些吗? 然后就不是太确定了,后来说弹窗里面还有个最重要的就是内容,但是就,,,,提醒之后我立马知道了,然后又问内容怎么传进来,我说如果有数据就将html写死,然后传进来json数据,如果没有,直接传进来一个大的html,对方说其实还可以穿iframe,是啊,以前明明用过类似的传iframe的组件的。后来又说下面会用确认等按钮,如何去绑定用户自定义事件,回答的是事件监听,又问了如果传进来按钮个数不确定怎么办,回答是,将按钮已数组的形式传进来,然后遍历数组进行事件绑定,又问,这样如果绑定对方的自定义事件,其实我想说的是我到现在都没有太懂怎么写自定义事件,但还是糊涂的答了一句,循环监听按钮然后再回调里面绑定自定义的时间(都没有办法说服自己),最后让我可以自己试一下下去。

然后大体就这么多了,问我有没有什么问题,我就问了一下对我的建议,大体说了一些就是说对应届生更重要的是学习能力和基础,然后说我知识面还是挺广但是可能有的需要深入,基础也算可以。(其实我想说的是,自己的定位就是知识面可以广,但是一定有一个(前端)专一的,但确实不是太深对知识的了解)。然后又问了一下关于造轮子(前面问我的时候还问了一下是否自己造过轮子,就把当时的jk那个轮子说了一下)。最后说没有了,对方说,就不想知道一些关于豆瓣这边的事情,然后就问了一下豆瓣那边前端的组织,前端开发用的东西,后来又问了一个FM页面上,为什么会用多个内嵌script,当时他打开看了一下,说着可能是工程上的问题,他并不建议这么写的。然后大体就结束了,说给同事反馈一下我情况给我联系,最后很有礼貌的再见了。

整体来说对自己的表现不满意,很不满意,但是感觉面试官好像还算满意。

很喜欢这样的面试官,包括问的问题,方式和交流时候的感觉都让人很轻松和让你很喜欢和这样的人一起工作。
结果:
过了,二面要去北京

大约一个多小时之后,HR打过来电话告诉我,想约去北京接着面,问我什么时候回北京,这完全是没在意料之中,这也是题目会这么写,最后就定了一个时间7.7号去北京面,其实自己挺不好意思的,一面和二面要隔这么久。而且心里也挺没哟底的,没有当面面过的,不过本来不就是想着多去经历一下吗这次,多一份成长。虽然没有被打击,但是还是应该多去深入学点东西了。

接下来就是要继续准备考试,准备回北京。

web动画–requestAnimationFrame

在很久很久以前我们页面动画是这个样子的

 

但是这样做有几个问题,就是

  • setTimeout效率并不是那么高
  • 大多数浏览器的是已16ms为一帧,但是如果你设置不对,就会出现跳帧现象

于是乎作为现代人的我们,有了新的解决方法就是利用 requestAnimationFrame

直接上代码:

 

针对不同浏览器做了兼容,可以说从IE6开始支持,那么requestAnimationFrame有什么好处呢,

  • 根据不同浏览器提供的帧去运动
  • setTimeout本身机制并没有requestAnimationFrame效率高(具体原因待考察)
  • 运行会更流畅,由其本身决定
  • 相对css3来说,绘制更高级,css3有很多效果达不到
  • 当当前页面不显示是,动画停止,节省cpu和电池热量

上面demo针对不同浏览器做了兼容,同时也写了取消事件。其实主要就这两个属性,很容易掌握。

ps: 其实开始研究的时候有个疑惑的地方,requestAnimationFrame 他没有时间这个参数,如果想要达到越来越快的效果怎么办。其实很简单,换个角度,以运动距离为参考,不断加大运动间距就ok啦。

参考:

MDN文档 

CSS3动画那么强,requestAnimationFrame还有毛线用?

最近好懒

一直要总结一些东西,总是没有去整理总结,把这一段时间做的东西整理列出来,需要过段时间,一点点整理。

  1. canvas画图    主要技术事件监听、碰撞检测、边缘检测 演示地址                                                     (PS:除了效果和ys大神的一样,其他的每一个代码都是自己思路写的,一直想去对比,最近太懒啦 o(╯□╰)o);
  2. chrome显示豆瓣歌词插件 源码
  3. shareMe(hoho)     主要技术  angular + Express + mysql (路由及层次逻辑)  、socket  demo
  4. jsonp跨域、js事件机制
  5. promise规范、requireJs、hybrid开发,angularJs总结

大公司里怎样开发和部署前端代码?

这是一篇来自知乎@张云龙前百度工程师,曾负责百度 前端集成解决方案 的核心设计与开发工作的回答,原文请见大公司里怎样开发和部署前端代码?  和他私聊了一会感觉很热心的回答了我很多小白问题,而且答案真的很有帮助,是他所说的“细思极恐”。

下面是原文:

我现在称这个领域为【前端工程】。没错,这是我最爱唠叨的问题域。
这是一个非常有趣的 非主流前端领域,这个领域要探索的是如何用工程手段解决前端开发和部署优化的综合问题,入行到现在一直在学习和实践中。 继续阅读