雾中之语

周报 #2|2305 - 改变

本周回顾

能够留在家中的时间越来越短了，两个月不过是白驹过隙，一闪而过。本周主要的时间花在了博客搭建和赶作业上，作业没啥好说的，就是一些无聊透顶的，但必须得去做的东西。但是搭博客的过程我觉得有必要总结一下。首先回顾一下我搭建博客的契机：

首先，博客是一个很好的载体，在写博客的时候，我能有一个很好的深度思考的机会。由其他推友影响，我也跟风开始写周报，为了能够让以后的自己在回忆这一段时光时至少了解自己做了些什么，想了些什么。现在我主要的目的是这个，同时这样也是锻炼自己写作技能很好的机会。我计划未来能够就自己所学写一些真正对自己和他人有用的文章，只是目前来说对我过于困难。总之，博客的搭建会是一个开始。

其次，最近 Twitter 频繁的业务调整，又是封禁第三方客户端，又是对 API 进行收费，这些都让我对这个平台的未来保持悲观。让我觉得把自己所写下的内容放在这个平台上是不安全的，同样我也不再愿意将自己绑定在这样一个平台上，现在我舍弃不了它的主要原因是我 follow 的人们都在上面，这一点短时间内很难改变。为了减少对它的依赖，我决定拓宽自己的信息输出渠道。

最后再回顾一下自己搭建博客的过程。首先，我对这一过程的总结就是一波三折与无能为力。具体的流程如下：

  1. Google 搭建博客的工具，这时了解到了 Hugo，然后看了下最近常去的博客也是 Hugo 搭建的，那 OK 就是它了。
  2. 因为之前有了解过 GitHub Pages 服务，所以就搜索用 Hugo 搭建博客并部署到免费的 GitHub Pages 的教程。
  3. 之后我创建了自己的 Hugo site，此时就出现了第一个问题。在添加 git submodule 后，启动 hugo server 的时候一直报错，整了半天才发现是 submodule 仓库没有被正确的 clone 到本地，搜索到了 git submodule update 的命令，总算得以解决。
  4. 接下来遇到的问题就超出了我的理解范围：GitHub Actions 并不能正确的将我生成的 Hugo 静态文件部署到对应的 gh-pages 分支上。每次我运行 workflow 之后它都没有任何的反应，而且由于对 GitHub Environments 的不了解，我从头到尾都没有发现原来自己的 workflow 就没有运行过，运行的只是这个 pages-build-deployment 而已。我当时不知道是为什么，现在还是不知道，所有的配置和 workflow 文件都是使用的相应 Actions 的文档的内容，还使用了 Hugo 官方提供的文档，都没有解决这一问题。
  5. 就这样，我删除过两次仓库，最终放弃了。只能选择另外的不使用 GitHub Actions 而手动进行部署的方法。这个方法需要有两个仓库，一个作为 Hugo site 的仓库，而另一个则是 GitHub Pages 相应的域名仓库。这个方法总算让我成功通过 GitHub Pages 访问到了自己的博客，但是更新比较麻烦，而且它使用了我的两个仓库，实在忍受不了。
  6. 最后，我从一个正常部署的仓库复制了 workflow 的内容到仓库中，打算最后试一下。让我没想到的是，这一次它成功了！我不太清楚是为什么，只是知道这一次和之前的尝试有两处不同：workflow 相应步骤的名称和之前不一样，最后 deploy 输入参数的 key 是全大写的，之前是小写；部署的仓库名不是 pages 的域名，而是另外的名字，不过我之后把名字改成了域名，同样正常的运行了。 至此，我的博客都在正常运行，虽然搭建它的过程浪费了我大量的时间。我也从这次的过程中学到了一些经验：
  7. 遇到问题，很多时候可能并不是自己的原因。而可能是工具产出的错误或者是超出认知范围外的配置、使用方法。所以此时要做的首先一定是先排除自己可知的问题，比如查看配置文件里有无错别字，有没有使用错误的参数等。排除这些错误后如果问题仍然存在，接下来应该做的是通过看文档、搜索等方法检验逻辑有无错误。我觉得这个步骤应该是最有效的定位问题的方法，但唯一的缺点是需要大量的时间精力，而且由于信息的庞大，可能并无法找到有用的信息。于是，如果这个步骤仍然无法定位问题，这时就应该另寻它路，重回起点。总之时间是宝贵的，遇到问题不应该固执地在无法定位错误的时候仍然幻想着再重来一遍就好，这条路走不通换一条路即可。
  8. 在进行一个项目前一定要提前规划好，列出需要用到的服务和工具，一定要提前对它们有一些基本的了解，这样在遇到问题的时候有助于自己定位问题所在。也能对自己使用它们能够达到的目标有一个认知，防止因无法达到预期而浪费时间。

本周探索

Nostr

最近，以 nostr 为协议的去中心化的 Damus 非常火，我也创建了一个帐号，公钥是 npub17yq9a5ua9e5c8389xfy0n0yea6py3slzh0z8e8c77js67nx9glzqcqdjth 如果有人看的话可以加一下。体验之后，给我留下最深刻的体验就是注册时的流程，简直是太简洁了，复制两串乱码，然后就创建了自己的帐号，这个体验很奇妙。其他部分的体验，说真的没有什么值得称道的地方，倒是体会到了 Posts 无法修改和删除、用别人的公钥登录可以看到发送私信的双方信息和信息时间这些因为其去中心化的信息架构带来的缺陷。所以，我认为它是不会成为主流的，特别是现在广告等垃圾信息的泛滥，用户集中在头部 Relay 对其形成的依赖，这些它现在都没有很好的解决方法。在我这样的普通用户看来，它也不过是一个创建帐号更简单的简陋版推特。但是，我仍然觉得 Nostr 有其存在的意义，它的流行和产生正是向世界普及去中心化网络的概念，我希望它能够成功。

最后，在 Twitter 被马一龙变成现在这幅封闭的样子之后，我不禁开始想象未来的社区会是什么样子的，互联网如何才能够做到忠实的连接人与人，做到信息的自由流通。而像 Nostr 这样的协议出现和流行，就意味着我们又向未来踏了一步。

我也看了一些 NIP 的内容，但对于现在的我来说过于高深，完全无法理解实现这些协议的底层技术，自己了解的技术还是太少，太单薄。

学习内容

本周，如同之前所说，几乎没有学习新的东西。只是学了一些 Hugo 的配置和搭建。但是，因为探索 Nostr NIP 时产生的挫败感，让我重新对自己的学习方向产生了动摇。我这个寒假以来，把大多数的学习时间都用在了前端的学习上。然而越是看到优秀的前辈，越是感到自己学习能力的低下和已有技术的贫乏，我在前端这个领域可能并无法做到优秀，甚至很长一段时间只能停留在入门水平，也就是我很难通过这一技能来获得工作。所以说到这里，我想我需要调整一下自己的学习重心了。我自认为在 UX 领域较为擅长，那么就应该进一步深入这个领域，并且打好 UI 设计的基础，这才应该是我目前的重心。而前端，或者广义上的 CS 则作为次要的学习目标。而不是像现在这样主次不分，错误的把大部分时间放在了次要的目标上。

越来越感到时间的急迫，我恨我过去浪费那么多时间，但也已经无法挽回。今后要开始选择性地学习，规划好自己的时间，做好对自己重要的事情。