Tootle returning to rails
1 likeâ˘508 views
This document summarizes Andrew Grimm's career path from university and research roles to his current position as a back-end Rails developer at a large company. It describes some key differences he has experienced moving from solo development and a research environment to group development and a commercial setting. These include working in a team with daily standups and pull requests requiring multiple approvals, as well as changing from Ruby to Rails and adopting different testing techniques like mocking.
Tootle returning to rails
- 2. TOOTLE: RETURNING TO RAILS ANDREW GRIMM ROROSYD JUNE 9 2015
- 3. MY CAREER SO FARâŚ
- 4. UNIVERSITY OF SYDNEY ⢠Bachelor of Science (Bioinformatics) Honours Class I (Biology) ⢠Final undergraduate year half biology, half computer science ⢠Honours year involved a bioinformatics project
- 5. CHILDRENâS HOSPITAL AT WESTMEAD ⢠Worked on RettBASE, an online database of mutations to MECP2 which causes Rett syndrome ⢠Biological knowledge important, plus general computing skills, but not much programming
- 6. MARINE BIOLOGICAL LABORATORY ⢠Work related to the Encyclopedia of Life, a website aiming to have a series of pages for each species known to science ⢠~ 6 months PHP, 6 months Ruby on Rails
- 7. UNSW AUSTRALIA ⢠Analysis of mutation in HIV ⢠Used Ruby (without Rails)
- 8. CURRENT POSITION ⢠Back-end Rails developer at a large product company
- 9. CHANGES FROM PREVIOUS TO CURRENT JOB ⢠Solo development => Group development ⢠Research => commercial environment ⢠Ruby => Rails
- 10. PULL REQUESTS ⢠Have to get two approvals for each pull request ⢠Advantage: Source of feedback ⢠Disadvantage: More work when you thought youâd ďŹnished
- 11. PACE OF WORK ⢠Previous job involved weekly or twice-weekly meetings ⢠Now daily standups and JIRA tickets
- 12. RUBY TO RAILS ⢠Bit more magical
- 13. TESTING ⢠In previous job used test/unit, real objects, and tested actual results ⢠Now use RSpec, factory girl. Techniques include mocking, and testing that one class is calling the correct methods on other classes and objects.
- 14. COMPARISON OF TESTING TECHNIQUES: SCENARIO ⢠A product has a delivery postcode, which must be four digits, and must be to a location we deliver to ⢠âSydneyâ is not valid, because it isnât 4 digits ⢠â0800â is not valid, because we donât deliver there ⢠â2000â is valid, because we deliver there
- 15. TESTING TECHNIQUES: REAL OBJECTS ⢠Is a product with postcode âSydneyâ invalid? ⢠Is a product with postcode â0800â invalid? ⢠Is a product with postcode â2000â valid?
- 16. TESTING TECHNIQUES: MOCKING ⢠Testing that Product successfully uses postcode format validation ⢠The format validator says that the postcode does not contain 4 digits. Is the postcode valid? ⢠The format validator says that the postcode does contain 4 digits. Is the postcode valid?
- 17. WHY THE DIFFERENCE? ⢠Canât do dependency injection ⢠Have to intercept calls to objects or classes
- 18. INHERITANCE ⢠Delegation (as opposed to inheritance): ⢠spreadsheet = Library::Spreadsheet.new ⢠spreadsheet.serialize(@spreadsheet_ďŹlename) ⢠Inheritance ⢠class MutationSpreadsheet < Library::Spreadsheet ⢠end
- 19. MAGIC ⢠Ruby-only style: ⢠length_validator = LengthValidator.new(dna) ⢠length_validator.valid? ⢠Rails style: ⢠validates :dna, length: true