1. 讲故事：家里有俩小爱音响，小孩喜欢睡前听故事，不过当前版本的小爱童鞋说实话挺不聪明，几乎不具备瞎扯编故事的能力。所以只能打开如豆包之类的 APP 满足此需求；
2. 查资料：以前啊，找个信息基本上只能靠搜索引擎的框框，人肉提取总结其反馈的结果。现在呢，有事问 AI…尽管结果可能不那么准确，但大多数时候还是靠谱的；

而且问 AI 还能有效避免广告的干扰，这要比百度一下体验好太多。没有广告影响，恐怕主要也是现阶段 AI 工具变现手段厂商们还没怎么想明白。不过这并不重要，能白嫖就赶紧用起来…

但，AI 并不是万能的

至少现阶段、乃至未来 3、5 年内，这并非只是技术上的瓶颈所致。我认为在 AI 完全取代人力之前，“伦理”问题一定要先解决掉，这可能就涉及到立法层面了，尤其是对于特殊的地区。

当然，本文并不打算扯这些有的没的。我想从编程这块，聊聊我认为为什么 AI 不是万能的。如你正好高度依赖 AI 工具去写码，这或许值得探讨…

前两天，我把一工程的gulp由 v4.x 升级到了 v5.x，然后你猜怎么着？在处理图片压缩的任务时，gulp-imagemin扔出了：Minified 0 images (gulp-imagemin 9.1.0)的提示…严格来说，这并不是错误！
起初，我以为是gulp-cache这货所致，于是各种排查。甚至清理了缓存，不过依旧没什么卵用…

import gulp from "gulp";import cache from "gulp-cache";gulp.task("clear", () =>  cache.clearAll((error) => {    console.warn("clearCache error", error);  }),);

然后，我就开始问claude.ai和Cursor（自带对撩）。反正吧，它们就是不承认自己真的不知道，就各种猜测，然后呢我根据线索逐个排查，都快把人整崩溃了还是不行。放弃问 AI 后，我去该项目的github issues顺利找到了解法…

通过这个小 Case，我意识到对于代码查错而言，先问 AI 并不是最优解，甚至可能是最差的。毕竟市面上新发布的工具都充满各种噱头，总让人误以为那是最优途径，于是真遇到问题，就顺势“偷懒”掉坑里了…这些工具能发挥的威力，跟正确提问和其训练的数据密不可分。

这里没有调侃的意思，只是说对于特定场景，AI 并不是万能的。如果在项目遇到问题后，第一时间 Google 一下可能更合适，当然如果用的开源内裤，直接去根上找也是极好的选择…

对此，我在这篇文章里也提到这个观点

如何发挥 AI 的效用

对于具体的编程问题，尤其是纠错方面，AI 很可能会给出干扰结果。这主要是因为训练数据更新不会那么及时，当它不知道时，也并不会谦虚的跟你讲！

而在以下这些场景，我认为能够非常有效的发挥 AI 效用，并能让人获益匪浅：

• 1、总结提效：这没什么好说的，现在是个 AI 主打的应用，都具备这方面能力。当然不同的大模型训练重点不同，最终效果也会不同！对于普通用户而言，只需用对、用好足矣；
• 2、寻求意见：当你有一个模糊的想法，但自己不太能捋清楚，此时可以尝试跟 AI 聊下。就想象力这块而言，AI 还是比普通人强太多，毕竟主流大模型的阅读量都是超出常人的；
• 3、探索新知：这是我今年以来，最常用的点。面对未知，AI 总能从已知中找到合适的途径和信息，从而避免人肉学习走弯路，这在快速入门一项技能或学习一个新的领域非常有效。

不同领域/场景下的姿势

👇 以下内容分享自一段先前看到的干货：AI 降本增效，一开始最好简单粗暴

差生文具多，如果要做优等生，先得抛弃对工具无休止的追逐。
哪怕是 AI 博主，也应该回归基本，主动熵减，把日常使用的 AI 工具控制在 20 个以内。
我的工作场景主要围绕 AI 职场办公，智能体开发和媒体制作。如果按付费意愿，真正会坚持用的会有以下几个：（无广）

1. 主力 AI 模型

GPT+Claude

平替：豆包+文小言（移动版）+kimi

GPT 越来越有被 Claude 替代的趋势，尤其是代码。但是 GPTs 还是增强了我的使用粘性。豆包的 TTS 语音国内无法被替代。文小言有一些我喜欢的功能，比如信息聚合订阅。

2. 主力 IM

飞书

平替：Notion+企微

我知道 Notion 很强。但是鉴于复杂的操作+国内网络不稳定+数据安全是真不太喜欢用。
创业以来我觉得最值得投入学习时间的并不是任何一款 AI 软件，而是飞书本身。好的 SaaS 就是最佳实践的产品化。企微是出于私域+客户对公不得不用。

3. 数据分析

Excel+GPT+各平台数据看板

平替：飞书多维表单

Excel 没有平替。AI 只是帮我解锁高阶功能，比如 VBA 和宏。多维表单的插件生态值得投入时间学习。

4. 设计

Midjourney+ideagram

平替：Canvas+稿定设计+佐糖

比起 Mj，Ideagram 的出图更具场景感，配合简单工具出海报+商图+封面+运营位都很方便。

5. PPT

PPT+islide 插件+彩璇 PPT

平替：Gamma，aippt

目前没有同时满足不要钱、支持定制模板、不科学上网、智能还可控性强的方案。但是 PPT+islide 已经增效超过 50%。Gamma 是应急神器。彩璇 PPT 比较小众，是一个方便做课件分享+编辑的平台，对咨询师/老师有刚需。

6. 剪辑

剪映（含 AI）+即梦 AI

初学者够用，为了省事就用字节系的。

7. 文本创作

飞书文档+flomo+GPT

平替：记事本

简单点好。如果开发一个支持 flomo api 导出直接 AI 生成标题/思路/文章大纲的工作流会不会有需求？

8. 智能体开发

Coze/Dify

平替：百度智能体

目前还在钻研工作流场景。已经做了 20 多个 Bot。Coze/Dify 各有千秋，百度则是打通了支付环节和数字人形象的交互。待继续钻研好和大家分享。

9. 代码辅助

Cursor+Claude

平替：字节豆包 Marscode

10. 工作流编排

Coze+飞书+各类 Github（开源项目）

通过飞书机器人平台把各类 BOT 接入到飞书群里。实现在 IM 办公软件中使用自己调试过的 AI 数字员工。

自从Cursor出来之后，就逐渐从VSCode迁移过来了。本质上这俩工具就是一个玩意，只是前者针对 AI 编程全链路进行了深度优化…感兴趣的小伙伴可以看下这篇文章

之前简单写过一篇vscode 中调试 node.ts的文章，有需要可以结合起来看。

问题和排查经过

当我按claude的建议添加了配置后：

{  "version": "0.2.0",  "configurations": [    {      "type": "node",      "request": "launch",      "name": "Debug Next.js API",      "runtimeExecutable": "pnpm",      "runtimeArgs": ["run", "dev"],      "env": {        "NODE_OPTIONS": "--inspect"      },      "console": "integratedTerminal"    }  ]}

我发现控制台启动时有一条显眼的提示：Starting inspector on 127.0.0.1:9229 failed: address already in use

另外，编辑器添加断点的地方还有：Unbound breakpoint：Some of your breakpoints could not be set. If you’re having an issue, you can troubleshoot your launch configuration.

话说claude不是号称现阶段最聪明、最好用的 AI 编程大模型吗，难道连这点小事都搞不定！？于是我又分别问了chatGPT和豆包

豆包的回答倒是干脆利落，不过结果却是一本正经的胡说八道…

我又多给了它几次机会，也试图把我的问题再描述清楚，直到它开始让我安装npm包去解决，我就不忍再直视了！
然后同样的话又再次问了chatGPT，不过同样没有正确的答案…

我突然意识到，对于大模型第一时间不能给出的正确响应，再继续追问，能问到正确答案的概率也不高（因为往往给出一个不正确的回答之后，再继续问就是针对那个不正确的点，然后各种发散就远离了最初的目的）。特别是越到最后，其幻觉就越明显，就像人一样要承认自己不知道对 AI 来说也挺难呢。

后来，我把同样的关键词组合扔给了谷歌，也确实找到了一些更相关的帖子，特别是在stackoverflow上。我本以为事情就完了，没想到还没这么容易…

一方面不同Nextjs版本可能配置不同，另外提问者起码都是 6 个月之前的情况，看了半天inspector被占用端口的问题算是搞明白了，但是仍然不能 Debug。最终在全球最大的同性交友网站找到了正确姿势：Debugger not binding breakpoints in VSCode

关于 Nextjs Debug 的相关资料

• https://nextjs.org/docs/pages/building-your-application/configuring/debugging#debugging-with-vs-code
• https://stackoverflow.com/questions/69513546/debugging-nextjs-api-endpoints-using-vscode
• https://github.com/vercel/next.js/issues?q=Unbound+breakpoints
• https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_breakpoints

正确有效的配置

{  "version": "0.2.0",  "configurations": [    {      "name": "Next.js: debug server-side",      "type": "node-terminal",      "request": "launch",      "command": "npm run dev",      "sourceMaps": true,      "sourceMapPathOverrides": {        "/turbopack/[project]/*": "${webRoot}/*"      }    },    {      "name": "Next.js: debug client-side",      "type": "chrome",      "request": "launch",      "url": "http://localhost:4455",      "webRoot": "${workspaceFolder}",      "sourceMaps": true,      "sourceMapPathOverrides": {        "/turbopack/[project]/*": "${webRoot}/*"      }    }  ]}

并且，没有折腾 TypeScript 以及 Next Config 的必要。

所有靠玄学可以起作用的，到我这都不好使。最终有效的只有一句：

// 通过 --turbo 启动，精准验证必须加这句"sourceMapPathOverrides": {    "/turbopack/[project]/*": "${webRoot}/*"}// 通过 webpack 启动(注意：此处笔者并没有试验其有效性，仅照搬github某comment)"sourceMapPathOverrides": {  "webpack://_N_E/*": "${webRoot}/*"}

关于如何有效解题

1. 用对工具：专业的事情，用专业的工具解决，如果没有那就造一个；
2. 用对语言：中文不行，换英文试试。特别是对于编程这个领域，毕竟全球码仔都用这门语言干活，这没啥好说的；
3. 经验判断：这个很考验工程师的“道行”，当然也没有特别的捷径。只有多看、多实践、多积累才能形成精准治疗的能力；
4. 及时放手：如果花了很多时间仍然没有答案，不妨暂时放手，这能立刻缓解身心健康。然后尝试去专业论坛提问，相信时间的力量；

最后，我想分享一段跟编程强有关的话，来自 AI 大模型爆🔥的这段时间。大意是说未来最好的编程语言，是英语，而不是什么 PHP、Rust 等，与其花时间追风，不如再把英语提升一下。闭上眼镜，用心体会，是不是很有道理呢～

如果你之前看过本站《DNS 玩法知多少》这篇文章，也正常搭建了本地 DNS 服务，但是遇到国内某些网站访问速度变慢的问题，那本文可能会给你一些解决思路。

最近发现针对京东、淘宝、阿里云乃至必应搜索使用本地 DNS 服务访问非常的慢，于是简单做了下背调：发现 SmartDNS 对于拥有国际业务的站点返回的都是国际 IP。比如下图的必应，可以看到通过 SmartDNS 返回的是13.107.21.200，而这个 IP 通过ip138查到归属地在美国华盛顿的微软云那里，因此国内正常访问这个 IP，能快才怪了…

而类似的情况也在前一阵发生，只是当时没有意识到会是这个问题：正常访问www.aliyun.com，总是会跳到www.alibabacloud.com
由于没有全局代理、浏览器也都正常，所以当时觉得很奇怪。但毕竟不是经常用阿里云，所以就没纠结。直到最近一直用必应老出问题才回过神来思考这个问题，后来改成DNSPod后，立马正常了，查了下结果发现指向了北京…

一些补充说明和设置更新

声明

假设默认情况下，不会一直开着全局代理，也没有精妙的所谓规则设定，因为这种情况不会出现访问延迟的现象，除非代理本身有问题。
因此，如果读者习惯开全局或者配置了针对性的进出口规则，那以下内容就不用看了！

macOS 关于 53 端口的问题

如果通过 docker 启动，发现因为 53 端口占用，无法启动，请移步这里

调整姿势

因为直接使用 SmartDNS 作为本地 DNS 服务，一定程度上必然会出现上文所述的问题！
尽管在之前那篇文章有提到通过dnsmasq-china-list进行内外分离，但由于当时配置不当造成查询错误…

如果不想太麻烦，最简单快捷的方法就是，默认情况一律走国内大厂的公共 DNS 解析服务。但需要注意的是阿里公共 DNS 将在 2024 年 9 月末进行限速，这是先前刷smartdns issues发现的，所以如果严重依赖阿里家的这项服务，需要注意一下！

smartdns 配置

在原来那份配置下，通过分析 docker logs 发现针对内外分离的规则没有生效…

result: cn.bing.com, client: 192.168.10.1, qtype: 1, id: 51332, group: default, time: 0msrequest: cn.bing.com, qtype: 1, id: 46522, group: defaultresult: cn.bing.com, id: 0, index: 1, rtt: -0.1 ms, 204.79.197.200result: cn.bing.com, id: 0, index: 2, rtt: -0.1 ms, 13.107.21.200

经过分析和实测，整理出以下核心配置 👇

smartdns 与 dnsmasq-china-list 最终整合配置

bind [::]:53server-name smartdnslog-num 5log-size 2Mlog-level warnlog-console yesspeed-check-mode none# 启用双栈优选dualstack-ip-selection yes# 域名预先获取功能prefetch-domain yescache-size 8192# ----- Default Group（解析国外） -----server 1.0.0.1server 8.8.4.4server 9.9.9.9server-tls 1.1.1.1 -bootstrap-dnsserver-tls 8.8.8.8 -bootstrap-dns# ----- Domestic Group（解析国内） -----## DNSPodserver 119.29.29.29 -group domestic -exclude-default-group## 阿里server 223.5.5.5 -group domestic -exclude-default-groupserver 223.6.6.6 -group domestic -exclude-default-group## 114 DNS、使用 TCP 查询server-tcp 114.114.114.114 -group domestic -exclude-default-groupserver-tcp 114.114.115.115 -group domestic -exclude-default-group## 腾讯 DNSPod IP DoTserver-tls 1.12.12.12:853 -group domestic -exclude-default-groupserver-tls 120.53.53.53:853 -group domestic -exclude-default-group# 分流配置conf-file /etc/smartdns/domestic/accelerated-domains.china.domain.smartdns.confconf-file /etc/smartdns/domestic/apple.china.domain.smartdns.conf

配置文件通过make SERVER=domestic SMARTDNS_SPEEDTEST_MODE=tcp:80 smartdns-domain-rules生成，可以考虑把dnsmasq-china-list全部下载到本地维护，定期 pull-make

注意：config-file 后不能加-group domestic，否则规则无效，这在上一篇文章中记录有误，此处特别提醒！

好了，以上就是SmartDNS 本地应用的一些使用体验和更新说明，祝大家玩的开心 🏄

当然，如果只是为了图省事，亦或需要在任何地方都能编辑或访问，那公有云方案确实是比较合适的选择。
但是，如果仅仅是为了记录自己的日常、并且有较高的私密性要求，那本地知识库搭建你绝对有必要了解一下。

先说结论吧：

• 优势：
  • 绝对私密且没有账户密码管理负担；🍐
  • 不用担心平台跑路或者不维护了（实际上很多公有云平台都不保险，特别是国内的互联网环境下）；🏃
  • 自由创作，写啥都可以，不用担心说了不恰当的话被封号；🙊
  • 自由定制（需要一些技术能力），需要啥功能自己自足，不需要办卡充会员；🙅
• 劣势
  • 只能自己电脑或私服访问，是否需要 Everywhere 取决你自己；
  • 有一定技术门槛，但非常有限；

缘起

大概 10 年前吧，我第一次接触Markdonw这种玩意，然后瞬间被以这种形式记录工作、日常的姿势深深吸引。包括后来搭建独立站，内容的载体都是一个个.md文件，乃至你现在看到的这篇文章，原始内容仍然是…后来由于工作和生活需要，我基于 vuepress 1.x 在本地搭建了一个知识库，通过Github托管内容。

这期间，由于 Vue3 的发布，很多基于 V2 版本的类库都出现了问题，比如当nodejs升级了，就发现原来本地的服务就跪了。再后来，官方搞了个 vitepress ，然后就没有然后了（vuepress 被正式晾在了一边，尽管现在有社区维护，但已经不好再作为第一选择了）！

由于本人技术出身，所以对于这类问题基本上都能处理，然而对于框架的新特性或者想要扩展一些额外的功能，就略显尴尬了…特别是到了今年，问题尤为明显。直到前两天，因为 tailwindcss库导致和vuepress某个依赖发生冲突然后直接启动不了了，所以就怒换了：Docusaurus

因为实在不想再继续为这老古董消耗时间和精力去折腾了，docusaurus 提供知识库基础能力的同时，还额外提供了比其他方案更多的优势

知识库套件

在换docusaurus之前，我想过升级成vitepress，因为在这种事情上，越少折腾越好。但后来发现：把 vuepress 迁移到 vitepress 并不容易

同样是体力活，索性一把换到位。于是最终选择了React解决方案

Docusaurus 指南

抱歉，没有这趴！毕竟官方文档已经写的很详细了，这里确实没必要再做搬运工…😏

从 Vuepress 的迁移

1、通过 create-docusaurus 生成目标站点

nlx create-docusaurus@latest MarsNotes classic --typescript

注意：这里的nlx是全局antfu ni的命令，没有装ni的可以根据自己需要换其他的，比如：yarn create xxx效果是一样的。当然这一步官方有详细的指北

额外的依赖，建议都安装一下：

ni @docusaurus/plugin-ideal-image @easyops-cn/docusaurus-search-local docusaurus-plugin-image-zoom

插件的配置和作用，对应到 github 的 readme 都有，请自行取用…

2、配置说明

把 vuepress 迁移到 docusaurus 比我想像中要容易的多，因为原来的知识库目录层级较多，有好几个大的分类。在 vuepress 托管时，愣是写了一大托node-fs操作代码，用来生成目录树结构：

import fs from "node:fs";import path from "node:path";/** * 返回边栏数据结构体 * @param group 组标题 * @param collapsable 是否折叠 * @param children 文章标题集 */export const SidebarGroupItem = (group: string, collapsable: boolean = true, children: any[] = []) => {  return {    title: group,    collapsable: collapsable,    children: children,  };};/** * 根据本地文件层级及文件名，动态生成树状边栏数据 * @param category 分类名称 * @param catePath 分类文件根目录 * @param group 分组 * @returns */export const genSiderbarGroups = (category: string, catePath: string, group: any[] = []) => {  if (!fs.existsSync(catePath)) {    console.error("catePath not exists:", catePath);    return null;  }  return fs.readdirSync(catePath).reduce(    (bars, file) => {      const currentFile = path.join(catePath, file);      const urlPath = currentFile.split(category + "/")[1];      if (fs.statSync(currentFile).isFile() && path.parse(currentFile).ext === ".md") {        const file = urlPath.slice(0, -3).replace(/README$/g, "");        path.parse(currentFile).dir.endsWith(category) ? bars[0].children.push(file) : group.push(file);      }      if (fs.statSync(currentFile).isDirectory()) {        const pathName = path.parse(currentFile).name;        const curGroup = SidebarGroupItem(pathName);        urlPath.split("/").findIndex((item) => item === pathName) > 0 ? group.push(curGroup) : bars.push(curGroup);        genSiderbarGroups(category, currentFile, curGroup.children);      }      return bars;    },    [SidebarGroupItem("概述", false)],  );};

vuepress 1.x 动态目录树构建

import path from "node:path";import { SidebarConfig4Multiple } from "vuepress/config";import { genSiderbarGroups } from "./shared";const Categories = ["cate1", "cate2", "cate3", "cate4", "cate5"];export const Sidebar4ZH: SidebarConfig4Multiple = Categories.reduce((bars, category) => {  const categoryRootPath = path.resolve(__dirname, `../../../${category}`);  bars[`/${category}/`] = genSiderbarGroups(category, categoryRootPath);  return bars;}, {});

但发现docusaurus 对动态目录树是原生支持的，它的sidebars.ts里有一段注释：”By default, Docusaurus generates a sidebar from the docs folder structure”

这就不要太爽好吧，所以在 docusaurus 配置知识库的目录树就异常简单了

import type { SidebarsConfig } from "@docusaurus/plugin-content-docs";const sidebars: SidebarsConfig = {  cate1Sidebar: [{ type: "autogenerated", dirName: "cate1" }],  cate2Sidebar: [{ type: "autogenerated", dirName: "cate2" }],  cate3Sidebar: [{ type: "autogenerated", dirName: "cate3" }],};export default sidebars;

其中，cate1、cate2…这些，对应 docs 目录中的其他大类目录名称
个别细节部分，比如知识库首页就需要自己根据需要定制了，入口：src/pages/index.tsx

如此，就基本完成迁移后的配置了！

3、一点优化

如果你打算通过以上方式构建本地知识库，通常情况下你应该并不希望一直开个黑窗口。所以此时可以再做些小优化：

• 后台运行：通过pm2把docusaurus start放在后台；
• 反向代理：选个你喜欢的域名，改本地 hosts，使其支持通过这个域名访问到 docusaurus 服务，这一步可以通过nginx搞定

pm2 的应用启动配置

{  "name": "my-wiki",  "script": "pnpm run build && pnpm run serve",  "cwd": "./my-wiki"}

注意这里启动命令是run serve而非run start。是因为通过构建后运行，docusaurus 会做服务端渲染。不过有个问题就是当你再新建或改动旧 MD 文件后，站点并不会更新，当然这个很好理解啦。所以如果需要时时更新，主要需要通过run start启动（docusaurus start）

上 Git

这点非常重要！

原因也很简单，因为你并不希望可能某天由于电脑进水了，然后资料丢失吧～
所以，选个你喜欢的 git 托管服务，创建一个private仓库，把本地知识库保存在云端就完事了。

通过 git 托管，还有一个好处，就是你能看到自己的创作记录，当然这个实际效果取决于自己的commit习惯。

对于技术人来说，这简直不要太滋润。如果是企业内部服务，也是可以考虑这么搞，正真的降本增效…
如果啊，有机会，试试这种本地知识库服务吧

有关于时间的快和慢

通常而言，让我们能感觉时间过的快，有这么几种情况：

• 专注于感兴趣的事情：比如打电游这种，会让你神不知鬼不觉的花费很多时间而不自知；
• 和亲朋好友愉快相处：和亲密的人在一起，分享快乐、交流情感，愉快的氛围会让时间在不知不觉中飞逝；
• 处于紧张刺激的状态：像是参加一场激烈的比赛、进行冒险活动或者面临紧急的任务；
• 旅行和探索新地方：在陌生的环境中，充满新奇的事物吸引着我们的注意力，使得时间迅速过去；

而，慢的感觉主要有以下这么几种情况：

• 处在不适的环境中：比如被迫参加自己不喜欢的活动，又或者身处恶劣的外部环境之中（冷/热/酸/臭）；
• 身体不适或空虚无聊：生病、受伤、孤独时，身心均承受着不同等级的痛苦，比如牙疼发作时，每一秒都让人难以忍受；
• 等待重要结果：对待不确定性，通常内心会产生焦虑，不同程度的期待会让每一分钟都显得格外漫长；
• 重复单调的任务：长时间进行简单重复的工作、劳动等，会让人产生烦躁的感觉；
• 分离和思念时：与亲人、爱人分离，满心的思念会让每一天都显得格外漫长；

不知道你有没有发现，这俩之间有什么共性和关联？

先聊聊我的结论：

• 快：核心在于足够聚焦，这种情况下通常没有心力去想别的东西；
• 慢：与快正好相反，这种身在一方心在另一方的作用，会让人过度关注到了时间本身；

贤者时间

通过以上分析可以有个基本结论，时间不够用的原因在于：我们往往在有限的时间内做了“快感”操作。而这种操作，通常是被认为对感兴趣的话题吸走了注意力，导致神不知鬼不觉的消耗了原来本该做事情的时间。

另外，会有感觉不够用这种想法，说明自己对时间有珍惜意识。便于理解，我这里用贤者时间来比喻这一现象。比如刷短视频：

一个接一个，爽是真的爽，只是回过神才发现，手机没电了，时间也没了，最后自觉悔不当初，于是愤愤卸掉 APP

奶头乐的事情做太多，外加一番贤者思考，就容易产生：为什么总感觉时间不够用 这个问题。

科学的规划

感觉时间过得快与慢的本质区别在于个人的心理状态和所从事活动的性质。

• 当感觉时间过得快时，通常是因为我们全身心投入到了能带来愉悦、满足或具有高度吸引力的活动中，我们的注意力高度集中，大脑处于活跃但享受的状态。
• 而感觉时间过得慢，往往是由于我们处于焦虑、无聊、痛苦、不舒适或者被迫从事不喜欢的事情等负面或低刺激的情境中，大脑对时间的感知变得更为敏感和漫长。

要科学地规划自己有限的精力，可以考虑以下几点：

1. 明确目标：确定长期和短期的目标，这能为行动提供方向；
2. 任务分类：将任务分为重要紧急、重要不紧急、不重要紧急和不重要不紧急四类。优先处理重要紧急的任务，合理安排重要不紧急的任务，尽量减少不重要紧急和不重要不紧急任务对精力的消耗。比如，工作中的重要项目是重要紧急的，自我提升的学习计划可能是重要不紧急的；
3. 合理安排休息：不要连续长时间工作或学习，适当的休息能恢复精力，提高效率；
4. 结合自身生物钟：了解自己在一天中不同时间段的精力状态，将重要和复杂的任务安排在精力充沛的时段；
5. 保持健康的生活方式：包括充足的睡眠、合理的饮食和适度的运动，这有助于维持良好的身体和精神状态，为精力提供基础保障；
6. 避免多任务并行：专注于一项任务，完成后再进行下一项，这样能提高效率，减少精力的分散；
7. 定期反思和调整：回顾自己的精力分配情况，总结经验教训，根据实际情况调整规划；

人生的长度有限，然宽度无限，但也大可不必宽的太厉害，享受必要的过程才是核心。最后，祝愿读者都能在预算一定的情况下，成为优秀的时间管理大师。

对于我来说，任何时候更换路由器，第一件事就是进入路由器管理后台手动更换运营商提供的 DNS 服务，原因很简单：

1. 上网较慢：通常运营商提供的 DNS 都是某个地区特定线路的节点，效果嘛只能说可以用；
2. 安全性差：如果说网慢一点（在忍耐范围内）也还能接受，但时不时被劫持、投放广告就过份了，当然还不仅限于此；

一般来说，我们可以在路由器后台或者自己电脑上手动指定适合自己的 DNS 服务，目前国内比较知名的有 阿里、腾讯、114这么几个，读者可以根据自己的情况自行选择。具体姿势如下：

# 以阿里DNS解析为例，获取离我最近的京东官网IP节点nslookup www.jd.com 223.5.5.5# 拿到上个命令的最终结果，PING下连通性能（选最合适你的那个）ping 27.36.125.193 -c 2

本文将分享另一种更为极客范的姿势，即：通过SmartDNS搭建本地 DNS 服务，特别适用于希望获得全球特定加速的人群。

PS：如果浏览器面前的你，对开发工具配置不是太熟练，以下内容可能会有难度。正常上网冲浪，并不需要这么折腾！

SmartDNS

SmartDNS，一个开源、高性能的本地 DNS 服务器工具，支持树莓派、OpenWrt、华硕路由器原生固件和 Windows 系统等。

更多详情，读者可以移步到他们的官网：https://pymumu.github.io/smartdns

基于 macOS 的本地化

smartdns工具本身是用 C 语言写的，目前该工具并不能直接跑在macOS下。有两种方式可以完成 mac 本地化

• rust 版：热心网友基于 C 移植了一份跨平台的，用法移步：https://github.com/mokeyish/smartdns-rs
• docker 版：官方容器化方案，相对更方便一些

特别提示：由于rust版的目前仍在开发阶段，我试了通过brew install smartdns安装，不过有一些问题。刚好我本地有Docker环境，所以就换成容器方案了。

工具依赖说明

1. Docker：下载和运行容器，具体移步：https://hub.docker.com/r/pymumu/smartdns
2. Git：用于dnsmasq-china-list源码下载；
3. Make：用于构建基于本地 DNS 服务的 list，如果 mac 有安装过 XCode，则认为make命令默认有效；

基于规则分流

由于某些众所周知的原因，国内公共 DNS 服务对海外网站解析是有限的。如果想要实现内外有别，推荐基于dnsmasq-china-list构建自己的清单。否则，仅 Docker 化就可以了

如果你已经准备好了上述工程源码，那现在可以开始构建了

make SERVER=domestic smartdns

这句命令的意思是，把国内节点解析交给smartdns。
成功后，会生成几个以smartdns.conf结尾的配置文件，然后再把它复制到系统目录：/et/smartdns/domestic

注意使用sudo操作，如果对应目录不存在，则手动创建。最后赋予文件可读权限…

配置参考

以下是smartdns.conf的配置参考，该文件位于：/etc/smartdns。如果没有，需要手动创建它

# Listen on local port 53, both ipv4 and ipv6bind [::]:53# 日志信息log-num 5log-size 2Mlog-level warnlog-console yes# 禁用全局测速speed-check-mode none# 启用双栈优选dualstack-ip-selection yes# 域名预先获取功能，开启会提高系统资源占用率prefetch-domain yescache-size 4096# 配置 bootstrap-dns，如不配置则调用系统的，建议配置server-https https://cloudflare-dns.com/dns-query -bootstrap-dns -exclude-default-group# ----- Default Group（解析海外） -----server 1.0.0.1server 8.8.4.4server 9.9.9.9server-tls 1.1.1.1server-tls 8.8.8.8# ----- Domestic Group（解析国内） -----## 腾讯 DNSPod IP DoTserver-tls 1.12.12.12:853 -group domestic -exclude-default-groupserver-tls 120.53.53.53:853 -group domestic -exclude-default-group## 阿里 IP DoTserver-tls 223.5.5.5:853 -group domestic -exclude-default-groupserver-tls 223.6.6.6:853 -group domestic -exclude-default-group## 114 DNS、使用 TCP 查询server-tcp 114.114.114.114 -group domestic -exclude-default-groupserver-tcp 114.114.115.115 -group domestic -exclude-default-group## DNSPod 兜底server 119.29.29.29 -group domestic -exclude-default-group# ----- Office Group（解析办公区内网） -----# Configure the Office(Home) upstream serverserver 192.168.1.1 -group office -exclude-default-group# Domain names ending with work are forwarded to the office group for resolutionnameserver /work/office# ----- 其他个性化配置 -----# Set static IP for domain nameaddress /x.tangkunyin.com/127.0.0.1# Block Domains (Ad Blocking)address /ads.baidu.com/## 加载由 dnsmasq-china-list 生成的 domain-rules 配置文件，使得国内的解析走 domestic 组conf-file /etc/smartdns/domestic/*.conf -group domestic

以上就是全球均衡的一个配置参考，各项参数的用途参考官方：https://pymumu.github.io/smartdns/configuration

运行和测试

配置文件和容器环境准备妥当后，执行以下命令：

docker run -d --name smartdns --restart=always -p 53:53/udp -v /etc/smartdns:/etc/smartdns pymumu/smartdns:latest

然后，你可能会运行失败！因为53 端口被系统服务占用了，你可以通过lsof -i:53或sudo lsof -i:53看下是哪个进程占用了，然后杀掉、重启容器

容器运行后，可以看到它的状态如上，可以清晰的看到事实上它并没有占用过多的系统资源。接着把本机的 DNS 改成：127.0.0.1

nslookup 一把

小结

DNS 之于网络的重要性不言而喻！构建一个合适的 DNS 服务，对每个网民都非常重要，希望本文能对读者带来一些启发和有用的参考。

更多有料有趣的知识，可以看这篇文章：我有特别的 DNS 配置和使用技巧

在此，感谢所有作者的奉献，以上！

然而向量数据库（又称矢量数据库），却不是人人都接触过，光看这名字，就充满高级与神秘感！

接下来，本文将从三个方面，来向读者介绍什么是向量数据库，以及它适用的业务场景和当前业界的主流方案。

基本概念

什么是向量数据库

标准解释：以数学形式存储的数据集合。翻译成人话，就是把人类看得懂的信息转换成机器容易理解的数据，并能有效建立关联关系，比如文字/音频/图片等转换成类似[[1],[22],[333]]这种高维度数据，主要应用于语义化相似度检索。

举个例子，在传统的数据库检索中，一般都是根据关键词做模糊匹配。比如简单粗暴的LIKE语句，然而这些本质上都是基于文本在做匹配查找，一旦关键词不对，结果就查不出来了。

诞生背景

• 传统数据库面向语义化查询明显存在短板，除非人为用代码去解决。但如果业务逻辑复杂或者面向文档类查询，基本上就没招了；
• 人工智能的发展需要，现阶段大模型都有一定 TOKEN 的限制，能够高效理解上下文、读懂用户意图决定了 AI 的基本素质；

如果没有向量数据库，单独查询机器学习模型速度会很慢，而且每次消耗大量 TOKEN 也得不偿失。通过向量化数据，可以有效整合并精准上下文信息关联，省时省钱、还提高了模型调用的精度。

与一般数据库的区别

这里列举一些主要的差异，体现在数据类型、查询方式、应用场景等方面：

数据类型

• 传统数据库：主要处理结构化的数据，如数字、字符串、日期等。数据通常以表格的形式组织，每一列对应一种数据类型。通常采用关系模型或键值、文档、图形等 NoSQL 模型，RDBMS 通常对应二维表结构，NoSQL 对应树状结构。
• 向量数据库：专门处理高维向量数据，如来自深度学习模型的输出向量。这些向量可以代表文本、图像、音频等各种类型的数据。通常不关心数据的具体含义，而是侧重于向量本身及其相似度。

存储和索引

• 传统数据库：使用 B 树、哈希索引等数据结构来优化查询效率。
• 向量数据库：使用特殊的数据结构（如 HNSW、PQ 等）来加速向量相似度查询。

查询方式

• 传统数据库：使用 SQL 查询语言或特定的查询 API 来检索数据，支持复杂的条件筛选、聚合操作等。
• 向量数据库：主要通过计算向量之间的相似度来检索数据，通常使用距离度量（如欧几里得距离、余弦相似度等）来查找最近邻或相似向量。

应用场景

• 传统数据库：广泛应用于事务处理、报表分析、数据仓库等领域。
• 向量数据库：适用于推荐系统、图像和视频检索、语义搜索、自然语言处理等需要处理非结构化数据的应用场景。

当然，截止目前，有的传统数据库也是可以通过扩展的方式支持向量查询的功能。这里就不再具体展开讲，有兴趣移步到文章末尾：参考资料的第一篇

业务场景

对于向量数据库，目前业界主要应用在以下场景：

• 相似度和语义搜索：
  • 电商领域：比如经典功能之一的：猜你喜欢
  • 影音娱乐：推荐歌曲/电影等
  • 聊天机器人
• 机器学习和深度学习：将信息的相关性连接起来，构建完成复杂认知任务的学习和模型训练
• 大语言模型（LLM）和生成式 AI：依赖向量数据库对文本/语音等进行上下文分析，通过将单词、句子和观点相互关联，LLM 可以理解人类的自然语言，甚至可以生成文本

主流方案

• Milvus：Zilliz 开发的开源向量数据库，支持分布式部署和多种索引结构。支持Go,Python,Java，文档和社区完善；
• Faiss：Faiss 是 Facebook AI Research 开发的一个高效相似性搜索库，支持 CPU 和 GPU 加速。主要面向C++开发者，数据规模大、需要高性能要求的首选；
• Annoy：Spotify 开发的用于近似最近邻搜索的库，适用于大规模、只读数据集。简单易用，适合快读原型开发，编程语言支持Python和C++；
• Qdrant：一个高性能、可扩展的向量搜索引擎，支持多种索引结构，如 Flat、HNSW 和 PQ (Product Quantization)，中大型业务和云原生应用；
• Weaviate：一个开源的向量数据库，支持图数据库的特性，可以存储和查询带有关系的向量数据。提供 RESTful API 和多种语言的客户端 SDK，适合构建语义化理解系统的团队；

简易排名

1. Milvus：提供了多种语言的 SDK，文档丰富，社区活跃。
2. Faiss：虽然主要支持 C++和 Python，但在性能方面非常优秀，有广泛的社区支持。
3. Qdrant：通过 RESTful API 支持多种语言，易于集成，社区活跃度良好。
4. Weaviate：同样通过 RESTful API 支持多种语言，社区支持也不错。
5. Annoy：支持较少的语言，但简单易用，适合快速原型开发。

最后，让机器来做个选择

参考资料

• https://guangzhengli.com/blog/zh/vector-database
• https://www.bilibili.com/video/BV11a4y1c7SW
• https://www.bilibili.com/video/BV1BM4y177Dk

因为我发现，几乎所有恶意请求都被拦截到托管质询这个规则里了，比如：/admin-post.php这种明显是恶搞的流量。所以我想了一下，把规则顺序做了调整

WAF 规则顺序调整

基于上文提到的问题，我把之前配置的规则做了如下的调整。主要是阻止访问的规则直接放在了首位

过了一天后，看下结果

可以明显看到，恶搞的请求被档在最外层了，而托管质询也被很好缓解了。接着点进去看看这个规则下，到底阻止了那些请求

本来呢，THOMAS TANG 这个站点就仅仅是一个类似 readme 的介绍而已，用hexo生成的纯静态站，没啥多余的东西。

但纳闷的就是，不知道哪来这么些闲的蛋疼的人，时不时恶搞一下（伤害倒没有，但挑衅意识极强）。有这兴趣，去干百度不更有成就感么…

再次优化

在分析托管质询这条规则日志时，我发现上头那种顺序，会误伤爬虫，比如这个记录

所以我想，最优的解法应该是：

1. 阻止：禁止恶意请求访问，比如代码脚本的恶意攻击，特殊的路径访问等；
2. 跳过：针对主流搜索引擎的爬虫进行放行，毕竟网站放到互联网，基本上都希望别人可以了解和访问到，因此爬虫能检索到很重要；
3. 托管质询：针对非常规的请求进行验证，这项就根据个人情况自己配了；

以上看法并非业内的最佳实践，但有了这几项配置和优化。对于绝大多数的站点我觉得都相当够用了。最终我的配置如下，供有需要的参考：

当然，识别到爬虫要尽量放开其他规则限制。不然容易被托管质询这里拦截。这块我在文章开头提到的那篇Cloudflare 安全性规则设置有提及。

关于 Cloudflare

再多说几句，关于Cloudflare，业内对 Ta 有个很高的评价，说是活菩萨还是铁观音来着。具体突然想不起来了，这个称号还蛮有意思，对标到国内这些厂商，还真是讽刺呢

总之，如果业务允许，试试 Cloudflare 一定不会让你失望。起码像HTTPS这种，不会像某云那样问你要钱…当然更多“白嫖玩法”就各位自己研究啦！

在安卓端，因为有一个现成的 demo 供参考，所以图省事就大量复制了原来的Java代码。本来弄完后可以播放（应付差事），但是腾讯的XP2P很耗时导致进入PlayerView时要卡差不多 2 秒！

这让我如何能忍？！ 😂

于是就用Kotlin的协程改造了一番，结果一顿操作猛如虎，改完一看，画面没了，然而 logcat 没有明显报错。这就让人抓狂了…于是有了这篇文档。

果与因

一、画布变量申明修饰符错误

在优化过程中，试图使用类似lateinit、lazy的关键词去声明可能有大消耗的变量，结果某个环节翻车了。以下是通过GPT学到的姿势：

使用 lateinit 的注意事项

1. 初始化保证：lateinit 变量必须在访问前被初始化，否则会抛出 UninitializedPropertyAccessException。确保在使用变量前它已经被初始化。
2. 线程安全：初始化 lateinit 变量的操作应该是线程安全的。如果你在一个多线程环境中使用 lateinit，确保只有一个线程负责初始化。
3. 可变性：lateinit 只能修饰 var 类型的属性，因为属性初始化后可能需要更改引用。如果你想要一个只读的延迟初始化属性，应该使用 lazy。
4. 非空类型：lateinit 只能用于非空引用类型，不能用于基本类型（如 Int、Double 等）。
5. 反射：使用反射初始化 lateinit 属性时，需要特别小心，因为反射操作可能绕过 Kotlin 的空安全检查。
6. 调试困难：由于 lateinit 绕过了 Kotlin 的空安全检查，它可能使得调试更难，因为你不能依赖于编译器来捕获未初始化的引用错误。

不应该使用 lateinit 的情况

1. 可提前初始化的属性：如果一个属性可以在构造函数或初始化块中被安全地初始化，那么不应该使用 lateinit。
2. 可选或可能为 null 的属性：lateinit 不应该用于可选的或可能为 null 的属性，因为 lateinit 要求属性非空。
3. 只读属性：对于只读属性，应该使用 lazy 而不是 lateinit，因为 lazy 提供了一次性、线程安全的延迟初始化。
4. 性能关键路径：在性能关键的代码中，如果延迟初始化不是必要的，应该避免使用 lateinit，因为它可能引入额外的运行时检查。
5. 多线程环境：在多线程环境下，如果多个线程可能同时尝试初始化同一个 lateinit 属性，可能会导致竞态条件或异常。

总之，lateinit 应该谨慎使用，主要用于那些在对象构造后才能安全初始化的属性，并且这些属性在初始化前不会被访问。在设计类时，优先考虑在构造函数或初始化块中初始化属性，只有在确实需要延迟初始化时才使用 lateinit

二、多线程异步不播放

截止 7.5 日的实际情况来看，并非播放不能在多线程异步条件下进行。前期播不了的根本原因在于多线程下 SDK 初始化和画布初始化存在时间差，即：SDK 初始化好了，但画布还没准备好。所以从 logcat 上看，有大把 ijkplayer 日志输出，但始终没有画面

后来，通过事件的方式，在完成画布初始化后通知 SDK 播放，此时整个流程如丝般顺滑…

1、把画布初始化时就设置上监听回调，原来是在播放那一刻才做这个动作。所以surfaceTextureListener时机很关键

private val playerView = LiveTextureView(context).also {    it.layoutParams = LayoutParams(LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT)    it.isOpaque = false    it.surfaceTextureListener = it    addView(it)    Log.i(TAG, "playerView added to MainView. called ============ 🏅")}

2、画布初始化完成后，通过消息通知，让 SDK 开始异步初始化

internal lateinit var surface: Surfaceoverride fun onSurfaceTextureAvailable(surface: SurfaceTexture, width: Int, height: Int) {    try {        this.surface = Surface(surface)        Log.d(TAG, "surface初始化完成，即将进行播放... ")        EventBus.getDefault().post(AppEventKey.OnSurfaceTextureAvailable)    } catch (e: Exception) {        Log.e(TAG, e.message!!)    }}

3、收到通知，异步开干！这里用到了androidx.lifecycle.ViewModel

@Subscribe(threadMode = ThreadMode.MAIN)internal fun calledOnAppEvent(event: AppEventKey) {    when (event) {        AppEventKey.OnSurfaceTextureAvailable -> {            initPlayerService()        }    }}private fun initPlayerService()  {    viewModelScope.launch(Dispatchers.IO) {        xp2PService.start(ctx)    }}

三、data class 定义

对于Kotlin这门语言，之前其实用到的并不多，可以说是小白用户。在优化过程中没有注意到一些的细节，然后导致RN那边的变量传过来是错的，而且竟然一直没有发现这个问题。直到一行行的分析 logcat 时，才偶然发现一个简短的 Warn：p2p error message

一点想法

• 日志的重要性：擅于分析日志的重要性不用多说，然而对于开源类库作者，输出有效的、合适等级的日志信息更重要。这直接影响业务对接的效率和体验；
• 文档的重要性：任何情况下，提供完尽、有条理的业务文档都很重要，然而对于大多数开发者而言，写文档没有直接写代码更有快感。这就导致了对接过程中要深入源码去看，如果能进入倒好。像 iOS 那种.a只提供头文件的，就当场吐血了；
• 对于编程语言的选择：这次算是对Kotlin有了更全面的体验，从个人码历而言，其快乐体验吊打一众别的大前端语言，如：Objc、JavaScript，甚至我个人觉得比Swift感受还要好。我觉得吧如果有得选，试试现代编程语言还是不错的选择。

写在最后

由于该播放器组件受保密协议约束，所以不能直接发github地址。当然作为expo module本身，也并不见得有多大的通用性。所以呢本文仅针对本人研发过程中遇到的问题做一个整理，如果你也恰好遇到类似的问题或需求，可以直接留言交流。

因为前段时间发现有恶意扫描请求到我的站点，看了下 Web 攻防这块，恰好 cloudflare 自带各类安全设置，所以就摸索了下、配置了若干…

后来发现google-search-console没能抓取到已提交的搜录请求，分析了下被拒的原因，发现是之前在 cloudflare 后台配置安全策略时，有些防卫过当了

被各种拒绝

Google Search

Bing Search

原因分析

先前基于WAF规则，做了很多配置。主要思路是开放正常请求 和 主流搜索引擎爬虫访问，但是分析日志后发现，有一些来自 Google 和 Bing 的请求 403 了

这些请求中，用户代理基本上没什么问题，但是协议有的是 1.1、有的是 1.2。另外多项规则设置中，匹配到爬虫并没有完全放开，以至于对后续规则进行了匹配，刚好卡在了阻止或需要验证的那一项。如上文图示的各种访问不到

另外发现，自动程序这项开启后，对于 Bing 后台的检测请求会执行失败，比如检测站点地图或 robot.txt 等都会失败

优化后的配置项

所有本文提到的配置，均基于免费版配置。诸如需要升级套餐的配置不在讨论范围内。

WAF

自定义规则

总览

跳过（爬虫放行）

(cf.client.bot) or (http.user_agent contains "Googlebot") or (http.user_agent contains "Google-InspectionTool") or (http.user_agent contains "Google-Extended") or (http.user_agent contains "Google-Display-Ads-Bot") or (http.user_agent contains "Feedfetcher-Google") or (http.user_agent contains "Mediapartners-Google") or (http.user_agent contains "bing") or (http.user_agent contains "bingbot") or (http.user_agent contains "duckduckgo") or (http.user_agent contains "facebookexternalhit") or (http.user_agent contains "dproxy/1.0") or (http.user_agent contains "disqus.com")

其中dproxy/1.0及disqus.com是对Disqus评论组件放行，如果站点加了类似的三方模块，需要单独设置一下。
另外需要注意的是，在要跳过的 WAF 组件里，需要勾选一下你想跳过的检查，否则会出现误伤。之前爬虫被拒，极大可能就是这里没处理好

托管质疑（恶意流量验证）

(ip.geoip.country in {"T1"}) or (not http.user_agent contains "Mozilla/") or (not http.request.version in {"HTTP/1.2" "HTTP/2" "HTTP/3" "SPDY/3.1"}) or (cf.threat_score ge 15 and not cf.client.bot)

以上规则含义：非正常代理请求 或 匿名网络请求 或 HTTP1.2以下协议 或 威胁分数大于15 均发出质疑

阻止（恶意流量阻止）

(http.user_agent eq "") or (http.user_agent eq "undefined") or (http.user_agent contains "null") or (http.user_agent contains "python") or (http.user_agent contains "node") or (http.user_agent contains "Go-http") or (http.user_agent contains "Java") or (http.user_agent contains "libweb") or (http.user_agent contains "libwww") or (http.user_agent contains "PHPCrawl") or (http.user_agent contains "PyCurl") or (http.user_agent contains "Gscan") or (http.user_agent contains "scanbot") or (http.user_agent contains "WPScan") or (http.request.uri.path in {"/admin" "/login" "/user" "/.git" "/www" "/wp-content" "/wp-admin" "//" "/wp" "/shop"})

对于空代理、代码扫描、网站扫描工具、特定目录频繁（试探）访问的都要阻止，这里可以根据安全线事件中的日志去分析，那些流量请求需要毙掉

速率限制规则

我的配置很简单，基于站点特定内容或目录，进行限速。具体速率限制条件，可根据自己的情况调整。我的是 10 秒内 5000，也就是 QPS 500 以上就限速…

(http.request.uri.path in {"/" "/about" "/categories"})

如果是用来做 API 服务的，可以（根据实际情况）酌情调大…

自动程序

最近新出了个AI Scrapers and Crawlers，看意思是用来屏蔽大模型爬虫抓网站内容训练的。如果没特殊问题开放即可

对于这两项，我目前都关闭了。特别是自动程序攻击模式这个，貌似会误伤爬虫或爬虫管理后台的检测服务

DDoS

1. 规则集：阻止
2. 规则集敏感度：高

设置

1. 安全级别选高（一般不要选：I’m Under Attack，顾名思义这个是当你正在被黑时的开关）；
2. 质询通过期，选30分钟就够了。这个意思是质询一次后，隔多久再发出质询；
3. 浏览器完整性检查：打开

结果验证

重新摁下站点地图提交后

在 Cloudflare 的后台可以看到，来自搜索引擎方面的检测请求已经跳过

每次 OpenAI 发布一个产品，就有一个论调说 XX 行业完了，XX 行业很多，包括程序员。实际上，不会的，因为，官员需要韭菜，老板需要奴才，AI 需要卷心菜……性玩具再好，也不如真人好。操 AI，哪有操员工来的舒服？玩人才有意思，也更有成就感。

这话挺好玩，也确实说出来某些实情。以至于让我忍不住上来写几行字…

技术领域的卷

卷，本来没有那么多意思。不过随着国内这些年 IT 行业红利到头发展降速，各公司/岗位为了突出业绩，工作状态越来越拧巴…

因为直接输出效果不再明显了，所以转而在其他看得到/看不到的地方“过分努力”。而这种努力带来的价值，往往却很有限。通常是为了表现的努力而努力，即：内耗自己或者他人。卷的本质是内耗，无用功的输出

以当下的风气来看，卷是个妥妥的贬义词。一提到它，总能让人浑身上下不自在 🥶

无码趣事

前些年，技术圈很流行LowCode/NoCode（一种低代码辅助生产方式），尤其是在前端这块。

因为业务需要…
因为研发提效…
因为闲的蛋疼…

总之，一个技术团队，没这方面的输出，就显得有种“不行”的感觉。当然某些业务场景下，这种姿势确实能很大程度上解决一定问题。但为了No而Low就显得有点用力过头了

比如国内某大型电商公司就曾出了一个：基于图生成代码的平台（imgcook）

这种东西，你说他有用吧，确实也有。但是能否替代专业码仔呢，并不能！

在AI大规模爆发之前，或者说ChatGPT诞生之前，所有这些所谓的LowCode和NoCode平台，其实都是需要ProCode去完成的，而且代价还不低（主要是后期维护成本）。

记得好多年以前，团队在一次外出团建时聊起过这个话题，当时有的同事很坚决，认为类似于界面这种东西，一定会有平台级工具产生，通过各种拖拉拽配置生成业务代码并自动运行。时至今日，这种工具我见过或用过的不少，但平台级工具、满足通用需求的，至今没发现…

我当时的看法是，这种趋势一定会有，但自动生成无法完全替代专业码仔。一方面是考虑生态平衡，另外觉得时间过于久远（除非硅基主导发展了）

最近，关于无码开发这个问题，有了新的答案。

随着人工智能的快速发展，机器对人类自然语言的理解能力达到了前所未有的新高度。了解到目前有一些利用AI基座搭建的，基于自然语言自动生成前端界面的平台：

• https://wegic.ai
• https://www.wix.com/ai-website-builder
• https://www.jimdo.com
• https://codewp.ai
• https://www.framer.com

当然，也有一些开源内裤

• https://github.com/wandb/openui

至此，无码开发到了新的境界，而且未来只会越来越强。但这些东西会让大量程序员下岗吗，我认为很长一段时间内不会。正如开篇所提到的那样…

卷

卷字，承担了一个作为普通汉子在这个美好时代不该承受的偏见，对于大多数卷的人，其最终结果恐怕跟下边这张图也是差不了多少…

No matter how you roll it, it's still a vegetable.

正好，今天下午写东西有点词穷，想通过机器人找点感觉，无奈https://chat.openai.com死活打不开。于是分别把玩了一下通义千问和文心一言两个产品…

关于其技术原理等硬核问题，不在本文的讨论范围内。这里我只想通过对两个产品的体验，谈谈我对百度、阿里两家大厂对待商业产品的一些看法。

文心一言

话不多说，先看图

小结

• 优点
  • 收费入口异常明显，不怕钱花不出去
  • 产图速度快，语义分析挺准，不过废话有点多
  • 支持插件，看起来能明显增强问答能力
• 缺点
  • 产品交互比较一般，有种某多多的感觉
  • 效率模块功能比较单一，除了作图，就是文字类创作
  • 文档上传单次一个，格式 doc/docx/pdf，单个最大 10MB（略显小气）
  • 是否支持多端，APP 哪里下？ 后台暂未发现入口

通义千问

话不多说，还是先看图

小结

• 优点
  • 产品交互做的不错，对于我这样的职业强迫症来说，体验很愉快
  • 废话少、不瞎 BB，语义分析挺准，随便瞎聊也能猜懂我的心思
  • 效率模块里的功能相当实用，特别是发现模块的音频播客解析（产研用了心思在搞需求）
  • 可同时上传 100 个文件（每个 150 MB）支持 PDF / Word / Excel / Markdown /EPUB / Mobi / txt
• 缺点
  • 产图的速度不太理想，对比了好几个发现都比文心一言慢
  • 不支持插件，不确定百宝袋里那些是不是
  • PC 站不支持响应式，有可能设计如此

观点感受

对于两家大厂的作品，说实话百度给我的直观感受挺不好：前端体验一般不说，满屏显眼位置写着充钱(提醒字样)

另外，我试着拉动浏览器做了下缩放，百度的 PC 端做了自适应，到一定尺寸时变成了移动 H5 的样子：页面强制刷新，PC 端功能界面没了，所以又得去找刚刚那个对话记录🤦，然后露出一个引导下载客户端的入口…

这里不是拿小问题来黑百度，也不是说收费不对。我只是觉得，作为一款普世的商用产品，把基础能力和用户体验做好了再出来收费是不是更好一些呢！？

相较于百度的粗糙，阿里就好很多，在 PC 端的功能丰富度上，我个人觉得目前的情况是吊打百度。其中有个细节请各位看官自行品鉴，而同样生成的图片，百度那边我没发现下载、缩放的入口在哪 🤷

另外我在通义千问后台发现了有个开源的东东（没仔细看，但给人的感觉是这哥们有格局），这同样让我想起另一款两个大厂都有的产品：网盘

去年末，由于一些资料需求用到了阿里云盘，意外发现那玩意可以当爱奇艺玩，当然产品体验也是优于百度那盘。在如今这个燥热时代，还有一些追求、以用户为本的科技公司不多了…

整体而言，阿里的作品超出了我的预期，能感觉到产研在用心为用户做事。而百度还是那个百度…尽管处在特殊环境下，也拥有绝对的流量优势，然而从大多数作品体现的态度来看，他们显然没把用户放在首位 ☠️

曾经，一位大佬谈过科技向善的观点，对于大模型这样的硬核科技，如果商业产品推行得当，则能强有力的造福人类。为那些不忘初心，牢记使命的人们点赞 😂

由一次内部系统小改引发的小故事：旧系统迁移和两个系统的整合部署，目标是一个容器内跑新旧两套系统，并用一个域名承载！

二、故事开始

1、镜像升级（定制镜像）

发现新系统在 Node 版本方面，有不一致的地方，比如编译环境是node-v12.x，而实际容器的运行版本则是node-v10.x，这还没算部分项目有依赖安装的场景…对于 Web 项目本身可能影响不大（已知 node-sass 对版本有依赖，使用 Sass 时需要注意），但是如果跑 Node 服务就会有影响（js 引擎在不同版本之间往往会有差异），更何况不同的版本之间默认 NPM 也不一致，也会造成安装的依赖存在略微差异！

除了 Node 版本，nginx 也一样。理论上讲，最新的稳定版本应该也会比老舅的性能更好，特别是版本差的太多的！

本来是想在之前的镜像上直接升级，后来觉得 OS 是不是也能折腾一下（主要是我米 SRE 提供的标准镜像都太老舅），于是就去 Docker 官方找了标准镜像

系统版本说明

• alpine：Alpine Linux 操作系统。占用空间最少（工具和基础软件包没有），但出现问题比较难以调试。一般不要选择这个类型；
• buster：基于 Debian Linux 发行的版本，比较新且支持全面。一般使用这个类型即可（大多镜像默认就以此为基础）；
• stretch：另一个基础 Debian Linux 发行的版本，相对于 Buster 系统比较老舅，建议不要使用（除非硬件不支持新系统）；

最终基础镜像选择为：Debian Linux 10.10(buster)。在搜索上选择了最新的 nginx 版本，即：1.21.1。如果本地已经安装好了 Docker 环境，则直接黑窗口执行：docker pull nginx:1.21.1

基础镜像下载到本地之后，就可以定制环境了。一般有两个姿势：

纯手工打造

1. 启动容器，安装基础工具（curl/procps/vim 等）和项目运行环境（node/nrm/yarn/cnpm/pm2 等）。考虑 node 未来升级的可扩展性，我们可以通过 nvm 来安装 node。需要注意的是通过 nvm 安装后，一定要把环境变量导出。否则容器启动后会因找不到类似 npm 命令导入安装依赖或在线打包失败……
2. 系统参数调优，比如 nginx 默认的一些配置，是否开启 GZIP 等；
3. 通过容器 ID 提交新的镜像并 push 到镜像仓库，具体参考以下步骤：

# 1. 从官方拉取基础镜像docker pull nginx:1.21.1# 2. 查看本地镜像编号/名称docker images# 3. 启动镜像容器（映射宿主机的一个目录到容器内，主要方便文件交换）docker run -itv /Users/tangkunyin/docker:/home ${镜像ID} /bin/bash# 4. 提交容器到镜像## 查看容器iddocker container ls -as## 提交容器并打标docker commit 9cae32ff7102 registry.cn-guangzhou.aliyuncs.com/thomax/nginx-node:1.21.1-14.16.0# 登录镜像仓库并push## 名字注意换成你的docker login registry.cn-guangzhou.aliyuncs.com --username=xxx## 确认无误后推送镜像docker push registry.cn-guangzhou.aliyuncs.com/thomax/nginx-node:1.21.1-14.16.0

通过 Dockerfile 自动打造

FROM nginx:stableLABEL maintainer="Thomas Tang <hello@tangkunyin.com>"LABEL description="Based on the nginx:stable, node installed by nvm and nrm yarn all installed"ENV NVM_VERSION 0.38.0ENV NODE_VERSION 14.16.0ENV NVM_DIR /usr/local/nvm# Replace shell with bash first so we can source filesRUN rm /bin/sh && ln -s /bin/bash /bin/sh && \apt-get update && \apt-get install -y curl vim procps net-tools iputils-ping openssh-client openssh-server && \rm -rf /var/lib/apt/lists/* && \mkdir -p /usr/local/nvm && \curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v${NVM_VERSION}/install.sh | bash && \. $NVM_DIR/nvm.sh && \nvm install ${NODE_VERSION} && \nvm alias default ${NODE_VERSION} && \nvm use ${NODE_VERSION} && \npm install -g nrm yarn && \nrm use cnpm && \nvm cache clearENV NODE_PATH $NVM_DIR/versions/node/v$NODE_VERSION/lib/node_modulesENV PATH $NVM_DIR/versions/node/v$NODE_VERSION/bin:$PATH

在文件同级目录下执行编译：docker build -t registry.cn-guangzhou.aliyuncs.com/thomax/nginx-node:1.21.1-14.16.0 .

以上构建成功后，参考手动部分再 push 到镜像仓库，即可完成镜像的定制！

2、子项目依赖

要实现一个容器里跑多个系统，项目代码最好就集中到一个主仓库，一来简化开发流程，二来也方便 Gitlab 打包的镜像包含所有的 dist。所以 Git Submodule 就用到了，不过特别需要注意的是子项目路径依赖最好用相对路径，而不是直接 https/ssh。对于项目都在同一个 gitlab 甚至是一个群组内，这个方式非常适合。如果是分布在不同 git 服务器上，则需要使用其他姿势了，具体自行谷歌容器之间配置 SSH 信任。

另外 Gitlab 的 Runner 也需要额外配置一下，因为构建时它默认并不会去拉 submodule 仓库。我们只需要在 gitlab-ci.yml 中 variables 里添加一行：GIT_SUBMODULE_STRATEGY: recursive

git submodule里的内容参考如下：

[submodule "platform-v1"]    path = platform-v1    url = ../platform-v1.git    branch = "master"

3、缓存策略的使用

通过 Gitlab 进行 CI/CD 中最浪费时间的地方就是安装依赖和在线打包，其中前者往往是很多前端同学的噩梦，为了尽可能提升流水线效率。我们就需要用到合理的缓存策略来加速。默认的策略是：push-pull，在默认方式下，每个 Job 开始执行前都会去检测并下载缓存文件，任务结束后又会上传一遍文件。但并不是每个 Job 都需要这样：

• 依赖安装：把首次安装好的 node_modules 缓存到 FDS 上，如果 package 文件不变，则后续流程就不用在进行依赖安装。对于这个阶段来说我们不需要检测 FDS 是否有缓存，要做的只是变更后 push 新的缓存包。因此这个阶段改成：push
• 编译打包：用安装阶段已经缓存的 node_modules 直接编译项目，完后不需要再上传文件。因此这个阶段改：pull

这样，FDS 下载和上传的时间就被节省掉（node_modules 包特别大时效果明显）。再有，缓存如果是被多个 Job 所共享，需要注意使用一致的名称和一致的 path，否则 Job 执行时会相互影响

这里建议用分支+自定义标识为缓存包做命名，比如这种：key: "${CI_COMMIT_REF_NAME}-dependenciesCache"

其中，CI_COMMIT_REF_NAME 是 gitlab 预定义变量值，参见：https://docs.gitlab.com/ee/ci/variables/predefined_variables.html

这种命名的好处是生产环境依赖和测试环境依赖可以有效区分开，避免可能的影响！

4、入口文件优化

每一个使用 Docker 来部署的应用的项目在其根目录都有一个 Dockerfile 文件，这个文件用来定义容器的运行时环境以及启动时应该执行的脚本任务。但对于复杂场景来说，Dockerfile 中的 ENTRYPOINT 或 CMD 指令就不太好描述了，特别是当需要判断环境执行不同任务时。此时一个 shell 文件就会解决所有难题，例如：

#!/bin/bashset -emkdir -p /home/work/log# Starting nginx servernginx# Starting node server. Note that staging won't run old-serverif [[ $runEnvArg == 'prd' ]]; then    cd /home/work/app/xxx-platform/platform-v1/server && npm run online >> /home/work/log/xxx-old.log &    echo "old server is running................................"ficd /home/work/app/xxx-platform/server && npm run $runEnvArg >> /home/work/log/xxx-new.logexec "$@"

原来的ENTRYPOINT指令改为：ENTRYPOINT ["./docker-entrypoint.sh"]

5、容器启动失败

docker 容器不同于虚拟机，我们可以简单粗暴的理解为宿主机内的一个进程。因此从这个角度来说，容器需要有一个前台任务“卡”着才能正常运行。否则“进程”启动后就会自动退出。所以重点来了，如果你的容器启动后无故自动退出且没有其他报错信息，请第一时间检查是否有前台命令……对于前端来说这个命令不是 nginx 就是 node。注意我再说一遍，不管哪个命令一定是前台执行，即：卡着黑窗口不退出的那种……

另外值得一提的是容器本地调试，如果发布平台上操作哪哪都不对，又不想浪费 Gitlab 流水线时间，那完全可以把已构建成功的镜像（你要部署的那条）直接下载到本地调试！

6、子系统访问路径的问题

这方面，需要注意两个问题，一是项目本身的publicPath ，二是 nginx 的root/alias指令。比如我开始提到的，我要一个域名跑新旧两个项目：

• 新：https://xxx.demo.com
• 旧：https://xxx.demo.com/v1

此时，旧项目在打包 dist 时就需要配置publishPath 为 v1，而 nginx 的配置就取决于旧项目包绝对路径，事实上使用 alias 指令，自由度会更高

7、CI 文件优化不完全指北

总的来说就是用 gitlab 手动维护多套基础模板，业务使用时，直接include基础模板并把需要的变量传递进去，而不是在每个项目的gitlab-ci.yml文件写一大堆冗余的配置。这样做的好处不言而喻，除了简单便捷，也在宏观层面尽可能统一了研发/运维的标准。尤其是对于新手同学，统一姿势会节省的大量宝贵的时间。

三、阅读资料

• https://wgjak47.me/tech/gitlab-ci_submodules/
• https://zhuanlan.zhihu.com/p/106971627

兴趣是最好的老师，对学琴这个事情，首先心态摆正。其次准备以下设备：

基础设施

• 61/88 键电子琴一台
• 头戴式耳机一副（主要是防止扰民）
• 平板/大屏手机一台（看曲谱或者智能音乐 App 跟弹）

目标与步骤

从最容易入手的电钢琴开始，以即兴伴奏为核心学习

• 时间
  • 练琴时间：单次练习不要超过 30 分钟，之后休息 5 到 10 分钟再继续练
  • 时间分配：清晨练习以及其他兴奋状态下
• 步骤
  • 有计划地安排练习内容：从简单到复杂曲谱集合，每首曲子要清楚连的是什么
  • 对于每首曲子的难点：暂时给予这些乐段以优先的地位，即抓住难点进行训练
• 方法
  • 循序渐进：从最简单的伴奏方式开始练起。最简单的伴奏方式是左手弹和弦根音，即和弦中几个音里最低的音。右手弹整个和弦。左手大的，可以弹两个八度的两个根音
  • 边弹边唱：手上无歌，心中有歌，才能跟上
  • 先分后合：先练右手，再练左右，两手再合。不要两个手一起练，否则事倍功半，因为没有单独练习，不熟练，难以配合

慢速练习

放慢速度是解决各类技术难点的首选方法，也是最有效的方法。慢练的目的，是让头脑清醒地向肌肉发出演奏某个乐句的正确指令。并检查肌肉的反应和动作是否正确

分手练习

分手练习可以使注意力集中于较单一的要求上，降低练习的难度，同时还能够对旋律、乐句、声部、伴奏的认识更加清晰。更加明确弹奏时两手各自的任务。最后使双手的合奏达到准确无误

变化练习

将练习的内容可以进行改变节奏、改变触键、改变奏法、改变力度、改变常规指法练习等来训练，变化的目的是增强技术难度。训练大脑对手指的指挥和控制能力，达到解决技术难点的目的

倾听练习

将自己的音乐听觉思维充分调动起来，不急不躁不激动，冷静地倾听自己弹奏的声音，根据音乐形象可将音准、节奏、和弦、强弱、快慢、弹奏动作等方面做总体把握。及时地调整，对自身的弹奏做一个全面的鉴别

练习时我们不可能把每一首都弹到尽善尽美，但要尽量把所学作品都有所浏览。不必弹得多么熟练，但一定要有所顾及。这样慢慢地，你就会发现原来自己是可以完成、做到的， 日积月累。练习的质量和数量都会有所提高。那么练琴的内容就会越来越宽泛了。

干货教程

必看

• 《数字灵感钢琴课程——精华十二课》
• 《蓝调小生司琴即兴伴奏一点通》
• 《教你快速识简谱》

补充

• 《教会键盘速成教材（基础）之快速入门基本的指法（右手和左手基本指法）》
• 《琴之缘电子琴和弦指法》
• 《钢琴弹唱的秘密》

避坑指南

• 避免长时间机械地反复练习一首整曲，不仅浪费了宝贵的时间，反而使头脑处于迟钝状态

code review 是现代软件开发非常有意义的一种技术管理方法，其价值不止在于代码的准入和找 bug，也是所有人技术交流和成长的一种手段，总结 CR 的意义，不限于：

• 找出可能的坑
• 帮助新人成长
• 互相督促代码质量
• 互相学习设计理念及编码思路

理想情况下所有代码合并都必须进行 code review，并且必须 CC 整个组，让你的每一个合并都更认真地对待

phabricator

诞生于 Facebook 内部，是一套基于 Web 的软件开发协作工具，包括代码审查工具 Differential，资源库浏览器 Diffusion，变更监测工具 Herald，Bug 跟踪工具 Maniphest 和维基工具 Phriction。Phabricator 可与 Git、Mercurial 和 Subversion 集成使用。

其本身是 PHP 开源程序：https://github.com/phacility/phabricator

系统配置

PHP 环境请自行 google，这里记录 nginx 配置

server {    set $content "~/dev-lib/phabricator/webroot";    listen 80;    server_name phabricator.tangkunyin.com;    root  $content;    location / {        index  index.php index.html index.htm;        rewrite ^/(.*)$ /index.php?__path__=/$1 last;    }    location ~ \.php$ {        fastcgi_pass                127.0.0.1:9000;        fastcgi_index               index.php;        fastcgi_intercept_errors    on;        include /usr/local/etc/nginx/fastcgi.conf;    }}

运行后，会提示通过命令设置Mysql信息，一般情况下直接设置密码即可

接着，会让你更新数据库信息，同样按提示操作即可

如此phabricator就算安装完成了，接下来根据引导配置一下系统各项参数。以下这些看情况配置就好

项目配置

先下载并配置环境变量：https://github.com/phacility/arcanist
再设置帐号信任：

arc set-config default http://phabricator.tangkunyin.com/arc install-certificate http://phabricator.tangkunyin.com/

执行后会提示到网站上找到对应的 token，找到后粘贴输入。注意提示的网址应该是：http://phabricator.tangkunyin.com/conduit/login/，如果不是重新登录以加载新的配置

最后在项目中创建**.arcconfig**文件并配置基础项，完整配置请自提自：arc get-config --verbose

{  "phabricator.uri": "https://phabricator.d.xiaomi.net/",  "history.immutable": false}

review 步骤

1、git commit 你的修改
2、开始 review

arc diff commit_id --create或修改arc diff commit_id --update D12306  （这儿的D12306是上一次review时的revisionId）

3、填写 review 信息

4、现在你会收到邮件，也可以在网站上看到你的 review，请大家评审吧

5、merge 仍然要在 gitlab 中完成，merge 消息中要带上 phabricator 的 review 地址，证明这次 merge 是 review 过的，收到了 accept 的 review 才进行合并

需要注意的是我这里并没有提到邮件发送配置，实际过程是要配置的，不然上边的邮件肯定发不出去

具体参考这篇文章：https://cloud.tencent.com/developer/article/1609447

平台操作资料：Phabricator Code Review 操作手册

随着同一业务线研发人力增多，混乱往往就逐渐成为了必不可免的问题。此时如果没有一套科学的流程规范，成员「个性」将会导致项目维护成本越来越高

本文主要从分支和日志两个方面来谈谈git在项目版本管理中的策略

分支管理策略

说到分支管理，就不得不提工作流。目前业内广泛使用的工作流有三种：Git flow、Github flow、Gitlab flow

在写这篇文章之前，我用过的也只有Git flow一种，我原以为其一招鲜就可吃遍天，结果发现这事还没那么简单。对于这三种工作流的介绍，阮一峰老师的博客里写的很清楚，科普请自提之。这里主要说使用策略

阶段性版本发布项目（Git flow）

对于目标是一段时间以后产出一个新版本的项目，Git flow是合适的。特别是对于小团队单线开发，不会有多需求同时开发的情况。使用 Git-flow 可以最大程度保证项目安全、有节奏的完成发布和管理。因此 Git-flow 适合有节奏按版本发布的项目，团队人员在 4 人以下

在这种流程下，需要同时维护两个长期分支：master、develop。比较合适的场景有：

• 开源类库
• 客户端项目（如 iOS App）

持续发布项目（Github flow 与 Gitlab flow）

对于发版不固定，甚至代码一有变动，就部署一次的项目。Github flow是合适的。因为这种流程足够简单，就一个长期分支master维护。比较合适的场景有：

• Web 或者动态化业务（RN、Weex）
• 后端接口服务

上图是Github flow的一个单线使用流程。而在互联网公司中往往为了最大化产研资源利用率，当前功能刚提测，下一轮评审可能就来了，即一波赶一波。目前在我的团队，工作流以这个思想为前提稍加了改造，如图：

关于 CI 部署方面，统一走 Tag 事件，避免不小心合并到主分支导致提前发布

另外

gitlab flow倡导的上游优先策略不仅有能适应不同开发环境的弹性，也有单一分支管理的简单和便利。不过个人感觉没有前两种来的爽快…维护成本也不低。所以具体用哪种，还是综合下来看场景

合并小插曲

快速合并（Fast Forward）

常规合并（–no-ff）

从sourceTree图可以看到，如果执行快速合并，开发者根本不会看到被合并的分支，就像在当前分支直接 commit 一样

正常合并如果没有合并冲突，都会进行快速合并。但是对于大多数功能驱动式项目开发来说，要尽量避免快速合并，毕竟有些时候还是要追溯 log，不仅对于代码分析特别有用，另外保证整个项目提交链的完整性也很有必要

日志管理策略

起因

某次项目质量管理时发现了如下图这样的提交…一个修 bug 的操作，commit 却密集的提交了 7 次之多

git 日志过于随意会有什么问题？也许你会说代码写对、项目正常跑不就完了呗，何必纠结那些细节。但如果意识到以下问题，可能你就不这么想了：

• 正常运行的功能出问题，要回滚代码到某个改动前或者查哪个改动引起的问题
• Code review，试想一些很小的改动，却多次无效提交，一个个看会不会崩溃
• 提取迭代的记录（CHANGELOG）做某项总结，结果发现这段时间都 TM 干了些啥
• 破窗效应，分支污染将导致恶性循环，对往后的管理和维护是在埋雷

策略

此模块包含以下两个部分

• commit lint：用于在提交前检查 commit message 是否符合规范
• commit tool：帮助我们简便生成符合规范的 commit message

具体用法教程太多，比如这个帖子：https://juejin.im/post/6844903710112350221

逼格

如果想在日志里做点骚操作，可以考虑emoji。要实现这个你需要关注两个库：gitmoji、emojify

库安装好以后，在项目根目录执行：gitmoji -i，用来加 git 钩子，使得 commit 时可以弹出交互式 moji 对话框。另外配合 zsh 增加别名，让 git log 色彩斑斓

alias gl="git log --color | emojify | less -r"

参考资料

• Git 工作流程
• Git-Rebase
• commitlint
• gitmoji
• emojify
• 

最近 NIZ 的command键非常不好使，并且shift也不动不动失灵。起初以为用的时间太久里面掉灰影响灵敏度了，于是将其大卸八块，仔细做了保洁，装上再试时，发现还是那样……于是萌发了固件升级的念头

所以

根据官方的视频，找到了对应的「刷机包」，如下：

一顿操作之后，发现问题解决了。欣喜万分…遂写下此日记！

后续

对于专业软件「操盘手」来说，有一款称手的利器再好不过，以前用过ikbc的红轴，也用过HHKB TypeS Pro2，发现都不爽。主要是前者因为机械键盘钢板的问题导致键盘很重，另外 ikbc 的红轴偏软，敲击感受不爽；后者虽然重量和感觉非常好，但是无奈有线限制，另外HHKB的出线方式个人感觉挺 SB 的……这一点要赞一下ikbc的两端走线

后来各种调研后选择了静电容键盘里的国产货，也就是本文的主角：NIZ，中文名：宁之，又称普拉姆。其实很早之前见朋友用过此货，颜值非常高，当时记忆算是深刻

我入手的是micro82双模白色 45g，体验至今感觉很超值，算得上是国货精品。当然不可否认的是，键盘稳定性还是有待提高。不过其团队还算负责，有专门的 QQ 群且一直提供升级包供专业人士折腾。如果你恰好看到这个文章，也想换个键盘，你可以考虑一下这个。可以说比动辄上千的机械键盘乐趣更大

传送门

• https://item.jd.com/37696679702.html

纯前端程序用 Chrome 大法调试自然不易翻车，另外打 log 也能输出对象、数组等复杂数据类型。但这一切换到 nodejs 环境就没那么爽了，黑窗口里输出复杂数据类型不仅看的眼花又缭乱，而且跟踪断点非常蛋疼，所以这就需要借助 IDE 能力去断点调试。

谷歌给出的文章时间上都比较老舅，所以写了这个笔录。本文采用 vscode + nest 搭配，系统环境在 macOS 下

vscode 版本是：1.46.1，开始之前最好配置一些偏好设置

调试步骤

确认启动调试的命令是否 ok，主要看 start 命令是否有**–debug**参数

点「甲壳虫」后，出现如下界面，接着点Node.js Debug Terminal

不出意外，nodejs 就可以调试了（得在 js 文件上打断点，如果是 ts 则找 build 后的 js 文件）……

此时，如果在 ts 源文件中直接打断点，可以看到的是，没有反映……，于是我们来折腾一下这块

配置 TypeScript 调试

姿势一

tsconfig.json中开启sourceMap，即："sourceMap": true,。一行见效

姿势二

ts-node大法

详见资料：使用 ts-node 和 vsc 来调试 TypeScript

延伸阅读

• 使用 VS Code 调试 Node.js 的超简单方法
• deno vs ts-node

本文说的工作泛指 CS 工程方向，这里特指软件研发。没有对其他行业做调研，也不太了解，所以不要全信，也不要不信！

工作的种类

按工作内容

• 日常工作：按部就班的作业
• 应急工作：自己负责的模块出问题后要做的作业（跟日常工作质量密切相关）
• 研发工作：前两种作业完成后。独立或共同研讨的对策、规划、调研等，不一定是编码

以上是当年刚入职小米时，某总监在一次晨会上提到的。作为已经工作好几年的人，当时听到这个话还是挺激动，所以我就深刻的记下了。一直一来，工作上我都参考这个规则来展开，尽可能避免一直处于日常工作当中的状态。

在软件开发领域，我们常常听到两种岗位：开发工程师和研发工程师，其实想想区别也倒简单，根据以上看哪个做的更多罢了。

思考

算了一下，到今天为止已经满载满荷的工作 N 个年头了。其中前些年主要还是以写代码为主，近两年开始专职带团队做事。当然工作内容发生了很大变化，所以我觉得有必要有个思考。这篇文章只是一个开始……

几乎每个技术人也都会面临这个问题，即到某个时间开始带人做事，随着团队规模越来越大，自己写码的时间越来越少，然后出现两个明显的问题：

• 没更多时间和精力专心撸码，担心技不如人（下次找工作尴尬）
• 不适应新经理角色，也很难一下做好。随之而来的挫败感大大降低了工作的幸福程度（不如编码实在）

难道对于技术和管理，就没法二者兼得了！？其实不然，关于这个话题的讨论网上有很多。这里不再赘述……

之前在某档管理课程学习的结论直接分享出来：

1. 专业线解决专业问题，管理线解决业务目标达成。后续并非一定存在高低，更多看个人发展。
2. 用目标来带动能力的提升（对于管理岗的患得患失）

时间的问题

按每天有效时间 6 小时（2 + 4）算，一周只有 30 小时，编码如果 20%，那就是整整一天……对于管理 8+的一线 Leader 来说，最好不要超过这个阀值，长期如此大概率会害人害己……

另外几个重要的关键词：惜时、主动、深度思考

多年前帮朋友写过一个 PHP 的项目用过 Mysql，后来硬盘空间不够了，所以卸载了。当时只是卸载没有清理干净，毕竟默认情况下卸载 Mysql 是不会自动删除db文件夹的，于是今天又有相关需求再次安装时，翻车了…

(HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (38)

解决姿势

起初以为mysql.sock这个文件没有，另外brew services restart mysql再怎么启动都也不明显报错……于是各种操作配置，一顿搞还是连不上。于是怒看 Log…

上图是/usr/local/var/mysql/KunyinTang.local.err中发现的，看上去跟我之前那个版本不兼容导致安装后服务没启动……

于是，一顿操作卸载并删除了所有相关的老的、新的 mysql 文件……整理的操作如下：

cd /usr/local/etcrm -rf my.cnf my.cnf.default# 旧的数据文件如果有用要记得保存一份！sudo rm -rf /usr/local/mysqlsudo rm -rf /usr/local/var/mysqlsudo rm -rf /Library/StartupItems/MySQLCOMsudo rm -rf /Library/PreferencePanes/My*sudo rm -rf ~/Library/PreferencePanes/My*sudo rm -rf /Library/Receipts/mysql*sudo rm -rf /Library/Receipts/MySQL*sudo rm -rf /private/var/db/receipts/mysql

验证效果

删完之后再用brew装一遍，问题解决了……

brew install mysql# 看看是不是启动了lsof -i :3306

再然后就可以愉快的玩了……

此次实践对比相对知名的框架：single-spa，icestark，qiankun

其中在微前端这篇文章中我们可以看到，icestark，qiankun，Magix 三个都是阿里旗下的产物，分别由 baba 和 mama 实现。下边将对各个框架逐一踩坑

开始之前，我先从stateofjs找了排前三的前端框架作为子项目

single-spa

• 官网：https://single-spa.js.org/docs/getting-started-overview
• 类型：
  • application / parcel：同属 UI 层，区别是前者为特定路由渲染微前端 UI，后者不受路由限制（通用组件 UI）
  • utility module (styleguide, api cache, etc)：逻辑层，暴露（通用）共享逻辑（helpers…）
  • root config：微应用入口配置（至少得有一个）。包括一个被所有 single-spa 应用共享的 html 文件和一个注册子应用的 js 文件，当然二者是可以合并成一个文件的，即可以在一个 html 里完成所有配置。

新项目接入

整个新建过程使用create-single-spa命令生成脚手架代码，请npm install -g create-single-spa先

1. 创建俩不同框架的 application

mkdir single-spa-demo && cd single-spa-demo && mkdir apps && cd appscreate-single-spa react-appcreate-single-spa vue-app

2. 创建 root-config

注意Organization这里不要为空，否则会有问题

3. 启动微服务并尝试接入子应用

启动基座

如果直接启动，你会发现有这个问题：Unable to resolve bare specifier ‘single-spa’。然后你需要从**cdnjs手动添加一个库。后来从官方了解到>=1.8.0**之后就没有这个问题了，实测是这样。所以如果遇到这个问题，请更新 cli 版本

实际上在index.ejs中，我们可以看到还有一个systemjs-importmap是被注释起来的。我们打开注释并加入依赖的核心库

<script type="systemjs-importmap" src="/importmap.json"></script>

{  "imports": {    "single-spa": "https://cdnjs.cloudflare.com/ajax/libs/single-spa/5.5.1/umd/single-spa.min.js",    "react": "https://cdnjs.cloudflare.com/ajax/libs/react/16.13.1/umd/react.production.min.js",    "react-dom": "https://cdnjs.cloudflare.com/ajax/libs/react-dom/16.13.1/umd/react-dom.production.min.js",    "vue": "https://cdnjs.cloudflare.com/ajax/libs/vue/2.6.11/vue.min.js"  }}

接入子应用

react和vue按照上面的命令一顿操作下来基本没啥问题，但svelte命令里没有集成，所以我们需要人肉集成

npx degit sveltejs/template svelte-app

然后参考：https://single-spa.js.org/docs/ecosystem-svelte

这样一顿操作之后，你又会发现Svelte挂掉了

紧接着，你需要把代码稍加改造

const svelteLifecycles = singleSpaSvelte({  component: function () {    return SvelteApp;  },  domElementGetter: () => document.getElementById("svelte-app"),  props: {},});

此时，三大框架均已成功融合到single-spa微应用了

registerApplication({  name: "svelte-app",  app: () => System.import("@thomas/svelte-app"),  activeWhen: "/",});registerApplication({  name: "react-app",  app: () => System.import("@thomas/react-app"),  activeWhen: "/react",});registerApplication({  name: "vue-app",  app: () => System.import("@thomas/vue-app"),  activeWhen: "/vue",});

<script type="systemjs-importmap">  {    "imports": {      "@thomas/root-config": "//localhost:9000/thomas-root-config.js",      "@thomas/react-app": "//localhost:9001/thomas-react-app.js",      "@thomas/vue-app": "//localhost:9002/js/app.js",      "@thomas/svelte-app": "//localhost:9003/build/bundle.js"    }  }</script>

icestark

• 官网：https://ice.work/docs/icestark/about
• 核心：
  • 框架应用：一个系统只有一个框架应用，框架应用负责系统整体的 Layout 以及子应用的管理与注册（由于目前的 API 设计参考了 React Router，同时为保证开发体验，框架应用跟 React 做了耦合，所以框架应用必须基于 React）
  • 子应用：通常是一个单页面应用，可能包含一个或多个页面，子应用负责自身相关的几个页面代码。

新项目接入

相比single-spa，icestark 的接入姿势简单许多，官方文档又是中文的，建议直接搬命令操作。

整体感觉封装的比较彻底，不需要过多配置。新项目入手还是很方便的，唯一会有的问题就是官方基座模板使用了icejs，无形之中又增加了一种学习成本。

改造旧项目

为了探究icestark的能力，这里我用改造旧项目的方式整合一个微前端应用。首先还是用官方的姿势创建一个框架应用

子项目改造

首先添加依赖yarn add @ice/stark-app，然后根据官方文档进行已有项目改造子应用。一切顺利的话，如下图就完成了 icestark 的整合！

qiankun

• 官网：https://qiankun.umijs.org/zh

从官方介绍来看，乾坤是基于single-spa的微前端实现库。因此一些概念和实现可能需要往上再看一遍

新项目接入

qiankun不像single-spa官方那样提供一个cli命令去生成主应用和子应用，也不像icestark那样主应用必须是 React。因此对于qiankun大法，主应用可以自由选择，比如用create-react-app或vue-cli。此处用@vue/cli 4.3.1创建主应用

另外官方例子中，有二者的实现，有需要可以参考一下：examples。主应用创建完成后，基本上按照官方的文档一顿操作即可集成

qiankun 官方文档相当简介，以至于稍不注意就看完了，我竟然还会有一种意犹未尽的感觉…以为上了个假官网！

总结

几乎遵循这两年流行的思想，即：「去中心化」。分治而又在某个统一规则下玩，除了single-spa，后边的icestark和qiankun都分别支持html entry，即某种成都上用一样的方式解决了样式隔离等微前端核心难题

从接入的友好性和研发成本来看，阿里的库无疑是比较好的选择，而icestark和 React 绑的比较重，从官方文档可以看到他们还有很多事情要处理，所以综合下来qiankun算是目前最好的微前端框架了。

之后有时间再剖一篇原理实现，敬请期待！

资料

• 助力 20+ 阿里内部平台级系统，面向大型应用的开源微前端解决方案 icestark
• 这可能是你见过最完善的微前端解决方案！
• Vue + Qiankun 快速实现前端微服务
• 基于 qiankun 的微前端实践

声明：本文说的保养是指汽车保养

记录一下第一次被 4S 店坑的经历，关于新手用车保养那些你必须清楚的事情，献给所有新车手。

文章标题可能有那么一丢丢的标题党，但我认为，这并不重要！如果你恰好是一位刚买车的新司机或准车主，本文可能会帮你省几百大洋 :-)

至于为啥说是年轻人的第一次，其实事后想想也蛮有代表性：一方面自嘲，另一方面我觉得绝大多数人都会踩进这个坑（除非车车是充话费送的）

首保那点事情

我的保养故事

自从提了爱车成为非专业老司机后，惊喜一直不断。一晃就从 6km 飙到了 5836km（当然不全是我自己行驶的距离），首保将至，内心也惶恐万分，毕竟印象里各种说法都暗示 4S 店保养神坑……

带着这种纠结的心情，5 号去了 4s 店，接待挺热情，一顿操作后手续就办下来了。因为住处停车非常艰难，本来想车子给他们我先忙我的去，等我哪天想用车了再过来提，不料这个羊毛没有薅成，所以就不得不去休息室耐心的等待了

首保内容

• 机油机滤
• 空调出风口清灰
• 胎压及其他方面例行检查
• 专业洗车一次（免费）
• 燃油添加剂（自费 218）

客户经理基本上是照着保养手册执行，其中有个燃油添加剂惹得我不太爽。他的解释是换机油有个回流过程，机油会回流到汽油油箱里导致一些问题，加这个的目的是为了清理发动机…而且还是必须要弄的！

其实我大概知道这个玩意是啥用途，毕竟从去年买车开始就一直关注某档说车的音频节目。包括后边跟朋友确认了下，同款车型人家保养就没提这个事情，算是一个可有可无的操作。到我这里就成了强制销售……

可以看到下边这张图，我从某宝搜到的商品，一样的东西一样规格，价格只有一半不到。可以肯定的是，4s 店拿货价格比某宝的价格还要低，所以这其他的价格差去哪儿了？既然免工时、机油、机虑这些保养常用操作，那多的这些会不会就是休息室里喝咖啡的钱！？

后边想了想，其实当时如果坚持不要这个应该也可以正常保养（或者换个说法家里有一模一样的东西），毕竟这个不是保养时必须加进去的东西，自己后续等燃油耗尽加进去或者不加其实没啥影响，实属可选项目！另外客户经理给的理由也不太能经得起推敲……

正是由于担心会伤害发动机或因不选择服务影响整体质保，所以选择相信，继而被套路。人家也是抓住客人这点心理，所以还是自己 too young too…

避坑琐事

从我的事故后，有以下几点经验供参考

1. 不要轻易相信 4S 店的客户接待，不管他们怎么说、怎么用保养指南“威胁”；
2. 对于要保养的项目，问清楚是否必须由师傅现场施工、还是自己回去在某个时间操作，如果上网方便，简单查一下要保养的项目；
3. 保质期内，车不会那么容易坏的。要有起码的自信（胡作除外），4S 接待不见得就很懂技术，但话术他比我们懂得多（要敢于追问和质疑），不想做的项目果断拒绝；
4. 基本上，新车前 3 次保养，都只需要换机油机滤，空气质量差的地方，可以适当换下空掉/空气滤芯，仅此而已；
5. 如对机车有兴趣，平时多积累相关理论知识（这里推荐一下备胎说车）。实操能力强的选手，可以自己动手保养（比如换空调滤芯就很简单）；

事实上除了 4S 店，目前有很多线上服务可以选，费用都比较合理，比如：xx养车，x团。另外，自己购买正品配件然后去维修店搞（仅支付工时）也是一个不错的选择

关于汽油

汽油之间也有学问

汽油这个事情，没车之前没咋关注。没想到这里面水也不浅…中石油、石化、壳牌甚至乙醇汽油这些常用油，最近看了些资料，说说结论：

1. 组织模式

国营：中石油、中石化、中海油
合资：壳牌、道达尔、BP
民营：以莆田系为主，比如中国国际能源、亚孚石化、中国油联、中图、中胜等

2. 地理分布

北方：中石油、延长壳牌（我老家陕西会多一些）、乙醇汽油（东北三省、河南、安徽 5 省等）
南方：中石化

3. 优劣情况（个人结论）

延长壳牌 > 中石油 > 中石化 > 乙醇汽油

注意：论环保程度，那得把乙醇汽油排第一位了。但是正常情况来看，油价贵、动力差、油耗高这三项可能不太会有人选它。当然某些观点会认为中石化的优于中石油（既定事实是炼油技术里中石化确实 NB，而本身不负责原油开采），不过都是国标油三者里取距离最近岂不更好！

4. 资料

乙醇汽油
乙醇汽油 2020 年将全面推广，有些话总要有人告诉您
2019 年中国加油站品牌力分析

大前端时代下，大型单体架构模型面临三大难题：扩展性差、团队维护成本大（耦合度与复杂性）、编译部署效率低下

概念

微前端是一种架构风格，其中众多独立交付的前端应用组合成一个大型整体

类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立运行、独立开发、独立部署。

与业务组件/widget 区别

部署方式

价值

• 工程价值
  • 优点
    • 独立开发和部署
    • 大型单页应用无限扩展
    • 不限技术栈
    • 多团队协作
  • 缺点
    • 体验有折损（子应用异步加载不如 SPA 如丝般顺畅）
    • 维护成本高（子应用拆太多，多个仓库，共用组件复用都是问题）
    • 管理版本复杂、依赖复杂
    • 开发体验不太友好（需要不同工程切换以及启动多个子系统）
    • 粒度不宜太小（跟通用组件区分好）
• 业务价值
  • 产品“原子化”（根据业务自由的编排组合）：扩展性、组合性、局部迭代
  • 解决能力输出最后一公里的价值（使得别人集成你的能力变得简单）
  • 云生态的新物种 —– 微应用

现状

业界方案

• single-spa
• Mooa（适用于 NG 的微前端框架，基于 single-spa）
• Ara Framework（基于 airbnb 服务端渲染的微前端框架）
• Ali
  • baba
    • WidgetJS（轻量级的微前端方案，不过文档不友好）
    • icestark（自主研发，较 single-spa 更简单轻量级的微前端框架）
    • qiankun（基于 single-spa 的框架无关的微前端框架）
  • mama
    • Magix（通过特有的 vframe(类似 iframe 的思路)帮你把页面按区块化拆分）

起飞资料

• 未来前端开发的新趋势 — 第四部分
• 大前端时代下的微前端架构：实现增量升级、代码解耦、独立部署
• 目标是最完善的微前端解决方案 - qiankun 2.0
• 微前端 qiankun 项目 实践 !!! 防踩坑指南
• 微前端方案 icestark 的现在与未来
• 面向大型工作台的微前端解决方案 icestark
• 年度文章集合 | 最全微前端集合
• 第十四届 D2 前端技术论坛视频

昨晚失眠到凌晨两点，于是开始听歌，辗转反侧时意外发现 QQ 音乐上王卡老用户有绿钻羊毛可薅，于是欣然薅掉。之后把之前不能听的挨个听了个遍……

第二天，登录 macOS 桌面版，把经常喜欢听的全部用无损格式下载了一遍，然而发现下载文件格式是被加密过的（也在情理之中……）。然后找了找解码工具，还真在万能的 github 找到了：https://github.com/Presburger/qmc-decoder

一顿操作后，所有文件顺利解码。剩下的问题是，测试这些爱曲是不是真的FLAC

所以

第一轮测试：auCDtestTaskManager

通过率：89.05%

第二轮测试：Lossless Audio Checker

通过率：100%

失败文件名称

• 周杰伦-床边故事
• 周杰伦-告白气球
• 周杰伦-说走就走
• 周杰伦-爱情废柴
• 周杰伦-前世情人
• 周杰伦-一点点
• 周杰伦-Now You See Me
• 周杰伦-不该
• 周杰伦-画沙
• 周杰伦-等你下课
• 周杰伦-说好不哭
• 周杰伦-不爱我就拉到
• 周杰伦-龙卷风 live
• 林俊杰-爱要怎么说出口
• 林俊杰-女儿情 live
• 林俊杰-输了你赢了世界又如何 live
• 张信哲-平凡之路 live

失败文件再检测

通过一波波操作，选出合格的无损文件

最后，sony-1000xm3 走起…

因为

先介绍下工具本身

MWeb是一款 macOS 下优秀的markdown工具，很早之前有个活动，于是在水果店买了一份，那也是第一次花钱买正版软件

你还别说，真是香！

后来，不知道为啥升级到 3.x 之后，开始重新收费了。我以为之前买断了版权，没想到这个跟 windows 还挺像，哈哈

所以

看下写文章结合图片的配置吧，请注意我这里是：2.3.0 (316) 版本

配置步骤如下

注意第二步的media save path这个要选absolute，这样当你用微信或 QQ 截图粘贴时，它会自动把图片保存到media foler name拼起来的那个文件夹里

这个操作还是很方便图片管理的，最终结果图片和文章友好共存，在本地和线上都能正常预览！

这个文章主要是记录下配置，方便日后换机。之前误删过 MWeb App，后来找不到添加外部文件夹的地方了……所以！

多说几句

玩了这么多年电脑，从windows到linux再到mac，每个平台下都有非常精致的效率工具。不过由于众所周知的原因，win 下的体验其实并不太好，在转行做iOS开发后，我基本上就没再用过 win 了（虚拟机除外，这没办法，你懂的）。

对于一款好用markdonw工具，我个人觉得，非常重要。从现实情况来看，目前还没有免费的并且非常好用的工具，再体验了 N 多付费版本后，我觉得MWeb非常对我的胃口。主要有以下这么几点特色（以版本 v2.3.0 为基准）：

• 强大的自定义主题支持，可以根据自己的喜好，定制各种样式，甚至可以定制自己的主题，然后分享给别人；
• 强大的编辑工具，可以直接在编辑器里写 markdown，然后直接预览，省去了很多麻烦；
• 支持从剪切版里复制图到文档中（截图或网络图片均支持），前文提到的配置就是这个特征。这点在其他类似工具没发现（貌似也没那种配置法）；
• 扩展能力，这个没做过多研究，不好评价。不过有总比没有强；

最后，传送门如下，有缘的朋友可以试试：

• https://zh.mweb.im

Electron 姿势

在这次着手准备之前，我把希望放到了Electron上，于是分别调研了electron-vue和electron-react

一顿脚手架把玩之后，除了后者看起来规范一些外，前者运行都报错issues。如果你是非常钟爱 react + redux + ts 组合的人，那入坑就对了。基本上你要的模板代码都有，包括prettier这种都是给你配置好了的，工程化结构很清晰。反观 vue 模板，electron 版本竟然在2.0.18……wtf，这都 2020 年了，查了下那还是 9012 年 3 月份的版本，这一年Chrome都升级 N 次了，注意现在已经到 81.x 了……

除了版本落后外，vue 库更新算是比较慢了，最后一次提交是在 4 个月前。react 版本是 9 天前，所以这也是为啥推荐入坑 react 版本的原因。当然，我比较头疼是不只是版本问题，Electron 本身存在的重大缺陷之一的打包文件体积大似乎这段时间并没有啥改善……

于是我又看了下它表兄弟：electrino，好家伙更新倒是在 29 天前，不过文档写的迷一样，几乎不知道怎么开始，有个issues比较有意思，之后随便翻了下 google 发现资料少的可怜，于是我也就准备弃坑了！

在这之后，我把目光放到了：react-native

React-Native 大法

如我之前调研的结果一样，这么长时间以来这个方向几乎还是那几个库，其中react-native-macos也已经半年没有过提交记录了，我试着运行了下脚手架，但初始化都失败了，见issues。然后releases列表里头最近的 tag 是支持到 RN44，拜托现在官方已经 62.2 了，看来作者差不多也是弃坑跑路了……

不过 windows 下的react-native-windows在微软强有力的支持下，更新倒是挺频繁，我也相信应该是目前 React-Native 大法最佳的桌面端实现，不过我用的是 macOS，就没再去尝试 demo……有 windows 条件和需求的可以看看，人家确实挺用心在搞：getting-started

一个小插曲，我发现RN-Win 官方说支持 Mac，结果文章下头却是：Coming soon!。翻到ms-rn后，我又发现一个MR

看上去，微软这个库支持 Mac 啦，我带着惊喜的心情做了如下尝试，结果发生了这些事情：issues

最终，通过各种猜测尝试，微软的这个库在 macOS 下终于跑起来了（顺便还在本地搭起了 npm 私服，虽然只有一个 package……）

私服的小插曲

在用Verdaccio为ms-rn搭私服的过程中，还遇到个问题，就是当我直接把微软的代码 pull 到本地 publish 到私服去用时，cli 竟然是拉的0.60.0-microsoft.67版本，就算指定了最新的 latest，react-native init AwesomeApp也是执行失败，后来意识到私服上没有这个版本，于是切到 tag 里疯狂的 publish 了一顿，最终初始化成功

工程相关

Letsnote

结果还是比较理想的，简单的开发体验非常友好，另外 Electron 体积大的问题，RN 方案算是质的飞跃，即使 demo 也要 12.8 MB

资料

• https://simulatedgreg.gitbooks.io/electron-vue/cn/
• https://juejin.im/entry/5c64db9851882562851b328f
• https://github.com/microsoft/react-native/pull/291

出自ES6的 Array，用来做累加的。以前我一直用来做算术求和，直到前一阵子看到了一个骚操作，于是又做了一番折腾…

看这段代码先：

const names = ["jack", "pony", "tony", "thomas"];const entry = names.reduce((prev, cur) => {  prev[cur] = `My full name is ${cur} ma.`;  return prev;}, {});

结果：

{ "jack": "My full name is jack ma.", "pony": "My full name is pony ma.", "tony": "My full name is tony ma.", "thomas": "My full name is thomas ma." }

把一个数组转成了对象，如此优雅的操作。试想，不用这个如何达到效果！？

const names = ['jack', 'pony', 'tony', 'thomas'];const obj = {};for (let name of names) {    obj[name] = `My full name is ${name} ma.`}

此时，多定义了一个变量，用了一层循环，看起来很没科技感。戳到 API，我们可以看到它是这么定义的：

reduce(callbackfn: (previousValue: T, currentValue: T, currentIndex: number, array: T[]) => T, initialValue: T): T;

是的，第二个参数竟然是泛型。之前一直传数字做累加，今天记住了。

所以

reduce 功能不止于此…

这篇文章所谈到的内容非常基础，如果你已经是一个前端老司机了，请直接掉头加足油门离去。

科普

REM

CSS3 新增的一个相对单位，来自 2013 年。全称：font size of root element。可根据网页根元素来设置网页中其他字体大小。

其中根元素指html标签，即：在html标签里设置font-size属性，以此来作为其他rem值的基准，从而取得自适配平衡。另外除了用来设置字体大小，rem 还可用来设置视图的：width，height，margin，padding…

EM

作用与 REM 类似，但早于 REM，算是他的前辈。全称：font size of element。相对于当前对象内文本的字体尺寸。如当前对行内文本的字体尺寸未被人为设置，则相对于浏览器的默认字体尺寸。其特点如下：

• em 值并不是固定的；
• em 会继承父级元素的字体大小；

使用 rem 为元素设定字体大小时，仍然是相对大小，但相对的是 HTML 根元素。而 em 是相对于父级元素；

实操

与 PX 的转换

px 像素（Pixel），相对长度单位。是相对于显示器分辨率而言。

目前对于大部分浏览器，如果不修改相关字体配置，都是默认显示font-size:16px，于是和 rem 的映射关系有：16px = 1rem。

html {  font-size: 16px;}

如果想给一个 p 标签设置 12px 的字体大小，那么用 rem 表示就是

p {    font-size: 0.75rem; // 12/16=0.75(rem)}

单位转换的工具：pxtoem

移动端的适配

media queries

最早，我刚接触响应式那会儿，是通过css3 的 media queries来获取当前设备屏幕尺寸，然后对应写几套 css。但这玩意的副作用就是代码量很大，维护不方便（为了兼顾大屏幕或高清设备，会造成其他设备资源浪费，特别是加载图片。毕竟加载流量和时间也是要成本的）。代表作：Bootstrap

flex 或百分比（%）

号称弹性布局的就是。查得资料所言，大部分套路皆为：flex+百分比的布局方式。另外，不需要适配的地方仍然是 px 单位。

其中，百分比是相对于父元素，正常情况下是通过属性定义自身或其他元素

rem（本文主角）

这个特性目前主流浏览器都支持，可以放心用。适配步骤：

1. viewport 设置

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0" />

其中 width=device-width 用于设置 viewport 的宽度等于屏幕的宽度，initial-scale=1.0, maximum-scale=1.0 的作用同 width=device-width 一样

之所以还要同时设置这两者，是因为当它们单独使用时，表现不够完美，即单独使用时，浏览器会有兼容性问题。另外当两者值不同时，浏览器取最大者。

2. 动态设置元素的 font-size 值。一般有俩姿势

• 利用 css 的media query来设置，好处是都是在样式表里，好管理；
• 利用javascript 动态操作 dom 属性来计算基准值；

样式设置

@media (min-device-width: 375px) and (max-device-width: 667px) and (-webkit-min-device-pixel-ratio: 2) {  html {    font-size: 37.5px;  }}

脚本设置

document.getElementsByTagName("html")[0].style.fontSize = window.innerWidth / 10 + "px";

这里除以 10，是为了控制数字不至于太大，便于后边计算，是随便定义的。即定义屏宽为：10rem，10rem * font-size = 设计宽度

3. 编写统一的计量单位值

在编写 CSS 元素时，width/height，margin，padding 等时，使用rem作为单位。换算方式如上文提到的那样。可以参考以下公式：

具体属性值 = 设计稿上的标注 / 设计稿的宽度

当然如果你是使用诸如 Less 这样的动态样式表语言的话，可以参考下边说的操作。这样就计算出设计稿上的元素和设计稿的比例了。

在 Less 中的应用

为了统一尺寸计算，可以造一个新的单位，比如：wem

module.exports = {  /**   * 基础尺寸换算。(eg in less: wem(1px))   * @param less   * @param pluginManager   * @param functions   */  install(less, pluginManager, functions) {    functions.add("wem", function (data, base) {      const bem = base ? base.value : 36;      return less.dimension(data.value / bem, "rem");    });  },};

在公共的 less 文件中，可以引用以上插件：

@plugin "less-plugin";// 外部的使用方式，直接用设计稿尺寸@contentWidth: wem(360);@padding: wem(10);

此时的 360 为设计稿的宽度，less 插件中的默认 36 是以设计稿 360px 为准的，如果你是 640px，换成 64 即可

延伸

DPR

设备像素比（device pixel radio），设备像素比（dpr） = 设备像素（分辨率）/设备独立像素（屏幕尺寸）。用人话说，就是常说的 2 倍图、3 倍图中的那个数字倍数

一般情况下，我们设置initial-scale=1.0就可以了，但是对于 dpr 大于 1 的，我们还需要精细化一波操作，可以用window.devicePixelRatio获取当前设备的 dpr，然后动态设置viewport

let drp = window.devicePixelRatio;meta.setAttribute("content", "initial-scale=" + 1 / dpr + ", maximum-scale=" + 1 / dpr + ", minimum-scale=" + 1 / dpr + ", user-scalable=no");

如此，配合 rem，就可以完全按设计稿标注来了，也不用再除以 2、除以 3。好处是：

• 解决了图片高清的问题；
• 解决了 border 1px 的问题。比如设置了 viewport 的 scale 为 0.5，在 2 倍屏下，1px 的 border 就被缩放成 0.5px，更为细腻；

VW VH VM

视口单位（Viewport units），之前写 Vue 时偶然发现的。是相对于视窗的宽高度，值为 100。VM（VMin），即：取决于哪个更小

对于移动端而言，最重要的是如何多终端兼容。以上介绍的响应式也好、REM 也好都各有千秋，而 REM 使得 CSS 和 JS 耦合在了一起。VW和VH的诞生解决了这一难题，目前来看，是最趋于完美的做法。具体做法参考以下资料：

参考资料

• 移动 web 适配利器-rem
• 掘金：移动端/web 端适配方案
• 视区相关单位 vw, vh..简介以及可实际应用场景
• vh,vw 单位你知道多少？
• 利用视口单位实现适配布局

在线 DEMO

• REM 布局 - 淘宝聚划算
• 视口单位布局

人的一生，最多能被贴多少标签，又有多少是专属的，这是一个值得胡思乱想的问题…

由于之前博客的文章分类比较乱，今天周末，就来梭哈一下。弄完看了看，发现还挺有意思，不知不觉诱发了我的胡思乱想症

见过有的同学搞博客，恨不得把好123的栏目全搞一遍，很少有人把减法做的很美…让我想起之前看到的一个故事，说是老外设计一个产品时，往往只需要满足一个或很少几个核心Tag即可；而大多数国人则更倾向于搞一个大而全的产品，恨不得大家就用我的，其他可以卸载了一样…

我记得之前有人在 Github 提Bug说，JSimple 配置太多导航，在小屏机就出问题了。事实上我老早就知道，我故意没修复而已，就是想提醒诸位：做减法啊，其实都是可以归纳提炼的。好吧，我承认我懒。哈哈

default_category: 技术category_map:  技术: tech-notes  人文: humanities  其他: otherstag_map:  ## language tags  dart: dart  swift: swift  objective-c: oc  java: java  python: py  javascript: js  typescript: ts  ## platform tags  苹果: ios  安卓: android  麦克: mac  ## frameworks  vue: vue  react: react  flutter: flutter  react-native: rn  hexo: hexo  ## client tags  后端: back-end  前端: front-end  跨端: cross-app  ## others  读书: reading  旅行: traveling  码常规: dev-tips  黑科技: cool-tech  碎碎念: impression

如上所示，这次将几个核心技能组合了下，之于WebX这个神器的标签，我今天刚发明的。因为叫 Web2.0 吧，过一阵还得换成 Web3.0，4.0，5.0…最后还得是 X 或 XS Max

我在想，当我不写码的时候，是否可以做到熟练掌握这些标签，如果可以。则不枉一代优秀的程序员。这些标签也时刻提醒我自己，在技术上别太偏离轨道…

胡乱思想

人的标签其实也一样，比如常说的首富这个标签，大家自然会想起：互联网二马老师，房事界王老师等人…

被赋予公认社会标签的价值和拯救地球的能力成正比，对于那种专属标签，普通人恐怕一辈子都难以得到。我们普通人要做的，恐怕还是做减法，努力让自己成为某个领域那拥有一个标签的人，而不是那种大而全的人……

我是：儿子，爸爸，写手，老公，90S，私企员工，码农，未来 De 企业家……你呢？

Preact，读：['pri:ækt]，而非批React。跟 Pure React 也扯不上什么关系。

是由谷歌的一群大兄弟开发和维护的优化版React。这并非造个轮子要取代 FB 的React，通过一些资料和实践，发现这个轮子并不简单。具体可以链接到官网，中文说明足够友好，作者真是太赞了。

官方：Preact 官网
项目地址：Preact

实践笔记，第一部分

这也并非是近期的新鲜事物，只是我个人刚接触罢了。从这一个月的使用看来，这个确实比 React 简单一些。比如核心库直接去掉了PropTypes这种东西，对Render也进行了优化，搭配TypeScript和Less使用，爽的么法…

一. 这里记录下开发环境的配置，主要依赖情况

• Preact: ^8.2.6
• typescript: ^3.2.4
• Less: ^3.9.0
• Webpack: ^4.29.0

"scripts": {        "dev": "NODE_ENV=development webpack-dev-server --config scripts/webpack.config.js",        "build": "NODE_ENV=production webpack --config scripts/webpack.config.js",        "ts-build": "tsc --pretty --outDir ./modules",        "ts-watch": "tsc -w --pretty --outDir ./modules",        "pm2-dev": "pm2 start npm --name prdemo -- run dev && npm run ts-watch",        "pm2-clear": "pm2 delete prdemo"    },    "husky": {        "hooks": {            "pre-commit": "lint-staged"        }    },    "lint-staged": {        "linters": {            "*.{js,jsx,md,json}": [                "prettier --write",                "git add"            ],            "*.{ts,tsx}": [                "prettier --write",                "tslint --fix",                "git add"            ],            "*.css": [                "stylelint --fix",                "git add"            ],            "*.less": [                "stylelint --fix --syntax=less",                "git add"            ]        },        "ignore": [            "./modules/**"        ]    },    "eslintConfig": {        "extends": "eslint-config-aerian"    },    "eslintIgnore": [        "build/*"    ],    "stylelint": {        "extends": "stylelint-config-standard",        "rules": {            "indentation": 4,            "number-leading-zero": null,            "at-rule-no-unknown": [                true,                {                    "ignoreAtRules": [                        "plugin"                    ]                }            ],            "selector-pseudo-class-no-unknown": [                true,                {                    "ignorePseudoClasses": [                        "global"                    ]                }            ]        }    },    "dependencies": {        "preact": "^8.2.6"    },    "devDependencies": {        "@types/jest": "^23.3.13",        "@types/node": "^8.10.38",        "copy-webpack-plugin": "^5.0.0",        "css-loader": "^2.1.0",        "file-loader": "^3.0.1",        "html-webpack-plugin": "^3.2.0",        "husky": "^1.3.1",        "jest": "^24.0.0",        "less": "^3.9.0",        "less-loader": "^4.1.0",        "lint-staged": "^8.1.1",        "mini-css-extract-plugin": "^0.5.0",        "mkdirp": "^0.5.1",        "preact-async-route": "^2.2.1",        "preact-render-spy": "^1.3.0",        "preact-router": "^2.6.1",        "prettier": "^1.16.1",        "recursive-copy": "^2.0.10",        "style-loader": "^0.23.1",        "stylelint": "^9.10.1",        "stylelint-config-standard": "^18.2.0",        "ts-jest": "^23.10.5",        "ts-loader": "^5.3.3",        "tslint": "^5.12.1",        "tslint-config-prettier": "^1.17.0",        "tslint-consistent-codestyle": "^1.15.0",        "tslint-eslint-rules": "^5.4.0",        "tslint-react": "^3.6.0",        "typescript": "^3.2.4",        "typings-for-css-modules-loader": "^1.7.0",        "uglifyjs-webpack-plugin": "^2.1.1",        "url-loader": "^1.1.2",        "webpack": "^4.29.0",        "webpack-cli": "^3.2.1",        "webpack-dev-server": "^3.1.14"    }

之所以加了pm2，是因为有两份TypeScript源码需要 watch，Webpack本身 watch 占用一个 console 窗口，tsc 自己也要有。如果一个命令启动，就会导致一个卡在另一个之前，导致另一个无法启动……所以索性把 webpack 直接放到了后台。其本身作为 Server 服务，也算合理。不过正常情况，不会像我这么变态……

二. TSC

{  "compilerOptions": {    "charset": "utf8",    "sourceMap": true,    "rootDir": "./src/",    "outDir": "./modules",    "skipLibCheck": true,    "allowSyntheticDefaultImports": true,    "target": "es5",    "module": "es6",    "lib": ["es6", "es7", "dom"],    "allowJs": false,    "jsx": "react",    "jsxFactory": "h",    "strict": true,    "declaration": true,    "moduleResolution": "node",    "noImplicitAny": false,    "esModuleInterop": false,    "experimentalDecorators": true,    "removeComments": false,    "preserveConstEnums": true  },  "include": ["./src/**/*"],  "exclude": ["docs", "modules", "typings", "node_modules"]}

注意jsxFactory使用的是h，这个h是Preact的核心之一

三. Less 的一点问题

1，正常使用 import 引用 less 时，IDE 会报错提示Cannot find module './style.less'.。直接加@ts-ignore可以忽略，但不是好方法

// @ts-ignoreimport style from "./style.less";

如上所以，解决方式也很简单：第一新建less.d.ts文件，第二在该文件内申明less

declare module "*.less";

然后，在基类中引用，注意不是 import，而是reference指令

/// <reference path="../../typings/less.d.ts" />

2，组件上，用点语法使用 less 的选择器。但又得注意，style.className的值是随机字符串，并非对象，因此不能接着点（内层嵌套拿不到值），即：style.className.Name1非法

a {  &.normal {    color: #333;  }  &.active {    color: #fff;  }}

以上用法如下：

<nav class={isActive ? style.active : style.normal}>{txt}</a>

四. Preact 无状态组件使用

import {FunctionalComponent, h} from 'preact';import style from './style.less';interface INavProps {    transparent?: boolean,    title?: string,    onBack?: (index) => void    onHome?: (index) => void,    onShare?: (index) => void}export const Navigator: FunctionalComponent<INavProps> = ({transparent, title, onBack, onHome, onShare}) => {    const onBackPress = (e) => {        if (onBack) {            onBack(e);            return;        }        // TODO.    };    const onHomePress = (e) => {        if (onHome) {            onHome(e);            return;        }        // TODO.    };    const onSharePress = (e) => {        if (onShare) {            onShare(e);            return;        }        // TODO.    };    const className = transparent ? style.transparent : style.normal;    return (        <nav class={className}>            <button class={className} onClick={onBackPress} />            <span class={className}>{title}</span>            <button class={className} onClick={onHomePress} />            <button class={className} onClick={onSharePress} />        </nav>    );};

五. 其他方面

由于着手的这项目有点怪，所以自制了一款 webpack 插件，其中有用到了recursive-copy。需要把指定文件夹里的非 TS 和 TSX 拷贝到另外的目录，配置其filter时曾让人蛋疼不已……具体请看minimatch。结论是这玩意跟一般正则不一样，当时按正则咋配咋不对

// 过滤ts和tsxconst OPTIONS = {    overwrite: true,    expand: true,    dot: true,    filter: ['**/*.!(tsx|ts)'],};

扩展阅读

• Preact：一个备胎的自我修养
• TS-Preact
• preact-material-components

上一篇的更新日志：The-Update-for-JSimple-in-Early2019

其实关于本文主题，Google 一下文章到处都是，然而我找了几篇都是gulp3，对于我这种忍不了旧习的人来说当然不行，于是，我一把梭的弄了gulp4

依赖情况

"scripts": {    "prepublish": "hexo clean && hexo g && gulp",    "publish": "hexo d && hexo b"  },  "dependencies": {    "@babel/core": "^7.2.2",    "@babel/preset-env": "^7.2.3",    "gulp": "^4.0.0",    "gulp-babel": "^8.0.0",    "gulp-htmlclean": "^2.7.22",    "gulp-htmlmin": "^5.0.1",    "gulp-imagemin": "^5.0.3",    "gulp-minify-css": "^1.2.4",    "gulp-uglify": "^3.0.1",    "hexo": "^3.7.0",    "hexo-deployer-git": "^0.3.1",    "hexo-generator-archive": "^0.1.5",    "hexo-generator-category": "^0.1.3",    "hexo-generator-index": "^0.2.1",    "hexo-generator-search": "^2.4.0",    "hexo-generator-sitemap": "^1.2.0",    "hexo-generator-tag": "^0.2.0",    "hexo-git-backup": "^0.1.2",    "hexo-renderer-ejs": "^0.3.1",    "hexo-renderer-marked": "^0.3.2",    "hexo-renderer-stylus": "^0.3.3",    "hexo-server": "^0.3.2"  }

新增的scripts操作，是在写完文章时便于梭哈。之于区分prepublish和publish，是想提醒各位，上线之前先检查下 ：）

Gulp 任务

站点根目录新建：gulpfile.js

var gulp = require("gulp");var minifycss = require("gulp-minify-css");var uglify = require("gulp-uglify");var htmlmin = require("gulp-htmlmin");var htmlclean = require("gulp-htmlclean");var imagemin = require("gulp-imagemin");// 引入babel，万一用了ES6呢var babel = require("gulp-babel");gulp.task("minify-html", function () {  return gulp    .src("./public/**/*.html")    .pipe(htmlclean())    .pipe(      htmlmin({        removeComments: true,        collapseWhitespace: true,        collapseBooleanAttributes: true,        removeEmptyAttributes: true,        removeScriptTypeAttributes: true,        removeStyleLinkTypeAttributes: true,        minifyJS: true,        minifyCSS: true,      }),    )    .on("error", function (err) {      console.log("html Error!", err.message);      this.end();    })    .pipe(gulp.dest("./public"));});gulp.task("minify-css", function () {  return gulp.src("./public/**/*.css").pipe(minifycss()).pipe(gulp.dest("./public"));});gulp.task("minify-js", function () {  return gulp.src(["./public/js/**/*.js", "!./public/js/**/*.{min,mini}.js"]).pipe(babel()).pipe(uglify()).pipe(gulp.dest("./public/js"));});gulp.task("minify-images", function () {  return gulp    .src("./public/img/**/*.*")    .pipe(imagemin([imagemin.gifsicle({ optimizationLevel: 3 }), imagemin.jpegtran({ progressive: true }), imagemin.optipng({ optimizationLevel: 8 }), imagemin.svgo()], { verbose: true }))    .pipe(gulp.dest("./public/img"));});gulp.task(  "default",  gulp.parallel("minify-html", "minify-css", "minify-js", "minify-images", function (done) {    done();  }),);

Babel 大法，毕竟你不能保证在激动时不用 ES6（主要是这货 uglify 对此不友好）

站点根目录新建：.babelrc

{  "presets": ["@babel/env"]}

验证一下

如果没有报错，就很没问题了！目前为止，暂时没发现有不对的地方。嗯，跪求打脸…

👀️提醒我该休息了，大新闻到此为止。明天中文多打一份荤菜奖励自己……晚安 ~ 😴️

效果如上， 更新日志如下

• 修复夜间模式下，一直被诟病的代码高亮部分空白；
• 修复返回顶部按钮在 Chrome 下失效的问题；
• 新增文章置顶功能；
• 新增 DNS 预取条目，尽可能为站点提速；
• 替换搜索模块，使用新的本地搜索，内容关键词也可高亮；
• 优化 404 描述页若干；
• 替换统计模块为Google Analysis；
• 新增文章，分类，标签等处Google AdSense，为大客户提供方便的流量套现操作；
• 新增图片懒加载操作；
• 新增作者统一配置，即优先读文章作者，其次主题作者；
• 国际化(i18N)优化；
• 去掉丑陋的滚动条；
• 优化文字样式、对其方式、屏宽若干；
• 优化配置字段，去掉不必要的配置项；
• 页脚链接优化，增加网站地图；
• 合并资源文件，减少 http 请求（搭配 Gulp 效果更好）；

下边对部分模块分别说明

1. 搜索

由于旧版本（< 0.0.7）的搜索，有样式问题，且无法检索文章内容，关键词也无法高亮。此次更新引入Next主题的Local-Search。

JSimple对此进行了二次修改，改进了搜索函数不合理或者有潜在问题的地方。新增键盘流操作。**正常浏览时，按F键可迅速唤起搜索；再按ESC可关闭搜索**。理想的交互下，应该使用方向键控制检索结果的选择，无奈改动较大，没有足够的时间精力投入，暂且放弃治疗

需要注意的是，搜索需要引入：hexo-generator-search库，它将为检索内容提供数据保障

2. 置顶

Hexo是静态站，没法做到类似WP那样后台配置一下就能顶。因此这个操作只能在生成静态 HTML 时做改变。

新版本目录中，增加了patch操作，其中generator.js就是置顶逻辑处理。需要将其替换到对应目录中，置顶方能生效。

另外两个文件，是对文章增加了timestamp字段，用在配置文章地址时。一般安装主题后，执行一下：./run.sh即可。当node_modules不慎删除或迁移站点后，页需要执行一次。

3. 广告

策略如下

1. 首页列表间：使用自动广告，一般会出现在分类列表中间。考虑到首页加载速度与体验及展示量，特使用自动广告取平衡，即：随缘展示。
2. 归档页：首部横向自适应广告
3. 标签页：尾部横向自适应广告
4. 文章页：分布两侧，以及末尾。

为什么用AdSense，个人基于以下几点：

1. 域名无需备案就能用；
2. 覆盖面广，如果你是针对这个地球的读者，那目前没有比它合适的；
3. 美元到帐，收益可观；
4. 广告质量相对人性化和底线化；

当然，如果观人不喜欢Google套装，请其自力更生…

4. 加速

本次将可以合并的资源，写到了一个文件。如对JQuery的引用不再是从 CDN 拉。引入DNS-Prefetch操作，尽可提高响应速度。

关于 Gulp 压缩资源的操作，请参考这边文章：引入 Gulp 压缩整站资源进一步提高写作效率

5. 将来

• Disqus 新增局部刷新操作
• 搜索结果支持方向键选择
• 更爽的移动端视觉及交互

拖了一个大礼拜，置顶了一大周，终于「象征性」的补完了…… 😅😅😅

因为

今年的年会，是第一次没去现场，可能也永远不会再去现场。毕竟山高皇帝远了…
往年，都是起得早早的，收拾的美美的。然后幻想着，能被运气照顾下，毕竟自己的工号数字很吉利。然而，每次都和大奖擦肩而过😅
屏幕这端看着直播，那边同事个个都是坐拥豪华大奖而归，而我只有下边那个…

想起前段时间朋友圈里看到的一个段子，大意如下：

上帝是公平的，给别人幸福的同时也会遮住你的眼，怕你看见心里难受

如果没有遮住你的眼，自己闭上就好了。做人嘛，开心最重要！

所以

当然，上面都是段子。重点来了…

赶紧去咸鱼，巴拉巴拉的平台。找自己需要的物品，全新未拆封，总有一款适合你

来年，继续加油…嗯，新年快乐！

Happy New Year.

Always belive yourself that good things will come in soon

… Just for fun😊

js 大法也玩了好几年。但今天读到一篇文章，提到了一个词：IIFE，立马傻眼了，这什么鬼…

于是谷歌了一梭…原来就是个自动执行的函数表达式。Immediately-Invoked Function Expression

一句话概括就是：定义时就会立即执行的 JavaScript 函数。以下来自mozilla的权威解释

这是一个被称为 自执行匿名函数 的设计模式，主要包含两部分。

第一部分是包围在 圆括号运算符() 里的一个匿名函数，这个匿名函数拥有独立的词法作用域。这不仅避免了外界访问此 IIFE 中的变量，而且又不会污染全局作用域；
第二部分再一次使用 () 创建了一个立即执行函数表达式，JavaScript 引擎到此将直接执行函数。

在 Javascript 中，圆括号**()**是一种运算符，跟在函数名之后，表示调用该函数。比如，print()就表示调用print函数。

话不多说，看代码

/** * 1. 当一个函数变成IIFE时，其内部的变量不能从外部访问 */(function () {  var name = "Jack";})();// 外部不能访问变量 nameconsole.log(name); // undefined/** * 2. 将 IIFE 分配给一个变量，不是存储 IIFE本身，而是存储其执行后返回的结果 */var result = (function () {  var name = "Jack";  return name + " love Rose";})();// 此时，IIFE就是一个变量，而不是函数console.log(result); // Jack love Rose

所以

• 需要有括号包起来，且两个 IIFE 连着写时，需要加分号；
• 省略函数命名，避免污染全局变量；
• IIFE 内部形成单独的作用域，可以封装一些外部无法读取的私有变量；

一个小知识点

// case1for (var i = 0; i < 5; i++) {  setTimeout(function () {    console.log(i);  }, 1000 * i);}// case2for (let i = 0; i < 5; i++) {  setTimeout(function () {    console.log(i);  }, 1000 * i);}

上面的 case1 和 case2，结果分别是什么？为什么？在看下面：

// case3for (var i = 0; i < 5; i++) {  (function (i) {    setTimeout(function () {      console.log(i);    }, 1000 * i);  })(i);}

case2 和 case3 均打出：0,1,2,3,4。而 case1，则：5,5,5,5,5

嗯，神奇现象之：let-for 搭配…块作用域的应用

题外话，今天突然意识到文章英文标题好像有点怪…ts-study，当时为啥不写成ts-learning呢，明显感觉后者读起来更爽口啊😂️

资料

• 入坑篇 1（前置操作）
• 自定义 tslint & eslint 详细规则
• 官方语法基础
• Typescript Guidelines
• TypeScript Handbook（中文版）
• 深入理解 TypeScript
• awesome-typescript

编码相关

由于官方及其他资料在这方面非常详细了，本文不作基础内容的赘述。这里假定读者已经学习了基础的语法，如基础类型、变量声明等……

1. 新建ts文件

可以选择在项目的根目录建立src目录，然后新建index.ts文件

type CallBack = (value?: string) => void;interface Config {  name: string;  age: number;  todo?: CallBack;}export default class Person {  init: Config;  constructor(init?: Config) {    if (init) {      this.init = init;      this.init.todo =        init.todo ||        ((value?: string) => {          console.log(value || "This person have been created...But nothing todo");        });    }  }  public todoSomething() {    // this.init.todo();    this.init.todo("Hello World. Welcome to learn TypeScript");  }}

2. 配置编译选项tsc、文档生成、头文件等

"scripts": {    "tsc": "tsc",    "dev": "npm run tsc -w",    "types": "tsc -d --emitDeclarationOnly --allowJs false --declarationDir ./@types",    "build": "build options...",    "prepush": "npm run tsc && npm run types",    "prepublish": "npm run prepush && npm run build",    "typingsdoc": "npx typedoc --out ./typings/doc  ./src/**/*.ts  --module umd"}

其中这块的配置，在part1提到过，包括同时生成头文件并允许 js 文件输入

这里把新增加的，简要说明下：

• dev: 监听.ts 文件改动，实时编译。即增加-w参数可避免手动编译
• prepush: 合并了两个命令，并且git push时，会被触发。以此可强制推送前编译最新代码
• prepublish: 同样合并两个命令，在即将发布上线时使用
• typingsdoc: 生成 Api 文档。关于这个，不清楚的读者请看这篇文章：Typedoc 使用笔记

3. tslint 及 tsconfig

// tslint.json{  "defaultSeverity": "error",  "extends": [    "tslint:recommended",    "tslint-config-prettier"  ],  "rules": {    "encoding": true,    "no-console": false,    "object-literal-sort-keys": false,    "interface-name": [true, "never-prefix"],    "no-unused-expression": [true, "allow-fast-null-checks"],    "only-arrow-functions": false,    "no-duplicate-imports": true,    "no-mergeable-namespace": true,    "import-spacing": true,    "interface-over-type-literal": true,    "new-parens": true,    "no-shadowed-variable": [      true,      {        "class": true,        "enum": true,        "function": true,        "interface": false,        "namespace": true,        "typeAlias": false,        "typeParameter": false      }    ],    "variable-name": false  }}// tsconfig.json{  "compilerOptions": {    "charset": "utf8",    "sourceMap": true,    "allowSyntheticDefaultImports": true,    "target": "es5",    "moduleResolution": "node",    "module": "umd",    "outDir": "./built",    "experimentalDecorators": true,    "removeComments": true,    "preserveConstEnums": true,    "allowJs": true  },  "include": [    "src/**/*"  ],  "exclude": [    "node_modules",    "built",  ]}

4. 测试编译

执行npm run prepush和npm run typingsdoc后。根目录下，应该多了俩目录：

Api 文档目录

如果遵照第一篇的配置，加过prettier大法。会发现src下的源文件也被美美的调整了代码风格

目前，暂时就这些。后边在整理，总结！！！

如果tsconfig.json中，同时配置了如下操作：

{  "compilerOptions": {    "charset": "utf8",    "sourceMap": true,    "allowSyntheticDefaultImports": true,    "target": "es5",    "moduleResolution": "node",    "module": "umd",    "outDir": "./dist",    "experimentalDecorators": true,    "removeComments": true,    "preserveConstEnums": true,    "diagnostics": true,    "allowJs": true, // 允许编译javascript文件    "declaration": true, //生成相应的 .d.ts文件（类似Objc中的.h文件）    "declarationDir": "./@types" //单独为头文件指定存放的位置  },  "include": ["src/**/*"],  "exclude": ["node_modules", "dist"]}

从这里开始，allowJs 如果为 true，则 declaration 就不应该存在。否则你将会看到编译时如下的报错…

Option ‘allowJs’ cannot be specified with option ‘declaration’.

看目录，好像需要的也都生成了！

但是作为一个优秀发程序员，能眼睁睁看到编译报错而不管嘛，当然不能！！！于是去撸github，发现早在 2016 年，微软那边就知道这事：issues-7546，但为毛现在还存在这个问题……

于是看他们讨论互怼，无意中看到巴基斯坦一兄弟的姿势。果断试了下，哎，别说，行了……

我把上边的操作整理了下，变成了一把梭，请看

"scripts": {    "tsc": "tsc",    "types": "tsc -d --emitDeclarationOnly --allowJs false --declarationDir ./@types",    "prepublish": "npm run tsc && npm run types"},

于是，之后你需要执行npm run prepublish就可以了。前提是把下边这两句从tsconfig.json中干掉

{  "declaration": true,  "declarationDir": "./@types"}

如果读者有更成熟的方案，麻烦告知。感谢！

听着 Jay 的歌、对着东南风，饮下这一壶漂泊，但也不知这一壶，还要喝多久……

上半场

差不多一个月前，我正式（此前已心里 BB 很多次）离开了漂泊六年之久的北京。来到了向往已久的南方城市 —— 南京
老实说，还从来没有对南京这座城市产生过想法，以前其实一直向往珠三角，没想到这次来的却是长三角，可能天意如此吧 😂

从 2012 年 7 月赴京到此时此刻已整整六年多，到现在还很清楚的记得刚来那些天。我是 19 号晚上坐火车上京的，到西站是 20 号的下午那会，当晚就是 7.21 暴雨。北京变成了水城，房山某些还发了洪水，近 80 人的生命没了…我则被大雨浇透全身，毫不夸张的说，连内裤都是湿的。当时打车去朋友住处途径积水潭，出租车司机都不想拉我走了（担心积水把发动机弄坏了）！当时那会还是很激动的，没有感到失望恐惧，毕竟到了首都…

作为一个一无所有、两袖清风的少年郎，我腰上别着两颗滚烫的肾，就开始了北漂生活。我的落脚点是二环小西天，但第二天起来就去五环外的西二旗参观了各大 IT 总部，包括联想、百度等（是不是挺好笑，毕竟后来我也觉得挺好笑），而也就是在那以后，在五环外住了六年多。可以说是见证了五环外的崛起，所以每当听郭德纲老师唱那首五环之歌时，我都特别感触。

在京城，除了工作还是工作（感觉每天都在疲于奔命），那些年也确实遇到过一些贵人，这里一并感谢和祝福。当然，要特别感恩的是李同学（当年的接待和帮助，虽然后来闲聊时你说都记不得了）…所以跟过去简单打个招呼，就再见吧！

Why 南京？

我的城市倾向是偏向于四季如春而不是四季分明，所以从这个角度来说南京相对于北京会有一丢丢优势。除了气候原因，另外就是帝都其实对于普通人而言，生活幸福感蛮低的。北京的冬天很冷，冷到外边树叶全部掉光，冷到外出不戴口罩脸都能冻掉。基本上在那种地方，更多的时间只能是待在出租屋里，让人很抑郁。同大多数北漂朋友一样，我非常讨厌搬家。当得知房东老哥的一句话后（老弟，房子明年我要自己住，麻烦你…）立马就下了南迁的决心。因为实在不想再找地方搬家，另外有南迁的机会，这个时间点非常碰巧，貌似老天暗中推了我一把，真是为我量身定制！

长三角，这个集群地带。不论是发展还是生活，都非常吸引人。这里有着上有天堂下有苏杭的美誉，气候温润、青山绿水，起码冬天出去到处也是绿油油的。这是北京永远给不了的福利…

所以离开，不是说不好，只是不适合自己。用一句话总结上半场：让我们微笑离开让故事留下来~

下半场

来这边快一个月了，体验非常好。特别是上下班时间被严重压缩，第一次感受到事业和生活是可以取平衡的，不像之前总在路上奔命……

新的一年，立几个 Flag，我希望：

• 把 18 年京东 618 买的几十斤书看完；
• 每周一篇文章，不管是技术笔记还是瞎扯淡，希望能坚持码字；
• 持续学英语，学会弹钢琴，成为自己想成为的那个人；
• 走遍长三角（如果不行，走遍南京市也可以）；

后记

隔壁的老王，希望你新的一年身体健康、万事如意。早日南下团聚……

加油，为梦想（花样作死）努力，永远相信美好的事情即将发生！

typedoc 使用笔记

以下记录 TOC 二级菜单插件的开发

先明确你自己的需求，你要做什么？现有的插件有没有能满足你的，如果有类似的，改改是否能用？如果毛都没有，那就从头写吧！

造轮子有一定代价，官网如果没有良好的教程指导，那将会很令人神伤。而 TypeDoc 就是这样，至少我谷歌了好久，没找到类似教程的东西，索性一把梭的去看了好多插件的源码实现。还好明白套路…

插件的作用无外乎是对原有的系统做了些许扩展。其原理在于某个时刻做某些拦截，然后构造必要的数据，然后再根据主题模板进行文件输出渲染。比如我们要改造 TOC 模块，使其支持二级栏目：

1. GitHub 找到 TypeDoc 源码，找到 TOC 模块所在

TocPlugin.ts

initialize() {    this.listenTo(this.owner, {        [PageEvent.BEGIN]: this.onRendererBeginPage    });}private onRendererBeginPage(page: PageEvent) {    // 以上省略.... 可以看到这里，右边原有的TOC目录树就是从这里生成数据。而我们要改的可能也在这里    TocPlugin.buildToc(model, trail, page.toc, tocRestriction);}

2. 研究其他插件的入口文件 index.js，我们可以发现

所有插件都有类似的注册方法，即：你的插件名称，功能需要挂接到文档系统。当开始生成数据时，收到事件后开始构造需要的数据结构

const P = require("./plugin");module.exports = function (PluginHost) {  const app = PluginHost.owner;  // 如果已经注册过了，就别再重复注册  if (app.converter.hasComponent(P.PLUGIN_NAME)) {    return;  }  if (app.renderer.hasComponent(P.PLUGIN_NAME)) {    return;  }  // 此处声明插件名称  app.options.addDeclaration({ name: P.PLUGIN_NAME, short: P.PLUGIN_SHORT_NAME });  // 监听数据变化  app.converter.addComponent(P.PLUGIN_NAME, P.TocGroupPlugin);  // 监听页面渲染  app.renderer.addComponent(P.PLUGIN_NAME, P.TocGroupPlugin);};

3. 做必要的监听及数据模型构造

研究 TOC 主题模板可以看到下图所示，其实最终读的就是 toc 这个变量里的 children。而要改造的就是把标签内容再包一层，塞到这个变量里。弄成二维数组即可。

需要注意的是，一定要在initialize方法里正确的监听事件。否则拿不到你要的值。正确监听的前提还必须是在index.js里正确注册。

比如要处理PageEvent事件，就要监听rendered类型；处理Converter事件，就要监听converter类型。

获取文档中指定注解名称和内容

// 1. initialize里监听： [Converter.EVENT_RESOLVE_BEGIN]: this.onBeginResolve,// 2. onBeginResolve回调中拿到Context，根据需求取或存数据const groupedData = [];const deprecatedData = new Set();const mapedTocData = {};const reflections = context.project.reflections;for (const key in reflections) {  const ref = reflections[key];  const comment = ref.comment;  const homePath = `modules/_index_.${context.project.name.replace(/\-/g, "")}.html`;  if (!comment || !comment.tags) continue;  for (const tag of comment.tags) {    // add deprecated item names    if (DEPRECATED_REGEXP.test(`@${tag.tagName}`)) deprecatedData.add(ref.name);    // add special tags    if (this.regexp.test(`@${tag.tagName}`)) {      groupedData.push(ref.name);      const groupKey = tag.text.split(/\r\n?|\n/)[0];      if (!mapedTocData[groupKey]) mapedTocData[groupKey] = [];      mapedTocData[groupKey].push(ref.name);      break;    }  }}// 以上构造的数据需要存到Context中，试过插件的成员变量，但是在其他事件回调中拿不到成员变量的值，事件关系没有深扒....context.project[PLUGIN_NAME] = { groupedData, deprecatedData, mapedTocData, homePath };

构造我们所需要的数据

请直接参考这里代码：buildGroupTocContent

4. 测试功能

将插件目录下的文件组织好，配置编译命令。然后拷贝到node_modules下，执行typedoc构建时，将会自动加载插件，无需手动配置：

Loaded plugin xxx/node_modules/typedoc-plugin-toc-group

如果控制台能打印类似的这条命令，那恭喜，你的新插件已经成功加载了。然后剩下的就是反复调试。直到实现你要的功能即可。

5. 定制主题

默认情况下，数据结构有了，页渲染出你要的结果了。但是可能长相不太好看。这时你就要定制一下默认的主题了。思路就是猜测你的功能所在的文件，然后去改造他。比如上面截图那个。

改完了之后，你可以选择提交到 npm，也可以放到自己项目中，用路径的方式去引用。

6. 总结一下

1. 明确需求，猜测与你功能相关的代码在哪里，去看源码；
2. 研究其他插件或主题的目录结构，搭建自己的插件或主题目录结构；
3. 入口文件注册事件，监听事件。拿到注解上的内容；
4. 当页面开始渲染时，根据注解去解析、拼凑你要的数据结构；
5. 将原来的数据结构从内部改掉（注意别改的太离谱否则加载会崩溃）；
6. 数据没问题后，定制主题。改成你喜欢的样子；

就写到这里，有不明白了。可以文章后留言，或者直接去看我写的这个主题。

关于 JS 模块化的问题，一直被忽视，今天重来拿出来谈谈：CommonJS，AMD，UMD，以及Harmony等…

CommonJS

主要用于 NodeJS 后端，采用同步的方式加载文件，它有四个重要的环境变量为模块化的实现提供支持：module、exports、require、global。实际使用时，用 module.exports 定义当前模块对外输出的接口（不推荐直接用 exports），用 require 加载模块。

特点：

1. 模块可以多次加载，但是只会在第一次加载时运行一次，然后运行结果就被缓存了，以后再加载，就直接读取缓存结果。要想让模块再次运行，必须清除缓存。
2. 模块加载会阻塞接下来代码的执行，需要等到模块加载完成才能继续执行——同步加载。

AMD

在服务端，模块文件都存在本地磁盘，读取非常快，所以这样做不会有问题。但是在浏览器端，限于网络原因，CommonJS 不适合浏览器端模块加载，更合理的方案是使用异步加载，即：ADM：异步模块定义，Asynchronous Module Definition。

AMD 规范采用异步方式加载模块，模块的加载不影响它后面语句的运行。所有依赖这个模块的语句，都定义在一个回调函数中，等到加载完成之后，这个回调函数才会运行。

一点优点：适合在浏览器环境中异步加载模块、并行加载多个模块；
一点缺点：不能按需加载、开发成本大。

CMD

CMD 是在 AMD 基础上改进的一种规范，和 AMD 不同在于对依赖模块的执行时机处理不同，CMD 是就近依赖，而 AMD 是前置依赖。此规范其实是在 sea.js 推广过程中产生的。

/** AMD写法 **/define(["a", "b", "c", "d", "e", "f"], function (a, b, c, d, e, f) {  // 等于在最前面声明并初始化了要用到的所有模块  a.doSomething();  if (false) {    // 即便没用到某个模块 b，但 b 还是提前执行了    b.doSomething();  }});/** CMD写法 **/define(function (require, exports, module) {  var a = require("./a"); //在需要时申明，很明显CMD可以做到按需加载  a.doSomething();  if (false) {    var b = require("./b");    b.doSomething();  }});

UMD

通用模块定义（UMD，Universal Module Definition）。兼容 AMD 和 commonJS 规范的同时，还兼容全局引用的方式。可运行在浏览器或服务器环境。

无导入导出规范，实现原理如下：

1. 先判断是否支持 Node.js 模块格式（exports 是否存在），存在则使用 Node.js 模块格式。
2. 再判断是否支持 AMD（define 是否存在），存在则使用 AMD 方式加载模块。
3. 前两个都不存在，则将模块公开到全局（window 或 global）。

(function (root, factory) {  if (typeof define === "function" && define.amd) {    //AMD    define(["jquery"], factory);  } else if (typeof exports === "object") {    //Node, CommonJS之类的    module.exports = factory(require("jquery"));  } else {    //浏览器全局变量(root 即 window)    root.returnExports = factory(root.jQuery);  }})(this, function ($) {  //方法  function myFunc() {}  //暴露公共方法  return myFunc;});

ES6 Module

旨在成为浏览器和服务器通用的模块解决方案。

其模块功能主要由两个命令构成：export 和 import。export 命令用于规定模块的对外接口，import 命令用于输入其他模块提供的功能。import 命令会被 JavaScript 引擎静态分析，在编译时就引入模块代码，而不是在代码运行时加载，所以无法实现条件加载。也正因为这个，使得静态分析成为可能。

ES6 模块是动态引用，并且不会缓存值，模块里面的变量绑定其所在的模块。

特点：

1. 按需加载（编译时加载）
2. import 和 export 命令只能在模块的顶层，不能在代码块之中（如：if 语句中）,import()语句可以在代码块中实现异步动态按需动态加载

语法：

1. 导入：import {模块名 A，模块名 B…} from ‘模块路径’
2. 导出：export 和 export default
3. import(‘模块路径’).then()方法

注意：export 只支持对象形式导出，不支持值的导出，export default 命令用于指定模块的默认输出，只支持值导出，但是只能指定一个，本质上它就是输出一个叫做 default 的变量或方法。

规范：

/*错误的写法*/// 写法一export 1;// 写法二var m = 1;export m;// 写法三if (x === 2) {  import MyModual from './myModual';}/*正确的三种写法*/// 写法一export var m = 1;// 写法二var m = 1;export {m};// 写法三var n = 1;export {n as m};// 写法四var n = 1;export default n;// 写法五if (true) {    import('./myModule.js')    .then(({export1, export2}) => {      // ...·    });}// 写法六Promise.all([  import('./module1.js'),  import('./module2.js'),  import('./module3.js'),]).then(([module1, module2, module3]) => {   ···});

System

systemjs 是模块加载器，可以导入任何流行格式的模块（CommonJS、UMD、AMD、ES6）。它是工作在 ES6 模块加载 polyfill 之上，它能够很好的处理和检测所使用的格式。 systemjs 也能使用插件转换 es6（ 用 Babel 或者 Traceur）或者转换 TypeScript 和 CoffeeScript 代码。你只需要在导入你的模块之前使用 System.config({ … }) 进行系统配置。

Dynamic ES module loader

Harmony

未来的模块，目前仍处于建设性阶段。

支持基于远程来源的模块，如：

module cakeFactory from "http://addyosmani.com/factory/cakes.js";cakeFactory.oven.makeCupcake( "sprinkles" );cakeFactory.oven.makeMuffin( "large" );

一些资料

• https://segmentfault.com/a/1190000012419990
• http://justineo.github.io/singles/writing-modular-js/
• https://juejin.im/post/5b4420e7f265da0f4b7a7b27#comment
• https://juejin.im/post/5aaa37c8f265da23945f365c
• http://wiki.jikexueyuan.com/project/javascript-design-patterns/es-harmony.html

npx是npm v5.2.0引入的一条命令，引入这个命令的目的是为了提升开发者使用包内提供的命令行工具的体验。

举例：使用create-react-app创建一个 react 项目。

老方法

npm install -g create-react-appcreate-react-app my-app

npx 方式

npx create-react-app my-app

这条命令会临时安装 create-react-app 包，命令完成后 create-react-app 会删掉，不会出现在 global 中。下次再执行，还是会重新临时安装。

也就是说 npx 会自动查找当前依赖包中的可执行文件，如果找不到，就会去 PATH 里找。如果依然找不到，就会帮你安装！

npx 甚至支持运行远程仓库的可执行文件：

npx github:piuccio/cowsay hello

主要特点

1. 临时安装可执行依赖包，不用全局安装，不用担心长期的污染。
2. 可以执行依赖包中的命令，安装完成自动运行。
3. 自动加载 node_modules 中依赖包，不用指定$PATH。
4. 可以指定 node 版本、命令的版本，解决了不同项目使用不同版本的命令的问题。

安装、使用方便。最后生成的是静态的 HTML 文件，界面简洁。

提供多个可选的配置，并且可以按照自己的需求自定义界面样式。

源码地址：TypeDoc

文档地址：TypeDoc Documentation

优雅的使用方式

// 1. 配置到package.json中，其中使用npx命令，无需单独安装typedoc库// 2. transform.js里可以将目标文档的特殊关键字替换。做一些前置处理"scripts": {    "typingsdoc": "node typings/transform.js && npx typedoc --out ./typings/doc  ./typings  --module umd"},

两个好用的插件

typedoc-plugin-single-line-tags

以上插件可以用一个注解，将描述展示为一行。而非多行，比如一个私有类，可以增加一个@private，然后增加一段说明

typedoc-plugin-external-module-name

当有多个模块，分为不同文件时，可以用上面的插件将模块区分出来。做类似的二级栏目。

关于同一 Module 文档的二级分类

1. 使用上面的插件，按文件区分；
2. 使用这个插件搞定：typedoc-plugin-toc-group

至于插件的开发，请移步这篇文章：

TypeDoc 插件开发小记

Recently this comic picture often come to my mind. Reality is always oppressive. I know I should read more books in order to see more beautiful world.

环境安装（macOS）

参考Flutter中文网的教程：https://flutterchina.club/setup-macos/

以上流程基本上是一把梭的就装好了，唯一需要注意的是PUB_HOSTED_URL和FLUTTER_STORAGE_BASE_URL这俩得写进环境变量配置里，如下：

# 1，我直接加到了系统环境变量中，需要加到自己家目录下同理vim /etc/profile# 2，复制以下配置# Flutter SDK https://flutterchina.club/setup-macos/PUB_HOSTED_URL=https://pub.flutter-io.cnFLUTTER_STORAGE_BASE_URL=https://storage.flutter-io.cnPATH=~/dev-lib/flutter/bin:$PATHexport PATH PUB_HOSTED_URL FLUTTER_STORAGE_BASE_URL# 3，使环境变量生效source /etc/profile

校验其他依赖

执行：flutter doctor，该命令检查您的环境并在终端窗口中显示报告，所以缺什么，直接复制命名继续安装即可，直到我这样就行了：

开始撸代码，首先配置 IDE（此处以 VS Code 为例）

配置方式如下

Visual Studio Code (VS Code) Dart 安装

启动模拟器

这里用 iOS 模拟器演示，执行：flutter emulators --launch apple_ios_simulator。然后模拟器就被正常启动

打开 VS Code 并创建 Demo 工程，按 F5 后

至此，Flutter的Hello-World工程就跑起来了，之后需要做的就是去学习语法开始撸代码

Rax 篇

先来区分一下概念：Weex 和 Rax

前者是一个容器（运行时环境），后者是一个跨容器的渲染引擎。即：Rax 可以跑在 Weex 里，但 Weex 不能跑在 Rax 中。
两者是相互独立的。Weex 可以简单理解为：Vue-Native。拿知乎段友的话概括就是：“看了一下好像是淘宝写 react-web 那几个人弄的，我猜他们是要用 weex 但是又喜欢 react 那套思想，所以整了个类 react 的东西，可以直接在 weex 里面渲染，也就是说可以用类似 react-native 的方式来写 weex 了”

具体也可以看看这里：Rax 系列教程（native 扫盲）

安装

Rax 快速开始

# 1. 安装命令行npm install -g rax-cli# 2. 初始化项目rax init hello-rax# 3. 启动npm run start

跑起来

Web 端

通过控制台生成的二维码，直接访问

Native 端

1. 先安装 Weex: npm install -g weex-toolkit

再在 Rax 目录中创建 Weex 环境：

2. 通过weex create创建的工程，没有 iOS 和 Android 工程模板，此时需要安装weex应用模板

// iOS (需要手动执行pod install)weex platform add ios// 安卓weex platform add android

3. 打开WeexDemo.xcworkspace，修改BUNDLE_URL并运行playground

4. 启动模拟器，就可以看到Rax跑起来了

总结

1. 大腿方：Flutter 抱 Google，Rax 抱 Alibaba;
2. 易用性：Flutter 完爆 Rax。Rax 创建后只有编码环境，运行环境还得再装 Weex，而 Weex 又是一个神奇的东西，对 Native 不熟的，可能会比较捉急；
3. 通用性：Flutter 目前主要用来做移动端，Web 端不行。Rax 则通吃，包括 Web；
4. Weex 和 RN 对比：Weex 和 RN 对比

典型方案

Electron

在客户端程序里面加入 webkit 做为引擎渲染存在本地 web 页面。使用这种解决方案典型的项目有 Atom, Github Desktop, Slack, visualstudio. 这些都是大公司的做出来的成果，目前看起来 Electron 是解决 GUI 跨平台很流行的方案，这得益于于 V8 的高性能，也和 nodejs 社区发展得如火如荼离不开关系。nodejs 几乎快变成了适用于任意地方万金油一样的编程语言。可是在客户端潜入一个 webkit 无论如何都会非常笨重，也难以做到轻量。你可能写一个简单的 hello world 弹窗最后打包的程序都需要 100M。 Electron 不适合轻量级的程序，也不是一个长期的 GUI 解决方案。它只适用于你只想做出一个凑合可用的跨平台应用。 Electron 应用更像是简单的把 HTML/CSS/JS 搬到一个不需要输入网址的浏览器里面。

React Native Desktop

Qt 在不同的平台上面把 GUI 直接画出来。Qt 发展了这么多年，一直处于非常冷清的状态，也很少见着一些大型的客户端是用 Qt 做出来的。Qt 也非常庞大，并不比基于 webkit 的 Electron 轻量。C++ 的使用和学习成本都非常高，做界面一致性远远也不如 web。除非不得已，现在几乎不会用 Qt 做为跨平台 GUI 的解决方案。C++ 自身跨平台代价也非常高。

Electrino

Electron的优化版，使用系统的浏览器引擎，大大降低了打包后应用的体积。然目前不支持 Windows。有人相信总有一天会取代Electron，可惜遗憾的时该项目 GitHub 已经一年多没有更新了。。。

Proton-Native

用 React 的思路封装了libui-node，底层的能力就是libui，不过目前不太成熟，实现商业化项目比较费劲。

React-Native

是的，你没看错。react-native-macos和react-native-windows这俩库扩展了React-Naitve，使得你可以开发 macOS 和 Windows 相对完美的 Native 应用，目前来讲就他合适了。

小结

从业务需求来看，如果不是要求特别高的性能，Electron和React-Native是最好的选择。如果是需要高性能，目前来说还没有合适的一码多端方案，不过对于大多数业务场景，Electron和React-Native都足以应付。

资料

• http://www.leyafo.com/post/2017-07-18-cross-platform-gui-solution-2017/
• https://josephg.com/blog/electron-is-flash-for-the-desktop/
• https://github.com/atom/atom/issues/14199
• https://www.zhihu.com/question/267324734

找了半天 Logo，发现并没有…俩大写字母太难看

1. 前置工作

在开始构建 TS 项目前，建议先把编码环境调整 ok，即：统一代码规范及结构，保证提交的是高质量的、同时尽量避免低级错误，最起码看起来爽，让别人知道你不是一个随便的人…

接下来，记录一下prettier、eslint|tslint、husky、lint-staged套装的使用。

2. 依赖情况

// .eslintrc.json内{ "extends": [  "standard",  "plugin:prettier/recommended" ], "parserOptions": {  "ecmaVersion": 7,  "sourceType": "module",  "ecmaFeatures": {   "jsx": true  } }, "parser": "babel-eslint", "env": {  "es6": true,  "browser": true,  "node": true }, "plugins": ["react", "jsx-a11y", "import"], "rules": {  "prettier/prettier": "error",  "class-methods-use-this": 0,  "import/no-named-as-default": 0,  "react/jsx-filename-extension": [   "error",   {    "extensions": [".js", ".jsx"]   }  ] }}// .prettierrc内（注意这个文件没有后缀。据说是加后缀VSCode不认，本人偏爱JB全家桶，所以没试过...）{  "printWidth": 180,  "tabWidth": 4,  "useTabs": false,  "semi": true,  "singleQuote": true,  "jsxSingleQuote": false,  "trailingComma": "all",  "bracketSpacing": false,  "jsxBracketSameLine": true,  "arrowParens": "always"}// package.json内{    "devDependencies": {        "typescript": "^3.2.2",        "typedoc": "^0.13.0",        "babel-eslint": "^10.0.1",        "eslint": "^5.11.1",        "eslint-config-prettier": "^3.3.0",        "eslint-config-standard": "^12.0.0",        "eslint-plugin-import": "^2.14.0",        "eslint-plugin-jsx-a11y": "^6.1.2",        "eslint-plugin-standard": "^4.0.0",        "eslint-plugin-react": "^7.12.0",        "eslint-plugin-node": "^8.0.0",        "eslint-plugin-prettier": "^3.0.1",        "eslint-plugin-promise": "^4.0.1",        "prettier": "^1.15.3",        "husky": "^1.3.1",        "lint-staged": "^8.1.0"    },    "husky": {        "hooks": {            "pre-commit": "lint-staged"        }    },    "lint-staged": {        "src/**/*.{jsx,txs,ts,js,json,css,md}": [            "prettier --write",            "eslint --fix",            "git add"        ]    }}

以上环境配好后，可以试着在src下建一个*.js文件。随便写点东西，然后咱们提交代码，看看发生了啥~

嗷嗷，如此犀利是不是。以上是针对 ES 的，来看下 TS 大法的~
新增俩文件：tslint.json和tsconfig.json，前者是规范约束文件，后者是 ts 编译参数配置

// tslint.json{    "defaultSeverity": "error",    "extends": [        "tslint:recommended",        "tslint-config-prettier"    ]}// tsconfig.json{  "compilerOptions": {    "sourceMap": true,    "allowSyntheticDefaultImports": true,    "declaration": false,    "target": "es6",    "moduleResolution": "node",    "allowJs": true,    "module": "umd",    "outDir": "./dist",    "experimentalDecorators": true  },  "exclude": [    "node_modules"  ]}// package.json{    "tslint": "^5.12.0",    "tslint-config-prettier": "^1.17.0"}// 其中scripts内需要配上tsc"scripts": {    "build": "tsc",    "prepare": "npm run build"}

关于这个架手架的源码，可以参考这里：TypeScript

到现在为止，好像关于写 TS 的事情并没有记录。做了太多前置工作，内容放到part2吧…

另外，叨叨一句，EditorConfig可以不用了（要了也是多余）

参考资料

使用 ESLint+Prettier 来统一前端代码风格

专治代码洁癖系列

因为

今天干了多半天的体力活，将为知笔记上的技术内容整理、删减各种折腾，最终留下并迁移了近 40 篇到 HEXO。虽说不是什么精华，但那毕竟是记忆。

2015 年 4 月 21 日我们相遇，对比了印象笔记等 XX 类笔记后，看上了你。今天还是不得不分手…

尤其是前阵子升级差点丢了数据，近乎懵逼的感觉让我下决心抛弃你。庆幸手没那么快。如果先卸载了，那只有哭了…

也怪我没及时看到你的更新公告： 关于升级至新同步服务的公告

嗯，往后，还是自己托管的好

所以

加油吧…

如果 render 中的组件以属性的方式引用了当前类的函数，且在 constructor 中 bind 这个函数，会造成这个函数仅刷新一次，如：

解决方式：在 Render 中 bind，在 SCU 中再拦截，控制实际 Render 次数

原因是：暂时不知道！！！

捂脸.png
捂脸.png
捂脸.png

易用、跨平台、良好的状态管理
教程：

https://www.jianshu.com/p/2f575cc35780 > https://www.jianshu.com/p/b877115fff1b

概况，React Navigation 分为三个部分：

StackNavigator：类似顶部导航条，用来跳转页面和传递参数；TabNavigator：类似底部标签，用来区分模块；DrawerNavigator：抽屉，类似从APP侧滑出一个页面

1、注意事项

iOS 和 Android 平台的 tabs 默认行为不一致，表现在 iOS 正常，安卓的 tab 在顶部且处于可滑动状态，一统江山方法如下：

const Navigation = TabNavigator(    {        tab1: { screen: screen1 },        tab2: { screen: screen2 },    },    // customize app tab bars    {        tabBarPosition: 'bottom',        tabBarComponent: TabBarBottom, // 安卓默认是顶部，不设置该项可能导致tabIcon位置错误        swipeEnabled: false, // 安卓默认可滑动        lazy: true,        initialRouteName: 'Offline',        tabBarOptions: {            indicatorStyle: {                height: 0, // android 中TabBar下面会显示一条线，高度设为 0 后就不显示线了            },            style: {                height: 49,                backgroundColor: 'white'          },            labelStyle: {                marginBottom: 3            },            iconStyle: {                height: 24,                width: 24,                margin: 0            },            showIcon: true, // 是否显示图标，安卓默认关闭            // label和icon的前景色 活跃状态下（选中）            activeTintColor: '#4ECBFC',            // label和icon的前景色 不活跃状态下(未选中)            inactiveTintColor: '#aaa',            // label和icon的背景色 活跃状态下            activeBackgroundColor: 'white',            // label和icon的背景色 不活跃状态下            inactiveBackgroundColor: 'white',            // 不透明度为按选项卡(iOS和Android < 5.0)            pressOpacity: 0.3,            scrollEnabled: false， // 是否启用可滚动的选项卡，安卓特有        }    });

安卓 tabbar 文字会下移，因为安卓比 iOS 多一个属性，就是 iconStyle，通过设置 labelStyle 和 iconStyle 两个样式，可以调整整理合理性。

2、安卓导航栏文字默认居左调整

自定义导航样式，重写：

headerTitleStyle

3、让安卓实现 push 动画

// 先引入这个方法import CardStackStyleInterpolator from 'react-navigation/src/views/CardStackStyleInterpolator';​// 在StackNavigator配置headerMode的地方，使用transitionConfig添加{    headerMode: 'screen',    transitionConfig:()=>({        screenInterpolator:CardStackStyleInterpolator.forHorizontal,    })}

二、iOS 平台专用的：NavigatorIOS

提供 UINavigationViewController 类的方法。其中 Navigator 已经被正式废弃！（于 RN44 被抛弃）

替代方案：react-native-deprecated-custom-components

三、Native 外观和体验的跨端方案：native-navigation, react-native-navigation

其中前者有 AirBnb 团队开发，1.x 前处于不稳定版本。不建议投入正式用途。
后者由 WiX 团队提供。目前功能已经相对完整，功能完全。必须在 RN 0.43 以后才可以用。
如果是混合开发，比如 RN 模块只作为一个 TAB 嵌入，那么可以考虑这种方案。

具体资料如下：https://wix.github.io/react-native-navigation/#/

1、安装 PM2：pm2

npm install pm2 -g

2、常用命令

pm2 ls

pm2 monit

3、 常用的服务启动命令

// 从某个文件作为服务入口启动pm2 start app.js​// 启动所有定义在packge.json中的服务pm2 start package.json​// 启动一个Node应用程序pm2 start npm -- start

二、ReactNative 默认端口修改

默人情况下，ReactNative 的 PackageManager 端口是 8081。

1、临时修改端口（这个命令是 2017 年 8 月 1 号以后增加的功能）

// 监听 9999
react-native start –port 9999

2、永久修改

planA：

手动修改所有涉及端口的文件，具体文件可谷歌

planB：

https://github.com/ktonon/react-native-port-patcher
script 中加 postinstall，devDependences 加

"postinstall": "react-native-port-patcher --new-port 9092""react-native-port-patcher": "^1.0.2"

安装以后，执行： yarn install | npm install
打开 Xcode 后，重新编译，就可使用新的端口

三、pm2 控制多个 ReactNative 服务

启动一个名为 xxName 的进程，可多个一起。其中start为scripts中定义的命令

pm2 start npm --name xxName -- run start

​

这种方式会启动一个名为 npm 的进程，如果不区别名称，则另外一个无法启动

pm2 start npm -- start

先说不优雅的方式

即：react-native init xxx

可以在 init 时加上模板参数，即：

react-native init xxx –template youui  // 这个意思就是生成 youui 开发样板（脚手架）

这种方式会生成 XCode 及 Android Studio 工程。通过 XCode 等工具可以直接运行模拟器或真机。

优雅的方式

1、官方推荐的 QuickStart

即 CRNA：create-react-native-app

CRNA 方式会生成一个带 Expo 的环境，但不会有 XCode 和 Android Studio 工程。也不会有各种目录配置。通过 Expo 客户扫描控制台二维码启动应用。

2、Ignite 生成项目

IGNITE 的官方地址：https://github.com/infinitered/ignite

IGNITE 是一个 React Native 的脚手架生成器（了解 ROR 的可以理解为 rails 命令），通过一个命令就可以生成一个结构完整的、可工作的空白 react native 项目，后续的开发就是向这个项目添砖加瓦，这比从头构建一个 RN 项目节省很多时间。而且 IGNITE 默认集成的很多库也都是不二之选，包含了前人的经验。

ignite new 之后会生成标准的开发结构。包括 Reactotron 配置等。结构比较重，版本也不见得是最新的！

3、Expo 方式

一、概念

普及英文读法： [‘ɛkspoʊ]，本身是展览会的意思。
来看官方的解释：https://docs.expo.io/versions/latest/index.html

Expo is a set of tools, libraries and services which let you build native iOS and Android apps by writing JavaScript

Expo是一组工具、库和服务，可以通过编写JavaScript来构建本地的ios和Android应用程序Expo Apps是包含了Expo SDK的react native Apps,SDK是一个native-and-js的库，它包提供对设备系统的访问功能，像照相机、联系人、本地存储和其他硬件）。这意味着你不需要使用Xcode或Android的环境，或写任何代码也使得你的pure-JS项目非常便携，因为它可以运行在任何自然环境包含Expo SDK。Expo还提供UI组件来处理各种应用程序，几乎所有应用程序都将被覆盖，但它不会突破react native Core的核心代码，例如图标、模糊视图，等等。最后，Expo SDK提供了访问服务，这些服务虽然很难管理，但几乎每个应用程序都需要它。其中最受欢迎的是：Expo可以为您管理您的资产，它可以为您处理推送通知，并且它可以构建准备部署到应用程序商店的本地二进制文件

FaceBook 的解释如下：

https://facebook.github.io/react-native/docs/more-resources.html Expo is a development environment plus application that focuses on letting you build React Native apps in the Expo development environment, without ever touching Xcode or Android Studio. If you wish React Native was even more JavaScripty and webby, check out Expo.

二、和 Ignite 等模板的区别？

Ignite 是一个脚手架生成工具，提供便捷的模板。区别于 Expo，它没有类似环境、服务的概念。某种意义上跟 CRNA 是一种东西。而后者主要是提供另一种 RN 开发环境，比如 Windows 下开发流程等。Ignite 可以作为模板扩展，加入到 Expo 工程里

关于打造自己的脚手架

https://zhuanlan.zhihu.com/p/32190298

另外有一篇关于：React Native App 应用架构设计

绝对是干货：React Native App 应用架构设计

比如在 ReactNative 中，安装完依赖之后，需要改端口、删掉某些文件……

多个操作不能在 package.json 中定义数组，但可以重新定义一个脚本，在脚本中定义操作集合：

shell 中这么写就行

#!/bin/bashecho 'Now run custom commands after all package is installed.'echo 'modify react-native package-manager default port'react-native-port-patcher --new-port 9090echo 'fix `Font Awesome` could not be found within the package etc.'rm ./node_modules/react-native/local-cli/core/__fixtures__/files/package.json

Cannot resolve symbol ‘Component’ & Cannot resolve symbol‘PropTypes’

1.解决 Cannot resolve symbol 'Component'  安装依赖：npm install @types/react --save  调用方法：import React, { Component } from 'react'2.解决 Cannot resolve symbol 'PropTypes'  安装依赖：npm install prop-types --save  调用方法：import PropTypes from 'prop-types'

https://www.npmjs.com/package/@types/react-native

npm install –save @types/react-native

为什么不用 Redux 了

三个哲学问题（未解之谜）？

1. Action 太多导致不记得 Action 的命名到底是什么？随便一个需求就要改动多个文件，一个小心写错字符，就够你查半天原因。及时专门写个管理工具，管理起来也非常痛苦；
2. Action 的流向到底是什么？
3. 经种种处理和反复传递，写 reducer 时，不打个 logo 真的不知道拿到什么数据结构

资料

中文文档：https://suprise.github.io/mobx-cn/

Mobx 最关键的函数在于 autoRun，举个例子，它可以达到这样的效果

const obj = observable({  a: 1,  b: 2,});autoRun(() => {  console.log(obj.a);});obj.b = 3; // 什么都没有发生obj.a = 2; // observe 函数的回调触发了，控制台输出：2

我们发现这个函数非常智能，用到了什么属性，就会和这个属性挂上钩，从此一旦这个属性发生了改变，就会触发回调，通知你可以拿到新值了。没有用到的属性，无论你怎么修改，它都不会触发回调，这就是神奇的地方。

autoRun 的用途

使用 autoRun 实现 mobx-react 非常简单，核心思想是将组件外面包上 autoRun，这样代码中用到的所有属性都会像上面 Demo 一样，与当前组件绑定，一旦任何值发生了修改，就直接 forceUpdate，而且精确命中，效率最高。

依赖收集

autoRun 的专业名词叫做依赖收集，也就是通过自然的使用，来收集依赖，当变量改变时，根据收集的依赖来判断是否需要更新。

实现步骤拆解

为了兼容，Mobx 使用了 Object.defineProperty 拦截 getter 和 setter，但是无法拦截未定义的变量，为了方便，我们使用 proxy 来讲解，而且可以监听未定义的变量哦。

步骤一 存储结构

众所周知，事件监听是需要预先存储的，autoRun 也一样，为了知道当变量修改后，哪些方法应该被触发，我们需要一个存储结构。

首先，我们需要存储所有的代理对象，让我们无论拿到原始对象，还是代理对象，都能快速的找出是否有对应的代理对象存在，这个功能用在判断代理是否存在，是否合法，以及同一个对象不会生成两个代理。

代码如下：

const proxies = new WeakMap()function isObservable<T extends object>(obj: T) {    return (proxies.get(obj) === obj)}

重点来了，第二个要存储的是最重要的部分，也就是所有监听！当任何对象被改变的时候，我们需要知道它每一个 key 对应着哪些监听（这些监听由 autoRun 注册），也就是，最终会存在多个对象，每个对象的每个 key 都可能与多个 autoRun 绑定，这样在更新某个 key 时，直接触发与其绑定的所有 autoRun 即可。

代码如下：

const observers = new WeakMap<object, Map<PropertyKey, Set>>()

第三个存储结构就是待观察队列，为了使同一个调用栈多次赋值仅执行一次 autoRun，所有待执行的都会放在这个队列中，在下一时刻统一执行队列并清空，执行的时候，当前所有 autoRun 都是在同一时刻触发的，所以让相同的 autoRun 不用触发多次即可实现性能优化。

const queuedObservers = new Set()

代码如下：

我们还要再存储两个全局变量，分别是是否在队列执行中，以及当前执行到的 autoRun。

代码如下：

let queued = falselet currentObserver: Observer = null

步骤二 将对象加工可观察

这一步讲解的是 observable 做了哪些事，首先第一件就是，如果已经存在代理对象了，就直接返回。

代码如下：

function observable<T extends object>(obj: T = {} as T): T {    return proxies.get(obj) || toObservable(obj)}

我们继续看 toObservable 函数，它做的事情是，实例化代理，并拦截 get set 等方法。

我们先看拦截 get 的作用：先拿到当前要获取的值 result，如果这个值在代理中存在，优先返回代理对象，否则返回 result 本身（没有引用关系的基本类型）。

上面的逻辑只是简单返回取值，并没有注册这一步，我们在 currentObserver 存在时才会给对象当前 key 注册 autoRun，并且如果结果是对象，又不存在已有的代理，就调用自身 toObservable 再递归一遍，所以返回的对象一定是代理。

registerObserver 函数的作用是将 targetObj -> key -> autoRun 这个链路关系存到 observers 对象中，当对象修改的时候，可以直接找到对应 key 的 autoRun。

那么 currentObserver 是什么时候赋值的呢？首先，并不是访问到 get 就要注册 registerObserver，必须在 autoRun 里面的才符合要求，所以执行 autoRun 的时候就会将当前回调函数赋值给 currentObserver，保证了在 autoRun 函数内部所有监听对象的 get 拦截器都能访问到 currentObserver。以此类推，其他 autoRun 函数回调函数内部变量 get 拦截器中，currentObserver 也是对应的回调函数。

代码如下：

const dynamicObject = new Proxy(obj, {    // ...    get(target, key, receiver) {        const result = Reflect.get(target, key, receiver)        // 如果取的值是对象，优先取代理对象        const resultIsObject = typeof result === 'object' && result        const existProxy = resultIsObject && proxies.get(result)        // 将监听添加到这个 key 上        if (currentObserver) {            registerObserver(target, key)            if (resultIsObject) {                return existProxy || toObservable(result)            }        }        return existProxy || result    }),    // ...})

setter 过程中，如果对象产生了变动，就会触发 queueObservers 函数执行回调函数，这些回调都在 getter 中定义好了，只需要把当前对象，以及修改的 key 传过去，直接触发对应对象，当前 key 所注册的 autoRun 即可。

代码如下：

const dynamicObject = new Proxy(obj, {  // ...  set(target, key, value, receiver) {    // 如果改动了 length 属性，或者新值与旧值不同，触发可观察队列任务    if (key === "length" || value !== Reflect.get(target, key, receiver)) {      queueObservers < T > (target, key);    }    // 如果新值是对象，优先取原始对象    if (typeof value === "object" && value) {      value = value.$raw || value;    }    return Reflect.set(target, key, value, receiver);  },  // ...});

没错，主要逻辑已经全部说完了，新对象之所以可以检测到，是因为 proxy 的 get 会触发，这要多谢 proxy 的强大。

可能有人问 Object.defineProperty 为什么不行，原因很简单，因为这个函数只能设置某个 key 的 gettersetter~。

symbol proxy reflect 这三剑客能做的事还有很多很多，这仅仅是实现 Object.observe 而已，还有更强大的功能可以挖掘。

mobx 的 proxy 完整实现版本参考 https://github.com/nx-js/observer-util 项目。

谈谈 Redux 与 Mobx 思想的适用场景

Redux 和 Mobx 都是当下比较火热的数据流模型，一个背靠函数式，似乎成为了开源界标配，一个基于面向对象，低调的前行。

函数式 vs 面向对象

首先任何避开业务场景的技术选型都是耍流氓，我先耍一下流氓，首先函数式的优势，比如：

1. 无副作用，可时间回溯，适合并发。
2. 数据流变换处理很拿手，比如 rxjs。
3. 对于复杂数据逻辑、科学计算维的开发和维护效率更高。

当然，连原子都是由带正电的原子核，与带负电的电子组成的，几乎任何事务都没有绝对的好坏，面向对象也存在很多优势，比如：

1. javascript 的鸭子类型，表明它基于对象，不适合完全函数式表达。
2. 数学思维和数据处理适合用函数式，技术是为业务服务的，而业务模型适合用面向对象。
3. 业务开发和做研究不同，逻辑严谨的函数式相当完美，但别指望每个程序员都愿意消耗大量脑细胞解决日常业务问题。

Redux vs Mobx

那么具体到这两种模型，又有一些特定的优缺点呈现出来，先谈谈 Redux 的优势：

1. 数据流流动很自然，因为任何 dispatch 都会导致广播，需要依据对象引用是否变化来控制更新粒度。
2. 如果充分利用时间回溯的特征，可以增强业务的可预测性与错误定位能力。
3. 时间回溯代价很高，因为每次都要更新引用，除非增加代码复杂度，或使用 immutable。
4. 时间回溯的另一个代价是 action 与 reducer 完全脱节，数据流过程需要自行脑补。原因是可回溯必然不能保证引用关系。
5. 引入中间件，其实主要为了解决异步带来的副作用，业务逻辑或多或少参杂着 magic。
6. 但是灵活利用中间件，可以通过约定完成许多复杂的工作。
7. 对 typescript 支持困难。

Mobx：

1. 数据流流动不自然，只有用到的数据才会引发绑定，局部精确更新，但免去了粒度控制烦恼。
2. 没有时间回溯能力，因为数据只有一份引用。
3. 自始至终一份引用，不需要 immutable，也没有复制对象的额外开销。
4. 没有这样的烦恼，数据流动由函数调用一气呵成，便于调试。
5. 业务开发不是脑力活，而是体力活，少一些 magic，多一些效率。
6. 由于没有 magic，所以没有中间件机制，没法通过 magic 加快工作效率（这里 magic 是指 action 分发到 reducer 的过程）。
7. 完美支持 typescript。

到底如何选择

从目前经验来看，我建议前端数据流不太复杂的情况，使用 Mobx，因为更加清晰，也便于维护；如果前端数据流极度复杂，建议谨慎使用 Redux，通过中间件减缓巨大业务复杂度，但还是要做到对开发人员尽量透明，如果可以建议使用 typescript 辅助。

https://zhuanlan.zhihu.com/p/25585910

另一组对比：

https://zhuanlan.zhihu.com/p/25989654

stores 代表着 UI 状态

永远记住，你的 stores 代表着你的 UI 状态，这就意味着，当你将你的 stores 储存下来后，就算你关了网页，再次打开，载入这个 stores，你得到的网页也应该是相同的。虽然 stores 并不是一个本地数据库的角色，但是他依然存储着一些类似于按钮是否可见，input 里面的内容之类的 UI 状态。

class SearchStore {  @observable searchText;  @action  setSearchText = (searchText) => {    this.searchText = searchText;  };}@observerclass SearchInput extends React.Component {  handleInputChanged = (event) => {    const { searchStore } = this.props;    searchStore.setSearchText(event.target.value);  };  render() {    const { searchStore } = this.props;    return <input value={searchStore.searchText} onChange={this.handleInputChanged} />;  }}

将你的 REST API 请求和 store 的 action 分离

不建议将 REST API 请求的函数放在 stores 里面，因为这样以来这些请求代码很难测试。你可以尝试把这些请求函数放在一个类里面，把这个类的代码和 store 放在一起，在 store 创建时，这个类也相应创建。然后当你测试时，你也可以优雅的把数据从这些类里面 mock 上去。

class TodoApi {  fetchTodos = () => request.get("/todos");}class TodoStore {  @observable todos = [];  constructor(todoApi) {    this.todoApi = todoApi;  }  fetchTodos = async () => {    const todos = await this.todoApi.fetchTodos();    runInAction(() => {      this.todos = todos;    });  };}

// 在你的主要函数里面const todoApi = new TodoApi();const todoStore = new TodoStore(todoApi);

把你的业务逻辑放在 stores 里面

尽量不要把业务逻辑写在你的组件里面。当你把业务逻辑写在组件里面的时候，你是没有办法来及时定位错误的，因为你的业务逻辑分散在各种不同的组件里面，让你很难来通过行为来定义到底是哪些代码涉及的这个错误。最好就把业务逻辑放在 stores 的方法里面，从组件里面调用。

避免使用全局的 store 实例

请尽量避免使用全局的 store 实例，因为这样你很难写出有条理而可靠的组件测试。取而代之的是，你可以使用 Provider 来把你的 store inject 到你的 component 实例的 props 里面。这样你就可以轻松的 mock 这些 store 来测试了。

const searchStore = new SearchStore();const app = (  <Provider searchStore={searchStore}>    <SearchInput />  </Provider>);ReactDom.render(app, container);

只有在 store 里面才允许改变属性

请不要直接在组件里面直接操作 store 的属性值。因为只有 store 才能够来修改自己的属性。当你要改变属性的时候，请使用相应的 store 方法。不然的话你的属性修改会散落在各处不受控制，这是很难 debug 的。

时刻记得在组件声明 @observer

在每个组件声明的时候使用@observer 来更新组件的状态。不然在嵌套组件里面，子组件没有声明的话，每次状态更新涉及到的都是父组件级的重新渲染。当你都使用了@observer 时，重新渲染的组件数量会大大降低。

使用 @computed

就像下面代码的例子，使用@computed 属性来处理一些涉及多个属性的逻辑。使用@computed 可以减少这样的判断类业务逻辑在组件里面出现的频率。

class ApplicationStore {  @observable loggedInUser;  @observable isInAdminMode;  @computed isAdminButtonEnabled = () => {    return this.loggedInUser.role === "admin" && this.isInAdminMode;  };}

你不需要 react router 来管理状态

你不需要使用 react router 管理状态。就像我前面所说的，你的 store 就代表了应用的状态。当你让 router 来管理部份应用状态的时候，这部分状态就从 store 里面剥离开来。所以尽量使用 store 来储存所有的 UI 状态，这样 store 的属性就是你的界面所得。

倾向于编写可控组件

多编写可控组件，这样会大大降低你的测试复杂度，也让你的组件易于管理。

参考

作者：Dominic_Ming
链接：https://juejin.im/post/5a3b1a88f265da431440dc4a
来源：掘金

Redux is a predictable state container for JavaScript apps.，其中 predictable 和 state container 体现了它的作用。

那么如何来理解可预测化的呢？
这里会有一些函数式编程方面的思想，在 Redux 中 reducer 函数是一个纯函数，相同输入一定会是一致的输出，所以确定输入的 state 那么 reducer 函数输出的 state 一定是可以被预测的，因为它只会进行单纯的计算，保证正确的输出。

状态容器又是什么？
说明 Redux 有一个专门管理 state 的地方，就是 Store，并且一般情况下是唯一的，应用中所有 state 形成的一颗状态树就是 Store。Redux 由 Flux 演变而来，但受 Elm 的启发，避开了 Flux 的复杂性，我们看看其数据流向：

不同于 Flux 架构，Redux 中没有 dispatcher 这个概念，并且 Redux 设想你永远不会变动你的数据，你应该在 reducer 中返回新的对象来作为应用的新状态。但是它们都可以用(state, action) => newState 来表述其核心思想，所以 Redux 可以被看成是 Flux 思想的一种实现，但是在细节上会有一些差异。

二、原则

1. 应用中所有的 state 都以一个 object tree 的形式存储在一个单一的 store 中；
2. 唯一能改变 store 的方法是触发 Action，Action 是动作行为的抽象；
3. 为了描述 Action 如何改变 State 树，需要编写 reducer 函数；

function testReducer(state, action) {  switch (action.type) {    case ACTION_TYPE: // calc...      return newState;    default:      return state;  }  return newState;}

state 是不可修改的，所以返回的新 state 应该是基于输入 state 副本的修改，而不是直接修改 state 后的返回。可见：

1. 单一数据源，store：整个应用的 state 被存放在一棵 Object tree 树，并且整个 object tree 只存在唯一的一个 store 中；
2. State 是只读的：唯一能改变 State 的方法是触发 Action；
3. 使用纯函数来实现 State 归并操作，reducer：传入待修改的 state 和一个告知 reducer 如何修改 state 的 action，reducer 将返回 action 规则对应下操作后的新的 state；

reducer(state, action) => new state

三、数据流

严格的单向数据流是 Redux 设计的核心，Redux 应用数据的生命周期遵循下面 4 个步骤：

调用 store.dispatch(action), 可以在任何地方进行;
Redux store 调用传入的 reducer 函数，并且将当前的 state 树与 action 传入。reducer 是纯函数，只用于计算下一个 state，它应该是完全可被预测的，相同的输入必定会有相同的输出，不能有副作用的操作，如 API 的调用或者路由跳转，这些应该都是在 dispatch 前产生；
根 reducer 将多个子 reducer 输出合并成一个单一的 state 树；
Redux store 保存了根 reducer 返回的完整的 state 树。
新的 state 树就是应用的下一个状态，现在就可以根据新的 state tree 来渲染 UI

1. React 有 props 和 state: props 意味着父级分发下来的属性，state 意味着组件内部可以自行管理的状态，并且整个 React 没有数据向上回溯的能力，也就是说数据只能单向向下分发，或者自行内部消化。
   理解这个是理解 React 和 Redux 的前提。
2. 一般构建的 React 组件内部可能是一个完整的应用，它自己工作良好，你可以通过属性作为 API 控制它。但是更多的时候发现 React 根本无法让两个组件互相交流，使用对方的数据。
   然后这时候不通过 DOM 沟通（也就是 React 体制内）解决的唯一办法就是提升 state，将 state 放到共有的父组件中来管理，再作为 props 分发回子组件。
3. 子组件改变父组件 state 的办法只能是通过 onClick 触发父组件声明好的回调，也就是父组件提前声明好函数或方法作为契约描述自己的 state 将如何变化，再将它同样作为属性交给子组件使用。
   这样就出现了一个模式：数据总是单向从顶层向下分发的，但是只有子组件回调在概念上可以回到 state 顶层影响数据。这样 state 一定程度上是响应式的。
4. 为了面临所有可能的扩展问题，最容易想到的办法就是把所有 state 集中放到所有组件顶层，然后分发给所有组件。
5. 为了有更好的 state 管理，就需要一个库来作为更专业的顶层 state 分发给所有 React 应用，这就是 Redux。让我们回来看看重现上面结构的需求：
   a. 需要回调通知 state (等同于回调参数) -> action
   b. 需要根据回调处理 (等同于父级方法) -> reducer
   c. 需要 state (等同于总状态) -> store
   对 Redux 来说只有这三个要素：
   a. action 是纯声明式的数据结构，只提供事件的所有要素，不提供逻辑。
   b. reducer 是一个匹配函数，action 的发送是全局的：所有的 reducer 都可以捕捉到并匹配与自己相关与否，相关就拿走 action 中的要素进行逻辑处理，修改 store 中的状态，不相关就不对 state 做处理原样返回。
   c. store 负责存储状态并可以被 react api 回调，发布 action.
   当然一般不会直接把两个库拿来用，还有一个 binding 叫 react-redux, 提供一个 Provider 和 connect。很多人其实看懂了 redux 卡在这里。
   a. Provider 是一个普通组件，可以作为顶层 app 的分发点，它只需要 store 属性就可以了。它会将 state 分发给所有被 connect 的组件，不管它在哪里，被嵌套多少层。
   b. connect 是真正的重点，它是一个科里化函数，意思是先接受两个参数（数据绑定 mapStateToProps 和事件绑定 mapDispatchToProps），再接受一个参数（将要绑定的组件本身）：
   mapStateToProps：构建好 Redux 系统的时候，它会被自动初始化，但是你的 React 组件并不知道它的存在，因此你需要分拣出你需要的 Redux 状态，所以你需要绑定一个函数，它的参数是 state，简单返回你关心的几个值。
   mapDispatchToProps：声明好的 action 作为回调，也可以被注入到组件里，就是通过这个函数，它的参数是 dispatch，通过 redux 的辅助方法 bindActionCreator 绑定所有 action 以及参数的 dispatch，就可以作为属性在组件里面作为函数简单使用了，不需要手动 dispatch。这个 mapDispatchToProps 是可选的，如果不传这个参数 redux 会简单把 dispatch 作为属性注入给组件，可以手动当做 store.dispatch 使用。这也是为什么要科里化的原因。
   做好以上流程 Redux 和 React 就可以工作了。

简单地说就是：

1. 顶层分发状态，让 React 组件被动地渲染。
2. 监听事件，事件有权利回到所有状态顶层影响状态。

资料

• https://segmentfault.com/a/1190000006742449
• https://www.zhihu.com/question/41312576/answer/90782136

如何理解 Facebook 的 flux 应用架构？

Flux 的核心就是一个简单的约定：视图层组件不允许直接修改应用状态，只能触发 action。应用的状态必须独立出来放到 store 里面统一管理，通过侦听 action 来执行具体的状态操作。
所谓的单向数据流，就是当用户进行操作的时候，会从组件发出一个 action，这个 action 流到 store 里面，触发 store 对状态进行改动，然后 store 又触发组件基于新的状态重新渲染。
即可以看出：视图组件变得很薄，只包含了渲染逻辑和触发 action 这两个职责，即所谓 “dumb components”（愚蠢组件）

2、结构图

总有那么一次操作后，想反悔，那么 git log 先：

所以

此时比如想恢复红框那个版本，执行：

git checkout 19d46ca0715df5223d9e30ba9743fc9d95a3bf78

命令结束后，会跳到 HEAD 分支

复制改项目到另一边，切回之前的分支，把备份覆盖回去。在 git diff 。对比一致后，在提交

OS X 系统有的文件移动或复制时，出现“Mac 不能更改一个或多个项目,因为他们正在使用”，这或许是多了个属性导致：

这就解决了，还有，如果是移动设备的文件导致的原因，解决时必须保证移动设备处于可读写状态，对于大部分移动硬盘都是 NTFS 的问题，可参考如下方法解决：

https://coolestguidesontheplanet.com/how-to-write-to-ntfs-external-disk-drives-from-os-x-10-11-el-capitan/

关于@的解释请参考：

http://mackuba.eu/2008/06/30/ls-on-mac-and-extended-file-attributes/

今天写代码时需要在 dealloc 里移除所有的通知,但是却发现控制器 pop 后不执行 dealloc 方法.

查到这句话:The dealloc method was not being called if any of the references held by a viewcontroller were still in memory.

dealloc 方法没有被调用是因为控制器的一个或多个强引用仍然在内存中,也就是说当前控制器的计数器不为 0.

所以

一般的原因有以下几种:

1. 定制器没有被销毁，解决方法:在 viewWillDisappear 之前需要把控制器用到的 NSTimer 销毁；
2. block 块使用不当，因为 block 会对方法中的变量自动 retain 一次, 请检查控制器中 block 代码；
3. 代理必须得用 weak 修饰，用 strong 强引用会导致计数器加 1，无法释放内存；
4. 在 getter 方法里使用 self，导致死循环；

Block 体内使用实例变量也会造成循环引用，使得拥有这个实例的对象不能释放

如果是纯 OC 项目，当你创建第一个 Swift 文件时，Xcode 会提示你建立一个$(PROJECT_NAME)-Bridging-Header.h 文件，这个文件就是 OC 与 Swift 间相互交流的桥梁文件，即：所有需要在 Swift 中调用的 OC 代码，OC 头文件必须在这个文件里引入，相反如果是纯 Swift 项目，当你建立第一个 OC 语法的文件时，他也会提示，照做就可以了，酱紫就完成了 Swift 中调用 OC。

如果发现建立了桥接文件而项目无法正常编译时，请检查如上配置

在 OC 中调用 Swift 代码

由于 Swift 中没有头文件的概念，所有在 OC 中，直接引入 Swift 文件，编译器会不高兴的，结果就是编译无法通过！！！所以你需要在调用 Swift 的 OC 代码中，引入一个名叫：$(PROJECT_NAME)-Swift.h，这个文件中定义了该项目中所有 Swift 的类及其方法，不过他是不可见的

当然，Swift 也可以编译后运行（二进制文件，直接执行）：

如果能解密出来，但是有乱码，如下：

所以

请考虑 IV（初始化向量）是不是有误或两个平台下不一样

再有，Java 端 MD5 可能直接返回了 bytes，并没有最终转成 String，注意多平台的区别

项目中使用到了从字符串创建选择器，编译时发现警告：”performSelector may cause a leak because its selector is unknown”（因为 performSelector 的选择器未知可能会引起泄漏），为什么在 ARC 模式下会出现这个警告？

经过搜索后，在 Stackoverflow 上发现了一个令人满意的答案。见http://stackoverflow.com/questions/7017281/performselector-may-cause-a-leak-because-its-selector-is-unknown。

原因

在 ARC 模式下，运行时需要知道如何处理你正在调用的方法的返回值。这个返回值可以是任意值，如 void,int,char,NSString,id 等等。ARC 通过头文件的函数定义来得到这些信息。所以平时我们用到的静态选择器就不会出现这个警告。因为在编译期间，这些信息都已经确定。

如：

[someController performSelector:@selector(someMethod)];- (void)someMethod{  //bla bla...}

而使用[someController performSelector: NSSelectorFromString(@”someMethod”)];时 ARC 并不知道该方法的返回值是什么，以及该如何处理？该忽略？还是标记为 ns_returns_retained 还是 ns_returns_autoreleased?

解决办法

1.使用函数指针方式

SEL selector = NSSelectorFromString(@"someMethod");IMP imp = [_controller methodForSelector:selector];void (*func)(id, SEL) = (void *)imp;func(_controller, selector);

当有额外参数时，如

SEL selector = NSSelectorFromString(@"processRegion:ofView:");IMP imp = [_controller methodForSelector:selector];CGRect (*func)(id, SEL, CGRect, UIView *) = (void *)imp;CGRect result = func(_controller, selector, someRect, someView);

2.使用宏忽略警告

#pragma clang diagnostic push#pragma clang diagnostic ignored "-Warc-performSelector-leaks"   [someController performSelector: NSSelectorFromString(@"someMethod")]#pragma clang diagnostic pop

通过使用#pragma clang diagnostic push/pop，你可以告诉 Clang 编译器仅仅为某一特定部分的代码来忽视特定警告。

如果需要忽视的警告有多处，可以定义一个宏

#define SuppressPerformSelectorLeakWarning(Stuff) \    do { \        _Pragma("clang diagnostic push") \        _Pragma("clang diagnostic ignored \"-Warc-performSelector-leaks\"") \        Stuff; \        _Pragma("clang diagnostic pop") \    } while (0)    ```在产生警告也就是performSelector的地方用使用该宏，如```objectivecSuppressPerformSelectorLeakWarning(    [_target performSelector:_action withObject:self]);

如果需要 performSelector 返回值的话，

id result;SuppressPerformSelectorLeakWarning(    result = [_target performSelector:_action withObject:self]);

3.使用 afterDelay

[self performSelector:aSelector withObject:nil afterDelay:0.0];

如果在接受范围内，允许在下一个 runloop 执行，可以这么做。xCode5 没问题，但据反映，xCode6 的话这个不能消除警告。

// 横屏设定的宏#define SetScreenOrientation- (BOOL)shouldAutorotate{    return YES;}- (NSUInteger)supportedInterfaceOrientations{    return UIInterfaceOrientationMaskLandscape;}//单斜杠是除法，双斜杠是注释，反斜杠可以链接宏定义，或连接字符串。

旋屏常用解释

• UIInterfaceOrientationMaskLandscape：支持左右横屏
• UIInterfaceOrientationMaskAll：支持四个方向旋转
• UIInterfaceOrientationMaskAllButUpsideDown：支持除了 UpsideDown 以外的旋转

当前屏幕方向 interfaceOrientation 的获取，有 3 种方式可以获取到“当前 interfaceOrientation”：

controller.interfaceOrientation，获取特定controller的方向[[UIApplication sharedApplication] statusBarOrientation] 获取状态条相关的方向[[UIDevice currentDevice] orientation] 获取当前设备的方向

// 一般写法：float tempOffset = wordsDisplay == DisPlayBottom ? -80 : 80;// 优质写法：float offset = (DisPlayBottom == wordsDisplay) ? - 80 : 80;// 遵循常量放左边的原则，三目运算也可以这么写：NSString *filetestpaht;filetestpaht = filetestpaht ? : [NSString stringWithFormat:@"abc"];

打包这事儿其实就是让xcrun来干，而xcodebuild只是xcrun的一个软链接。分工如下：

1、xcodebuild负责讲工程源文件编译成 xxx.app；
2、xcrun负责给 xxx.app 签名并打包成 xxx.ipa

工作步骤

1、先查看本机命令编译环境及需要编译项目的信息

2、开始编译

1、清理：xcodebuild -target Test clean
2、编译：xcodebuild -target Test
3、打包：xcrun -sdk iphoneos PackageApplication -v ./build/Release-iphoneos/Test.app -o ~/ipas/test.ipa

3、查看结果

4、特别提示

以上打包方式仅对*.xcodeproj项目有效，如果是 cocoapod 项目，则需要改一遍编译命令：

xcodebuild -workspace Test.xcworkspace -scheme Test -configuration Release -derivedDataPath build

1. 对于基本数据类型，当然使用 assigin；
2. 对于 mutable 的，一定要使用 strong。父控件 UI 元素也使用 strong；
3. 子控件元素使用 weak；
4. 不可变的类型，使用 copy。（NSString,NSArray,NSDictonary 这些一定要用 copy）对于 mutable 的对象，如果是 mutable 的却定义属性为 copy，则往里面加值时可能引起程序崩溃。而对于不可变的使用了 strong，则可能引起值改变，这就违背了内存管理语义

二、关于 getter

if (_messageTipNumber > 0) {       self.tipCountLable.frame = CGRectMake(150, (self.frame.size.height - 14)/2, 14, 14);       self.tipCountLable.layer.cornerRadius = _tipCountLable.frame.size.width/2;       self.tipCountLable.text = [NSString stringWithFormat:@"%d",_messageTipNumber];       [self.contentView addSubview:_tipCountLable];}

代码笔记

CATransition* transition = [CATransition animation];transition.type = kCATransitionPush;//可更改为其他方式transition.subtype = kCATransitionFromTop;//可更改为其他方式[self.navigationController.view.layera ddAnimation:transition forKey:kCATransition];[self.navigationController pushViewController:userLogin animated:NO];

再来

//可根据上一个页面，来确定当前页以何种方式消失- (void)viewWillDisappear:(BOOL)animated{    [super viewWillDisappear:animated];    [self clear];    BOOL fromRight = YES;    NSArray *viewControllers = self.navigationController.viewControllers;    if ([[viewControllers lastObject] isKindOfClass:[BFEAddContactViewController class]]) {        fromRight = NO;    }    CATransition *transition = [CATransition animation];    transition.type = kCATransitionPush;    //页面卸载时，改变PUSH方向    transition.subtype = fromRight ?  kCATransitionFromRight : kCATransitionFromLeft;    transition.duration = 0.3;    transition.delegate = self;    [self.navigationController.view.layer addAnimation:transition forKey:kCATransition];}

ios 有如下三种随机数方法：

// 不加这句每次产生的随机数不变    srand((unsigned)time(0));    int i = rand() % 5;    srandom(time(0));    int i = random() % 5;    int i = arc4random() % 5 ;

注：rand()和 random()实际并不是一个真正的伪随机数发生器，在使用之前需要先初始化随机种子，否则每次生成的随机数一样。

arc4random() 是一个真正的伪随机算法，不需要生成随机种子，因为第一次调用的时候就会自动生成。而且范围是 rand()的两倍。在 iPhone 中，RAND_MAX 是 0x7fffffff (2147483647)，而 arc4random()返回的最大值则是 0x100000000 (4294967296)。

精确度比较：arc4random() > random() > rand()。

常用方法：arc4random

1、获取一个随机整数范围在：[0,100)包括 0，不包括 100

int x = arc4random() % 100;

2、 获取一个随机数范围在：[500,1000），包括 500，不包括 1000

int y = (arc4random() % 501) + 500;

3、获取一个随机整数，范围在[from,to），包括 from，不包括 to

-(int)getRandomNumber:(int)from to:(int)to{    return (int)(from + (arc4random() % (to – from + 1))); //+1,result is [from to]; else is [from, to)!!!!!!!}```

在继承关系下，子类使用父类的数据通过属性最为合适，也最直接明了。

Block

如果有某种继承或所属关系时，父元素要使用子元素的数据，那么此时应该使用 block 回调。因为此时子元素属性就不一定能取到值（初始化未或动作未必完成）。

消息

两个类根本没有关联，则可以采取发消息的方式。如果两个类可以引入某一方，则还是采取属性或者 block 方法，因为发消息实际上通过 KVO 比较消耗系统资源。能不发消息，尽量不要发消息。

UIView 的 exclusiveTouch 属性

来自 2015.6.10 的笔记：UIView 事件独占

exclusiveTouch 的意思是 UIView 会独占整个 Touch 事件，具体的来说，就是当设置了 exclusiveTouch 的 UIView 是事件的第一响应者，那么到你的所有手指离开前，其他的视图 UIview 是不会响应任何触摸事件的，对于多点触摸事件，这个属性就非常重要，值得注意的是：手势识别（GestureRecognizers）会忽略此属性。

列举用途：我们知道 ios 是没有 GridView 视图的，通常做法是在 UITableView 的 cell 上加载几个子视图，来模拟实现 GridView 视图，但对于每一个子视图来说，就需要使用 exclusiveTouch，否则当同时点击多个子视图，那么会触发每个子视图的事件。当然 还有我们常说的模态对话框。

关于指针定义（解决 sending ‘const NSString _’ to parameter of type ‘NSString _’ ）

// 比如，写了const NSString* firstString = @"xxx";NSString* secondString = @"yyy";[secondString isEqualToString:firstString];// 会出现 sending 'const NSString *' to parameter of type 'NSString *' discards qualifiers 警告。解决办法：const NSString* firstString = @"xxx";// 改成NSString* const firstString = @"xxx";

解释：前者相当于指针本身不可修改，后者表示指针指向的内容不可修改，两者的作用都是使 firstString 只可读不可写。

来自 2015.5.29 的笔记

- (void)testScanNumberFromString{    NSString *str = @"98234hk323hello234你好";    NSMutableString *numberString = [[NSMutableString alloc] init];        NSScanner *scanner = [NSScanner scannerWithString:str];    NSString *tempString;        while (![scanner isAtEnd]) {        [scanner scanUpToCharactersFromSet:[NSCharacterSet decimalDigitCharacterSet] intoString:nil];                //收集数字        [scanner scanCharactersFromSet:[NSCharacterSet decimalDigitCharacterSet] intoString:&tempString];;        [numberString appendString:tempString];        tempString = @"";    }    NSLog(@"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ number is: %@",numberString);}

使用

[scanner scanUpToCharactersFromSet:[NSCharacterSet newlineCharacterSet] intoString:&indexString]; //扫描一行[scanner scanUpToString:@" scanover " intoString:&theString];  //从游标开始扫描，直到给定字符串为止。期间扫描的字符串存到theString[scanner scanString:@"sanMe" intoString:NULL]; //直接扫描指定字符串

int main(int argc, const char * argv[]) {        NSString *str = @"白日依山尽";        //编码    NSString *encoderStr = [str stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];        //解码    NSString *decoderStr = [encoderStr stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];        //字符串打散    for (int i = 0; i < str.length; i++) {        NSString *word = [str substringWithRange:NSMakeRange(i, 1)];        NSLog(@"%@",word);    }            NSLog(@"%@",encoderStr);        NSLog(@"%@",decoderStr);        return 0;}

1、相同点

都可以作为方法的返回类型

2、不同点

• instancetype 可以返回和方法所在类相同类型的对象，id 只能返回未知类型的对象；
• instancetype 只能作为返回值，不能像 id 那样作为参数，比如下面的写法：

//err,expected a type- (void)setValue:(instancetype)value{    //do something}

就是错的，应该写成：

- (void)setValue:(id)value{    //do something}

从 XCode5 以后，默认都采用了 ARC，但有时候又想使用 MRC，无奈写了 MRC 语法后，编译器保持：

解决方式如下

注意：-fno-objc-arc 这句不要有空格。

MRC 工程中也可以使用 ARC 的类。方法如下

在 targets 的 build phases 选项下 Compile Sources 下选择要使用 arc 编译的文件，双击它，输入 -fobjc-arc 即可

@interface MyViewController :UIViewControlle{    UIButton *myButton;}@property (nonatomic, retain) UIButton *myButton;@end

类与类别中添加的属性要区分开来，因为类别中只能添加方法，不能添加实例变量。经常会在 ios 的代码中看到在类别中添加属性，这种情况下，是不会自动生成实例变量的。比如在：UINavigationController.h 文件中会对 UIViewController 类进行扩展

@interface UIViewController (UINavigationControllerItem)@property(nonatomic,readonly,retain) UINavigationItem *navigationItem;@property(nonatomic) BOOL hidesBottomBarWhenPushed;@property(nonatomic,readonly,retain) UINavigationController *navigationController;@end

总结

这里添加的属性，不会自动生成实例变量，这里添加的属性其实是添加的 getter 与 setter 方法。

注意一点，匿名类别(匿名扩展)是可以添加实例变量的，非匿名类别是不能添加实例变量的，只能添加方法，或者属性（其实也是方法）。

成员变量用于类内部，无需与外界接触的变量。

根据成员变量的私有性，为了方便访问，所以就有了属性变量。属性变量的好处就是允许让其他对象访问到该变量。当然，你可以设置只读或者可写等，设置方法也可自定义。所以，属性变量是用于与其他对象交互的变量。

一些建议

1. 如果只是单纯的 private 变量，最好声明在 implementation 里.
2. 如果是类的 public 属性，就用 property 写在.h 文件里
3. 如果自己内部需要 setter 和 getter 来实现一些东西，就在.m 文件的类目里用 property 来声明

在 hexo 博客中打造相对完美的 URL

那篇文章，我向大家介绍了如何在 hexo 博客中打造一个相对好看、好用的 URL 链接。然而遗憾的是，时间戳在 permalink 中没法直接使用。当时说了一个笨办法，就是模板中手动去加时间戳，然后文章生成是再取出来。不知道使用过的朋友有没有喷我…

时隔一年多，我又准备玩 hexo 了，理由是被类似为知笔记这种东西伤透了心。

然而也是一年多过去了，官方并没有做这样的支持，那我就不高兴了。在强迫症的驱使下，我读了他的源码，发现加这个时间戳相当简单，所以我义不容辞的提了这个PR。这是半个月前发生的事情，在我写这篇文章的时候，官方还没有 Merge。所以你如果想在permalink中使用时间戳。办法就是人肉把node_module文件夹下指定的文件做修改。怎么改？改哪个文件？改成啥样？请直接看那个 PR。

如果一切顺利，你现在就能愉快的玩耍了。比如：

https://demo.com/category/entitle/timestamp/

当然别忘了配置站点_config.yml

permalink: :category/:entitle/:timestamp/

最后，祝读者们儿童节快乐！

再来看

==========来自 2018 圣诞节的更新===============

最近升级了 NPM、NodeJS 及 Hexo 依赖库，发现时间戳不好使了。（PS：之前人肉改了 Hexo 的源码，看上去并没有被 Merge…）

于是有了补丁包，操作姿势：

1. mkdir patch/  && cd patch2. touch run.sh && vim run.sh#!/bin/shcp ./scripts/post.js ../node_modules/hexo/lib/hexocp ./scripts/scaffold.js ../node_modules/hexo/lib/hexo3. mkdir scripts// 将node_modules/hexo/lib/hexo对应的文件复制到新建的这个目录中。内容做点更改。更改内容参见上面提到的PR4. chmod 775 run.sh && ./run.sh// 是不是发现时间戳被加回来了....5. hexo n test

今天要说的是一个很炫的东西，叫做NodePPT

项目地址

let’s look look… demo

源码：nodeppt

文档：推荐 nodeppt：使用 markdown 语法来写网页 ppt

安装使用啥的，官方文档说的很清楚，以下为我使用笔记

1 升级版本：

npm update -g nodeppt

2 创建一个文档：

#a. 执行如下命令nodeppt create hello#b. 交互式信息补充please input：title (slide title) Hellosubtitle worldspeaker (speaker) Thomas TangSuccess：hello.md, please write your slide content#c. 使用MWeb之类的MD工具开始愉快的编写ppt吧~

3 启动预览

# 其中，-w表示watch模式，即：改动会时时生效，无需手动刷新浏览器。有没有很*的样子nodeppt start -w -p 9090

将写好的 PPT 作为 gitpages 服务发布

1、导出全部，包括 nodeppt 的 js、img 和 css 文件夹到执行目录下，如：docs

nodeppt generate . docs -a

目前发现两个问题，首先生成 docs 目录里，还有一个 docs 目录，在接着执行命令，还会继续生成。直接删掉不需要的目录；其次第一步生成的 docs 目录用了Git初始化，这就是说如果你的根目录已经用了 Git 管理，再套一层会导致推送到 GitHub 对应的目录没有文件，而git status会出现：**modified: docs (modified content, untracked content)**。解决办法还是删掉.git和.gitignore

2、有了 docs 目录后，本地打开里面的index.html，看看样式对不对，没问题之后再进行第三步
3、在 GitHub Pages 的Source处，选择：Use only the /docs folder for GitHub Pages
4、访问配置好的域名，如http://ppt.demo.com，就可以远程访问 ppt 了，这并不需要你在任何平台安装 office 全家桶
5、剩下的工作就是发挥创造力，码字，做交互。每次写完重复以上步骤就可以使得 ppt 更新

先分享核心项目和资料

Swift in server side

Perfect

Documentation

Chinese Doc of Perfect

Discuss Channel in Slack

Slack

后续的事情

之前立了一块牌坊，却始终没有内容，感觉不太合适，后续的笔记，整理整理再发上来……

背景

本文将持续跟进主题更新，除了 Github 的文档，就这里更详细了，有错误发现和建议可以直接提在本文后头

任何的软件作品，不论是成品还是半成品，提供一份易懂的说明还是很重要也非常有必要的。在这件事情上，我很抱歉！因为主题制作过程本来断断续续，开始我也只是想弄个主题供自己用，后来发到 Github 和 hexo 官方，发现还是有不少朋友喜欢，在此一并感谢。最近 Github 反馈的问题很频繁，所以写个文档显得更为迫切和有必要

主题概况

大概介绍下，主题的统计用的CNZZ，评论组件用的Disqus，搜索是Google InsightSearch，大致风格是简书网的前身。对于统计和评论，你可以直接改主题的对应文件，替换就好了，只是考虑到统计为私有信息，因此把配置放到了站点配置文件中，如果你为此感到难受，请自己放到主题配置文件里就好。多余的不用纠结。

主题发布这段时间，感谢热心网友提 PR 改进意见，现在主题已经支持Gitment，代码高亮也显示的比较顺眼了。由于个人原因，博文和主题前半年关注较少，再次一并感谢所有对开源做出贡献的朋友们，谢谢你们。后边，咱们一起装逼，一起飞……

当你下载了这份主题，改好站点配置后，第一个工作不应该是hexo g或hexo s运行演示，因为这样你一定会遇到错误，要完整的运行，你需要手动配置如下项目：

1、写作模板文件配置

在scaffolds文件夹下，保留两个文件即可：post.md和page.md，他们分别表示普通文章和独立页面

post模板内容如下

title: {{ title }}date: {{ date }}author: 托码斯avatar: /images/favicon.pngauthorLink: https://tangkunyin.comauthor: https://hello.tangkunyin.comauthorDesc: 一个写代码的「伪文人」categories: 科技tags: - hexo - webkeywords:description:photos:- img/2017/demo.jpg---

如果新建的文章要归属于某个分类，请在categories处对应你的分类名称即可。标签使用同理，一篇文章可以有多个标签，打标签的方式就是写成数组方式。photos是缩略图，地址可以是相对的，也可以是绝对的。

page模板同上，但没有categories和tags，多了comments，后者用来控制独立页是否支持评论组件。至于要把作者的信息放到模板里，是考虑到如果网站采用投稿方式，可以保留原创信息。即：显示不同作者不同文章信息，不会乱！

2、站点分类别名和自定义 URL 配置

关于自定义 URL，请参考这篇文章：在 hexo 博客中打造相对完美的 URL

分类别名和标签别名配置，站点_config.yml文件中，其中主题配置文件里的menu项需要和category_map键值对一致。二者顺序可以不同，但是主题中的顺序决定网站导航栏菜单的顺序。

# Category & Tagdefault_category: 技术category_map:技术: tech人文: humanitytag_map:hexo: hexo生活: life

3、站点左侧导航配置

# 便于动态配置导航，最新版把左导航写成配置方式了。注意 uri 前边的"-"，这里是 object 类型，内层包了数组leftPagesMenu:- uri: pageName // 这个是创建 layout 为 page 类型的页面名称，简而言之，就是独立页面名称  title: navName // 故名意思，导航名称，这在大屏幕时体现  faName: fa-wifi // FontAwesome 样式名称，最新主题使用了 4.7.0，请参考http://fontawesome.io/icons/

4、社交信息

最新一版支持了telegram, instagram, slack, twitter, github, sinaWb, facebook 7 中，你要不嫌挤，可以全部配置上

5、关于搜索功能

相对于静态博客而言，本站所使用的搜索功能，我个人觉得还是相当赞的，但是这并不意味着需要很复杂的配置，来一起看看你的package.json依赖吧：

"dependencies": {    "hexo": "^3.2.2",    "hexo-git-backup": "^0.1.2",    "hexo-renderer-ejs": "^0.2.0",    "hexo-renderer-marked": "^0.2.11",    "hexo-renderer-stylus": "^0.3.1",    "hexo-server": "^0.2.0",    "hexo-deployer-git": "0.2.0",    "hexo-generator-archive": "^0.1.4",    "hexo-generator-category": "^0.1.3",    "hexo-generator-index": "^0.2.0",    "hexo-generator-tag": "^0.2.0",    "hexo-generator-json-content": "^2.2.0"  }

请注意最后一行，那是用来生成检索数据content.json用的，这个文件在你的public下，当你无法使用搜索时，请务必检查依赖以及是否生成了数据文件。

6、关于 CNAME 多提一嘴

有朋友提Issues说，每次deploy之后，相应的CNAME文件就丢失了，难道每次deploy都需要重新创建CNAME文件，这个怎么解决啊？

这个只是你把CNAME文件放错位置了而已，解决办法就是把 CNAME 文件放到主题的 source 文件夹中，这样就不会丢了

特别提示

• 主题目前的最新版本是v1.0.2，由于时效性原因，上文提到的信息请慎重参考；
• 本站目前运行的版本和1.0.2没有特别大的差异，如有配置不清楚、运行错误等，请本文底部留言交流；

CleanMyMac

ParallelsDesktop

Charles

其他资源，麻烦自提

ShareFreeAll

awesome-mac

XClient

这里讨论一个强迫症问题

如果你是全部用英文写作，那么这篇文章对你确实没什么 Luan 用。对 hexo 而言，我们可以很轻松的自定义文章 URL。

对数字敏感，你可以在站点的_config.yml文件中permalink处配置成:year/:month/:day/:title/。是的，这个不需要改动，保持 hexo 默认就是

结果是：http://localhost:4000/2017/04/18/demo

有静态网页情结的你，认为.html结尾利于SEO，则可以把permalink配置成:category/:title.html或:category/:timestamp.html

结果是：http://localhost:4000/demo/1492523268.html

注意第二种使用分类别名，请一定要设置两个地方：

// 1、站点的\_config.yml 中找到以下部分# Category & Tagdefault_category: uncategorizedcategory_map:演示: demotag_map:## // 2、scaffolds/post.md 文件中改成如下title: {{ title }}  date: {{ date }}tags:  timestamp: {{ date }}  categories: 演示---

是的，增加了两行，在写文章时，通过hexo n demo后，生成的demo.md文件里如下：

---title: hellocategories: 演示date: 2017-04-18 22:19:45timestamp: 1447295415tags:---