#44 楼 @trenttian finnally 读起来感觉像法语

难道不就应该用 Api::ApplicationController 解决吗？ 另外其实建议最好不要给类起一样的名字，否则就会出现你这样的命名冲突的情况。 命名冲突的时候要强制命名路径，比如要严格区分 ::AppCtrler 和 ::Api::AppCtrler 而不能就只写一个 AppCtrler。 建议类改名成，比如说， ApiController。

#5 楼 @novtopro tasks 本身是一个数据库请求，数据库请求上的 #sum 是执行 SQL 语句中的 SUM() 函数。 如果你的 points_toward_velocity 是一个数据库字段，那么这样执行是没问题的。 但如果是一个对象的方法的话， ActiveRecord::Calculations#sum 就没办法执行了，因为没法把这个调用转写成 SQL 语句。 所以需要手动通过 to_a 去先执行这个 SQL 语句，然后变成对结果数组执行 Enumerable#sum 了，这样就对了。

:doge: 非提的欧洲移民之路啊。

URL 请好好编码。 + -> %2B -> +

#5 楼 @hemslo :doge: 太下流了

get %r{/background(|/user/write)/?\Z} do

没用过 Sinatra，纯猜测。

def all_combi_origin str
  combi = ['']
  # Split into upper and lower cases
  chars = str.each_char.map { |c| c =~ /[[:alpha:]]/ ? [c.upcase, c.downcase] : [c]}
  # Combine them
  chars.each do |chs|
    combi = combi.product(chs)
  end
  combi.map(&:join)
end

这是把你的思路用 Ruby 改写后的代码。

测速

Benchmark.bm(20) do |x|
  x.report('all_combi')        { 50_000.times { all_combi 'ru123by!' } }
  x.report('all_combi_origin') { 50_000.times { all_combi_origin 'ru123by!' } }
  x.report('all_combi_4楼')    { 50_000.times { all_combi_4楼 'ru123by!' } }
end

#                           user     system      total        real
#all_combi              1.540000   0.000000   1.540000 (  1.587790)
#all_combi_origin       2.780000   0.010000   2.790000 (  2.894336)
#all_combi_4楼          1.400000   0.000000   1.400000 (  1.443631)

写 Ruby 就要用 Ruby 的思路去设计算法。 比如你这里

for i in 1...s.length
  q=q.product(t[i])
end

就至少应该写成

(1..s.size).each do |i|

或者是

t[1..-1].each do |ti|

以及

q.each do |g|
  puts g.join
end

应该写成

result = q.map(&:join)
puts result

require 'pp'

def all_combi str
  combi = ['']
  # Split into upper and lower cases
  chars = str.each_char.map { |c| c =~ /[[:alpha:]]/ ? [c.upcase, c.downcase] : [c]}
  # Combine them
  chars.each do |chs|
    combi = combi.flat_map do |s|
      chs.map { |ch| s + ch }
    end
  end
  combi
end

combi = all_combi 'ru123by!'
pp combi
puts combi == combi.uniq

随便写了一下，具体效率怎么样就不知道了。

还有一种嘛，每次把请求地址塞进 Session 里。不过请求地址和浏览器 URL 是不一定相关的。

取浏览器显示的 URL 要从浏览器取，用 JavaScript 拿。 Referrer 并不能保证一定是上一次的请求。有些特定情况下 Referrer 甚至会被浏览器屏蔽。

你贴了 4 个一样的地址是什么意思……真看不懂。

#4 楼 @yanguango 这里用来区别

• 填了 true
• 填了 false
• 没填

#10 楼 @yanhao 诶看岔了以为是 Transfer 开始的。

#4 楼 @douxiance 我只说一句。谷歌搜索是必需品。没有访问谷歌能力的人，没法好好学习和工作。

#6 楼 @yanhao 不知道能不能直接 include(:user)？

#2 楼 @douxiance 内容很好，然而回帖没什么用啊，除了增加水量以外。 优秀的帖子留在论坛里通过搜索引擎就可以找到了，不停顶贴没意义。

#46 楼 @cys #48 楼 @jiemoon 不不，为什么会突然提到胡建？

手动点个赞。 （有没有打算把 RSpec 也加入？

#3 楼 @lips 没有研究。我随便挑了个便宜的买的。

IPS 屏基本都能竖着。当然像素点排列这是没办法的事情，不能多纠结了。 自用 Acer B6 B296CL 竖过来看没什么问题（当然不会竖着用就是了

#43 楼 @cys 诶？福州是哪里？

#41 楼 @killernova 嗯，应该是 04-06K

没实际环境不好说。通过以下的方式去调试吧：

• 检查final_amount.class
• 试着用final_amount.to_f
• 试着稍微更改以下params[:order]['final_amount']的值，使他和final_amount不一样。

• 测试：单元测试很多时候是没必要的。建议花点时间看一下 RSpec 关于 Feature test 的部分。会写 Feature test 比会写 Unit test 重要的多。
• 前端：JavaScript 一定要会一点的，要不然很多前端操作还是太麻烦了点。可以考虑从 Coffee 学起。
• UI：把 BootStrap 学会很重要。非常容易做出美观大方的界面。而且如果不想和别的站千篇一律的话，还可以去买 WrapBootStrap 的模板回来套，总之是个效率很高的框架。
• MongoDB：NoSQL 这个概念的出现，主要是把以前 RDBMS 带来的很多特性（关系型）去掉了，并且转变成了扩展性和性能（可以更高并发，可以横向扩展）。通常只有在访问压力比较大的时候才会考虑 NoSQL（比如 Twitter 这种级别，数据之间关系不多，对性能要求高的场景）。平时普通的应用开发，我个人更倾向于普通的 RDBMS。

#37 楼 @279959599 demo 应该是展示自己水平的地方，应该是把自己做得最优秀的部分告诉别人。 我一般给别人看这几个站。

http://ra.gg/ 这是我 5 年前在公司里做过的一个站。当然这漂亮的前端并不是我做的。

http://rooms.library.oregonstate.edu/ 这是 2 年前我初学 Ruby 的第二个项目。前端后端都有参与。

http://beta.camoe.net/ 这是我初学 Ruby 的第三个项目，前端后端都是我自己做的。

demo 站是你水平的象征，别人看到的东西就是别人对你的第一印象评价。如果你说你做的站和你的水平不符，那你把站给别人看的目的是什么？特别是 #12 楼 你让大家多指点指点，结果又说这些东西我都知道你别轻易评价因为你不了解真相。几个意思呢。

回到正题。 Rails assets pipeline 本来就是 best practice，就算你用 CDN 用多域服务器，还是要用到 assets digest 这些东西，不用的结果就是无法刷新掉旧的静态文件。 CSS 也好，JS 也好，一般做 Rails 的公司肯定会要求用 SASS/SCSS/LESS 和 Coffee 之类的替代语言以提高开发速度。你把所有文件放在 public 目录下，说明你根本没有利用到这些技术。 你说线上代码里有 .svn，那么问题来了，你为什么不用 Git 来做版本管理？大公司里不可能只有你一个人做开发。就算只有你一个人，也不可能你同一时间只处理一个功能或者一个问题。Git branch / Git flow 的运用能力是必不可少的。（甚至我之前做兼职开发的时候，老大要求我们一律做 Fork + Branch + Pull Request + Code Review 流程）你这给人的第一印象就是连 Git 都用不好。

然后回到 #31 楼 。你不要以为一直回答别人的问题，就是对别人的帮助。 现在很多人最欠缺的能力就是自己解决问题的能力。学习上，工作上，一遇到什么问题，就到处伸手。「哪里能下载到 XXX？」「哪里能找到 XXX 的资料？」天哪，他们就在我能找到他们的地方——搜索引擎的对岸啊。 之前我加了一个技术群，是专门玩视频图像处理的。我一直在里面回答问题，甚至是我根本不懂的问题，解决了很多很多人的燃眉之急。怎么做到的？很简单，打开谷歌，查一下，然后把链接贴给他们。或者是查到相关的资料，结合他们的问题，给他们解释一遍。他们一看，哦原来是这样。完美解决。我甚至都不用搞懂他们说的到底是什么东西。 然而这对他们没好处，让他们养成了一遇到问题就伸手的坏习惯，最后丧失了自己思考自己研究的能力。 我从高中的时候就进字幕组界玩了，就当时入门的时候有几个前辈带了几天，剩下的十来年，都是自己研究自己思考。我现在带新人的时候感觉就非常明显。天天问问题的人，一定比天天自己研究问题的人，最后的水平差的多。 我不反对问问题，但是问的问题应该有些深度，应该对其他人也有帮助，应该能引起人们的思考，而不是「XX 出错了怎么办」然而又特别基础的问题。（然而，「XX 出错了怎么办」但内容丰富值得回味的问题倒是非常欢迎的）

总之，我是一直建议新人好好读完「提问的智慧」。否则没前途的。（参见置顶帖）

#12 楼 @279959599 薪水定价，有很大一部分是看的解决问题的能力，而不是问问题的频率。 现在除非一个问题我折腾很久都不行，否则我是不会真的去外面发帖的。 （而且实际上我问的不少问题最后还是我自己折腾出来自己回答结贴的。 去一个大公司面试，经常会被要求解决一些实际问题（算法或者设计）。 能不能自己思考并做出来，是是否会被录取的关键。

PS: 16K 的薪水是什么水平不太清楚，现在拿 4-6K 左右的路过。

你可以在 Windows 下开发。但是最好别在 Windows 下运行。

不在日本也能申请？