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 免费可用,但可能更新不够频繁,无法很好的兼容一些重要的设备。

5e54199359bbafe0ef692365a9bcffb6

如何修复 Beego 运行测试时的报错 undefined: web.Trace

Beego 近来已经更新了 2.X,因此,你现在可以使用更新版本的 Beego 来完成你的快速开发。

不过,beego 2.x 在使用 bee 工具初始化一个新的项目时,默认的项目中有一个 bug,当你在项目根目录下执行 go test ./... 时,会提示 tests 目录中有一个错误。而你并没有修改任何的源文件。

如果单独执行 tests 目录,就会报错如下内容

tests/default_test.go:28:2: undefined: web.Trace
Code language: JavaScript (javascript)

你会发现这段代码指向了 default_test.go 中的这行代码。

beego.Trace("testing", "TestBeego", "Code[%d]\n%s", w.Code, w.Body.String())
Code language: CSS (css)

这段代码中的 Trace 找不到导致无法正常使用。

我通过一些搜索,找到了答案。在 GitHub 中,beego 的 repo 下有一个 issue 和一个 pull request 与这个 bug 相关。结论是这个方法已经被移动到 log 文件夹,因此需要调整一下输出的来源。

在代码中引入 "github.com/beego/beego/v2/core/logs" 并将 beego.Trace 替换为 logs.Trace ,即可解决这个问题。

修改后的代码如下:

package test
import (
    "net/http"
    "net/http/httptest"
    "testing"
    "runtime"
    "path/filepath"
    _ "backend-server/routers"
    "github.com/beego/beego/v2/core/logs"
    beego "github.com/beego/beego/v2/server/web"
    . "github.com/smartystreets/goconvey/convey"
)
func init() {
    _, file, _, _ := runtime.Caller(0)
    apppath, _ := filepath.Abs(filepath.Dir(filepath.Join(file, ".." + string(filepath.Separator))))
    beego.TestBeegoInit(apppath)
}
// TestBeego is a sample to run an endpoint test
func TestBeego(t *testing.T) {
    r, _ := http.NewRequest("GET", "/", nil)
    w := httptest.NewRecorder()
    beego.BeeApp.Handlers.ServeHTTP(w, r)
    logs.Trace("testing", "TestBeego", "Code[%d]\n%s", w.Code, w.Body.String())
    Convey("Subject: Test Station Endpoint\n", t, func() {
            Convey("Status Code Should Be 200", func() {
                    So(w.Code, ShouldEqual, 200)
            })
            Convey("The Result Should Not Be Empty", func() {
                    So(w.Body.Len(), ShouldBeGreaterThan, 0)
            })
    })
}
Code language: JavaScript (javascript)

参考阅读

black and white penguin toy

如何使用 GitHub Action 自动部署 MKDocs

MKDocs 是一个基于 Python 写成的文档生成工具,在实际的使用过程中,我们可以借助 GitHub Action 来实现自动部署到 GitHub Pages 。

操作流程

首先,你需要先在本地生成一个 MKDocs 项目

qyeuk

生成后, 你可以在项目的根目录创建 GitHub Action 所需目录。

mkdir -p .github/workflows/

并创建一个配置文件 publish_docs.yml

name: Publish docs via GitHub Pages
on:
  push:
    branches:
      - main
jobs:
  build:
    name: Deploy docs
    runs-on: ubuntu-latest
    steps:
      - name: Checkout main
        uses: actions/checkout@v2
      - name: Deploy docs
        uses: mhausenblas/mkdocs-deploy-gh-pages@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          CONFIG_FILE: mkdocs.yml
          EXTRA_PACKAGES: build-base

创建完成后,将配置文件添加到版本控制中,并提交到 GitHub 上,就可以在你提交代码的时候,自动推送到 GitHub Pages 中。

需要注意的是,我使用的是 MKDocs 的 Material Design 主题,如果你使用的是其他主题(非自带的主题),则需要修改 EXTRA_PACKAGES 的配置。

代码解读

这个配置文件中主要是 on 和 steps 比较有学习的价值。

on:
  push:
    branches:
      - main

这段代码限制了,只有在 main 分支上,出现了 commit 的时候,才会触发这个 action 的执行,如果是其他的分支,则不会触发 action 的构建。

    steps:
      - name: Checkout main
        uses: actions/checkout@v2
      - name: Deploy docs
        uses: mhausenblas/mkdocs-deploy-gh-pages@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          CONFIG_FILE: mkdocs.yml
          EXTRA_PACKAGES: build-base

这里的两个 step, 第一个是 clone 出所有的代码, 第二个 step 就是我使用一个已经做好的 action mhausenblas/mkdocs-deploy-gh-pages@master,这个 action 的作用就是将 mkdocs 的文档生成并部署到 GitHub Pages 中。

这个 action 自带了 material design 的主题,执行后,会构建并推送到 GitHub Pages。如果你使用的也是这个主题就可以直接按照我的样式进行配置。如果你使用的不是这个主题,则需要将你的主题配置在 EXTRA_PACKAGES,从而让 action 在执行的时候安装相应的 package。

总结

GitHub Action 的 Marketplace 中有大量的现成 Action 可以供你使用,借助现成的 Action ,你可以非常简单的完成自己的 CI/CD 流程,非常方便。