Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Czech Hackfest 2009 notes: Difference between revisions

From MoodleDocs
(unit testing)
 
(12 intermediate revisions by 3 users not shown)
Line 1: Line 1:
''Hackfest participants, if anything we discussed has been been missed out, please [https://docs.moodle.org/en/index.php?title=Developer_meeting_September_2009&action=edit edit the page] and add it!''
''Hackfest participants, if anything we discussed has been been missed out, please [https://docs.moodle.org/en/index.php?title=Developer_meeting_September_2009&action=edit edit the page] and add it!''


==Moodle 2.0==
==Moodle 2.0==
Line 12: Line 11:
* ''development > experimental > database export''
* ''development > experimental > database export''
* to learn sql write stats code, write unit test to check if sql is correct
* to learn sql write stats code, write unit test to check if sql is correct
* [[DML functions]]
* [[DML functions]], [[DB layer 2.0 migration docs|Migrating from 1.9 DB code to 2.0]]


===Plugins===
===Plugins===
Line 18: Line 17:
*Complete list of plugin locations available
*Complete list of plugin locations available
*previously stuff was hardcoded, now cleaned up
*previously stuff was hardcoded, now cleaned up
*After 2.0, work on integration with new moodle.org Plugins database to download/install via web GUI.
*to do: work on lang pack part
*to do: work on lang pack part


Line 100: Line 100:


==Testing==
==Testing==
===QA testing===
* [http://tracker.moodle.org/browse/MDLQA-1 Moodle 2.0 QA testing]
* Tracker project, MDLQA, one bug for each release, subtasks for every feature/piece of functionality (up to 10 steps)
* Workflow – passed, failed, obsolete
* If a test fails, link to MDL issue
* Dual purpose – list of features/functions defines what Moodle is, page [[Features]] out-of date and not maintained, whereas new lists [[:Category:Functional testing]] will list all Moodle features
* Ask Moodle community to help test before release, testers group to sign things off
* Before Moodle 2.0 is released, 100% tests passed
* Duplicate for Moodle 2.1, reset, add new stuff for 2.1
* QA/functional testing to be run after beta version, if a developer makes changes to a module which has chance of regression they should go and reset the QA tests for the module
* To do: document QA testing process, rewrite Tuesday testing process, review members of testers group (group can be the same for QA testing and Tuesday testing), asking people to confirm whether they wish to remain in the testers group


===Unit testing===
===Unit testing===
Line 111: Line 124:
* Looking at implementing [http://www.phpundercontrol.org phpUnderControl] (Jordan)
* Looking at implementing [http://www.phpundercontrol.org phpUnderControl] (Jordan)
* Will look at reimplementing fake db during the 2.0 beta period
* Will look at reimplementing fake db during the 2.0 beta period
==Performance and cron==
Build smoketest server to do daily performance tests on CVS code
Measure: CPU time, RAM use
With Caches on/off
User stories for performance measurement
#user logs in and views the front page
#open MyMoodle page with 20 courses
#attempting a quiz
#posting to a forum
With Site types
#Many courses, Many users
#Many courses, Few users
#Few courses, Many users
#Few courses, Few users
#Lots of quizzes
#Lots of Scorm packages
#MySQL vs PostgreSQL
Ideas for performance improvement
#Cache capabilities for guests
#Shared memory for capabilities
#LANGROOT and THEMEROOT for storing downloadable packs separately from normal DATAROOT (and not over network, for example).
#User picture icons, better caching control
#log archiving
#storing session table in alternate database (perhaps via a session storage plugin mechanism)
#Oracle is evil!
See also [[Scheduled Tasks Proposal]] about cron
==Editors==
See [[Text formats]]
==My Moodle==
dashboard pages
* ''/my/index.php''
* only users can see their own
* users can customize freely
* users can add their own pages
* link to page for changing settings (in settings block)
* admin can define default blocks that users can remove
public profile pages
* ''/user/profile.php''
* everyone can see everyone's
* admin can define blocks that are always seen
* users cannot delete these blocks
* users can add new blocks (if they have the capability)
course profile
* ''/user/view.php''
* picture, description, general information, private information (only displayed to teachers)
* link to full public profile
* controlled by code (no editing by any users)
Use navigation block rather than tabs
Hubert Chathi to develop MyMoodle
==Workshop module==
* Provides options for peer and self assessment, different grading strategies
* Fields for introduction, instructions for submitting, instructions for assessing
* Planner tool with current workshop phase highlighted
* Phases: setup, submission, assessment, grading evaluation, closed
* Assessment form with grade and comment for each aspect
* Submissions may be allocated manually or randomly
* Capabilities to allow students to view names of submission authors and view names of reviewers
* 2 grades for each student in gradebook for submission and assessment, may be aggregated as desired
* To do: migration code, example submissions support, user interface improvements, review of lang strings and help files
==Wiki module==
* Latest code from Ludo, module on right track, though still needs quite a bit of work
* Wiki history code taken/reused from OU wiki
* To do: text formats, comments API, grading, lang strings review
* Also look into reducing the number of wiki-specific blocks (currently 6) to one or none
==Feedback vs Questionnaire==
Both of these modules are still popular.  Questionnaire is the most-downloaded 3rd party module we have, and Feedback was previously selected as a "standard" module and so is also heavily used by people expecting an upgrade path.
For consistency we need to try and bring these users together in one upgrade path.  The final result needs to support the features of both.
===Feedback has problems ===
* Andreas Grabs (the author) is not able to maintain it in future
* There are some database structure issues that need to be fixed.
* There are some interface issues and string issues needing to be fixed.
===Questionnaire has problems===
* There are some database structure issues that need to be fixed.
* There are some security issues that need to be fixed.
* There are some cross-course features that need to be redesigned.
===Survey has problems===
People expect to be able to create their own surveys in it and are dissapointed when they can't.  The existing survey instruments are powerful and translated into 70+ languages but under-used.  Real shame because the pedgagogical benefits of using COLLES every week (for example) are huge.
===What we will do for 2.0===
Martin voted for Feedback to have necessary work done and go into 2.0, because people are crying out for a standard user-survey tool, and then be upgraded to a new super-Survey module in 2.1.
Almost everyone else at the hackfest disagreed and thought none of them should go into 2.0, so that we would avoid un-necessary maintenance headaches in future.  Feedback and Questionnaire would continue in contrib.
Mike Churchward volunteered to come up with a proposal for a new version of Questionnaire that fixed the problems and also added all Feedback features, as well as templates that utilise lang strings so that we could merge Survey as well.
Martin would like that new module to be called Survey and replace the core Survey in 2.1, converting all existing questionnaire and feedback instances into "survey" instances.  This would fix the awkward naming of these modules once and for all.
==Moving Moodle to Git==
===Why use git?===
* History etc is much faster
* Local check-ins / tracking
* Commits are kept as sets of files
* Easy reverting of checkins
===Possible workflows===
* check into head
* copy from 1.9 to head
** cherry-pick into 1.9 from head, or
** merge trees (gets everything)
* use more feature branches
Petr had a valid point that his old workflows with CVS worked perfectly well for him and were not possible to duplicate in git because the git support in Eclipse and Netbeans was immature.
We talked about the possibility of moving contrib to git first, because it would be really useful there, and allow everyone to try out the workflows and get used to it.
There is no timeline for this yet, but Martin has bought some git books for Moodle HQ and we will all start trying it out.

Latest revision as of 05:14, 23 December 2009

Hackfest participants, if anything we discussed has been been missed out, please edit the page and add it!

Moodle 2.0

DB stuff

  • New development area in admin menu, new feature in db layer - db session
  • Use db for session information setting (on by default)
  • things which really need testing - sessions, large scale
  • migrating data from one db to another db server
  • development > experimental > database transfer
  • development > experimental > database export
  • to learn sql write stats code, write unit test to check if sql is correct
  • DML functions, Migrating from 1.9 DB code to 2.0

Plugins

  • Every plugin should have support for install, upgrade, access etc
  • Complete list of plugin locations available
  • previously stuff was hardcoded, now cleaned up
  • After 2.0, work on integration with new moodle.org Plugins database to download/install via web GUI.
  • to do: work on lang pack part

File API

  • previously teachers moving, renaming files and linking them from everywhere e.g. backup and restore includes all course and site files just in case
  • can be lots of files in course files not used at all, people upload new version, same file put in lots of courses
  • 2 character directory names
  • things which really need testing - copying of files during upgrade
  • need to warn admins in upgrade notes
  • no longer course files for teachers
  • in 2.0 file link will contain lots of info - path, file name
  • if teacher uploads new version of file, students immediately see new version
  • re draft files, previously editing files in place, no undo, when editing set of files copy of old files made, copied to draft area, after editing click save then option to submit or cancel / discard
  • no direct editing of files, done in separate area, instead of using course files, use file picker, save rubbish elsewhere
  • missing piece - management of personal files
  • interface needs optimizing
  • not yet done: quotas
  • editing activity content section ajaxy

Navigation

  • Needs to be a block
  • 2 dimensions - context (site, course, activities) and page type (course-view, mod-quiz-view etc)
  • moodle theme changes, base class, page class
  • mod/quiz/lang - lang file in plugin folder (same for core and contrib)
  • mod/quiz/theme - theme file in plugin folder (same for core and contrib)
  • base theme as simple as possible, install theme will be different - nice-looking theme
  • no more standard red, blue etc, config options to change colours instead, easier to customize
  • 2.0 themes should have much better performance
  • should be easy to install new icon sets e.g. tango
  • sam going to convert/redevelop one theme for 2.0 then patrick to develop 20

Web services

Roles

  • 2.0 has admin tools for managing roles, but still difficult for sites with large numbers of users, looking at how other systems manage roles
  • For each capability, have allowed roles and prohibited roles (or even remove prohibited role column completely) - see http://skodak.org/blog/?p=29
  • Manager role without doanything capability, fixed admin role with doanything cap only
  • Changes in role archetypes,changes in role enrolments, so students assigned site-wide and enrolments separate
  • No changes in DB or API only internal

Enrolments

See Enrolment rewrite and role tweaks proposal (written in March 2009)

  • Currently enrolment data stored in the enrolments table, guest access + passwords cause problems in 1.8, 1.9, can't disable built-in features such as guest access
  • How to improve performance and improve plugins?
  • Need instances of enrolment plugins in each course e.g. paypal instances in same course each with different cost
  • Course password (enrolment key) separate for guests and students, settings e.g. course cost kept in enrolment plugin, each course only has plugins which are enabled
  • Suggestion - change course settings page, perhaps have enrolments as separate link in course admin block
  • Question: should enrolment plugins work in different contexts - course, category?

Site-wide groups

See Site-wide groups

Backup and restore

See Backup 2.0

Gradebook 2.0

Grade settings provided by gradelib like groups settings on mod_edit.php

Gradinglib also needs to provide more of the grading interfaces that modules use in their grading interfaces, such as ratings.

Separate ratings API (like comments) ratingslib.php ratings table, and ratings parameters on the course_modules table

Also, to deal with gradebook hiding issues:

  1. Hiding of grades only applies to user report. Conditional activities and grader report always should show them.
  2. Add one option to only aggregate visible items (or not).

Languages

See Languages and Development talk:Languages

Testing

QA testing

  • Moodle 2.0 QA testing
  • Tracker project, MDLQA, one bug for each release, subtasks for every feature/piece of functionality (up to 10 steps)
  • Workflow – passed, failed, obsolete
  • If a test fails, link to MDL issue
  • Dual purpose – list of features/functions defines what Moodle is, page Features out-of date and not maintained, whereas new lists Category:Functional testing will list all Moodle features
  • Ask Moodle community to help test before release, testers group to sign things off
  • Before Moodle 2.0 is released, 100% tests passed
  • Duplicate for Moodle 2.1, reset, add new stuff for 2.1
  • QA/functional testing to be run after beta version, if a developer makes changes to a module which has chance of regression they should go and reset the QA tests for the module
  • To do: document QA testing process, rewrite Tuesday testing process, review members of testers group (group can be the same for QA testing and Tuesday testing), asking people to confirm whether they wish to remain in the testers group

Unit testing

  • Site admin > Development > Unit testing
  • Currently using simple test, but not designed for php5
  • Aim to encourage people, including contrib devs, to write unit tests

Summary:

  • Looking to move to PHPUnit before Moodle 2.0 (Sam H to work on spec for converting to PHPUnit and post in Gen Dev forum)
  • Looking at implementing phpUnderControl (Jordan)
  • Will look at reimplementing fake db during the 2.0 beta period

Performance and cron

Build smoketest server to do daily performance tests on CVS code

Measure: CPU time, RAM use With Caches on/off

User stories for performance measurement

  1. user logs in and views the front page
  2. open MyMoodle page with 20 courses
  3. attempting a quiz
  4. posting to a forum

With Site types

  1. Many courses, Many users
  2. Many courses, Few users
  3. Few courses, Many users
  4. Few courses, Few users
  5. Lots of quizzes
  6. Lots of Scorm packages
  7. MySQL vs PostgreSQL

Ideas for performance improvement

  1. Cache capabilities for guests
  2. Shared memory for capabilities
  3. LANGROOT and THEMEROOT for storing downloadable packs separately from normal DATAROOT (and not over network, for example).
  4. User picture icons, better caching control
  5. log archiving
  6. storing session table in alternate database (perhaps via a session storage plugin mechanism)
  7. Oracle is evil!

See also Scheduled Tasks Proposal about cron

Editors

See Text formats

My Moodle

dashboard pages

  • /my/index.php
  • only users can see their own
  • users can customize freely
  • users can add their own pages
  • link to page for changing settings (in settings block)
  • admin can define default blocks that users can remove

public profile pages

  • /user/profile.php
  • everyone can see everyone's
  • admin can define blocks that are always seen
  • users cannot delete these blocks
  • users can add new blocks (if they have the capability)

course profile

  • /user/view.php
  • picture, description, general information, private information (only displayed to teachers)
  • link to full public profile
  • controlled by code (no editing by any users)

Use navigation block rather than tabs

Hubert Chathi to develop MyMoodle

Workshop module

  • Provides options for peer and self assessment, different grading strategies
  • Fields for introduction, instructions for submitting, instructions for assessing
  • Planner tool with current workshop phase highlighted
  • Phases: setup, submission, assessment, grading evaluation, closed
  • Assessment form with grade and comment for each aspect
  • Submissions may be allocated manually or randomly
  • Capabilities to allow students to view names of submission authors and view names of reviewers
  • 2 grades for each student in gradebook for submission and assessment, may be aggregated as desired
  • To do: migration code, example submissions support, user interface improvements, review of lang strings and help files

Wiki module

  • Latest code from Ludo, module on right track, though still needs quite a bit of work
  • Wiki history code taken/reused from OU wiki
  • To do: text formats, comments API, grading, lang strings review
  • Also look into reducing the number of wiki-specific blocks (currently 6) to one or none


Feedback vs Questionnaire

Both of these modules are still popular. Questionnaire is the most-downloaded 3rd party module we have, and Feedback was previously selected as a "standard" module and so is also heavily used by people expecting an upgrade path.

For consistency we need to try and bring these users together in one upgrade path. The final result needs to support the features of both.

Feedback has problems

  • Andreas Grabs (the author) is not able to maintain it in future
  • There are some database structure issues that need to be fixed.
  • There are some interface issues and string issues needing to be fixed.

Questionnaire has problems

  • There are some database structure issues that need to be fixed.
  • There are some security issues that need to be fixed.
  • There are some cross-course features that need to be redesigned.

Survey has problems

People expect to be able to create their own surveys in it and are dissapointed when they can't. The existing survey instruments are powerful and translated into 70+ languages but under-used. Real shame because the pedgagogical benefits of using COLLES every week (for example) are huge.

What we will do for 2.0

Martin voted for Feedback to have necessary work done and go into 2.0, because people are crying out for a standard user-survey tool, and then be upgraded to a new super-Survey module in 2.1.

Almost everyone else at the hackfest disagreed and thought none of them should go into 2.0, so that we would avoid un-necessary maintenance headaches in future. Feedback and Questionnaire would continue in contrib.

Mike Churchward volunteered to come up with a proposal for a new version of Questionnaire that fixed the problems and also added all Feedback features, as well as templates that utilise lang strings so that we could merge Survey as well.

Martin would like that new module to be called Survey and replace the core Survey in 2.1, converting all existing questionnaire and feedback instances into "survey" instances. This would fix the awkward naming of these modules once and for all.


Moving Moodle to Git

Why use git?

  • History etc is much faster
  • Local check-ins / tracking
  • Commits are kept as sets of files
  • Easy reverting of checkins

Possible workflows

  • check into head
  • copy from 1.9 to head
    • cherry-pick into 1.9 from head, or
    • merge trees (gets everything)
  • use more feature branches


Petr had a valid point that his old workflows with CVS worked perfectly well for him and were not possible to duplicate in git because the git support in Eclipse and Netbeans was immature.

We talked about the possibility of moving contrib to git first, because it would be really useful there, and allow everyone to try out the workflows and get used to it.

There is no timeline for this yet, but Martin has bought some git books for Moodle HQ and we will all start trying it out.