Actions

Difference between revisions of "Developer Area/Developer Meetings/52"

From Mahara Wiki

< Developer Area‎ | Developer Meetings
 
(One intermediate revision by the same user not shown)
Line 11: Line 11:
 
# Topics from previous meeting
 
# Topics from previous meeting
 
## mingard will work on finding and documenting duplicated sections, and maybe do a bit of a proposal on how we should restructure the scripts generally
 
## mingard will work on finding and documenting duplicated sections, and maybe do a bit of a proposal on how we should restructure the scripts generally
# Your topic goes here
+
## anzeljg will try to create some plans/wireframes for simplifying Mahara create page procedure
## '''Drop support for PHP 5.3?''' --[[User:Aaronw|aaronw]] ([[User talk:Aaronw|talk]]) 18:42, 29 March 2016 (NZDT)
+
# '''Drop support for PHP 5.3?''' --[[User:Aaronw|aaronw]] ([[User talk:Aaronw|talk]]) 18:42, 29 March 2016 (NZDT)
### [https://pear.php.net/package/PEAR/download/1.10.1 Latest version of PEAR], a Mahara dependency, now requires PHP 5.4 or later. Perhaps it's time Mahara should raise its supported PHP version to 5.4 as well.
+
## [https://pear.php.net/package/PEAR/download/1.10.1 Latest version of PEAR], a Mahara dependency, now requires PHP 5.4 or later. Perhaps it's time Mahara should raise its supported PHP version to 5.4 as well.
### We previously discussed this topic 1 year ago, [http://meetbot.mahara.org/mahara-dev/2015/mahara-dev.2015-04-23-08.03.html Dev Meeting 43, in April 2015]. The decision then was to gather more data about which PHP versions are in use by expanding the site data registration.
+
## We previously discussed this topic 1 year ago, [http://meetbot.mahara.org/mahara-dev/2015/mahara-dev.2015-04-23-08.03.html Dev Meeting 43, in April 2015]. The decision then was to gather more data about which PHP versions are in use by expanding the site data registration.
### The latest stats (from [http://meetbot.mahara.org/mahara-dev/2016/mahara-dev.2016-02-02-07.34.html Dev Meeting 50 in Feb 2016]) still had 20% on PHP 5.3. I'll try to gather more stats before the next meeting.
+
## The latest stats (from [http://meetbot.mahara.org/mahara-dev/2016/mahara-dev.2016-02-02-07.34.html Dev Meeting 50 in Feb 2016]) still had 20% on PHP 5.3. I'll try to gather more stats before the next meeting.
## '''Switch to PSR-2 coding standard?''' --[[User:Aaronw|aaronw]] ([[User talk:Aaronw|talk]]) 16:21, 1 April 2016 (NZDT)
+
# '''Switch to PSR-2 coding standard?''' --[[User:Aaronw|aaronw]] ([[User talk:Aaronw|talk]]) 16:21, 1 April 2016 (NZDT)
### http://www.php-fig.org/psr/psr-2/
+
## http://www.php-fig.org/psr/psr-2/
### Should be easier to find auto-formatting tools; less barrier for devs new to the project
+
## Should be easier to find auto-formatting tools; less barrier for devs new to the project
## '''Namespaces & autoloading?''' --[[User:Aaronw|aaronw]] ([[User talk:Aaronw|talk]]) 16:21, 1 April 2016 (NZDT)
+
# '''Namespaces & autoloading?''' --[[User:Aaronw|aaronw]] ([[User talk:Aaronw|talk]]) 16:21, 1 April 2016 (NZDT)
### Currently Mahara has a lot of standalone methods, and after a recent performance patch that removed an unnecessary loading of *every* artefact class on *every* page load, we now have a "dependency hell" situation where some random actions will fail because they expect a function to be present (usually artefact_get_descendants()) but no scripts have yet loaded it.
+
## Currently Mahara has a lot of standalone methods, and after a recent performance patch that removed an unnecessary loading of *every* artefact class on *every* page load, we now have a "dependency hell" situation where some random actions will fail because they expect a function to be present (usually artefact_get_descendants()) but no scripts have yet loaded it.
### We could avoid that problem if we did this:
+
## We could avoid that problem if we did this:
#### Move all standalone methods into static class methods (perhaps one class per library file)
+
### Move all standalone methods into static class methods (perhaps one class per library file)
#### Put Proper PHP namespaces on all of our library files (namespace supported was added in PHP 5.3)
+
### Put Proper PHP namespaces on all of our library files (namespace supported was added in PHP 5.3)
#### Add an autoloader method that loads up the correct Library file based on the class name and namespace: http://php.net/manual/en/language.oop5.autoload.php
+
### Add an autoloader method that loads up the correct Library file based on the class name and namespace: http://php.net/manual/en/language.oop5.autoload.php
### This will have the added benefit of "modernizing" our code and getting it more compatible with the modern PHP code ecosystem.
+
## This will have the added benefit of "modernizing" our code and getting it more compatible with the modern PHP code ecosystem.
### Downside: all code that calls standalone Mahara functions will need to be fixed to include the classname for each function.
+
## Downside: all code that calls standalone Mahara functions will need to be fixed to include the classname for each function.
#### We can write automated tools to fix most instances of this (although I would not be surprised to discover there are cases where the function name is determined dynamically).
+
### We can write automated tools to fix most instances of this (although I would not be surprised to discover there are cases where the function name is determined dynamically).
#### For backwards-compatibility with 3rd-party plugins, could make a "compatibility" module that declares a standalone method matching each of the current ones in Mahara and simply passing through the call to the new static one. e.g.: function artefact_get_descendants($ids) { return \Mahara\Artefact\ArtefactUtil::artefact_get_descendants($ids); }
+
### For backwards-compatibility with 3rd-party plugins, could make a "compatibility" module that declares a standalone method matching each of the current ones in Mahara and simply passing through the call to the new static one. e.g.: function artefact_get_descendants($ids) { return \Mahara\Artefact\ArtefactUtil::artefact_get_descendants($ids); }
 
# Next meeting and chair
 
# Next meeting and chair
 
# Any other business
 
# Any other business

Latest revision as of 19:58, 28 April 2016

Agenda for the 52nd Mahara developer meeting on Thursday, 28 April 2016, 7:00 UTC

The developer meetings are held on IRC in the #mahara-dev channel. An IRC bot will be used to take minutes of these meetings and agendas made available on these pages before-hand.

If you don't have an IRC client, you can join us using your web browser.

Chair: Kristina

Agenda:

  1. Topics from previous meeting
    1. mingard will work on finding and documenting duplicated sections, and maybe do a bit of a proposal on how we should restructure the scripts generally
    2. anzeljg will try to create some plans/wireframes for simplifying Mahara create page procedure
  2. Drop support for PHP 5.3? --aaronw (talk) 18:42, 29 March 2016 (NZDT)
    1. Latest version of PEAR, a Mahara dependency, now requires PHP 5.4 or later. Perhaps it's time Mahara should raise its supported PHP version to 5.4 as well.
    2. We previously discussed this topic 1 year ago, Dev Meeting 43, in April 2015. The decision then was to gather more data about which PHP versions are in use by expanding the site data registration.
    3. The latest stats (from Dev Meeting 50 in Feb 2016) still had 20% on PHP 5.3. I'll try to gather more stats before the next meeting.
  3. Switch to PSR-2 coding standard? --aaronw (talk) 16:21, 1 April 2016 (NZDT)
    1. http://www.php-fig.org/psr/psr-2/
    2. Should be easier to find auto-formatting tools; less barrier for devs new to the project
  4. Namespaces & autoloading? --aaronw (talk) 16:21, 1 April 2016 (NZDT)
    1. Currently Mahara has a lot of standalone methods, and after a recent performance patch that removed an unnecessary loading of *every* artefact class on *every* page load, we now have a "dependency hell" situation where some random actions will fail because they expect a function to be present (usually artefact_get_descendants()) but no scripts have yet loaded it.
    2. We could avoid that problem if we did this:
      1. Move all standalone methods into static class methods (perhaps one class per library file)
      2. Put Proper PHP namespaces on all of our library files (namespace supported was added in PHP 5.3)
      3. Add an autoloader method that loads up the correct Library file based on the class name and namespace: http://php.net/manual/en/language.oop5.autoload.php
    3. This will have the added benefit of "modernizing" our code and getting it more compatible with the modern PHP code ecosystem.
    4. Downside: all code that calls standalone Mahara functions will need to be fixed to include the classname for each function.
      1. We can write automated tools to fix most instances of this (although I would not be surprised to discover there are cases where the function name is determined dynamically).
      2. For backwards-compatibility with 3rd-party plugins, could make a "compatibility" module that declares a standalone method matching each of the current ones in Mahara and simply passing through the call to the new static one. e.g.: function artefact_get_descendants($ids) { return \Mahara\Artefact\ArtefactUtil::artefact_get_descendants($ids); }
  5. Next meeting and chair
  6. Any other business