• 发帖方式不对,应该像这样发:https://ruby-china.org/topics/22992

  • 编程语言谜语 at 2020年09月03日

    隐隐透出浑浊的类型,桀骜不驯张狂的对象;空串·未定·非数·虚无,皆为假象。爬行的原型之链,不断自残的迷之回调,递归·循环·延伸至地面,知晓自身的无力吧!破道之九十,爪哇脚本!

  • Web 还是 APP 跟用不用 Rails 有什么必然联系?无非 Web 输出 HTML,APP 输出 JSON。难道 Rails 的优势在于写 HTML?

    我觉得社区的没落也或多或少跟这些莫名其妙的言论传到还没入门的新人耳朵里有关系。

  • Ruby 已经如此堕落了

  • 从楼主发的所有帖子当中发现。

  • “高手去做培训”说明什么?

    1. 编程高手的收入不如做培训高,培训出来之后最好的出路是做培训;

    2. 编程高手赚得太多,够用几辈子了,闲着没事亏本来给大家做贡献;

    3. 或者这个“高手”根本就是个半桶水。

    在山脚下的人无法分辨云端之上的山到底哪座更高。

    韭菜总得有人收割。

    无论韭菜的主观意愿如何,客观上看韭菜的行为总是在期待着被收割。

    吃亏之后能有所得,也算值得。

    以上同样适用于各技术社区各路大神的各种误导,看透之后就干脆不干涉。

    最后只恨收割人不是自己罢了。

    我没有道德。

  • 是哈弗 + 加州理工的,所以呢?

  • 如何从 MongoDB 迁移到 MySQL at 2017年11月02日

    我倾向于大家玩透了把坑踩遍了我根据自己的需要决定上不上。我不觉得有什么新技术是能带来翻天覆地不得了的变化的。

    现在还依稀记得某人写过一篇《我们不是在做技术决策,我们在玩》。

  • 可以看看你的代码吗?

  • 推荐些你看好的公司? at 2017年08月10日

    跟上次哪个创业公司一样,什么都还没见过,一上来就很有经验地我不要做这个不要做那个。会失去很多机会。

  • 免费赠送图书 at 2017年06月04日

    好吧

  • 免费赠送图书 at 2017年06月04日

    算法导论你要?我可以送你,很早买的,一直扔书架上吃灰。

  • 仔细想起来,对多数程序员来说,编程并不需要太过复杂的逻辑思维能力和太高的数学水平,可能更需要的是细心、耐心以及英文水平。

    另外,初高中的数学成绩不理想并不能说明问题,可能只是缺乏技巧和训练,看问题的角度太窄。很多问题成年之后带着目的再回去解,也不见得难到哪里去。人一辈子是场长跑,起步快并借此碾碎那些起步慢但本可以在将来实现超越的人的自信心的,只是运气好罢了。

  • 不是

  • JavaScript

  • 求推荐机械键盘 at 2017年03月15日

    来个链接吧: https://www.zhihu.com/question/23105050/answer/23706016

    蛮值得参考

  • 常见重构手法 (上) at 2017年01月20日

    其实我现在越来越倾向于认为,写代码的问题只能在招聘这一关解决。

    知道吸烟喝酒对身体不好还要吸的大有人在。知道要早睡早起、坚持锻炼身体才能好但还总是熬夜、几乎不怎么运动的更是数不胜数。人们总是抱着侥幸的心理,却没有意识到不好的东西一直在以你很难注意到的程度积累,只是还没爆发。在遇到什么重大变故之前,期望他人改变根深蒂固的习惯和观念几乎只能得到绝望。而软件开发这份工作,似乎代码再怎么乱也不会引起多大变故,对那些早就习惯了在泥潭里打滚的人来,最坏的情况也就是丢掉一份工作罢了。

    不停的提醒别人早点睡觉、坚持锻炼是很让人烦的,对别人的代码指指点点人家会觉得你吹毛求疵。对于非家人的身体健康,我们当然可以完全不管不顾,但现在开发软件总是需要“团队”来“合作”完成。

    我无意与任何人争论,只想求一个解。

  • 常见重构手法 (上) at 2017年01月20日

    #21 楼 @u1440247613 这样说,写代码还得先精通算命,写之前给这个项目算一卦。

  • 常见重构手法 (上) at 2016年12月21日

    #3 楼 @qinfanpeng 这个我觉得不一定吧。改遗留代码好像更多时候仅仅只是让人觉得难改,但是对认识到自己平时开发中的各种坏习惯并没有帮助。而且多数程序员好像总会有各种办法在原来的基础上打补丁的。就更别说从中总结出好的写法了。情况好像往往是程序员一边难过地写代码,一边还认为自己的各种想法和做法始终是对的。你要说一个方法的参数超过 2 个很多时候是个 bad smell, 多数人只会笑话你,然后继续写出自以为正确的代码,然后继续痛苦。

    像《重构》这样的书,很多人好像也就是看看而已,用他们的话说:“实际项目是很复杂的”。

  • 常见重构手法 (上) at 2016年12月21日

    感觉比起重构手法,价值观来得重要一些:什么样的代码是好的,什么样的代码是不好的。或者说有这些价值观是对代码进行重构的动力。请问大家是怎么对团队成员进行价值观传播的?对这个问题我一直比较苦恼。

  • 先粘贴两个链接,不知道 lz 是不是需要:

    领域模型的价值与困境

    再论领域模型的困境


    然后说点题外话。实际上我觉得写代码就是 3 件事:实现功能,去除重复,最后使表达清晰——主要是命名。

    但是在完成后面两个目标的时候,特别是是“去除重复”这个目标的时候,我们会不断的遇到困难。这时候就不得不动用你所在的那个世界(那门语言)所能提供的所有方法资源:封装、组合、继承、mixin、元编程等等。

    极端地去除重复必然导致模块粒度细化,各种最细粒度的模块互相结合又成为更粗粒度一些的模块,最后软件成为各种不同粒度(不同抽象级别)组合而成的一个组合体。它的内部因为没有重复而条理清晰。似乎很多写不干净代码的人会嘲笑这种情况只是个梦。

    所以,我觉得没有必要去纠结太多概念,也没有必要迷信各种框架的写法。有了原则,什么都好办,没有太多固定的模式。

    其实以我自己的一点经验,多写写脱离现有框架的东西。比如公司项目里看似比较边缘的,跟整体框架关系不是很紧密的,又没有现成框架可用的东西。把那些东西写干净的话,对自己的提升其实比在一个框架(比如 Rails)里写代码来得大得多。

    希望以上这些能有点帮助。

  • 新功能上线:公司/组织 at 2016年10月24日

    有离职的功能么?

  • 其实 OrderReview 跟 ProductReview 不是一个东西。

  • 不写测试代码 at 2016年10月20日

    其实需要测试的代码最需要的不是测试

  • #29 楼 @beiersi 就是说到了存盘点忘了保存就走远了。

  • https://ruby-china.org/topics/30905

    好有趣,点个赞收藏一下。

  • 其实 Filco 的红轴偏硬。红轴最好的是 Cherry 3494/3496,就是个头大,但是敲着那个轻盈,真没找着可以替代的。

  • #9 楼 @feitian124 追回来……这种就需要一个漂亮的回旋踢好吧

  • 办公室午睡最佳实践? at 2016年07月07日

    #28 楼 @xwf286 怎么说?

  • 假设 opened, closed 两个 scope 只是查询 state 字段的值:

    state = params[:filter] == 'closed' ? 'closed' : 'opened'
    @projects = Project.includes(:todos).where(:state => state).sorted_by_alias_asc
    

    假设用了 state_machine 还可以:

    state = params[:filter] == 'closed' ? 'closed' : 'opened'
    @projects = Project.includes(:todos).with_state(state).sorted_by_alias_asc
    

    假设你的这两个 scope 的实现很复杂:

    class XXController < ApplicationController
    
      def ooxx
        state = params[:filter] == 'closed' ? 'closed' : 'opened'
        @projects = Project.includes(:todos).with_state(state).sorted_by_alias_asc
      end
    end
    
    class Project < ActiveRecord::Base
    
      scope :opened, -> { 很复杂的实现 }
      scope :closed, -> { 很复杂的实现 }
    
      def self.with_state(state) #假如因为用了 state_machine, 方法重名了,另起一个名字。
        allowed_states = ['opened', 'closed']
        raise ArgumentError("Not allowed state: #{state}") if !allowed_states.include?(state) #直接把 __send__ 的参数暴露出去很危险,小心人家传个 `destroy_all` 进来
        __send__ state
      end
    end
    

    如果 includes(:todos).with_state(state).sorted_by_alias_asc 这一长串 scope 使用超过 1 次,还可以简化:

    class XXController < ApplicationController
    
      def ooxx
        state = params[:filter] == 'closed' ? 'closed' : 'opened'
        @projects = Project.ooxx(state) #
      end
    end
    
    class Project < ActiveRecord::Base
    
      scope :opened, -> { 很复杂的实现 }
      scope :closed, -> { 很复杂的实现 }
      scope :ooxx, -> {|state| includes(:todos).with_state(state).sorted_by_alias_asc} #
    
      def self.with_state(state)
        allowed_states = ['opened', 'closed']
        raise ArgumentError("Not allowed state: #{state}") if !allowed_states.include?(state)
        __send__ state
      end
    end
    

    假如 includes(:todos).with_state(state).sorted_by_alias_asc 这样的 scope 只用了 1 次,我也会像上面这样简化,但是如果有人把那串 scope 留在 controller 里,我也能接受。