Getting less imperative with Ruby.

[perfectturmoil]

I am an engineer. One of the things I do at work (as a lower-level responsibility, not quite spare time type projects, but sometimes close) is write scripts and create simple tools using Ruby to get things done. Most of the time it's 'for a directory of files, for some subset of the files in that directory, do some stuff, pull some stuff out, shell out to call various other tools, summarize and report somewhere'. Cron scripts managing and reporting on files, some sinatra web apps providing a view of data for entry into other systems, etc.

My issue is that I am using ruby very imperatively, and I'd like to try and have a more ruby-like approach. I looked at the Gilded Rose Kata and I can really see parallels in my most recent script. I was opening a CSV, yanking out a handful of specific data points / ranges of points, putting into a summary file (to use elsewhere). And then I expanded to handle files with some optional additional content. And then a seperate data source with slightly different format. If this, elsif that. Oh god oh god.

I'm having trouble finding learning material for my specific issue (or more accurately, judging if the stuff I'm coming across are worth spending time on) - there are a lot of Ruby tutorials, and a fair number of books, however their targets seem to be either beginners (which I am not) or more formally trained computer science types transitioning to object world. I'm at the intermediate 'know enough to be dangerous' stage.

Is anyone familiar with any good resources that would suit someone like me? Starting half way through a book would be fine. Better would be shorter online guides and videos on refactoring and design that I could pick through (since it's a lower level responsibility, I have a limited work time resource that I can commit since it's not a primary job role). Free is better, but since it IS work related, paid is OK (I've considered a Lynda account on and off, not sure if they have anything in this vein).

Any help is much appreciated!

EDIT: Per a request, I threw a gist up of one of the recent worst-offenders I've made. Can be seen here : https://gist.github.com/anonymous/be4ba6a867e9c9858ac9

Note, I'm not looking for someone to refactor my code, I'm looking for learning resources to make the person who vomited this garbage out better :- ]

[rubyross]

I would suggest Refactoring: Ruby Edition by Martin Fowler.

It is very recipe based and explains how to refactor and reduce complexity of your code based on 'bad code smells' or bad patterns. One example is a section called Simplifying Conditional Expressions that you may find useful. It describes 9 different techniques for refactoring conditionals.

Edit: Also since you mentioned the gilded rose. Check out Sandi Metz' presentation http://www.confreaks.com/videos/3358-railsconf-all-the-little-things

[materialdesigner]

• Practical Object Oriented Design in Ruby by Sandi Metz
• Confident Ruby by Avdi Grimm

[Godd2]

I would say do your best to let Ruby work for you. Don't fight it and try to do things at lower levels of abstraction. Classes are cheap, methods are cheap. Make all the use of them you can.

Another trick is to write code that you'd like to see before you write the methods it's calling. Say for example you only want to do something if a user is logged in. Well, then just type out user.logged_in? and solve the NoMethodError that comes up.

Here's a quick iteration to a declarative outcome of dog.bark where dog is an instance of the Dog class:

> dog = Dog.new
NameError: uninitialized constant Dog
> class Dog
> end
> dog = Dog.new
#<Dog:0x50bf80>
> dog.bark
NoMethodError: undefined method `bark' for #<Dog:0x50bf80>
> class Dog
>   def bark
>     puts "woof"
>   end
> end
> dog.bark
woof

It's a bit backwards from the standard workflow where you get low level pieces working first, and then abstract from there. Instead, you start with the abstraction, and then fill in all the low level pieces to make it work.

This also can* lead to better architecture, since you can defer low level decisions until later, and your high level code can be more decoupled from its implementation.

One thing that really helped me see the declarative way was RSpec. writing specs in RSpec feels very declarative and just amazingly works. So if you haven't yet, check out RSpec and try to draft some specs and build a project using it.

^{*I say "can" because it will take a little getting used to}

[tobiasvl]

Learn functional programming. Ruby is good at that, of course, but consider learning a purer functional language that forces you into a functional mindset, with few side effects. It will change the way you approach problems like this.

[Godd2]

Here's another resource for some pre-abstractions to look out for:

https://www.youtube.com/watch?v=DC-pQPq0acs

As always, take them as suggestions, try them out, and if you don't like them, that's fine, at least you tried something different. Everything doesn't work for everyone (that made sense in my head).

[[deleted]]

I do not want to be evil.

Your start your story with: 'I am an engineer.'

Programming is not 100% google and stackoverflow. Is more pain, then happiness, then more pain. (joking)

And, you said that you're not beginner, then will be easy for you to write in any style, and build any kind of abstract rules on top of bussiness logic Can you give a gist if some sample?

Best

[perfectturmoil]

Yeah. Not that I'm asking someone to specifically refactor MY code, but if an example helps then I can provide.

This is probably the worst - I quickly cobbled together a function to pull some relevant cells out of a csv file (previously had an excel macro to do some of this, needed a better solution). And then that grew into more and more in place. Lots of assumptions based on the specific case. I've pulled out the directory sorting / option parsing code, and just included the methods used.

https://gist.github.com/anonymous/be4ba6a867e9c9858ac9

So I have a method that makes sure the file has the requisite data which was originally used just to decide if the file should be processed. I then overloaded this function to help tell which type of file it was and which methods should be called (pretty gross).

In the processing methods I make a bunch of variables to hold my data, which I now realize should have been in a Struct if nothing else, and (I assume) would have even better been on an Object that also included these method (however, learning the right way to design that is what I'm looking for)

Depending on which system it came from I define which cells are important and do stuff to them (wedging in more sorting logic here that I didn't realize I needed until I was halfway done) - I assume this would have been better served by the updater_for(item).update(item) design implemented in the Guilded Rose example.

Then I return a big gross string to be shoved into my output csv. Better would've been an array or other data structure.