=========== How to setup Development Environment =========
STEP -1: Install Ruby with RVM. Use ruby version you are going to use in your project
STEP -2: Clone Project from VCS and Place in your directory and cd to your “project” and ask which branch is ahead and checkout to that branch
STEP -3: If gemset already created then if you cd to project it will automatically use that otherwise create gemset
STEP -4: install bundler by typing this command: ‘gem install bundler’ and install other dependances if require
STEP -5: Type command: ‘bundle install’ to install all gems. In between you will meet with many unmet dependancy errors. Solve them.
STEP -6: Check config/database.yml file and fill reqire information if needed
STEP -7: Type these commands one by one:
rake db:create # to create database, Solve errors if any
rake db:migrate # to migrate all migration to database
rake db:seed # if any seed data
STEP -8: Now type command: ‘rails s’ inside your project directory to start server and visit ‘localhost:3000’ into browser
======== ============ How to Explore Existing Rails Project ==================
1) Use The Site. Understand the purpose of the product
It can be tempting to jump straight in to the code to see how everything works. If the site is already up and hosted somewhere, try and curtail that urge and instead just go use the existing site. Click around and really get a feel for it. Even if you’ve been given an administrator account with which to work on the app, create an account and go through the sign up process. Pay attention to the URLs and paths. This will give you a general idea of the overall flow of the application. Don’t worry about any 500 errors you see, just make a mental note.
2) Read the Gemfile Twice
The Gemfile will contain all of the different external libraries in use by the application. If you’ve been working with Rails apps for a little while, you may be familiar with most of the gems inside. The most subtle surprises that arise when reading a new code base are from external libraries — mystery method definitions and constants that aren’t directly searchable in the application code can be troublesome to locate. You won’t necessarily combat all of those by getting familiar with the library names in the Gemfile but seeing them may jog your memory later.
3) Build a project vocabulary
What is a Player , and what’s a Session ? How about an Account vs a User vs
a Provider ?
Every app uses different terms and differentmetaphors. And if you don’t understand the vocabulary of an app, you’ll waste time browsing app/models every time you see a new class name.Or worse, you’ll make bad assumptions about how features work.So, the first thing you have to do is build that vocabulary. Learn what this app is made of. And if you want to do that quickly, start by reading db/schema.rb . You’ll learn the terms
the app uses, and how all its data fits together. Pay special attention to the *_id columns,
so you can see how the models connect to one another.If you’re more visual, try the railserd gem. It generates a diagram from your Rails models,showing all your tables and columns and how they interact. Keep a printout on your desk,and you’ll have an easier time understanding the rest of your app.
After this checkout seed.rb file
4) Check out the models
The app/models directory is the next place to check when going through an app for the first time. I won’t necessarily even open every single model when looking through the code the first time — it’s just good to get vaguely familiar with the models in the app.
In a welldesigned Rails app, not everything will be backed by a database table. To continue to build your project vocabulary, look inside app/models for extra classes and attributes that you didn’t see inside db/schema.rb.Don’t spend too much time here yet. It’s easy to get lost in how things work. You’re just here
to fill out your project vocabulary.
As you learn more about the parts your app is built from, you might wonder why certain
objects exist, or why they fit together the way they do. And that’s the point of the next stage.
5) Helpers and Routes
This is the last stop on the app tour before getting in to the front-end code. The reason for checking the helpers directory first is to get the idea of potential helper routes that may not be covered in the routes.rb file. A lot of apps will create custom helpers for URLs and I’ve noticed it’s beneficial to keep those in mind early. With any luck, common layout code will be extracted in to helpers as well which is also good to know up front.
6) Look at The Controllers
I’ve found it helpful to glance at the ApplicationController first to see what methods are used in every controller in the application. It’s usually a great source of information and can be filled with rescue_from directives which will save you head-aches later. After the ApplicationController, take a look at other controllers in the app and look for similarities:
Do they follow Rails conventions?
Does the app follow a skinny controller/fat model conventions?
Is the app RESTful?
Controllers can be a pain point in Rails applications and you may find some less than ideal code here.
7) Check the lib directory
The lib directory has been, in my experience, the source of most surprises when working on an existing Rails application. Unless the team has had a rigid structure in place, code seems to be dumped in here when it doesn’t fit anywhere else. Random POROs, miscellaneous modules, and more wind up finding a home in the lib directory. You’re not trying to read every file in here but it’s still the first stop I make after the test directory. It’s also where the rake tasks live, so check those out while you’re in here.
8) Asset Pipeline and Related Directories
A quick glance at th app/assets and related directories can give you a bunch of information with a relatively quick glance:
What CSS frameworks are being used?
Are there any other external front-end libraries in use?
9) Try the app, and find out “why”
Once you feel comfortable with the objects the app uses, start the app up. Click around and explore. If there’s documentation, it can help guide you. Otherwise, just see those terms you just learned come to life.
As you use the app, you’ll start to see it from a higher level. You’ll notice that there are reasons why models have the associations they do. Why they’re grouped together. Why those class names were chosen. Maybe they all appear on pages together, or are built from
the same form.And when you start to understand the parts the app is built from and why they exist, you’re
ready to figure out how it all works.
10) Figure out the “how”
By now, you know enough about the app to learn it in detail. You won’t get distracted by new terms and new interactions. You can pick one thing you want to learn, and follow it all the way through.
There are lots of ways you can go from here. These are a few of my favorites:
Browse the UI, and think: How could this feature be built, knowing what you know about the pieces? Can you guess? Use a debugger to confirm your guess, or discover how it actually works.
Pick a test case and follow it all the way through the app. Either read through the code,or explore it with a debugger.Pick a route or controller action. Can you figure out how to reach that controller action from the UI?
This is also a good time to go back through your models and plain Ruby objects. And this time, you cango into the details of how the models work.Become curious about the app. Find gaps in your knowledge and close them with a debugger and the code.
11) Why not start with the tests?
But absolutely, make sure the tests run. If they don’t, you’re working with a broken system. And you can’t rely on the things you discover from a broken system.
================ Conclusion ================
What, to why, to how
To understand a new Rails app, go through these three phases, in this order:
What parts make up this app?
Why do those parts exist? Why are they put together that way?
How does each piece work?
That will give you both the broad point of view and the narrow knowledge you need in order to make that new app yours.