Quantcast
Channel: CNode:Node.js专业中文社区
Viewing all 14821 articles
Browse latest View live

node 获取音频buffer 的播放时长

$
0
0

如何用node 获取音频buffer 的播放时长? node能创建 new Audio()对象码? 听说可以ffmpeg获取?


nsp依赖库检查工具: nodejs的依赖库的依赖库有问题怎么办

$
0
0

做了一个项目有nsp工具检查了一下依赖库的安全性。 这是其中一个结果: ┌────────────┬────────────────────────────────────────────────────────────────────┐ │ │ Regular Expression Denial of Service │ ├────────────┼────────────────────────────────────────────────────────────────────┤ │ Name │ minimatch │ ├────────────┼────────────────────────────────────────────────────────────────────┤ │ CVSS │ 7.5 (High) │ ├────────────┼────────────────────────────────────────────────────────────────────┤ │ Installed │ 2.0.10 │ ├────────────┼────────────────────────────────────────────────────────────────────┤ │ Vulnerable │ <=3.0.1 │ ├────────────┼────────────────────────────────────────────────────────────────────┤ │ Patched │ >=3.0.2 │ ├────────────┼────────────────────────────────────────────────────────────────────┤ │ Path │ kails@0.1.0 > gulp@3.9.1 > vinyl-fs@0.3.14 > glob-stream@3.1.18 > │ │ │ minimatch@2.0.10 │ ├────────────┼────────────────────────────────────────────────────────────────────┤ │ More Info │ https://nodesecurity.io/advisories/118│ └────────────┴────────────────────────────────────────────────────────────────────┘

minimatch@2.0.10 版本有问题,但是它是 gulp@3.9.1(最新)的依赖库的依赖的依赖。完全没法改呀,请问什么好的建议可以解决这个问题。

大家好 问个数据类型转换的问题

$
0
0

我JS基础不好 刚才出现了个问题不明白是咋回事

1.png这里我往客户端发的时候 userList 还是个数组

2.png console.log也出来了 是个数组

3.png然后这里接收的时候 这里就变成obj了

4.png为什么会变成obj?

React + redux最新开源项目推荐下

$
0
0

最近在学React, 没找到比较完善的React/redux实战项目, 哪位好人有相关的项目分享来学习下, 感谢!!!

Immutable.js 用过吗,真的很好?

$
0
0

Immutable.js

使用不可变数据类型的头一条理由肯定是能够保证做项目的人不能违反不可变原则。 严格地说,Immutable.js 库有助于简化开发过程,因为大家不再需要在代码中追踪数据,寻找数据变更的位置。不可变数据类型取而代之,能始终精确表现当前存储对象(store)中存储的程序状态。

有了这种库,就能发挥上述不可变数据类型的优点,但缺点也确实存在

不便与调试

如果要查看数据直接使用 console.log 需要翻来覆去的深层次的找,如果使用 toJS() 它自带的转换则一定层度上减缓开发速度。 javascript 语法错误就不存在了,若 a.b.w.d ‘w’ 对象名称写错了,现在得到的只会是一个 undefined 而真正的问题无法得知。

不便与迁移

1.toJS() 可以把Immutable对象转换成普通对象,不难免的会在代码中用到(例如与服务器交互),但如果该对象较为深,则性能消耗的代价也是巨大的,PC 端这一点可以忽略,但移动端则需要考虑,包括 fromJS

不符合主流ES6原生代码的格式

比如 ES6 的解构,就变成了只能使用 get() 或 getIn(),若 props 携带有一定数量,则会带来更多的冗长代码,ES6 的 … 扩展语法也是

压缩后的 Immutable.js 大约 57kb

配合redux的话,中间必用来做转换的 redux-Immutable 引入了整个 Immutablejs 库 无法做 Tree shaking 代码缩减优化

侵入性强

例如引用第三方组件的时候,不得不进行数据转换

入手不易

需要对 Immutable.js 一套 api 进行熟悉才可上手

这是我总结的一些缺点,最终发现 缺点大过了缺点,最后想问一个问题,现在移动端项目盛行,若对于移动端项目而言,Immutable.js 是否真的合适?如果只是为了 不可变约束,immutability-helper 这类更加更加贴近原生的库是不是要更合适一些

NODE和板卡通信

$
0
0

毕设,做一个和物理板卡通信的平台。板卡不支持传输json,只能通过socket传输二进制,定义好了一套通信协议。 经验不足,不知道有NODE生态里有没基于net模块的框架,类似于HTTP的express。可以提供一些粘包分包处理,编解码,事件分发这些功能的框架

[北京] 产品咨询公司 招募node.js freelancer

$
0
0

freelancer的小伙伴们看这里我们是一家产品咨询公司,一体化的做出相应的解决方案。目前启动的项目正在寻找freelancer的小伙伴们~~以下有几个人物画像,首次发帖如有不妥请大家指正(国内的freelancer环境并不好,希望大家可以正式freelancer的工作性质,当然自己也要技能上自己厉害起来,好好沉淀) 所有的小伙伴均需要可以独立负责项目开发,因为这次启动项目的特殊性,所以要求可以客座北京办公室1-2次/周,项目周期在6-7周左右

【1】熟悉 node.js & express开发,每周可以到北京的办公室1-2次,其他时间可远程~~项目周期预计时间6-7周 【2】熟悉 python&flask,可以独立负责项目,有丰富的项目开发经验,每周可以到北京的办公室1-2次,项目周期预计时间6-7周 【3】iOS/android开发工程师 各1名,可以独立负责项目,有丰富的项目开发经验,对上架审核协议熟悉。可以每周到北京办公室1-2次的小伙伴,项目周期预计时间6-7周

报酬的部分:以上描述的项目需求人员,人均报酬大概3万左右(会正式的签署项目协议、保密协议,项目的打款进度安排一般分为2次:中期1次,50%,收尾1次,50%) 如果以上有符合的小伙伴 可以加我的微信:shuiwuyou722或直接将您的简历发送至我的邮箱349907143@qq.com 关于回复:因为工作的关系,我会在每天的9点到10点,下午13:30至14:00,晚上的19:00至20:30给大家回复 关于项目的介绍等信息,如果您符合以上基本情况,可以私聊。

测试话题,你看看


玉伯《从前端技术到体验科技(附演讲视频)》

$
0
0

很抱歉在首届蚂蚁体验科技 SEE Conf 大会上,给大家讲得有点磕绊不太清楚。今天写下来行诸文字,希望一些思考能与大家进一步交流。(设计师朋友可以跳过前端技术部分,直接看后面章节)

什么是前端技术

第一次接触前端开发是 2002 年大学期间,转眼 15 年多。这些年一直在思考一个问题:究竟什么是前端技术?很长很长一段时间,前端技术的定义非常清晰,就是浏览器端的 HTML、CSS、JS 技术。我们用这些技术做出各种各样的页面,我们是离用户最近的程序员。

v2-356e4bb976792ec0c2ae166405e4b502_hd.jpg

记得 2009 年开始接触 Node,很快前端技术开始爆炸性增长。最开始的变化,是前端压缩工具从基于 Java 的 YUI Compressor 开始切换到基于 Node 实现的 UglifyJS 等工具。除了前端工具上的一路狂奔,在服务端领域也出现了 Express 等框架,前端开始通过 Node 完成服务端模板甚至整个 MVC 层的开发。在蚂蚁金服,服务端层我们更多把 Node 定位为 BFF 层实现,BFF 是 Backend For Frontend 的缩写,翻译成用户体验适配层。

BFF 模式下,整体分工很清晰,后端通过 Java 等语言负责服务实现,理想情况下给前端提供的是基于领域模型的 RPC 接口,前端则在 BFF 层直接调用服务端 RPC 接口拿到数据,按需加工消费数据,并实现人机交互。基于 BFF 模式的研发,很适合拥有前端技术背景的全栈型工程师。这种模式的好处很明显,后端可以专注于业务领域,更多从领域模型的视角去思考问题,页面视角的数据则交给前端型全栈工程师去搞定。领域模型与页面数据是两种思维模式,通过 BFF 可以很好地解耦开,让彼此更专业高效。

除了服务端的渗透,从 2013 年开始,阿里开始无线 ALL IN 战略,这对前端影响非常大。有相当多的前端开始转型为 iOS 工程师(转型为 Android 的比较少,有部分 Java 工程师转型成了 Android 开发),没有转型的,也开始大量投入到 Mobile Web 开发。这个大背景下,前端与客户端技术开始互相融合,特别是在容器层。从 2015 年开始,物联网 IoT 逐步兴起,前端开始涉足 IoT 设备上的应用研发。端的本质是 devices,台式机、手机、IoT 设备都是一台台 devices,很多会直接被用户使用,有用户使用的 devices,就会有人机交互需求,就会有前端的工作价值。前端是离用户最近的工程师,这个定位一直没变。

非常有意思的是,在移动端的架构里,这几年也出现了基于 RPC 接口 + 网关 + BFF 的架构体系,在研发效率、网络性能等方面均有优势。随着 IoT 应用的涌现与复杂化,我相信最终也会出现 BFF 架构。BFF 模式不仅仅是一种技术架构,从社会分工角度讲,BFF 更是一种多元价值导向的分层架构,每一层都有不错的空间去施展,不仅能发挥工业社会双手的作用,还能使用上双手上面的脑袋。齿轮不再是被动跟着转,而是开始拥有自驱的转动力。同一时期,业界也出现了一些类似的职业融合。比如 DevOps 倡导开发也懂运维,不少大公司在推行开发也懂测试,测试则转型为更专业的质量工具部门,还有前端也懂设计的 DesignOps 的出现等等。各种全栈概念的涌现,都是在重新探索更合理的分层协作模式。纷纷扰扰,成败如风。

补充一个说明,当年提出的前后端分离,并不准确,这些年一直努力纠正为前后端分层的理念。专业的分工协同对效能的提升很关键。全栈的含义是指分层演化后,每一层的技术栈要求,是每一层横向技能的全,而不是纵向跨层的通(纵向跨多层都能通的人才非常少,就如当今社会已经非常难诞生博物学家了)。不断探索更好的分层协作是有意思的,这就如人类家庭里夫妻的关系一样,男权、女权都不可取,社会的演化最终会视人为人,每个个体平等、自由,社会会以一种必然的不可阻挡的形态往前演进。

回到前端发展历史,前面说了这么多,只说了一件事,前后端分层协作的各种模式。协作的边界是数据,后端提供数据服务接口,前端消费数据实现人机交互。不同模式下,BaaS(Backend as a Service)的含义各有不同。在 BFF 模式下,由于 BFF 层的运维部署需要,前端还需负责 BFF 层的 PaaS 平台建设。不同模式下的工程体系各有不同,工程的本质是让一群人做好一堆事,涉及代码规范、协作流程、运维部署、性能与安全等很多领域,这里不再一一展开。

服务端 Node 与各种终端的涌现,让前端进入了大前端范畴,这时候的前端,已远远不只是浏览器端的页面实现技术,而是后端服务与人机界面的连接器。

v2-374230208f31483237155e80d46f1c0d_hd.jpg

什么是体验科技

我属于无线 ALL IN 战略中,选择留下来继续做 PC Web 的前端。虽然公司重点转向无线,但 PC 业务一直没停。随着近几年整个阿里集团“大中台、小前台”的策略,越来越多的企业级中后台产品处于兵荒马乱阶段,设计师非常缺失,随手一抓,都是大量体验比较糟心的产品。这过程中,越来越感觉什么地方有问题,一定在某些点上我们没做好。当时没多想,就想着既然缺设计师,我们就尝试去招聘。于是体验技术部开始拥有了设计师,非常艰辛的起步,非常感激的是,虽然艰辛,但找到了一些与我一样坚信中后台产品价值的设计师。一旦有了设计师,整个中后台产品的用户体验,一下子就提升上来了。

v2-54abf60cd133916e016343ae4adaf376_hd.jpg

设计团队的融入,日常的各种碰撞交流,让我的思维发生了很大变化。前端技术再牛,都很难直接解决产品层的用户体验。对中后台产品来说,设计的价值也远远不止于让产品的颜值提升,设计的更多更多价值,在于深入到产品的业务逻辑里去,去帮助业务梳理产品信息架构与任务流程。用户体验是一个非常综合的事,需要各种专业人士在同一个产品上聚焦发力,一起共同努力才能真正提升产品体验。设计师在这个过程中很痛苦,很多中后台产品都是非常垂直领域的业务产品,中间件、ECS、ODPS 等一堆堆专业术语让设计师们痛苦不堪,幸运的是,我们扛了过来。

v2-9b693a1affab86f96e24e0bee03b3e90_hd.jpg

接下来的故事,在今天各个讲师的分享里,不少都有提及。整个团队的重心,开始非常清晰地往几个方向发展:

  • TWA 方向:这是比 BFF 更大的概念,上午不四的分享里有详细阐述,可参考 知乎专栏文章 。TWA 是 Techless Web App 的缩写,是一种技术理念,希望越来越多的开发者,可以不用再关注流程、构建、环境、部署等各种事,希望能做到技术无感化(Techless),让每一位开发着能安安静静的快乐编码。
  • UI 智能化方向:Ant Design 是一个设计体系,antd 是 Ant Design 的 React 实现。这几年 antd 的发展,不仅让前端编码更快更爽了,同时让一个历史悠久但生生不息的领域重燃希望:是否存在人机交互界面智能可视化搭建的可能?这个领域,这一两年在阿里内部非常火,各种搭建产品层出不穷,目前都还处于比较垂直的领域,泛化到行业级通用的产品还没怎么出现。我们也开始尝试,而且我们相信天时地利人和,一定能折腾出点什么,正在努力中,或许在下次 SEE Conf 大会中会展示给大家。
  • 数据可视化方向:下午绝云和御术的分享,相信大家对 G2 和 AntV 已经有了一个整体了解。可视化方向我们是从 2014 年开始正式投入人员去做,最开始的想法来自科幻片,大家如果喜欢看科幻片的话,会留意到各种人机交互界面都是各种可视化效果了,很少很少有传统网页。可视化是个历史非常悠久的领域,我们小学时学会的乘法竖式,就是一种可视化,可以帮助我们减少记忆成本,同时提升计算速度。
  • 图形互动化方向: 上午好修和景夫有分享,这一块才开始一年多,是我们非常笃定的一个方向。很多小孩,对书本都比较抗拒,但对游戏有着天生的喜爱。蚂蚁森林让大家从表单形式的公益,变成了互动游戏型的公益。越来越多的人机交互形式,会是有互动交互的图形界面。应用的泛互动化,是一个很大趋势。支付宝是个生活服务平台,各种生活服务的互动有趣化,一定是更有吸引力的。

v2-6830ebf2ca603dca8bd33723d73220e3_hd.jpg

看更远的未来,我相信对体验科技来说,自然化和虚拟化会是两个大趋势。

我现在在分享这个 PPT,要翻页时,需要点击键盘按钮,为什么电脑不能直接理解我的意图而自动翻页呢?比如我只要头往下示意一下,就能自然而然翻到下一页。我们现在很多行为,跳脱出来看,能发现很多很多不自然。天猫精灵等各种智能音箱,真正去用时,离自然交互还有比较远的距离。Ant Design 设计价值观里,最最重要的就是自然价值观,一切才刚刚开始探索。

再说虚拟化。虚拟化不仅仅指 AR、VR 等技术,看过黑客帝国、西部世界等科幻片的,会对虚拟化有更多体感。如果以后每个小孩出生时,就会被植入一个能五感俱全的芯片,这种情况下,我们的人机交互会是怎么样的。太多可能性与挑战在等着我们。

这一切都是体验科技,是技术与设计的融合,是服务与用户连接,是下图中的一个公式。

v2-773def061a6dd38cd97c52f040da29cc_hd.jpg

v2-e4186cd37a1f978abbf64970dee50ba9_hd.jpg

体验科技是 UX = f(services) 这个公式,能将各种各种的 services(后端服务) 通过技术与设计的融合,转变成体验一流的用户产品。这个公式的一个实现,就是蚂蚁体验云。蚂蚁体验云的初心,是希望能帮助有梦想的你,将一个个优秀的想法,通过体验云实现成一个个终端产品。 v2-ab3eae986630f436d1c6b751f4a8d895_hd.jpg

体验云才刚刚起步,目前已在内部服务蚂蚁金服、阿里巴巴集团,同时快速孵化出了云凤蝶、语雀、小钱袋等创新产品。虽然还很不完善,但我们希望能尽快与用户一起成长。很多激动人心的事正在发生,通过体验科技的开放,我们希望着能为世界带来更多平等的机会。 v2-98323a7d1c563df55151451066a7709e_hd.jpg

感谢聆听,期待交流。

附 SEE Conf 演讲视频: 优酷地址

最后,演讲 PPT 已精心整理并转换为 PDF 上传至 SEE Conf 语雀在线知识库,欢迎下载(请 注册语雀,个人描述内注明 #知乎seeconf# 便可快速申请邀请码,登录后即可下载)

求教关于严格模式下定时器中this指向问题

$
0
0

浏览器环境

setTimeout执行函数打印this,如果非严格模式下指向window,严格模式下指向undefined

// 下面代码在严格模式下也指向window,为什么?

var timerID = setTimeout(function(val) {
  'use strict';	// 开启严格模式
  console.log(val)	// 1
  console.log(this) // window?
}, 1 * 1000, '1')

【聘】阿里云业务中台招募前端工程师 &专家

$
0
0

20090211_154905.jpg

大风起兮云飞扬,安得猛士兮守四方

我们是「阿里云事业群-中国区业务中台-平台产品技术-体验技术」,主要负责阿里云官网、控制台等产品,同时,负责业务中台前端相关的「工程体系、开发框架、组件体系、工具及平台」的研发工作,以横向支持各产品线和项目组,为部门、为公司提效。

职位描述

持续迭代并改进阿里云官网、控制台及其它产品、提升用户体验; 参与面向业务中台的各种「框架、工具、平台」的开发,以及体系建设; 用技术服务中台业务,改进工作流程、提升工作效率、促进业务发展;

岗位要求

两年以上互联网行业前端工作经验; 基础编程知识牢靠,熟悉面向对象编程、熟悉函数式编程; 前端技术扎实,关注对新事物和技术,熟悉主流前端开发思想; 擅长 JavaScript,熟悉 ES2015,擅长 CSS,了解相关的前端生态; 擅长 React,了解 React 的核心思想,熟悉 Redux/MobX 理解它们解决的问题; 了解前端模块化,能够编写出易于维护的前端代码; 熟悉 Node.js,能够用 Node.js 编写工程工具或 Restful API 会使用 Webpack 或 Gulp 等前端构建工具实现开发流程自动化; 了解测试的重要性,熟悉测试驱动开发,熟练编写单元测试、E2E 测试; 熟练使用常用的 Git 操作,熟悉基于 Git 的常见协作规范及流程; 执行力强,有良好的分析、总结能力,能够有效识别痛点、并找到的解决方案; 良好的团队协作精神、利用自身技术能力提升团队整体研发效率;

加分内容

参与知名开源项目,或在 GitHub 上有超过 500 star 的个人项目; 熟悉包括但不限于 Java/Go/Python/PHP 等任意一门后端语言;

投递邮箱

zhanfeng.hzf@alibaba-inc.com标题注明「应聘前端工程师」

微信、QQ上页面,video 标签如何不默认全屏?有没有搞过的,实在没辙了

$
0
0

请不要百度出来的东西复制给我,, 百度了半天。。 有说是有白名单的,不知道哪里申请。。

你不知道的前端算法之文字避让

$
0
0

本文作者:TalkingData 可视化工程师李凤禄

编辑:Aresn

inMap 是一款基于 canvas 的大数据可视化库,专注于大数据方向点线面的可视化效果展示。目前支持散点、围栏、热力、网格、聚合等方式;致力于让大数据可视化变得简单易用。

GitHub 地址:https://github.com/TalkingData/inmap

文档地址:http://inmap.talkingdata.com/

在地理信息可视化中,我们经常会遇到在地图上标记文字的需求,下面展示的是某流行 chart 图表框架的效果:

image

要显示的文字空间不够时,就会造成文字重叠显示混乱,用户体验很不友好。

怎么解决这个问题呢?我们采用文字避让算法,解决这种坑爹的问题。

下面展示的是 inMap 文字避让效果:

image

文字标注算法是 GIS 中最复杂的问题之一(属于 NP 复杂度问题,所以通常不能找到最优解,只能找到较优解)。

inMap 避让算法采用的是四分位模型算法,接下来手把手教你写避让算法,老司机带你装逼带你飞。

准备数据

inMap 接收的是经纬度数据,需要把它映射到 canvas 的像素坐标,这就用到了墨卡托转换,墨卡托算法很复杂,以后我们会有单独的一篇文章来讲讲他的原理。经过转换,你得到的数据应该是这样的:

[
  {
    "name": "海门",//要显示的文字
    "lng": 121.15,
    "lat": 31.89,
    "count": 7,
    "pixel": { //像素坐标
      "x": 968,
      "y": 736
    }
  },
  {
    "name": "鄂尔多斯",
    "lng": 109.781327,
    "lat": 39.608266,
    "count": 5,
    "pixel": {
      "x": 659,
      "y": 478
    }
  },
...
]

好了,我们得到转换后的像素坐标数据(x、y),就可以做下面的事情了。

求出每段文字矩形的实际大小

measureText()是 canvas 内置的方法,返回字体宽度的像素单位:

let ctx = this.container.getContext('2d'); // canvas 上下文
let width= ctx.measureText(name).width;

我们通过 measureText 得到每个文字的宽度,canvas 并没有直接获取文字的方法,那文字的高度如何的得到呢?

我们通过反复测试发现 canvas 的 font 等于 “13px Arial” 字体(别的字体不敢保证)的时候,文字的高度大概是 fontSize 的 1.1 倍。

所以代码如下:

let fontSize = parseInt(ctx.font);
let height = fontSize * 1.1;

文字的宽度和高度得到后,我们就可以创建文字矩形的坐标系了。

创建四分位模型

image

所谓四分位模型,每一个标记点都有上下左右四个放文字的位子,如果左边放不下,那就放右边试试,还不行就放到下面试试,以此类推,原理就这么简单,哈哈。

创建右侧虚拟矩形坐标描述:

image

右侧虚拟矩形坐标的描述把圆点也包含在内了,是为了防止文字和圆点重叠。

在计算虚拟矩形的高度时有些坑,圆点大小不是固定的,是根据用户动态配置的,圆点的直径可能大于文字的高度,我们就设定虚拟矩形的高度永远都是最大的那个,需要做一些特殊处理。

代码如下:

_getLeftAnchor() {
    let x = this.center.x - this.radius - this.textReact.width,
        y = this.center.y - this.textReact.height / 2,
        diam = this.radius * 2,
        maxH = diam > this.textReact.height ? diam : this.textReact.height; //矩形的高度
    return {
        x,
        y,
        minX: x,
        maxX: this.center.x + this.radius,
        minY: this.center.y - maxH / 2,
        maxY: this.center.y + maxH / 2
    };
}

以此类推,描述下面、左面、上面的虚拟矩形坐标。

判断碰撞

判断两个矩形是否覆盖相交,根据矩形的 minX,maxX,minY,maxY 判断相交,原理比较简单,代码如下:

/**
 * 判断分位是否相交
 * @param {*} target 
 */
 
isAnchorMeet(target) {
    let react = this.getCurrentRect(),
        targetReact = target.getCurrentRect();
    if ((react.minX < targetReact.maxX) && (targetReact.minX < react.maxX) &&
        (react.minY < targetReact.maxY) && (targetReact.minY < react.maxY)) {
        return true;
    }
    return false;
}

创建虚拟文字集合对象

let labels = pixels.map((val) => {
    let radius = val.pixel.radius + this.style.normal.borderWidth; //圆点半径
    return new Label(val.pixel.x, val.pixel.y, radius, fontSize, byteWidth, val.name);
});

递归遍历虚拟文字集合、判断是否与其他相交,如果有相交就移动当前文字位子,直到不相交为止。当找不到合适位置时,就选择隐藏当前文字。

代码如下:

do {
    var meet = false; //本轮是否有相交
    for (let i = 0; i < labels.length; i++) {
        let temp = labels[i];
        for (let j = 0; j < labels.length; j++) {
            if (i != j && temp.show && temp.isAnchorMeet(labels[j])) {
                temp.next();
                meet = true;
                break;
            }
        }
    }
} while (meet);

绘画文字

labels.forEach(function (item) {
    if (item.show) { //是否显示
        let pixel = item.getCurrentRect();
        ctx.beginPath();
        ctx.fillText(item.text, pixel.x, pixel.y);
        ctx.fill();
    }
});

文字避让算法到目前介绍完了,对应的 inMap 文件地址为https://github.com/TalkingData/inmap/blob/master/src/worker/helper/Label.js,接下来还会继续给大家分享干货。

福利

分享两位业内大牛的前端课程:

如何避免 Node 安全漏洞----越权

$
0
0

web安全中XSS,CSRF 大多都基本可以防范,但是很多比例集中在越权这块,有没有什么好的策略来尽可能的避免,求知

express的依赖模块send中this.res是从哪里初始的

$
0
0

在看express的源码的时候 发现它的一个依赖库send 主要为了流式发送文件等 在看这个模块的代码的时候 发现里面有下面这段 image.png这个模块继承了stream模块 通过看node lib下的stream模块 没有发现在哪里初始了this.res
想的一个原因是express中调用的时候 res绑定到res上 通过原型查找到(因为代码中有句this.req = req这个req是在初始的时候传入 的)对这部分的理解不好 但是通常情况下使用这个模块呢 这个res是在哪里初始的呢。 image.pngimage.png


electron 打包adb二进制文件,访问不可用的问题

$
0
0

版本信息如下:

adb:Android Debug Bridge version 1.0.39 Revision 3db08f2c6889-android "electron": “1.7.10”, “electron-builder”: “^19.48.3”, “electron-webpack”: “1.11.0”, “electron-webpack-ts”: “^1.2.0”, node.js:v6.9.4 Mac OS:10.13.1

Expected behavior

可以启动adb service通过adb devices获取到设备id

Actual behavior


A JavaScript error occurred in the main process

Uncaught Exception:

Error : spawn ENOTDIR

adb放置在resources/mac/adb,代码写在src/index.js中,整体的目录结构如下:

resources // adb二进制文件
src //源代码
.babelrc
package.json

代码:

import os from 'os';
import path  from 'path';
import childProcess from 'child_process';
const spawn = childProcess.spawn;
const PLATFORM = {
  MAC: 'mac',
  WINDOWS: 'windows',
  UNKNOWN: 'unknown'
}
function fetchPlatform(){
  switch(os.platform()){
    case 'darwin':
        return PLATFORM.MAC;
      break;
    case 'win32':
        return PLATFORM.WINDOWS;
      break;
    default:
        return PLATFORM.UNKNOWN;
      break;
  }
}
const platform = fetchPlatform();
const rootDir = path.resolve(__dirname,'../');
const RESOURCES = path.resolve(rootDir,'resources')
const _adbPath = path.resolve(RESOURCES,platform);
function fetchAdbPath(){
  switch(platform){
    case PLATFORM.MAC:
        return path.resolve(_adbPath,'adb');
      break;
    case PLATFORM.WINDOWS:
        return path.resolve(_adbPath, 'adb.exe');
      break;
    default:
        return false;
      break;
  }
}
export function start_server(callback){
  let adbExecPath = fetchAdbPath();
  if (adbExecPath){
    let adb = spawn(adbExecPath,['start-server']);
    adb.stdout.on('data', function (data) {
      console.log('stdout: ' + data);
    });
    adb.stderr.on('data', function (data) {
      console.log('stderr: ' + data);
    });
    adb.on('exit', function (code) {
      typeof callback === 'function' && callback(code);
    });
    adb.stdin.end();
  } else {
    throw new Error('Not Found Android Debug Bridge');
  }
}

How to reproduce

将上述代码做为一个npm包,假设叫adb-test-a,然后在electron工程里,npm install adb-test-a,调用start_server,必抛错误:Error : spawn ENOTDIR

自己发现的问题是:每一个操作系统的版本的路径不同,spawn访问了错误的路径。然后自己也找了一些方法,发现都不起做用,比如asar:false这样的配置关闭asar,依然问题如旧。

编码库是什么一个概念?

$
0
0

最近express 项目用到 “ffmpeg” 这个模块 ,文档说明“需要已经安装了ffmpeg(包括libmp3lame或libx264等所有必要的编码库)”,请问这个是怎么一个概念?是要在电脑环境配置那里设置码?还是只是通过 npm 就能下载?

cpu profile中的program指标指的是什么?

$
0
0

程序出了点问题,cpu一直占满,但是业务代码基本没执行, profile如图,问下99.9%的program指标是什么?是死循环吗? image.png

nest之后,觉得其他框架脚手架可以立碑了……

$
0
0

标题有点夸大,不过用过nest之后,本人是不想在用其他框架了。不过,没有想安利大家的意思,前提是你要足够了解nest。 准确说,nest不是框架,而是模块规范,或者是高阶构建工具,它改变了以往团队协同的编码组织结构,使得模块化开发思想真正得以实现,提高的并不是技术,而是降低了耦合风险,隔离了工作区间,具体说明可以看我的gh 链接:nest介绍 nest的学习成本较高,对于基础理论,设计模式,原生语法都要有较高的理解要求,如果想用nest,建议 先看es6的proxy,reflect,symbol 链接:es6的Reflect再看typescript的装饰器 链接:TS装饰器再看java的六大设计原则(自行百度) 再看nestjs的核心代码实现 链接:nestjs最后写一个完整的场景覆盖demo(自己动手) 你会发现…… 前端弱爆了,哈哈哈 开玩笑的,你会爱上nest。

Golang defer的Javascript实现

$
0
0

简单先说一下Go的defer特性:

  • defer是后进先出的原则执行
  • defer是在函数运行结束之后,才会运行

那么这些特性能干什么

  • 延迟任务
  • 尾部验证(比如运行函数之后,需要对返回值校验)
  • 资源销毁

一个具体的场景

在后端开发中,可能需要多人协作,多语言,多模块开发。这时候可能就需要用RPC通信

比如有个用户模块,在进入到一个业务的时候,你需要去验证用户是否合法

async function main(username) {
  const client = await rpc.createConnection(); // 创建RPC链接
  const data = await client.getUserInfo(username); // 通过RPC链接获取用户信息
  // 下面是业务逻辑
}

但是你发现,RPC链接并没有被关闭(即便函数执行完毕,对象client被销毁), 它依旧占用着服务端的资源,如果多次调用这个函数,会多服务端造成很大的压力.

解决方案有两个

  1. 维护连接池
  2. 在每次创建链接之后都销毁

第一种方法是大多数ORM,RPC框架做的,应用内只保持n个链接,不断的创建再销毁,而这个过程不用使用者关心。 很可惜的是,我选用的RPC框架Thrift,有屎一样的坑。为了保持和Go的业务逻辑一样,采用第二种方案,每次创建链接之后都销毁,保证它是干净的

依旧是上面的代码,改成这样

async function main(username) {
  const client = await rpc.createConnection(); // 创建RPC链接
  try{
    const data = await client.getUserInfo(username); // 通过RPC链接获取用户信息
    // 下面是业务逻辑
  }catch (err){
    await client.close(); // 关闭链接
    throw err
  }
}

上面的代码已经能很好的解决问题了,但是也有一个,如果需要关闭多种链接呢(比如RPC,DB,Socket等),一直try,catch也不是办法

受到Go的defer启发,于是写了这么一个库godefer, 依旧改写上面的代码

const godefer = require('godefer');

const main = godefer(async function(username, defer) {
  const client = await rpc.createConnection();

  // 注册一个defer函数
  defer(function() {
    client.close(); // 关闭链接
  });
  
  const data = await client.getUserInfo(username);
  
  // 下面是业务逻辑
  // ...
  // 运行完毕,则开始执行defer
});

Defer函数的执行,遵循了后进先出的原则, 即 先注册的defer函数,后运行

实现上与Go差不多, 有一点重要的差别是:

Go的defer内,能修改父级函数的返回值 godefer不能修改(不是不能做,而是不做)

好了,愉快的解决问题了, 有什么想法,评论来刚啊

Viewing all 14821 articles
Browse latest View live