jrainlau.github.io icon indicating copy to clipboard operation
jrainlau.github.io copied to clipboard

My personal blog.

Results 33 jrainlau.github.io issues
Sort by recently updated
recently updated
newest added

![未命名 002](https://user-images.githubusercontent.com/12172868/96690661-8cac2680-13b6-11eb-97a8-f7c96e51c4f6.jpeg) > 项目仓库:https://github.com/jrainlau/node-redis-missions-queue ## 前言 在最近的业务中,接到了一个需要处理约十万条数据的需求。这些数据都以字符串的形式给到,并且处理它们的步骤是异步且耗时的(平均处理一条数据需要 25s 的时间)。如果以串行的方式实现,其耗时是相当长的: > 总耗时时间 = 数据量 × 单条数据处理时间 > > T = N * t (N = 100,000; t = 25s) > >...

original

![image](https://user-images.githubusercontent.com/12172868/58156892-c2248000-7ca9-11e9-91a9-1583773d9108.png) 对于爱写东西的人来说,挑一个合适的博客平台是非常重要的。而作为一个 Web 开发者,我们肯定都希望能够拥有一个高度定制化的博客平台,用以展示我们独一无二的个性以及记录长久以来的学习工作等。与此同时,我们也希望这个平台可以让我们方便地发布内容,提供完整的点赞、留言等操作。在经历过 Hexo,Wordpress,自行搭建服务等一系列尝试以后,我最后选择了以 Github issues 来作为我的博客平台。 ## 博客的基本能力 对于一个合格的博客平台来说,它主要提供了下列几种能力: 1. 个人介绍 对于个人博客来说,它首先要支持展示博主的个人介绍。这个个人介绍里面可能包括了头像、昵称、联系方式等基本内容,能够让读者能够对这个博客的主人有一个基本的认识。 2. 文章的撰写与展示 对一个博客来说,最重要的就是它的内容,也就是里面的文章。一个好用的博客平台应该具备方便的撰写文章的能力,让够让用户毫无负担地撰写、编辑自己的文章。此外,还必须能够文章的信息,比如展示标题、节选、封面,创建/修改时间,评论点赞数等等。 3. 归档能力 一篇文章的撰写时间、内容标签/分类等都是不同的,如何按照不同的要求对这些文章进行归档整理,也是考验博客平台的能力之一。再者,当文章数量较多的时候,添加一个搜索的功能也能大大方便读者对博客的浏览。 4. 博主与读者互动的能力 仅仅只有博主一个人自嗨可能难以激发写作的动力,如果博客能够提供博主与读者互动的能力,将能有效激励博主持续创作,更能提升文章的传播度——点赞和评论功能则是互动能力中最重要的功能之一。 经过上面的几个点,基本可以知道一个博客平台,其主要功能就是“展示自己,沟通外界”。在满足这个基础的前提下,它也应该具备方便操作,高度定制化的特点。 ## 为什么不选择其他方案 ![image](https://user-images.githubusercontent.com/12172868/58172040-0d4e8b00-7cca-11e9-85df-768fb1ec1ed7.png) 在文章的开头我有提到,我曾经尝试过用 Wordpress,Hexo,自行搭建服务等途径去尝试维护博客。但这些尝试的结果均不合我意,最后无疾而终。归根结底,就是不够自由和方便。 举个例子,Wordpress...

original

![image](https://user-images.githubusercontent.com/12172868/94019570-85f4b880-fde4-11ea-893f-7b67dd0b2780.png) 在最近的工作中,接手了一个古老的项目,其中的 JS 代码是一整坨的面条代码,约 3000 行的代码全写在一个文件里,维护起来着实让人头疼。 ![image](https://user-images.githubusercontent.com/12172868/94010564-afa7e280-fdd8-11ea-89c3-1a8132e6499b.png) 想不通为啥之前维护项目的同学能够忍受这么难以维护的代码……既然现在这个锅被我拿下了,怎么着也不能容忍如此丑陋的代码继续存在着,必须把它优化一下。 横竖看了半天,由于逻辑都揉在了一个文件里,看都看得眼花缭乱,当务之急便是把它进行模块化拆分,把这一大坨面条状代码拆分成一个个模块并抽离成文件,这样才方便后续的持续优化。 ## 一、结构分析 说干就干,既然要拆分成模块,首先就要分析源码的结构。虽然源码内容很长很复杂,但万幸的是它还是有一个清晰的结构,简化一下,就是下面这种形式: ![code](https://user-images.githubusercontent.com/12172868/94011611-3a3d1180-fdda-11ea-9150-683cc9f4ea7b.png) 很容易看出,这是一种 ES5 时代的经典代码组织方式,在一个 IIFE 里面放一个构造函数,在构造函数的 `protorype` 上挂载不同的方法,以实现不同的功能。既然代码结构是清晰的,那么我们要做模块化的思路也很清晰,就是想办法把所有绑定在构造函数的 `prototype` 上的方法抽离出来,以模块文件的形式放置,而源码则使用 ES6 的 `import` 语句把模块引入进来,完成代码的模块化: ![code](https://user-images.githubusercontent.com/12172868/94012243-1af2b400-fddb-11ea-9fc0-1b7fc5f850d8.png) 为了完成这个效果,我们可以借助 `@babel` 全家桶来构造我们的转化脚本。...

original

> 原文链接:https://dmitripavlutin.com/parse-url-javascript/ 统一资源定位符,缩写为URL,是对网络资源(网页、图像、文件)的引用。URL指定资源位置和检索资源的机制(http、ftp、mailto)。 举个例子,这里是这篇文章的 URL 地址: ``` https://dmitripavlutin.com/parse-url-javascript ``` 很多时候你需要获取到一段 URL 的某个组成部分。它们可能是 *hostname*(例如 `dmitripavlutin.com`),或者 *pathname*(例如 `/parse-url-javascript`)。 一个方便的用于获取 URL 组成部分的办法是通过 `URL()` 构造函数。 在这篇文章中,我将给大家展示一段 URL 的结构,以及它的主要组成部分。 接着,我会告诉你如何使用 `URL()` 构造函数来轻松获取 URL 的组成部分,比如 hostname,pathname,query...

translate

![一座被设计为能避开气流的建筑 (https://pixelz.cc)](https://user-images.githubusercontent.com/12172868/72320668-208ceb80-36dd-11ea-966b-98b20c978288.png) 软件应用程序在计算机的主存储器中运行,我们称之为随机存取存储器(RAM)。JavaScript,尤其是 NodeJS (服务端 JS)允许我们为终端用户编写从小型到大型的软件项目。处理程序的内存总是一个棘手的问题,因为糟糕的实现可能会阻塞在给定服务器或系统上运行的所有其他应用程序。C 和 C++ 程序员确实关心内存管理,因为隐藏在代码的每个角落都有可能出现可怕的内存泄漏。但是对于 JS 开发者来说,你真的有关心过这个问题吗? 由于 JS 开发人员通常在专用的高容量服务器上进行 web 服务器编程,他们可能不会察觉多任务处理的延迟。比方说在开发 web 服务器的情况下,我们也会运行多个应用程序,如数据库服务器( MySQL )、缓存服务器( Redis )和其他需要的应用。我们需要知道它们也会消耗可用的主内存。如果我们随意地编写应用程序,很可能会降低其他进程的性能,甚至让内存完全拒绝对它们的分配。在本文中,我们通过解决一个问题来了解 NodeJS 的流、缓冲区和管道等结构,并了解它们分别如何支持编写内存有效的应用程序。 我们使用 NodeJS v8.12.0 来运行这些程序,所有代码示例都放在这里: [narenaryan/node-backpressure-internals](https://github.com/narenaryan/node-backpressure-internals) >...

translate

随着 Vue 3.0 Pre Alpha 版本的公布,我们得以一窥其源码的实现。Vue 最巧妙的特性之一是其响应式系统,而我们也能够在仓库的 packages/reactivity 模块下找到对应的实现。虽然源码的代码量不多,网上的分析文章也有一堆,但是要想清晰地理解响应式原理的具体实现过程,还是挺费脑筋的事情。经过一天的研究和整理,我把其响应式系统的原理总结成了一张图,而本文也将围绕这张图去讲述具体的实现过程。 ![vue 3 响应式系统原理](https://user-images.githubusercontent.com/12172868/66459249-45067580-eaa7-11e9-9d83-e1596944e9cc.jpeg) > 文章涉及到的代码我也已经上传到[仓库](https://github.com/jrainlau/tiny-reactive),结合代码阅读本文会更为流畅哦! ## 一个基本的例子 Vue 3.0 的响应式系统是独立的模块,可以完全脱离 Vue 而使用,所以我们在 clone 了源码下来以后,可以直接在 packages/reactivity 模块下调试。 1. 在项目根目录运行 `yarn dev reactivity`,然后进入...

original

![image](https://user-images.githubusercontent.com/12172868/65132576-c1231580-da33-11e9-895a-45cbda6bdaae.png) 最近在做 Node 服务端需求的时候,遇到了几次服务端报错的问题。打 log 发现均是一些 Error,但是它们都没法很好地透传给前端浏览器,出现问题只能查看服务端机器的日志,调试起来非常不方便。思考了一下,服务端的内容都是通过 JSON.stringify() 处理,然后设置 `Content-type: text/json` 的响应头以后再传给前端的,如果 Error 也能够被这样处理,那么调试起来就方便多了。 ## 举个例子 说到 JSON.stringify() 这个方法,相信所有玩过 JS 的同学都不会陌生。它能够方便地把一个对象转化成字符串,在不同的场景中都有着极大的用处。但是它也有一个较大的缺点,无法直接处理诸如 Error 一类的对象。 首先来看个例子: ```javascript const err = new Error('This...

original

![image](https://user-images.githubusercontent.com/12172868/60765960-07bfcf80-a0d5-11e9-9eac-ebfb595cc90b.png) 上周发布了一款名为 [Smartour](https://github.com/jrainlau/smartour) 的工具,是完全采用 TypeScript (以下简称 ts)来开发的。抛开以前做业务的时候的不完全使用,这次实践可以算是我第一次真正意义上的使用 ts。由于写法上的不同,以及对不熟悉事物的新鲜感,在这次项目开发的过程中着实有着许多感悟,于是打算写篇小东西好好记录下来。 # TS 能让人养成“先思考后动手”的好习惯 在以往的开发过程中,我的习惯总是“先想好一个大概,然后边做边想再边改”。这样的好处是动作比较快,顺利的时候效率会很高,但更多的时候是不断地推翻自己先前的想法,相信不少的人也有跟我类似的体会。 而使用 ts,可以在一定程度上减少这个问题。众所周知 ts 是强类型的语言,这也意味着它能有效制约开发者在开发过程中“随心所欲”的程度。就以定义一个函数的参数为例,可以看看我在写 js 和 ts 的**思考方式**上有什么不同。 写 js 的时候,我的思考过程是这样的。 > 1. 首先这个参数是一个对象,这个对象的属性 `el` 是一个 css 选择器;而对象的属性...

original
typescript

![image](https://user-images.githubusercontent.com/12172868/57382983-8f29b900-71e0-11e9-8fe9-c0f12fd54a9a.png) 最近基于 Github API 开发了一款图床 Chrome 插件 **Picee**,现在已经开源并上架 Chrome 应用商店。当中的过程涉及到一些有趣的知识点,故将其记录下来。 > Github地址:https://github.com/jrainlau/picee > > Chrome商店下载地址:[Picee](https://chrome.google.com/webstore/detail/picee/nmeeieecbmdnilkkaliknhkkakonobbc) ## 灵感 平时有写点东西的习惯,但是奈何一直找不到合适的图床。有人推荐以微博或者七牛来做图床,但是总给我一种”受制于人“的感觉,不知道什么时候就会被各种限制,比如禁止图片外链等等。后来发现其实 Github 是非常适合做图床的,因为仓库里的文件都可以通过 `https://raw.githubusercontent.com` 这个链接直接外链以供下载。但是如果为了写个文章而每次添加图片都需要一顿 Git 操作,那么写作体验必定非常不好,如果有更方便的办法就好了——那就是Github API。 ## Github API Github 提供了一套完善的...

original

![image](https://user-images.githubusercontent.com/12172868/64330948-82896600-d004-11e9-94b0-932af0d32b45.png) 在使用 GraphQL (以下简称 gql)的前端项目中,往往需要等待后台同学定义好 Schema 并架设好 Playground 以后才能进行联调。如果后台同学阻塞了,前端只能被动等待。如果对于 gql 项目来说也能够和 REST 一样有一套 mock 方案就好了。经过一系列实践,我选择了 **mocker-api** 加 **Apollo** 的方案来实现。 ## mocker-api [mocker-api](https://github.com/jaywcjlove/mocker-api) 是一个基于 node 实现的接口 mock 工具(前身是`webpack-api-mocker`,依赖于 webpack-dev-server,现在可独立运行)。由于我们的项目大都和 webpack 结合,所以这里仅简单介绍其与...

original