• 小白总结：在使用 Ruby 发现一些较为巧妙的写法 at 2017年01月06日

    #9楼 @Canmel 可以直接

    def xxx
rescue #可选
ensure #可选 不管是否发生异常是否捕获异常都会执行 (finally)
end

    不过你写的相当于的那个形式少了一个end, 因为给了begin， rescue就跟着begin了，begin和def各自有一个end

    说到单独用ensure有个套路 (可能用不到但会读到)

    def foo  #不希望出现在异常回溯(backtrace)中的方法，如就是简单封装另一个方法bar
   bar
ensure
   $@.shift if $@ # $@是异常回溯的数组或nil(无异常发生)，移除掉第一项(含有foo的这一项)
end
  • 做了一个关于换源的小工具 at 2016年12月02日

    #14楼 @jasl 其实这样的回答我是认可的，而且我基本上是暗自钦点rc源了（见#11我的解释）。但是作为脚本，并且我的标题是换源工具(中立向)而不是换RC源的工具(特化向)， 毕竟我和楼上的dalao不一样，并没有ruby-china的钦点的立场。

    作为换RC源的情况可以做另一个工具或者加选项，那又是另一件事了，起码我不能用一个中立的repo，明显做钦点的事情吧。其他的回答里面提到的information security(vulnerability)的问题，跟这个工具在意的information safety(availability)的问题还是有点不同的。

  • 做了一个关于换源的小工具 at 2016年12月02日

    @ #10楼 @jasl

    Ruby China 镜像是国内最首选考虑的镜像（你承认的），那直接介绍和使用 Ruby China 镜像就已经解决问题了，遇到访问不畅的情况，及时提交 issue。

    前一句我承认，后一句我只能说我一般不提交也不建议优先issue，一般提交pr，这样对于当时发生问题的个例解决问题的时间进度比较有利。

  • 做了一个关于换源的小工具 at 2016年12月02日

    #10楼 @jasl 说两个事， 第一，

    既然假设用户不知道 Ruby China 镜像，那更不会知道你的脚本，用户真不知道 Ruby China 镜像，直接告诉他 Ruby China 镜像就好了

    用户不知道RC镜像但有可能知道我的脚本，事实上我是QQ群党，之前论坛上来得不多，也同样很多不来论坛的人士。这是论坛的普及问题，如果普及力度不够再怎么样也只会有种钦点的感觉。

    第二，

    安全是最重要的问题，任何时候都必须选择受信任的源或者镜像

    用户真不知道RC，也以跑起来为第一要务的情况，是不能光说安全的。 给你讲个真实的故事，有个人在rails群找源，当时还是 ruby.taobao.org 的时代，然后其他人随口说了句淘宝源。然后他去淘宝上面逛了一下午没看到卖源的，接着他就从http://rubygems.org 手动下载* .gem然后本地安装，然后这些gem又有依赖gem吧，然后人就继续手动解决依赖关系，反正最后也就陆续装上了几个gem，也没有解决他的主要问题。

    虽然当时现场是当笑话看的，这也可能是个个例，我想说的只是，光说淘宝源或者ruby-china源，知道的还是知道，不知道的还是不知道。安全问题当然重要，但人家要求的是availability的时候强调security是毫无意义的。

    第三

    对于环境问题，Ruby 在 Windows 环境的生态就是不好：
    Ruby 官方不提供 Windows 的构建版本，官方推荐的 Ruby Installer 不能及时跟进 Ruby 最新版本

    https://github.com/ruby/ruby/blob/trunk/win32/configure.bat
    请解释用这个成功跟进到HEAD，而且其依赖工具链可以只用winsdk.exe安装的理由。
    可以理解你把[*-mingw32]当做win上全部ruby构建的理由，毕竟[*-mswin32]的case是另一个折腾方向。

    且gem instaill rails 现在可以直接在windows装。

    第四 我所谓的非主流只是自嘲而并不是什么把柄，你所谓的主流不要给人一种钦点的感觉，世界上都在打破和融合原来的界限，比如rubyinstaller从无到有， rails现在无障碍在windows下gem install，而我们还在拒绝给windows用户技术支持，是想等彻底成熟了直接拿来别人的成果吗。

  • 做了一个关于换源的小工具 at 2016年12月02日

    #9楼 @kgen

    大家关心的安全问题

    • 自动找个源居然不是ruby-china.org第一这才是最危险的。

    为何不直接写呢

    • 有两个option这是公认了的，即便只有一个option直接写会给人一种钦点的感觉不够灵活，写程序总要在解决现在问题基础上泛化一下解决几个未来可能的问题。
    • 未来可能的问题是什么呢？
      • ruby-china的url被挤下去了
      • 临时局部地区的不可访问

    我这个脚本并不是一定要钦点本论坛的源或者黑它的立场。你知道我为了跟进这个结果换了多少个百度关键词吗
    如果想要完全钦点的你可以rails new app -m https://raw.githubusercontent.com/RGSS3/rails-new/master/zh-CN/win/app.rb

  • 做了一个关于换源的小工具 at 2016年12月01日

    #6楼 @hging 见我的解释的第一节

  • 做了一个关于换源的小工具 at 2016年12月01日

    #5楼 @huacnlee 我长期在windows下维护，mirror list也是另一种方式（见repo），但我也希望发现更多的源，而且曾经连不上ruby-china用了备选sdutlinux一段时间，速度还是可以的。

    • 我说这么多就在于表明，即便只有两条路（甚至可能只有一条），也还是可以做一个泛化的工具，因为pragmatic way。 而且是Ruby解决Ruby的问题，不是某shell解决ruby的环境问题。

    • 为何不能换环境的问题，可能我对环境的依存不是那么大吧，而且ruby系列对windows的支持是越来越好了，至少我现在接触到的问题里面，只有rubinius是官方明确表明不支持windows，而且我也尝试了一周还是移植失败了的。 至于其他的问题…… 不过我的路线可能比较非主流，11年开始玩RPGMaker，RPGMaker的Ruby不能require二进制插件的问题（比如socket.so），以及无法使用Fiddle作为windows回调函数的问题，到现在也找到了Ruby way的解决方法。而且我现在主要的方向是Ruby生成，Ruby的runtime和生成代码的runtime可以不在一个环境，所以对环境的依赖真心不大。

  • Ruby 中读取大文件 at 2016年12月01日

    如果要提取数据量大的话，直接全部读入然后扫描换行符位置然后提取可能更快，毕竟相当于全部缓存或者按行缓存和拼接。时间空间平衡度是不一样的。

  • 麻烦问下大家关于 ruby 的 throw 和 catch 的问题 at 2016年12月01日

    ruby里面异常处理的普通来说是raise / rescue
    要进行继续处理而言用yield/Fiber.yield甚至callcc
    而catch/throw的作用并不像在其它语言里面一样是异常处理，更多的是流程控制。
    比如快速跳出多重方法/catch块，throw的作用是跳到同名catch块的后续，catch块可以有返回值，一般是最后一条表达式的值，发生throw时，如果throw带了第二个参数那么以这个参数作为值
    比如 

    a = catch :foo do
  catch :bar do
     throw :foo, 3
  end
end

    则throw直接让catch :foo返回且之后a = 3

  • 做了一个关于换源的小工具 at 2016年12月01日

    #3楼 @marksloan 楼主我读书不多，当然认可层主这一楼的方法。层主的担忧不无道理，但是也并不见得有这么大的风险。毕竟层主的描述是有具体上下文的，而我这个脚本的写作也是有具体上下文的，并且两者并不太一样。

    不过既然层主是谈解决方案，这里谈一下这个脚本作为微型产品的合理性的角度，并非一定要争论什么的，而且真的出现了此类攻击，甚至可以作为rails或相关gems的安全性的一个技术研究蜜罐，见详述 ：

    • 用户群的角度(谁会用这个脚本)：

      • 已有gems.ruby-china.org或者其他长期固定源的用户自然不需要用。
      • 经常不在一个地方或移动式开发，或
      • 演示给新手或需要快速展开的环境，出来什么网站是可见的，并且不需要临时购买或者注册翻墙工具的情况，（甚至层主还给了推荐码）。
        • 对于其他人，当然可以直接换成gem sources -r https://rubygems.org/ -a http[s]://gems.ruby-china.org/
        • 对于新手，应当说两句话，https://rubygems.org/ 是最权威的源，http[s]://gems.ruby-china.org/ 是在天朝最应当首选考虑的镜像，这么说不致于造成误导和混淆。

    • 开源自动化的角度

      • you can fork it as your own tool
      • 这脚本是从人搜索Ruby源的方式和角度出发的。(即用户未知 gems.ruby-china.org )
        • 如果木马站针对这个我今天至少就维护了三次代码逻辑(对应也换了三个 codepad.org 路径)的地址进行欺骗
        • 甚至不出一个月排名就挤下去了 ruby-china.org
        • 手动百度源的用户一样中招hhh
        • 强行替换和只从百度取属于体验问题而并非绑架问题，-ropen-uri -e 本来就是geek角度，从geek角度到UX角度本来就有一个过程。

    • RubyGems源的角度（源的问题，不能算是完全解决）

    • 被木马站针对的问题的对应以及攻击的角度

      • 常用的 curl -sSL https://get.rvm.io | bash
        • 如有欺骗攻击，与我这里是同类的，虽然是个ssl，能到层主说的威胁程度，那也扛不住证书欺骗和DNS污染。
        • rvm.io 也要求用户首先用gpg校验，而存在一些人和教程也没进行校验步骤。
        • 如果出现了层主所说的攻击，如果只给一个月时间，似乎更应该走rvm的路线更加广泛。
        • 至少也是 http://gems.ruby-china.org/ 的DNS污染更加方便
      • 木马具体逻辑放置的位置及工程的角度:
        • 一般不会是gem中
        • 因为部署时就该用正式的方法去bundle install一套，gem中如有奇怪的逻辑也带不到对面（但生成的除外，下述）
        • 可能是生成器等生成的代码中
          • 开发者可能会直接修改的，如controller和一些启动配置等。如果是层主那种高要求的担忧，是逃不过Code Review的
            • 当然也有安全级别高但是不进行Code Review的情况，这个问题出在人员。
          • 开发者不直接改的，可以追溯到bundle install中，同前一节。
        • 层主和我都能想到奇怪的攻击方法，还能绕开这个部分的1,2节，但没有进行攻击，从经常使用Ruby进行开发和维护的开发者数量来看，孤陋寡闻的我暂且认为绕开并且攻击而且大面积扩散是大牛闲闹着玩……
          • 真的出现了此类攻击
          • 并且绕开了新手用户群和工程代码质量管理
          • 那其实有把用这个脚本的工程作为蜜罐探讨rails或有关的gems中植入木马的技术问题的必要性了，也不只是这一个脚本的个例了。