这是为超级精品网做准备吧？

我现在用 12 吋 MacBook 跑 IntelliJ IDEA 都没问题， 13 吋 Air 性能比 12 吋只强不差。

@Light3 后来推了的可以再去，只要用人单位还需要招人，你实话实说他们也不会为难你。

@cyang 一般劳动合同会约定试用期提前三天通知就可以走人。所以严格按合同来，顶多让他入职打卡坐班三天。

@ichou 奸情

码没有了， 0.99 美元也不贵，买之

很快中国领网就能划出来了。

没有 profile 的性能优化都是算命

语言把强制规范定得再完善，也挡不住 low b 写出烂代码

看劳动合同怎么写

@Goooogle 想按 Ctrl+Esc 时一定很痛苦

假设电源输出电压和手机一样为 3.8V ，电流是 15W / 3.8V = 3.947A ，按户外使用 8 小时，热效率 80%计算，移动电源的容量至少为 39470mAH ，重量就不说了，好大一颗炸弹挂在身上。

搜了一下只找到这个 https://www.v2ex.com/t/112732

信用早已破产

简单来说区别在于数据库软件是否负责维护数据间的关系。

关系型数据库是依照实体-关系模型建立起来的，它包括两个部分：一是数据库部分，负责数据的保存和索引，让你完成增删改查操作；另一个是关系部分，利用数据表把数据按行的形式组织起来，检查每个字段的数据类型、长度甚至取值范围，利用外键约束数据表之间的关系，利用事务机制确保数据库操作的 ACID 特性。

非关系型数据库全部或者部分放弃了实体-关系模型，它们只负责保存数据，并不组织数据表，也不约束表间关系，关系的部分交由开发人员自己来完成。比如 MongoDB 用 JSON 序列化的方式保存数据，虽然也有表的概念，但是结构可以随时扩展调整，而无需更新既有数据。比如 LevelDB 是一个 Key-Value 数据库，重视写入性能而非读取性能。 Redis 提供了 Key-Value 、 List 、 Set 、 Sorted Set 等多种数据结构模型。 Cassandra 则使用面向列的数据模型。

关系型数据库设计之初是为了给国防、金融、政府及企业管理使用，对数据一致性要求极高，再加上当年存储成本高昂，业界努力的方向也是确保事务安全和减少数据冗余。实体-关系模型提供了简单易学、健壮可靠，相对通用的软件数据建模方法，自然成为各种数据库软件的基础模型。非关系型数据库早就存在，但是因为缺乏必要的数据一致性保障而未能流行。直到 SNS 时代，社交网络应用对数据的一致性要求相对较低，对数据处理的实时性要求和大并发处理能力方面的要求非常高。通过放弃一致性检查和事务机制，非关系型数据库一般比关系型数据库拥有更好的性能，而且也不局限于实体-关系模型，能有更灵活的数据模型和操作方式供开发人员使用。

未来的趋势是两者结合， PostgreSQL 作为老牌的 RDBMS 开始提供 JSON 等更灵活的数据字段， Redis 等典型的 NoSQL 系统也开始提供 atom 操作接口。

不存在哪种数据库更好，请按自己的实际业务场景结合起来使用。

@zjqzxc 本来就没有更替生育率的概念，只说生育率是否达到世代更替水平。如果男女出生概率相同，那么要达到世代更替水平的生育率应该是 2.0 ，考虑孩子未成长到育龄而早夭等情况，国际上才普遍把世代更替水平要求的生育率设置在 2.1 ，以中国的婴幼儿死亡率，和男女比例考虑，世代更替水平要求的生育率只会更高。

@zjqzxc 二胎政策真的是众望所归吗？国际公认生育率要达到 2.1 以上才能达到更替水平，现在开放二孩政策，就算所有夫妻都生两个孩子，也才 2.0 的生育率，然而连计生委的人都估计会生二胎的人群比例不到六成，距离 2.1 的生育率还差得远呐。

至于所谓政策环境变了所以自然调整的说法，根本站不住脚。你只看到了“ 1965 年生育率是 3 ，现在是 1.3 左右”，就以为“政策自然调整了”。然而 1981/82 年全国人口普查时生育率已经降到 2.61 了， 1989/90 年全国人口普查时降到 2.29 了， 1995 年 1%抽样调查发现生育率已经只有 1.45 了， 2000 年全国人口普查时生育率已经降到 1.21 了， 2010 年全国人口普查更是降到了 1.18 ，后来开放了双独二胎和单独二胎政策才有了现在“ 1.3 左右”的“危险水平”。如果政策真的是环境变了，自然调整，早在 1995 年就该调整了。