其实不需要装任何插件,IDE 自带的 Markdown 插件即可支持该操作:

  1. 使用任意截图软件截图到剪贴板;
  2. Ctrl + V 复制到编辑器中;
  3. IDE 会自动生成图片文件 img.png(如果已存在,则会加自增后缀),以及相应的 Markdown 标签 ![img.png](img.png)

但是,默认的插件不能配置保存路径(只能是 markdown 文件所在的路径),也不能配置命名规则,因此找了一个插件来增强这个功能。

阅读全文 »

关于 React Hooks 与 Vue Composite API:

二者为了共同的目的,在接近的时间点,以非常相似但是又带有本质区别的方式,推出了各自对于未来前端代码结构发展的新思路。本文在对二者做一些简单介绍的同时,也会重点关注二者之间的统一与区别。

阅读全文 »

在不想全局 vpn 的情况下,可以用 host 加速。

该方法主要利用 github.com/ineo6/hosts 的 hosts 文件,国内镜像 gitee.com/ineo6/hosts

方法一:手动

手动复制 hosts 的内容,并粘贴至对应操作系统的 hosts 文件内。

方法二:自动

  1. 下载开源的 host 切换软件 SwitchHosts
  2. 新建一条规则:
    1. 方案名:随便
    2. 类型:远程
    3. URL 地址:https://gitee.com/ineo6/hosts/raw/master/hosts
    4. 自动更新:随便,或 1 小时
  3. 保存,保存后可以先手动刷新一次
  4. 启用即可

Assertions include boundaries, which indicate the beginnings and endings of lines and words, and other patterns indicating in some way that a match is possible (including look-ahead, look-behind, and conditional expressions).

断言是正则表达式组成的一部分,包含两种断言。本文记录了一些常用断言。

阅读全文 »

今年疫情原因,本来不是很想回家过年的,想着工作累了,在珠海(中山)做几天废人也不错。但是现在回想起来,虽然家里比较小也比较无聊,逢年过节还是应该回家看看。

阅读全文 »

有数据格式如下:

{
"id": "745",
"knownName": {
"en": "A. Michael Spence",
"se": "A. Michael Spence"
},
"familyName": {
// 结构同上,下同
// ..
},
"orgName": {
// orgName 当获奖者为组织时出现
// ..
},
"gender": "male",
"nobelPrizes": [
{
"awardYear": "2001",
// ...
"affiliations": [
{
"name": {
"en": "Stanford University",
// ...
},
"city": {
// ...
},
"country": {
// ...
},
// ...
}
]
}
]
}

想要实现:

  1. 查找名为 CERNaffiliation 的所在国家
  2. 查找获奖次数大于等于 5 次的 familyName
  3. 查找 University of California 的不同所在位置总数
  4. 查找至少一个诺贝尔奖授予组织而非个人的年份总数
阅读全文 »

上一篇博文 Integrate Renovate with GitLab 中介绍了为私有代码仓库与私有源提供依赖自动检测更新并发起 Merge Request 的方式。Renovate 可以自动通过 Release Notes 获取到版本之间的更新日志,并在 MR 中展示,这为执行合并的评审人提供了极大的便利。

接下来需要解决另一个问题:如何为分散在各处的私有依赖自动生成更新日志?

阅读全文 »

企业项目群中往往会有部分代码逻辑需要公用,将其抽离作为公共包发布到私有源的做法是比较优雅的解决方式。但是这么做的话后期需要面临一个问题:当一个公共依赖包的使用者数量逐渐庞大的时候,如何保证当此包发布新版本时,所有使用者都能尽可能快地得到更新?

传统的解决方案:

  1. 手工对所有项目逐个升级。这种办法相当繁琐,且容易产生遗漏,当项目数量足够庞大的时候,发布一次将会是相当痛苦的体验;
  2. 在依赖安装时指定版本为 latest。这种办法虽然能保证每次安装时都能得到最新版本,但是却有诸多弊端,如:
    1. 无法保证依赖的安全性,有可能一次更新不慎造成大面积的瘫痪;
    2. 对「依赖锁」不友好,如 yarn.lock 等。

因此,如何使这个过程变得优雅,是一个亟待解决的问题。

阅读全文 »

本文是一些 GitHub Actions 常用发布动作的总结。

强烈建议将所有 Publish actions 分开执行,不要集中到一个 Workflow 内。原因是如果其中一个动作因为某些原因失败了,GitHub 目前只能重启整个 Workflow,而如果 Workflow 内某个 Job 已经成功了,那么该 Job 下一次执行必然是失败(因为此类任务一般不能对同一个版本号执行两次,发布成功一次以后第二次尝试将会被拒绝发布),因此这一个提交的 Workflow 将永远不可能成功。

需要注意的是,以下所提到的 secrets.GITHUB_TOKEN 均是 GitHub Action 内置的 Access Token,无需自行创建。而其它 secrets 则需要在 项目主页 -> Settings -> Secrets 处创建。

阅读全文 »
0%