一些设计原则

一些设计原则

小红书发布的 52 个设计原则，涉及很多用户心理 和 视觉心理 的内容，值得多看几遍，去思考各个产品设计是不是符合一些原则 52个设计原则 列举一些理论或效应： 把结论放在前面 => 倒金字塔结构 一图胜千言 => 图优效应 自己参与的事情会被认为价值更高 => 宜家效应 被期望成什么样的，会慢慢真的变成什么样 => 皮格马利翁效应 经过深度分析的信息会比简单

设计原则 设计 原则
什么是增量写作

什么是增量写作

增量写作的主要场景是： 当你在思考一些主题的时候，你可以先写一部分，然后定一个周期，一段时间之后再重新去思考同一个问题。 这样就可以在之前的基础上前行，而不是在一个怪圈里转。你也可以在每次思考一个问题时，扩展一些新的思考方面，然后简单写点片段，并扔到队列里，等到之后再来填这个坑。学习知识，追求的就是 螺旋式进步 ，而 增量写作，就完美契合了这个过程。 当我们用增量写作的方式去做 主题学习 时，一

syncthing的方案及安装记录
解决ob的图床问题

解决ob的图床问题

背景如 解决ob的发布问题 中所描述的，我有很强的发布需求，在发布过程中，经常遇到这样的问题： 图片数量多了后，压缩、打包、发布的速度就降下去了 [强诉求] 不同的电脑间，文件同步变成了一个比较麻烦的事 [弱诉求] 分享一篇文档时，本地图片地址无法查看 [中等诉求] 于是就开始思考这个问题 : 如何解决 blog 的 图片/视频 等静态资源问题? 方案实际是很成熟的 : 使用图床。 实际上，

ob的使用问题
ob文件同步方案

ob文件同步方案

ob 是基于本地存储的 md 编辑器 及 知识管理软件。 由于其文件存储在本地，当我们有 2 台以上的终端设备时，就希望某一台终端上的修改能够及时同步到其他终端。此时，就有文件同步的需求了。 我有两台 mac ，一台在公司，一台在家里，我希望两台的内容能够同步，这样，在公司(jia)里没写完的内容，回到家 ( gongsi ) 还能接着写。 方案有如下几个： 官方提供的 sync 服务 远程硬盘

ob syncthing 文件同步
解决ob的发布问题
grpc在k8s中的负载均衡问题
关于基于接口定义的开发流

关于基于接口定义的开发流

背景之前做前端开发，需要依赖后端同学的接口文档，涉及到一些老接口的时候，经常出现接口信息疏于维护的情况，然后找这个找那个的，依然很难做到让接口信息完整，当时就在想，为什么不再要修改一个接口的时候，把接口文档顺便维护了呢？心中甚是鄙夷。 后来做后端开发，经常出现一些要求快速完成进行联调的情况，更甚至有临时改变一些功能的情况，自己可能顺手就加上了，然后上到测试环境让前端同学调一下，然后……就没有然后了

grpc openapi go-kratos develop go-zero
记一次k3s环境搭建记录

记一次k3s环境搭建记录

背景生产环境中，我们很早在使用 k8s 作为基础设施了，后来，企业项目要做私有化部署，就把目光转向 k3s 了。k3s 是一个轻量级的 k8s，几乎实现了所有 k8s 的特性，除了一些边缘的场景，基本可以把 k3s 当做 k8s 去使用。 一些备选方案早期部署 k8s 环境是十分繁杂的，各个组件都是二进制方式部署，如果遇到问题，排查起来需要的预备知识非常多，因此，大部分企业在使用 k8s 时，都是

k8s enviroment k3s develop