ranching killer zombie robots: lessons learned

Download Ranching Killer Zombie Robots: Lessons Learned

If you can't read please download the document

Author: moosetrout

Post on 26-Jun-2015

1.831 views

Category:

Technology


0 download

Embed Size (px)

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

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]