Rails daily usage cheat sheet

Task	Command
Start server	rails s
Start console	rails c
Generate a db migration to add columns	rails generate migration add_column_to_some_table column_name:string... class AddColumnBankAccountNameToRequests < ActiveRecord::Migration def self.up add_column :direct_debit_requests, :bank_account_name, :string end def self.down remove_column :direct_debit_requests, :bank_account_name end end
Generate a db migration to add index	rails generate migration add_index_to_some_table class AddIndexToActionAudits < ActiveRecord::Migration def self.up add_index :action_audits, [:controller, :action, :action_failed] end def self.down remove_index :action_audits, [:controller, :action, :action_failed] end end
Generate new model	rails generate model loan_charge product:references listener_reference:string  fixed_charge:integer min_charge:integer  max_charge:integercharge_percentage:float  class CreateLoanCharges < ActiveRecord::Migration def self.up create_table :loan_charges do |t| t.references :product t.string :listener_reference t.integer :fixed_charge t.integer :min_charge t.integer :max_charge t.float :percentage_change t.timestamps end end def self.down drop_table :loan_charges end end

Ruby on Rails development notes, tips, practices

Development

• Performance tuning tools:
• New Relic
• Useful tips:
• Use rails console to counter check the SQL statements being executed.

Testing

• Unit tests should be written in a way that adding new records in test fixtures shouldn't affect the previous test results.  
• New test fixtures should be added in a way that they should link to existing fixture data so as to avoid breaking existing test cases.

Quality Assurance

• Besides unit, functional and integration test within rails framework.  Create automated browser test using tools like "Selenium" over test/real data.

Maintenance

• Avoid using unnecessary code reflection.  It's not good for performance and maintenance.

General guidelines for team software development

Development Environment

• Source control - e.g. Git (preferred choice) , Csv, Svn
• May use internal server or public source controls (e.g. Github/ Unfuddle)
• Team members should receive notification whenever there's new push/commit to the server repository.
• Knowledge base - Wiki
• Team members should try to contribute on:
• Project documentations
• Technical know-hows
• Workflow control for agile development.  Some choices:
• Simple and easy to use - Pivotal Tracker
• More comprehensive one - Atlassian JIRA  
• Continuous integration - Build and test server.  For example:
• Jenkins - For Ruby on Rails developments
• CuriseControl.NET - For .NET developments
• Test Automation
• Browser test - Selenium IDE

General Coding Practices

• DRY - Don't repeat yourself.  Never copy and paste same (similar) block of code in multiple places within the project.  Instead, common functionalities should be "extracted" to a single access point like a helper function or by other means.
• Coding conversions - Team members should follow a single set of coding conversion.
• Try to keep each line under 120 to 150 chars.
• Code with comments.
• Should always keep the code clean and easy for maintenance.
• Should keep small code source files.  Every source code file should in general not more than 500 or even 300 lines (excluding large blocks of comments).
• Should keep small functions - not more than 30 to 50 lines.
• Should keep functions as private/protected as possible.  Only expose a function to public whenever necessary.
• Every single function/method should be unit tested.
• Regular code coverage test.
• Developers may keep a work diary to log everyday's work done.

Daily Collaboration Practices

• Team members MUST complete test (unit, functional, integration test) and make sure there's no unexpected error before pushing code to repository.
• The build server (e.g. Jenkins/CuriseControl.NET) should run complete test whenever there's code update on repository.  In this way, whoever broke any tests can be clearly identified.
• If there's unexpected errors (except explicit NotImplementedError) reported by build server, whom pushed the related code should fix the errors ASAP.
• Responsibilities - whenever a feature raised a issue/bug need to be fixed/enhanced, the team member(s) who contributed to that feature should be have the priority to follow the case.
• Communications
• Better communications between team members always save development time and avoid unnecessary bugs.
• Always let other team members know what you're working on.
• Pending or unfinished feature can be marked as "NotImplementedException" and let the corresponding test fail.  Then commit code to repository.
• Any bug reported from QA Engineers should state as much details as possible including the environment and steps to reproduce a bug.
• Code review
• Team members should review each others' code.
• For any problem spotted, one should inform the author of that code.  In addition, adding unit tests to indicate the problem may also helps.
• It there's no QA team in the group.  Developer should write additional test cases for each other!  It's always better for a developer to find a bug before the end users!
• All developers should stand by when a new release is deployed to production.
• Business logic and any updates should be kept in a centralized repository such as work flow control or wiki.
• Every developer should try their best to commit/push the work done on that day before leaving the office.

Source Control Usage Practices

• New project feature should be developed on a separated branch.  Then merge back to master/main trunk when finished and tested.
• Project releases should be tagged.

Git daily usage cheat sheet

Task	Command
Initialize a new git repository	git init
View local branches	git branch
Create new local branch	git branch [new_branch_name]
Delete local branch	git branch -d [branch_name]
Switch to a branch	git checkout [branch_name]
Add files to git	git add .
Undo all current changes.	git checkout .
Commit changes	git commit -a -m "Log message"
Show git logs	git log
Push local to remote	git push origin [branch_name]
Pull from remote	git pull origin [branch_name]
Merge branch	git merge [from_branch]
Show diff	git diff
Show all branches	git branch -a
Fix a tagged release	git checkout -b [tag_name]_fixes [tag_name] OR (for getting a remote branch) git checkout -b [new_local_branch] origin/[remote_branch] e.g. git checkout -b myfeature origin/myfeature
Create a new tag	git tag [tag_name]
Push tags to remote	git push --tags
Overwrite existing tag	git tag -f [tag_name]
Delete tag	git tag -d 12345 git push origin :refs/tags/12345
Merge individual commits	git cherry-pick [commit_hash]
Stashing	git stash git stash apply git stash list
Create an empty repository	git --bare init
Adding a remote repository	git remote add origin [server_name]:[directory_name]

Checkout a single file on another branch:
$ git checkout branch_name file_full_path

More on: http://gitref.org/index.html

Capistrano cheat sheet

Description	Command
List cap details	cap -T
backup database	cap bullitt db:backup:adhoc
Deployment without migration	cap bullitt deploy
Deployment with migrations	cap bullitt deploy:migrations