平铺窗口管理器表示都是渣渣

twitter

pg 的 json 和二进制 jsonb 是可以建索引的。所以作为查询条件、连表条件都是没问题的。技术其实在进步，大家可以试着尝试一下这些数据库的新功能。

我们现在的新项目都是上 PG ，关系型非关系型都是一套系统。全文索引也是用 pg 。后台的数据库选型异常的简单。
（但我们不是做电商这样的高并发项目的，所以不清楚规模上去了会怎么样；在初创阶段，一个功能丰富的数据库能帮助到开发速度很多）

我喜欢看冬天和狗狗在野外露营的视频，感觉整个被治愈了

https://youtu.be/5z9-4Rafh6k

@charleslzq 其实没法 1：1 迁移。只是希望两边的组件有匹配，比如 S3 对 aliyun OSS，这样就可以保证一样的组件拓扑；然后就可以比较简单的重写 terraform 里面的 resource （肯定还是需要更改相当一部分代码，但是思维方式可以保持一致）

在家远程工作了两年的表示天天和摄像头作伴

网路条件如果不太好的化，建议台式机装 linux，靠 vscode remote 插件和正常的 ssh 来实现远程办公。这个对带宽需求极小。
网络实在差，可以用 mosh 或者 eternal terminal 这类的 ssh client，自动断线重连，体验不错。

这两个组合使用，和直接本机 linux 体验基本没有差别。

私有化部署真是个难题。

我们现在处理的比较好的就是客户已经上了公有云，我们使用 AWS cloudformation 之流的 stack orchestration 工具，用客户的账号在他们那边整一套部署。

使用私有云的，或者只有裸金属虚拟机的，目前还完全不知道怎么弄，只能暂时选择不做。插个眼听听大家怎么看。

firebase 把，没有比这更快的了。。都不用写后端，只用管前端就行了。

多人协作需要 type hints 和 docstring，否则神仙难救。

可以在 linting 阶段加入 mypy 或者 pyre 这样的类型检查器，让大家尽量不全类型信息。

rancher?

我们在 aws 上的简单配置：
1. 多 EC2 实例部署 django 应用
2. 接个 ASG 保证 HA
3. 最前面再接个 API gateway

LZ 的问题听者像是数据库瓶颈的问题。如果经常需要做大量数据统计和报表的功能，一个是考虑优化一下 query 的性能；一个是可以考虑设置定时任务预计算一些常用的报表；另一个是考虑上 OLAP 的数据库，例如我们的 OLTP 用的 postgre，OLAP 用的是相关的 greenplum

创始人不拿钱合适。
早期员工不拿工资不合适。如果需要靠抹除人力成本才能拉长 runway，这个模式不可持续性太大了。

员工和创始人需要区别对待。

给开源项目交 PR，先搞几个 good first issue 上上手

@mywaiting django 更符合一些 python 的直觉，do one thing with one way 。老年人表示 django 比较友好

外包的外包？

因为 go 被设计出来的主要目的不是来写 cms，电商平台这类高度业务相关的程序的。

go 一直是作为一个 better C 被设计出来的。C/C++的使用成本很高，go 出来之前，比较正经的基础组件（数据库、中间件、网路、容器编排等）基本选择只有 C/C++。但这个模式不符合大厂的利益，因为能用好 C/C++的人太少，写出来的程序 bug 太多。go 被搞出来之后，即使是年轻的工程师也可以像老帮菜一样，写出质量较高，性能不错的各种基础组件了。这个才是对大厂生产力提高最多的地方，也是 google 为什么乐意持续投资搞 go 的原因。

至于传统的 web 后端，这个完全是语言流行起来之后的溢出效应。这个道理就和你问，为什么 C/C++写的 CMS 和商城系统这么少呢？非不能也，只是擅长的领域不一样。

你需要写测试和设计文档