Irb/Bundle Exec Irb/Bundle Console/Rails Console

  • irb is the basic Ruby console. It ignores your Gemfile, and only core Ruby classes are accessible without require-ing them. It can’t easily load gems that Bundler installs outside of RubyGems’ load path.
  • bundle exec irb is like irb, if you also required bundler/setup. You can only easily require gems that are in your Gemfile.lock, but you can load those gems no matter where Bundler put them.
  • bundle console is like bundle exec irb, if you also called Bundler.require. All of the gems in your Gemfile, except the ones marked require: false, can be used without requiring them. It’s really convenient when you’re writing your own gems, or working on non-Rails code.
  • rails console is like running bundle console inside a Rails app, if you also required config/environment.rb. You can play with your entire Rails app, autoloads and database connections work, and everything’s hooked up the way you’d expect. If you’re working in a Rails app, this is the most helpful kind of console.
Advertisements

Web Server / App Server / Passenger / Rack

What’s a web server?

A web server is a program that takes a request to your website from a user and does some processing on it. Then, it might give the request to your Rails app. Nginx and Apache are the two big web servers you’ll run into.

 

If the request is for something that doesn’t change often, like CSS, JavaScript, or images, your Rails app probably doesn’t need to see it. The web server can handle the request itself, without even talking to your app. It’ll usually be faster that way.

 

Web servers can handle SSL requests, serve static files and assets, compress requests, and do lots of other things that almost every website needs. And if your Rails app does need to handle a request, the web server will pass it on to your app server.

 

What’s an app server?

An app server is the thing that actually runs your Rails app. Your app server loads your code and keeps your app in memory. When your app server gets a request from your web server, it tells your Rails app about it. After your app is done handling the request, the app server sends the response back to the web server (and eventually to the user).

 

You can run most app servers by themselves, without a web server in front of it. That’s probably what you do in development mode! In production, though, you’ll usually have a web server in front. It’ll handle multiple apps at once, render your assets faster, and deal with a lot of the processing you’ll do on every request.

 

There are a ton of app servers for Rails apps, including Mongrel (which isn’t used much anymore), Unicorn, Thin, Rainbows, and Puma. Each has different advantages and different philosophies. But in the end, they all accomplish the same thing – keeping your Rails app running and handling requests.

 

What about Passenger?

Phusion Passenger is a little unique. In “standalone mode,” it can act just like an app server. But it can also be built right into a web server, so you don’t need a separate app server to run your Rails apps.

 

This can be really convenient. Especially if you’re planning to run a bunch of apps and don’t want to spend time setting up an app server for each one. After installing Passenger, you just point the web server directly at your Rails app (instead of an app server), and your Rails app will start handling requests!

 

Passenger is a nice option, but having a separate app server can be still be good. Keeping the app server separate gives you the flexibility to choose an app server that best fits your needs, and you can run and scale it on its own. Still, I’m going to try it again the next time I deploy a new small app. I’m hoping it’ll make it easier to deploy future apps to the same server.

 

What about Rack?

Rack is the magic that lets any of these app servers run your Rails app. (Or Sinatra app, or Padrino app, or…)

 

You can think of Rack as a common language that Ruby web frameworks (like Rails) and app servers both speak. Because each side knows the same language, it means Rails can talk to Unicorn and Unicorn to Rails, without having either Rails or Unicorn know anything about the other.

 

How do they relate?

So, how does this all fit together?

 

Out of these pieces, a web request will hit your web server first. If the request is something Rails can handle, the web server will do some processing on the request, and hand it off to the app server. The app server uses Rack to talk to your Rails app. When your app is done with the request, your Rails app sends the response back through the app server and the web server to the person using your app.

 

More specifically, Nginx might pass a request to Unicorn. Unicorn gives the request to Rack, which gives it to the Rails router, which gives it to the right controller. Then, your response just goes back through the other way.

 

This overview might be simplified. But even just knowing these categories will help you put the software you run into into the right mental buckets.

 

After you understand how app servers and web servers fit together, it’ll be a lot easier to debug server problems when you have them. You’ll know all the different places you could look, and how they interact. And once the next interesting app server arrives, it’ll be even easier for you to swap it in!

How to load CSS and JS based on company / user

How to load CSS and JS based on company :-

application.html.erb :-

Top of the file,

<%= stylesheet_link_tag ‘application’ %>
<%= load_default_theme_css -%>
<%= load_customer_specific_css(current_company) -%>

Down of the file,

<%= javascript_include_tag “application” %>
<%= load_default_theme_js -%>
<%= load_customer_specific_js(current_company) -%>

application_helper.rb,

All files are present inside the ‘/home/selva/Project/main/shared/theme’ folder
application location – /home/selva/Project/main/sub

def load_customer_specific_css(company)
stylesheet_link_tag “/theme/#{company.theme}.css”, :media => “screen, projection” if company.presence.try(:theme)
end

def load_default_theme_css
stylesheet_link_tag “/theme/#{Rails.application.config.default_theme}.css”, :media => “screen, projection” if Rails.application.config.default_theme.present?
end

def load_customer_specific_js(company)
javascript_include_tag “/theme/#{company.theme}.js” if company.presence.try(:theme)
end

def load_default_theme_js
javascript_include_tag “/theme/#{Rails.application.config.default_theme}.js” if Rails.application.config.default_theme.present?
end

How to generate CSV in rails

How to generate csv and fetching the data from xls/fetching from db are given below,

users = User.first 10
file = “#{Rails.root}/public/user_data.csv”
column_headers = [“User ID”, “First Name”, “Last Name”, “Email”]
CSV.open(file, ‘w’, write_headers: true, headers: column_headers) do |writer|
users.each do |user|
writer << [user.id, user.login, user.name, user.email]
end
end

How to send mail with attachment in ruby

We can send mail with attachment in ruby, given below

require ‘mail’
options = { :address => “smtp.gmail.com”,
:port => 587,
:domain => ‘gmail.com’,
:user_name => ‘dev@gmail.com’,
:password => ‘password’,
:authentication => ‘plain’,
:enable_starttls_auto => true }

Mail.defaults do
delivery_method :smtp, options
end

mail = Mail.new do
from “dev@gmail.com”
to “selva@gmail.in”
subject “This is a test email”
body “Hello”
add_file “#{Rails.root}/public/report.csv”
end

mail.deliver

How to find model relationship/ irb history / grep -nr / git blame

Find the relationship with the model in rails console,

Find super class name,

TransportOrder.superclass.name / TransportOrder.descendants.map(&:superclass)

Find sub class name,

TransportOrder.subclasses.map(&:class_name)

Find the associations,

Invoice.reflect_on_all_associations.map(&:class_name) / Invoice.reflect_on_all_associations(:has_many).map(&:class_name) / Invoice.reflect_on_all_associations(:has_one).map(&:class_name) /  Invoice.reflect_on_all_associations(:belongs_to).map(&:class_name) and etc .

Find irb(Interactive Ruby) history :-

puts File.read(“#{ENV[‘HOME’]}/.pry_history”);

puts File.read(“#{ENV[‘HOME’]}/.irb-history”);

puts Readline::HISTORY.to_a

Search keyword through out the folder :-

grep -nr ‘is_service_provider_created_pickup_request’

Check the history of file in git command(who and updated the file) :-

git blame app/models/model.rb

 

 

Debugging Rails Applications

Rails applications can debug many ways, we will see few debug ways,

  1.  debug
  2.  to_yaml
  3.  inspect
  4.  gem
  5. Logger

DEBUG :-

The debug helper will return a <pre> tag that renders the object using the YAML format. This will generate human-readable data from any object. For example, if you have this code in a view:

<%= debug @article %>
<p>
  <b>Title:</b>
  <%= @article.title %>
</p>
You’ll see something like this:
--- !ruby/object Article
attributes:
  updated_at: 2008-09-05 22:55:47
  body: It's a very helpful guide for debugging your Rails app.
  title: Rails debugging guide
  published: t
  id: "1"
  created_at: 2008-09-05 22:55:47
attributes_cache: {}
Title: Rails debugging guide

 

TO_YAML :-

Alternatively, calling to_yaml on any object converts it to YAML. You can pass this converted object into the simple_format helper method to format the output. This is how debug does its magic.

<%= simple_format @article.to_yaml %>
<p>
  <b>Title:</b>
  <%= @article.title %>
</p>
Eg :-
[245] pry(main)> 2.weeks.to_yaml
=> “— 1209600\n…\n”
INSPECT :-
Another useful method for displaying object values is inspect, especially when working with arrays or hashes. This will print the object value as a string. For example:
<%=[1, 2, 3, 4, 5].inspect %>
<p>
  <b>Title:</b>
  <%=@article.title %>
</p>
Eg :-
[246] pry(main)> 2.weeks.inspect
=> “14 days”
GEM :-
There are several gems available to debug rails application such as pry, byebug and etc.
LOGGER :-
When i use “puts”  You don’t see any text outputted in the terminal where I have run rails s.

You’re definitely headed the right direction in using logger.debug instead of puts as puts is more for command line applications.

Rails.logger.debug, or in short logger.debug writes the parameter text to a log file. This log file is by default environment specific. If you are currently running rails in development environment then the log file in use is log/development.log.

The Logger class outputs messages that meet the log level that you set, and in Logger, there are six levels

Unknown > Fatal > Error > Warn > Info > Debug

Make Logger work for you

Ideally, your logs should be so good that someone can understand the issue using no other information. We might not get to that level, but we’re going to try!

Avoid puts; use Logger

When outputting messages to debug your code, use

logger.{unknown|fatal|error|warn|info|debug} instead of puts. While this requires a bit more typing, you get output that:

  • Fits into the standard log format
  • Comes with timestamps
  • Is logged with levels so that you can determine which messages appear in a given environment

Eg :-

Rails.logger.info(“Logger message”)