用 django 开发后端，结合 template 开发前端网站。跟 Java 的 SpringMVC 是类似的，不过更简单直接，django 是 MTV(Model, Template, View)架构，没有 Controller 层，业务逻辑都是写在 View 里面，django orm 提供了很多操作数据库的 API ，有管理面板来管理数据库，比较方便。

比如 T-ara 演唱会合肥场： https://www.bilibili.com/video/BV1ZV411i7me/?spm_id_from=333.337.search-card.all.click&vd_source=568136ee833b19c986cf70dfdc4263fd
从第 17 分钟开始，因为有翻译的参与，演唱会成功开成了日常生活交流会，比纯粹的歌舞演唱会更能感染观众。

过去韩流在国内火的时候，这种人才应该是很受欢迎的，给我印象最深的就是 T-ara 演唱会上的那个女翻译，哈哈，开演唱会带上这种两边都是母语级的翻译简直是如有神助。

对个人项目来说 TypeScript 对开发速度影响不大，大部分类型可以通过智能提示获取，直接 copy 就行，实在找不到类型就暂时 any 替代，或者 disable type check 。
不过对于企业项目如果 lint 和 tsc 规则过于严格会影响开发效率，需要时间适应。

从事 Rust 开发可考虑向 Web3 方向发展，Rust 在 Web3 的应用比在 Web2 多，在 Web3 领域，Rust 的岗位需求超过 Golang ，而且薪资是最高的，既可以开发底层的链，也可以开发上层的智能合约，Ethereum 的 zk(zero knowledge) layer2 几乎都是用 Rust 开发，新出的公链比如 Polkadot ，Sonala ，Near 等都是基于 Rust 的

打篮球的一些感悟：
1 ，打野球才能体会到打篮球的乐趣，主要是持球，运球要熟练，左右手都能上篮，转身运球，背后运球，转身投篮，这样就可以轻松突破到篮下，即使面对比你高的对手，也防不住你投篮；
2 ，经验表明做俯卧撑，举重能提高投篮命中率，因为增加肌肉，动作更准确；
3 ，一个很重要的一点是保证充足的睡眠，头脑要清醒，要有避免受伤的意识，否则对抗的时候很容易受伤；
4 ，篮球鞋一定要是高帮的，曾经穿低帮的篮球鞋打球导致脚扭伤，差不多一年多才完全恢复。

String 是一个可变的，堆上分配的 UTF-8 的字节缓冲区，它是可增长的、可变的、有所有权的、UTF-8 编码的字符串类型，使用 to_string 或者 String::from 创建。

fn test() -> String{
let s1 = String::from("test1");
return s1
} // 创建并返回一个具有所有权的字符串，

let s2 = test(); // 把所有权转移给 s2 ，s1 就失效了。

内存表示如下：
[–––––– s1 –––––] [–––––s2 –––] // 栈上的胖指针（包含三个字：地址，容量，大小）
+–––+–––+–––+–––+–––+–––+–––
stack frame │ │ │ │ • │ 8 │ 5 │
+–––+–––+–––+– │–+–––+–––+–│
│ │
+––––––––––––––+
│
+–V–+–––+–––+–––+–––+–––+–––+–––+–
heap │ t │ e │ s │ t │ 1 │ l │ │ │ // 保存在堆上的数据
+–––+–––+–––+–––+–––+–––+–––+–––+–

Effect Events are not reactive and must always be omitted from dependencies of your Effect. This is what lets you put non-reactive code (where you can read the latest value of some props and state) inside of them.
参考文档：
https://react.dev/learn/separating-events-from-effects#reading-latest-props-and-state-with-effect-events

还有比互联网精彩得多的东西，对大多数人来说，互联网只是谋生的手段。

标题写的地道一些可以说：Can not figure out what Docker attach and STDOUT are, please help! / please give me some advice.
另外中间很多语法错误让别人看不懂你的问题。

@outgoing4443 那是驿站数量设计不合理问题，可能有的地方需要提高驿站密度，而不是驿站模式的问题

@YY 放家门口无法保证快递安全，如果要保证安全就只能当面签收，但是很多时候收件人不在家。
假如你某一天要收 5 个件，而且那天你刚好在家，那你要准备接 5 个快递电话，当面签收 5 次，但是如果是放驿站，你只需要看下短信，在方便的时候去驿站一次。一般驿站可以存放快递包裹多天，大部分人一周顶多一两个件，你可以一周去一次驿站。

flutter or react native

快递默认放驿站从程序员的思维来看是正确的，快递放驿站跟上门当面送收货人的区别其实就相当于是异步与同步的区别，cpu 不需要同步等待上一段代码执行完才执行下一段代码，而是告诉某个线程你有空就去执行某个任务，完成了通知 cpu ，cpu 再回调，这是异步执行，不会因为某段程序没执行完卡在那里耽误时间。
快递放驿站，同时发个短信通知收件人，收件人收货后扫描收货码自动签收，这就是异步，可以大幅提高快递系统的效率，收件人也可以选择在方便的时候自行取件；
送货上门等待用户当面签收这是同步，快递员要通知收件人在某个时间段送货，收件人需要随时留意快递员的电话不能错过，效率下降成本提升，这是二十年前电商刚起步阶段的模式。
初代计算机都是同步的，所以速度慢，执行简单任务也会卡顿，现代计算机都是异步的，所以速度快，即使是大型程序也能运行流畅。

另外用于统计的 query 比如 sum ，average 等，以及 where 子句条件不精确，会导致索引失效，全表扫描，不适合 OLTP 型数据库。

既然是在 AWS 上，可以试试 Snowflake ，AWS 上的数据仓库平台，把数据库文件导入 Snowflake ，查询的时候会自动横向扩展提升查询效率，查询包含 1000 亿条数据的表也只需 10 秒左右的时间。

1 ，优化 sql ，上亿的行数就不要用 join 了，只针对单个表进行查询，查询位于主键索引（聚簇索引）上的列，避免回表。避免用 in （ in 导致查询复杂度提升一个数量级，要用 in 的话最多只能放 1000 个值）；

2 ，分库分表；

3 ，纵向扩展提升机器硬件；

4 ，利用云计算数据仓库技术（ Cloud Data Warehouse platform ），比如 AWS Snowflake ，GCP BigQuery ，或者 Azure Synapse ，把数据库文件导入数据仓库，在查询的时候会自动横向扩展增加机器，查询包含 1000 亿条数据的表也只需要 10 秒左右的时间，费用会根据所查询的列来计算。