@GooMS 嗯，现在确实是有自动上传数据的血压计。但想到图片这种方式，看看有没有办法能实现出来。

@doudou1523102 # 48 我水平有限，还没具备指导他人的能力哈。

分享一个我自己的： https://www.linnana.me/2023/09/20/Life-how_to_lose_wegiht 。

快走 + 改善饮食结构，关键是得找到一个路径让自己容易坚持！

今天看到江宏的博客，他加入你们了。

wow!

@AoEiuV020JP #3 取决于怎么看待。抛开各种硬性、软性的好处。或许也可以参考一下另一种看法，即：技术文档是团队工程实践的记录，并且属于团队知识的一部分（而不是个人知识）。团队内的资深工程师和 Tech Lead 有责任维护它并进行更广泛的传播。

这些文档尽量不要等到交接的时候再去写，而是应该在日常工作中去完成。同时也应该把这些文档当成项目或者仓库的一部分，放在 仓库 wiki 里随着项目更新而修改。这样不管是对新人还是工作交接都更有利于。

以下是我们团队的一些实践：
1.新手教程。
2.架构说明。各个组件的作用，核心依赖以及非核心依赖。国内、海外，主、备等。
3.组件介绍。每个组件的核心逻辑、核心目录等介绍，可以根据重要程度详细或者简略介绍。
4.编码实践。如何搭建本地环境、分支管理策略、issue/PR 规范、代码审核规范、单元测试规范。
5.运维实践-开发篇。如何预发布、灰度、发布、重启、回滚等，以及 CI/CD 。
6.运维实践-运维篇。云服务商依赖、基础设施依赖简介。监控：业务监控、基础设施监控，报警：业务报警、其他报警。
7.测试。 如何单元测试、本地集成测试、预发布环境测试。
8.日志。日志规范、如何使用日志。
9.故障与问题。历史故障复盘、常见问题如何处理。
10.非预期。限流、降级、预案等，最小集功能。
11.账号与 license 。 各种依赖的账号、license 应该去那里找。
12.其他：核心功能的设计讨论文档链接等等。


等到交接的时候再去写上面的这些内容，细节早就遗失了。

阿里业务部门的测试基本只做测试相关的工作，开发工作基本不涉及的。记忆里在阿里三年多接触到的测试大部分时间都花在业务测试上了，开发相关的工作好像也就是极少写写链路压测脚本之类的。

@4kingRAS #9 不太可能是应用级的问题，应用级的问题回滚一下就好了，再差顶多几十分钟一个小时也就处理完成了。

@vanityfairn 这些人大概率都还在大公司里全职呢，估计连融资都还没拿到，也不愿意花时间去写这个 side project 。想白嫖一把做出 demo 去骗融资。

真是中国人就坑中国人啊

@moonrailgun https://www.webpagetest.org 和 https://ping.chinaz.com

墙内的好处就是访问可能快些。

我的 https://www.linnana.me 墙外测首页加载完基本 600 ms 内，而墙内 3 s 左右，有些省份还是 5 s 。

你这种结论有点片面了，国内也有不少这样的人和公司。

@seres 我平常读英文书籍一般都是读要义，能理解整体意思就满足了。我英语四级多一点的渣渣水平，但读《 Philosophy of Science: A Very Short Introduction 》对应中译：《科学哲学》，其实还好，能读得懂。

或许需要加一下词汇量？

@lowend 哦，又学到一个知识点。

忽然想不起来自己为什么能理解中国的古诗了。