Ryan Bates

Producer of RailsCasts - Ruby on Rails Screencasts

[Ryan Bates @rbates]

I finally set up a Bluesky account. You can find me at https://t.co/Rd0CG5ZMq8

I'll continue to post on Twitter/X as well.

[Ryan Bates @rbates]

@chreyesg @sortpop @linode Fixed thanks

[Ryan Bates @rbates]

I no longer recommend DigitalOcean for hosting. They pulled the rug out from under me. RailsCasts has moved back to @linode.

[Ryan Bates @rbates]

@excid3 @woochaq @stripe Thanks Chris! Made my day.

[Ryan Bates @rbates]

What an awesome little game Replicube is. It’s like Picross 3D meets shader programming. The puzzles are a fun challenge and the interface is charming. Thanks @walaber! https://t.co/KtrCIxlQLp

[Adrián M. @amugnolo]

@rbates Service objects are not much better. A great read by @pragdave about this. https://t.co/xPA3XmTMnK

[Ryan Bates @rbates]

@amugnolo @pragdave That’s a great article, thanks for sharing. I basically code in a similar style that Dave does here. Create modules with class methods for the behavior. Use classes/objects as bags of data with minimal logic.

[Ryan Bates @rbates]

90% of the Ruby code I’ve written the past few years has been class methods without shared state. The code has clearer dependencies and is easier to read, test and maintain. OOP has its place, but I don’t think it fits the majority of web-app logic.

[Ryan Bates @rbates]

@jorgemanru Yeah, I might write up a blog post on the topic sometime.

[Ryan Bates @rbates]

@lazaronixon I always use named arguments unless it’s a single argument with the name of it in the method. Most of the time it’s 1-5 args.

[Ryan Bates @rbates]

@MorriceGavin @ismasan I generally don’t follow the functional core approach. Having a pure method is great, but I don’t go too far out of my way. I find most web apps rely so heavily on the database that a functional core leads to a lot of layers and indirection. I don’t like layers.

[Ryan Bates @rbates]

@justinamarsh Hard to do on Twitter. I might make a blog post about it some day.

[Ryan Bates @rbates]

@MorriceGavin @ismasan Exactly, those dependencies are very clear. You can see what is being called and follow them. It’s also easy to reverse-lookup to see what is calling a given method.

[Ryan Bates @rbates]

@gagsdfhy I should add, if you do pass the same set of arguments around frequently you can put them into a hash or data object.

[Ryan Bates @rbates]

@gagsdfhy There is some repetition but it isn’t bad with the Ruby shorthand for named arguments. I thought this would be a bigger issue but it really isn’t.

[Ryan Bates @rbates]

@mahdix I’m actually not the greatest fan of functional programming either. I’m fascinated by it but the constraints are a little too much for me. I often find functional code harder to read and follow compared to a more procedural style.

[Ryan Bates @rbates]

@ismasan @MorriceGavin Right. No instance variables or hidden state. Just arguments.

[Ryan Bates @rbates]

@talent_overflow My reasoning is less about breaking existing code and more about keeping the flow of the code straightforward to read.

[Ryan Bates @rbates]

Whenever you’re tempted to reuse a method that *almost* does what you want: Stop, duplicate the method, make the modifications, and then refactor the actual duplication.

[Ryan Bates @rbates]

I Googled “capybara drag_to” and the results caught me by surprise.

[Ryan Bates @rbates]

Anyone else find GitHub code diffs near impossible to use in Safari lately? Slows to a crawl and/or doesn’t render.

[Ryan Bates @rbates]

@jnstq Difficult to grep, difficult to read. Harder to track down bugs when they do happen. Overall a maintenance headache.

[Ryan Bates @rbates]

Ruby’s metaprogramming is like a forbidden fruit. Always there tempting me, and I almost always regret using it.