最近写一个Node.js的项目，使用ts-node做为运行时，在使用top-level await的时候，遇到了一些问题。
我是在VSCode里写的项目，实际上我debug模式和生产部署都是使用ts-node，感觉非常方便，一个配置都不需要就能这么Run起来。
但是我在处理Mongo/Redis链接时，为了图省事，我想直接在await connect()，结果启动程序报错:
SyntaxError: await is only valid in async functions and the top level bodies of modules
...
课程列表中有一门Java编程课程，其中有一个实验作业是模仿Windows自带的计算器做一个非常简单的计算器，但由于目前没有使用Windows，于是只能仿着MacOS自带的计算器实现了一个，初次接触Java，也初次接触swing。
我没有具体研究过计算器的各项功能，仅凭自己简单的使用经验写了一个，具体实现以下功能。
...
这是一个同事遇到的问题，他说他用kubeadm初始化一个集群后，一切看着正常，但pod网络之间不通，不知道哪里出错了。我其实是有点害怕解决这样的问题的，因为k8s的绝大部分问题都是网络问题，而且还不好定位解决，也就是说可能你花了很长时间也未必找到问题，所以我通常建议要不就重新初始化。但同事说初始化好几回了，问题依旧存在，听到这里我觉得不得不直面问题了。
一顿排查，发现IPVS没有相关的规则，为什么没有相关规则呢？顺着问题接着排查，最后看到kube-proxy有这样一段可疑的信息
...
这应该称得上他俩这个时期爱好的标签了，只要有任何机会就要坐电梯，无论是扶梯还是直梯，他还会仔细观察电梯有多宽，有什么按钮，应急按钮是干什么的，还误按了几次应急按钮（实在是防不住）
家附近有一个商场，他俩开始学会走路后，那会正直疫情封控，能去的地方非常少，于是夏天就喜欢带他俩去商场里溜达。
只要一进商场，路线就已经给你规划好了，拉着你坐各式各样的扶梯，只要他能看见的，基本都要坐。那个时期我比较痛苦，因为他俩胆子还小，走路要抱着我的腿，两个小孩一人抱一腿，他俩的头正好顶我的屁股上，我走路就跟企鹅一样，时间长了非常累。一开始我以为这是小孩有什么特殊的原因，后来也就慢慢理解了，喜欢坐电梯的小孩还挺多的。
...
大环境差，公司刚经历一波裁员，我的团队也全部解散了。工作也没有之前那么忙了，正好也可以抽时间完成之前一直在计划但没有做的事
转眼，2024年已到来，两个宝宝也迎来了4岁生日！不少人回想过去通常会觉得很艰辛，的确，非常感谢我老婆无比艰辛的怀两个宝宝最后顺利出生。
...
2023～相信看到我这篇文章的大多数IT行业的朋友都受到了2023经济低迷的影响，降薪裁员一片哀嚎～，就连家底殷实的大厂也不例外。要说这个时期有没有逆势者可能大觉都共认华为了，一机难求，它给中国制造提振了不少信心，问界汽车一把做到龙头位置，其它当然还有芯片、国产系统产业都是逆势归来。人们在经历不幸时总会展望来年，我也不例外，经历了2023团队解散、降薪、业务线停滞等种种事之后自然就在思考2024会好起来吗？
时间飞快，7月团队解散，转眼就2024的元旦了。公司也并没有消停，经过2024年的市场预期，计算了一下现有的成本，发现还得继续裁员才能做到成本持平，这让我想起了前段时间我看的一本萨希尔·拉文吉亚写的《小而美》,作者一直努力想让自己公司变成独角兽，但是至少少数公司能成为独角兽，大多数公司能盈利就不错了，之前有过相关的创业数据称平均一家创业公司的存活周期是2年，也就差不多天使轮之后要么成要么黄。
...
今天需要把一个clickhouse的实例转移到另外一个实例，本来要使用clickhouse-backup工具，但最终总是导出metadata，没有包含实际数据，没办法只能放弃，使用脚本的方式导出建表语句，再导出CSV的数据。
然而在导出建表语句的时候，非常奇怪，在clickhouse CLI下总是看起来正常
$ SHOW CREATE TABLE analysis.spm_dictionary
SHOW CREATE TABLE analysis.spm_dictionary
Query id: 0bd7cb9d-b92a-4625-9ca9-eb306ce77fd3
┌─statement───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ CREATE TABLE analysis.spm_dictionary
(
`spm_b` String,
`name` String
)
ENGINE = MergeTree
ORDER BY spm_b
SETTINGS index_granularity = 8192 │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
1 row in set. Elapsed: 0.014 sec.
...
前两天在解压一个tar包时提示
Cannot change ownership to uid 1000, gid 1000: Permission denied
第一次遇到这个问题，看这个错误感觉像是权限的问题，但我当前操作就是在root账号下，理论上root应该拥有一切权限，而我这次操作跟以往不一样的地方是我在NFS下解压的。
我在本地磁盘下可以解压，在NFS下无法解压，难道我需要去修改NFS的文件系统？
后来在tar的帮助文档里看到了一个关键性配置项--no-same-owner，这个配置项的意思是在解压时不用保持相同的Owner，我试了一下，错误解决～
...
我有一个Rust项目，需要发送kafka消息，容器化运行。我使用的是Rust 1.70版本，kafka类库使用的是rdkafka，但最近遇到一个非常奇怪的问题，我发现在没有修改任何依赖与Carogo.lock的场景下重新构建出来的镜像竟然无法发送消息。到生产后一直报错
Failed to produce kafka message: Message production error: MessageTimedOut (Local: Message timed out)
...
前两天逛httpie的Github仓库，发现README写了一段有意思的内容
We lost 54k GitHub stars
有点好奇，就点进去看了一下，总的来说这是发生在2022年因为一次误操作把仓库从public改到private导致Github系统把原仓库5.4万的stars清零的悲惨事件。
到现在有一年时间也不属于什么新鲜新闻了，甚至可能看到这篇文章的很多读者都已经知道了这件事，接下来我就摘抄文章里的一些有意思的片段
...