https://blog.yibu.org/ Recent content on 亦步 Hugo -- gohugo.io Sat, 11 Apr 2020 00:00:00 +0000 https://blog.yibu.org/posts/2020/04/11/netlify-scoop-search-deployment-rust-zola/ Sat, 11 Apr 2020 00:00:00 +0000 https://blog.yibu.org/posts/2020/04/11/netlify-scoop-search-deployment-rust-zola/ 之前文章中提到我自己搭了个页面 Scoop Buckets Search 用来搜索软件包，主要结合了 Gatsby 和 GitHub Actions 拿数据搭静态页面，然后部署在 Netlify 上。有两个问题值得注意： 正如在之前文章抱怨的那样，Gatsby 之类的网站生成器由于 JavaScript 技术栈的原因，构建速度并不让人满意，在 Netlify 平均一次从 Build 到 Deploy 要 1 分 30 秒左右。Netlify 也有一个缺点，limit 一过就会自动扣钱并添加一个 Extra Build Time 包，关键是 limit 快超过时也没有特别的警告之类的。 另外一个是搜索速度。由于数据在页面状态内，事实上每次页面加载时才会构建搜索用的索引，加上 JavaScript 的搜索库效率并不高，即使是只有 2k 不到的条目，搜索也会感觉卡顿。我尝试使用 LazyLoad 懒加载，效果并不理想。 所以呢，就想针对这两点优化一下。其实标题党了😂，因为减少构建时间的手段非常直白：换个快速的静态网站生成器。 用 Zola 构建网站 之前有过 Hugo 和 Zola 构建网站的经历，极快的构建速度让我印象深刻，而且需要的依赖也很少。这次就选择用 Zola 构建。Zola 的类 Jinja2 模版系统 - Tera 用起来简单，从 Gatsby 的模版迁移过来很方便，基本上直接挪过来就能用。 Netlify 也支持 Zola，因此整个构建 workflow 可以和 Gatsby 的保持一致，就是喜欢这种省心的。弄完简单测试了一下，不带搜索的页面 build 时间下降到了 30s。 https://blog.yibu.org/posts/2020/03/17/netlify-scoop-search-deployment/ Tue, 17 Mar 2020 00:00:00 +0000 https://blog.yibu.org/posts/2020/03/17/netlify-scoop-search-deployment/ 之前文章中提到我自己搭了个页面 Scoop Buckets Search 用来搜索软件包，希望比终端快一些，比 GitHub 搜索直观一些。 这篇文章啰嗦一下，将说明一下如何结合 Gatsby 和 GitHub Actions 拿数据搭静态页面，然后部署在 Netlify 上。Netlify 确实很好用。 Scoop 自带的搜索会搜索默认的 Main Bucket。有些时候，我要找的软件不在其中，我就会去 Extra Bucket 找找看。大家呢又在 GitHub 维护着好几个不同的 Buckets，如此反复在不同 Buckets 中寻找软件既不直观也很折腾。 于是我就想整合不同 Buckets 的软件列表到一个页面上搜索。粗暴的方法就是把数据扔进数据库，搞个搜索界面。但是这样太折腾，也没必要。要是能定时抓取 Buckets 的数据，放进静态页面，整个页面内搜索就好了。想了一下应该挺简单，可以搭一个（事实上我东搞搞西弄弄，这玩意也折腾了一整天）。 在哪里部署页面？ 终于要点题了吗？😂 我的构想是弄一个简单的静态页面，包含搜索和结果展示。部署静态页面的方法也非常多： 复古点就放在自己的服务器。可能会多一些维护成本。在有服务器的情况下，对于不频繁更新的页面，这种方法可能是最简单直接的。 部署在更专业的静态网站服务器商。例如 Netlify，ZEIT，Surge 等等。这类服务通常都有 CDN，SSL，Git Hooks，很友好的入门 Plan，甚至还有 Serverless Functions 的功能（Netlify 还有 Identity 和 Forms 这些非常实用的功能）。 Netlify 我自己比较熟悉，这次就部署在 Netlify 图省事。每次有更新就 push 到 GitHub，Netlify 可以利用 Hooks 自动构建部署页面。 如何构建页面？ 一个静态单页面，直接手写也应该不难。考虑到之后的更新维护，我决定还是用静态网站框架来搭页面。 现在流行而且相对成熟的静态框架也很多 Hugo，Gatsby，Hexo 等等。Gatsby 的数据流模式和插件系统很有意思，虽然我之前没用过，这次还是由于好奇心的驱使决定用 Gatsby。 https://blog.yibu.org/posts/2020/03/15/windows-package-manager/ Sun, 15 Mar 2020 00:00:00 +0000 https://blog.yibu.org/posts/2020/03/15/windows-package-manager/ 相信用过 Linux 的朋友一定会对各个发行版的包管理器印象深刻，例如 Debian 的 apt，Arch Linux 的 pacman，以及 NixOS 的 Nix，包管理器解决了软件的安装、更新、依赖检查等问题，使得系统用起来会省心不少。 那么 Windows 系统上有类似的包管理器吗？抱歉，官方没有专门的包管理器，也许 NuGet 算一个（Microsoft Apps Store 可称不上包管理）。Wait，Windows 需要包管理器吗？直接各个软件官网下载安装包一路点击“下一步”到底，根本不需要包管理器。然而对于我来说，我有一些额外需求： 软件能集中管理：统一安装在某个位置便于集中管理。 软件安装、更新、卸载方便。 环境变量和注册表配置省心。 以上需求主要针对一些工作学习用软件，例如 emacs / vim 和 各种语言的解释器安装包（docker也许更方便省事？）等。浏览器这种我就让其放飞自由了 😅。 Windows 上的非官方包管理器现在比较知名的应该是 Chocolatey 和 Scoop。我之前一直用 Chocolatey 来管理一些工作软件，直到最近装机开始转投 Scoop。 Chocolatey 基于 NuGet，软件仓库内软件包丰富，软件仓库还有一定程度的审核机制，维护人员也挺活跃。整体上我觉得 Chocolatey 会比较适合 IT 批量部署。我觉得使用上的不足有： 需要 Administrative Priviledges：安装、更新、卸载都涉及 Admin 的权限想想就头疼。当然 Chocolatey 也有 Non-Administrative 的安装方法。 软件配置不够透明灵活：包括环境变量和注册表配置等，也包括自己要更新软件仓库的配置繁琐。 Scoop 除了限制在 PowerShell 中运行外，其余要比 Chocolatey 更加灵活： 软件仓库被称为 Buckets，除了可以使用预置的一些 Buckets 之外，还可以自己创建 Buckets。 只需要普通用户权限，所有软件安装在对应用户的指定位置。 关于 Scoop 和 Chocolatey 具体区别可以查看 Scoop and Chocolatey Comparison。 https://blog.yibu.org/about/ Mon, 01 Jan 0001 00:00:00 +0000 https://blog.yibu.org/about/ 欢迎来到 亦步 (yibu)，这是由 yibum 所维护的 blog ，记录生活工作的想法和偶尔折腾的各种技术相关内容。 更多文章索引请浏览 Home 和 Tags。 为了减少冗余的页面（其实是懒），做了如下简化： 不设置 Archive 页面，Home 页面的作用同 Archive， 不设置 Categories 页面，Tags 页面的作用覆盖 Tags 和 Categories。 博客内容仅代表个人观点，与雇主无关。 博客的呈现使用了以下相关工具和平台：