@ecloud 嗯，张小龙、马化腾、周鸿祎、扎克伯格等等哭晕在厕所

哈哈，可以，这很软广

客户端再怎么整都可能会有问题（合法性、安全性），这事儿必须服务端来整。

Nexus 5 摔过两次，有一次把后盖摔开了一个口，按下去就好了。。。用到现在没出现啥问题

@qiayue 请问这个是啥 App

楼主还是太年轻，可视化编程早就出现了（看看 http://coolshell.cn/articles/11094.html ）。国内大一点的 ERP 厂商基本上都有一套通过拖放业务组件生成业务代码的工具。印象中几年前普元的 EOS 有一套完全可视化编程的工具，就连 if 这种流程也是通过拖放组件来完成的。。。如果用在稍有点规模的项目上，这开发效率可想而知是有多酸爽啊。。。我用鼠标拖个组件并且配置（连接）各种参数的时间，估计够我敲百来行代码了。所以你去实际体验下这些可视化编程工具，就知道为什么不普及了。

function A() { console.log.apply(console, [].slice.call(arguments)) }

1. 远程 sshd 改完配置重启了吗？
2. 本地私钥是这个 /Users/fourstring/.ssh/hexo 对吗？

@adv007 换成声音就是分答或者值乎呗

哈哈，回到大学 BBS 的既视感

好吧，看到楼主的 ID ，请忽略楼上的疑问

看到黄海均的头像，你们是「职人社」的？

国内的暂时没找到，国外的有这些：
- https://www.bitrise.io
- https://greenhouseci.com

@dahvlh 几年前就在那了

一点小挫折而已，算不上悲惨，放正心态最重要。 3 就不要选择了，你是嫌在研究生阶段被老板压榨得还不够吗？可以暂时选择 4 或者趁这段时间好好提升一下自己的技术能力，等答辩后直接找社招吧。当年我们一个同学和老板处得不好（听说），答辩直接不让参加，阿里巴巴的 offer 也黄了。然而这也不算啥。

- 既然选择了结构化的数据传输方式，当然就是按照业务逻辑来建模数据。只要符合业务逻辑语义，数据嵌套多少层都没有问题；
- 如果产品目前只有一个端，由前端驱动 API 设计并没什么问题。道理很简单，由需求方驱动，合作会更容易进行。人家要什么你就提供什么，这样前后端集成起来就快了。如果后续还有其他端需要接入，可以提供新的统一 API ，也可以继续给每个端提供独立的 API （还是由各个端驱动）；你可能觉得这样就不那么通用了，然而过早设计通常并没有什么卵用，特别是在快速迭代的项目，几个月后接口可能都面目全非了；预留一定的灵活性就可以了，毕竟产品快速上线才是第一要务；
- API 不应该和后端资源（特别是数据库）紧耦合。 API 对于后端来说就是一个 View ，对于相同的资源，后端应该可以为不同的端提供不同的 View （ API ）。「因为数据太多，需要插入很多表，如何保证数据一致性？」这个问题和 API 设计完全没有关系，恰恰说明你设计 API 的思路还是「面向数据库」，你应该恨不得把所有 API 都设计成数据库的 CRUD 吧。然而你最终提供的 API 不应该和数据库结构（知识）有半毛钱关系，要不以后调整数据库表结构了、要分库分表了、要换数据库了、甚至不用数据库了，该怎么办？改 API 吗？
- 把你提供的 API 当作产品一样对待，你就知道该怎么做。满足用户（ API 调用方）需求、用户用得爽的，才是好产品；
- 楼主表面上提了个技术问题，实际上是对对方「想要主导开发，而且比我要受到老板信任」感到不爽。抱怨无用，多互相沟通、多互相学习、自我提升才是正道。

@ragnaroks 怎么无法提交文件，用 multipart/form-data 啊

要的话肯定不开啊，怎么可能给这种敏感信息

这个坑。。。 mark 一下