RubyConf Bangladesh 2017 - Rails buggy code
Download as PPTX, PDF0 likes91 views
The document outlines best practices for structuring code within the MVC (Model-View-Controller) architecture in Ruby on Rails. It emphasizes minimizing logic in controllers and views, promoting the use of POROs (Plain Old Ruby Objects) for additional logic, and utilizing helper classes to maintain clean and manageable code. It also addresses the importance of adhering to principles like DRY (Don't Repeat Yourself) and careful management of gems and database migrations.
![[MVC] Controller
Generally, the only types of logic you should have in your controller are:
- Session and cookie handling.
- Model selection.
- Request parameter management.
- Rendering/redirecting.
Fat model, skinny controller](https://image.slidesharecdn.com/rawvhnrw1vu4sp9fhgcv-signature-41d33e9250509c73de0164bc972f4803f73126f0cdf09eaacd8e1590bd308eb4-poli-170427162628/85/RubyConf-Bangladesh-2017-Rails-buggy-code-2-320.jpg)
![[MVC] View
View templating engine: ERB
If you’re not careful, you can soon end up with a large file that is a mix of HTML and
Ruby code.
This is also an area that can lead to lots of repetition, leading to violations of DRY
(don’t repeat yourself) principles.](https://image.slidesharecdn.com/rawvhnrw1vu4sp9fhgcv-signature-41d33e9250509c73de0164bc972f4803f73126f0cdf09eaacd8e1590bd308eb4-poli-170427162628/85/RubyConf-Bangladesh-2017-Rails-buggy-code-3-320.jpg)
![[MVC] View
require 'ostruct'
helper_method :current_user
def current_user
@current_user ||= User.find session[:user_id] if
session[:user_id]
if @current_user
@current_user
else
OpenStruct.new(name: 'Guest')
end
end
<h3>Welcome, <%= current_user.name -%></h3>
<h3>
Welcome,
<% if current_user %>
<%= current_user.name %>
<% else %>
Guest
<% end %>
</h3>](https://image.slidesharecdn.com/rawvhnrw1vu4sp9fhgcv-signature-41d33e9250509c73de0164bc972f4803f73126f0cdf09eaacd8e1590bd308eb4-poli-170427162628/85/RubyConf-Bangladesh-2017-Rails-buggy-code-4-320.jpg)
![[MVC] View
A couple of additional recommended Rails best practices:
- Use view layouts and partials
- Use presenters/decorators](https://image.slidesharecdn.com/rawvhnrw1vu4sp9fhgcv-signature-41d33e9250509c73de0164bc972f4803f73126f0cdf09eaacd8e1590bd308eb4-poli-170427162628/85/RubyConf-Bangladesh-2017-Rails-buggy-code-5-320.jpg)
![[MVC] Model
Minimize the logic in views and controllers.
The only place left in an MVC architecture to put all that logic would be in the
models, right?
not quite](https://image.slidesharecdn.com/rawvhnrw1vu4sp9fhgcv-signature-41d33e9250509c73de0164bc972f4803f73126f0cdf09eaacd8e1590bd308eb4-poli-170427162628/85/RubyConf-Bangladesh-2017-Rails-buggy-code-6-320.jpg)
![[MVC] Model
The only logic that should remain in your model is:
- ActiveRecord configuration
- Simple mutation methods
- Access wrappers
- Sophisticated queries](https://image.slidesharecdn.com/rawvhnrw1vu4sp9fhgcv-signature-41d33e9250509c73de0164bc972f4803f73126f0cdf09eaacd8e1590bd308eb4-poli-170427162628/85/RubyConf-Bangladesh-2017-Rails-buggy-code-7-320.jpg)
![[MVC] Model
So if the logic shouldn’t go in the views, and it shouldn’t go in the controllers, and it
shouldn’t go in the models, well then, where should it go?
POROs](https://image.slidesharecdn.com/rawvhnrw1vu4sp9fhgcv-signature-41d33e9250509c73de0164bc972f4803f73126f0cdf09eaacd8e1590bd308eb4-poli-170427162628/85/RubyConf-Bangladesh-2017-Rails-buggy-code-8-320.jpg)
![[MVC] Helper classes
The Rails framework places an emphasis on the named components (i.e., model, view,
and controller) of an MVC framework.
But sometimes we might need methods that don’t seem to fit into any of the three.
Rails generators conveniently build a helper directory and a new helper class to go
with each new resource we create.](https://image.slidesharecdn.com/rawvhnrw1vu4sp9fhgcv-signature-41d33e9250509c73de0164bc972f4803f73126f0cdf09eaacd8e1590bd308eb4-poli-170427162628/85/RubyConf-Bangladesh-2017-Rails-buggy-code-9-320.jpg)
RubyConf Bangladesh 2017 - Rails buggy code
- 1. Avoid to write buggy code Md. Tauhidul Islam Software Engineer Nascenia Ltd.
- 2. [MVC] Controller Generally, the only types of logic you should have in your controller are: - Session and cookie handling. - Model selection. - Request parameter management. - Rendering/redirecting. Fat model, skinny controller
- 3. [MVC] View View templating engine: ERB If you’re not careful, you can soon end up with a large file that is a mix of HTML and Ruby code. This is also an area that can lead to lots of repetition, leading to violations of DRY (don’t repeat yourself) principles.
- 4. [MVC] View require 'ostruct' helper_method :current_user def current_user @current_user ||= User.find session[:user_id] if session[:user_id] if @current_user @current_user else OpenStruct.new(name: 'Guest') end end <h3>Welcome, <%= current_user.name -%></h3> <h3> Welcome, <% if current_user %> <%= current_user.name %> <% else %> Guest <% end %> </h3>
- 5. [MVC] View A couple of additional recommended Rails best practices: - Use view layouts and partials - Use presenters/decorators
- 6. [MVC] Model Minimize the logic in views and controllers. The only place left in an MVC architecture to put all that logic would be in the models, right? not quite
- 7. [MVC] Model The only logic that should remain in your model is: - ActiveRecord configuration - Simple mutation methods - Access wrappers - Sophisticated queries
- 8. [MVC] Model So if the logic shouldn’t go in the views, and it shouldn’t go in the controllers, and it shouldn’t go in the models, well then, where should it go? POROs
- 9. [MVC] Helper classes The Rails framework places an emphasis on the named components (i.e., model, view, and controller) of an MVC framework. But sometimes we might need methods that don’t seem to fit into any of the three. Rails generators conveniently build a helper directory and a new helper class to go with each new resource we create.
- 10. Concerns Model and Controller concern - Reduce size of model or controller? - DRY model and controller?
- 11. Gems Ruby and Rails are supported by a rich ecosystem of gems. This is great for building up a complex application quickly. But sometimes the number of gems in the application’s Gemfile is disproportionately larger than the functionality provided.
- 12. Database migrations rake db:migrate rake db:schema:load rake data:migrate
- 13. Checking sensitive information into repositories config/secrets.yml config/initializers/secret_token.rb config/database.yml application.yml
- 14. Thank You
Editor's Notes
- #3: Session and cookie handling. This might also include authentication/authorization or any additional cookie processing you need to do. Model selection. Logic for finding the right model object given the parameters passed in from the request. Ideally this should be a call to a single find method setting an instance variable to be used later to render the response. Request parameter management. Gathering request parameters and calling an appropriate model method to persist them. Rendering/redirecting. Rendering the result (html, xml, json, etc.) or redirecting, as appropriate.
- #6: Use view layouts and partials appropriately to encapsulate things that are repeated on your pages. Use presenters/decorators like the Draper gem to encapsulate view-building logic in a Ruby object. You can then add methods into this object to perform logical operations that you might otherwise have put into your view code.
- #8: ActiveRecord configuration (i.e., relations and validations) Simple mutation methods to encapsulate updating a handful of attributes and saving them in the database Access wrappers to hide internal model information (e.g., a full_name method that combines first_name and last_name fields in the database) Sophisticated queries (i.e., that are more complex than a simple find); generally speaking, you should never use the where method, or any other query-building methods like it, outside of the model class itself
- #12: Makes the size of a Rails process larger than it needs to be Slow down performance in production Need for larger server memory configurations and increased operating costs Takes longer to start larger Rails applications (which makes development slower and makes automated tests take longer)