@waitwait365 问题解决

@Mikewu 追书神器的 API 不敢用，哪天废了都不知道，不如自己撸一个，后续还可以加些有意思的功能

@Mac 不想把换源的逻辑开放给用户，后台目前自动选择最优源，后续可能服务端加入观察源状态自动切换可用源

@waitwait365 试试其他的书，目前是自动选择源

褪黑素

@fever 如果新开始看一本书，倒序就有点累了，总有取舍，目前就考虑顺序了。

@fever 仅提供搜索和转码，内容都来自第三方网站，app 本身没有存储内容。

问题的 id 是客户端生成的还是服务端，如果客户端生成，生成的时候就该生成一个 unique id 。如果是服务端生成的，又怎么会出现重复。

你自己说的第一种方式，可以在步骤一就返回全部的新数据，完全没必要两次请求。
但是你也说了数据可能会有很多，每次增删改查都返回全部数据显然并不合适。

@lipeiwei 网站可能暂时有证书问题，也可以直接发我邮箱 cxg#giga.build

@lipeiwei 我们公司有招人，上海，但是要到上海来面试，有兴趣可以投递一份简历， http://jobs.qlear.build

@JackyBao

你看谁都是公关有什么可说的呢，还觉得 Blue Air 是假洋品牌，
现实测出来的 CARD 值都不愿意相信，有什么可说的呢。

如果每个型号的产品没有达到标称 CARD 值，你可以说设计差，净化效率差，不然说毛线啊。

@JackyBao 道听途说就不要提了

恰好我们公司就是专业做空气质量评测的，市面上大部分的监测器，净化器都评测过。
而且绝对比 FView 这种业余级别的评测准确很多。

得出的结论恰恰相反， blue air 基本是消费级产品里表现最好的，就是性价比一般。
FView 里面非要用最低端的型号去测那就没什么说的了。

性价比最好的当然是小米，就是最高档噪声太大

@JackyBao 为什么不买 Blue Air ？

https://qlear.build

推荐个 App QLEAR
也有 web 版的 qlear.build

@firecicada

既然 quake 或者后面的小哥成长起来一个人就可以 hold 住，为什么你现在那么坚定不要 Ruby 做后端呢？
招一个靠谱的 Ruby 程序员难度并不大吧

@nannanziyu

既然觉得买得起，也觉得几百块的键盘根本无所谓。
纠结这么点钱的东西就剩作这么一个原因了

React 又没有强调过单向数据流，单向本身就是 flux 推崇的，而且是有意设计成这样的。

复杂的组件交互，传统的事件模型耦合度太高，维护成本高。
任何事情都是有 trade-off 的，用 flux 那一套，简单功能的模板代码量就会增加。

前端是改变的太快了，但是感觉全文基本都喷的不在点上

这包纯粹炒概念，做工不行，上头会塌，败笔啊