6ee6df690137fd06bc6166adb63caca1

如何找出小程序项目中体积最大的文件？

发表评论

为什么要找到小程序项目中体积最大的文件？

微信小程序由于有「用完即走」的愿景，在小程序的大小上做了一些限制，单个小程序的大小需要在 2M 以内，如果小程序大于2M，则需要通过分包来实现。

在不使用分包的情况下，想要确保小程序的大小符合要求，就需要对项目中的文件进行优化。通过找到大文件，对项目的大文件进行优化是一个好办法。

如何找到项目中的大文件？

在 macOS 系统中，你可以借助命令行工具，来快速找到项目中的大文件。

你可以打开命令行，输入以下命令，获取到项目中最大的 10 个文件。

find . -type f -not -path '**/.git/**'  -exec du -h {} + | sort -r -h | head -n 10
Code language: JavaScript (javascript)

执行效果如下

命令行执行效果

代码解读

上面这行命令采用了 Linux 下的通道来进行数据的传递，可以分为以下三个子命令

  1. find . -type f -not -path '**/.git/**' -exec du -h {} + 找到当前目录下的所有文件，并执行 du -h 获取到文件尺寸
  2. sort -r -h 对输入的内容，降序排列
  3. head -n 10 提取前 10 条数据，进行展示

通过对于上述的三个子命令的理解，你可以根据自己的实际需求进行调整，适配你自己的项目情况。

building photography

平台型 Serverless 产品的必杀技：免鉴权调用API

发表评论

我在2019年的文章中（别找了，被我删了）曾经介绍过，国内的 Serverless 产品可以分为两个大类：

  1. 大公司产品：包括腾讯云云开发、字节跳动微服务、阿里云的云开发产品、Google 的 Firebase
  2. 小公司产品：比如 LeanCloud、Bmob 等等

而前者的最佳发展路线我也曾经提到过，大公司的 Serverless 想要赢得时间的最佳方案，是通过内部资源的整合，将开发者彻底绑架在自己的平台战车之上。

而这样的方案，现在已经在各家的方案中有所体现，比如腾讯云云开发和微信合作推出的「小程序·云开发」产品中的「云调用」能力、轻服务推出的免鉴权调用小程序 API 的能力。

在微信小程序中，你可以通过 cloud.openapi.templateMessage.send 来实现免鉴权调用公众号的模板消息 API ，将过去数百行的代码简化为一行代码实现，可以有效的提升开发者的开发效率。

如今，轻服务提供了类似的功能，你可以通过 inspirecloud.openapi.tt.sendTemplateMessage实现免鉴权调用推送模板消息。

我一直觉得，Serverless 这样的产品，是为小团队、创意者而生的。而这些人的特点是，对于技术的深度可能不那么在意，毕竟他们关注的是我要实现一个创意，解决一个问题，至于 Scale 的问题，是在后续才需要注意的。而对于大公司的产品来说，想要干掉小公司的产品，一个利器就是免鉴权调用平台 API。

免鉴权调用平台 API 对于开发者而言是一杯毒酒，不喝，你可能会被竞争对手超越，最终失去用户而死；喝了，你就会因为 Serverless 这样的产品模式，最终被绑死在战车之上。随之而来的，便是伴随着产品用户规模的不断提升的，是这些 Serverless 基础设施的成本就会逐渐超过你使用传统的服务器模式的成本。

但回过头来说，你真的能拒绝这样的平台优势么？很难，即使作为我这样的前后端一把梭的开发者，也很难抵挡 Serverless 产品前期的低成本和快速迭代，对于大量无法独立完成大型后端开发的工程师来说，这是一个必须喝下去的毒酒。

希望你在选择技术方案的同时，不给自己挖坑。

blue and red cargo ship on sea during daytime

用 Docker 调试 Nginx

发表评论

容器技术被广泛应用在各种场景，在实际的应用过程中，我们也可以根据自己的需要，进行各种配置。我最近因为在调试 Nginx ，因此，也使用 Docker 来调试 Nginx。

Requirements

  • 已经安装 Docker
  • 安装了 docker-compose

实现思路

docker-compose 可以帮助我们把一些 Docker 启动的配置给简化，通过编写配置文件，简化启动容器的命令。

具体操作

创建一个项目，并在项目的根目录中放置 docker-compose.yml 以及 nginx.conf。其中，nginx.conf 是你需要测试的 nginx 文件，docker-compose.yml 则是用来记录你的 Docker 容器启动配置。

文件结构

启动容器并测试效果

将你需要测试的配置文件内容放置在 nginx.conf 中，并在dockcer-compose.yml 中添加如下内容

web:
  image: nginx
  ports:
    - "8080:80"
  volumes:
    - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
  command: [nginx-debug, '-g', 'daemon off;']
Code language: JavaScript (javascript)

随后，执行 docker-compose up 就可以启动容器，并展示出容器的运行效果

执行效果

此时，你就可以访问 localhost:8080 来查看你自己的配置了。

building photography

平台型 Serverless 如何赋能中小开发者？

发表评论

在 1 月 7 日的推文中，我有提到，「大公司的 Serverless 想要赢得时间的最佳方案，是通过内部资源的整合，将开发者彻底绑架在自己的平台战车之上」，对于很多人来说，如何理解这种内部资源的整合和它带来的赋能开发者？今天就用小程序 · 云开发最近开放的一个新能力 —— 短信跳小程序为例来聊一聊。

短信跳小程序这个能力其实背后是另外三个能力的组合：

  1. 微信最近开放的 URL Scheme ，我已经在 1 月 9 日的推文中写到了。
  2. 云开发的网站托管能力
  3. 腾讯云自有的短信推送能力

云开发基于上述的两个能力，辅以一些很低的开发工作量，实现了短信跳小程序这个能力。

其中，云开发的网站托管能力和短信推送能力，便是平台型 Serverless 产品内部资源整合而来的。

同样是一个 Serverless 团队要做这样的功能，作为小公司的 Serverless 就会面临：

  1. 短信服务供应商的选择和沟通
  2. 短信签名的审核和提交
  3. 底层代码拉通

但大公司的平台内往往已经自有短信推送的渠道，平台型 Serverless 只需要将底层代码拉通，就可以完成产品能力的对接。

这一点相比于小团队的重新选择供应商等，流程和耗时要少的多，要踩的坑也少的多

平台型 Serverless 团队借助于这样的很多内部能力，就可以轻松实现各种各样的能力，让开发者可以以最低的成本在自己的业务系统中加入产品能力。实际发布给开发者使用的产品，也就变得更加的简单易用。

就短信触达用户而言，云开发将这个能力做到了极简，你需要做的仅仅是将模板代码上传到静态网站托管中，并部署一个配套的云函数，就可以用cloud.openapi.cloudbase.sendSms触达你的用户，剩下的无需你操心，就自动完成了相关的功能。

const cloud = require('wx-server-sdk')
cloud.init()
exports.main = async (event, context) => {
  try {
    const result = await cloud.openapi.cloudbase.sendSms({
        env: 'online-12345678910',
        content: '发布了新的能力',
        path: '/index.html',
        phoneNumberList: [
          "+8612345678910"
        ]
      })
    return result
  } catch (err) {
    return err
  }
}
Code language: JavaScript (javascript)

作为一个云开发的用户，我很期待有更多的同类型功能出现。

node js 736399 640

用 KOA 做 API Mock

发表评论

在测试一些服务的时候，会需要用到一些第三方 API， 但如果你在测试的时候需要调用这个 API 的同时，又不太关注这个 API 具体的返回值的时候（比如你要测一个功能，但这个功能依赖了一个第三方服务，这个服务的返回值并不是你所关注的）。你需要一个比较好用的 Mock 方案，来解决这个问题。

写一个 Mock 服务并不是很复杂，想要写好的话，又不是一个很简单的事情。因此，各种语言提供的一些轻框架就是一个不错的选择。比如说我比较常用的是 KOA。

Koa 是 Node.js 下的一个轻量级框架，你可以通过简单的几行代码，构建一个简单的 HTTP 服务。

比如说我测试的服务依赖了两个第三方服务，这个时候我就可以借助于 Koa 提供的基础能力，快速编写出两个 API，从而在本地构建一个高性能的 Mock 服务。

比如说，这是我的一个 Mock 服务的代码案例。

其中我只使用了一个中间件，在中间件中使用 startsWith 来匹配请求路径，从而接管该路径下的所有请求，实现针对同一个 API 的所有请求返回一个特定的结果。

const Koa = require('koa');
const app = new Koa();
// response
app.use(async ctx => {
    ctx.body = "ok"
    if(ctx.url.startsWith("/api/xxx/")){
        ctx.body = 'need return2';
    }
    if(ctx.url.startsWith("/v2/xxx/")){
        ctx.body = 'need return 1'
    }
});
app.listen(3000);
Code language: JavaScript (javascript)

如果你希望这个方案进一步优化，则可以考虑在返回结果时，给出一组数据，使用 Random 来在每一次返回时给出一个随机值，确保返回的数据不是唯一的。

black and white penguin toy

@action/checkout 如何抓取所有的历史记录

发表评论

GitHub 的 Action Template 中默认带了一个 checkout 插件，这个插件可以实现将你的项目 Clone 到 CI 的运行环境中，从而执行各项操作。

为了提升速度，Github 在实际上实现的时候，默认会限制 depth=1，这就导致在 clone 的时候，仅 clone 一个 commit ，如果你需要依赖 git 进行操作，则需要更多的 commit 。

在具体的实现过程中，你需要做的仅仅是在配置 github action 中的 fetch-depth 选项，设置为你需要的 commit 数量。如果你需要的是所有的 commit， 则将该选项设置为 0。具体配置如下

- uses: actions/checkout@v2
        with:
          fetch-depth: 0

这样你就可以在 CI 中访问到所有的数据。

不过，这样你并不能直接执行诸如 git merge-base 这样的命令，因为你虽然将所有的数据抓取到了本地，但并没有建立相应的分支，则需要你先建立相应的分支，才能进行处理。

这个时候你可以在 action 当中新增一行，用来切换分支。

- run: git checkout x

这里的 x 是你需要操作的分支，不过你需要注意，切换过来以后，还需要重新切换回去，不然你的代码就版本不对了。

code 1076536 640

低代码之殇

发表评论
2021 01 19 142921

我在前一段时间就发过朋友圈吐槽过 Low Code 和 No Code 工具。今天想更加系统的阐述我对于这个问题的看法。

以下内容以问答的形式进行。

1. Low Code/No Code 有价值么？

当然有价值。在传统行业中，大量的行业效率是非常低下的，借助于 Low Code/No Code 工具，可以以更低的成本，很好的解决传统行业遇见的问题。

此外，很多传统行业面临的问题其实是一致的，如果将这些问题的底层逻辑拆分并打包成独立的模块，就可以很好的在 Low Code/No Code 中应用。

2. 你为什么发朋友圈吐槽 Low Code/ No Code？

Low Code 和 No Code 近来有些过热了。几乎所有人都在想着要去做一个 Low Code/No Code 平台，这是有问题的。

Low Code 和 No Code 平台的用户是有限的，而不是像 To C 应用，理论上是无限的。在这种情况下，过热会让这个领域轰轰烈烈的生，轰轰烈烈的死。反而可能不会让 Low Code 和 No Code 落地。

目前很多 Low Code 和 No Code 平台的落地逻辑都是基于人人可用，但在实际落地的时候，你会发现，并非人人都是理性且有逻辑的。Low Code 和 No Code 对于逻辑的要求是比普通的 To C 应用更高的，因此，用户群体规模会被进一步缩小。

现有的 Low Code / No Code 工具在处理复杂的业务路逻辑的时候，并不会说完全不需要代码，大部分会在某个关键节点上需要不到 100 行代码，但也正是这100行代码， 限制了 Low Code、No Code应用的用户规模。

3. 你看好国内做 Low Code/No Code 么？

我总体来说，看好产品形态，但不太看好做这个产品的公司。原因是国内的企业大多没有开放的基因，比较喜欢玩「私域流量」，这会导致在跨企业的合作上变得十分困难。

但 Low Code / No Code 产品不可能由一家公司完全做好所有的模块（如果真的做了，那他的投入和长期的收益回报是非常可观的），这就导致在国内做 Low Code/No Code 是一个脏活累活，而不是一个可以轻易 Scale 的产品。

我其实用过很多海外的 Low Code/No Code 产品，其大多是构建一个开放平台，各家接入，这些国内的风气还没有起来，还有待观察。

4. 你会去使用 Low Code/No Code 平台么？

我一直在使用，比如 Notion、AirTable、IFTTT、Zaiper、Microsoft Flow 都是我常用的工具，我会根据实际的使用场景决定使用什么样的工具。

797c396d4608cc56c4f96bbcca699422

工具创造者的自我修养

发表评论

独立开发者中有一大批人是通过做工具来获取收入的。做工具也算是独立开发者圈子中经久不衰的话题了。

但到了具体的工具开发之时，其中又有不少可以拿来讨论的内容。

而这里，我最想讨论的是工具的理念。

992zk

对于工具类的软件开发而言，最容易出现的就是「别人做了一个什么东西，我觉得不够新/便宜/不爽，我自己也要开发一个」。对于开发者来说，遇见问题， 并自己解决问题是非常常见的。 但是，工程师常常的问题也在于此，因为复制一个产品的成本越来越低，所以最先选择的是复制，而不是思考这个产品的长期发展道路。这会让产品陷入简单的 Copy and Paste 的模式下，长期来看，并不利于产品发展。

在我看来，如果工程师想要做好一款工具，那么一定要为自己的工具准备一个最基本的方法论。这个方法论一定是基于你自己对于问题的看法做出的拆解，而不能是依赖于其他第三方软件的。

这个方法论将指导你的产品朝着最终的目标，要解决的问题，奋力前行。你后续所遇见的问题，都会成为你前行的助力，为拓宽前进的道路。

fcu1l

而一个没有方法论的产品，则会被途中遇见的各种问题引导偏离最初的目的地。我们目前的市场中有太多的工具了，每一款工具都有其优秀之处，倘若没有自己核心的理念，那只会被众多的 Feature 搞得「乱花渐欲迷人眼」，最终失去了自己对于工具的定位，抄成了一个四不像。

i2wjj

总结

如果你想要以一个小团队打造一款好用、生命力持久的工具，那么先想清楚你的目标和理念，再动手开发，是一个好的路子。需求有很多，但并不是每一个都适合你。工具有很多，也不是每一个都适合你，预期去抄别人的理念，做别人要做的工具，不如发现自己的需求，做自己的工具。

6ee6df690137fd06bc6166adb63caca1

物联网设备如何链接到你的小程序？

发表评论

物联网项目在涉及到传统行业的数字化改造时，是一个非常常见的选择。通过对于传统的物联网设备进行改造，就可以和云计算设备链接起来，并辅以大数据设施，完成对于产业的优化和迭代。

而到了具体物联网设备和小程序开发时，主要有以下几种链接方式：

直接链接 · 蓝牙

蓝牙链接物联网设备算是最为常见的方式。小程序提供了蓝牙的接口，你只需要调用蓝牙接口，链接到物联网设备上，并读取数据，就可以实现和物联网设备的链接。

比如你可以使用小程序来链接小米手环（如果你知道他的蓝牙配置）。

直接链接 · NFC

小程序提供了 NFC 接口，有了 NFC 接口，你就可以调用机身自带的 NFC Reader 和 NFC Writer 对 NFC 卡片进行读取和写入，来完成和外部设备的交互。

对于 Android 用户来说，使用 NFC 交互可以快速完成近场通讯的数据同步问题。

直接链接 · WiFi

小程序提供了 WiFi 接口，如果你的物联网设备可以对外提供 WiFi 服务，则可以通过调用 WiFi 接口，连接到指定 WiFi，并通过标准的 HTTP 接口来获取数据。

间接链接 · WiFi

WiFi 除了可以用作直接链接，还可以用作间接链接，你可以让设备通过 WiFi 连接到互联网上，并通过 HTTP 协议与服务器进行沟通，从而与服务器之间进行交互，交互完成后，你就可以在小程序端直接读取数据了。

间接链接 · NBIoT

NBIoT 你可以简单理解为手机卡链接，只不过使用的是物联网卡和2G/3G模组。如果你的设备上链接了 NBIoT 设备，就可以直接通过 NBIoT 设备访问到你自己的服务器，并提交信息。

总结

物联网的链接方式随着基础设施的迭代，会有不断的更新。如果你知道有别的方法， 欢迎留言告诉我。

red and white nescafe ceramic mug

如何将 HTTP 请求中的 UA 转化为可读的 UA 信息

发表评论

什么是 UA （User Agent）

UA 是 HTTP 在发送请求的时候，带上的请求方的各项基本信息。就我自己为例，我的 UA 是 Mozilla/5.0 (Macintosh; Intel Mac OS X 11_1_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36 Edg/88.0.705.50

这个 UA 当中包含了大量的我的基本信息，包括我的电脑信息、我的操作系统、浏览器的版本等。

在具体的 UA 信息中，具体的结构为

User-Agent: <product> / <product-version> <comment>
Code language: HTML, XML (xml)

如果有多组 UA 信息，则语法如下

User-Agent: Mozilla/5.0 (<system-information>) <platform> (<platform-details>) <extensions>
Code language: HTML, XML (xml)

UA 能够帮助我们理解什么？

UA 可以提供设备的基本信息，比如浏览器、比如设备的版本号等，有了这些信息，我们就可以分析用户的使用习惯、使用场景等信息。

比如，当 UA 中有大量的访问是来自微信浏览器，那么你就可以考虑针对微信的浏览器提供一些优化，比如使用微信自带的第三方 SDK 等信息。

如何将 UA 转换为可读的 UA 信息？

各种语言都有自己的 SDK 来实现从 UA 的 String 提取出操作系统的信息，一般来说，都是通过正则表达式来识别的，你可以在 Github 上找到你所使用的语言提供的 SDK。

不过，除了使用开源的 SDK 以外，你还可以考虑使用一些服务来进行解析，比如我今天发现的 User Stack

kyibb

UserStack 是一个 UA 识别服务，如果你接入该服务，就无需自己维护 User Agent 的识别规则，由服务帮你维护，你只需要调用该 API 即可实现对设备的识别。

总结

UA 转换为人类可读的信息需要通过第三方 API 或开源的 SDK 来实现，你可以根据自己的需要来选择不同的方案。SDK 免费可用，但可能更新不够频繁，无法很好的兼容一些重要的设备。