1. 13

Hey folks, here’s the talk I gave two days ago on improving OO design in Rails apps, mostly applying taken from functional programming in a way Ruby/Rails devs don’t see as weird and unidiomatic. Rolling this around in my head is why I keep posting so many stories about FP, dynamic languages, OO design, and the intersection of same.

A silly trailer for the talk and signup for ongoing info + slides with speaker notes is here: https://push.cx/2015/railsconf

  1.  

  2. 6

    This is not relevant to the meat of your talk and I know the code you showed was old, but it stuck out at me because it’s caused me problems before so I thought I’d mention it.

    def valid?
      @str =~ /\A[a-zA-Z0-9]{8}\Z/
    end
    

    The uppercase \Z anchor matches even if there’s a newline at the end of the string, so “abcd1234\n” would be a valid call number according to that regex, though you probably don’t want that since it’s not alphanumeric and not 8 characters. The lowercase \z anchor is probably what is wanted and would require just “abcd1234” to match.

    1. 4

      Thank you, I was unaware of the distinction. :)

    2. 4

      I thought this was a great talk! As a long-time Rails dev turned Haskell dev I’ve seen all the problems that come with large codebases in Rails and have had many of the same thoughts but not as well expressed as in this talk.

      I really wish we could have support for gradual typing in Ruby like Flow/TypeScript for JS.

      Or even just some decent static analysis tools that could enforce/analyze the patterns in mutable/immutable/nofx/fx.

      This talk made me hopeful that maybe some time in the future it can be possible to write a large ruby codebase that doesn’t end the way they usually end up.

      1. 4

        We might see some static typing features.

        And, yeah, one reason I emphasized several times the idea of immutable objects not calling mutable ones and nofx objects not calling fx ones is that I can’t see any way to enforce those rules. It’s probably possible to write a Rubocop rule ensuring they don’t refer by explicit class name, or argument with the exact name of a mutable class, but that’s pretty flaky. If Ruby didn’t have “freeze” something like it could be built in that would work against anything but an explicit attempt to subvert it (which is the level at which Ruby enforces its “private” convention)… but I think it would be impossible to prevent an object from having side effects.

        I’m glad it gave you some hope. My hope is to help the wonderful Ruby community be happier writing more reliable and maintainable software, and this talk is my first big step.