Lsnsh的网络日志

Basic

Taichi（太极）是一种用于高性能数值计算的并行编程语言。它嵌入在 Python 中，其即时编译器将计算密集型任务卸载到多核 CPU 和大规模并行 GPU。

GitHub: https://github.com/taichi-dev/taichi

Install

Currently, Taichi only supports Python 3.6/3.7/3.8/3.9 (64-bit).

1
2
3
4
5

# install python
brew install python

# install taichi
python3 -m pip install taichi

Taichi Examples

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

➜  ~ ti example -h
[Taichi] version 0.8.10, llvm 10.0.0, commit 016feb38, osx, python 3.9.8

*******************************************
**      Taichi Programming Language      **
*******************************************

Docs:   https://docs.taichi.graphics/
GitHub: https://github.com/taichi-dev/taichi/
Forum:  https://forum.taichi.graphics/

usage: ti example [-h] [-p] [-P] [-s]
                  {ad_gravity,comet,cornell_box,euler,explicit_activation,export_mesh,export_ply,export_videos,fem128,fem128_ggui,fem99,fractal,fractal3d_ggui,fullscreen,game_of_life,gui_image_io,gui_widgets,implicit_mass_spring,inital_value_problem,keyboard,laplace,marching_squares,mass_spring_3d_ggui,mass_spring_game,mass_spring_game_ggui,mciso_advanced,mgpcg,mgpcg_advanced,minimal,minimization,mpm128,mpm128_ggui,mpm3d,mpm3d_ggui,mpm88,mpm99,mpm_lagrangian_forces,nbody,odop_solar,pbf2d,physarum,print_offset,rasterizer,regression,sdf_renderer,simple_derivative,simple_uv,stable_fluid,stable_fluid_ggui,taichi_bitmasked,taichi_dynamic,taichi_logo,taichi_sparse,tutorial,vortex_rings,waterwave}

Run an example by name (or name.py)

前言

在今年早些时候，参加了极客时间的前端进阶训练营，接触到了人机对战的井字棋游戏，说要写一篇博客记录一下，今天填坑来了属于是。

井字棋、或者说三子棋相信大家都不陌生，学生时代在本子上画一个“井”字和同学一起下棋，或者直接在带格子的语文作业本上下。

话不多说，我们先来看看，实现的效果：

背景

陆续升级到 MacOS BigSur/Monterey 后，电脑上装了两个虚拟机（PD、VMWare Funison），日常开发体验不好。一番取舍后，备份好数据，抹除硬盘给 MacBook 装了双系统，然后要重新装环境。

安装 OpenJDK

OpenJDK 是 Java 的开源版本，有 Oracle 构建维护的，也有其他组织或公司构建并维护的，这里选择安装 Oracle 构建的（OpenJDK builds from Oracle）。

Since September 2017, Oracle provides JDK releases under a free open source license (similar to that of Linux). Availability and community support of OpenJDK releases provided by Oracle is listed separately on jdk.java.net.

自 2017 年 9 月起，Oracle 在免费开源许可（类似于 Linux）下提供 JDK 版本。 Oracle 提供的 OpenJDK 版本的可用性和社区支持在 jdk.java.net 上单独列出。—— Oracle Java SE Support Roadmap

背景

在最近一期的「前端早早聊-大会直播」上，来自阿里妈妈的叶兮做了一期关于 《如何把 Vue2 一键升级 Vue3 - GoGoCode》 的分享，然后就接触到了 GoGoCode，看直播的时候就感觉很酷，于是迫不及待的就开始使用了

尝试转换的项目，是早期基于 Vue-CLI 2.x 搭建的，目录结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

.
├── build
├── config
├── logs
├── node_modules
├── src
├── CHANGELOG.md
├── DEPLOY.md
├── README.md
├── package-lock.json
├── package.json
├── prettier.config.js
└── tsconfig.json

前言

从第一代 DIV + CSS 正常流的排版方式，到 Flexbox 弹性盒模型，再到 Grid 的排版方式，以及最新的可以利用浏览器渲染引擎的 CSS Houdini。今天我们先来讲一下 Flexbox 弹性盒模型的基础以及如何实现常见布局，并对比传统 DIV + CSS 布局。

1. 互联网是什么？

美国国防部，ARPANET 项目，为了组建承受核弹攻击后仍能保持通信的网络；
多节点，网状结构，互相开放；
部分节点受损后，其他节点仍能以不同的路径，到达目标节点；
互联网不受任何人控制，又或者是受任何人控制，取决于规模和网络管理员，但是由于节点对外开放是性能最大化的，限制出入，不是符合常规的做法或趋势；
由于互联网的存在，轻松的跨域了地域的限制，地球两端的人，能够学习和分享对彼此可能是很有用的知识。

前言

上一篇我们讲到，webpack3.x 升级 4.x 后打包大小优化，今天讲一下 webpack 4.x（webpack 4.43.0） 的打包速度优化，其实在升级了 webpack4 之后对于打包速度就已经有了很大的提升，但是查找时间（缩小范围）、loader 处理时间（多进程）、二次打包时间（缓存）仍有可优化的空间。

打包分析

在优化之前我们需要清楚项目打包的性能情况，这里我们使用 speed-measure-webpack-plugin 插件来进行分析

webpack.base.js

1
2
3
4
5
6
7
8
9
10
11
12

+const SpeedMeasurePlugin = require('speed-measure-webpack-plugin');

+const smp = new SpeedMeasurePlugin({
+  outputFormat: 'humanVerbose'
+});

const webpackConfig = merge(baseWebpackConfig, {
  // ..
});

-module.exports = webpackConfig;
+module.exports = smp.wrap(webpackConfig);

打包看下，本次耗时 62,361 ms，列出了 Plugins 和 Loaders 具体耗时的细节：

图比较长但是基本能看出，其中耗时较多的是 vue-loader 和 ts-loader

前言

上一篇我们讲到，webpack3.x 升级 4.x 时遇到的问题、原因和解决方案，今天讲一下 webpack 4.x 的打包优化。

打包分析

在优化之前我们需要清楚项目的打包情况，npm run build 后 webpack 会将打包信息打印到终端，像这样：

能够看到有好几个文件比较大，但是并不清楚具体包含哪些模块，哪些模块适合单独提取，哪些模块不适合提取，这个时候就需要用到打包分析的工具。

前言

产品需求评审后，各自拆分任务，从 master 分支切出一个 release 分支，根据各自任务情况切出 update 或 feature 的开发分支；

开发调试或提测时，将代码 push 到远程分支，提 merge request（以下简称 mr）到 test 分支，GitLab CI 将项目代码自动构建并部署到测试环境；

测试完毕后提 mr 到 release 分支，待本次需求的开发分支都 code review 并合并后，从 release 分支提 mr 到 pre 分支，GitLab CI 将项目代码自动构建并部署到预生产环境，然后进行回归测试，有问题再从 release 分支切出开发分支进行修改，重复之前的流程。

预生产环境没问题后，从 release 分支提 mr 到 master 分支，，然后打 tag 上线，GitLab CI 将项目代码自动构建并部署到生产环境，然后进行回归测试，有问题再发版。

至此一次需求的完整开发流程就告一段落了，其中构建/部署等一些重复工作都是 GitLab CI 帮我们完成，对此一直很好奇，接下来我们就来尝试搭建一个使用 GitLab CI 的项目。

背景

在 vue-cli3 发布之前，使用 vue-cli2 构建的 vue 项目是基于 webpack3.x 的，伴随着项目的版本迭代，功能逐渐增多，文件也逐渐增多，打包时间从最初的 4.5 分钟，最久的时候 17 分钟。

因为使用 ts 的缘故，每次打包 ts-loader 需要进行类型检查，导致耗时剧增。权衡利弊下，将 ts-loader 的类型检查禁用后（transpileOnly 选项设置为 true），打包时间锐减到 1 分钟。

随着时间的推移，项目依赖逐渐落后，打包时间也到了 2.5 分钟，恰逢 webpack4 对于打包性能的提升，于是就有了这篇升级日志：

起步

整体思路：

1. 升级项目依赖
2. 跑通开发环境打包
3. 跑通生成环境打包

升级项目依赖

一开始的项目依赖升级的思路是，先升级 webpack 到最新的版本，然后逐步升级 loader 、plugin 、babel 等依赖。但是基于之前其他项目升级 webpack4 的经验，发现逐步升级会耗费一部分时间在新旧依赖的问题上，于是决定激进一点，使用 ncu 一次性将 package.json 中包含的项目依赖升级到最新版本，考虑到不确定性，可以选择性的修改 package.json 不升级某些依赖，比如主要版本号有变动的依赖（eg: 0.x.x => 1.x.x）。

1
2
3
4
5
6
7
8
9
10
11
12
13

# 安装 npm-check-updates
npm i -g npm-check-updates

# 检查项目依赖的版本与最新稳定版本，列出清单（beta版本可能不会列出来）
ncu

# 将 `package.json` 中包含的依赖的版本号，更新到最新
ncu -u

# 删除旧的依赖，安装新的依赖
rm -rf node_modules
rm package-lock.json
npm i