How to guarantee your change is integrated to Moodle core

Developer/Integrator em Moodle HQ
22 de May de 2013

Mais conteúdo relacionado

Similar a How to guarantee your change is integrated to Moodle core(20)


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 (
  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 •
  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 • 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
  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: • 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:
  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:
  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 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 | | 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’ • 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 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 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? ?