2. Who am I?
• Core developer in Moodle community since 2005
• Worked with schools, universities and businesses
around UK
• Moved to Australia and joined Moodle HQ in 2012 as
an Integrator and Developer
• Since joining HQ, i’ve spent a lot of my time
complaining about the price of beer in Perth...
$10!
£7
€8
(http://www.quora.com/Beer/Does-Perth-Australia-have-the-most-expensive-beer-prices-in-the-world)
3. Who am I
I’m also part of the Integration Team..
• Experienced group of Moodle developers at HQ, who
act as the final ‘gatekeepers’
• Conducting final checks before code makes it into
Moodle release
• Bring historical context and try to facilitate
communication between interested parties
• Consider the whole communities point of view
• http://docs.moodle.org/dev/Integration_Review
5. How to guarantee your change is
integrated to Moodle core
You can’t!
6. Why not..
• The Moodle community is diverse and we need to support a
large community in a generic way
• We’re maintaining a ‘platform’ with core tools
• We don’t have unlimited resources to maintain every feature
anyone can think of
..use moodle.org/plugins/
• Plugins to support as many types of customisations as possible
• Tightly integrated to Moodle for easy install and upgrades
[DEMO]
• Infrastructure will continue to be improved in this direction
7. Why contribute anything to core?
• It’s a bug
• You can’t fix core bugs in
plugins!
• There isn’t an appropriate
plugin point
• You’re confident the Moodle
community will be on board
• Its rewarding!
• Dan core contributors
• (we’ve got 2800 open bugs and
appreciate help)
0
25
50
75
100
28
51
76
84
93
2.1 2.2 2.3 2.4 2.5
Non-Moodle HQ core contributors
per release
8. But if you fit the bill..
Here are some ways to increase your chances of success..
9. 1. Process
• Same for any developer, even Moodle
HQ
Simplified:
• Make code available as a git branch
• Multiple rounds of code review
• Pulled into main Moodle repository and
tested
• If successful, closed and change is
deployed
http://docs.moodle.org/dev/Process
10. 1. Process
Pitfalls:
• Learning the ropes can be daunting, don’t be afraid to
ask for help!
• Some aspects of the process involve waiting for
feedback
• Other parts of the process request your feedback
quickly, in a time limited way (e.g. ‘testing failed’ state)
11. 2. Tracker
• All developments start with a tracker
issue. The ‘home’ of developers, lots of
knowledge recorded on issues
• Be sure to search for and link together
related issues
• Record your thoughts/decisions while
developing code, is useful reference
• Be sure to link to related forum
discussions, docs and materials which
are relevant, else a developer may not
aware of this
12. 2. Tracker
Pitfalls:
• Commenting on an already closed issue
• Useful in some cases, but if new work is required, a
new issue is needed
• Creating duplicate issues
• Please search, make use of component fields to
narrow down issues
• Some actions need additional permissions, see Moodle
Docs: Tracker Guide
13. 3. Community support
• Gather support from the community for your
changes:
• Announce and publicise on forums, twitter,
moots etc.
• For major changes, construct a specification on
the developer docs wiki and solicit feedback
• Be sure to consider use cases other than your
own
• Once you’ve gathered tracker votes, comments
and support, be sure to link from the tracker
14. 3. Community support
Pitfalls
• Not soliciting any feedback
• Bumping forum posts to get attention
• If you are not getting interest it may actually indicate that
nobody else is interested.. which might not be a good
fit.
• Ignoring a use case which doesn’t fit with yours
• We can’t ignore specific use cases in core
15. 4. Coding Style
• Moodle has nearly 1 million lines of code which have
evolved over 10+ years from hundreds of developers
• The Moodle coding style was created to improve
consistency and should be followed for all new code:
http://docs.moodle.org/dev/Coding_style
• Lots of old code sucks, don’t copy it!
• The codechecker and moodlecheck plugins allow
you to check your code against coding style rules
automatically.
• Try to take a sensible approach to any code you are
modifying. Its often sensible to match the surrounding
style for better readability
16. 4. Coding Style
Common Pitfalls
• Not checked against code checker at all
• Gives suggestion of poor attention to detail, don’t give us that
excuse!
• Use of underscores in variable names
• Incorrect spacing on control statements
• Developing without DEBUG_DEVELOPER
17. 5. Code Review
• All Moodle Code is reviewed multiple times before making it into the
final release
• Moodle is so huge and has been evolving for so long that no one person
knows everything
• The code review serves as a way to both improve the code and to share
the historical context which might apply to each change
• Ideally, for the best chance of success, someone experienced with the
area you are coding would review the code (e.g. component maintainer)
• Code review is a two way process, don’t be afraid to justify your
decisions (an important part of the process is to extract the rationale for
others to see)
18. 5. Code Review
Pitfalls:
• Difficulty finding a peer reviewer
• Try to be patient and when your patience runs out, consider campaigning
politely on the forums
• Reviewers can be critical and sometimes frank
• Try not to take it personally, the goal of everyone is to find the best
technical solution for each issue
• Disagreement with reviewer
• Feel free to state your case and if necessary, disregard their advice. But
be sure to justify your rationale for final integration
19. 6. Cross-DB Compatibility
• Moodle supports PostgreSQL, MySQL, Oracle and MS SQL.
Please try to test against another db to your usual environment as
a minimum
• Pay special attention when writing custom SQL
• At this time, transactions cannot be relied upon in core, because
we still support myisam
• Can be useful for constructing complex queries against different
engines: http://sqlfiddle.com/
20. 6. Cross-DB Compatibility
Common pitfalls:
• Forgetting $DB->sql_compare_text() or $DB->sql_concat()
• Using DISTINCT on text columns (not compatible with Oracle)
• Adding LIMIT clauses, rather than using the function params
• Not including all GROUP BY items in the SELECT field-list (MySQL vs
PostgreSQL)
• Not using placeholders for user input
• Not using the XMLDB editor for creating schema definitions
21. 7. Performance
• Don’t decrease performance!
• Database queries are by far one of the most expensive things you
can do, try not to increase them, ensure that they are constant.
• If you improve performance, please record and share your results on
the tracker. We love integrating performance improvements!
• profile, profile, profile (see Tim Hunt’s recent blogpost: Performance-
testing Moodle )
• Make use of the Cache API for adding caching, don’t create your
own caches: http://docs.moodle.org/dev/Cache_API
22. 7. Performance
Common pitfalls
• DB Queries in loops or widely called functions
foreach ($courseids as $courseid) {
//... do stuff..
foreach ($studentids as $studentid) {
$DB->get_record('user', array('id' => $studentid);
// Could be called 50,0000 times even on small sites!
}
}
• Loading a large amount of data into RAM
• Try to use $DB->get_recordset*() on large datasets
• Be mindful with file inclusions
23. 8. Security
• You should know and be using, at least:
• optional_param()/ required_param() or formslib to validate
user input
• PARAM_xxx types for cleaning user input
• XSRF protection using session keys
• s(), p(), format_string() and format_text() for
outputting user-inputted text
• How to control access using capabilities, the context hierarchy and
require_login() etc
• Our process for dealing with security bugs is different, in order to
achieve responsible disclosure.
24. 8. Security
Common pitfalls:
• Forgetting session keys
• Handled for you by formslib, else you need to do it!
• Often missed when simple toggle functions
• Incorrect use of PARAM_ types
• Study the top of lib/moodlelib.php
• Careful with FORMAT_TEXT - it’s name is misleading due to
multilang
25. 9. Internationalisation
• Moodle 2.5 has over 100 language packs and is a strong multilingual
community
• Use get_string() for strings, don’t hardcode english!
• Consider carefully the time of translators in creation of your strings
(tricky tradeoff)
• Remember to use userdate() for times, we provide a number of
standard time formats as standard.
• Not all languages use ‘.’ for floating point numbers! Remember to use
format_float() and unformat_float() to recieve and output
floating point numbers in the users locale
• Consider Right To Left (RTL) languages in CSS/design [.dir-rtl]
26. 9. Internationalisation
Common pitfalls:
• Concatenating strings, this breaks badly for rtl languages or when
its impossible to translate correctly
• Using the same string in different contexts
• Use AMOS SCRIPT in git commits to do an AMOS CPY to make
the translators life easier http://docs.moodle.org/dev/Languages/
AMOS#AMOS_script
• Using PARAM_FLOAT for user input
27. 10. Testing
• A big focus for Moodle over the last two years
• Unit testing with phpunit
• Tests written in php and executed in a sandboxed ‘per unit’ environment.
• Much more powerful than the old simpletest environment
• Test environment is reset between tests
• Data generators allow test data to be easily constructed
• Extensive range of assertions
• Automated acceptance testing, using behat
• Tests written in English and executed automatically in a browser environment
• Used for UI testing in multiple environments
• Manual tests for situations which are not possible to automate
• All automated tests are being run and verified on a weekly basis to check for
regressions
28. 10. Behat Demo
Scenario: Login to course and add forum
Given the following "users" exists:
| username | firstname | lastname | email |
| presenter1 | Presenter | Dan | dan@moodle.com |
And the following "courses" exists:
| fullname | shortname |
| iMoot Course | imoot |
And the following "course enrolments" exists:
| user | course | role |
| presenter1 | imoot | editingteacher |
And I log in as "presenter1"
And I follow "iMoot Course"
And I turn editing mode on
And I add a "Forum" to section "1" and I fill the form with:
| Forum name | iMoot Forum |
| Forum type | Standard forum for general use |
| Description | Test forum description |
When I follow "iMoot Course"
Then I should see "iMoot Forum"
29. 10. Testing
Pitfalls
• No tests at all
• Consider using TDD for new code (its likely to be helpful
for you too!)
• We will become stricter about this over time (no excuses)
• Adding complex logic into tests and other ‘test smells’
• http://xunitpatterns.com/Test%20Smells.html is
recommended reading
• Learning curve setting up the tools
• Please post on the forums and help us improve our tools!
30. Grab bag..
• Knowledge of git and how to create a git branch is essential. As are
good commit messages (see http://docs.moodle.org/dev/
Commit_cheat_sheet )
• Backwards compatibility must be maintained for for core code,
ensure that your changes don’t break backwards compatibility
• When fixing bugs, we generally need to support the last 3 versions
currently in support, as specified in http://docs.moodle.org/dev/
Releases
• Don’t be put off from contributing your code if you can’t do all of
what I suggest. Moodle HQ can help prepare code for integration
(and appreciate any effort you are able to give).
