Ranching Killer Zombie Robots: Lessons Learned

Ranching Killer Zombie Robots
Brian Jorgensen, BScEE
Systems Analyst / Web Software Engineer, Athabasca University, Canada
[email_address] ; brian@moosetrout.com

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)

Overview
robots
zombies
killer
ranching

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”

Zombies
“ Walking dead”: assume each local customization has a finite lifespan.
Simply a question of when a customization “falls over”, not if.

Killer
Large upstream refactors == many local changes break ALL AT THE SAME TIME!
Moodle 2.0 has quite a few major changes....

Ranching
Customization == “customer” satisfaction increase.
Satisfaction increase == more customization requests.
More requests == more customization == maintenance nightmare!

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 !

Moodle 2.0 – The Zombocalypse!?

Questions?
[email_address]
[email_address]

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

Idea I: Patch Workflow
Goals: automatibility; predictability; community (communability?)

Avoiding the “Walking Dead”
APIs == “Social contract”
Generic extension points
Admin reports
Local folder
Blocks
Database fields and presets

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

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!

“ The Redbean svn book Chapter 'Vendor Branches' is not my recommended workflow for tracking large upstream projects like Moodle.”

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

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.

Keep Your Herd Separate!
Store changes as patches.
Assemble your herd.
Use shell scripting and/or externals properties (svn) to apply patches.

Patches + Externals / Shell Scripts
Pros
Forecasting
Automatable builds
Phased security upgrades
Cons
Must assemble “local codebase”
Requires a little more scripting

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

“ Collaboration at the Core”
The community's needs ARE your needs
“ They” are “you”
“ They” are “us”
Sure, it's scary at first

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!

You Know You're Pushing Back the Zombie Hordes When....
'Reversed (or previously applied) patch detected! Assume -R? [n]'

Idea II: Required Inline Changes
Goals: maintainability; extensibility

Overriding/Hooking
General problems to solve:
Data (“model”)
Templates (“views”)
Logic/state (“controller”)
(Now you know my bias/experience!)

General Local Override Ideas
Override/extend/implement OO classes and methods
Override existing procedural methods
Hookutils to replace chunks of code

Hookutils: Methods, Methods, Methods
Minimal inline changes
Methods in external files
Signatures: method sigs, return sigs, error/exception sigs
( Data / Display / Logic)

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)??!!]

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 {
...
+}

Idea III: 1.9.4.x Maintenance Branch
Goal: ü ber-stability

1.9.4.x Maintenance Branch
No features
Only bug fixes
Fixes must be tested before going in
Dedicated testing server

Idea IV: Unit Testing and Coverage
Goals: verifiability; regressability

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?!

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

Simpletestcoverage Form

“How Much Extra Work is Testing?”

How I Explain it Now

Systems Analyst, Web Software Engineer
Athabasca University, Alberta, Canada
[email_address]
[email_address]

http://www.markdrechsler.com	298
http://www.slideshare.net	1
http://translate.googleusercontent.com	1

Ranching Killer Zombie Robots: Lessons Learned

by moosetrout

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 300

Statistics

Ranching Killer Zombie Robots: Lessons Learned Presentation Transcript