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.

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) -%>


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)

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?

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

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