确定公司有钱就去劳动仲裁，胜率极高。但仲裁记录也是公开的，能被其他公司查到。有些 HR 很怕懂得运用法律保护自己的人，以后找工作会受到一些影响。

如果公司是因为没钱而发不起工资，那仲裁了也弄不出钱来，只能自认倒霉了。

马斯克

@airyland @ericls 难道 S tripe 有二清的特权？

@uqf0663 “党”在中文里多含贬义，还是不要这么说的好。

谁不喜欢省事呢？但很多人坚持原生，是为了照顾使用低配机的老人、穷人等弱势群体。他们要付出比统一框架更多的劳动时间，就为了让用户能够更流畅一点。我认为他们是应当受到尊重的。

当然每个人都可以有自己的观点，但如果不是为了明确表达对这个群体的反对意见，还是别用这些容易引起误会的词。

TPM 在物理安全的情况下是可靠的，所以我司对存有敏感数据的主机都放在有保险设施的机房里，使用者只能使用远程桌面访问。局域网环境下与使用物理机体验几乎一致。

几年前的测试结果，拿 PostgreSQL 当 nosql 用，性能比 mongo 还好，也不知道这几年 mongo 提升了没有

按 git 的最佳实践，应该每完成一个改动就 commit 一下，学名叫原子性（ atomic ）。

习惯这么做以后，就不会发生这种惨剧了。

楼主需要补点 React 的基础知识。

一方面，React 是函数式编程，要想改变对象的状态，不是更新对象里面的值，而是用新的值重新生成一个新的对象。但任何模式都不是万能的，ref 的存在就是为了照顾一些确实需要访问同一对象的情况。

另一方面，React 里的<input ref={这个东东} type="text" />也不是 html，而是 jsx，它是仿照 html 的语法写的，但又很不一样。

早年我司加班管吃管车，后来限制越来越多，我就不加班了。

本来我就是懒，想着回家还得做饭洗碗，折腾两个小时还不如写程序，毕竟写程序在我的舒适区。

既然老板瞎折腾让我不舒适了，那就不加班了呗。也不知道老板自己觉得这是赔了还是赚了。

这种问题 100%是硬件问题，先搜索一下你的硬件有没有兼容问题吧，比如带光驱的 MBP 把光驱拆了加装第二硬盘就会有这个问题。

@john990 本来都写了 500 字了，又删了，因为不知道还要写多少。你这是个多对多的关系，是最复杂的场景，我怕是很难用几句话给你讲清楚。

你还是读一下官方的最佳实践吧，根据官方推荐的做法，你应该把所有数据都放在一张表里，所以不会有歌手表这种东西。

另外，用 DynamoDB 不能一点一点的挤牙膏，你得先把所有读取的场景都列出来再设计表，否则后期很难修改。所以最好以微服务的思想去设计你的系统，每个服务各自用一个表，以降低耦合，在充分利用 DynamoDB 优势的同时为后期扩展保留灵活性。

@chonger 估计是，不过这也太敏感了，绝对是正能量的想法，是因为这个话题好坏都不准讨论么？

楼主思路有点偏，虽然是“基于”centos，但已经完全不是一个东西了。

就像 Ubuntu，虽然是基于 Debian，但我见过好几个软件只能运行在 Debian 却不能运行在 Ubuntu 了。

持证的路过，你如果是 AWS 的用户，学学还是有用的，至少知道想做什么事可以用哪个服务，不必啥啥都自己开发。

但你如果不用 AWS，那完全没用。一来它重概念，轻实操，考完了你还是不会，得具体用的时候另学。二来它只能指导你用 AWS 的哪个服务，换个云就不一样了。

@thedrwu 人工转过去的我知道，但那个帖子根本没见过，发完了就没了

DynamoDB 是靠 GSI 实现复杂查询的。

比如你的需求，可以建一个 Partition Key 为歌手，Sort Key 为歌名的 GSI （其实反过来也行，具体看你还有没有别的需求可以利用这个 GSI ），然后 query 这个 GSI 就行了。

GSI 用起来跟表一模一样，只是表里的键是唯一的，而 GSI 允许重复。你用”歌手=xxx AND 歌名=xxx“为条件可能搜到多个 item，所以你只能 query 而不能 getItem，然后再根据搜到多少条来决定下一步怎么处理。

另外，歌手如果是个检索条件，那就不应该放到同一个 item 里，而是为每个歌手创建一个 item 。这样你就可以通过 GSI 搜索”歌手=xxx”来得到该歌手所有的歌曲。