![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](https://image.slidesharecdn.com/2013-imoot-dan-poltawski-130522222450-phpapp02/85/How-to-guarantee-your-change-is-integrated-to-Moodle-core-6-320.jpg)
![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]](https://image.slidesharecdn.com/2013-imoot-dan-poltawski-130522222450-phpapp02/85/How-to-guarantee-your-change-is-integrated-to-Moodle-core-25-320.jpg)
How to guarantee your change is integrated to Moodle core
- 1. Dan Poltawski Integrator Moodle HQ How to guarantee your change is integrated to Moodle core @dan_p
- 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
- 4. How to guarantee your change is integrated to Moodle core
- 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).
- 31. Questions? ?