这要求，这工资感觉一点都不门当户对啊

@nightire 很喜欢看你的评论，属于心直口快的那种。个人认为这就是最有效的交流方式，客观，直接。 不过对于下面这句话表示不能完全赞同：

但我始终觉得加班和 Hackthon 这两件事情不太适合用来驱动自己去达成上述的论点或是目标。

首先这句话表达得比较笼统，没有表明中间的一些关系。其次博主并没说加班和Hackthon就是驱动。

先来理下各种关系，加班和低效率的关系

在中国，IT 行业普遍加班严重，先不说行业特征与企业文化。 就我最近面试的经验来看，很多程序员的开发效率实在是低到不忍直视。

所以「效率」是一个导致加班的重要因素。 如果你效率高，但迫于企业有加班的文化，你完全可以用加班的时间来学习一些新的技术，进一步提高自己的效率。

这是博主的原文，这里其实说明了导致加班的因素有两点，一是企业文化，而是低效率。所以说低效率并不代表绝对会加班。那么接下来博主这句话：

效率低会引起下图的怪圈：（配图参考原文）

就是一个不合理的陈述！ @seabornlee

说到这里，怪圈出来了。接下来博主开始论述他破解怪圈的方法，这个方法就是刻意学习。但是博主提出这个方法的时候并没有说我要在什么时间去刻意学习。接下来博主开始根据自己Hackthon的经历来告诉读者，最好不要在工作时间来刻意学习，因为他认为这是战场，是需要高效工作的地方。那么言下之意就是你需要通过刻意学习来破解怪圈，但是你最好不要在工作时间来这样做。

所以，博主的论点或是目标或是刻意学习的方法针对的是怪圈，而不是加班或Hackthon。 而怪圈的产生需要满足的条件就是你工作效率太低导致了你经常加班，进而导致占用了你的学习时间，跟Hackthon没任何关系，而加班也仅仅是怪圈中的一环。

@rubyfan1 我一直在用 Vim，但是并没有降低我的代码质量，也没有因为用 Vim 而坑了队友。IDE 的特点就是集成了很多的工具，一个 IDE 就是一个集成的开发环境。Vim 仅仅专注于文本编辑，而我们每天的工作也就是把一段代码写出来，然后重构，重构……再提交。在编辑文本的速度和便捷程度上目前没有哪个 IDE 可以和 Vim 相比。所以，我觉得他们各有各的特点，用或不用，好用与否都因人而异。其实说这么多就是因为你那句话：

非要把 VIM 搞成这样真是浪费生命

其实就是想说，这并不是在浪费生命！

@rubyfan1 你知道 Vim 和 IDE 各自的优缺点吗？这种太随意的评价👎

好贴！吸引了这么多的大神。

#1 楼 @huacnlee 能发现自己还有东西不会本身就是一个牛逼的技能：）！

好文，好分享 :plus1:

:plus1: 很好的分享！

#3 楼 @adamshen {N}> 或者 V{N}G>

@aquajach

If the challenge of working of some of the best developers around

读起来怪怪的，这样是否好点 If the challenge of working with some of the best developers around

要求写得挺仔细，但是福利难道就是仅仅是每月到账的薪水？

@yue 很多时候确实是不好界定什么时候用合适，什么时候用不合适。但是在 stackoverflow 上看到了一总结，感觉挺能接受的

Summary: When to use? When it will make your life easier and not complicate others' lives.

@yue 你这回复让人摸不着头脑啊。什么叫做好好写代码？为什么偏偏不能用method_missing?

@ery 那该什么时候用呢？

@easonlovewan 我其实就是抛出了这个问题，并不能表现出我是否极端。但是在我的工作经验中，确实遇到一些看似极端的现象，就是大家其实在尽量避免元编程的一些用法，像是方法代理 (method_missing)，方法动态定义 (define_method)，等等。所以，在此抛出此问题主要是看看大家对元编程用法的见解。

#1 楼 @mizuhashi 这个只是增加了一定的难度去找到这个方法在哪儿产生的，不管是动态定义或者不是，一个方法总有一个 caller，一个 receiver，所以其实还是可以较好定位的。

#7 楼 @rei 感觉作者其实期望不要另眼相看元编程，无所谓特别，用 Ruby 而不用元编程其实还不如不用 Ruby。

内心好骚动

:plus1:

#25 楼 @fionhan 原来女程序猿真的存在😄

#58 楼 @jarorwar Marvin 比活跃还好么

@poshboytl ＋1

不晓得你用的 rails 版本是什么，我这里自己 demo 了一下，没有什么问题

def index
  @cart_total = "38.0"
  final_amount = @cart_total
  params[:order] = {"shipping_id"=>"1",
                    "ship_day"=>"任意日期",
                    "ship_special"=>"",
                    "ship_time2"=>"任意时间段",
                    "part_pay"=>"4",
                    "payment"=>"wxpay",
                    "memo"=>"",
                    "is_tax"=>"false",
                    "tax_company"=>"",
                    "ship_zip"=>"",
                    "ship_tel"=>"",
                    "ip"=>"127.0.0.1",
                    "member_id"=>4451,
                    "supplier_id"=>1,
                    "status"=>"active"}.with_indifferent_access
  params[:order].merge!(:final_amount => final_amount)
  return render :text => "#{params[:order][:final_amount]} => #{params[:order]}"

没感觉有歧视。文中风趣的描述可能部分是事实，只是数据应该不是那么绝对。只是这绝对不是 Rails Girls 发起人想看到的结果：）。

我去，真拼啊，好高推荐费！

@vmskipper 你也是用心良苦啊，看来是伤透了！

#1 楼 @xiaoronglv 关于补充 2 首先看看我的叙述

当你发现 Module.nesting == [] 的时候，说明你正处于 top level，也就是说你正处于打开的 Object 中

我在这里其实是想解释下，什么是 top level。我的理解是，当你打开 bash，敲入irb or pry，好你已经进入了 top level 了。这个时候：

[12] pry(main)> self
=> main
[13] pry(main)> self.class
=> Object

可以看出，你正处于 Ruby 的第一种 context 中，这个对象是main，而这个对象的 class 就是Object。所以我对 top level 的理解就是，当你处于打开的Object中的时候，你就是处于 top level 了。

而关于attch，我理解这是一个专门针对Module.nesting的概念。

class A
  class B; end
  module C; end
end

这里，我们可以说，因为我们在打开的 class A 中定义了，class B 以及 module C，所以我们可以说，我们把 B 和 C attach 到了 A。

#1 楼 @xiaoronglv 你的补充才是这篇分享的一次升华啊，你的理解的确很深入，也很专业。

关于补充 1 对于你例举的三种 context，我的理解如下： 1.self 当前对象

class A
  def m
  end
end

a = A.new
a.m

这里对于方法 m 中的任何操作，a 是当前对象

1. definee 当前类 class A ... end 这里，我们实际上做了一个打开类的操作。所以，对于我们将要在打开的类中进行的任何操作，A 都是他们的当前类。
2. lexical scope 说实话，这是我第一次接触这个概念，我对它只有一个表象上的理解，专为Module.nesting而生

然后，回到我的那句话

我的理解是你访问常量的代码定义所在的 class 或者 module

其实我本意是在这里想解释下，当前打开类，也就是你所说的第二种 context 的那种概念。顺便附上原文

The currently open class or module is the innermost class or module statement in the code. A common misconception is that constant lookup uses self.class, which is not true. (btw, it's not using the default definee either, just in case you wondered):

我又小小测试了下

8] pry(main)> module C
[8] pry(main)*   def get_d
[8] pry(main)*     puts Module.nesting
[8] pry(main)*   end
[8] pry(main)* end
=> :get_d
[9] pry(main)> class A
[9] pry(main)*   include C
[9] pry(main)* end
=> A
[10] pry(main)> class B < A
[10] pry(main)* end
=> nil
[11] pry(main)> B.new.get_d
C
=> nil

从此例可以看出来，无论你是 mix in 或者是继承，当你调用get_d的时候，Ruby 都把定义get_d这个方法所在的 module 作为当前打开类。从我目前的理解来看，我觉得我有点混淆了 Ruby 的三种 context，但是想要表达的东西碰巧合适。因为Module.nesting的第一个成员就是当前打开类。

[67] pry(main)> h = {'one' => 1, two: 2}
=> {"one"=>1, :two=>2}
[68] pry(main)> h['two']
=> nil
[69] pry(main)> h.with_indifferent_access
=> {"one"=>1, "two"=>2}
[70] pry(main)> h
=> {"one"=>1, :two=>2}
[71] pry(main)> h.with_indifferent_access['two']
=> 2