一个 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 是大忌中的大忌,绝不可用。