Published on October 25, 2017
1. Basic Rails Training Arthit Hongchintakul Swiftlet Co., Ltd. [email protected]
2. Introduction to Ruby on Rails > Ruby: Dynamically but strongly typed OO language. > Rails: Web application framework built on Ruby. > Web application = HTTP communication > Rails is designed upon the MVC pattern. > Ruby libraries are packaged and distributed as Rubygems > Rubygems you MUST know: rails, bundler, rake
3. Setting up your machine > Either native Ubuntu machine, or an Ubuntu virtual machine. > For Ubunbu VM, the host machine needs 8+ GB Ram, decent graphics adapter, and more than 32 GB free space dedicated to the VM. Virtualbox.org offers free virtualization software. > “Stable” releases are recommended for Ubuntu. Currently 12.04 is the latest stable. Use 64-bit desktop version. > Follow instructions here to install required packages.
4. Revenue Science Specifics > Use Ruby 1.9 series > Use Rails 3.2 series > Use Postgres database > For today’s class, use sqlite > Set up github and Heroku accounts. We’ll use this later > Exercise: if you haven’t done so already, setup your machine.
5. Introduction to Ruby > Hello World program > Ruby Syntax Ruby on Rails.pdf > OOP in A PIE > Modules > Closures > Enumerables
6. HTTP Refresher > HTTP > Client-Server architecture > Stateless architecture > HTTP Request > HTTP Response > REST
7. MVCServer InternetRequest Controller Request Model Model Model Model DB Response Response View
8. Rails Application in 7 steps $ rails new five_minute $ cd five_minute $ echo “gem ”therubyracer”” >> Gemfile $ bundle install $ rails generate scaffold post title:string body:text $ rake db:migrate $ rails s $ firefox http://localhost:3000/posts
9. Rails Request Lifecycle > Routing > Controller – Action > Model > View – Embedded Ruby
10. Rake > Ruby’s “make” > Task management > Rake tasks you must know today: – rake db:drop --trace – rake db:create – rake db:migrate > rake -T
11. Exercise: Due next class Create a new Rails application that reads and check Sudoku answers. Using the generator, create a scaffold and modify it to perform the following: > List previously submitted Sudoku answers, also show that the answer is correct or not > Show the detail of a record of Sudoku answer. Show that the answer is correct or not > A form to create a new Sudoku answer record
12. Exercise: Due next class > New form submission should create a record in the database, and then redirect to the index page > Edit form of the Sudoku answer > Edit form submission should update an existing record in the database and then redirect to the show page > Delete a Sudoku answer record > Extra credit: create another scaffold to generate a correct grid
13. Sudoku correctness > A correct Sudoku answer must be a grid of 9 columns and 9 rows > Every cell in the answer must contain one of the digits 1-9 > Every column of the answer must contain all digits 1-9 > Every row of the answer must contain all digits 1-9 > Partition the main grid to a subset of 3x3 grid, each sub-grid must contain all digits 1-9 > This implies that there is no repetition in the columns, rows, and sub-grid
14. Agenda > Revenue Science’s Rails > Git, github > Heroku > Deployment process > Rails Model > Rails Controller > Rails View
15. Setting up Revenue Science Machine $ rvm install 1.9.3-p545 $ rvm use [email protected]_science --create --default $ gem install rails --version “3.2.17”
16. Git > Git is a distributed version control system > Version control system: save points and history of software development > Distributed VCS vs. Centralized VCS > No one authoritative source
17. Github > https://github.com > Sign up for your own account. > You will need to pay for a private repository. > Consider https://bitbucket.org for a service with free private repositories. > Create a key pair to connect with github
18. ssh-keygen > Remote access without typing your password > Create a key pair with the command ssh-keygen > 2 keys are generated: id_rsa and id_rsa.pub – You can set the key name. > id_rsa is a private key. Keep it to yourself. > id_rsa.pub is a public key. Share this key to anyone you need to communicate with. In this case, github. > Visit https://github.com/settings/ssh to add your public key
19. ~/.ssh > This is where you keep your private keys > This is where you keep your ssh config file $ mkdir –p0700 ~/.ssh $ cp id_rsa ~/.ssh/ $ touch ~/.ssh/config $ chmod 0600 ~/.ssh/config
20. ~/.ssh/config Host github.com Hostname github.com User git IdentityFile ~/.ssh/id_rsa > Test by running the command $ ssh -vT github.com > It should greet you with your username Hi arthith! You've successfully authenticated, but GitHub does not provide shell access.
21. Creating a new repository Server side > Create a new, empty one. > Fork an existing repository. Local machine side > Initialize your repository > Add a commit > Add a remote repository > Push your code to the remote repository > Clone it to another machine
22. Basic git workflow > Pull remote changes > Make your own change > Test your change; make sure everything works > git status > git diff to see the change; make sure no unintentional change exists > git add to stage the change > git rm, git mv to remove or move files > git reset HEAD /path/to/file to un-stage changes > git commit –m “commit message” –m “another message” > git pull –rebase > git push > Start over.
23. Merge conflict > Resolve the conflict in the file, choose yours or remote code, or merge the two together. > git add the files > git rebase --continue # to apply the merge > git rebase --abort # to abort pulling > git reset --hard <commit id> # revert to commit with id > Git pull to get fresh remote
24. Feature branching > A discipline to manage software releases > Every new feature should be developed on its own branch > When a feature is accepted, the branch is merged on to the master branch via pull request > Your manager will test the branch and eventually merge the code to master > Be very careful of merge conflict. Be prepared to help your manager merge your change in the case of conflict.
25. Git branching $ git branch –a $ git branch new_branch $ git checkout new_branch $ git push –u origin new_branch $ git checkout master $ git merge new_branch $ git push
26. Heroku > Cloud-base zero-configuration web application hosting service > Solves the problem of complicated steps to deploy Rails application. > All you need is a git repository of your Rails application and Heroku Toolbelt application. > ssh key is also required. Use a different key for each service.
27. Deploy to Heroku Install https://toolbelt.heroku.com heroku git:remote –a app-name-here #OR heroku apps:create app-name-here heroku addons:add heroku-postgresql # heroku addons:docs heroku-postgresql Remove sqlite from Gemfile Use gem “pg” instead Modify database.yml to use postgresql in development
28. Deploy to Heroku RAILS_ENV=development rake assets:precompile git add . git commit –m “precompile assets” git push origin master git push heroku master heroku run “RAILS_ENV=production rake db:setup” #OR # heroku run “RAILS_ENV=production rake db:migrate” heroku logs –t # to see the logs Now try and deploy your application to heroku
29. Rails routing > Routing – RESTful resource: 7 basic routes and their convention – Custom RESTful routes: member vs collection – Non-REST routes: custom route mapping > Mapping to controllers#actions $ rake routes
30. Controller > Controller Action > Non-action methods AKA helper methods > Action filters > Multiple formats > Rendering > Redirection > HTTP Error Codes
31. Rails Migration > Why migration? > Creating a new migration > #change vs #up and #down > IrreversibleMigration error > schema.rb $ rails generate migration add_description … $ rake db:migrate $ rake db:rollback $ rake db:reset $ rake db:drop db:create db:migrate $ rake db:schema:load $ rake db:test:prepare $ rake db:seed
32. Model > ORM: Object Relational Mapping > Entity Definition – migration > Relationship Definition – inverse_of > Validation > Callbacks > Transaction: ACID Property > Scopes : Decorator Pattern > Non-ORM models
33. View > ERB > Layout > Partial > Partial’s local variables > Object partial > Collection partial > Asset Pipeline
34. Asset Pipeline > DRY > Scoping > Caching – rake assets:precompile – rake assets:clean
35. Exercise > Create a new contact list application > Push to github repository > Deploy to Heroku > Create a new feature branch > Add “Company” feature – Contact belongs to a company – Company has many contacts > Pull request > Merge feature > Deploy
36. Test Driven Development Red Ball Green Ball Refactor
37. Software Quality > Correctness > Optimal – Sufficiency – Necessity
38. Rails Application Design Model Entity Relationship Validation Indexing Optimization Behavior Controller Routing Actions (Index, show, new, create, edit, update, destroy) Custom actions Filters Request Parameters Authentication Authorization Response View Layout Navigation Structure Content Representation Design Behavior
39. Rails Testing Tools > Rspec-rails > Capybara > Capybara-screenshot > Capybara-webkit > Shoulda-matcher
40. Anatomy of a test case > Acceptance criteria – Given [a certain circumstance] – When [an action is performed] – Then [an expected behavior should occur] > Test case – Setup (Given) – Perform (When) – Assert (Then)
41. Level of testing > Unit > Functional > Integration > Acceptance
42. QA Process > Requirement analysis > Test scenario verification > Try to break the feature > File bug report
43. Bug Report > Refer to the requirement > State what is wrong > Steps to reproduce > State what the expected behavior is > Developers: – Verify the bug: requirement from another work, missing requirement, external error, software error – Reproduce the bug – Fix it
44. Service Layer Servers talking to each other
45. Service Layer > Essentially still HTTP > Request header > Controller Actions > Response header and body > Sessions > Integration testing > Non-integration testing
46. Receiving Service Calls > HTTPS is (usually) handled by the reverse-proxy > Rails accept various format of request parameters – HTML Form parameters – JSON – XML parameters requires actionpack-xml_parser gem > Rails auto-convert the parameters to params hash. > Same MVC pattern. > Response format depends on the request “accept” header > Consistent Service API specifications > API specification may be required for remote end point developers. > rspec –fd with well written specs
47. Rendering Response > Response code is very important > JSON – Object#to_json method – JSON.pretty_generate(object) – Builder view template > XML – ActiveRecord::Base#to_xml method – Nokogiri gem – XML view template – Builder view template > Others
48. Sending Service Calls > Various methods, but essentially all HTTP/HTTPS > Ruby ‘net/http’ > rest-client gem > Generate acceptable request parameters > Handle responses gracefully, including error responses > Timing out at different stages: open, read, SSL, continue > Remote API specifications
49. Separation of Responsibility > Service call can be implemented in a separated model > Service model can be separated into the application logic and the connection driver. > Application logic provides higher level of functionality to the application. > Drivers handles all the remote connection and payload management. > Drivers are interchangeable for API version updates.
50. SOAP > Another layer of communication on top of HTTP – May also be on top of other application layer such as SMTP > SOAP message consists of an envelope, and the body > Instead of specifying RESTful URL, SOAP goes to a specific URL, the SOAP service URL. This breaks down MVC quite badly in Rails. > In the message SOAP will say what action is requested and what parameters are sent. > SOAP response looks the same as SOAP request. > Crazy XML all the way through > savon gem
51. Sessions > HTTP is stateless > Sessions can be implemented in Rails > Service call is almost always atomic > If it’s not atomic, you’re doing it wrong > Service controllers should not rely on session for any information. > Authentication are to be implemented with encryption and message signing
52. Security 101 > Authentication – Verification of identity: you are who you say you are – Prevent: false identity, eavesdropping > Authorization – Verification of right: you can do what you are trying to do – Prevent: access violation, unauthorized action, e.g., self-promotion to site admin – No read up, no write down > Auditing – Verification of action: a record of what you have done – Record of who did what, changed what to what, at what time, what server
53. Integration Testing Development Test instance Remote test instance
54. Integration Testing > Testing receiving calls is simply controller tests. > Testing sending calls requires a test instance of remote end point > Setup has to be done on both remote and local sides > Perform step hits the remote end point > Assertion may be verified on the local or remote side, usually local. > The hard part are setting up and testing the error cases > The hardest part is testing the network error handling
55. Non-Integration Testing Local connection driver Mock/Stubs
56. Non-Integration Testing > Somewhat reduce the complexity in setting up > Separation of the remote and local endpoints > Mocking is required to provide remote responses > Mocking must strictly conform to remote API specification > Discipline must be taken seriously to never mock internal system > Only mock what you cannot access or control > Very high risk of systems being out of sync if remote end point is still under development > Can easily test error cases, timing out, and network errors > Testing code that requires service call may be stubbed for reasonable complexity > Mock vs Stubs
57. Background Worker
58. Background Worker > Reasonable response time for a web application is 7 seconds > Push long, complex tasks to background workers > Background workers imply infrastructure and code complexity > Introduction to distributed system
59. Background Worker PGSQL Message Queue App Server App Server App Server App Server Background Worker Background Worker Background Worker Background Worker Task
60. Background Worker > Usually needs domain model knowledge and logic – Relationship, validations – Custom logic > Needs to communicate with the database > Might as well use Rails environment > resque gem
61. Background worker gems > https://github.com/blog/542-introducing-resque > https://github.com/resque/resque > Resque comes with a whole lot of plugins – http://rubygems.org/search?utf8=%E2%9C%93&query=resque – resque-scheduler, resque-retry, resque-mailer > Front end interface with a bunch of nice features – Status, re-queue, cancel job, etc.
62. Redis > Key-Value storage, much like persistent JSON hash > Has a lot of traits that represent messaging queue > Ridiculously fast; written in pure C. > Redis earns the inventor a job at VMWare > Redis has its own set of syntax: – http://redis.io/commands > redis, redis-namespace gems provide Ruby API – https://github.com/redis/redis-rb – https://github.com/resque/redis-namespace
63. Infrastructure Setup > Resque server(s) > Redis database – Fault tolerance > Deployment steps > System monitoring: redis, resque parent, resque workers > Testing environment – Job test is a simple unit test – Functional test that connects to test Redis instance – Be careful when testing email functionality
64. Where does it go wrong? > Resque front end > Job functionality > Resque server inspection – ps afx – lsof –Pni – QUEUE=queue-name rake resque:work > Redis server – redis command line interface – Redundancy