- 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]
-