MLB app

[André Luiz Abdalla Silveira]

Guys, I'm making a baseball league application, and I'm facing some challenges. Biggest of them is trying to make a match simulation method (I didn't think a view was necessary for it). This method is in matches_controller.rb, but again, there isn't any view for that. How do you think I should handle it? Have you ever faced any similar trouble?

Git repository: https://github.com/dede999/myMLB

PS: I love sports at all, so if you have a hockey application to share (it doesn't have to be written in Rails), please do it

[Hassan Schroeder]

On Fri, Dec 22, 2017 at 4:16 PM, André Luiz Abdalla Silveira
<andrel...@gmail.com> wrote:

> Biggest of them is trying to make a match simulation method (I
> didn't think a view was necessary for it). This method is in
> matches_controller.rb, but again, there isn't any view for that. How do you
> think I should handle it?

I think you should read as much as possible about Object-Oriented
programming right away :-)

"Practical Object-Oriented Design in Ruby (POODR)" by Sandi Metz
is a good intro, but there are lots of other resources online.

That "simulate" method does NOT belong in a controller, it belongs
in a model, and I would also recommend you step back and try to
describe the problem(s) you're trying to solve in the form of tests,
breaking the steps down as much as possible. Flowcharting on a
whiteboard or sheet of paper might be useful too.

Good luck!

--
Hassan Schroeder ------------------------ hassan.s...@gmail.com
twitter: @hassan
Consulting Availability : Silicon Valley or remote

[radhames brito]

Hi andre, like hassan is pointing out, your code wil become very needlessly complex pretty soon because you are not separating responsibilities or the classes, the controller is a class that should only be handle handling where to direct the request, not actually performing operations on the data or what ever. If you keep going that route the controller will become a huge procedural app in itself. You should have something like this there

```

Match.new(params[:match_data]).simulate()
```

And then simulate should hide all that complexity from the controller.

In any case, please explain better the problem you are trying to solve.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/dc886a29-58d4-497a-a7dd-a29370b84dfd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[André Luiz Abdalla Silveira]

First of all, Happy holidays to you folks.

Secondly, I'd like to deeply appreciate the help you're giving me

Hassan, I'll search for this material you've suggested ^^. But I didn't understand why this doesn't belong to the controller (since it's on the controller), but I hope I can make it clearer at the end of this message. I also have a difficulty on describing my problem as a set of tests, since it's not completely clear to me the complete set of states of execution my app will go through

Radhames, I couldn't understand what you tried to tell me there (copying what you said) --> "the controller is a class that should only be handle handling where to direct the request, not actually performing operations on the data or whatever."

Talking about what I want to do. My long-term goal is to simulate a MLB season game by game (with every kind of play and player).  To achieve it, I want to build a method to simulate a match. By now, and as a short-term goal, I want to produce a generic result, and important for me is building a good algorithm not depending on where to build it (controller, model, or helper -- it sounds a little freak to me to make on the view (I'm doing it, but I swear it's just provisory LOL))

 In a close future, I want to take the simulation to next level, creating a model for pitchers and batters. But again, it's something for future steps.

I know I have a long way to go through on learning Rails, but on groups like these, my learning goes faster

Again, thank you, Hassan and Radhames

[Hassan Schroeder]

On Mon, Dec 25, 2017 at 5:35 PM, André Luiz Abdalla Silveira
<andrel...@gmail.com> wrote:

> But I didn't understand why this doesn't belong to the controller

Business logic doesn't belong in controllers, it belongs in models or
service objects. It's accepted good practice and makes testing much
much easier. Reading up on the MVC pattern would probably be a
good thing too.

> also have a difficulty on describing my problem as a set of tests, since
> it's not completely clear to me the complete set of states of execution my
> app will go through

Writing tests is a way to explore the problem space, it doesn't mean
having a completely architected solution first.

[Colin Law]

On 26 December 2017 at 01:35, André Luiz Abdalla Silveira

<andrel...@gmail.com> wrote:
> First of all, Happy holidays to you folks.
> Secondly, I'd like to deeply appreciate the help you're giving me
>
> Hassan, I'll search for this material you've suggested ^^. But I didn't
> understand why this doesn't belong to the controller

Remember that a model does note need to be backed by a database table.
There should not be any significant logic in a view or controller.
It is much easier to test logic (algorithms) if they reside in a model.

Colin

[radhames brito]

@andre the issue is you are trying to dump walls of code (text) in a single file. The complexity of your application will increase a lot, you will have one BIG simulate method that does everything, such big methods are hard to understand after a few weeks even by the developer that wrote them. In general good code is written in a way that hides complexity from the rest of the system, so, what its actually maintainable is to have code that works by hiding complexity. Something like a model, for example, User.first, its nice to use because its hiding the complexity of connecting to the DB, building the query and mapping record into a ruby object, imagine having that code dumped into each model file, wouldnt it make finding your own code or navigating around different part of the code confusing? now imagine dumping that code directly in the controller, having a controller connect to the DB, build the query and handle the edge case and then loading a ruby object with the returned record? that would surely make controllers a mess, instead of having the short methods like 

```

def index

  @users = User.all

end

```

it would be

```

def index

   HUGE ALL OF CODE THAT NO ONE WANTS TO READ

end

```

you are talking the path of the second example. 

So how is this problem solved? there are several best practices, like encapsulation, and limiting responsibility of what you are putting in a file. In Object Oriented Programming we aim at hiding complexity inside classes, think of classes as kitchens, like the ones in cafeterias,

they have a small window, an order comes in on a small piece of paper and a dish comes out, how the dish is made and how many cooks are in the kitchen is not something that customers or waiter should be concern.  Your controller is a class, it takes one argument calles the 

Request object from rails, that object has the params and session information, the controller uses it to decide if it should respond with success, redirect or deny access. During one of those decisions it might ask a class for a value, and there is a chance that a class is an active record model, but the controller does not know that and does not care where User.first got its value, to the controller its just a ruby object, period. You are trying to change that pattern, you want to make a controller that will calculate a "Simulation" something that might imply a lot of code and needless complexity.

You will have this

```

def simulate

HUGE CHUNK OF CODE THAT YOU WILL NOT UNDERSTAND IN A MONTH FROM NOW

end

```

Instead you should have something like this

```

def simulate

   @simulation = Simulation.new(HomeTeam.new(params[:home_team]), AwayTeam.new(params[away_team]))

   if @simulation.valid? # check if the simulation makes sense inside that method and hide everything from the controller

     flash[:notice] = "this are the results"

  else

    flash[:error] = 'Simulation parameters are invalid'

    redirect_to :show

  end

end

```

In the above example the controller does not know where the simulation values come from, its only responsibility is the decision of where to send the user, this is what rails does, it scopes stuff, this is why its split into model, view and controller, to make your code simpler.

Like it was mentioned by Hassan, you need to read about Object Oriented programming because you are creating a very complex solution for a very simple problem.

Let me finish by saying that if this is a throw away project you are doing to learn, this is the right moment to learn OOP. If you think the reading we suggesting is too much effort for a throw away app you are mistaken, reading/learning OOP will prepare you for your career as a developer since the mistake you are making right here is a very beginners mistake and it will show in any job you apply to.

https://www.amazon.com/Practical-Object-Oriented-Design-Ruby-Addison-Wesley/dp/0321721330/ref=sr_1_1?ie=UTF8&qid=1514584223&sr=8-1&keywords=practical+object+oriented+design+in+ruby

https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=sr_1_1?s=books&ie=UTF8&qid=1514584244&sr=1-1&keywords=code+complete

--

You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/acd64e74-d9bc-4440-9e51-cdd0ca24d833%40googlegroups.com.