ranching killer zombie robots: lessons learned
DESCRIPTION
Customizing Moodle is like ranching a herd of Zombie Robots... and only fools want to ranch Zombie Robots. However, if your heart is set, I will offer a set of strategies and techniques to minimize the likelihood that your herd of Zombie Robots grows into an unmanageable horde of Killer Zombie Robots that consumes half of the herd and half of your CS department every time you upgrade. Areas covered will include Common Zombie Robot Facts and Myths, General Containment Strategies (repository), Robot Branding (repository plus issue tracker), Robot Construction 101 (php patterns), and why Robot Testing is Better for Beginners.TRANSCRIPT
- 1. Ranching Killer Zombie Robots
- Brian Jorgensen, BScEE
- Systems Analyst / Web Software Engineer, Athabasca University, Canada
- [email_address] ; [email protected]
2. Disclaimer
- Worked with Sakai since 2006
- Sakai 2.1.x Maintenance B ranch Release Manager for 6 months.
- Lessons learned with Sakai; looking for conversations about Moodle.
- Quite new to moodle and php. (< 1 year)
3. Overview
- robots
- zombies
- killer
- ranching
4. Robots
- Herd of robots
- Import the starter herd
- Add local robots to that larger herd
- Some of your robots are independent
- Some of your robots are sub-robots
5. Zombies
- Walking dead: assume each local customization has a finite lifespan.
- Simply a question of when a customization falls over, not if.
6. Killer
- Large upstream refactors == many local changes break ALL AT THE SAME TIME!
- Moodle 2.0 has quite a few major changes....
7. Ranching
- Customization== customer satisfaction increase.
- Satisfaction increase == more customization requests.
- More requests == more customization == maintenance nightmare!
8. Just Say No!!
- A major upstream refactor can turn your robot zombies into a herd of...
-
- killer robot zombies that will consume your Computing Services department
- ... for months when it comes time to upgrade !
9. Moodle 2.0 The Zombocalypse!? 10. Questions?
- Brian Jorgensen, BScEE
-
- [email_address]
-
- [email_address]
11. RFC (Request for Conversations)
- Idea I: Patch Workflow
- Idea II: Inline Changes
- Idea III: 1.9.4.x maintenance branch
- Idea IV: Unit Testing and Coverage
12. Idea I: Patch Workflow
-
- Goals: automatibility; predictability; community (communability?)
13. Avoiding the Walking Dead
- APIs == Social contract
- Generic extension points
-
- Admin reports
-
- Local folder
-
- Blocks
-
- Database fields and presets
14. Specific Extension Points
- Auth and enrolment plugins
- Assignment types and gradebook plugins
- Course formats and reports
- Filters
- Question types and plugins and portfolio plugins
- Resource types and quiz reports
- Search engine adaptors
- http://docs.moodle.org/en/Development#Make_a_new_plugin
15. Social Half of the Solution
- Learn to work with the community.
- Offer patches to other people's code.
- Upstream ranchers don't want to take care of your robots!
16.
-
- The Redbean svn book Chapter 'Vendor Branches' is not my recommended workflow for trackinglargeupstream projects like Moodle.
17. 18. Don't Paint Your Robots Pink!
- Surrounding inline changes with comments to facilitate grepping
- Indication that your repository practices need some work
- Discourages passing patches upstream
19. 20. Always Merge Your Small Herd into the Larger Upstream Herd
- Upstream releases can have 100s of changes.
- Merge what you know into what you don't know.
- Problem: remerge your change into a fresh upstream file.
21. Keep Your Herd Separate!
- Store changes as patches.
- Assemble your herd.
- Use shell scripting and/or externals properties (svn) to apply patches.
22. Patches + Externals / Shell Scripts
- Pros
-
- Forecasting
-
- Automatable builds
-
- Phased security upgrades
- Cons
-
- Must assemble local codebase
-
- Requires a little more scripting
23. Try to Keep Your Upstream Stock Recent
- Duplicating community effort
- Time wasted searching through tracker.moodle.org
- Discarding work
- Blend your local reality with the community's reality
24. Collaboration at the Core
- The community's needsAREyour needs
- They are you
- They are us
- Sure, it's scary at first
25. Summary of Patch Workflow
- Grab fairly recent upstream copy
- Use script to add in modules/themes/etc; apply your customizations (patches)
- Check for merge conflicts and failures...
- Iterate: do the work!
26. You Know You're Pushing Back the Zombie Hordes When....
- 'Reversed (or previously applied) patch detected! Assume -R? [n]'
27. 28. Idea II: Required Inline Changes
-
- Goals: maintainability; extensibility
29. Overriding/Hooking
- General problems to solve:
-
- Data (model)
-
- Templates (views)
-
- Logic/state (controller)
- (Now you know my bias/experience!)
30. General Local Override Ideas
- Override/extend/implement OO classes and methods
- Override existing procedural methods
- Hookutils to replace chunks of code
31. Hookutils: Methods, Methods, Methods
- Minimal inline changes
- Methods in external files
- Signatures: method sigs, return sigs, error/exception sigs
- ( Data / Display / Logic)
32. Hookutils
- Thanks to: Penny and Dave (Catalyst) and Tim
- 3.5 methods:
-
-
- override_with_error($file, $method)
-
-
-
- override_with_exception($file, $method)
-
-
-
- override_without_error($file, $method)
-
-
-
- [overridable_constant($name, $value)??!!]
-
33. Hookutils::override_with_error
- Example: /mod/quiz/something.php:
-
- + require_once($CFG->dirroot . '/local/hookutils/hookutils.php');
-
- + require_once($CFG->dirroot . '/local/au_quiz/au_quiz.php');
-
-
- ...
-
-
- + if (override_with_error('/au_quiz/au_quiz.php', 'au_quiz_method1')) {
-
- + au_quiz_method1();
-
- + } else {
-
-
- ...
-
-
- +}
34. Idea III: 1.9.4.x Maintenance Branch
-
- Goal: ber-stability
35. 1.9.4.x Maintenance Branch
- No features
- Only bug fixes
- Fixes must be tested before going in
- Dedicated testing server
36. Idea IV: Unit Testing and Coverage
-
- Goals: verifiability; regressability
37. Unit Testing
- Start with a small project
- Code first, then add tests?
- Let it improve how you code
- Let it show what needs work
- Iterate, iterate, iterate
- Holy Grail: TDD?!
38. Simpletestcoverage Admin Report
- Uses Spike PHPCoverage library
- Replaces standard Unit Testing Admin Report
- Replaces form with mform
- Currently integrating html reports with moodle auth/headers/footers
39. Simpletestcoverage Form 40. 41. 42. 43. 44. How Much Extra Work is Testing? 45. How I Explain it Now 46.
- Brian Jorgensen, BScEE
-
- Systems Analyst, Web Software Engineer
-
- Athabasca University, Alberta, Canada
-
-
- [email_address]
-
-
-
- [email_address]
-