Posts List

大佬,您这是在借鉴嘛

今天闲来没事看到一篇文章,感觉质量挺好的,就想翻译一下。之前写过一个将文档导出成 markdown 的插件,因为这个插件一开始是为了翻译 Medium 文章开发的,但是后来因为 Medium 的 json 接口启用了,所以这个插件后面也不怎么维护了。不搜不知道,一搜吓一跳,居然发现一个和插件差不多的插件,不会吧,这么烂的插件也有人抄?后来仔细看了一看,这个大佬应该是在借鉴我的插件,辛苦地改了几个中文。 两款插件名名字几乎一模一样,只是这个借鉴者加了一个后缀:掘金翻译计划版。不确定和掘金有没有关系,我知道掘金是有一个翻译项目的,以前我也参与过。 对比 插件介绍 我的插件 李鬼插件 代码对比 上面的简洁基本上已经展现了浓重的李鬼味道,本着客观严谨的态度,我还是去看了一下代码。 我的插件 李鬼插件 除了一个 js 文件的引用,几乎可以说是一模一样了。核心的文件是 widget.js 这个文件,这个属于插件自身的 js 文件。 从这代码对比,可以看得出这个借鉴者巨大的工作量。 总结 鄙人的这款插件是在 GitHub 上开源的,当时也是出于个人需求搞得这么个小玩意,但是没想到居然还有李鬼借鉴,还真是离谱他妈给离谱开门。大家如果有空的话,还是动一下发财的小手点一下 Report,这个李鬼插件还是下架比较好。我也联系了这个开发同学,希望他能及时下架。

Pornhub Web 开发者访谈

原文:Interview with a Pornhub Web Developer 译者:neal1991 welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT 无论你对色情内容采取何种立场,都无法否认成人网站行业对推动互联网发展具有巨大影响。从将浏览器的视频限制推送到通过WebSocket推送广告,以便广告拦截器无法检测到它们,你必须足够聪明才能在互联网的前沿进行创新。 最近,我很有幸采访互联网最大的成人网站 Pornhub 的一名 Web 开发者。我想了解技术,Web API 如何改进以及在成人网站上工作的感受。请享用! 注意:成人产业竞争激烈,因此有一些他们无法回答的问题。我尊重他们保守商业机密的需要。 成人网站显然会显示许多图形内容。在开发过程中,你是否使用了大量的占位符图像和视频?最终产品和开发时的内容和经验有什么区别? 实际上,我们在开发网站时不使用占位符!其次,重要的是代码和功能,接口是我们现在非常习惯的东西。一开始肯定会有一些学习曲线,但是我们大家很快就习惯了。 对于网络流和第三方广告脚本,你如何在网站和功能开发过程中模拟这些重要的动态资源? 为了进行开发,播放器分为两个部分。基本播放器实现核心功能并触发事件。开发不会受其他因素干扰。为了在网站上进行集成,我们希望运行那些第三方脚本和广告,以便我们尽早发现问题。在特殊情况下,我们将与广告客户合作,允许我们手动触发通常可能是随机的事件。 平均每个页面可能至少包含一个视频,GIF 广告,一些 cam 表演者预览以及其他视频的缩略图。你如何测量页面性能以及如何使页面保持最佳性能?有什么你可已分享的技巧吗? 我们使用一些测量系统。 我们的播放器会向我们报告有关视频播放性能和一般用法的指标 用于一般站点性能的第三方 RUM 系统。 WebpageTest 私有实例,用于在可用的 AWS 数据中心中编写测试脚本。我们主要将其用于查看给定时间可能发生的情况。它还使我们能够查看来自不同位置和提供者的“瀑布”。 我必须假设前端最重要,最复杂的功能是视频播放器。从在视频之前加入广告,标记视频的精彩时刻,更改视频速度和其他功能,你如何维护该资产的性能,功能和稳定性? 我们有一支专门致力于视频播放器的团队,他们的首要任务是持续监控性能和效率。我们为此几乎使用了所有可用的东西;浏览器性能工具,网页测试,指标等。我们进行的所有更新均通过可靠的质量检查来确保稳定性和质量。 专门的视频团队有多少人?团队中有多少前端开发人员? 我要说的是,团队规模倾向于基于产品规模的平均水平。 在成人网站上工作期间,你如何看待前端未来的变化?哪些新的 Web API 使你的生活更轻松? 我肯定在前端世界的每个方面都看到了很多改进; 从纯 CSS 到最终使用 LESS 和 Mixins,再到使用具有媒体查询和图片标签的灵活 Grid 系统,以适应不同的分辨率和屏幕尺寸 jQuery 和 jQueryUI 慢慢地被淘汰,因此我们将回到 vanilla JS 中更高效的面向对象编程。在某些情况下,框架也非常有趣 我们喜欢新的 IntersectionObserver API,对于以更有效的方式加载图像非常有用 我们也开始使用画中画 API,以便在我们的某些页面上播放该浮动视频,主要是为了获得用户对该想法的反馈。 展望未来,有没有你想要更改,改进甚至创建的 Web API?

黑产代码解密--利用canvas加载代码

前段时间获取到黑产的一些代码,不得不感叹黑产的代码实在在写的是好得很,思路巧妙,环环相扣。不得不说,技术不好,黑产都做不了了。虽然分析了好多天,但是也只是一知半解。这里抽出一小部分来讲一下。二话不说,先上代码: 最初的代码是经过混淆的,代码经过整理如下: var createImgElement = function(urla, b) { var imgElement = document.createElement('img'); var canvasEle = document.createElement('canvas'); imgElement['crossOrigin'] = true; imgElement['onload'] = function() { canvasEle.width = this.width; canvasEle.height = this.height; var canvasContext = canvasEle.getContext('2d') canvasContext.drawImage(this, 0, 0, this.width, this.height); for (var canvasContext = canvasContext.getImageData(0, 0, this.width, this.height), cancasDataLength = canvasContext.data.length, arr = [], i = 0; i < cancasDataLength; i += 4) { var code = canvasContext.

Bootstrap真的总是好的吗

原文地址:Bootstrap considered harmful 原文作者:Hidde de Vries 译文出自:neal 译者: Neal 个人主页:http://neal1991.pythonanywhere.com 这些年Bootstrap已经在前端项目中流行起来,它能够带来很多好处。然而,但是如果以你们的团队已经有了在职的前端开发人员,我觉得最好还是不要用Bootstrap,在某些地方,弊大于利。 Bootstrap的好处是什么 Bootstrap主要是栅格系统,但同时也带来了很多组件的样式表和脚本,包括表格,导航栏,进度条,页码,表单样式,模式和提示文本。在这篇文章,我所说的Bootstrap是包含它的所有功能的。 Bootstrap是一个很好的工具对于一个纸箱装饰他们的程序但是无须担心结果的样式问题的后端开发人员。如果因为某些原因,预算或者什么的,你的团队没有前端开发人员或者设计人员,Bootstrap是一个绝佳的弥补方法。 对于设计人员来说,Bootstrap也是有用处的:它可以快速地从设计软件切换到浏览器中,不需要过多担心前端的代码设计。 即使是对于那些基本只专注于数据但是很少关注UI和布局的前端开发人员来说,Bootstrap也是一个绝佳的工具。 什么时候你最好别用它 然而,如果你的团队已经拥有了前端开发人员,使用Bootstrap可能会潜在的浪费他们宝贵的时间,并让他们可能从解决实际问题上转移注意力。Bootstrap做的正是前端开发人员所擅长的事情,但是用的是一种很通用的方式。你的网站或者网络app是非常特别的,因此如果你使用一个通用的系统可能会不太合适。这意味着为了实现这种特殊性将会包含很多的异常发生。 当需要很多异常来复位Bootstrap Bootstrap曾经是被Twitter 的开发人员用于系统化他们网络app的样式。如果你的网站app和他们的样式不一样,这意味着你需要解除他们中的某些样式。 很多网站和Twitter的样式并不相同。因此,如果他们装载了Bootstrap的时候,他们可能需要卸载很多地方。 在某些网站上,我看到有9/10的Bootstrap样式已经被网站自己的样式所替代。坦白说,这很荒谬。 当它让简单的事情变得复杂 CSS是给网站添加一套简单的样式规则,这有时候可能会被重写。当你在你的网站使用Bootstrap的样式的时候,几乎所有的元素都是用一个复杂的样式规则。任何异常都会在它之上表现。问题是大多数网站他们的样式异常都被表现在Bootstrap之上。 Bootstrap的样式是非常复杂的:你可以利用12列的栅格系统和任何元素相结合起来,对于需要特别处理的列则要区别对待。很多网站十分简单:它们在小屏幕设备上没有列或者只有一到两列在大一点的屏幕上。 当它产生技术债务的时候 前端依赖Bootstrap的时间越长,就会牵扯到更多的东西,更多的规则需要设置来覆盖Bootstrap的某些规则。这或多或少地让技术代码背负技术债务,尤其前端代码的部署需要手动的更新。随着依赖的增多,Bootstrap将变得更加难以移除。 当它命名一些不是你app的规定 命名是一件很困难的事情,为团队的应用中的规定命名需要花费相当多的时间。使用’btn’之类的缩写并不能很好的给组件命名。 结论 Bootstrap可能对于产生网站的多个流程都起到了很大的帮助。但是它并不能让所有的事情都变得简单:相反,很多问题可以由前端开发人元专注于UI就能够更好地解决。