Ranching Killer Zombie Robots: Lessons Learned


Published on

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.

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Ranching Killer Zombie Robots: Lessons Learned

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