这个 http://www.luna-lang.org/

@steve-chan-clojure

我有几个观点，

1. clojure 活跃度不高
2. 没有 debugger
3. 第三方库少

关于 活跃度

你没反对，我就当你同意了。

关于 debugger

我还知道有人写 php 不换行，也没 bug 的呢。 clojure 需不需要 debugger，是要看使用者的看法，而不是某个人，当然也可以说，clojure 只给那些不需要 debugger 的人用的，我也表示没意见。

需要 debugger 的人应该不仅我一个，比如这个 https://github.com/cgrand/poucet ，应该就可以证明。

关于 第三方库少

我说了我没有数据支持。你可以说我，没数据，在扯淡。但你说 第三方库多，也没给出数据。那这成了来回扯淡。 我只能说，clojure 第三方库就是少，反正都是在扯淡。

关于 Java

要是仅仅就是想调用 java 方法，大可不用搞一门语言吧？Ruby 就很少拿能用 C 代码说事，也很少拿 JRuby、mruby 说事。

一个语言，调用另一个语言，会有很多不舒服的地方。只有在万不得已才这么做。也就是说，是用来弥补缺陷的方法。。。就算不是缺陷，也是备选方案吧？

而且很多语言都能有这种功能吧？ruby, python, rust, julia。。。

@tony612 还真看过一些简单的东西！

我也觉得 clojure 不活跃，第三方库也少，仅个人看法，无实际依据。

clojure 据我所知，现在还不支持 debugger，但社区认为函数式语言不需要这个，个人表示无法理解，可能是我姿势不对，或者智商有限吧。。。

if Rails.env.development?
      p ">>>"

用 logger 会好一些

logger.debug ">>>"

可以避免开发环境和其他环境行为不一样。

1. 干脆不处理。ruby-china 有的地方就是这么做的。问题也不大。
2. 用 partial 觉得一块东西很多，有共用性，就可以用 partial。不过这个和 if else 逻辑是没关系。 用 partial 是处理两块代码的复杂，而不是 if else 带来的复杂。

另外 @user.articles.exists? 应该会快一些，any? 要 load 成数组，exists? 触发 query。

请去掉 像样 两字。

纯粹瞎说，不要介意。。。

我对 doctest 的期待是，有例子的文档，并且这些例子是可以跑的通的。 写注释的时候，写例子方便理解和调试。

doctest 里，如果测试特别多的时候，会对阅读有影响。测试变复杂的时候，doctest 也会显得比较吃力。

鼓励在注释里写例子，但能作为测试，只是 bonus。

s.split(" ").join("-").capitalize

没理解为啥要模仿 -> 这种操作符。

DateTime ?

另外这个判断，单独写比较好。 比如 longer_than_xx? = (Datetime.parse("Dec click_this_time") - Datetime.parse("Dec click_last_time"))/3600 > 24

如果是用 form 的话，可以用这种 https://stackoverflow.com/a/23497023/2477886

sublime 或者 ide，因为简单， 想玩的看起来牛逼一点，emacs 或者 vim

我的同事也问过我为啥一定要用 form_for。我说我们是用 Rails 的，不是写 php 的，既然用了，就试着写出 rails stype 的东西吧。

提供便利

ActionView::Helpers 里面这么写的

Form helpers are designed to make working with resources much easier compared to using vanilla HTML.

rails 在做数据库的操作的时候，有很多约定。比如 User.find(1).update(name: "bar") 就直接做了更新。那生成的代码，就要符合这样的约定。

多数时候，更新和创建我们会使用类似的 form，只是 url 和 request method 不同。我们可以判断，要更新的对象是不是 new_record? 来生成对应的代码。

这个时候，你会发现手写，就要处理一些逻辑上的问题，那么引入 helper 就是一个不错的选择。

其实这个时候，还不算有趣。如果 user 有很多 (has_many) books 呢？如果想要在一个表单做 books 的操作呢？

可以这么搞，Book.new.book_attributes = [:name => "Ruby"] (之前要声明 accepts_nested_attributes_for :book) 。

这个时候，如果我们想用这个约定，就要构建对应的 form，要根据 nested 的关系构建对对应的 input 的字段。books 还是有序的。等等一系列的操作，但 form_helper 都帮我们搞定了。

减少重复

到现在，其实已经没有不用 form helper 的理由了。但 rails 没有止步于此。rails 用继承的方式，避免了代码上的重复 -- FormBuilder 。 我们看下面的代码

<%= form_for(@company) do |f| %>
  <%= f.text_field :name %>
  <%= f.submit %>
<% end %>

多数的 input 前是要放 label，有一天，我们不想在写这样重复的代码，怎么办？ FormBuilder !

可以这样搞

class LabellingFormBuilder < ActionView::Helpers::FormBuilder
  (field_helpers - [:label, :check_box, :radio_button, :fields_for, :hidden_field, :file_field]).each do |selector|
    class_eval <<-RUBY_EVAL, __FILE__, __LINE__ + 1
          def #{selector}(method, options = {})  # def text_field(method, options = {})
            @template.send("label", @object_name, method) +
             @template.send( #{selector.inspect}, @object_name, method, objectify_options(options))
          end
        RUBY_EVAL
  end
end

<%= form_for(@company, builder: LabellingFormBuilder) do |f| %>
  <%= f.text_field :name %>
  <%= f.submit %>
<% end %>

具体可以看看这篇文章 https://segmentfault.com/a/1190000004425543 (只有一，没有二、三。。。)

还有更好玩的 - simple_form

很多 ruby 程序员，说 simple_form 不好用。

但 simple_form 是大大的简化了代码。怎么搞呢，直接 custom 一个 form_builder 来，然后，大家套用这个 builder 就可以了。

custom 一个 form_builder 难不难呢？我们优秀的前端小伙 zack，第一次玩，就 custom 出来了一个。

不用这些可以吗？

先说，这是一个非常好的问题。

除了这些便利无法享受到以外。项目中的每一个人，每一个 form，都要重头写 form！都要了解 rails 的细节，都要了解 HTML form 的细节（笔记 array 在 rails 里生成的参数是什么样的？）。

代码变得不可 review -> 错误不好发现 -> 隐藏的 bug。

在约定和继承的路上渐行渐远

Rails 复杂，就是因为 Rails 提供了很多这样的便利。

有的时候，难免会想，这些到底值不值得？

accepts_nested_attributes_for 我第一次用，也是一脸懵逼。但我花了一天左右的时候，就搞差不多了，顺带还知道 Rails 的很多细节，比如 create、update 几个方法的关系。影响了我后今后的编码生涯（虽然听着很夸张，但却是如此）。以后 form 可以用的很爽。

搞了这么多，做起来难不难？不难，就像 simple_from，我们前端的小哥，半天就定制好了！Rails 难的时候，可能是你用它的姿势不对。

为啥要用框架？

框架，不但能提供了好用的方法，能解决常见的问题。

还封装了细节，让我们不那么懂的时候，可以写出东西来。

提供了解决问题的姿势，大家可以用一样分流程解决类似的问题。

用 Rails，不能写完业务就万事大吉，还要读文档，了解 Rails 的机制。

八成是，现在不给钱，要钱？以后给。。。

没人会否认 Lisp/Clojure 的价值。语言有自己的特点，也有自己的适用范围。

有很多人从 Ruby 转向 clojure，也有很多人在用 ruby 做函数式的尝试。

Ruby / Rails 本身都在函数式编程上学习了很多。比如 rails 的 ActiveRecord::Relation User.wher(xx: xx).find(xx) 。每一个方法都返回一个 ActiveRecord::Relation 的实例，而且是 lazy evaluation 的。

Clojure 也在做解决状态的尝试，比如 https://github.com/stuartsierra/component 。

面向对象，会带来复杂度，但也能解决问题，比如被很多 rails 程序员诟病的 https://github.com/josevalim/inherited_resources ，也可以极大程度上提高生产力。开发效率和能力成正比。这种东西所带来的好处就是，大多数情况下，隐藏了细节，团队开发就变成了有经验的 + 经验少的这种组合。而不是所有人都要有经验。

有些问题，需要通过 提供抽象、提供解决方案来解决。 比如创建数据，需要用到 factory，需要实现的就是 factory_girl 的那些方法，无论是 ruby 还是 clojure。

高手潜水呀

ruby-china 也有人潜水。但国内有很多牛人都不潜水，有管理论坛的的，有回答新手问题的、有分享撕逼的。至少看起来，是团结、热闹的。

同样的帖子，http://clojure-china.org/t/clojure-sdk/691 ruby-china 的热度更高啊！

搜索搜到这个帖子，没啥事，就试着写了下，跑通那几个用例，一共用了不到 30 分钟。

感觉挺好写的。这个算法我知道怎么回事。翻译成代码就 ok 了，ruby 又这么好写。二分法的递归也是属于比较容易的递归。写个骨架，然后再加最简单的测试用例（下面的前 4 个），之后对着用例开始微调，无外乎就是加减 1 的问题，试几次就 ok 了。再之后，就看看给的测试用例有没用问题。

递归转遍历，只要理解递归的原理，把递归维护的状态，手动维护下，就 ok 了。反正测试用例有了，测试一直跑的，开始微调。

倒是觉得测试用例挺重要的。要是让我直接用面试官给的用例，我估计就要懵逼了。

递归是基本功。可以很好的锻炼抽象和分解问题的能力。递归学东西，一大片算法可以随便撸了。

递归可以这么考，先递归实现，之后用尾递归实现，再之后用遍历实现。再问问为啥尾递归可以被优化之类的。哈哈哈哈，我承认我挺无聊的。。。

代码如下，算法相关的，就没注意命名之类的问题。

## recursive version
def binary_search_helper(arr, ele, start, end_)
  return false if start > end_
  middle = (start + end_) / 2

  middle_ele = arr[middle]

  if ele > middle_ele
    binary_search_helper(arr, ele, middle + 1, end_)
  elsif ele < middle_ele
    binary_search_helper(arr, ele, start, middle - 1)
  else
    middle
  end
end

def binary_search(arr, ele)
  end_ = arr.length

  binary_search_helper(arr, ele, 0, end_ - 1)
end

def expect(r, expected)
  unless r == expected
    puts expected
  else
    puts "Success"
  end
end

## iterative version
def binary_search_helper(arr, ele, left, right)
  return false if left > right

  while left <= right
    middle = (left + right) / 2

    middle_ele = arr[middle]

    if ele > middle_ele
      left, right = middle + 1, right
    elsif ele < middle_ele
      left, right = left, middle - 1
    else
      return middle
    end
  end
  false
end

def binary_search(arr, ele)
  length = arr.length

  binary_search_helper(arr, ele, 0, length - 1)
end

expect binary_search([0], 0), 0
expect binary_search([0], 1), false
expect binary_search([0], -1), false
expect binary_search([], 0), false

expect binary_search((1..15).to_a, 8), 7
expect binary_search((1..15).to_a, 1), 0
expect binary_search((1..15).to_a, 14), 13
expect binary_search([2,3,8,15], 8), 2

破解密文是为了达到某种目的。

通过事实验证。 比如破解登陆密码，那么，拿这个密码登陆下就知道对不对了。再比如二战时候，破解的密文，就包含要攻打某某地的信息，只要真的攻打这个地方了，就能证明破解正确。

明文实际上就是看起来的“乱码”怎么办 接着破解。本来就是乱码的话，只能说，人家在逗你玩。。。

一个加密算法的安全性，是建立同时知道明文和密文的前提下，是否能得到秘钥。

可以呼吁，可以倡导，但不要给别人下定义。让人反感。

view 里面调用了 edit 那个路由，我猜是没声明找回密码的路由，试试这个 https://stackoverflow.com/a/7403353/2477886 。

如果还是不行，试试重启下 sidekiq。

[ 招聘] 多了一个空格， [招聘]

暴露我年龄

办活动不容易

CEO 人很靠谱

加油加油！望楼主坚持下去！

我觉得深究这些东西，还有一个原因，就是好奇。就是想搞懂到底是怎么回事。

从认知过程上来说，人理解事物需要时间。一个技能，连着学 7 小时的效果远不及每天学 1 小时，学 7 天效果来的好。

但效率是可以提高的。但对老师，学生、习题、教材要求都十分高。berkeley 有在教 SICP（简化版），学时是 4 个月。知识量非常惊人。

我个人来说，一部分靠学习（课程、老师、同事），一部分靠积累。

比如，定义变量、函数都能提高优先级，维护性更好。比如递归。比如分解问题。都是通过课程学习到的。

有些是观察别人（同事多一些）是怎么处理的。有些是别人告诉我的，比如 CTO 跟我 carrierwave 把一个开发级别的任务，变成配置级别的任务。一下就明白了一个 gem 的意义。

有些是自己坑自己，一边骂自己傻逼，一边默默填坑。

学习和训练都很重要。

比如我在学递归的时候，怎么都不会。是按照老师、教材（sicp）的思路，才开始理解递归。 之后写了几个月的 clojure（遍地递归），撸了门算法课（撸的第二门了。。。），每一次都有更进一步的理解。

不同程序员有不同的要求

我对 ROR 理解是，几个人，能力最强的那个，搭架子，别人搬砖。

在比如 simple_form，有一个人懂就可以，剩下的人，有问题，就找那个人解决就好。

新人开始的时候，能照葫芦画瓢就好。知道 rails 的概念，看完 guides，看完 ruby 元编程。之后了还要知道 rails 的实现思路。HTTP，数据库等知识。

最后，学习这东西，要想学好，需要付出很大的努力，包括时间、别人的指点、正确的方法。

@sec 如果只是想学东西的话，可以不要那个证书，就是免费的。