Posts

背景 在使用 Docker 搭建 Gitlab/Gitee 会导致无法与主机端共用 22 端口，这导致 ssh 连接的时候会使用形如 ssh://git@git.xxxx.cn:4022/zs/zsblog.git 的 ssh 链接，而不是像官方 Gitlab 那种非常干净的 git@git.xxxx.cn/zs/zsblog.git 链接。这对于我这种强迫症而言非常的难受啊，但因为主机的 22 端口已经被占用了，无法共用，所以需要考虑两者共享端口的问题。 虽说是两者共用，但其实还是使用类似于端口转发的特点，简单说就是在主机设置 git 用户，然后通过一个脚本将 git 用户的所有 ssh 流量转发到 Gitlab 容器中，从而完成对应的事情。 关于 Gitee 的设置，Gitee 官方的 Docker 部署教程1已经说的很清楚了，按照该步骤执行完全没问题。 而关于 Gitlab 貌似没有比较详尽的教程，搜索后发现了一个 Issue2 以及一篇博文3，后者讲的比较清楚，但是经过实践后发现存在一定问题，因此决定将可行的方案记录下来。 具体步骤 一、初始设置 在开始之前，docker-compose.yml 中设置比较关键的几个配置如下： gitlab-web: image: 'gitlab/gitlab-ce:latest' container_name: 'gitlab' restart: always environment: GITLAB_OMNIBUS_CONFIG: | gitlab_rails['gitlab_shell_ssh_port'] = 4022 ports: - '3090:80' - '4022:22' - '6060:6060' volumes: - '/srv/gitlab/config:/etc/gitlab' - '/srv/gitlab/logs:/var/log/gitlab' - '/srv/gitlab/data:/var/opt/gitlab' - .... #一些其他的配置 如上设置基本可以确保 Gitlab 形如 ssh://git@git.xxxx.cn:4022/zs/zsblog.git 的链接可以使用。 ...

前言 春节期间，走亲访友是必不可少的。交谈的多了，免不得一些问题的讨论。 读了很多书，经历了很多事，似乎想法也有一些”离经叛道“，记一下自己目前的一些想法，不知道多年后的自己看这篇文章会是什么想法，还会一如既往的坚持吗。 讨论的话题 打点关系 无论是父母，还是各方亲戚，大家好像都喜欢打点关系，以此来获得一些好处。 最常见的是求人办事，很多时候是我们常说的”走后门“，想让孩子上个好点的小学，避免不了又送礼又吃饭。 事件上升的恶劣一些，定然就是贪污受贿，这肯定是错的，大家都知道，但是度在哪里呢。 和我儿时的哥哥探讨中，他认为，这种送礼打点关系是必要的，送点小礼没啥问题。而我总觉得，这就是0、1、无穷的区别，有一就有二，有二就有无穷。 从出生到现在，试问自己从没遇到过必须送礼才能办成的事，或许以后会遇到，但我想、我应该宁愿放弃这个机会也不会去送礼打点。 大家都对我说：“你现在是这个想法，是没有经历过社会的毒打，你踏入社会就也会这样了。”，我无言。 或许吧，或许以后也会变成善于打点关系、整天辗转于酒局的人。 至少我现在，还是个滴酒不沾、不屑于打点的鸟人。 酒文化 我是个滴酒不沾的人 有两点比较重要的原因 一个是因为酒真的很难喝，好喝也就罢了，难喝为什么要喝呢？ 二是因为我真的很讨厌饭桌上推杯换盏，你推我我推你，大家都喝得烂醉如泥。村里有很多喝酒出事去世的例子，小时候看见一个哥哥的朋友，喝醉后在大街上和别人干架，然后在欢喜的日子里一起进医院···何必呢？ 推杯换盏还导致饭菜里会混入多多少少的酒，真的不好吃。 大家为什么都不能别这么执拗，这里用执拗可能不合适，不过没想到什么好的词语。人家明明都说了不喝、不吃，为什么还总要一遍遍的推脱？最后立场不坚定的，只能不情愿地吃了。立场坚定的，又闹得双方不愉快似的。 还有很多明明想喝、想吃，却又怕尴尬嘴上说着不喝不吃，一样可恶。 硬唠 平时在家总喜欢窝在自己的屋子里，倒腾自己的事情。 亲戚来了，似乎不出去跟他们聊天就是个错误。总是要数落你一下，在饭桌上调侃你一下，跟家长阴阳怪气一下你。 不想说的是，真的感觉没有什么共同话题，聊不到一起去，实在是没什么话说，只能在那里低头玩手机，哦对了，手机也不得玩，玩多了也会被说。只能在那里干坐着东看西看，听大家侃大山，却因为离家过久大多事都没听说过，时间白白的浪费。 人际关系真的蛮烦的。 关于入党 最近舅家的哥哥萌生了入党的想法，说：”就算无论花多少钱，也得入党。“ 我问，那你入党又是为了做什么呢？ 他说，入党好啊，入党好啊，入党可以在村委里谋个一官半职，可以轻松一些，赚钱也多。 我说你不应该为了自己的私利来入党，他说，人不为己天诛地灭，没有人不顾自己的私利。 实话的讲，我哥哥是个不错的人，乐于与村里人交善，村民家里出什么事他也喜欢帮忙。但是这个入党的观念真的让我不理解，入党是应该认为认同，而不是因为利益驱使。 大家入党好似都是为了后续能谋个公务员的出路，如果能贯彻为人民服务的宗旨还好，如果一心为了钱，很容易会变成蛀虫、老虎，那这样的话，不如踏踏实实另谋出路。 后记 春节期间思考了很多，感觉与周围的很多亲戚们都格格不入。 文章算是想到什么写什么，可能看起来杂乱无章，见谅。文章也只是我自己的一些看法，不代表普遍性，也无言对错，大家看看就好。 还好的是，我的亲戚们大多不会问我，考的咋样，有对象了没…… 之前与一个舅家的哥哥很要好（与上文不是同一个），因为之前感觉我们两人观念很类似，亲戚们也都觉得我们两个像。 这个春节与他进一步交流了一些，似乎观念不尽相同了。 现在他步入社会，参加了工作，开始应付酒局，也会打点关系了。也开始教导我应该善于打点。 我以后也会这样吗？

前言 最近看了一些 js 有关的知识，其中令我这种初学者感到很头疼的一个问题就是异步问题。 今天就我碰到的一个小问题详解一个关于异步的小技巧。 背景 我在程序中需要鉴权，来判断一个用户是普通用户还是管理员，针对不同的用户渲染不同的页面。 每个用户具有唯一的 ID，因此我只需要将管理员的 ID 放到数据库，然后加载程序的时候一一比对即可。 但是我的主程序初始化与页面的初始化是异步的，管理员的判断逻辑我放在了主程序初始化中，这也就意味着很可能我页面在加载时，主程序还没有判断完用户的身份。 每个人默认不是管理员，因此这就会导致一个问题——管理员可能也会显示成普通用户的页面，因为渲染页面的时候程序还不知道这个用户是管理员。 方案 这个方案其实是我从官方的代码上学到的，其实就结合代码给大家讲一下。 官方这里是在获取用户的 userInfo 时用到的。 主程序初始化部分代码： 这里主程序的逻辑就是在 getSetting 调用成功后，判断是否已经获得过 userInfo ，如果已经获得过，则可以直接调用 getUserInfo 函数获取值，赋值成一个主程序的全局变量，所有页面都可以用。 接下来就是一个比较奇怪的点了 可以看到官方的注释为 由于 getUserInfo 是网络请求，可能会在 Page.onLoad 之后才返回 所以此处加入 callback 以防止这种情况 这里判断了主程序内是否含有 userInfoReadyCallback 这个函数，如果有的话就执行。 qq.getSetting({ success: res => { if (res.authSetting['scope.userInfo']) { // 已经授权，可以直接调用 getUserInfo 获取头像昵称，不会弹框 qq.getUserInfo({ success: res => { // 可以将 res 发送给后台解码出 unionId this.globalData.userInfo = res.userInfo // 由于 getUserInfo 是网络请求，可能会在 Page.onLoad 之后才返回 // 所以此处加入 callback 以防止这种情况 if (this.userInfoReadyCallback) { this.userInfoReadyCallback(res) } } }) } } }) 页面初始化部分代码： ...

前言 更换博客系统的想法已经萌生很久了，一个是感觉 Handsome 这个主题有点看腻了，但是在 Typecho 中好似已经没有更好的博客主题可选择了。 有一个看起来貌似很不错，主题名叫 maupassant。效果如下图所示，顺附链接 pagecho/maupassant(github.com) 不过一直没有下定决心更换，后来也尝试过使用 WordPress，又觉得 WordPress 体量有点太大了。 每天逛 Github 的时候看到了很多很不错的静态博客主题，那天看到一个学长分析学校校园网的博客，第一眼就感觉很不错，找寻了一下发现博客基于 Hugo，主题是 hugo-PaperMod。 于是顺着寻找了一下，发现 Hugo 中很多博客主题非常的不错。此外，Hugo 相比于 Hexo 也有很多优点：博客构建速度快，基于模板的概念组织内容，环境配置容易，在 Ubuntu 下一行命令即可，而 Hexo 依赖于 Node.js，体量稍微有点大。 于是决定把博客迁移到 Hugo，并且采用主题 Coder 。 过程 Typecho 文章导出 这里采用了 lizheming 大大的迁移插件：lizheming/typecho-export-hugo 具体导出为 zip 的时候可能会提示损坏，这样的话可以直接去服务器 \tmp\Export2Hugo 下面打包。 安装 hugo 过程基于 Windows 平台，很简单，在 这里 下载 hugo 最新的 release 版本，找到对应自己系统的即可。下载后解压到某个目录下，设置一下环境变量即可。这里牵扯到 hugo 和 hugo_extended 两个版本的区别，以下是某个 issue 中的解释： I agree. The only functional difference is SASS/SCSS The technical build time difference is that it requires a C++ build chain for the target platform to build, the reason why we currently only build the extended for 3 platforms (Windows, Linux, MacOS) Binaries are slightly less portable as you need a compatible Libc version on your computer (for Windows we build a fully static version as Libc is rather uncommon unless you have Visual Studio or something installed). via: Please document the difference between the “extended” and non-“extended” versions ...

前言 近期著名 Markdown 编辑器 Typora 宣布收费了，起初感觉很难受，后来感慨之余也觉得算是合理，毕竟 Typora 用起来感觉是真的很良心，也在考虑是否买一份支持一下。 已于2021/12/10购入，还是选择回归了 Typora 了哈哈哈 虽说左右分屏的设计可能更符合 Markdown 的初衷，但是像 Typora 这种所见即所得（WYSIWYG） 的书写体验确实是感觉习惯了就回不去了。 因此近期也搜集了 Markdown 编辑器作为 Typora 的替代品，在这里给大家分享一下。 特别声明，下面的分享多是我日常体验中的一些感受，可能不够客观，比较片面，大家可以自己使用体验一下！ 一、Obsidian 界面预览 特点 具有文档的双向链接 支持行级和块级公式 官网可以购买 sync 套餐保持各个客户端同步 可以购买 publish 服务将 markdown 发布为排版美观的界面 有丰富的插件，例如日历、待办清单、Git同步等等。 有Linux，Windows，iPad等多平台支持。 使用体验 Obsidian 中文为黑曜石。我觉得它的图标很好看。 在我使用的一段时间内，他给我的感觉是，功能十分丰富的一个 Markdown 文件管理工具。如果你购买了他的同步服务，那你可以很轻松的在各平台同步你的 Markdown 文件夹，并且基于他强大的插件，可以很完成很多 Markdown 文件份外的事，例如待办清单、日历等等。 他虽没有所见即所得的模式，但是依靠其一款第三方插件，可以达成类似的效果，不过还是用起来不如 Typora 这种顺手。同时，它的各端同步如果不开启官方的服务，用起来还是挺麻烦的，经过我的一阵倒腾，我总结了如下几个方案： 使用第三方Git管理插件，可以定时推送文件夹中的内容到仓库，这样可以完成 linux 与 Windwos 平台的同步，只需要在某一方推送某一方拉取即可。而 Windows 平台与 iPad 平台的同步，可以借助 Apple 的 iCloud，Windows上有对应的客户端，这也是 Obsidian 官方支持的。不过在我使用的过程中我发现，这样异常的麻烦，使用 Git 来管理很可能会产生冲突，导致需要手动处理冲突，久而久之就会觉得很烦。 使用自建云盘如 NextCloud + Obsidian，或者 Seafile + Obsidian。 这个是我觉得目前非常可行的一个方案，最近我也有在尝试 NextCloud，它的多端同步做的非常不错，依靠此可以在各个平台同步文件夹，加上 Obsidian 强悍的能力，是不错的组合！ ...