• 😆 读完感觉LZ的主要目的是想写一篇文章可以放在blog里……

  • 模板里根据逻辑判断一下 简单的 if..else 就可以了

  • Rails 程序员如何进阶? at 2016年01月12日

    编写一些业务逻辑上的代码真的感觉不到提升。

    首先你可以尝试去想一下怎么控制业务逻辑的复杂度, 速度和可维护性的取舍, 编码规范等等. 这在后面遇到比较复杂的项目时是非常非常非常重要的.

    再就是培养自己工作方面的思维方式, 比如接到一个任务先去站在这个产品的角度去理解这个需求, 明白为什么要做这个, 这样才能更好地发挥你的主观能动性. 举例来说, "网站在新用户第一次登录后要弹出一个提示框, 让用户完善信息". 接到这个任务时先想一下为什么要做这个. 假定这个目标是"收集信息以便后续提供更多服务, 改善用户体验从而增加用户粘性", 那么明确目标之后就想一下怎么才能更好地实现它. 例如用户大多比较懒, 不愿意填写太多东西, 或是用户不愿被频繁打扰. 那么就能得出两个结论: 1. 尽量让用户填写最需要的东西, 要精简, 大表单是完全不可取的, 并且最好让用户提前知道只需要填写很少的东西. 2. 在用户关掉这个提示框后要设定在某段时间内不再显示, 否则会引起反感. 至此, 有了目标,有了注意点, 再去想一下怎么实现就能比较好地做好东西了. 至于到后面更加纯熟了就可以更进一步, 如果是外包的话, 当客户说想要 A 的时候, 不急于答应, 而是问为什么要 A. 因为你是专业的, 根据客户的真实需求, 你可以给出更好的建议 B. 这样不仅更好地完成了客户的需求, 也增加了客户对你的信任和好感..

    我是认为,在公司里, 技术是手段, 做好东西才是目的.

  • #17楼 @haoxilu 最近略晚, 都是10点半左右. 计划明年9点睡..

  • #10楼 @chairy11 😄 加油. 刚开始比较困难 不容易入睡 比较简单的办法就是 9点钟就断网 关手机电脑 然后热水泡脚. 也不要看书. 什么也不要做,就是待着. 总得来说就是让自己整个进入休息的状态. 一般半小时左右就哈欠连天了. 大概坚持过半个月就能习惯了. 过半年就真成习惯了..

  • 我是在做胃镜后吃了不少的药依然无效后恢复的正常作息. 几年下来已经完全不习惯晚睡了. 早上早早起来那种感觉特别舒服, 文艺点说是"看着整个城市醒来" :trollface: 而且感觉一天也变得更长. 5点起床9点上班的话, 在上班前可以锻炼一下,合适地吃个早饭, 然后看会书写写代码或者玩会游戏 开始上班的时候感觉已经过了好久. 其实也不过是把以前晚上晚睡做的事情挪到早上. 但是身体感觉完全不一样. 以前的胃病,牙龈出血, 脸上的小疙瘩, 皮肤黯淡无光,早上起来不是神清气爽而是疲惫不堪, 工作到下午4点就各种不舒服等等等等都基本搞定.

    所以从我个人经验来说, LZ 要么尽早下决心改变,要么等着身体警告你必须改变 😄. 还是自己拿着主动权更好一些. PS.做胃镜的感受实在是... 太难受了.

  • routes.rb 里相关内容删掉就算是完成了对外关闭.

    然后把相关的 redirect_to, action 本身和相关的 views 删掉应该就没了.. 除非写的很奇葩 那就另说了

  • 好像.. 是这个

  • Ruby 不写测试不心虚么.. 一个误写的字符就能搞挂程序 这算是非编译型语言优点还是弱点呢 :trollface:

  • Connection refused 难题!! at 2015年11月25日

    运行的好好的,就是昨晚改了点东西之后才出现这个问题,所以一直很纳闷。

    在这里找吧

  • Ruby China 生日快乐~ at 2015年10月28日

    👍 👏

  • 👍

  • 交流中误解太多 扯淡停止

  • #13楼 @blacktulip 看清楚上下文

  • #9楼 @peter 不理解为啥你会拿数量来说事.. 就算是冷兵器时代也没有这么算的

  • 难民的话,真正冲突起来大概也就是当年土客战争的样子.. 何况政府这个掌握着最强大武装力量一方的立场是不言而喻的.

    通过子宫这个.. 就难说了

  • $('button[data-disable-with]').each(function () { ... }) 我们是这样做的

  • 赞同 LZ, 十字螺丝钉用十字螺丝刀, 一字的就用一字的.

    从个人倾向来说, 如果一件事 几个语言包括 Ruby 都能干, 那肯定选 Ruby. 因为它趁手,用着舒服,写着快乐 😄

  • 从小的方面来说

      OutsideService::SHARED_SERVICES.each do |service_name|
        name = "share_to_#{service_name}"
        attr_accessor name.to_sym
        attr_accessible name.to_sym
    
        define_method("#{name}=") do |val|
          self.instance_variable_set "@#{name}", Judge.true?(val)
        end
    
        ...
    end
    

    这样的方法定义方式可以把大量重复的代码砍掉,保持最精简.

    从代码结构上来说, Duck Typing 是另一个让代码变少的概念 用 Ruby 内比较典型的 to_str 来做例子

    class A
       def to_str
           "I'm a string because I'm respond to 'to_str'"
       end
    end
    
    a = A.new
    puts("Are you a string ? --- " + a)
    
    >> Are you a string ? --- I'm a string because I'm respond to 'to_str'
    
  • 书不在多,精读才行 at 2015年09月18日

    #8楼 @ericguo 希望各位高人,能提供本重构的书,ruby进阶的书 ..

  • #4楼 @coooldfarmer 换个方式来想这个问题, 加个if, 当出现重复的字符串的时候就重新生成一次 直到不重复 这样就可以了

  • 书不在多,精读才行 at 2015年09月16日

    这本感觉很好 Confident Ruby

  • #18楼 @blacktulip 赞同

    像我们平常最常用的 Post.find(params[:id]) => Post.find(1) 上下文已经让这个很好读了 并不需要 Post.find("The first post of hello world").

  • 这个问题怎么会牵扯到可读性呢? LZ 你举个例子看看?

  • 提个可能相关的事情, 如果你的程序需要辨别获取这个东西, 那你需要考虑一下是不是设计方面有什么问题. 参见 Tell, Don't ask . 当然如果仅仅是好奇语法就当我没说..