• 到底如何做 HTTP API? at 2016年08月31日

    第一个问题:个人观点,不一定符合restfull规范,resource定义可以更灵活一点,同样的resource,可以增加定语来适应不同的场景.而批量的场景,可以在post或put中兼容. 不建议API按页面来定义,有时候一个页面需要请求2-3个接口,有极小的性能损失,但是跟语义清晰,扩展性这些优点比起来,可以接受. 第二个问题:有restful规范是好的,好处是,这个规范不用培训.url的构建,实在不是问题.

    不过我们做的时候没太遵循restful规范,为了简单,也没有用/api/v1/users/{id}/stories这样的方式,所以也没遇到什么障碍.对于url的方式,我们也是更倾向于使用?id=xxx&name=xxx这样的方式.这样的方式好处非常明显,使用key value的方式,可读性比较好(不需要查文档),扩展性也比较好,比如search这样的场景,筛选条件是不定的.

  • 兴趣很重要,人生目标也很重要。做好职业规划。选择了就要坚持,做到最好。个人拙见。

  • MVC 是一个巨大误会 at 2015年10月19日

    楼上说的有道理,架构是抽象的。mvc没有对实现细节进行描述,比如业务逻辑应该在哪一层。一个典型的复杂web应用也不能用mvc概括,因为这样会导致一个控制器几千行代码,太常见了。

  • PHP vs Golang vs Node.js at 2015年10月19日

    确认瓶颈所在了?数万人这个量级实在太低了

  • git-flow 的使用 at 2015年10月15日

    http://git.oschina.net/progit/ http://nvie.com/posts/a-successful-git-branching-model/

    1 通读git, 2 在 github或者oschina 上弄个项目练。 3 过一遍git-flow ,记住那张经典的图, 4 重复2,记住看每个命令的返回信息,它会告诉你git-flow到底干了什么

    基本就会了 再到项目实践,会遇到一些问题,到时候再往深了研究。

  • 在校生,求收留 at 2015年10月14日

    挺不错的,工作意向呢,比如想找什么方向,还有想从事什么技术的开发?如果有match的,我可以推荐。

  • 这个问题设计成两步操作会更简单。 第一步,产生一个后台统计任务,将统计结果保存到表,或者其他中间存储。 第二步,查询统计结果,基于统计结果,点击导出。

    如果一定要等待然后应答,就用楼上的回答。

  • 1:1是个坑

  • 同意楼上的,最好的方案通常不是讨论出来的,一般自己认定的东西就很难改变了.自己用用就知道了,现在的软件迭代速度都很快.用完了,再回来看看.没什么问题就继续用,不好就重构.