How to guarantee your change is integrated to Moodle core


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

How to guarantee your change is integrated to Moodle core

  1. 1. Dan PoltawskiIntegratorMoodle HQHow to guarantee your change isintegrated to Moodle core@dan_p
  2. 2. Who am I?• Core developer in Moodle community since 2005• Worked with schools, universities and businessesaround UK• Moved to Australia and joined Moodle HQ in 2012 asan Integrator and Developer• Since joining HQ, i’ve spent a lot of my timecomplaining about the price of beer in Perth...$10!£7€8(
  3. 3. Who am II’m also part of the Integration Team..• Experienced group of Moodle developers at HQ, whoact as the final ‘gatekeepers’• Conducting final checks before code makes it intoMoodle release• Bring historical context and try to facilitatecommunication between interested parties• Consider the whole communities point of view•
  4. 4. How to guarantee your change isintegrated to Moodle core
  5. 5. How to guarantee your change isintegrated to Moodle coreYou can’t!
  6. 6. Why not..• The Moodle community is diverse and we need to support alarge community in a generic way• We’re maintaining a ‘platform’ with core tools• We don’t have unlimited resources to maintain every featureanyone can think of..use• 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. 7. Why contribute anything to core?• It’s a bug• You can’t fix core bugs inplugins!• There isn’t an appropriateplugin point• You’re confident the Moodlecommunity will be on board• Its rewarding!• Dan core contributors• (we’ve got 2800 open bugs andappreciate help)025507510028517684932.1 2.2 2.3 2.4 2.5Non-Moodle HQ core contributorsper release
  8. 8. But if you fit the bill..Here are some ways to increase your chances of success..
  9. 9. 1. Process• Same for any developer, even MoodleHQSimplified:• Make code available as a git branch• Multiple rounds of code review• Pulled into main Moodle repository andtested• If successful, closed and change isdeployed
  10. 10. 1. ProcessPitfalls:• Learning the ropes can be daunting, don’t be afraid toask for help!• Some aspects of the process involve waiting forfeedback• Other parts of the process request your feedbackquickly, in a time limited way (e.g. ‘testing failed’ state)
  11. 11. 2. Tracker• All developments start with a trackerissue. The ‘home’ of developers, lots ofknowledge recorded on issues• Be sure to search for and link togetherrelated issues• Record your thoughts/decisions whiledeveloping code, is useful reference• Be sure to link to related forumdiscussions, docs and materials whichare relevant, else a developer may notaware of this
  12. 12. 2. TrackerPitfalls:• Commenting on an already closed issue• Useful in some cases, but if new work is required, anew issue is needed• Creating duplicate issues• Please search, make use of component fields tonarrow down issues• Some actions need additional permissions, see MoodleDocs: Tracker Guide
  13. 13. 3. Community support• Gather support from the community for yourchanges:• Announce and publicise on forums, twitter,moots etc.• For major changes, construct a specification onthe developer docs wiki and solicit feedback• Be sure to consider use cases other than yourown• Once you’ve gathered tracker votes, commentsand support, be sure to link from the tracker
  14. 14. 3. Community supportPitfalls• Not soliciting any feedback• Bumping forum posts to get attention• If you are not getting interest it may actually indicate thatnobody else is interested.. which might not be a goodfit.• Ignoring a use case which doesn’t fit with yours• We can’t ignore specific use cases in core
  15. 15. 4. Coding Style• Moodle has nearly 1 million lines of code which haveevolved over 10+ years from hundreds of developers• The Moodle coding style was created to improveconsistency and should be followed for all new code:• Lots of old code sucks, don’t copy it!• The codechecker and moodlecheck plugins allowyou to check your code against coding style rulesautomatically.• Try to take a sensible approach to any code you aremodifying. Its often sensible to match the surroundingstyle for better readability
  16. 16. 4. Coding StyleCommon Pitfalls• Not checked against code checker at all• Gives suggestion of poor attention to detail, don’t give us thatexcuse!• Use of underscores in variable names• Incorrect spacing on control statements• Developing without DEBUG_DEVELOPER
  17. 17. 5. Code Review• All Moodle Code is reviewed multiple times before making it into thefinal release• Moodle is so huge and has been evolving for so long that no one personknows everything• The code review serves as a way to both improve the code and to sharethe historical context which might apply to each change• Ideally, for the best chance of success, someone experienced with thearea you are coding would review the code (e.g. component maintainer)• Code review is a two way process, don’t be afraid to justify yourdecisions (an important part of the process is to extract the rationale forothers to see)
  18. 18. 5. Code ReviewPitfalls:• Difficulty finding a peer reviewer• Try to be patient and when your patience runs out, consider campaigningpolitely on the forums• Reviewers can be critical and sometimes frank• Try not to take it personally, the goal of everyone is to find the besttechnical solution for each issue• Disagreement with reviewer• Feel free to state your case and if necessary, disregard their advice. Butbe sure to justify your rationale for final integration
  19. 19. 6. Cross-DB Compatibility• Moodle supports PostgreSQL, MySQL, Oracle and MS SQL.Please try to test against another db to your usual environment asa minimum• Pay special attention when writing custom SQL• At this time, transactions cannot be relied upon in core, becausewe still support myisam• Can be useful for constructing complex queries against differentengines:
  20. 20. 6. Cross-DB CompatibilityCommon 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 vsPostgreSQL)• Not using placeholders for user input• Not using the XMLDB editor for creating schema definitions
  21. 21. 7. Performance• Don’t decrease performance!• Database queries are by far one of the most expensive things youcan do, try not to increase them, ensure that they are constant.• If you improve performance, please record and share your results onthe 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 yourown caches:
  22. 22. 7. PerformanceCommon pitfalls• DB Queries in loops or widely called functionsforeach ($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. 23. 8. Security• You should know and be using, at least:• optional_param()/ required_param() or formslib to validateuser input• PARAM_xxx types for cleaning user input• XSRF protection using session keys• s(), p(), format_string() and format_text() foroutputting user-inputted text• How to control access using capabilities, the context hierarchy andrequire_login() etc• Our process for dealing with security bugs is different, in order toachieve responsible disclosure.
  24. 24. 8. SecurityCommon 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 tomultilang
  25. 25. 9. Internationalisation• Moodle 2.5 has over 100 language packs and is a strong multilingualcommunity• 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 ofstandard time formats as standard.• Not all languages use ‘.’ for floating point numbers! Remember to useformat_float() and unformat_float() to recieve and outputfloating point numbers in the users locale• Consider Right To Left (RTL) languages in CSS/design [.dir-rtl]
  26. 26. 9. InternationalisationCommon pitfalls:• Concatenating strings, this breaks badly for rtl languages or whenits impossible to translate correctly• Using the same string in different contexts• Use AMOS SCRIPT in git commits to do an AMOS CPY to makethe translators life easier• Using PARAM_FLOAT for user input
  27. 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 forregressions
  28. 28. 10. Behat DemoScenario: Login to course and add forumGiven the following "users" exists:| username | firstname | lastname | email || presenter1 | Presenter | Dan | |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 onAnd 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. 29. 10. TestingPitfalls• No tests at all• Consider using TDD for new code (its likely to be helpfulfor you too!)• We will become stricter about this over time (no excuses)• Adding complex logic into tests and other ‘test smells’• isrecommended reading• Learning curve setting up the tools• Please post on the forums and help us improve our tools!
  30. 30. Grab bag..• Knowledge of git and how to create a git branch is essential. As aregood commit messages (see )• 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 versionscurrently in support, as specified in• Don’t be put off from contributing your code if you can’t do all ofwhat I suggest. Moodle HQ can help prepare code for integration(and appreciate any effort you are able to give).
  31. 31. Questions??
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.