山维空间

标签： Github

  • SSR，云平台，ChatGPT——我的 2023 技术关键词

    SSR，云平台，ChatGPT——我的 2023 技术关键词

    前言

    2023 年，因为换工作，启动新项目等原因，我对我的技术栈进行了比较大的更新，主要集中在这三个方向：

    1. SSR（Server Side Rendering，服务器端渲染）。之前我开发的项目基本上都是 SPA（Single Page Application），比如 Vue，但之后我会越来越多开始用 Nuxt。由于基础设施的发展，以后 SSR 会更方便更好用。
    2. 云平台。以前我大概买了 3、4 台云服务器用来做各种尝试，在上面各种折腾。去年使用 Vercel、Supabase、CloudFlare 平台之后，我已经不打算再在服务器上浪费时间了，云平台实在太好用了。未来我会努力把所有服务都迁移到云平台上，新增产品都直接云原生。
    3. ChatGPT。相信不只是我，很多人都会把 ChatGPT 作为去年技术的首选关键词。如今我不仅在上面完成产品开发，日常也会使用它替代大部分的搜索；甚至我家孩子写作业也会使用它来帮忙。我认为，未来 ChatGPT 就像是搜索引擎一样，决定了一个人的起点和成长速度。

    接下来逐个分享。

    服务器端渲染，SSR

    起初我不是很看重 SSR，我总觉得，我当年也写过 PHP，有什么“服务器端渲染”我没见过？实际用过之后，我承认：真香……

    首先，使用 SSR 可以提升用户体验，且有利于 SEO，这点相信大家都知道。如果对其原理不太清楚的话，欢迎观看我的视频：从浏览器渲染机制理解 Web 性能——“在浏览器地址栏输入 URL，按下回车后会发生什么？”

    其次，如今的 SSR 与当年 PHP 模版套页面的实现有很大区别：

    1. 语言同构化：开发难度大大降低，没有心智负担。
    2. 数据传递与状态管理：虽然数据不能完全通用，但是框架尽量会帮我们处理好，让我们在服务器端和客户端都能自由使用。
    3. 渲染由边缘计算负责：这一点有点依赖云平台，不过考虑到浏览器的渲染机制，SSR 并不会拖慢渲染速度，用户体验只会更好。
    4. 页面切换不需要重新加载。对于旧的编程语言来说，因为前后端环境割裂，所以页面切换的时候都是重新加载完整页面；但是新框架下，则只需要加载数据即可，此处跟 SPA 的体验无二。

    第三，如今的 SSR 框架都很好的整合了服务器，包括中间件等功能，还有各种官方第三方模块支持，能大大降低我们开发服务器软件的成本。所以已经是我启动新项目的不二之选。

    云平台

    以前我长期维护好几台服务器，一方面可以部署自己做的产品 demo，另一方面也可以部署一些开源项目方便日常使用。因为各种云都有面向新用户的优惠活动，所以成本不高，我觉得值得一搞。

    自己的服务器当然比较比较自由，坏处就是免不了产生运维成本，即使使用 docker 也一样。部署新代码至少要去跑一遍拉取脚本，对吧？我的一位老板朋友甚至请我帮忙写了一套服务器脚本，用来做 CI/CD。

    初期这么搞没问题，但后来就越来越觉得功能不够，性价比也太低，开始寻求替代方案。之前我参加 Hackathon 的时候了解到 Vercel 云平台。它与 GitHub Pages 不同，支持 SSR、支持云函数，配合一些云数据库，比如 Upstash，可以快速搭建起来一套可用的服务。去年年初，我的那位老板朋友想做一套打分系统，放在他的静态网站里，于是，我就尝试用 Nuxt.js + Upstash 开发了一套，并且部署在 Vercel 上，效果非常好，免运维，多环境，推到 GitHub 自动部署，实在太好用。

    我把这个过程制作成了系列课程：Nuxt3+Vercel+Serverless 数据库全栈开发。大家感兴趣不妨看一看。

    后面一发不可收拾，过去一年我不再采购新的单体服务器，旧的服务器用完也不再续费。新产品都部署在 Vercel 等云平台上面，帮我节省了大量的时间。

    Vercel 去年年中的时候开通了存储功能，实际上就是打包了几家云数据库服务来卖，我也很快获准开通。从此，云平台使用就更加顺利了。临近年底，我尝试 CloudFlare Pages，效果也非常好。他们家的优势是自带统计分析功能，远比 Vercel 大方，一站式解决更省心。

    云数据库方面，我使用 Upstash 的 Redis，KV 数据库足以满足大部分产品需求。数据库用 Supabase 和 TiDB 比较多。前者支持 PG Vector，方便我们进行 LLM Embedding & Search；后者则提供 5GB 免费额度，比较好用。云存储有 CF 的 R2，空间和流量也相当充足。如果不是 PHP 太老没人支持，我都想把博客这台机器退掉了。

    ChatGPT，以及其它

    ChatGPT 更是值得大书特书的一个技术关键词。不过考虑到大家去年一整年应该已经被类似的内容淹没了，所以我这里就少写一些，只说说我的情况。

    我目前订阅了 ChatGPT+，方法是借用国外亲戚的手机号注册，并且用他的手机号注册 PayPal，通过 Google Play 订阅。订阅的原因是 ChatGPT 4 + DALL-E 都可以随便用，比 API 便宜得多。

    在编程领域，GPT-4 比 GPT-3.5 好太多了，知识库更新到去年 4 月份之后，除了 next.js 14 的内容外，我日常的编程问题大多可以用 GPT-4 解决，比如：

    • 写正则
    • 写 SQL
    • 查函数、查第三方库
    • 纠正函数错误

    帮我节省了大量的 Google 时间，单凭这点，每月 $19.99 的订阅费用就很值得。

    除此之外，我还在继续使用 GitHub Copilot。Copilot 也很好用，除了生成工具函数、编写测试外，我发现翻译语言和框架方面也有很大的作用。去年我就完全靠它开发了一个 flutter 应用，方法就是把 TS+Vue 写好的代码丢给它让它翻译。

    所以，无论是学习新东西，保障日常开发，还是扩展新领域，AI 对我都帮助巨大。

    总结

    总而言之，如果再有同学问，前端想学后端，应用学什么语言框架以及是否需要搭自己的服务器？我都会建议他们：不要学 Express、Koa；习惯用 Vue 就学 Nuxt，习惯用 React 就学 Next.js；不需要搭建服务器，就用云存储就能解决绝大多数问题。

    我还建议大家，尽快想办法开通 ChatGPT，再不济国产大模型也要用起来，未来是 AI 的时代，学会用 AI，效率会大幅度提升。半年的初入门新人，善用 AI 可以赶上 3 年的老程序员；而老程序员学会用 AI 之后，可以快速把自己的能力扩展到其它领域。

    以上，就是我去年关键的技术栈总结，希望对大家有所帮助。如果大家有什么意见建议，想说的想聊的，欢迎留言。

  • 【视频】Vuepress 搭建个人文档网站 GitHub Actions/GitHub Pages 免费资源用到饱

    【视频】Vuepress 搭建个人文档网站 GitHub Actions/GitHub Pages 免费资源用到饱

    这个视频其实我很早就录了，当时都还没阳。录制的过程中出现了一个问题，折腾很久才解决。所以中间必须补录一段，剪接拼贴，所以一直拖到现在。

    我在安装依赖的时候，按照习惯，使用 pnpm i vuepress@^2.0.0-beta.53，希望安装当时最新的 2.0.0-beta.53 版本，并且声明对后续版本的支持，只要大版本保持一致，可以接受小版本升级。

    但是实际安装的时候，不知道是什么原因，pnpm 给我装了一堆不合适的插件。（我怀疑跟 beta 有关），导致启动开发环境后白屏，报告一堆莫名其妙的错误。最后我把环境清空，从头开始配置，仔细看各种输出才猜出来。

    期间浪费了 40 分钟，我觉得直接放出来纯属浪费大家的时间，所以一直没有上传。前几天终于下定决心补录，并且处理了字幕，才最终上传。

    这则视频里介绍了：

    1. 使用 Vuepress 生成静态文档站
    2. 使用 GitHub Actions 执行特定的工作流程，在 master 更新后执行 pnpm run build
    3. 然后把生成的 dist 目录推送到新的分支，避免 /docs 污染代码仓库
    4. 利用域名 CNAME 突破科学上网的封锁，利用免费资源拥有自己的网站

    希望这段视频对大家有用。如果你有静态网站构建需求，或者想使用免费线上资源简历自己的网站，都可以学习这个视频。如果你有其它问题、意见、或建议，也欢迎评论留言。请看到的同学帮忙一键三连、完播、转发，谢谢。

  • GitHub 开放自定义 Profile 功能

    GitHub 开放自定义 Profile 功能

    GitHub 有一个个人简介（Profile）页面，比如我，我的用户名是 meathill，我的个人简介就是 https://github.com/meathill。这个页面和 GitHub Pages 有所不同，后者是完全自定义的，想放啥都可以；Profile 页面只体现我们在 GitHub 上的状态。

    不过很多同学并不满足 GitHub Pages，还想定义这个页面；现在 GitHub 闲钱也比较多，可以改进这些痒点；于是乎，自定义 profile 就诞生了。

    使用方法：

    1. 创建一个与用户名相同的仓库，比如我，就是 meathill 仓库
    2. 创建时，你就能看到小提示了：（因为我已经创建过仓库，所以有错误提示，正常没有）
    3. 如提示所写，你只需要编辑这个仓库里的 README 文件，就会自动更新页面上的内容
    4. 更新后的效果如下：

    感觉还不错，近期找工作的同学赶紧用起来吧，是个不错的加分项。

  • 使用 GitHub Registry 托管私有 NPM 源

    使用 GitHub Registry 托管私有 NPM 源

    我厂有不少私有仓库，都是日常开发中提炼出来的，在几个项目中共享，比如 UI、Vuex、网络请求（axios 封装）等。以前的主要形式是使用 npm 安装 GitHub 仓库，即

    npm i openresty/some-repo

    这样 npm 会自动去 GitHub 查找对应的仓库，然后 clone 下来完成安装。项目中的 .npmignore 文件也会正常生效，安装后的目录会忽略不需要的文件。这样做的好处就是简单，只要仓库存在，安装依赖的系统有足够的权限（比如 ssh key），就能顺利安装。在过去的三年时间里，我们一直都这样做。

    但是这样会有一些问题：

    1. package-lock.json 里记录的是 commit hash，只看这个值无法判断版本，npm 也没法使用版本号解决依赖冲突的问题。换言之，比如 A 仓库需要 C 仓库的 1 版本，B 仓库需要 C 仓库的 2 版本，那么就只能同时安装两个版本，因为 npm 无法判断两个版本是否兼容。
    2. 安装的时候要走 git clone，下载量很大，速度很慢，经常被同事吐槽。也会影响 CI 的效率。
    3. git 仓库里要提交编译后的代码，一方面浪费时间和空间，另一方面大量编译后的代码也影响 code review

    所以，考虑之后决定改用 GitHub Registry。GitHub Registry 是 GitHub 提供的私有源，感兴趣的同学可以访问这个页面了解详情。这个服务需要收费，不过我厂本来就是 Team 用户，额度比较富裕，所以并没有阻力。

    经过一段时间的摸索，终于搞成了，下面简单说一下做法。

    对依赖项目

    修改 package.json，把项目名称改成 @openresty/some-repo，即“@公司名/仓库名”。然后增加 publishConfig 字段，设置源为 GitHub registry：

    {
  "publishConfig": {
    "registry": "https://npm.pkg.github.com/"
  },
}

    接下来，正常使用 npm publish 发布依赖即可。不过在发布之前，最好使用 .npmignore 忽略掉开发时的源文件和配置文件，一方面这些文件对于其它项目的开发没有价值，另一方面无论是存储还是下载消耗流量，都要收费，能省则省嘛。

    对业务项目

    因为这些依赖仓库都是私有项目，所以我们先得解决身份认证的问题。GitHub 提供了 Personal access tokens 方式，生成 token 后，添加到 ~/.npmrc 文件即可：

    //npm.pkg.github.com/:_authToken=<TOKEN>

    接下来，在业务项目中，添加 .npmrc 文件，指名依赖源：

    registry=https://registry.npmjs.org/
@openresty:registry=https://npm.pkg.github.com

    这段配置分两部分：其它域的依赖，直接从 npm 的源下载；@openresty 域下的依赖，从 GitHub Registry 下载。

    最后，正常使用 npm i @openresty/some-repo 安装依赖即可。

    最后的最后附上修改前后的效果对比，可以看出，改造后效果明显：

    国内修改前real 0m39.543s
    user 0m17.768s
    sys 0m3.944s    		阿里云
    修改后real 0m16.450s
    user 0m15.204s
    sys 0m3.380s    		阿里云
    国外修改前real 0m49.350s
    user 0m22.352s
    sys 0m4.144s    		阿里云
    修改后real 0m30.807s
    user 0m15.780s
    sys 0m3.936s    		阿里云
  • 解决新机不能 npm install 私有仓库的问题

    解决新机不能 npm install 私有仓库的问题

    前些天换了电脑，从 iMac 27 Retina 2014 late 升级到 iMac 27 2019。关于前因后果，我写在张大妈，感兴趣的同学可以看下：《肉山的电子产品 篇九：机不如新，人不如故——iMac 27 换新记》。

    换机器要搭环境。有两个选择：

    1. 整盘复制，利用 Time Machine 之类的工具
    2. 自己慢慢搭

    考虑到老电脑已经工作了 5 年，经历了小十个系统版本，各种软件删装无数，里面的垃圾很多；再加上我的环境并不复杂，所以我决定自己慢慢搭。

    然后遇到一个问题：npm install 会卡住，没有明显的提示信息，只有一段比较可疑：

    The authenticity of host 'GitHub.com (1.1.1.1)' can't be established.
ECDSA key fingerprint is SHA256:abcdefg.
Are you sure you want to continue connecting (yes/no)?

    因为项目中用到一些私有仓库的依赖，所以我怀疑是它们的问题。于是我把私有仓库从 package.json 里移除，再安装，成功。看来猜的没错。

    然后我手动 git clone 一个项目到本地，clone 的过程中，会看到上面的提示，手动输入 yes，记录目标机器的指纹，视它安全可靠。clone 完成。再把私有仓库依赖加回 package.json，安装，成功。问题解决。

    原因：使用 npm 安装 GitHub 仓库作为依赖，实际上等同于使用 git clone 将目标仓库 clone 到 node_modules 里。而 git 协议依托于 ssh 协议。在新机器上安装时，因为没有访问过目标机器，本地不信任目标机器，而 npm 又没有对这个异常做处理，所以就会卡住，不上不下。

  • 面试经：GitHub

    面试经：GitHub

    GitHub 越来越有名，很多同学都把它作为一个关键字加入自己的简历当中。不过我在面试中，问到如何使用 GitHub，对方通常会答复：上去看源码呀！这个答案完全无法让我满意，具体的原因，一方面可以参考我之前的一篇文章《谈学习：读源码》，源码不是小说，直接看源码收获太小。另一方面，看源码是一个太直接的逻辑推断——上面有源码所以我去看源码——我不认为这是一个细心耕耘慢慢养成的习惯。

    接下来我想简单谈一下，我认为应该如何使用 GitHub。

    Issues 和 PR

    一个 GitHub 仓库可不仅仅是一份源代码那么简单。GitHub 是开发者社交平台，所以每个项目在代码之外，都会有两个非常重要的模块：

    1. Issues 问题，包括 Bug，和其它使用者希望有的功能
    2. Pull Requests（PR） 其他的开发者在这个项目上做出了一些改进，或者修复了一些 Bug，希望能够合并到 master 当中，就会发起 PR

    完美的代码是不存在的，越是用的人多的库，存在的问题，或者说被发现的问题可能就越多。阅读其他人提的问题，很多时候可以获得不小的收获，比如，大家开发时都遇到了什么问题？有没有与我类似的情况？他们是怎么解决的？大家最想要的新功能是什么？有哪些值得关注？我能做什么？等等。

    以及，可能是更重要的，我们应该怎么样通过 Issues 与仓库的原作者进行交流。

    毕竟我们每个人的时间都是有限的，对于大部分开源的类库来说，了解怎么用、有哪些问题、怎么避免踩坑，通常会比你知道它某个函数是怎么写的更有价值。

    看文档

    好的开源类库通常还会有一个做得非常到位的地方，便是它们的文档，做得通常详尽有价值。通过阅读文档，可以很快的了解这个仓库是干嘛用的，应该怎么用，能解决哪些问题，以及接下来，它的发展方向是怎样的。

    据我观察，文档通常分布在三个地方：

    1. README.md，也就是打开仓库页面，默认渲染在文件列表下面的那块
    2. 官方网站，通常在导航下方，仓库简介那里
    3. wiki，通过导航链接可以到达

    观察提交频率

    并不是所有的仓库，都有开发者在进行积极地开发和维护。如果搜索到几年前的文章，被导引到一些比较古老的仓库，可能出于某种原因，已经没人对它进行维护了，这个时候，该放弃就要放弃。

    人生苦短，时间有限，总会有更具价值的仓库供我们学习。

    GitHub 热门趋势

    GitHub 还有一个热门趋势页面，从中你可以了解到全世界的开发者都在关注哪些仓库，你可以把自己感兴趣的那些加星标记一下，将来不定时的翻一翻看一看它的 Issue、PR 和文档，通常都会有不小的收获。

    GitHub Pages

    GitHub 还提供给我们一个非常好的静态网站空间，完全免费，全世界都有 CDN，不用白不用。便是传说中的 GitHub Pages。

    我们可以用它写博客，做笔记，重点是内容完全可以进行版本管理。

    具体做法请自行 Google。

    不要放弃提交自己的仓库，也应积极向别的开发者提出 Issue 和发起 PR

    我觉得这件事和写博客一样，如果你只是在纸上记笔记给自己看，那多半会不求甚解；但是你想到写成博客总会有人看到，那多半还是会把要写的内容搞清楚，写全面，逻辑清晰可自洽。所以写博客是比记笔记更好的学习方法。以此类推，把自己的仓库推到 GitHub，也理应也是比在本地练习更好的学习方式。

    这里绝不鼓励大家乱来，相反，我希望大家对自己的行为负责，重视 Issue 和 PR，毕竟都是提给其他开发者的，或多或少都会对别人造成影响。所以在提之前，十分有必要阅读仓库主人的提交须知，按照对方的代码规范书写代码，写好相关测试，然后再提交。做到言之有物，切不可乱来画猫。

    总结

    这篇文章不是传授大家应聘技巧的，而是希望分享自己的一些经验，让大家能够通过 GitHub 这个世界上最大的代码托管平台，正确的学习开发技巧。

    如果您有相关的经验技巧，欢迎交流。

  • Git 笔记

    Git 笔记

    这里记录一些 git 概念和技巧。

    其它相关文章：

    （更多…）

  • 使用TortoiseGit+MSysGit+Github进行版本管理

    以后准备都用git进行版本管理。看完 http://progit.org/book/zh/ 的1~3章， 基本就对Git有了初步的理解，接下来，就是实战了。

    （更多…）