在特定情况下,用 nginx 反代 git 仓库,且避免出现 go get meta tag did not match import path
的报错。
配置如下:
1 | location / { |
后续 go get 时,可能出现 terminal prompts disabled
的报错,使用 GIT_TERMINAL_PROMPT=1 go get
方可化解。
在特定情况下,用 nginx 反代 git 仓库,且避免出现 go get meta tag did not match import path
的报错。
配置如下:
1 | location / { |
后续 go get 时,可能出现 terminal prompts disabled
的报错,使用 GIT_TERMINAL_PROMPT=1 go get
方可化解。
记几个命令行,用来暂停/恢复 spotlight 搜索的索引进程:
As you know, the mds and mds_stores are Spotlight activities.
The reason why your Spotlight is so active could be a number of things; it could be you have an app or multiple apps constantly changing some folder contents.
First let's check whether Spotlight is the cause of the fans running so much. To test this, run the following in your terminal:
1 | sudo mdutil -a -i off # 暂停索引建立 |
this turns off indexing of files, and should result in a clear slow down of the fans if mds
and/or mds_stores
are to blame.
To turn indexing back on, run:
1 | sudo mdutil -a -i on # 恢复索引建立 |
After this you could run the complete re-indexing of your hard drive (be aware this could be an over night job), it will delete your Spotlight data base forcing it to start over.
1 | sudo rm -rf /System/Volumes/Data/.Spotlight-V100/* |
The next and final step would be to add others to your (do not scan), privacy settings.
参考自: https://apple.stackexchange.com/questions/144474/mds-and-mds-stores-constantly-consuming-cpu
mdutil
用法:
1 | $ mdutil --help |
如果需要用 Homebrew 安装已经被 disable 掉的 formula,例如需要安装 v1.12 版本的 golang, 使用 brew install go@1.12
是无法安装的,需要修改对应的 formula 脚本:
1 | > brew edit go@1.12 |
该操作会在默认的编辑器中打开位于 /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula
目录下的 go@1.12.rb
脚本文件。
编辑脚本文件,找到 disable
方法的调用,并注释掉,例如:
1 | class GoAT112 < Formula |
之后,再次使用 brew install go@1.12
,虽然会有 warning 但最终还是可以顺利安装 v1.12 版本的 golang 。
通过 github 仓库搜索 go@1.12.rb
, 在 commits 中找到对应的提交。将 rb 文件保存到本地, 例如: go@1.12.rb
。 然后执行:
1 | > HOMEBREW_NO_INSTALL_FROM_API=1 brew install ./go@1.12.rb |
温故 base64
编码过程。
虽然现在绝大多数编程语言都已经在标准库中实现了 base64 编码和解码,但还是要时不时回顾其原理。
TLDR: 将 8 位
二进制串 分割为 多个 4 个 6 位
二进制串,参考 https://zh.wikipedia.org/wiki/Base64 。
ASCII
码ASCII
码由十进制转为 8 位二进制一组
,若在分隔的时候,位数不够则用 0 填补在末尾base64 索引表
中找到对应的编码。一组
,则用 =
号填补在末尾编码 (encode) 过程如下:
Text |
ASCII |
8 Bit |
Index |
Base64 |
1 | echo -n 'mixx' | base64 # 输出: bWl4eA== |
最近恰巧有机会在一台 Centos 物理机上搭建 Jenkins, 也借此机会实践了从 git 提交自动触发 Jenkins build 的工作流,故在此记录,以作备忘。
docker 镜像在 https://hub.docker.com/r/jenkins/jenkins 。
docker-compose.yml 配置如下:
1 | version: "3" |
需要注意宿主机的 ./jenkins/
目录需要将用户和组更改为 1000:1000
:
1 | > sudo chown -R 1000:1000 ./jenkins |
启动之后,进入 web 界面,需要输入 admin 的密码,这个密码可以在容器的日志中获得:
1 | > docker-compose logs jenkins # 查看容器日志 |
1 | jenkins_1 | ************************************************************* |
接下来建议直接选择安装社区 推荐
的插件,然后进行简单配置后,就可以正常登陆到 Jenkins 控制台了, 然后进行slave节点配置,顺便配置下域名反代。
之前的博客是需要在我本地电脑上手动执行命令来部署的:
1 | > make deploy |
如今已经成功将这个部署的过程迁移到了 Github Actions。 整个 workflow 包括 npm 依赖的安装和缓存,将 Markdown 生成静态 html 文件,和部署到服务器。
配置如下:
1 | name: deploy |
近日有机会在 Linux 环境中从零开始使用 docker 部署 JIRA, 在此记录下部署过程中遇到的问题及解决.
在 docker 的镜像仓库中搜索 'jira', 会看到好几个相关的镜像: atlassian/jira-software, atlassian/jira-core 等. 这里应当选择 atlassian/jira-software
.
根据 dockerhub 中的描述, 编排出下面的 docker-compose.yml
配置:
1 | version: '3' |
启动之后, 进入web界面, 选择手动配置, 然后开始配置 JIRA.
在配置数据库时, 此时还只能选在内置数据库, 不能选择 MySQL 或者 PostgreSQL, 因为 atlassian/jira-software 镜像中并没有包含连接 MySQL 或 PostgreSQL 的驱动 jar 包. 接下来就需要去下载对应的 jar 包, 并将其放入容器中特定的目录下, 来完成 MySQL 或 PostgreSQL 的配置.
回首这些年工作和业余时间的 git 使用,发现在提交内容时,写的 commit message 其实并没有做到统一和规范化。 于是抽空去 Google 了一番,发现有不少的开源项目在使用一种语义化的提交。 这种语义化的提交能够做到足够简短且开门见山。 看过之后确实也是受益匪浅,故在此记录。
https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716 。 这是一个拥有 2k+ star 的 gist,里面陈述着语义化提交的基本范式。 下面是我个人对这套规范的理解。
来看看这个提交信息的小小改动,能对你的程序带来多少益处吧。
格式: <type>(<scope>): <subject>
,其中 <scope>
是非必要的。
1 | git commit -m "feat: add hat wobble" |
Type | 语义 |
---|---|
feat | 针对用户侧的新特性。是对外的而非对内的 |
fix | 针对用户侧的 bug 修复。是对外的而非对内的 |
docs | 仅文档内容的变更 |
style | 仅格式化相关,比如行尾的分号(;),空格等。不影响线上使用 |
refactor | 重构功能代码,如重命名变量,抽象方法等 |
test | 添加或重构单元测试。不影响线上使用 |
chore | 更新 CI/CD 流程、任务或脚本。不影响线上使用 |
原文地址 : https://blog.golang.org/fuzz-beta
作者 : Katie Hockman and Jay Conrod
时间 : 3 June 2021
我们兴奋地宣布: 原生 fuzzing
已经可供beta测试了,就在 dev.fuzz 中的 development 分支里!
Fuzzing
是自动化测试的一种,通过持续操控程序的输入来找出问题,比如说 panic 或 bug。 这些半随机的变换数据能够覆盖到已有单元测试所遗漏的地方,并且揭露出一些不易察觉的边界 bug。 正因为 fuzzing
可以抵达这些边界情况,fuzz 测试对于查找安全漏洞和弱点是尤为重要的。
详见 golang.org/s/draft-fuzzing-design 。
你可通过运行下面命令来上手
1 | $ go get golang.org/dl/gotip |
该操作从 dev.fuzz 的 development 分支构建 Go toolchain,将来一旦代码合并到了 master 分支就不用这样了。 运行之后,gotip
可以看做 go 命令的绿色替代 (drop-in replacement)。 你现在可以这样运行命令
1 | $ gotip test -fuzz=FuzzFoo |
因为在 dev.fuzz 分支中会不断地开发和bug修复,所以你应当有规律地执行 gotip download dev.fuzz
来应用最新的代码。
为兼容已发行的 Go 版本,在提交含有 fuzz target
的源文件到仓库时,要使用 gofuzzbeta
build tag。 dev.fuzz 分支中,这个 tag 在 build-time 是默认开启的。 如果你对 tags 使用有疑问,参考 the go command documentation about build tags。
1 | // +build gofuzzbeta |
原文地址: https://blog.golang.org/context-and-structs
作者: Jean de Klerk, Matt T. Proud
时间: 24 February 2021
在许多尤其是现代的 Go API 中, function 或 method 的第一个参数常常是 context.Context. Context 为传输提供了 deadline, 为调用方提供了 cancellation, 也为其他进程间跨 API 请求提供了传值手段. 它常常被间接或直接使用了远程服务的库所使用, 例如数据库, API 等.
Context 文档 所述:
Context 不应存储在 struct 内部, 而应传给需要它的 function.
这篇文章就是针对上述建议的详述, 通过举例说明的方式来阐述为什么要传递 Context 而不是存储在另一个 type 里. 本文也强调了一种边缘情况: 将 Context 存储在 struct 中也是合理的. 以及如何安全实现.