标签归档:开发经验

使用 Taro 的一些小配置

使用 Taro 的一些小配置

我自己在使用 Taro 开发小程序的时候,一定会开启的两个配置:

1. 开启压缩

Taro 在预览模式生成的文档比较大,对于小程序的预览来说,不是很友好,所以开发的时候,我经常会打开压缩,以便于在小程序开发者工具进行预览。

修改也比较简单,只需要在你的 package.json 当中加入对应的环境变量 NODE_ENV=production 来支持即可。

diff 见下

2. 开启 webpack 持久化缓存

Taro 可以开启 webpack 的持久化缓存,以便加速 webpack 的构建速度,因此我也会开启这个配置,以提升构建的速度。

树莓派开启密钥登录

树莓派开启密钥登录

由于树莓派跑内网,再加上这个树莓派算得上是我的实验机器。因此便打算直接使用 root 来完成日常操作,懒得在 pi 和 root 用户之间切换了。而 root 登录,我又不希望使用密码登录(以我的懒散的性子,可能会设置一个比较短的密码),便为树莓派配置了密钥登录。

先使用 pi 登录到树莓派上,并切换至 root 用户。在 root 用户下,将我本地公钥复制,并放在 ~/.ssh/authorized_keys 当中,保存并退出。

接下来,就可以在本地以 ssh root@ip 的方式直接登录树莓派了。为了简化这个ssh命令,我还配置了 SSH Config 的别名,来简化我的登录命令(具体可参考 如何用 SSH Config 来优化你的 SSH 连接?

使用 glean 插件优化你的 React 项目

使用 glean 插件优化你的 React 项目

React 相比于 Vue 的好处是你可以相对轻松的将一个组件抽离出来,这使得开发者可以根据自己的需要进行抽象。

但手动抽象组件还是相对较麻烦,于是我便搜索有没有一些方便的插件,可以帮助我更好快的完成组件的抽象。于是乎便找到了 Wix 出的 glean 插件。

glean 插件可以将任意层级的组件抽出为一个全新的函数,并在之前的位置引用你的函数,因此,你可以先非常快的构建出一个完整的 UI 界面,再基于这个界面,进行不同层次的抽象。或者是在开发界面时,随时根据需要来完成界面的抽象。

官方提供的 Demo

在实际使用过程中,你可以将 glean 插件提供的命令设置为快捷方式,从而实现更快的抽象组件,或者是点击组件前的黄色小灯泡💡来完成组件的抽象。

黄色小灯泡
使用 Obsidian 的 CSS 代码片段优化你的 Obsidian 体验

使用 Obsidian 的 CSS 代码片段优化你的 Obsidian 体验

我最在研究使用 Obsidian,期间更换了不少的主题,但都不尽如人意,主要的原因便是行高度。大部分主题的行高都是面向英文设计,对于中文场景下的方块字,会使得整个页面的拥挤度极大, 非常容易让你感受到挤压感。

因此,我决定使用 Obsidian 自带的 CSS 代码片段功能来优化我的体验。CSS 代码片段可以在你自己的存储库内存储一些 CSS 样式,并生效在你的 Obsidian 当中,从而为你带来优化界面的可能。

打开 Obsidian 设置,进入「外观」—「CSS 代码片段」,可以看到这里的配置。默认情况下,是没有任何配置的。你可以点击右上角的打开目录的 Icon ,进入到 CSS 存储目录,创建对应的 CSS 文件。创建完成后,回到 Obsidian 中启用这个 CSS 就可以达成你的效果了。

实务

以我自己为例,这是我使用的 Obuntu 主题的默认行高,看起来不算特别差,但总感觉行与行之间的距离太近,让人略感压抑。

摘录

于是,我便在刚刚说的 CSS Snippet 文件夹下新建了一个 line-height.css 文件,并在其中添加如下代码,并在设置中生效。

// 以下代码仅用作演示
*{
  line-height: 2 !important;
}

Obsidian 的 UI 中的文字就会变得更易于查看了,这样就达成了我的目标。不过,我上面写的 CSS 非常的粗糙,是对所有的文字都进行了修改(包括那些本来不应该修改的),所以在真实场景下使用,还是需要自行 Debug 来进行修改。

参考

通过 Code Snippet 提升效率

通过 Code Snippet 提升效率

在开发应用的时候,我们常常会借助快速生成工具来帮助我们生成一些模板代码。

相比于 JS,Ruby 干脆让很多需要手动输入的地方可以不用输入,体验会更好。Rails 更是做到了极致,大量的约定。对于一些模板化的行为,你甚至可以不用写代码,框架帮你来解析。

常见的编辑器比如 VSCode、Sublime Text 都提供了大量基于插件的 Code Snippets,方便你可以快速生成一段模板代码。

不过在实际开发过程中,他们提供的模板代码可能并不太符合我们的需求,我们往往可能会有一些定制化的需求需要满足,这个时候,就比较依赖自定义模板了。

好在各种编辑器不止可以通过插件来定义 Code Snippet,你还可以自定义自己需要的 Code Snippet。

以 VSCode 为例,你可以参考其官方文档来定义自己需要的 Code Snippet,只需要简单的配置,就可以定义出你自己所需要的 Code Snippet。它可以是你自己写代码时的 Code Snippet,也可以是你在写博客时的 Code Snippet(比如写博客时自动生成前置的描述信息)。

不过,Code Snippet 的语法很多时候比较麻烦,需要一行一个字符串,对于较为复杂的 Code Snippet,构建这个 Code Snippet 本身就比较麻烦。好在有一些第三方工具,可以帮助简化这个过程。比如 Snippet Generator 就可以非常方便的帮助生成 VSCode 的语法,你只需要将需要生成模板的代码粘贴在左侧,并填写一些基本信息,就可以生成包括 VSCode、Sublime、Atom 的 Code snippet 代码,再将其粘贴到你的 VSCode 的配置中即可。

Snippet Generator

你还可以将其中的一部分内容替换为对应编辑器所提供的占位符,就可以帮助你更加高效的利用这个 Snippet 来完成内容的快速撰写。

其他

如何用 SSH Config 来优化你的 SSH 连接?

如何用 SSH Config 来优化你的 SSH 连接?

在 Windows 的时候,我一度非常喜欢使用诸如 XShell 之类的软件,主要原因是我可以将不同的服务器信息保持在同一个软件当中,不用每次都手动保存(Putty往往就无法保存)。

而到了 macOS 之后,我不再使用 XShell 这样的软件来完成我的 SSH 工作流(事实上我也找不到类似 XShell 的软件,后来在 Setapp 软件包中发现了 Core Shell,但我已经有了下面的技巧了,就没再用)。

经过一番研究,我发现对于我的诉求来说,其实完全没必要使用一款第三方软件来完成,SSH 自带的功能即可完成。

再次 Review 一下我的诉求:

  1. 我希望不要输入 IP 地址,而是输入一个短语,或者是域名来连接我的服务器。
  2. 我希望能够支持自定义端口,因为我一般会把我的服务器端口从 22 改为一个随机的数字。
  3. 我希望可以指定密钥文件,因为我有多个密钥,不通的场景可能使用不同的密钥。

这些诉求如今我的新方法都可以实现。

SSH 支持自定义 Config 文件,而默认的 Config 文件位于 ~/.ssh/config 这个文件中,你可以在其中添加自己的配置来实现自定义 SSH。

比如这里用到的就是 SSH Config 中的 Host 定义,你可以以如下的规则来定义一个新的配置。

Host 主机名
    User 登录用的用户名
    HostName 登录用的主机名,可以是域名或者IP
    Port 登录用的端口号
    IdentityFile 需要使用的密钥文件

比如下图就是一个配置的例子

通过在你的 Config 文件当中添加对应的定义,你就可以用 ssh 主机名 的方式来连接你的服务器了。

比如,我的树莓派的配置的主机名是 pi 那我就可以使用 ssh pi 的方式来连接到我的树莓派当中。

在油猴脚本中实现新增按钮和按钮的点击效果

在油猴脚本中实现新增按钮和按钮的点击效果

在油猴脚本中,有些时候,我们需要在界面当中添加一个新的按钮。这个时候我们可以使用 document.getElementById("id").innerHTML=xxx 来指定某个元素中的内容是特定的 HTML,从而实现添加一个新的按钮。

但在这个按钮上绑定事件则不是通过简单的指定 button 的 onclick 来完成的。核心原因是默认情况下,你在油猴脚本中所写的函数只运行在油猴脚本中的 Scope ,而 button 则是运行在 Document 的 Scope 下。直接绑定事件在触发时会无法找到对应的函数。

一个好的办法是为你新增的 Button 带上 ID,并通过 ID 找到对应的 Element 并添加事件绑定来实现。

参考代码如下:

// ==UserScript==
// @name         示例代码
// @namespace    https://www.ixiqin.com
// @version      0.0.1
// @description  示例代码
// @author       bestony
// @license      MIT
// ==/UserScript==

(function () {
  'use strict';
  window.addEventListener('load', function () {
    function viewAuthor() {
      // button click event
    }

    var targetElement =document.getElementById("xxx")

    targetElement[0].innerHTML = targetElement[0].innerHTML + ` &nbsp;<a id="view-author">查看作者</a>`

    var link = document.getElementById("view-author");
    if (link) {
      link.addEventListener("click", viewAuthor, false);
    }
  }, false);
})();
油猴脚本不支持 Modules Javascript 导致空白脚本报错

油猴脚本不支持 Modules Javascript 导致空白脚本报错

最近在写一个油猴脚本时,因为懒得写 DOM 处理函数,我试图在油猴脚本当中引入 Zepto.js, 用于实现 DOM 操作。

但在引入 Zepto 之后,发现即使是空白的脚本文件,在网页加载时依然会报错。经过排查发现,是我引入的 Zepto 文件导致的,进一步研究后发现,之所以有这个问题,是目前油猴脚本仍不支持 Modules ,因此,我引入 Zepto 就会报错。

想要解决这个问题倒是也简单,将 Zepto 替换为 JQuery 即可。本来想着用 Zepto 会轻量一点, 最后发现还是要上 JQuery。好在是目前 JQuery 提供了不含 Ajax 和 Effect 的 Slim 版本,倒是也不用担心引入的依赖文件特别的大。

三个有用的 Golang 辅助网站

三个有用的 Golang 辅助网站

在我数十年的编程生涯里,我大部分时间写的都是动态类型语言,所以我对于类型并不太感冒。不过,当我在写 Golang 的时候,确实遇到了一些过去写 PHP、 Node.js、前端不同的问题。

一个最令我困扰的点便是:对于 JSON 的处理,需要先定义结构体来做转换。对于一些简单的 JSON 结构,我还可以简单的完成定义。但如果是一些比较复杂的结构体,我就放弃了手动定义,而是选择借助一些辅助工具来完成

比如我最常用的便是各种 JSON to Go 的网站,贴一个 JSON 进去,然后自动生成对应的 Golang 的 Struct,接下来我只需要复制右侧生成的 Struct 到我的代码里,就可以完成 JSON 的定义,使用 Golang 自带的 JSON 库解析即可。

截图的网站是 https://mholt.github.io/json-to-go/

另外一个可以实现 JSON 转换成 Go Struct 的网站是 https://transform.tools/json-to-go,它提供了更加全面的转换路径。不过有些时候选择太多也会让我有点困惑。

另外一个令我困扰的也是类似的格式转换,不过是 YAML 的。思路相同,手写要配置的 YAML 文件,并生成对应的 Struct: https://zhwt.github.io/yaml-to-go/。在设计风格上,和上面的 JSON2Struct 类似,是基于上面的项目改造过来的。

除此之外,如果你在定义 YAML 的时候, 对于部分数据如何定义不太明确,可以考虑使用 JSON2Yaml 的工具来实现将你需要的数据转换为 YAML 定义。

在 Go 当中嵌入父目录中的文件

在 Go 当中嵌入父目录中的文件

自 Go 1.16 版本开始,Go 提供了将二进制文件打包进入到 Binary 文件当中的机制:`//go:embed。不过,我看到的示例大多数都是嵌入当前文件夹下的子文件夹的示例。并没有嵌入父一级文件夹的示例。于是,我便开始研究起来。

为什么会需要嵌入父目录中的文件?

这是因为不同的项目的构建规则不同。一些小型项目可能只有一个 main.go 或同级目录下几个其他的 go source 文件即可,但对于更大型的项目,合理的项目拆分是有助于帮助提升项目的可维护性的。

以我为例,我的目录结构如下:biz 目录下是我的核心逻辑,也是我日常写代码的地方;conf 则放置了各种配置,比如各种 API Key,ral 则是网络访问层,比如我比较喜欢用 gin 来做底层的网络访问层;script 放置了开发所需要的各种脚本文件;static 则放置了前端所需要的 JS / CSS 文件。在开发一些偏内容向的页面时,我会习惯使用 Server Side Render,所以我在 biz 目录下还有一个 template 目录。而主要的逻辑则放在 handler。

├── biz
│   ├── dal
│   ├── handler
│   ├── logic
│   ├── service
│   └── template
├── conf
├── ral
│   └── gin
├── script
└── static
    └── public

在日常开发时,一个非常常见的操作是在 handler 里处理基本的逻辑,并将 template 中的模板渲染出来,并返回给用户,这个时候就需要在 handler 里使用上一级目录的文件了。

错误的尝试1:使用 .. 来引入

作为文件系统的常规配置,我自然知道可以通过 .. 来代表上一级目录,因此我试着使用如下的语法来引入文件

//go:embed ../template/*

结果报了个错误 invalid pattern syntax。看得出来,是因为我的语法出现了问题。

通过搜索,我找到了这个 Github issue,才得知,由于避免跨模块的访问,go embed 阻止了 .. 语法的使用

Because embed.Files implements fs.FS, it cannot provide access to files with names beginning with .., so files in parent directories are also disallowed entirely, even when the parent directory named by .. does happen to be in the same module.

https://go.googlesource.com/proposal/+/master/design/draft-embed.md

错误的尝试2: 使用 go:generate 来执行复制

在上面的 issue 当中,我注意到还有另外一个方式,可以实现类似的效果。可以借助 go:generate来实现在执行 go generate 方法时,复制文件到本地,这样就可以实现在 Build 二进制文件之前,把文件复制到本地,即规避了跨模块的问题,也避免了将 template 文件放在本地,污染代码目录的问题。

//go:generate cp -r ../../assets ./local-asset-dir
//go:embed local-asset-dir
var assetFs embed.FS

这个方法在运行的时候没有效果,不过在其他人可能是有效果的(我猜是因为我开发时很少直接用 go generate,都是直接 go run 了)。不过,这个方法也有个问题,因为是写在代码本身当中的,很有可能后续因为某些原因,这些代码被误删除或修改了,导致整个系统的运行不正常。而散落在各文件的描述也会使得修复十分复杂。

正确的做法

在看这个 issue 的最后,我注意到了正确的用法,在另外一个 issue 当中,开发者 tomasf 提到了,我们应该在 asset 目录下创建一个 embed.go 来完成 embedFs 的建立,并在其他文件直接引入这个文件,完成定义。

You can create a embed.go file in your assets directory and make the assets available as it’s own package to the rest of your program.

tomasf

这个说法一出,豁然开朗!尝试一下,果然有效。我在 template 目录下创建了一个 embed.go 文件,并添加了如下代码。

package template

import "embed"

//go:embed *
var TemplateFs embed.FS

并在另外一个文件当中使用template.TemplateFs.ReadFile("index.tmpl") 来完成模板文件的引用。这样既不违背 golang 的跨模块,也不会使得代码不可维护,非常好。

参考阅读

  • https://go.googlesource.com/proposal/+/master/design/draft-embed.md
  • https://github.com/golang/go/issues/46056
  • https://github.com/golang/go/issues/41191#issuecomment-686621090
  • https://blog.carlmjohnson.net/post/2016-11-27-how-to-use-go-generate/
  • https://blog.carlmjohnson.net/post/2021/how-to-use-go-embed/
在 Dokuwiki 当中接入 draw.io 的绘图

在 Dokuwiki 当中接入 draw.io 的绘图

作为一个工程师,我难免会在自己的博客 / Wiki 当中加入流程图、时序图之类的。因此,需要更加简单的绘图的方式。

过去往往是采用本地绘制好图片,然后再复制上传到 Wiki 当中。不过,随着 tldraw、draw.io 等一类在线绘图工具出现以后,大家开始习惯于在线绘制图片。

在使用飞书文档的时候,我觉得其中内嵌 Diagram.net 的服务体验很不错。

现在,在 Dokuwiki 当中你也可以实现类似的功能。安装 Dokuwiki 上的 drawio 插件,随后,在你们的编辑器当中就可以看到一个 Drawio 的图标,点击这个图片,就可以插入一个 Drawio 的图片引用

Drawio 的图标

插入完成后,你可以在下方的输入框当中看到插入新的引用,此时你可以修改具体的文件名和对应的 namespace。

插入完成后,点击保存(也可以在预览中修改),保存成功后,你会看到一个 Start drawing by clicking here,点击这个图标,就可以在渲染出的新的 UI 当中绘制你想要的流程图。

绘制完成后,点击右上角的保存,即可保存你绘制的流程图。

此时,你的流程图就绘制好了,其他人看的时候也是你画好的流程图。

后续如果你需要编辑这个流程图,只需要在登录的状态下,点击绘制好的图片,就会自动进入到编辑的模式,允许你修改你的流程图。

以下是一个简短的视频介绍:

在 Dokuwiki 当中实现拖拽上传

在 Dokuwiki 当中实现拖拽上传

在 Dokuwiki 当中,如果你想要上传一个文件,需要先将文件通过媒体管理器上传到wiki当中,再将对应的媒体插入到对应的页面中,流程繁琐不说,还容易把文件上传到意料之外的地方。

不过,你可以通过安装第三方插件,来实现 Drag & Drop 拖拽上传。

安装 Dokuwiki 的 Dropfiles 插件,你就可以开启在编辑 Dokuwiki 的同时,直接拖拽上传文件的体验。

同时,因为你上传时已经在文本编辑的状态,因此,你上传的文件也会自动按照 wiki 所在路径来上传,对于不支持分页管理的 dokuwiki 来说,是一个非常有用的 Feature。

此外,如果你安装了这个插件,我强烈你开启 insertFileLink 这个选项,开启后,你拖拽上传的文件链接将会自动插入到当前文件中,十分方便。