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.
- 1. Ranching Killer Zombie Robots
- Systems Analyst / Web Software Engineer, Athabasca University,
Canada
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
4. Robots
- 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?
11. RFC (Request for Conversations)
- 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
-
- Database fields and presets
14. Specific Extension Points
- Auth and enrolment plugins
- Assignment types and gradebook plugins
- Course formats and reports
- Question types and plugins and portfolio plugins
- Resource types and quiz reports
- 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.
- Use shell scripting and/or externals properties (svn) to apply
patches.
22. Patches + Externals / Shell Scripts
-
- 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
- Blend your local reality with the community's reality
24. Collaboration at the Core
- The community's needsAREyour needs
- 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...
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:
- (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
- 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
-
-
- 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')) {
34. Idea III: 1.9.4.x Maintenance Branch
35. 1.9.4.x Maintenance Branch
- Fixes must be tested before going in
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
38. Simpletestcoverage Admin Report
- Uses Spike PHPCoverage library
- Replaces standard Unit Testing Admin Report
- 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.
-
- Systems Analyst, Web Software Engineer
-
- Athabasca University, Alberta, Canada