node-canvas 绘制文字,自定义字体,最新文档更新

发现网上很多人都在提供一个错误都思路,因为node-canvas已经更新了,所以自定义字体只需要如下写法
请注意,注册registerFont字体方法的位置,一定要在createCanvas之前


const { registerFont, createCanvas } = require('canvas')
registerFont('comicsans.ttf', { family: 'Comic Sans' })

const canvas = createCanvas(500, 500)
const ctx = canvas.getContext('2d')

ctx.font = '12px "Comic Sans"'
ctx.fillText('Everyone hates this font :(', 250, 10)

前端规范第一版

以下为前端规范第一版,大家有啥想法及时交流一起完善

HTML 基本规范 【强制】

  • 标签全部小写且闭合
  • 代码中的引号全部使用双引号(区别js)
  • 合理使用语义化html标签
  • 使用utf-8编码

css 基本规范 【强制】

  • pc端默认字号16px;
  • 使用外链css文件
  • html标签中不使用style样式
  • css文件中样式按块写,公共样式要提取,同一属性要合并,注释要清楚
  • 尽量不使用html标签选择器来声明样式
  • 样式的小图片使用sprite图片
  • h5页面使用rem适配,html的font-size:50px;

CSS选择器命名规范 【强制】

  • 类和id命名,一律小写,使用中杠连接
  • 类和id命名,尽量不缩写,除非一看就明白的单词
  • 不要轻易使用id

CSS书写顺序 【建议】

  • 位置属性(position, top, right, z-index, display, float等)
  • 大小(width, height, padding, margin)
  • 文字系列(font, line-height, letter-spacing, color- text-align等)
  • 背景(background, border等)
  • 其他(animation, transition等)

公共组件的css 【强制】

继续阅读前端规范第一版

微信小程序swiper之巨坑

今天突然发现自己的小程序出现问题,多页滑动到第二页有问题,出现空白,元素不展示,奇怪从来没动过呢,后来发现自己手机微信版本更新了 版本号为:7.08

是不是新版本导致swiper组件出现问题呢,特意找了一个代码片段,没问题,那就是自己代码的问题了!

把所有代码从头到尾删了个遍,最后发现是swiper-item 内定义了宽高所致,记录一下

最后亮出我的小程序,一起学习交流

 

微信小程序自定义组件编写指南之我见一

微信小程序自定义组件(以下组件特指自定义组件)在开发过程中有着不可替代的作用,在我看来,小程序的编写就是大部分工作量在组件的开发,在前期规划好组件功能,在小程序不断迭代会有非常好的编程体验

实际上,组件开发也体现出了前端在开发过程中封装的思想,这里就谈一下我在开发过程中的一些感悟,记录总结一下,供大家参考填坑

以下为文章导航,不一定按顺序写,有些文章也不一定会一次写完,有时间就写点补充,包括这里的目录也会修改补充,都会在这里列出来最新更新时间和链接,大家关注下吧

  • 先介绍一下组件的基本功能特性
    1. 写法规则,样式(8月23日更新)
    2. 通信规则
    3. 生命周期
    4. 组件之间关系
    5. 数据监听
    6. 单元测试
  • 什么时候我们应该使用组件
    1. 为什么要用组件 (8月23日更新)
    2. 什么时候要封装成组件
  • 新建组件规划
    1. 组件properties变量规划
    2. 组件私有数据规划
    3. 组件方法规划
    4. 组件通信事件规划
    5. 组件生命周期规划

组件模板和样式 

组件模板和样式

类似于页面,自定义组件拥有自己的 wxml 模板和 wxss 样式。

组件模板

组件模板的写法与页面模板相同。组件模板与组件数据结合后生成的节点树,将被插入到组件的引用位置上。

在组件模板中可以提供一个 <slot> 节点,用于承载组件引用时提供的子节点。

代码示例:

在开发者工具中预览效果

<!-- 组件模板 -->
<view class="wrapper">
  <view>这里是组件的内部节点</view>
  <slot></slot>
</view>
<!-- 引用组件的页面模板 -->
<view>
  <component-tag-name>
    <!-- 这部分内容将被放置在组件 <slot> 的位置上 -->
    <view>这里是插入到组件slot中的内容</view>
  </component-tag-name>
</view>

注意,在模板中引用到的自定义组件及其对应的节点名需要在 json 文件中显式定义,否则会被当作一个无意义的节点。除此以外,节点名也可以被声明为抽象节点

模板数据绑定

与普通的 WXML 模板类似,可以使用数据绑定,这样就可以向子组件的属性传递动态数据。
继续阅读组件模板和样式 

破34亿!《哪吒》跻身前五

高兴由衷的 为中国的动漫事业

猫眼公布的最新实时数据显示,截止8月11日16时07分,动画电影《哪吒之魔童降世》(以下简称《哪吒》)累计票房达到34.50亿,排在中国电影票房总榜第5名。

数据显示,截止11日12时41分,《哪吒》累计票房达到33.99亿,已经超过前日第6名《美人鱼》的33.86亿元和第5名《唐人街探案2》的33.97亿元。其中有9393.5万人次观看,猫眼口碑评分高达9.7分。

在中国电影票房总榜上,截至8月10日的数据显示,《哪吒》还以33.39亿元排在第7位,但目前排到该榜单的第5名,并直指第4名《红海行动》的36.5亿元。

据此前报道,截至8日17时32分,该影片已连续13天获得单日票房冠军,累积突破30亿,跻身中国影史票房总榜前八名,并成为中国影史首部进入“30亿俱乐部”的动画电影。

据了解,《哪吒》从上映以来连续创造多项纪录,直到今天已经进入上映后的第17天,票房占比仍超过54%,排片占比高达37%,猫眼票房专业版对其总票房预测为47.17亿。

如何优雅重加载 Web 应用 

但凡在各种环境中,尤其是生产环境中部署过应用的,比如更新应用或者配置,就会了解到,应用的重启或者升级多少都会影响用户访问,那这种影响会到什么程度呢?

影响用户的重启

表面上看,轻则是页面不能正常加载,让用户以为是网络不好(事实上,这也经常成为服务器出问题的背锅原因,有的 APP 则直接在前端硬编码报错信息,所有的错误统一显示:网络出错了,请重试)。
重则影响用户的支付流程,导致用户放弃支付,更严重的则是用户支付过程中处理数据不当的话,就会丢失数据,导致对账失败。

而从本质上看,如果你在浏览器中调试的时候,这种错误会在调试窗口显示 net::ERR_CONNECTION_REFUSED,原因就是端口被释放了,这也就是告诉我们,重启过程中的一段时间里,由于后续程序无法快速建立监听,会导致 TCP 链接被短时间断开,端口监听也会被释放,导致数据包无法送达,正在使用中的连接也会被打断,就会导致这个现象。

所以,我们该如何解决?回过头看这个过程,我们就需要达到的目标无非就是用户无感知,那对于我们就有两种方案:一种是把这个责任交给现有的成熟负载均衡器,另一种是自己用操作系统提供的 API 自己实现自我升级。

自我升级方案

目前已经有多个社区的基础库可以帮助实现了,比如 Golang,我们至少有以下几个1

实际上,看源码后自己实现也可以,因为原理是一致的,升级的大致过程就是以下:

  1. 启动进程,运行 Web 服务,监听相关的端口;
  2. 接收到 Reload 命令,运行新程序,运行并等待服务可用;
  3. 新子程序出错时,直接报错,退出 Reload 步骤;
  4. 没有问题则继续,旧进程退出,新进程接管流量;

这种方案就是非常常见的方案,只是在这个过程中,同一时间只允许一个升级,不然就会出现问题。其实还有个方案,如果是针对自己无法修改的程序,可以参考 Github 为 HAProxy 开发的 multibinder2

负载均衡方案

这种方案是最简单的,因为负载均衡器可以接管流量,负责升级过程:当新进程准备完成时,把旧 Web 应用的流量切换到新 Web 应用,然后不断升级剩余的应用,这在 Kubernetes 或者 Docker Swarm 中叫做 Rolling Upgrade,这个过程会非常顺滑,可以达到让用户无感知。

另外,有的负载均衡器自己就实现了自我升级的,比如 Nginx,我们用 nginx -t reload 这个命令就能让 Nginx 重新加载配置,这个过程中,它就进行了自我升级。

而在 Node.js 中,有 pm2 提供给我们的 Graceful shutdown 方案,即通过进程内通信的方式,让我们能够在关闭时提前关闭数据库等连接,以及启动的时候等数据库连接等完成后再继续。这种方式可以让我们自己在 Cluster 模式中,进行应用的优雅升级,只是,它做得不够好(2.x 版本的时候):

  1. 升级过程中,不会判断新程序有没有准备完毕,一旦超时还是会继续升级,这在之前导致了非常多的线上问题;
  2. 升级无法控制速度,升级速度很快,于是我们可以看到监控画面上,过山车似的一上一下,这实际上是不好的,因为这就表示我们的重启影响到了部分用户;

新版本 (3.x) ,还没用过,但是看文档,它提供了 –parallel 这个参数,能让我们自己控制并行升级数量了,也就是能控制升级速度了,配合 Graceful shutdown 的功能,应该能够缓解。

但更好的方案的话,还是得用 Kubernetes 提供的 Rolling Upgrade 功能,这在我之前的实践中,可以观察到明显的对比,即新方案上了之后,每次升级监控上的响应时长波动会很小。

Ref

  1. Graceful upgrades in Go
  2. GLB part 2: HAProxy zero-downtime, zero-delay reloads with multibinder

首发于 Github issues: https://github.com/xizhibei/blog/issues/108 ,欢迎 Star 以及 Watch

本文采用 署名-非商业性使用-相同方式共享(BY-NC-SA)进行许可
作者:习之北 (@xizhibei)
原链接:https://blog.xizhibei.me/2019/06/03/how-to-graceful-reload-web-app/

shell.js——给node插上隐形的翅膀

一.Shell && Shelljs

码农界存在着无数条鄙视链,linux使用者对windows的鄙视便是其中之一,cli使用者对GUI用户的嘲讽也是如此,在这样一个讲究逼格的时代,如果你的桌面上没有一个小黑窗时不时地从下往上翻滚并抛出一些亮绿色的字符串,你真不好意思跟人打招呼。而前端这种天生几乎不用和命令行打交道的物种,自然再一次莫名其妙地处在了鄙视链的末端,没错,是再一次。

Shelllinux下的脚本语言解析器,拥有丰富且强大的底层操作权限。Shelljs就是基于node的一层命令封装插件,让前端开发者可以不依赖linux也不依赖类似于cmder的转换工具,而是直接在我们最熟悉不过的javascript代码中编写shell命令实现功能。

二.前端开发人员学Shelljs干嘛

shell自动化是强相关的,个人理解其用途主要是两方面:

  • 1.从业务逻辑的需求来看,shelljs并不是什么具有非凡意义的插件,它只是对node的底层API进行了一些封装,方便我们以类似shell的语法去编写代码梳理逻辑,实现一些业务逻辑需求,如果你所在的项目组恰好需要这样的能力,用它会很方便;
  • 2.cli相对于GUI或许是更快,但它依然是一种重复劳作,有了shelljs和全栈能力,开发者可以将团队中耗时的重复性常规动作编写为自动化脚本,并利用前端的天然优势为其配备GUI,用页面上的一键点击来替代重复劳作,在紧张的开发节奏中,平均每天为你节约个30-40分钟起来走走喝杯水难道不好吗?

想要一统江湖,大前端的深度和广度是缺一不可的,你可以说你不精通shell,但不要说自己不懂shell,更不要一脸天真地反问面试官“前端还能搞shell?这么神奇?”他不会觉得你对知识有好奇心,只会觉得你很low,哦不对,是大写的LOW.

三.官方示例(包含注释)

废话说完了,开始学习,拿好小本子,我要开车了。

//引入shelljs
var shell = require('shelljs')

//检查控制台是否以运行`git `开头的命令
if (!shell.which('git')) {
  //在控制台输出内容
  shell.echo('Sorry, this script requires git');
  shell.exit(1);
}

shell.rm('-rf','out/Release');//强制递归删除`out/Release目录`
shell.cp('-R','stuff/','out/Release');//将`stuff/`中所有内容拷贝至`out/Release`目录

shell.cd('lib');//进入`lib`目录
//找出所有的扩展名为js的文件,并遍历进行操作
shell.ls('*.js').forEach(function (file) {
  /* 这是第一个难点:sed流编辑器,建议专题学习,-i表示直接作用源文件 */
  //将build_version字段替换为'v0.1.2'
  shell.sed('-i', 'BUILD_VERSION', 'v0.1.2', file);
  //将包含`REMOVE_THIS_LINE`字符串的行删除
  shell.sed('-i', /^.*REMOVE_THIS_LINE.*$/, '', file);
  //将包含`REPLACE_LINE_WITH_MACRO`字符串的行替换为`macro.js`中的内容
  shell.sed('-i', /.*REPLACE_LINE_WITH_MACRO.*\n/, shell.cat('macro.js'), file);
});

//返回上一级目录
shell.cd('..');

//run external tool synchronously
//即同步运行外部工具
if (shell.exec('git commit -am "Auto-commit"').code !== 0){
    shell.echo('Error: Git commit failed');
    shell.exit(1);
}

继续阅读shell.js——给node插上隐形的翅膀

6个最优秀的微信小程序UI组件库

开发微信小程序的过程中,选择一款好用的组件库,可以达到事半功倍的效果。自从微信小程序面世以来,不断有一些开源组件库出来,下面6款就是排名比较靠前,用户使用量与关注度比较高的小程序UI组件库。还没用到它们的你,可以关注和了解一下哦!

WeUI WXSS

WeUI WXSS是腾讯官方UI组件库WeUI的小程序版,提供了跟微信界面风格一致的用户体验。

GitHub地址:https://github.com/Tencent/weui-wxss
npm下载:npm i weui-wxss

iView WeApp

iView是TalkingData发布的一款高质量的基于Vue.js组件库,而iView weapp则是它们的小程序版本。

GitHub地址:https://github.com/TalkingData/iview-weapp
npm下载:npm i iview-weapp

ZanUI WeApp

ZanUI WeApp是有赞移动 Web UI 规范 ZanUI 的小程序实现版本,结合了微信的视觉规范,为用户提供更加统一的使用感受。

现已包含 badge、btn、card、cell、dialog、icon、label、noticebar、panel、popup、switch、tab、toast、tooltips 等组件或元素。

GitHub地址:https://github.com/youzan/zanui-weapp
npm下载:npm i zanui-weapp

另外,ZanUI也使用mpvue重写了zanui-weapp,实现了其中所有组件,为使用mpvue的开发者提供了方便。

GitHub地址:https://github.com/samwang1027/mpvue-zanui
npm下载:npm i mpvue-zanui

继续阅读6个最优秀的微信小程序UI组件库

tite与h1的区别 、b与strong的区别 、i与em的区别

html语义化标签:

1)title与h1的区别

title与H1是不能划等号的

1.H1是大标题的意思。一般出现网页文章页面,作用如同一张报纸的大标题,使用读者在没看内容之前就

大概了解本文的旨意,它是直接给用户看的。而且在SEO中,搜索引擎也非常重视H1,目的是告诉搜索引擎,这

个地方的内容很重要,H1要求贴近文章内容,突出主题,言简意赅。

2.title是用来面对的是搜索引擎和用户,其范围相对于H1来说要广,title中可以包含H1,在搜索引擎中

tiele的权重要高于H1;一般来讲,H1做到突出主题目,title修饰主题关键字。

H1与title之间的联系

A.从网站角度而言,title则重于网站信息标题,突出网站标题或关键字用title,一篇文章,一个页面最好只

用一个H1,H1用得太多,会稀释主题;一个网站可以有多个title,最好一个单页用一个title以便突出网站页面

主题信息。

B.从文章角度而言,H1则概括的是文章主题,突出文章主题,用H1,面对的用户,要突出其视觉效果。

从SEO角度看,title的权重高于H1,其适用性要比H1广。

2)b与strong的区别

b和strong标签,在网页中默认的情况下均是加粗字体的作用;

标签是一个实体标签,它所包含的字符将被设为blod粗体,是html语言中的;—视觉化

标签是一个逻辑标签,作用是为了加强语气而加粗字体,是xhtml中的,其强调作用,可以用css标

签控制strong强调的方式。—-语义化标签

在符合w3c的标准,推荐使用strong标签—语义化

3)i与em的区别

标签告诉浏览器把其中的文本表示为强调的内容。标签可以用来把这些名称和其他斜体字区别

开来。

在文本中加入强调也需要有技巧。如果强调太多,有些重要的短语就会被漏掉;如果强调太少,就无法真

正突出重要的部分。这与调味品一样,最好还是不要滥用强调。

尽管标签修饰的内容都是用斜体字来显示,但这些内容也具有更广泛的含义,将来的某一天,浏览

器也可能会使用其他的特殊效果来显示强调的文本。

如果你只想使用斜体字来显示文本的话,请使用 标签。除此之外,文档中还可以包括用来改变文本显

示的级联样式定义。

除强调之外,当引入新的术语或在引用特定类型的术语或概念时作为固定样式的时候,也可以考虑使用

标签。例如,W3School 经常对重要的术语使用标签。标签可以用来把这些名称和其他斜体字

区别开来。

作者:蜻蜓之鱼
链接:https://www.jianshu.com/p/59691c0900d3
來源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。