我自己其实不太了解 ASoul，也没有特别的关注，毕竟作为一个社牛，不太会通过虚拟人来获取情绪价值。但我确实之前听说过 VTuber，在我的下意识以为，VTuber 的声音应该是由 AI 来完成生成，工程师建模，PM/运营来负责脚本的产出（类似微软小冰）。
不过，现实可能是 ASoul 这样的项目其实是由中之人来完成声音的录制，更接近于传统的声优的角色。对于资本来说，中之人就是一个耗材，但对于喜爱 VTuber 的人来说，中之人是非常重要的。
当一个 VTuber 之后是一个独立的人的时候，其实能贡献的当然不只是声音的问题，还可以贡献出更多的情绪价值。而这些情绪价值，正是一个 VTuber 的独特的价值。
这些东西是完全无法通过 AI 生成的么？可能是可以生成的，但暂时可能无法生成。随着技术的进步，逐步拆解出人的各种情绪和诉求，再由 AI 来完成生成，实现真正意义上的 VTuber
我们在生活中，需要注意情分和本分的区别。不要错把本分当情分，把情分当本分。
举个例子来说，
假设我当前的房子快要到期，我找了一个新的空房间。为了减少租期的重叠，我与房东达成了一致，在两周后入住。
但因为我自己的原因，不得已需要提前入住，这个时候我和房东沟通，说我是否可以提前入住？房东同意我提前入住。
在这个事情当中，房东同意我入住是情分，房东不同意我入住是本分，因为我们的合同签署的入住日期是两周后，即使不允许我入住，我必须出去住酒店，也是因为合同签署的确实是两周后，这也是合法合理的。
在生活中我们需要感谢别人的情分，感谢他人的帮助。但同时也要明白，别人遵循本分做事并没有什么不对，人家只是遵照合同办事，没有过错。
长期投资：本月持续定投指数基金。
投机：本月开始进行 Crypto 领域的买入，目前在买入的是 NFT 。NFT 的市场还是比较有意思的，波动比想象中的要小一些（也可能是因为我一进来就碰到了一个还行的项目）。目前两张图片都还是有浮盈的，不过首先于最近的股币双杀，没有太大的变化可以预期。好在我买的时候都很便宜，也不指望这一笔赚多少钱，挂了个单就丢那里了。
不过在购买 NFT 的时候，也发现了很多机会（也可能是坑），目前 NFT 领域的工具链并没有我们想象中的那么全面和丰富，里面有不少的空间可以去做一些东西。后续我应该也会去
这方面还没有变化。感觉还需要拆解一下，如何提升稿费。
阅读量？但看起来像是广告费。需要量化一下。感觉自己这个 KR 定义的有问题。
目前支出预算略超，五月要考虑节约一点了。
软件类业务本月没有太大的进展，主要是状态不好，盯盘的花费的精力较多，5月优先这部分 KR。
赚钱的目的是生活，不能为了赚钱而赚钱，更应该关注自己的生活。因此，为了生活，设定下如下两个 Key Result：
四月份去泡了个温泉，体验了一把室外温泉。没有远行，主要还是收到了疫情的影响，比较难。
四月看了一场话剧，圆了自己的一个心愿。
暂无进展
原本说想在少数派写原则系列的书评，结果也鸽了。。。唉。。。
继续 0 进展。为什么不敢写？应该还是怕自己的产出这不符合自己的预期？有偶像包袱？
暂无进展。
在使用 OneInStack 时，有一些事项需要注意，不然可能会导致你的 Redis 在使用过程中出现问题。
OneInStack 中 Redis 的默认内存配置是比较小的，只有 122MB ，对于一些大型应用来说，是肯定不够的，因此，在实际使用过程中，还是最好将其修改为一个更大的值。
配置文件路径: /usr/local/redis/etc/redis.conf
需要修改的项目 maxmemory 122000000，将 122000000 修改为 256000000 即可将 Redis 使用的内存设置为 256 MB，从而扩大了整体可用的内存的大小，应对大型数据库也游刃有余。
OneInStack 中 Redis 的默认逐出机制是 noeviction，即内存满后不逐出，写入缓存报错，读缓存不受影响。
对于将 Redis 作为数据库的场景而言，这么干是正确的。但对于做缓存的场景，则需要修改逐出机制，比如可以将逐出机制修改为 allkeys-lru，即在全部的key中淘汰最近最少使用的key。
在配置文件（ /usr/local/redis/etc/redis.conf）中加入一行配置即可
maxmemory-policy allkeys-lru
我算是一个被「消费主义」洗脑的人，很喜欢买各种各样的东西，比如：
我买了很多东西，其中一部分是我自己生活需求的延展所带来的，另外的一部分，则是来自于被各种视频/朋友推荐。
我买的制冰机便是一个典型的例子：
我是在津津乐道的节目当中听到大家推荐居家好物的时候，提到了制冰机，以及制冰机带来的畅快感，就买了制冰机。
而我购买产品的逻辑倒是也十分简单：我不太会听陌生人的推荐，而更相信一些有着持续关系和持续口碑的人的推荐。在我看来，靠谱的人推荐的产品大多是靠谱的，不靠谱的人推荐的产品是不可信的。
最近，又快要到搬家了。准备继续寻找一个更加低成本生活的方式。届时，又是一次断舍离。
当我的东西变少的时候，确实，生活变得更快乐一些（就像我们想要去露营，体验的一方面是大自然的美妙，另一方面，则是对于逼仄生活的反抗。）
MySQLDump 是非常常用的数据库导出工具。不过，大部分时候，我们使用的都是 mysqldump -uuser -p database_name > database_name.sql
这样可以提供数据导出功能，但导出的数据会是全表数据，我们在导出数据的时候，如果希望导出部分数据，就需要借助于其中的 --where Flag，来实现导出部分数据.
此外，由于导出的数据是部分数据，因此，就涉及到需要指定导出时的表名，才能实现导出相应的数据，需要满足如下格式
mysqldump [OPTIONS] database [tables]
Code language: CSS (css)举个例子来说，假设我们需要导出数据库 wordpress 的 wp-options 表中的 ID 小于 20 的数据，则需要执行如下命令:
mysqldump --where="id < 20" wordpress wp-options
Code language: JavaScript (javascript)上述命令就实现了从数据库中导出符合特定要求的数据。
在使用 Next.js 进行开发的时候，会遇到某些组件是不提供 SSR 支持的（很正常，毕竟 SSR 是一个相对比较小众的应用场景。此外，某些组件会依赖浏览器环境的上下文），在这种情况下，我们需要一种方式来实现对非 SSR 组件的支持。
一般而言， 有两种方式，一种是使用 useEffects 来控制组件的载入，从而实现只在客户端层面加载组件，服务端渲染的时候就不再加载该组件。
另外一种方式是可以考虑借助于 Next.js 自带的 Dynamic Import 的特性，来完成组件的引入。
在使用层面比较简单，引入组件的方式从直接引入改为最外层套一层 dynamic 函数即可
import dynamic from 'next/dynamic'
const DynamicComponentWithNoSSR = dynamic(
() => import('../components/hello3'),
{ ssr: false }
)
function Home() {
return (
<div>
<Header />
<DynamicComponentWithNoSSR />
<p>HOME PAGE is here!</p>
</div>
)
}
export default Home
Code language: JavaScript (javascript)这个问题的解决让我再次激起了对于 Next.js 的兴趣。过去因为不确定如何解决在浏览器和客户端环境下的问题，对于 Next.js 有些畏难；如今问题已解决，可以继续放心的使用 Next.js 了。
最近在研究和体验一些 GitHub 上的前端项目，遇到了一些让人体验不佳的点， 这里梳理一些我遇到的，一方面是留存，记录那些让我体验不好的事情。另一方面警示自己在开发前端项目的时候应该注意一下开发体验，确保不会让别人在开发的时候也遇到这些问题。
这是不少 GitHub 上面项目的普遍问题。现有的文档要么是以 Framework 生成的 Readme 为主，要么直接没有文档。
但没有文档对于后来者的开发其实非常不友好，比如几个常见问题：
上面这些文档是帮助后来者快速使用你的项目所必需的（换句话说，如果你要做开源项目，想要打造开源社区，这也是必要的）。
我在开一些前端项目的时候，明显会感到浏览器的响应变慢了，我以为是我的 Mac Mini 2012 性能不行。但我打开自己的博客，依然如丝般顺滑，我就明白了。问题不在于我的电脑性能跟不上，而是这个前端页面加入了大量的有用或无用的代码，使得 CPU 需要大量的计算。
虽然进入 SPA 的时代以后，我们开始将算力的使用从服务端往客户端转移，但也建议各位工程师控制自己项目的复杂度，不要一开网页，风扇就呼呼的转。浏览体验不好，还凸显自己的技术不行。
console.log在编译型语言当中，使用 Debugger 来进行调试是一项基本技能，因为需要在运行时去看不同的变量的值，以此来完成调试。
但在前端领域，因为 console.log 的过于好用，大家开始习惯于使用 console.log 来打印变量，但对于大型项目来说，大量的 console.log 也会让你的项目输出许多无意义的内容，让整个项目的调试和开发受到阻碍。
最近看项目，总结了三条自己觉得影响体验的点，后续随着看的项目的深入，会逐渐总结出更多影响体验的点，引以为鉴。
我的博客能够保持日更，主要来说，是有两方面因素：
很多时候，我的写作都是要先取悦自己。所以我对于一篇博客的要求没有那么高，达到最低标准，300 字即可（这个也是微信公众号原创文章的要求），所以我不会有太多的心理压力，担心一篇文章是否足够完美。
我每天会看到大量的文章内容，这些文章内容可以激发我自己思考，并产生出新的灵感，通过这些新的摄入诞生的很多灵感都不够深刻，但确实可以写下我对这个问题的思考，并在后续的时间沉淀下，不断的重新思考、再次思考。
我常用的信息输入的平台：
如果你发现自己没有灵感，不妨试一试。
最近重读《番茄工作法》和《番茄工作法图解》，有一种预感，大家可能都用错了。大部分人用番茄工作法关注的是 25 分钟工作 5 分钟休息。但在我看来，这个可能是整个番茄工作法中最不重要的了，不同的人不同。你应该根据自己的实际情况来调整你的工作时长和休息时长。倒是背后的几张表格可能更重要。
番茄工作法中，包括三张表：「今日待办」、「活动清单」、「记录表」。
今日待办记录了今天要做的事情和突发的紧急事项，用于指导你在一天中的工作；活动清单则类似于 GTD 当中的 Inbox，收集了所有要做的事情；记录表则是存储了任务的元数据，可以用来对自己进行分析和指导。目前市面上大部分的工具都集中在如何做好定时器。对于记录表、今日待办和活动清单都没有做的特别好。 Session 算是比较好的，对于这些任务的数据有了展示。但在我看来，这个依然不够有效。主要是这里的数据其实是最基础的，对于形成反馈优化我们的时间和工作没有太多的帮助。
在我看来，番茄钟的基础是 25 + 5 的模式，来让你集中 & 放松。但想要保证 25 ，是需要「今日待办」中的「计划外和紧急活动」来保障的。不然待来的结果是要么 25 分钟费了，中间干别的了；要么是你 25 分钟倒是用好了，但计划外事项和紧急活动丢了。
至于活动清单，倒是相对简单一些，是 Inbox 以及进行任务的预估。Inbox 无需多说。任务的预估对于构建番茄钟的系统来说非常重要，你的精力是有限的，将精力用在有限的事情上需要你明确自己的精力状态和能做的事情，以及对要做的事情有明确的预估，才不会出现大面积 Delay 的情况。
记录表则用来追踪这些原始数据，并搭配着「今日待办」和「活动清单」一起来构建一个反馈系统，得出优化的结论。
上述的这些是现在的番茄钟工具大多没有关注到的。这些工具更加关注 25 分钟这个时间，但其实这是最没用的。
这也是为什么我现在又回到了纸笔的方式来使用番茄钟。不过我的做法可能过于原教旨主义了。明明这些事情用工具可以更好的解决，但我确实找不到更好的工具了。所以回归纸笔了。
