一个 Rails 项目非要用两种数据库，这不是给自己找麻烦吗？

补来补去，问题越补越多。还不如花一点时间：

选项 1：把 MySQL 数据导入 PostgreSQL, 彻底放弃 MySQL。或相反，彻底放弃 PostgreSQL。

选项 2: 实在不能动 MySQL 的情况下，把有关 MySQL 的 models 分离出去，用服务交换数据。

你装新版本的时候应该是有选项让你选择是否更新 Grub 的啊。如果没有更新，那么 Grub 对应的还是旧版本，然后旧版本又删除了，所以出错了。这个看上去是 Grub 坏了，得重装。

我没重装过 Grub，可看这 http://howtoubuntu.org/how-to-repair-restore-reinstall-grub-2-with-a-ubuntu-live-cd http://askubuntu.com/questions/145241/how-do-i-run-update-grub-from-a-livecd

但你现在 U 盘启动还有问题就搞不清楚了。照道理 U 盘系统和其他系统什么关系都没有的。

要实在不行就把重要的文件和配置都拷出来重新装 Ubuntu 吧。十分不推荐装最新版本。13.10 就足够了。

楼主你要确定是 Rails 项目才可以这么写。blank?和present?都是 Rails 的，不是 Ruby 的。

这两个你看哪个顺就用哪个，没必要纠结在这些细节，浪费时间

当你研究了半天，试过了各种解决方案，最后会发现，还是自己写来得靠谱：）

我觉得刘翔还是挺牛的，能跑步还能写代码。

@zy01 没有笑：）我是觉得重复的东西对社区没什么价值，但自己记笔记绝对是好事。

@dxxeng 你的比喻不是一回事。粮草是战争的必备条件，就好像你现在必须有电脑才能写代码，就好像你现在关心什么样的工具适合开发。部署是下一个阶段的事情，就好像你仗还没开始打就担心着怎么处理战利品。

非要方方面面都考虑齐全才动手不是做事情的正确态度。另外，就算你现在把服务器弄好，写项目还得几个月吧，这几个月岂不是浪费钱。

抄文档干什么。

项目都还不知道是什么就着急什么部署。先在本地写出来再说吧。

@lucky215 不知道苏杰是谁。域名自然是越短越好，iam 凭空多了两个单词，三个字母，又没有一点意义。另外 iam 也可以写成 im, 要是你的网站真做大了，人家用一个 im 就可以混淆你。

你选域名要根据目的。你是拿来做个人博客的吧，这种空泛的名字，不管是带 rubyer 也好，带 rubyist 也好，都没什么意思，体现不了任何特色。不合适。做 Ruby 的人多了去了。

当然你如果注册到单名的域名又另说，比如 rubyer.com，rubyist.com，这些还是值钱的。不过开发成网站还得有相匹配的内容和实力。不然一个高大上的域名放上不相配的内容会被人笑话的。

楼主不懂域名吧，im, iam 放在域名里面很难看的。

做的事情太杂是对开发者的快速消费。每种技术都需要花时间研究，花时间跟踪更新，花时间优化效率。就算一个 CSS，下足功夫也可以玩出世界级的花样。

什么都做哪里有时间专注主要的、感兴趣的、擅长的事情？只能是消费开发者之前的积累。

Ubuntu 的新版本我是不想尝鲜了，实在没必要，各种 bug。老版本其实都够稳定，够用。Carnoical 主要喜欢在界面上折腾。我的经验是新版本发布三到四个月之后再考虑升级比较合适。

@fantasticfears 明白了，我们说的不是一回事。我之前以为的是/lib 那些，对 Rails 的扩展。我看 Discourse 的业务逻辑基本上都是自己写的，不抽象，但看上去很实用。

你说的 Plugins 是对 Discourse 本身的扩展，我不了解，因为没用过，只是研究过他本身的代码。感觉这一块是不太容易，对 plugin 作者和库本身都有要求。Wordpress 的 plugins 就不说啦，乱糟糟。Drupal 在这一块还是要好一些。

谢谢你的详细回复。

@fantasticfears 他的 plugin 和业务有关的基本都是自制的，很少外来的，我倒觉得很实用。你说一般，能否稍详细点批评一下？

Ruby 开发工程师税前 5k? 广州请个靠谱的保姆都不是这个价了。Ruby 开发者就这么不值钱？

多谢分享经验。请教，如果是比较小的订阅，比如说 Basecamp 这种 30 多美金一个月的或更低的，然后占用资源也很少的，使用 PAAS 会不会比较重了？

@pynix docker 好像很有意思，谢谢，涨姿势了。

@huacnlee 有道理

@special 订单状态直接设到订单 model(table) 里只能说是 demo 级的。最起码订单状态必须有 log。订单 id，user_id（谁改的）、状态、关联事项等等。谁、什么时候改的、改成什么状态、原因是什么，都必须有据可查。

订单表就是订单本身，不直接加状态栏。

读状态时，选关联 log 的最新状态。写状态不允许任何表单直接写。从业务上来说，状态也不是表单能增删改的东西。状态修改必须从属于某一个动作，比如说客户下单、仓库发货、等等。从这些动作里面来写状态。

这另一方面也增强安全性，只要你不刻意在订单 model 中明确表示接受状态的 nested_attributes，没人能直接从订单改。

看看你用的 Bootstrap 版本是不是 3。你看的书用的是 Bootstrap2 版本。3 和 2 相比有很大改变，其中一个就是变量的名字。以前是 camel case 类似$grayLight, 现在是 hyphen 类似$gray-light。是 3 的话把变量名改一下就行了，还有问题可以自己查找 Bootstrap 文档看看新的变量名。

@QueXuQ 我没有实际做过这种 multi tenancy 的项目，但从代码上看是可以保证线程安全的。因为写值是写入现有线程，其他线程是拿不到同样的值的。

@hz_qiuyuanxin 准确说应该是现有线程的全局变量。其他全局变量，以及cattr_accessors, @@foo 这些都是线程不安全的。

@kesin 那就是 return 的问题，你的 redirect 没有 return, 所以 action 会一直执行下去直到 render。那么用户看到的 url 就是 redirected url, 但是内容却是 new。create也是一样，不会阻止，直到 post created。

发贴的是注册用户还是非注册用户？

正常来说更新是不需要，因为更新需要现有的 id，没有 id 会出错。

可能 condition 有问题吧，最好多贴点具体细节。

@5swords 明白。乱喷了一下，勿怪 :)

@Kabie 主要原因是这个 rescue 把以前所有可能发生的报错全部拯救了，这样调试时根本看不到正常的 backtrace，可能的坏蛋都被这个包庇者藏起来了。

但是有具体 class 的拯救还是好的，比如rescue ActiveRecord::RecordNotFound

总之 resue 应该用于具体的，有意义的拯救。像这种解决显示 title 的问题，即使有具体的拯救也没有必要使用。好比郭靖也不会见人就使降龙十八掌。

更多的你可以看看这个： http://stackoverflow.com/questions/10048173/why-is-it-bad-style-to-rescue-exception-e-in-ruby

Don’t rescue Exception. EVER. or I will stab you.

就这个具体场景而言，我认为find_by_id和try(:title)都是不好的做法。好的做法是先拿到 post instance, 然后再展开各种 attributes。如果找不到，rescue as above。

@keating 看来我今天要喷好几次了。无条件 rescue 是大忌中的大忌，绝不可用。