
## 介绍
在开发 Tauri 应用的使用，在服务层定义的 `rust struct` 往往需要在前端再通过 typescript 再定义一次。
可以使用 `tauri-specta` 通过在编译时，自动生成 typescript 类型和函数，来解决这个问题。

## 使用
### 安装
在 `Cargo.toml` 中添加依赖
```shell
cargo add specta@=2.0.0-rc.5
cargo add tauri-specta@=2.0.0-rc.2 --features javascript,typescript
```

详情可以见 [文档](https://github.com/oscartbeaumont/tauri-specta)

## 问题
### 1. NaiveDateTime 无法转换

specta 实现了对 chrono 的支持，但是需要再 features 中开启，详情请见 [文档](https://docs.rs/specta/1.0.5/specta/#attributes)

### an `Err` value: BigIntForbidden(usize)
因为 Javascript 的最大安全整数是 2^53 - 1，所以 u64 / i64在转换时，如果超过这个范围，会报错。
`specta` 支持了 `pub struct ExportConfiguration { /* private fields */ }`
所以在 tauri 的 `main.rs` 里可以添加如下代码：
```rust
    let config = specta::ts::ExportConfig::new().bigint(BigIntExportBehavior::Number);

    let specta_builder = tauri_specta::ts::builder()
        .config(config)
        .commands(tauri_specta::collect_commands![...some command]);
```

## 备选方案
rspc 是一个类型安全路由器，它允许在 Rust 中构建具有端到端类型安全的 API。您可以在后端的 Rust 函数中定义逻辑，并使用 React hooks 或 Typescript 客户端来调用它。其内置了对 Tauri 的支持。其作者和 specta 是同一人。
[文档在这里](https://www.rspc.dev/integrations/tauri)


## 有用的链接
[关于 Tauri 自动生成 ts 代码的讨论](https://github.com/tauri-apps/tauri/issues/1514)


Tauri 配置自动生成 typescript 类型和函数

Mac 上如果长按某个键，会出现特殊符号的选择，但是如果是 vim 用户，为了方便移动就会经常按着 h/j/k/l 不放。
为了优化长按快速移动，可以做两步配置：

第一步，如图所示，这个设置可以帮助光标更快速地响应，两个选项都移动到最右边：

![system-setting.png](/assets/blog/images/some-mac-setting-for-dev/system-setting.png)


然后在 terminal 里执行以下的命令就可以了：
```shell
defaults write NSGlobalDomain ApplePressAndHoldEnabled -bool false
```
如有必要，也可以需要重启。


Mac 配置长按键盘重复输入


如果不太懂体育且强势的家长，希望孩子走体育这条路时，对于孩子来说，可能是件很危险的事情。
这两天看到一个四五岁的孩子学打网球，一招一式打的很好，好多教练都在夸他的基本功比较扎实。但是在有教练的情况下，妈妈也一直在旁边指导（妈妈为了孩子学网球，自己也开始研究），孩子胆子很小，不敢反抗，一直按照妈妈的指示做事。教练有意地鼓励他表达自己的想法，让他学会反抗，哪怕说一句“我想休息”或者“我想喝水”。
对于希望把体育作为自己的职业的人来说，自信是第一要义。自信心很大程度上决定了你如何面对漫长的体育生涯中的成功和坎坷。甚至影响了当你站在赛场上，所做的每一个能够支持你能否胜利的决定。其次，家长以自己视角的“总结”，剥夺了孩子在参与这项运动时的一部分意义——不断自我总结提高。这其实是参与运动的乐趣之一。这样可能在孩子小的时候确实能够提高很快，但总有一天，孩子要独自面对自己的困境，要自己调整，而这一部分能力，他极可能处于劣势。
当我和在场的网球教练教练交流这些时，他还举了自己身上的例子：他小时候也不自信，所以很能体会这个小朋友的处境。他出去打比赛的时候，4 比 0 领先，当时把对手已经打懵了。但是节间休息的时候，他突然有一个念头闪过：这如果都能输，我就不适合打网球了。后来回到比赛，以4 比 6输了。他说他后来花了很长的时间，去克服这个念头给自己带来的影响。

体育观察——孩子的运动信心

暂时离开了上海，而且是以最突然的方式：下午决定离开，然后从公司请假回家开始收拾东西，第二天早上六点出发，晚上九点到达。

猫咪和狗子在车上都难得乖巧，没有惹乱子。

带它们离开之前，很担心女朋友的妈妈接受不了它们。毕竟它们中有能吃的，有能闹的，也有能睡的，最重要的，还有能掉毛的。对于有洁癖的人来说，动物毛发就是灾难。

在这里生活了两个周，大概明白为什么我的一些朋友们为什么喜欢呆在小城市了。这里舒服，安静，仿佛招招手就能触及你想要的一切。想去的球场出门二十分钟就可以到达。江边随意修建的草坪，我在上海两年也没有见到过。在上海寸土寸金的地方，每一根草坪上的草，都在被精确规划着。城市太小，遇到熟人的机会就会大大增加。女朋友的健身教练和我的网球教练认识。类似的场景不要太常见。

当然也可以预见的：我们的生活娱乐，一直在围绕着那几个地方。

离开上海的这两个周，我在疯狂运动：网球、篮球、飞盘、板式网球，玩一切我感兴趣的运动，已经快要抵上我在上海半年的运动量。在这里，我又有了篮球梦，我又有了运动梦。

上海有“谣言”说，封控又要开始了。希望那里的朋友一切都好，我想我们很快就回来。

后疫情时代 #5

突然疫情就“结束”了。

我们小区松动的第一天，小区门口就堵了车，车辆排出了一百米的队伍。饭馆陆陆续续择良辰开门。一开始我以为，两个月的亏本，街边的店铺会迫不及待的开始营业，但事实上并不是。打电话问家附近最喜欢的面馆是否已经营业了，那边的回复是：怕出事，等过一个周看看。大家都变的小心翼翼。

看起来结束了封禁，但离恢复正常还很远很远。

六月初，附近的核酸采样点总是排着长队，大家为了"出门资格"浪费了很多时间。好像全上海的核酸采样点都在吵架。我们附近的也在吵过几次。老人们起早去做，年轻人贪黑去做。凌晨两点，做完核酸吃个烧烤的场景，就发生在六月初的上海。每次打车回家，下车之前我都会要求司机多开一点，顺便做个核酸。我也在被驯化。

官方说七月份做核酸就要开始收费了，我很好奇这种收费是不是有"强买强卖"的违法行为在里面。学法律的朋友没有回答我的这个问题，我自己开始学习行政法。但是学着学着我就在想：在中国，公民了解法律好像无法保护自己，只是能在吵架的时候底气足一点。

弱势群体太弱势了，就像餐厅无法堂食这个事情。消费者无法对抗店家，店家无法对抗商场管理、商场无法对坑更上一级。一层层往下蚕食权利、一层层往下分摊义务。在这种体系下，“互相体谅”是无用的、也是不值得被鼓励的。互相体谅就代表这沉默，就只能"一层层往下蚕食权利、一层层往下分摊义务"。这时候，学法律的优势体现出来了，至少在骂人的时候，说出“你这是违法”这几个字之后，对方得掂量一下是不是需要找自己的领导出来，免得背锅。

但无论基层的哪一环，大家都有怨言，去打车、去吃饭、出去玩，交谈间都是几句抱怨起手。好在还在夸政府政策好的傻子虽然还有，但已经不多了，随之而来的是：政府成了无法反抗的笑话，如碎玻璃一般。

后疫情时代 #4

超预测：预见未来的艺术和科学

这个周终于出了小区门，也是封控了80天之后，第一次迈出小区门。

虽然荒凉的街道有点惨淡，但终归是自由点的空气。

周二早上核酸的时候，在群里@了居委会主任，表示自己不会下去做核酸了。也告知了目前自己的精神状态很不稳定，所以不想继续做这些无意义的事情。尽管最后在邻居和楼长的劝说下，我和女朋友最后下去做了核酸，但是第一次，业主群里有大量的人参与了讨论。在以往，当我们抛出一些“反动”言论的时候，会迅速被一些团购信息覆盖。沉默的大多人仍旧沉默。也许是被汇贤居的反击所影响，再加上解封在望，大家有了参与讨论的动力。

虽然主任最后还是没有回复，一如既往。但还是在楼长的撮合下，当面和主任一起聊了一下。

虽然过程看起来友好，但从结果来看，我们并没有得到任何有用的信息以及任何承诺。当然这在意料之中。搞笑的是，反而像是我们在安慰主任，缓解身上的压力。特别是在主任说“昨天晚上开会到十二多点，今天需要领悟一天再传达给办公室的人”之后。

我们和这些人，好像生活在两个世界，过着不一样的生活。当然，并不是相看两不厌，而是互相觉得傻逼。

我们和邻居的关系熟悉起来，这也是除了做饭，这次新冠带给我们的唯二的好处之一。经常和邻居交流，甚至会凑到一起玩。

最后，我终于把《独裁者手册》看完了，这本书给了我另一个视角去理解当下发生在上海的事情。上海经济的严重失速，也许会加速这波荒诞闹剧的结束。这是一个两难的境地，虽然我的收入没有受到影响，但是其他人呢。

后疫情时代 #3


文章地址：[《中文大约的确已经死了》](https://mp.weixin.qq.com/s/GZKMemoSIDtKBKOI6orVsQ)

新冠（每次使用“疫情”这个词的时候，我都会有不适）流行之后，确实很多流行词开始变得看似搞笑但不再友善。在新冠之前，每年也会有流行词排行，但感觉当时的流行词明显比现在留存时间会很久，甚至某个流行词会流行一年。

这几天看视频，经常有人提到“老六”，我完全不知道意思是什么，也没有兴趣去查。这种层出不穷、快速更迭的新名词，我已经追不动了。

名词简单化，意味这其表达的表达的含义无法精确，必然引起滥用、冒犯等一系列问题。这个简单化的过程中，我们的忍耐阈值在不断升高。刚开始，一个稍有冒犯的词出来，我们可以忍受，然后这种冒犯不断升级，直到“小阳人”、“抓羊”这种词出来。大家已经没有太多的不适了，或者感觉稍有异议，然后选择接受。

有一个观点我有不同的看法。流行词的低龄化在我看来并不完全是自下而上，或者说并不是劣币驱逐良币，这个过程是有自上而下的因素的参与。官方的媒体也会逐渐使用这些词语，其实大大加速了某些词的普及过程。最重要的，当大家逐渐适应简单表达，思考就会逐渐消失，就会变得安全。

当然，在喜欢这些词的人眼里，我们可能只是旧时代的卫道者，守旧又刻板。

【速读】中文大约的确已经死了


公司最近要搞活动，需要做两个活动的官网用于宣称。在活动准备伊始，公司找了外包团队来做这件事，但是最后交付之后效果不满意，所以紧急找内部开发和设计想要重新开发。

呃，没错，我就是那个开发。以下是一些经验总结，非技术居多，希望能够帮助到大家。

网站使用的技术栈是：nextjs + tailwindcss + vercel。以下是整个过程中面对的问题。

## 技术

### 最快的方式部署

nextjs + vercel 部署很方便，完全不用额外的时间去设计CI / CD，这可以节省大量的时间，因为前端写 github action 诸如此类的配置文件，不小心就会跳进坑。如何快速部署是我们需要第一考量的。

### 响应式

需要从一开始就想好如何做移动端和PC端的兼容。用 tailwindcss 做出一套响应式的网站还是比较容易的，只要理解好 tailwindcss 里的断点使用就可以了。

### 处理好图片

我个人觉得图片是很难处理的一部分。无论是要求不同屏幕上的正常显示，还是响应速度，图片都很麻烦。

先把 png / jpg / svg 的区别与使用场景分清楚，特别是清晰度的问题。了解 picture、img、srcset、object-fit 这些概念之后，就能够很好的帮助到我们快速解决图片的问题。

实在不行，就用上 JS 大法。

### 中英文排版

页面的布局是一种排版，主要取决于设计师的考量。

中英文的呈现也是一种排版，好的排版会让页面显得高级，排版规则请参考：[中文文案排版指北](https://github.com/sparanoid/chinese-copywriting-guidelines)。

### 国际化

从一开始就要问清楚当下或者以后有没有做多语言的需求。现在很多库都能帮助开发方便的添加多语言，不会花费太多时间。但如果做到中途发现需要实现多语言，可能 Ctrl + C 和 Ctrl + V 就会被按烂。

### 关注过渡

好的交互细节能够极大的提升用户访问的体验，例如交互按钮的 hover 效果，页面的滚动效果，或者更复杂的效果。

### 注意 UI 细节之外的东西

作为活动，必定会在一些社交媒体分发，怎么保证在设计媒体最优显示，是非常值得注意的问题。例如，在 twitter 分享的时候，有一个加 twttier card 的东西，可以帮助别人浏览推文的时候，预览网页内容。为此，需要在网站的 head 里设置添加一些 meta 信息。

当然，最基本的，把一些基本的 SEO 问题处理一些，例如设置title 等meta，以及一些语义化标签。

### 无障碍访问和键盘导航

没什么好说的，我也不是很懂，学习中。

## 非技术

### 不需要的设计整理

例如，我们要做一个人物介绍的列表，大概有100个人，每个人最近基本的信息有：名字、介绍

图片。我们可能写了一个组件，我们只要把数据整理成数组，map / foreach 就可以。

我们绝大部分时间都是花在整理数据，其实完全可以交给运营或者设计来做，因为整理这些数据本来就是需要做的，ta 们完全可以顺手整理一份你想要的数据。当然，你或许想要一份 json 数据，但是运营 / 设计很难理解或者编辑这种数据结构。你可以用 ta 们熟悉的文本编辑方式，最后自己写个脚本做 format。

### 直接和运营沟通

在某种情况下或者项目前期的时候，可能不太会和运营产生直接的接触（都不一定）。个人感觉越早越好。

这种沟通是双向的，可以尽早的把网站部署在不重要的域名上，给相关人员预览，方便早期得到反馈。

## 售后服务

即使这个网站需要快速上线、即使这个网站可能只用几天，也不要在开发的时候偷懒，至少不要偷懒太多。尽量减少冗余的代码，尽量设计组件，虽然可能看起来很简单。

因为上线之后，运营人员根据一些内部或者外部的反馈，对网站进行调整，这些调整可能包含某些细微的设计更改，或者是推翻整个一大部分设计。如果此前偷懒了，就代表面对这些更改，你需要霰弹式更改，非常恶心。

编写你觉得正确的代码风格的代码，即使可能花费一些时间。



最后，祝大家切图愉快。


活动官网开发接锅指南


上海封城已经接近两个月了。

上海的居民就像温水里的青蛙，在慢慢被煮熟，我也已经半熟了。

最近，小区里热闹了不少，每天中午都有很多孩子在玩，前几天天气好，还搭建了很多帐篷，孩子们在这里玩的很开心。特别是阳光恣意的下午，到处都是遛弯的人们。正好也是竹子生长的时节，下午会有很多家长带着孩子在小区的竹林里挖竹笋。我好奇，家长们是如何向孩子解释现在上海的情况的，是带着理解还是带着愤怒。

但热闹了几天，上海又进入了静默期。

“静默期”，又是一个新的名词。新的名词不断涌现，口号不断标新立异，居民不需要思考、也不需要深入理解，只要简单重复就好。

小区的群已经被团购的信息充斥着，以往关于疫情的讨论逐渐消失，偶尔几句关于防控措施的抱怨，也在热心群众的口号中很快消逝散去。这里容不下不同的声音。

看样子，大家已经习惯生活着这个环境里了。

昨天在twitter上看到了童之伟教授的《对上海新冠防疫两措施的法律意见》。这是我看到的第一篇通过法律有理有据的反驳官方行为的文章。并且文中指出，很多其他的学者也对文章提了修改建议。突然对于当下的学者有了敬意。有骨气的学者在这样的特殊时期发声寥寥无几。何等让人绝望，毕竟 ta 们大多为人师表。

敬佩那些不断发声的人。对大部人来说，事情不落到自己的身上是无法共情的。但发声者，哪怕一点点声音，也可能唤起人性中残留的善良、勇气。

后疫情时代 #2

第三帝国的语言


最近的一周大多都是在放假的时间中度过的。因为时间比较多，内容也丰富一些。最有价值的一点：学习 K8s 的经历让我突然找到了某种学习节奏。

- 找了视频，认真学习了一下 K8s。虽然视频还没有完全看完，但是已经丰富了很多之前对 K8s 的理解。而且这次学习比以前好的部分是，我在一边看视频，也一边在实践。接下来需要了解的是 helm 和权限系统。
- 带家里的猫猫狗狗都下楼玩耍了。上海 lockdown 之后，我们平时遛狗也匆忙了很多，遛狗也越来越不耐心。趁着五一假期，带狗狗下去跑步，也给猫猫们拴了绳子，让她们在草地玩，虽然第一次下去遛弯的她们很谨慎，但是明显感觉能够自己触碰都自然的气息，她们也格外兴奋。
- 逐渐停用微信。通过朋友圈的方式把这个决定告诉了大家。随后我打开的微信次数逐渐下降了（虽然也没有降低我玩手机的频率）。到目前为止，通过 telegram 联系到我的人多一点，大概有七八个；iMessage 只有一个；而 email 一个也没有。这基本反应了我朋友圈真实的社交软件使用情况。我觉得 telegram 还是太小众了。也在继续寻找其他的可以替代微信的方案，而手机号目前是兜底方案。
- 继续看非技术书籍。在过去的一段时间里，我的输入基本停滞了，只是看了几本技术书籍。我从关注的几个twitter好友中获得了鼓励，重新开始看非技术的书籍，目前大多是社科类的。
- 开始玩 Switch Sports。这个游戏已经替代了分手厨房，成为了我们最喜欢的游戏。刚开始玩的一两天，玩到手臂第二天抬不起来，非常上瘾。分手厨房再也没有打开。虽然和真实的运动动作有差距，但是运动量并不少。目前最喜欢的运动是网球和击剑。
- 开始纠正自己的打字习惯。虽然每天写代码，但是我的打字习惯并不好，错字率很高。可能的原因：我的左手的键位还可以，但是右手的很差，特别是需要按标点符号的时候几乎需要挪动整个右手，导致效率很低且复位之后，可能按键位置不对，导致按错键。不知道有没有可以统计删除键使用场景的软件，可以帮助我优化按键习惯。

<b>接下来准备做</b>：

- 把第三帝国的语言读完。为什么选择这本书？当下中文语言的表达越来越标语化，这对语言的发展是非常不利的，但是缺非常利用宣传。希望能够识别出这些语言，并加以防范。
- 通过 K8s 部署 Ory。Ory 是一个开源的身份授权 / 认知服务，可以帮助我们在开始项目的时候，免于设计身份认证体系，提高效率。
- 继续优化自己的博客。接下来的注意的优化方向是交互。

最近做了什么 #1


今天 2022 年 4 月 24 号。

上次离开小区是 3 月的这个时候，那天小区解封了一天，下午自己一个人去山姆买了一大包狗粮以及熬粥和熬汤的的配料，当时很想学熬粥，就义无反顾的去了。现在想来，感谢那次阴差阳错的采购，让狗子得以在物资最短缺的时候不用担心粮食的问题。

封城还没有结束，我已经开始写"后疫情时代"了。我乐观的看来，疫情疫情逐渐好转，至少比刚刚开始的混乱无章好了很多。冰箱现在的东西很满了，不用担心吃喝问题，似乎只要等着解封就好。微信群里面对团购也不再是蜂拥而上，大家都有了自己稳定的购货渠道。例如我，很喜欢在楼下的小饭馆买些零碎的东西。小餐馆原本是卖冒菜的，现在成为了杂货铺。

但无论解封与否，解封得多快，封城所带来的精神创伤，已然无法抹去。

疫情刚开始的生活总是艰难的，每天早上六点闹钟抢菜，九点半被喇叭喊起来做核酸，十点半上班。作息被切碎，但还是只能把辛苦咽回肚子里，每天读书、上班、看英语。楼下不时响起喇叭通知大家下楼做核酸的声音。上次听到用喇叭喊人，还是在高中、穷乡僻壤的农村。

后来，核酸换成了抗原检测；很多渠道都能买到菜。但人的心理走向了两个方向，“被磨平”和“愤怒到无法抑制”，而我属于后者。论持久战，我可能是第一个疯掉的人。封城刚刚开始看的书被用来垫了电脑。

这种愤怒似乎也无法传递或者消解。和几个不在上海的朋友聊了些上海的现状。我在试图传达我的愤怒，但我没有得到我想要的结果。但反过来我又问自己：希望在这种交谈、吐槽中得到什么呢？是希望和我一样愤怒吗，还是希望得到怜悯。无论我最后希望得到什么，结果就是我什么都没有得到。网络将我们互相连接起来，但是信息也随着两端的距离，逐渐在被过滤、弱化。我的怒喊，可能得到的只是一个”嗯“。这种割裂感，几乎存在于我的每个交谈中。

在网络的世界里，我也厌倦了“资本”、“美帝主义”、“牺牲”、“秋后算账”这些词语。我甚至已经不在乎“清零”还是“共存”，我只在乎一个个“人”是否得到妥善对待，而这只是因为我一是个“人”。

如何保护自己，我也不知道。我问学法律的朋友：防疫人员如果想要强行带走我，我该如何运用法律的手段保护自己。ta委婉的表达：“特殊时期”。我在想，如果法律如果在特殊时期就可以随意逾越，那平时也是可以随意逾越的。因为特殊时期的定义，也不在民众手里。

在这种焦虑、恐慌中，我就会问自己：我在做什么、我做了什么。我试图写几行代码，优化某个流程，让大家更快的找到能够帮助自己的人。我试图写几行代码，让大家更快的集结起来，共渡难关。

但，确实这几行代码没有改变现实的能力，戴着镣铐跳舞罢了。

放下键盘，走出去，去摸一摸具体人，脚踩着的土地。

后疫情时代 #1


作为一个JetBrains的死忠粉，终于在下午WebStorm卡死、晚上IDEA还让我买license之后，心态发生了变化。

<img width="800" alt="image" src="https://user-images.githubusercontent.com/19925717/162787484-924cf251-f146-42ae-b2a4-089630782dfe.png">

思来想去，决定先用neovim试一试，毕竟有一点vim的底子（在JetBrains里用vim，别骂了），也很喜欢vim，也希望能够尽量摆脱鼠标。而且VSCode的快捷键总感觉没有那么爽。

安装的过程就不必细说了，主要是起手的配置麻烦，这个问题我想了很久。开始的时候，我在思考要不要自己从零开始搞一套配置出来，且直接全套lua接管，但是后来就发现这个想法太天真了。lua的语法需要熟悉一下、也完全不知道哪些插件好用，而且neovim的文档让我多少也有些困惑。也就是说，我对整个生态几乎是完全陌生的，于是我果断放弃了。

马上找现成的配置。于是我在YouTube上看到了这个视频：[Better Neovim plugin setup! Use Packer, break your init.lua into modules, look like a hero! - YouTube](https://www.youtube.com/watch?v=NkfMBI1tVwY&ab_channel=BenFrain) 整体来说毕竟符合我的审美（颜值即正义），赶紧去看了一下博主的GitHub，直接clone到本地，等我再次启动nvim，已经大不同了。

我觉得这个配置文件，可能就是我的lua启蒙代码了。我改过的代码在[这里](https://github.com/NikoManiac/nvim)，主要是在原来的基础上，加了`rust-analyzer`。同时标注了原来的Github Repo，辛苦大家去给原Repo个Star。

后面会继续折腾继续更新（如果没被玩死）。


从JetBrains搬家到Nvim


# 2021小结

按照农历的新年去总结过去的一年挺好的：有充足的假期，也不会和大家密密麻麻的总结撞车。

2021年有新的家庭成员加入：甜酒——一只不太聪明的拉布拉多。去见他的那天晚上出发之前，小徐和我说无论这只狗狗我们多么喜欢，我们都不能直接把他带回来，要回来考虑一下。结果去和他遛了一圈，小徐就一直在诱导我说把他带回家。这样家里有两只猫两只狗，看起来达到了某种平衡，但甜酒后来调皮捣蛋，两只猫脾气太好，家里的不平衡并没有扭转过来。甜酒来到家里一两天后就开始又吐又拉，送到医院被诊断为细小。最后经过一个周的住院治疗，抢救了过来。我们养宠物的过程都不是很顺利，kuang当时也是遇到了猫传腹。希望这些小动物们能够健康的成长。甜酒经过半年多，现在已经60多斤，身材开起来比较健硕，但是很粘人，小时候的小可爱变成了现在人见人烦。如果用一个词来形容和他们的相处：痛并快乐着。

还有一件大事：我爸妈和小徐的爸妈在湖南见了面，在小徐的精心安排下，过程还是比较顺利。小徐和她的爸妈都考虑比较周到，很照顾我们的感受。我其实很担心这次见面，担心我爸妈不习惯，也担心出什么意外，双方都不满意。圆满的结果就把问题抛给了接下来这次见面，小徐的爸妈应该还会去我们家，该怎么搞，我现在还没有头绪。我生在农村，所在的县城也没去过几次，哪里好玩哪里有坑，说是家乡，其实我是不了解的。我越来越意识到，自己没有目前还没有能力去组织好这些事情，最重要的，自己的比较懒，不愿意去想这些事情。这两个原因的先后顺序、因果关系无论哪个放在前面都可以。从大学开始就一直在外面，过年回去发现，我能熟悉的也就是那些山，那些小路。出去走亲戚串门儿的时候，我还特意走一些不常走的小路，看看自己的记忆是否正确，也看看小路是否有变化。

小徐的存在，让我和爸妈试着交流，也越来越有耐心交流。虽然已经27，但这方面我还很不成熟，当然我也不希望成熟。

年中的时候，我离开了TW。毕业后的三年里，我一直在TW工作，我对技术、社会、工作的认知，都在其影响下逐渐形成的。我无论什么时候想起这些，都会觉得这对我很重要。离开TW的原因可能就是因为在同一个公司待得太久了，想换个环境，而且工资的涨幅也一直不尽如人意（并不是抱怨，而是优秀的同事太多），再加上上半年在做国内的项目，略卷，就想离开了。

新的公司是区块链行业，对我来说几乎是陌生的领域。第一次听说区块链还是18年在百度实习的时候。公司有人讲session，介绍百度的区块链布局，后来还抢了百度的加密狗（类似加密猫，现在的NFT）。即使当时接触了，但是后面也没有深入了解。后来我有反省这件事：区块链确实超出了我的认知范围，我无法理解其意义，而且当时还在忙于校招，就这样错过了。我越来越确信，普通人只能赚认知之内的钱。

换了公司之后，才开始真正的意识到有工作和生活的界限感是多么的重要。新的公司需要加班的时间比较多，虽然有加班费，但是频繁的加班其实在模糊工作和生活的界限。这些是有了对比之后才有了更多的感触。

而且当我逃离的原来的舒适区、去面对困难的时候，才能更清楚的认清我是一个什么样的人，有什么优点，又有什么缺点。

我的读书在下半年几乎停滞了。爆炸般的网络信息试图代替书籍，成为新的输源入，但并没有成功。我其实一直没有很好的读书习惯。但遇到问题的时候，我却很希望通过读书去找到答案，这个事情其实很奇怪，但是又很常见。读书不是唯一的途径，只要我们有一定的整合能力，去快速的了解某件事甚至某个行业，都是不困难的。但这个能力我明显是欠缺的。

与此同时，我一直在思考自己和质疑自己之间不断徘徊。在TW的时候，我就觉得自己不是优秀的那一队，新的公司也是如此。有一点不自信，也有一点的思考：我的优势在哪里。而且在区块链行业，焦虑是难免的。一夜暴富的故事对人的影响总比一夜崩塌的故事更印象深刻，而币圈最不缺的就是一夜暴富的故事。这种焦虑给我带来的影响和冲击直到现在还是很大，我正在逐渐适应，也在慢慢调整。

有个很有意思的转变，我越来越关心个人了，这个“个人”可能是我自己，也可能是和我毫不相干的某个个体。好像似乎从小就被灌输了一种宏大的视角：关系国家，关心民族，关心世界。“我”作为一个很小的个体，总是被忽略。这些感触源于和一个朋友的讨论，大概话题是：电信诈骗的亲人受到政府不公平对待该怎么办。朋友支持“连坐”，这在我看来不可思议的观点中，引申出另外一个问题：我和朋友的认知/观点不可避免的逐渐走向岔路。

有一个思考一直都没有停止，可能需要思考下去：我以后该做些什么。

2022年，希望能够把区块链这个行业摸清楚且有自己的项目，还要看看/准备出国读书的事情。书也多读读，20本左右吧。

2021小结


我和小徐搬家了。搬到了浦东，住进了大一点的房子。

去年这个时候匆匆离开北京，到现在一年了。其实并没有很多离开北京的理由。相反，在北京有很多朋友，租的房子也舒适。但大概当时想：在北京呆了两三年，也是时候离开了。我就是这样，在一个地方呆久了就会厌倦、麻木，于是逼迫着自己离开。我不厌倦搬家的繁杂劳累，永远都是期待着。

但上海的一年是艰难适应的过程。新的城市环境，新的朋友。在北京的左家庄，好像毫不费力的就认识了好多人：留在的五金店老板，她还帮我们找到了第二套租的房子；隔壁楼一直喂养流浪猫的阿姨，还有热心帮我们找猫的京东小哥。好多人都是那么偶然认识的。

上海的面很好吃，来上海的一个周每天都在吃面，或者说几乎每顿都在吃面。我住在中山公园附近的酒店里，附近的小街小店也很多，我每顿吃不同种类的面，恣意品尝。记得最好吃的是葱油拌面，后来发现葱油拌面的浇头是万能的。

一个月前，狗子开始找到了新的玩伴朋友。周五晚上带着他去公园，打三四个小时的架，然后回家睡个好觉。因为狗子在家里实在跑不开了，所以为了找大房子，从新华路搬到了浦东，开始还有点失落，但是住下来好像还不错。

在一个月前，还在犹豫要不要离开上海，我喜欢上海，最后有机会应该还会回到这里，所以趁早可以出去溜达一圈。

我喜欢上海。

<b>注： 本文过期于2022.4</b>



搬家，在上海（已过期）


# Gitflow

Gitflow 由 [Vincent Driessen](http://nvie.com/posts/a-successful-git-branching-model/) 在 2010 提出。Gitflow 有着严格的流程：只有2个主干分支，Master 和Develop 分支：Master 分支上只有稳定的生产版本，Develop 分支用于集成。而其他还有三类辅助性质的分支：Feature 分支用于开发人员各自开发；Release 用于代码合并和集成；Hotfix 用于产品版本代码的紧急修复。

![gitflow-all.png](/assets/blog/images/git-workflow/gitflow-all.png)

## 主要分支 The main branches
- Master 分支
- Develop 分支

![gitflow-main.png](/assets/blog/images/git-workflow/gitflow-main.png)

当 Develop 分支中的源代码达到稳定状态并准备发布时，所有的修改应该以某种方式合并回 Master中，然后打 tag。具体如何做，在后面进一步讨论。

因此，每次当变化被合并回主版本时，根据定义，就是一个新的生产版本。在这一点上往往非常严格，所以理论上，我们可以使用 Git 钩子脚本，在每次主版有提交时，自动构建并将软件发布到生产服务器上。

## 次要（辅助）分支 Supporting branches

- Feature branches
- Release branches
- Hotfix branches

**Feature 分支**

- 从 `develop` 分支拉出来
- 完成开发完，合并回 `develop`
- 分支命名比较随意，语义化即可 `release-*`, or `hotfix-*`

**Release 分支**

Release 分支支持新生产版本的准备工作，允许进行小的错误修复，并为发行版准备元数据（版本号、构建日期等）

通过在Release分支上做这些工作，Develop 分支就可以开发下一个大版本的功能。

- 从 `develop` 分支拉出来
- 完成开发完，合并回 `develop` 和 `master`
- 分支命名应该为: `release-*`

**Hotfix 分支**

生产版本有存在bug的时候，从 Master 上建立 Hotfix 分支，团队成员（在 Develop 分支上）的工作可以继续，而另一个人则在准备快速的生产修复。

- 从 `master` 分支拉出来
- 完成开发完，合并回 `develop` 和 `master`
- 分支命名应该为: `hotfix-*`

![gitflow-hotfix.png](/assets/blog/images/git-workflow/gitflow-hotfix.png)

## 问题：

- Hotfix 分支和 Release 分支引入了复杂性，例如 Release branches 和 Hotfix branches 都需要同时 merge 到 Master 和 Develop，容易忘记（对比我们的 Release 分支）。
- 在实际的需求中，它比想象的更复杂，以至于开发了一个大的脚本来帮助严格执行这个流程。[https://github.com/nvie/gitflow](https://github.com/nvie/gitflow)
- 分支周期很长，合并困难，影响持续集成。
- 持续交付降低甚至消除了对 Hotfix 和 Release 分支的需求。

ThoughtWorks 也一直在抨击 GitFlow 模型:

- 2011停用feature分支： [https://www.thoughtworks.com/radar/techniques/feature-branching](https://www.thoughtworks.com/radar/techniques/feature-branching)
- 2015停用长时分支：[https://www.thoughtworks.com/radar/techniques/long-lived-branches-with-gitflow](https://www.thoughtworks.com/radar/techniques/long-lived-branches-with-gitflow)
- 2016停用GitFlow：[https://www.thoughtworks.com/radar/techniques/gitflow](https://www.thoughtworks.com/radar/techniques/gitflow)



作者在最近，在这篇文章上加上了note（具体见博客）：

> Git开发的最流行的软件类型也更多地转向了Web应用。网络应用通常是持续交付的，而不是回滚的，而且你不必支持软件的多个版本在运行。这不是我10年前写博文时想到的那一类软件。如果你的团队正在做软件的持续交付，我会建议采用更简单的工作流程（比如GitHub flow），而不是试图将git-flow塞进你的团队。
> 

# GithubFlow

发布于[https://scottchacon.com/2011/08/31/github-flow.html](https://scottchacon.com/2011/08/31/github-flow.html) 。GitHub Flow 推荐只有一个主分支 master，团队成员们的分支代码通过 Pull Request 来合并到 master 上。

![github-flow.png](/assets/blog/images/git-workflow/github-flow.png)

**原则（Copy from [https://scottchacon.com/2011/08/31/github-flow.html](https://scottchacon.com/2011/08/31/github-flow.html) ）：**

- Anything in the `master` branch is deployable
- To work on something new, create a descriptively named branch off of `master` (ie: `new-oauth2-scopes`)
- Commit to that branch locally and regularly push your work to the same named branch on the server
- When you need feedback(这个如何做到) or help, or you think the branch is ready for merging, open a [pull request](http://help.github.com/send-pull-requests/)
- After someone else has reviewed and signed off on the feature, you can merge it into master
- Once it is merged and pushed to ‘master’, you can and *should* deploy immediately

这里需要注意第六条后面的说明：

Finally, your work is done and merged into the `master` branch. This means that even if you don’t deploy it now, people will base new work off of it and the next deploy, which will likely happen in a few hours, will push it out. So since you really don’t want someone else to push something that you wrote that breaks things, people tend to make sure that it really is stable when it’s merged and people also tend to push their own changes.

最后，你的工作完成了，并合并到主分支中。这意味着即使你现在不部署它，人们也会以它为基础进行新的工作，而下一次部署，很可能会在几个小时后进行，会把它推送出去。所以，由于你真的不希望别人推送你写的东西破坏了一些东西，所以其他人在合并的时候往往会确保它真的是稳定的，其他人也往往会（介于这个PR）推送自己的修改。

// 这里可以看出，Github Flow针对的（理想）场景是每天可能发布数次。

## 步骤（Copy from Github）：

[Create a branch](https://help.github.com/en/articles/creating-and-deleting-branches-within-your-repository) from the repository.[Create](https://help.github.com/en/articles/creating-new-files), [edit](https://help.github.com/en/articles/editing-files), [rename](https://help.github.com/en/articles/renaming-a-file), [move](https://help.github.com/en/articles/moving-a-file-to-a-new-location), or [delete](https://help.github.com/en/articles/deleting-files) files.[Send a pull request](https://help.github.com/en/articles/creating-a-pull-request) from your branch with your proposed changes to kick off a discussion.Make changes on your branch as needed. Your pull request will update automatically.[Merge the pull request](https://help.github.com/en/articles/merging-a-pull-request) once the branch is ready to be merged.[Tidy up](https://help.github.com/en/articles/deleting-unused-branches) your branches using the delete button in the pull request or on the branches page.

> 可以看一下官方的介绍：https://guides.github.com/introduction/flow/ 带一点动画

## 优势：

- 干净整洁容易理解。
- 真正意义上的控制代码的合并。
- 及时的发现代码中存在的问题。
- 通过issue进行问题追踪。可以通过tag对问题进行分类。
- 分支的周期很短。

## 存在的问题：

- 没有解决不同环境的问题, 没有解决开发节奏和交付节奏不一致的问题。
- 不是很适合web service。
- 基础设施要求高。
- 到达理想状态很遥远。

# GitLab Flow

GitLab flow 是 GitLab 官方推荐的分支管理策略，他吸收了 Git flow 和 Github flow 的优点。Gitlab flow 的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支 master，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他（出了 feature 分支以外）分支。

[https://docs.gitlab.com/ee/topics/gitlab_flow.html#git-flow-and-its-problems](https://docs.gitlab.com/ee/topics/gitlab_flow.html#git-flow-and-its-problems)

## 延迟发布-Production分支

控制发布时间

![gitlab-flow-1.png](/assets/blog/images/git-workflow/gitlab-flow-1.png)

## Environment分支

解决不同环境的问题

![gitlab-flow-2.png](/assets/blog/images/git-workflow/gitlab-flow-2.png)

## Release分支

如果代码不是部署到某个环境，而是需要对外发布，则可以使用release分支。

![gitlab-flow-3.png](/assets/blog/images/git-workflow/gitlab-flow-3.png)

我的理解是这三种分支策略可以视情况选择。

## 问题：

- Hotfix怎么办 - 官方文档没有说明

# Trunk-Based Development

创作者：Paul Hammant

[https://paulhammant.com/2013/04/05/what-is-trunk-based-development/](https://paulhammant.com/2013/04/05/what-is-trunk-based-development/) 

`trunk`是SVN中主干分支的名称，对应Git中则是`master`分支。

![trunk-base.png](/assets/blog/images/git-workflow/trunk-base.png)

如果需要发布，可以基于主干发布（利用tag）作为发布的版本，如果满足不了需求，则从主干分支创建发布分支。

如果需要修复bug，按照主干开发的最佳实践应该是在主干分支上重现 bug，并在主干分支修复和测试，通过持续集成再 cherry-pick 到发布分支，等待发布分支的持续集成再一步验证，在进入生产环境。

## 适合与不适合

- 比较需要 Senior developers，不太适合团队成员大部分都是 Junior developers

## Q&A：

**和Github Flow的不同：**

1. 主干开发仍有细微差别主要区别在从何进行发布。Github flow存在一点小问题：可以从分支直接发布，但是这个分支上可能落后了几个commit，导致一些功能缺失

![trunk-base-merge.png](/assets/blog/images/git-workflow/trunk-base-merge.png)

![trunk-base-release.png](/assets/blog/images/git-workflow/trunk-base-release.png)



**和Gitlab Flow的不同**

1. 分支策略更为严格？

feature没有开发完，要release怎么办：

- feature toggle
- Branch by Abstraction

## 问题：

- 开源项目采用什么策略【还没看】
    - Github flow更适合开源项目
- 各种分支策略在团队规模不同上的差别
- 我们平时关注的是Web开发，其他的类型的开发采用的策略是什么，如：
    - Data项目
    - 移动开发
    - lib
    - 产品的开发
- 发展的趋势来看，我们总体在关注哪些方面
    - 在实际应用中的复杂度 ➡️简单
    - 分支的生命周期long ➡️short-lived

# 参考文章：

- [http://www.brofive.org/?p=2165](http://www.brofive.org/?p=2165)
- [https://scottchacon.com/2011/08/31/github-flow.html](https://scottchacon.com/2011/08/31/github-flow.html)
- [https://guides.github.com/introduction/flow/](https://guides.github.com/introduction/flow/)
- [https://nvie.com/posts/a-successful-git-branching-model/](https://nvie.com/posts/a-successful-git-branching-model/)
- "Branch by Abstraction" [https://martinfowler.com/bliki/BranchByAbstraction.html](https://martinfowler.com/bliki/BranchByAbstraction.html)
- [https://cn.trunkbaseddevelopment.com/branch-for-release/](https://cn.trunkbaseddevelopment.com/branch-for-release/)
- [https://drprincess.github.io/2017/12/26/Git%E4%B8%89%E5%A4%A7%E7%89%B9%E8%89%B2%E4%B9%8BWorkFlow(%E5%B7%A5%E4%BD%9C%E6%B5%81)/](https://drprincess.github.io/2017/12/26/Git%E4%B8%89%E5%A4%A7%E7%89%B9%E8%89%B2%E4%B9%8BWorkFlow(%E5%B7%A5%E4%BD%9C%E6%B5%81)/)

Git WorkFlow 演变总结

## GatsbyJS VS NextJS

- 如果只是构建简单的静态页面，可以考虑Gatsby，例如静态的官网、博客等。
- 如果涉及到用户状态，则可以选用NextJS。

## 介绍

Gatsby文档： [https://www.GatsbyJS.com/docs/](https://www.GatsbyJS.com/docs/)
Strapi文档： [https://strapi.io/resource-center](https://strapi.io/resource-center)

GatsbyJS是基于React的前端框架，基于其配置约定，我们就可以快速开发出纯静态网站。其本身有丰富的插件系统，例如SEO、从CMS拉取数据、直接把Markdown文件编译成页面等。
同时也提供了CLI工具([https://www.GatsbyJS.com/docs/reference/gatsby-cli/#build](https://www.GatsbyJS.com/docs/reference/gatsby-cli/#build))，能够帮助构建网站。

### 架构图

以下架构图是基于GatsbyJS + Strapi的一种静态网站架构实现：

![架构图](/assets/blog/images/gatsbyjs-website-architecture.png)

## 本地开发流程

1.	先在本地运行strapi，设计并创建整个系统需要的content type（即数据模型），并将代码部署到dev环境。这一步并没有开发工作量。因为创建content type是在本地 strapi admin控制页面进行的可视化操作，strapi会根据开发人员设置自动生成代码并对本地代码库进行更改。但是如有需要，我们也可以手动更改代码，例如调整数据模型细节/路由、对strapi admin ui进行定制化开发。
2.	部署成功后，在strapi dev环境填充所需要的数据（类似于在数据库table上添加数据），同时配置访问权限。
3.	本地gatsby开发是依赖strapi dev环境数据的，所以strapi一定要先部署。为使得gatsby能够拉取strapi的数据，需要安装gatsby插件：gatsby-source-strapi。详情可见文档：[https://strapi.io/documentation/developer-docs/latest/developer-resources/content-api/integrations/gatsby.html#create-a-gatsby-app](notion://www.notion.so/laanfor4/%E6%96%87%E6%A1%A3)，该插件能够在本地开发或者构建的时候，从strapi 拉取数据，并转换成graphql能够理解的数据格式，方便gatsby获取。注意：执行gatsby develop后，会把数据一次性拉取到本地，如有CMS数据变化，需要重新执行gatsby develop 。

## 部署

对于strapi来说，可以一次打包，到处使用。
但是对与构建时依赖CMS数据的gatsby来说，是无法做到一次打包，到处使用的。不同环境的数据是不相同的。所以不同环境，gatsby要单独打包。
对于dockerfile，strapi和gatsby都有官方推荐的dockerfile，如果没有特殊的需求，可以直接使用。

### 媒体文件处理

strapi支持上传文件，如果没有特殊处理，会默认上传到strapi服务所在的目录。
但是strapi有第三方插件可以支持将文件上传到AWS、阿里云等Object storage服务。例如：strapi-provider-upload-aws-s3

### 性能优化

如果大量的页面需要构建，例如上百条博客文章，可以使用gatsby提供的增量构建方案。[https://www.GatsbyJS.com/docs/reference/release-notes/v3.0/#incremental-builds-in-oss](https://www.GatsbyJS.com/docs/reference/release-notes/v3.0/#incremental-builds-in-oss)

## 问题

### 面向运营人员

strapi面向运营人员需要进行优化：

1.	左侧导航栏中的content type中的名字，对于运营人员来说很难理解其代表的含义。这就需要更改strapi的代码，自定义其i18n文件。（需要在本地进行开发）。
2.	为了方便理解content type中的每一个属性的含义，我们可以在config the view中定义每一个field的中文名。（无需开发，可在线上进行配置）。

![Strapi截图](/assets/blog/images/strapi-snapshot.png)

### 面向运营人员的网站部署

使用wordpress类似的CMS网站，因为页面是动态渲染的，所以用户只需要保存数据，再次访问网站即可看到更新。
但是gatsby构建的网站是纯静态页面，不会进行动态渲染，所以就会涉及到两个问题：

1.	如何把变更发布到网站
2.	如何进行预览

### 变更发布到网站

目前的设计中，整个网站的发布通过pipeline进行的。所以最粗暴的方式就是在strapi admin控制页面提供一个部署按钮，当用户点击的时候，可以触发pipeline。
这里谈到的pipeline可以单独设计，而不必使用和开发阶段一样的pipeline。
### 如何进行预览
无法动态渲染，就没有办法进行即时预览的。
目前折中的方案是提供一个预览环境，其使用的数据是生产环境数据。当用户修改数据后，可以先发布到预览环境。确认无误之后，再点击发布到生产。

### 注意：

涉及到发布部署，Pipeline构建需要时间。这个时间取决于pipeline的速度。所以要尽可能的进行优化。例如前端增量构建，前端node_modules缓存等。
除此之外的隐患就是，一旦构建失败，运营人员是无法解决的，因为大概率是Pipeline的问题，这时候就需要开发人员介入。

### 不同环境数据同步

strapi有相关的插件，目前还没有尝试。

### strapi镜像过大

目前的方案中，strapi打包过后的镜像在1G左右，暂时还没有找到优化方案。


GatsbyJS + Strapi静态网站架构


Clubhouse因为马斯克的Room而开始火爆全球，当下邀请码更是一码难求。

Clubhouse创建于2020年4月，主打语音聊天，趁着新冠病毒蔓延，在疫情中平稳发展，直到前两天马斯克的加入，引爆了国内外社交平台。这一周ClubHouse的讨论热度直线上升。原本偏向投资、产品的圈层，如今出圈了。

这种模式在以往的产品中并不少见，例如YY语音。但是为什么Clubhouse火爆了起来。我会试图从我几次使用体验来说一下感受。

首先在Clubhouse交朋友是一件很轻松的事情，我们可以把语音视为介于文本和视频中间的媒介，它比文本更直观、比视频更有安全感。几句闲聊就可以“认识”（姑且称为认识）全世界的朋友，因为隔着屏幕、因为语音，用户更为放得开。有了第一次发言之后，后面几乎没有心理障碍。

在Clubhouse也没有社交压力。我可以随便进某一个Room，可以选择一直旁听，主持人可以邀请，但你也有拒绝的权利。可以随时离开，各个Room“偷窥”。我们可以去直接倾听各个行业的大佬侃侃而谈，也可以举手发言。在这种低社交压力中，讨论和意见吸收是更容易进行的。

其次话题广泛而随意，适合闲逛。ClubHouse的首页会显示我能看到的Room。这个Room列表的显示取决于我关注的人正在哪些房间，这很容易提高关联用户之间的熟悉度。我可以在这些话题中任意寻找自己感兴趣的话题，这种操作好像类似于逛街，在不同的店里试衣服。而且当我在不同的Room里看到相同的人的时候，“陌生到认识”就是很自然的过程

假设用ClubHouse来传递知识。这样知识的传递更高效，但是无法沉淀。马斯克参与的讨论，让普通人里马斯克这种大佬更近了，能够更直接的获取他的一些观点，知识传递的层级少了。但是相比较于播客类似的音频节目，它无法保留，也就无法沉淀。

最后，就是目前的Clubhouse很纯粹，只是单纯做语音社交这一件事情。可以预见国内可能会有大厂跟风做类似的产品，但是很可能是在现有的产品上做加法。这就很难做到纯粹，用户的安全感可能就不会那么强。而安全感是我自身特别在意的体验。

Clubhouse本身用到的语音技术并不复杂，但是做到全球的语音聊天而延迟很低，优化的非常不错。邀请码也是一个很好的运营手段，邀请码一码难求，颇有小米饥饿营销的味道。当很多人在各个平台寻找邀请码的时候，就是一种很好的宣传，也会引起“路人”的兴趣，例如我。

除此之外，我也有一些疑问：例如Clubhouse的盈利点在哪里。

Clubhouse体验

最近热播的韩剧《棒球大联盟》讲述了职棒球队Dreams在连续四年垫底之后，队内矛盾爆发。新任团长白承洙以出人意料但强硬的方式开始对俱乐部进行剥丝抽茧的改革，因触动球队各方利益而频频遇到阻碍。在与各种阻碍的对抗中，导演还原了球队经营的全貌。

“在棒球社的工作，就相当于公务员。”故事一开始就直白的讲述了背景与起因。

![tv-stove-league.png](/assets/blog/images/tv-stove-league.png)

棒球大联盟》整体剧情平稳，并没有通过酝酿很久的高潮来获取观众的好感。反而按照球队真实的休赛期的调整节奏来讲述故事，每一两集都会通过当下的球队任务，来解决球队中存在的问题：明星球员林东奎过于强势影响了球队的氛围，因此团长选择交易；寻找潜力股的选秀制度，因为有暗地交易导致选到的新秀都不出众；高层的资金压力导致降薪，使得薪资协商困难、异地训练没有如期举行。问题的解决没有很大的跳跃点，都是对夺冠基础条件的累积。

因为这样稳健扎实的叙事节奏，《棒球大联盟》给我们提供了更高的视角去关注俱乐部经营，从中也能窥探一些球队管理的内幕。从各利益方（球员、棒球社管理人员、出资的母公司、舆论媒体等等）的对抗中，我们能够清晰的感受到，改革在这样传统的球队中的步履维艰。

首先是球员和管理层的对抗。球队核心林东奎过高的话语权，使球队的资源并不平衡，压制了球员的发挥和削减了教练的权威，但即使如此，球队的管理人员几乎没有人同意送走在这里扎根的林东奎。固守成规的棒球社运营人员在消耗林东奎的价值，而林东奎也在享受地位超然带来的优越感。而管理层掌握了球员的放逐、薪资，也在某种程度上制约着球员。当意欲改革的新任团长白承洙出现的时候，便自然而然的受到了全面的抵制。

棒球社与媒体之间的斡旋，也贯穿了始终。电视剧中频频出现的球员或者球队工作人员利用媒体争取自己的利益，像极了NBA管理层的套路。通过媒体透露消息，帮助自己把利益最大化。而反方面，在媒体引领的舆论面前，球队的各方面往往要做出妥协。

全剧偏向球队的运营描述，而球队之间的对抗，在本剧中并没有着笔墨去表达，仅仅有过几次短暂的冲突。但是我们能够能从几个团长反复“算计”后，又能坐下来互诉利益，看得出棒球社的经营的准则不是人情面子，是利益，这也是棒球社能够健康成长的基石。

当所有的对抗趋于平衡的时候，棒球社与母公司因利益不同而产生的最大的对抗最终被拿到了台前。常务权庆民对球队的百般刁难并不是无厘头的，从人情世故的角度出发，他需要的员工做需要“听话”、“讲礼貌”。从利益的角度看，他需要的员工需要考虑如何解决棒球社的“赤字”问题。在权庆民的自有的价值观与逻辑体系中，白承洙这两点做的都不好，所以常务便有正当理由来制裁团长白承洙。白承洙因为看透球队问题的本质是缺乏透明公正，所以试图在利益与球队感情之间取得平衡。最好的例子便是棒球队营销组组长林美善曾充满热情，但是随着持续的失败和压力之下，也学会人情世故的逻辑，又因团长白承洙的改革，燃起了心中的热情。

说到底，就是人情世故和逻辑主义的对抗。

当观众对权庆民咬牙切齿的时候，其实他也在从另一方面觉醒。这就给了《棒球大联盟》更深层的主题——守护。

但是我们也能感受到，这里所有的对抗都不是绝对的，是能够相互转化实现共赢的，而这就依仗团长白承洙的智慧与魅力。

因为能把这些针锋相对的对抗妥善处理，所以《棒球大联盟》对观众，特别是球迷观众来说，应该算得上是另一种“爽剧”，这也是我作为篮球迷真实的体验。整个故事的圆满结尾，给当下发生的某些球类运动的改革提供了理想的改革模板：要遵守原则，追求公正，尽量摆脱人情世故，绝对的理智以及双赢的交易。不过，就像玄幻小说中顶着无敌光环的主角一样，白承洙这个完美的经理人在现实生活中难以找到，但是在这部电视剧里我们可以不通人情世故，以绝对的逻辑就生存下去，在想象中提前庆祝自己的主队因为有了体系的提高与改革而成功夺冠。

拉回现实，但是故事的结局还是有隐喻，母公司的成功重组以及球队的解散重建，延伸下去就是人情世故和逻辑主义的对抗是无解的。也许这不过是描述了俱乐部的一个瞬间，而这个瞬间可能是被重复的第n次。

枪炮、病菌与键盘

Home

Posts

Books

RSS