我的项目在阿里云上面，还行吧，因为没用到 github, 都是通过 ssh 来上传 war 包的方式发布。其他需要的组件 yum + wget 都能搞定。因为暂时一台机，没上 puppet script 和 vagrant.

牛啊..

用了 1 个多月了.... 有些软件 broken 了... 不应该做小白鼠的。

#17 楼 @xiaoronglv 上海近一年当中天蓝的次数用手指都数的完... 要不是台风来了，哪有今天这么蓝的天

现在除了全栈，还有全端工程师... 就是包括 web, ios 和 android 端全包....

只是技术方面的全栈感觉还行，因为技术都是想通的，而且因为前后都自己统一考虑，design 和实现起来会优美很多，还少了很多不必要的沟通。

如果全栈连 产品经理，图像设计，营销，运营，人力资源啥的全算上.... 那确实有点无语了..

真不如好好看看斯坦福 IOS 教程。

你这不算是迁移。因为你的新的卖书网站一开始就选型了 PostgreSQL, 压根和 mongoDB 木有关系。

一楼是正解，其他基本扯呼。

#36 楼 @hlxwell TJ 真是太 cool 了...

3 年前在 O2 做的几个项目就开始前后分离了，主要的理念就是弱化前端浏览器使其变成了一个和 ios, android 一样的终端，后端只需要实现一套 restful api, 完全与 represetation layer 分离. 我自己做的 88jimo(dot)com 也是前后分离的，SPA 带来的速度和用户体验还是不错的，确实 SEO 上面会很惨。

呵呵

mongoDB 对于单一 collection 的单次操作，是原子而可靠的。

比方说某个场景是 如果该条数据不存在则新增，否则更新该数据，那就使用 update with upset = true, 而不是写两句命令. 比方说 FindAndModify 则可以避免先查询再修改可能产生的脏数据问题。

MongoDB 给出了建议的跨 collection 操作的 transaction 解决方案 (当然得自己实现), http://docs.mongodb.org/manual/tutorial/perform-two-phase-commits/

Operations on a single document are always atomic with MongoDB databases; however, operations that involve multiple documents, which are often referred to as “transactions,” are not atomic. Since documents can be fairly complex and contain multiple “nested” documents, single-document atomicity provides necessary support for many practical use cases.

你这个问题不是 Rails 独有的，基本上 web 程序的测试都得这么测. 无非就是 单元测试

• 前端 Angular -> 使用 Jasmine + Kamar + photomjs/brower
• 后端 Rails -> 普通的单元测试

集成测试/Acceptance Test 系统在真实部署情况下的白盒测试

• Rails 的 Restful 端测试 -> 比较简单，无非是一些 restClient 访问而已，需要根据 case prepare fixture
• 集成测试，使用 angular E2E, 或者使用更为通用的 selenium 方案

其他可选方案 随着 nodejs 和 phontomjs 的兴起，可以使用更为简单实用的 js 来写 acceptance test case 来替代 selenium 的方案. 当然考虑到浏览器兼容性问题，还是推荐 selenium 结合几个主要的目标浏览器来跑。

测试用例特别是 acceptance test 的 cover 程度，需要根据团队实际的 confidence/comfortable level 来确定，否则的话是无底洞。

你说的这个流程就是再正常不过的微信 oauth2 流程. 首先要确保你在微信菜单里的回调 url 带参数都要 url encoding. 其次，token 必须设置正确。

一般情况点击了餐单会立即弹出 oauth 授权页面，这一步应该相当快。点击确认后，如果你从这里开始很慢，说明你的逻辑或者各种 key 有错，微信在尝试 5s 重试。

我做过的速度很快啊，难道你的服务器在国外？

你可以试试我的 www(dot)88jimo(dot)com

我也升了 10.10, 确实会有些小问题，有次还死机重启了... 无语。

@xhj6 看来你就是想要个 110 元入个 pd

推荐用 media query 来控制 banner 颜色，PC 端用这种白色确实难看。IOS 用白色还差不多。

如果我做迁移，可以写 mongo script, 把数据生成需要的 json map 或 cvs 格式，然后写程序导入 mysql

为啥要迁移回去呢？

感觉企业协同工作软件就和社交软件一样热门啊，个个都在做这个。

貌似不仅是精华，就是其他几个分类，也都是到 100 页. 我觉得可能目前论坛是在代码里写死了页数的，在某类别帖子不能到 100 页的情况下，后面的都是空的...

我对 lz 是如何边旅游边工作感兴趣

本来想自己写的，结果看到这篇文章，已经 star 了你的 atjs 项目，支持！

祝好运

@Rei @darkbaby123 我同意 darkbaby 的看法，随着现在移动端如此强势的情况下，网页端已经弱化成一种终端形式，后台的 restful 化能够使得架构及其简单实用，非常易于扩展和维护。各个终端开发团队可以并行开发，分别实现最贴近于各自平台的交互和 UI (或者是 hybrid).

Rei 转的那篇文章我觉得思路有些不对，我认为计算力应该往终端移，特别是初创企业，如何减少服务器和带宽使用，就能减少初期投入而增加生存的可能性。

这年头选择太多了也确实是头疼啊，所以才有了 http://todomvc.com/ 这种奇葩网站. 不过说实在的，todo list 这种简单的应用真的用框架写了也不太能试出来一个框架的痛点。

这两者里面只用过 angular, 投 angular 一票吧。

#39 楼 @Rei 是啊，这些都是超级牛人... 还有诸如 TJ Holowaychuk 这类的... 只能膜拜啊。

git 的优势就是本地细粒度提交再整体完成后 push, 所以每当一个的 step 完成后，你就可以本地提交 (前提当然是没有 broken test), 但是 push 的时候就要非常注意了，一定是不能影响功能。

用 Ruby 的人自然而然会喜欢用 CoffeeScript, 因为 Coffeescript 就是 inspired by Ruby 等等语言，同理，Rubylist 会选择 SASS 而不是 LESS.

不过如今 JavaScript 原生的 library 越来越多了，诸如 underscore 这种，也一样能提供类似 sugar syntax, 一样可以很方便的操作数组，Map 等等，更别说如今特别火的 MVC frameworks.. 所以没有 coffeescript 也一样可以灵活的使用 JavaScript 并且避开诸多的坑。

楼上有些人用 jquery 和 coffee 类比是不对的，一个是需要编译的语言，一个是原生的 library, 没有可比性。