今天在一台新 Windows 10 设备上尝试使用 yarn create 命令的时候发现一个报错：

可以看到是因为我的用户名中存在空格，导致 yarn create 命令误把空格之前的部分当做完整的命令来执行了，这显然是个 Yarn 的 bug。

寻找答案

首先 Google 一下：

很快就能定位到这个 Yarn 项目下的 issue：

cannot run yarn create if yarn is in a folder where the file path has a space · Issue #6851 · yarnpkg/yarn

Yarn v1.12.3 my laptop (helpfully, thank you windows) installed yarn by default in a directory where the file path includes a space (e.g. C:/Users/Some Name/AppData/Yarn...). This results in the fo...

GitHubyarnpkg

issue 里面有老哥提到了一个比较简单的 workaround。就是重新指定 cache-folder 和 prefix 这两个配置项，将默认路径替换为无空格路径：

yarn config set cache-folder "C:\Users\Valor~1\AppData\Local\Yarn\Cache"
yarn config set prefix "C:\Users\Valor~1\AppData\Local\Yarn"

试了下，搞定！

但过了一会，我居然在 Users 目录下发现了一个名为 Valor~1 的目录。

虽然不行，但还是很好奇老哥是从哪里知道会有 Valor~1 这种短名称的。

继续寻找答案

带着这个疑问继续找答案：

定位到这个提问：

How can I find the short path of a Windows directory/file?

I need to use shortened path names for an application that I am using. For example I need C:\PROGRA~1\ as opposed to C:\Program Files. The program can’t handle spaces and won’t accept quoted paths ...

Super Usersomehume

运行答主 @Paul 在回答里面给出的命令，就可以输出目录缩写了：

dir \x

同时答主 @freedenizen 解释了相关的规则：

The "short name" is really the old DOS 8.3 naming convention, so all the directories will be the first 6 letters followed by ~1 assuming there is only one name that matches, for example:

C:\ABCDEF~1    - C:\ABCDEFG I AM DIRECTORY
C:\BCDEFG~1    - C:\BCDEFGHIJKL I AM ANOTHER DIRECTORY

原来 Windows 对目录的总是保留前 6 个字符，然后以 ~1 结束，如果重复的话，则序号依次递增得到 ~2 ~3 ...

问题解决

显然，对我来讲正确的解决方案应该是：

yarn config set cache-folder "C:\Users\VALORL~1\AppData\Local\Yarn\Cache"
yarn config set prefix "C:\Users\VALORL~1\AppData\Local\Yarn"

运行之后，重新测试，问题解决。

后续阅读了更多的资料之后发现，这个应该是 Node.js 的锅，它居然不支持安装到带空格的路径中。但是别急，我们看下 macOS 的对同样用户名的目录处理方式：

所以说，归根结底：Windows 就是逊啦~

尝试一下记录问题解决过程的写法，如果大家喜欢这样的文章，给我点赞评论，下次有机会就多写写。

就讲这些了，我们下次再见。

作为一个经常需要在 VPS 上面部署各种应用的程序员，我要说 Docker 是真的香，但配置 Nginx 是真的烦。每部署一个新的应用，都要去改一次 Nginx 的配置文件，把它指向我们新部署的应用。每当应用下线的时候，还得记得手动去把对应的配置删掉。

虽然说只是改个配置文件的事情，这对于我这种又懒记性又差的人真是一件痛苦的事情。因为我根本记不住各种配置项，导致得在几个目录之间来回切换反复调试。麻烦也就算了，关键是这样一旦把 Nginx 改挂了，还会影响到其他正在运行的应用。

那么，有什么更好的办法来解决这个问题呢？

反向代理配置

nginx-proxy 这个项目帮我们解决了这个问题。

首先创建 docker-compose.yml 文件：

services:
  nginx-proxy:
    image: nginxproxy/nginx-proxy
    container_name: nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - conf:/etc/nginx/conf.d
      - vhost:/etc/nginx/vhost.d
      - html:/usr/share/nginx/html
      - certs:/etc/nginx/certs:ro
      - /var/run/docker.sock:/tmp/docker.sock:ro

  acme-companion:
    image: nginxproxy/acme-companion
    container_name: nginx-proxy-acme
    environment:
      - DEFAULT_EMAIL=mail@yourdomain.tld
    volumes_from:
      - nginx-proxy
    volumes:
      - certs:/etc/nginx/certs:rw
      - acme:/etc/acme.sh
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  conf:
  vhost:
  html:
  certs:
  acme:

这里面只有 DEFAULT_EMAIL 一个地方需要修改，改为你平时常用的邮箱就行。当证书快过期没有自动续订成功时， Let's Encrypt 会给这个地址发送报警邮件。

保存好之后，启动它，从此以后我们就再也不需要维护 Nginx 的配置了。

接着我们来配置需要被代理的应用。

应用配置

记得先将域名解析配置好，然后来写应用配置。以本站的 hello.doctype-html.com 配置为例：

services:
  hello.doctype-html.com:
    image: crccheck/hello-world
    environment:
      - VIRTUAL_HOST=hello.doctype-html.com
      - LETSENCRYPT_HOST=hello.doctype-html.com
    expose:
      - "8000"

networks:
  default:
    name: nginx-proxy_default

这份配置做了三件事情。

1. 设置 VIRTUAL_HOST和 LETSENCRYPT_HOST ，分别告知 nginx-proxy 和 Let's Encrypt 本应用想要使用域名。
2. 设置参数 expose，将此应用的端口暴露给 nginx-proxy。
3. 设置网络信息，保证应用跟 nginx-proxy 处于同一网络。

启动它，我们就能通过配置好的域名来访问这个应用了。

深入思考

大家有没有想过为什么有人能做出 nginx-proxy 这样的项目呢？它是基于什么样的思路做出来的呢？

其实，这里面只用到了一个控制反转的思想。我们在 Nginx 的配置中给其他应用做反向代理的时候，意味着配置文件需要了解所有应用的信息。

而 nginx-proxy 这个项目帮我们对反向代理配置做了一个抽象，定义成了一个规范，nginx-proxy 只依赖于这个规范，从而实现了与具体的应用信息的解耦。

我们只要按照它的规范来实现一个新应用的配置，它就能正确识别新应用。至此，被代理的应用就被插件化了，可以随时增删，同时也不用担心某个应用的配置修改导致全局的反向代理受到影响。

今天就聊这么多，我们下次再见。

Insert console.log()

Install extension: v-snippets

Type cl and then press TAB, it expand to console.log()

Usage:

cl => console.log()
cw => console.warn()
ce => console.error()
...

Wrap selected code

Install extension: javascript console utils

Usage:

Unit tests

Unit = Unit of work

This could involve multiple methods and classes invoked by some public API that can:

• Return a value or throw an exception
• Change the state of the system
• Make 3rd party calls

Basic

1. Test case
2. Test suit
3. Stub
4. Mock
5. Coverage

Test case

A test case is the smallest unit of testing. It checks for a specific response to a particular set of inputs.

You may do these things in a test case:

1. Prepare/mock input data
2. Apply action
3. Check the response

Format

it('should [expected behaviour] when [scenario/context]', () => {
  // Your test logic
});

Example

it("should return 2 when 1+1", () => {
  expect(add(1, 1)).toBe(2);
});

Some times you need to split it into multiple lines

:(

it("should return all matched person", async () => {
  expect(await personService.getPersonsByIds([1, 2, 3])).toEqual([{ id: 1 }, { id: 2 }, { id: 3 }
  ]);
});

:)

it("should return all matched person", async () => {
  const result = await personService.getPersonsByIds([1, 2, 3]);
  expect(result).toEqual([{ id: 1 }, { id: 2 }, { id: 3 }]);
});

But keep in mind that split code into multiple lines is the last choice, put them in same line when possible.

Test suit

A test suite is a collection of test cases, test suites, or both. It is used to aggregate tests that should be executed together.

Testing a function

Format

describe("[functionName()]", () => {
  it("should [expected behavior] when [scenario/context]");
});

Example

describe("add()", () => {
  it("should work with int");
  it("should return NaN when add a NaN");
  it("should concern about preciseness");
});

Testing a class

Format

describe('[ClassName]', () => {
  describe('[functionName()]', () => {
    it('should [expected behaviour] when [scenario/context]');
  }
});

Example:

describe("Calculator", () => {
  describe("add()", () => {
    it("should work with int");
    it("should return NaN when add a NaN");
    it("should concern about preciseness");
  });
});

Mocking

Mocking is one particlar technique to allow testing of a unit of code with out being reliant upon dependencies.

Mock could do these for you:

• Erasing the actual implementation of a function
• Capturing calls to the function
• Capturing instances of constructor functions when instantiated with new
• Allowing test-time configuration of return values.
• Boost test speed.

Ensure function called

import EventEmitter2 from 'eventemitter2';

class UploadManager extends EventEmitter2 {
  on(type, listener) {
    super.on(type, listener);
  }
  emit(type, ...arg) {
    super.emit(type, ...arg);
  }
}

it('should call the event handler', () => {
  const handler = jest.fn();
  uploadManager.on('1', handler);
  uploadManager.emit('1');
  expect(handler).toHaveBeenCalled();
});

Configure return values

import PostAPI from 'sdk/api/glip/post';

export default class PostService extends BaseService {
  async getPostsFromRemote({ groupId, postId, limit, direction }) {
    // ...
    const requestResult = await PostAPI.requestPosts(params);
    // ...
    return result;
  }
}

describe('getPostsFromRemote()', () => {
  it('should return posts of the group from remote', async () => {
    PostAPI.requestPosts.mockResolveValue({ data: { posts: postsOfGroup3 } });
    const result = await postService.getPostsFromRemote({ groupId: 3 });
    expect(result.posts).toBe(postsOfGroup3);
  });
});

Replace dependecies module with mock

// utils.js
export const fn1 = () => {};

// doSomeThing.js
import { fn1 } from './utils';
export default function doSomeThing() {
  // ...
  fn1();
  // ...
}

// doSomeThing.test.js
import { fn1 } from './utils';
import doSomeThing from './doSomeThing';

jest.mock('./utils');

it('should call fn1', () => {
    doSomeThing();
    expect(fn1).toHaveBeenCalled();
});

Coverage

test coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs.

Coverage report

Coverage detail

Best Practice

Unit tests are isolated and independent of each other

• Any given behaviour should be specified in one and only one test
• The execution/order of execution of one test cannot affect the others

:(

const store = new Store();
it('should append object', () => {
  store.append({id: 1});
  expect(store.getById(1)).toBe({id: 1});
});

it('should remove object', () => {
  store.remove(1);
  expect(store.getById(1)).toBeNull();
});

:)

it('should append object', () => {
  const store = new Store();
  store.append({id: 1});
  expect(store.getById(1)).toBe({id: 1});
});

it('should remove object', () => {
  const store = new Store([{id: 1}]);
  store.remove(1);
  expect(store.getById(1)).toBeNull();
});

Unit tests are code too.

• They must meet the same level of quality as the code being tested.
• They can be refactored as well to make them more maintainable and/or readable.
• They should be review first when applying a code review.

Unit tests are lightweight tests

• Repeatable
• Fast
• Consistent
• Easy to write and read

Make your tests:

• Readable
• Maintainable
• Reliable

:(

expect(result === obj).toBe(true)

:)

expect(result).toBe(obj)

:(

expect(result.length).toBe(2)

:)

expect(result).toHaveLength(2)

:(

const result = store.getById(1);
expect(result.id).toBe(1);
expect(result.name).toBe('Object 1');
expect(result.group).toBe(2);
expect(result.type).toBe(3);

:)

const result = store.getById(1);
expect(result).toBe(obj1);

:(

store.append({id: 1, name: 'Object 1', group: 2, type: 3});
store.append({id: 2, name: 'Object 2', group: 2, type: 3});

:)

store.append({id: 1});
store.append({id: 2});

:(

store.append(obj);
expect(store.items.find(o => o.id === 1)).toBe(obj);

:)

store.append(obj);
expect(store.getById(1)).toBe(obj);

:(

it('should return 100 if type is 1 and 200 if type is not 1', () => {
  const obj1 = {id: 1, type: 1};
  const obj2 = {id: 2, type: 2};
  const obj3 = {id: 3, type: 3};
  [obj1, obj2, obj3].forEach(o => {
    if(o.type === 1) {
      expect(getPrice(o)).toBe(100);
    } else {
      expect(getPrice(o)).toBe(210);
    }
  });
});

:)

it('should return 100 when type is 1', () => {
  expect(getPrice({id: 1, type: 1})).toBe(100);
});

it('should return 200 when type is not 1', () => {
  expect(getPrice({id: 1, type: 2})).toBe(200);
});

Test Driven

Test first.

life-cycle

Why use TDD?

• Change the way of thinking.
• Setup a tiny enviorment for development and debug.
• Don't have to run entire application to verify code.

Always use TDD?

NO

Don't use TDD unless it makes you feel good and confident.

CI

Tools

• VS Code - Jest Plugin
• VS Code - Wallaby.js Plugin
• ESLint plugin for Jest
• Jenkins/Gitlab

Reference

• Book: Effective Unit Testing

• A guide to unit testing in JavaScript

• 5 Tips for Writing Great Javascript Unit Tests

• Test Driven Development (TDD): Best Practices Using Java Examples

• Jenkins and Gitlab integration

• Gitlab Coverage Report

众所周知，在团队中统一代码风格是一件很重要但实践起来却非常困难的事情。在过去，我们为了实现整个项目代码风格的一致，需要制定一套冗长的规范，要求团队每个成员阅读并按照规范来编写代码，这使得每个新成员需要一个很长的学习周期才能比较好的融入团队。同时，对新成员而言，一个陌生项目的初始化和各项环境配置也是一件非常麻烦的事情，需要较高的学习成本。

为了解决这些问题，很多工具应孕而生，例如：jslint、eslint、stylelint、editorconfig…… 但由此带来的另外一个问题就是，这些东西本身也是有学习成本的。虽然新成员不再需要再阅读冗长的规范文档了，他们仍然需要学习这些工具的配置和使用。那么有没有一种办法，可以让新成员无需学习这一切，直接上手新项目呢？

有，而且非常简单！用我们所熟悉的 WebStorm 就可以轻松实现。当然其他 JetBrains IDE 也是一样的，这里介绍的方法同样适用于：IntelliJ IDEA、RubyMine、PhpStorm、AppCode、PyCharm、CLion 和 Android Studio。

项目配置

WebStorm 项目配置由一系列的 xml 文件组成，位于项目根目录下的 .idea/ 目录。 在 WebStorm 中，许多设置项都是能够只对特定项目生效的。当你在设置界面上看到这行小字的时候 这就代表你在这个界面上的做的所有设置都只对当前项目生效，并且会以 xml 文件的形式存储到 .idea/ 目录中。这意味着，如果合理利用的话，我们就能够在团队成员间通过版本控制系统来共享这些配置。新人接手项目时，无需关心此项目原先的代码风格，只需一个快捷键便可将代码整理成统一的风格。新人只需几分钟便可完成整个开发环境的搭建。

对我们而言，以下是比较重要的一些配置：

代码风格 Code Style

首先，创建一套自己的代码风格配置，大部分人都有自己的一套风格配置了。如果没有的话，WebStorm 除了默认方案之外，还有两套预设可供选择

接下来，将 Code Style 的 schema 设置为 Project

点击 OK，然后 BOOM!!! 配置文件出现了 .idea/codeStyleSettings.xml

运行/调试 Run/Debug

没错，这个功能的配置也是可以共享的

只要勾选 share 选框即可

点击 OK，相应的配置文件已经安静的躺在 .idea/runConfigurations 目录中了

启动任务 Startup Tasks

同样是一个 share 选框，在这里可以找到
配置文件为 .idea/startup.xml

语言和框架 Languages & Frameworks

选择当前项目所使用的 ECMAScript 版本

配置保存在 misc.xml 中。

文件监视 File Watchers

这个无需额外配置，所有的 File Watcher 都会自动被添加到 .idea/watcherTasks.xml 当中。

比较常用的就上面这些了，其他的大家可以自行摸索。

添加 .gitignore 文件

相信不少人刚接触 WebStorm 的时候，都有过将 .idea/ 目录下的文件提交到 git 上，导致 WebStorm 错乱而痛不欲生的经历。为了避免这种问题的发生，不少人都粗暴地将整个 .idea/ 目录忽略掉了。

一开始我也很纳闷，为什么 WebStorm 要将整个项目的所有配置放在项目根目录下，让大家一个不小心就提交上去出错呢？直到有一天，我通过 ignore 插件生成了一份针对 WebStorm 的 .gitignore 文件，我发现插件生成的规则，并不是简单的将整个 .idea/ 目录排除在外，而是有针对性的排除掉了一些用户私有配置文件，而保留了所有可以提交到 git 上但又不会导致 bug 的配置文件。我恍然大悟，原来 .idea/ 目录下这些文件，就是用来让你在团队成员间共享的！只不过前提是你需要搞清楚，哪些文件可以提交，哪些不可以。

只要有一份合理的 .gitignore 文件，.idea/ 目录中的文件也是可以提交的！而由于有 ignore 插件的辅助，这一切也非常简单。

方案1 使用 ignore 插件生成配置

安装 ignore 插件

使用插件新建一个 ignore 文件

创建时会让你选择模板，搜索并勾选 JetBrains 模板，点 Generate

方案2 使用 gitignore.io 生成配置

打开 gitignore.io。

输入 JetBrains 点击创建，获得配置文件。

方案3 复制这份配置

# Created by .ignore support plugin (hsz.mobi)
### JetBrains template
# Reference: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839

# User-specific stuff:
.idea/**/workspace.xml
.idea/**/tasks.xml
.idea/dictionaries

# Sensitive or high-churn files:
.idea/**/dataSources/
.idea/**/dataSources.ids
.idea/**/dataSources.xml
.idea/**/dataSources.local.xml
.idea/**/sqlDataSources.xml
.idea/**/dynamic.xml
.idea/**/uiDesigner.xml

# Gradle:
.idea/**/gradle.xml
.idea/**/libraries

# CMake
cmake-build-debug/

# Mongo Explorer plugin:
.idea/**/mongoSettings.xml

## File-based project format:
*.iws

## Plugin-specific files:

# IntelliJ
out/

# mpeltonen/sbt-idea plugin
.idea_modules/

# JIRA plugin
atlassian-ide-plugin.xml

# Cursive Clojure plugin
.idea/replstate.xml

# Crashlytics plugin (for Android Studio and IntelliJ)
com_crashlytics_export_strings.xml
crashlytics.properties
crashlytics-build.properties
fabric.properties

提交配置文件

最后一步，只要将上述 .gitignore 文件以及 .idea 目录下没有被忽略掉的文件提交到 git 上就行了。

验收一下成果，重新 git clone 一次这个项目，观察各项配置能否正常同步。

完成之后，去泡杯茶，或者咖啡休息一下吧。

find 命令

# 找到 src/ 目录中的 file.txt 文件
find src/ -name 'file.txt'

# 找到 src/ 目录中的所有 txt 文件
find src/ -name '*.txt'

-exec 参数

以复制所有找到的文件至 dest/ 目录为例，命令如下

Mac 下

find src/ -name 'file.txt' -exec rsync -R {} dest/ \;

Linux 下

find src/ -name 'file.txt' -exec cp --parents {} dest/ \;

先上最终效果

开启方式

在终端中输入命令

defaults write com.sample.yourApp WebKitDeveloperExtras -bool true

其中com.sample.yourApp是你要调试的程序的Bundle identifier。

如果不知道值是多少，可以在应用程序中找到你想调试的程序，点击右键=>显示包内容=>在Contents/Info.plist文件中查找CFBundleIdentifier。

自从上次博客挂掉，丢失了所有数据之后就好长一段时间没有写东西了。今天稍微折腾了一下 Windows 服务器，配置的过程中找了几篇文章，都没有看比较全面的讲解，踩坑不少，浪费了不少时间，感觉有必要做一些总结。我们一步一步来吧。

安装FTP服务

首先Ctrl+R输入control.exe /name Microsoft.ProgramsAndFeatures打开程序和功能窗口。点击启用或关闭 Windows 功能。

此时会出来一个添加角色和功能向导窗口，我们先跟着功能向导的提示，直到服务器角色这一步。

在角色列表中选中FTP服务器，然后继续跟着功能向导的提示就能完成FTP服务的安装了。

添加FTP站点

我们打开IIS管理器，右键网站或服务器名，选择添加FTP站点。

输入站点名称并选择内容目录，点击下一步。

这样就来到了绑定和SSL设置界面，绑定部分我们不需要动他，SSL部分选择无SSL。

最后，设置身份验证信息，一般我们都不开启匿名访问功能，所以身份验证这块勾选基本即可。授权方式选则指定用户，输入Windows的用户名，我这里是事先创建了一个叫做“ftpuser”的Windows用户。权限方面，读取和写入都勾选。

这样我们就完成了FTP站点的添加了。
但我们还需要设置一下Windows用户对ftp目录的访问权限，否则默认情况下非管理员帐号“ftpuser”对“c:\ftproot”目录是没有写入权限的。

配置用户权限

在“c:\ftproot”文件夹上点击右键选择属性-点击安全选项卡中的编辑-在新窗口中点添加按钮；

输入Windows用户名。

勾选完全控制选项。

这样“ftpsuer”便拥有了这个目录的写入权限。

客户端访问FTP站点

如果一切顺利的话，现在就可以在文件资源管理器里面输入 ftp://IP地址 来登录FTP服务器了，如果你有域名解析到服务器ip上的话，也可以直接访问ftp://域名来登录服务器。

只需要输入设置好的Windows用户名和密码即可。

防火墙设置

如果出现了连接不上的问题，那么可能是防火墙的原因，可以尝试暂时关闭防火墙测试一下是否能够连接。如果是防火墙的原因，编辑一下防火墙规则即可。

(转载请注明出处并保留原文链接)