1. Ranching Killer Zombie Robots

• Brian Jorgensen, BScEE

• Systems Analyst / Web Software Engineer, Athabasca University, Canada

• [email_address] ; brian@moosetrout.com

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]