代码人生：编织技术与生活的博客之旅
前端的技术框架层出不穷，各种生态衍生的库更是多到让人眼花缭乱，光是看着这些名字就一时让人分不清谁是干什么的。
这与 JavaScript 这门语言的广泛的应用有关，由它衍生出的运行时环境就有 Node.js 和各种浏览器的内核例如：Chrome V8，然后随着各种运行时环境中发展出来的应用场景 衍生出来的技术框架。有专门应用于服务端的和客户端的技术，同时也有支持服务端渲染的。
基本上前端框架就是围绕着 Vue 和 React 两大生态，它们两者互相借鉴，又各具特色和优势。
这不最近我就错把 Nest 当做 Next ，被两者的学习资料搞混淆了。
微前端是指存在于浏览器中的微服务，其借鉴了微服务的架构理念，将微服务的概念扩展到了前端。
如果对微服务的概念比较陌生的话，可以简单的理解为微前端就是将一个大型的前端应用拆分成多个模块，每个微前端模块可以由不同的团队进行管理，并可以自主选择框架，并且有自己的仓库，可以独立部署上线。
首先我不是 iphone 用户，甚至是果黑（苹果的小黑子，合理来说是苹果手机的小黑子），所以我一向从内心就很摈弃苹果的产品。因此我从来没体验过 MacOS 系统，用了近 4 年 window，不过由于我的那台 window 本 （21 年小新 pro14） 给我的体验非常差，虽然说续航勉勉强强足够支撑我一个下午的开发，但 intel 的 i5 cpu 我就没打算将其作为主力机开发（根本做不了），更多是使用向日葵远程桌面软件来远程连接到我的台式电脑，远程操控来进行开发。然而由于屏幕分辨率不同以及网络延迟，这样的体验长期下去必然会崩溃。因此更换自己的移动办公设备已经成了我当下的刚需。
见识到诸多程序员大神都将 mac 作为主力开发机器，同时又被安利过很多次 MacBook，但我一直对 macOS 保持观察的态度，自己从未亲自体验过，最多也就看别人用用，在 window 上这些同样也能实现，何必要多此一举再去了解一个新的系统，新的操作逻辑。但直到我真正接触并体验过 macOS 后，我便爱不释手。
在写这篇文章时，我已经用了近一周 的 macbook，因此想分享个人的购买流程、选购建议、使用感悟，或许对于某些想要尝试 MacOS 但又保有迟疑态度的用户有所帮助，也算是给曾经的我对苹果的偏见的转变。
拖更了近两个月的博文了，摆了一整子，说来也确实有些许惭愧。不过目前生产力工具已就绪，也要开始步入正轨。
对于想快速实现一个产品而言，如果使用传统开发，又要兼顾前端开发，同时又要花费时间构建后端服务。然而有这么一个平台（Baas Backend as a service）后端即服务，能够让开发人员可以专注于前端开发，而无需花费大量时间和精力来构建和维护后端基础设施。
对于只会前端的人来说，这是一个非常好的选择。后端即服务的平台使得开发人员能够快速构建应用程序，更快地将其推向市场。当然了，你可以将你的后端应用接入 Baas，这样你就无需配置数据库，编写复杂的身份效验。
如果你想了解 Baas，我想这篇文章或许对你有所帮助。
如果你的项目要长期使用并维护的话，那么代码自动测试就非常有必要使用。因为没人能保证在修改代码后，不会引发其他额外 bug（功能失效，渲染失败），而在修改完代码后，跑一遍测试就能很大程度让开发者发现自己所修改的代码是否存在问题，是否会导致原有功能失效。
尤其是在其他人接手这个项目时，诱发 bug 的概率自然也就更高（因为他有很大的可能不知道这部分代码的上下文的功能用途），所以这也就是为什么很多开源项目与大型企业的公司都会使用自动化测试，以及要求一定的代码覆盖率。
当然如果项目不是长期维护的，那么完全没必要编写测试代码，这么做无疑是在浪费开发者的时间。
老早老早之前就听过 monorepo（单一代码库） 这个名词，也大致了解其出现的意义与功能。但奈何自己的一些小项目中暂时还用不上多项目存储库，所以迟迟没有尝试使用。
但随着越来越多的开源项目使用 monorepo，现在不实践到时候也肯定是要实践的，这次实践也算是为以后的技能先做个铺垫了。
准备给我的一个 Vite 项目进行重构，其中一个功能(函数)要花费 JS 主线程大量时间，会导致主线程画面卡死，无法正常点击，直到该功能(函数)执行完毕而言。这样的用户体验非常差，于是就准备使用 WebWorker 对该功能封装。
当我使用笔记本的时候，每次移动光标，都要大费周章，同时由于笔记本的缘故，导致键入Home与End都需要搭配Fn功能键来实现。所以我希望在任何情况下（敲代码，写文章）都可以将某些组合键绑定为上下左右键，在代码编辑器上有键盘映射可以设置，但脱离代码编辑器就不起作用了，在window下有个神器 AutoHotkey 可以实现我想要的功能。
Vercel 除了能部署静态站点外，还能运行 Serverless Functions，也是本次的主题
如果有写过项目的经历，就免不了将代码上传到服务器上，安装依赖，然后输入启动命令的步骤。但是有的项目往往需要经常性的改动，如果还是照着上面的方式进行部署的话。先不说这样操作的效率，操作个几次就想罢工了。并且上面这样操作的往往容易误操作。而 Github Actions 正是该问题的良药。
Vercel 部署静态资源网站极其简单方便，并且有可观的访问速度，最主要的是免费部署。
如果你还没有尝试的话，强烈建议去使用一下。
与之相似的产品 Netfily，如果你想部署私有化，推荐 Coolify
如果你想搭建一个类似这样的站点，不妨参考我的 Docusaurus 主题魔改
由于某些原因，vercel.app 被 DNS 污染（即被墙），目前在国内已经无法打开，除非你有自己的域名，通过 CNAME 解析访问你的域名。
因此想要在国内访问，建议不要使用 Vercel 部署了，最好选用 Cloudflare 或者 Netlify。
虽然知道开源有个许可证 LICENSE，但一直没给自己写的一些开源项目选择开源许可证。于是准备系统了解一下开源许可证，以及如何为 Github 项目添加 LICENSE。