(Part 2) Top products from r/ruby

There are some SUPER valuable insights in the replies of this thread that took me YEARS of programming to fully understand. So you did yourself a great service asking this question here :)

 

These insights are:

by u/cmd-t
> think in OOP in terms of passing messages from object to object. Every function call is actually sending a message to an object: a request for it to do something.

by u/saturnflyer
> Don't model the real world. Create the world you need.

by u/tom_dalling
> It's a common misconception that classes model real-world things. Classes model data, or behavior, or responsibilities.

 

To answer your question, yes, OOP is hard to master. As a result, there are many books written on the subject. And for a complicated system, even senior developers will have trouble getting the design right on a first try.

 

If you feel lost, it's not because you are not good at this. It's because the subject you are learning does require lots of time and practice.

IMHO, the best way to learn this is by actually working alongside with senior engineers in a real production project. So you can see some existing designs and also bounce ideas with other engineers.

While that might not be possible at the moment, you can

• look at existing designs of open source projects
  
• read books: Practical Object-Oriented Design in Ruby by Sandi Metz, Smalltalk Best Practice Patterns by Kent Beck These two might be a bit too advanced. I couldn't think of any good OOP introductory books of the top of my head, maybe Head First Object-Oriented Analysis and Design?
  
• practice and bounce your design ideas with other engineers
  
   
  
  Happy coding and I hope to see you posting more questions here! :D
  
  

One of the things we can do to make our lives harder in software engineering is muddle terminology. It adds needless friction to our job if when you say "flernb" you're referring to a widget but when I use say it, I'm talking about a whozit.

In low level code, we're pretty good about sticking to the first term that was coined for something. If you have a series of objects, each with a reference to the next, you'll probably call it a "linked list", just like I would.

But when it comes to higher-level architecture and design, names get a lot messier. Fortunately, some dudes wrote a book that tries to be the beginning of a taxonomy for architecture. Ultimately, the names they pick are arbitrary, but if we all agree to stick to them, then they become concretely useful.

What the author describes here is not a proxy. A proxy is a local object that represents a distant one, usually on another machine or process. It's not a very common part outside of distributed systems.

The author created an adapter.

Qt is used quite a bit; there should be numerous books/sites of use. I myself use PyQt, the Python API, of which there is an astoundingly good how-to book. I don't know if there is a Ruby-specific version, but the concepts are quite general and would still be useful.

There is also a Zetcode tutorial. These tend to be basic, but are solid.

Also, if you going full-hog with Qt, Qt basis its code on a slight variation of MVC, called Model-View-Delegate.

> Failing that, are there any good cheatsheets/references for JS "gotchas" and unusual features that devs from other languages might not be familiar with?


There are entire books dedicated to this! (Also some entertaining talks.)


Here are some good JS books not aimed at total beginners:

• JavaScript: The Good Parts
  
• Professional JavaScript for Web Developers
  
• Effective JavaScript
  
  
  Bonus (to give you a sense of the kinds of "gotchas" you'll find in JS):
  
  
  // Even though you pass in numbers, JS sorts them lexicographically
  > [5, 1, 10].sort();
  [ 1, 10, 5 ]
  
  // You "fix" this by passing in a custom comparator
  > [5, 1, 10].sort(function(a, b) { return a - b; });
  [ 1, 5, 10 ]
  
  // This probably makes sense to someone, somewhere
  > Math.min();
  Infinity
  
  > Math.max();
  -Infinity
  
  // Some things are best left unknown
  > {} + {};
  NaN
  
  > var wat = {} + {}; wat;
  '[object Object][object Object]'
  
  Here are a bunch more in quiz form.

I love Ruby Koans.
If we're going back to other references for general programming and algorithmic knowledge I would also recommend:

• Don Knuth's "Art of Computer Programming"
  
• Abelson, Sussman and Sussman's "The Structure and Interpretation of Computer Programs" (free)
  
• Reading lots of code. Reading other people's code and learning from it is one of the most valuable reference materials around. :)
  
  Edit: "general" was the wrong word to use. Thanks worst!

The UK Amazon site has the book and it's free until Christmas:

• http://www.amazon.co.uk/dp/B00QK2T1SY
  
  If you like the book, it'd be nice to leave a review. There's only two reviews on UK Amazon. Both five star reviews! There's three dozen reviews on the US Amazon site (almost all 5 star reviews).

The game piece example is about using singleton to, yes, conserve memory, with simple data types. For instance, you'll note that ruby itself, analogously, uses it with integers. 101 is always exactly the same object in ruby (which is necessarily immutable for that reason; in general, singletons that have any mutable state at all are going to give you nightmares, especially under concurrency). (You can verify this checking 101.object_id, always the same for any 101 anywhere in a program execution. This is not true for string "101", which is of course also mutable).

In the "Gang of Four" book, which introduced the notion of "design patterns" in programming as well as the "singleton" pattern specifically -- I think this particular pattern would actually be identified as the "flyweight" pattern, rather than "singleton", although it's implementation might in this case be in terms of singleton.

I probably wouldn't be likely to actually implement a chess game that way. I think the "flyweight" pattern is pretty specialized in contemporary programming, where RAM is a lot more bountiful compared to when the GoF was writing. The times you need to conserve RAM this way and it's worth the added complexity are probably rare (although probably not never ever encountered).

I'm getting good mileage out of David Copeland's Build Awesome Command-Line Applications in Ruby 2 (2013). For Ruby-specific best practices (I'm coming from PHP), Sandi Metz' Practical Object-Oriented Design (2019) and Russ Olsen's Eloquent Ruby (2011) are opening my eyes to how it's done here. In particular, Metz' focus on the role of messages in OO design has changed my approach to planning and testing - just in time for a critical project.

It can be hard at first, but it's really worth it. If you surpass the 100 lines limit for a class it's surely doing too much, try splitting it into several smaller classes, or at least some concerns.

Something which can help with that is Refactoring: Ruby Edition, it's more of a senior-level book than POODR, and you can't read it from cover to cover, you have to stop at each pattern, see if you can apply it, then repeat, but it's definitely a great resource, and it helps you "develop an eye" for bad code.

Reek seems to use some smells from the Refactoring book. Not sure if all of them can be analyzed statically though.

EDIT: I didn't know Sandi was updating POODR, I think she's just working on 99 Bottles of OOP, her new book.

• Pickaxe is a good place to start
  
• Everyday Scripting is easy to get into
  
• Cookbook is good too
  
  I'm not completely sure what you mean by using Rails as a front-end for your script data, but it and Sinatra are good for uploading/displaying data processed on the server.

If you're new to Ruby, Head First Ruby is a really good intro book, follow it up with POODR by Sandi Metz.


**

The Ruby Programming Track on Odin Project is also good for someone new to Ruby.

I'm looking for something similar - not so much a 'learn ruby' book as a more technical 'best practices' type of book - something more in line with Effective Java or the Effective C++ series.

For books I'd recommend:

Practical Object-Oriented Design in Ruby

The Rails 4 Way - Good for after you've covered the basics of rails.

The Little Schemer will teach you to truly think recursively. It teaches via a continuous series of question and answer.

I like Learn to Program by Chris Pine. but what really made me understand Classes, Methods etc was Beginning Ruby

if you are hardcore and have a year: https://www.amazon.com/Computer-Programming-Volumes-1-4A-Boxed/dp/0321751043

http://www.amazon.co.uk/gp/product/B00QK2T1SY?keywords=Learn%20Ruby%20on%20Rails&qid=1450740356&ref_=sr_1_1&s=digital-text&sr=1-1

they made a smalltalk companion book

So, these OOP concepts might not make sense right now, but as you gain experience youll know when to use what technique. IMO, use what ever technique better conveys what you are trying to do.

What helped me was reading some refactoring books and reading on anti patterns. Refactoring will teach you how to fix bad code and anti-patterns teach you what bad code is.

Youll have to write some bad code before you get good at it; just code.