Actions

Developer Area/Developer Meetings/93: Difference between revisions

From Mahara Wiki

< Developer Area‎ | Developer Meetings
m (Added a link to a Proposal page for the code linter.)
 
(7 intermediate revisions by 2 users not shown)
Line 12: Line 12:
*Update coding and code review guidelines to add words around security
*Update coding and code review guidelines to add words around security
*PHP 8.1 progress
*PHP 8.1 progress
New items
*Idea to progress towards PHP 8.1: Introduce a project-wide linter
*Standardising/automating the code rules and save development time with a linter (re-think our standards and adapt to more modern PHP 8+ standards)
**What we currently have: <code>make minaccept</code>  
**our <code>minaccept</code> was written in 2010 (12 years ago, which matched that standards at the time of writing)
**#Written in 2010 at the time of ''PHP 5.3'' standards (12 years ago, which matched that standards at the time of it was written)
**we need to adapt our standards to what is perceived as good standards today in other backend languages
**#Unmanaged and difficult to update and manage as it's hard-coded, covering a small subset of rules
**https://www.oracle.com/java/technologies/javase/codeconventions-programmingpractices.html - Java
**How does a linting tool help us?
**https://www.php.net/manual/en/control-structures.elseif.php - the official PHP website cuddles their if/else ifs
**# Less time spent on syntax, more on implementing and pushing solutions (towards PHP 8 compliance).
**https://www.php-fig.org/psr/psr-12/ - PHP PSR12 standards
**# Easily to change, update, and adapt the rules within the project as we need and in our speed.
**https://www.perltutorial.org/perl-if/ - Perl
**# Eventually, CI/CD can warn us of issues of new code we push the code before merging, i.e. on GitLab
**https://www.w3schools.com/php/php_if_else.asp - Schools standards taught today
**# With a standardised syntax, the core team can more easily work with community patches and get them in faster.
**https://firefox-source-docs.mozilla.org/code-quality/coding-style/coding_style_cpp.html Mozilla Firefox's standards
**What is a linter and formatter?
*...
***A linter is a static analysis tool that can show us area of bad coding practice.
General items
*** A static analysis tool to find  weak spots in the code, highlighting issues
*Any other business
*** where rules are configurable
*Next meeting and chair
*** We can change the strictness, warnings vs. errors.
*** Formatters provide syntax checking and updates code
**How does it help other teams at Catalyst?
*** The frontend team use Prettier formatter – a set of rules to follow
*** Fix once, get the benefits going forwards with minimal changes
*** By using Prettier for JavaScript, they can adjust the rules in a prettier.rc/.json for each project.
*** The frontend team agreed to use Airbnb style guide to help  use best practices, but there are many others to choose from.
*** Look into prettier for formatter, ESLint for linter. When starting on ESLint, it asks you for the rules you like.
*** We could have it as a tool that formats the code, so we can diff before pushing change
 
== Minutes ==
[https://seafile.catalyst.net.nz/f/65b34a582bb3462b8815/ Audio recording of the meeting].
 
* Attendees
** Doris Tam (Wellington, NZ) - Mahara developer, Catalyst IT
** Gold (Wellington, NZ) - Mahara developer, Catalyst IT
** Kristina Hoeppner (Wellington, NZ), Mahara project lead, Catalyst IT
** Adam Bark (Texas, US), Co-founder, LearnOpenTech
* Apologies
** Robert Lyon
* Agenda
** `make minaccept` updates : postponed for Bob being present
** `make security` updates: still needs attention
** PHP 8.2 compatibility
*** Mahara Core has no Errors or Warnings
*** Third party libraries in the Mahara codebase still have some issues, but not a lot. Updates may resolve these.
** Project wide code linter
***[https://github.com/PHPCompatibility/PHPCompatibility PHPCodeSniffer]
*** [https://www.phpro.be/en/partners-and-tools/grumphp GrumPHP]
*** A JS linter will also be needed but will discuss in the future
*** [[Developer Area/Coding guidelines|https://wiki.mahara.org/wiki/Developer_Area/Coding_guidelines]]
*** [https://wiki.mahara.org/wiki/Proposals/Code_Standards_checking_on_commit Extra discovery has been done and captured as this proposal as well].
* Other business
** Adam - Is there object storage support in Mahara?
*** There is an [https://github.com/catalyst/mahara-module_objectfs S3 module]. This is one Adam already knew about and has raised [https://github.com/catalyst/mahara-module_objectfs/issues/15 an issue] on it.
*** There is also an OpenStack module in the works, but it isn't public yet.
** Kristina - there are new episodes of the [https://podcast.mahara.org/ podcast].
* Next Developer Meeting
** Who: Bob (Chair), Kristina (Note taker)
** When: Wednesday, 22 March 2023 at 23:00 UTC

Latest revision as of 15:02, 25 Ocak 2023

Agenda for the 93rd Mahara developer meeting on Tuesday, 24 January 2023 at 23:00 UTC

We will meet online using Big Blue Button (A Catalyst staff member will initiate the call).

Our #Mahara channel on Matrix will be our backup in case there are problems with the web conferencing tool and we'll need to chat to resolve it. You can connect to our Matrix channel also using the #mahara channel on Freenode IRC.

  • Chair: Doris Tam
  • Minute taker: Gold

Chair and minute taker duties explained

Agenda

Items from previous meetings

  • Change to makefile to add some basic security checks
  • Update coding and code review guidelines to add words around security
  • PHP 8.1 progress
  • Idea to progress towards PHP 8.1: Introduce a project-wide linter
    • What we currently have: make minaccept
      1. Written in 2010 at the time of PHP 5.3 standards (12 years ago, which matched that standards at the time of it was written)
      2. Unmanaged and difficult to update and manage as it's hard-coded, covering a small subset of rules
    • How does a linting tool help us?
      1. Less time spent on syntax, more on implementing and pushing solutions (towards PHP 8 compliance).
      2. Easily to change, update, and adapt the rules within the project as we need and in our speed.
      3. Eventually, CI/CD can warn us of issues of new code we push the code before merging, i.e. on GitLab
      4. With a standardised syntax, the core team can more easily work with community patches and get them in faster.
    • What is a linter and formatter?
      • A linter is a static analysis tool that can show us area of bad coding practice.
      • A static analysis tool to find weak spots in the code, highlighting issues
      • where rules are configurable
      • We can change the strictness, warnings vs. errors.
      • Formatters provide syntax checking and updates code
    • How does it help other teams at Catalyst?
      • The frontend team use Prettier formatter – a set of rules to follow
      • Fix once, get the benefits going forwards with minimal changes
      • By using Prettier for JavaScript, they can adjust the rules in a prettier.rc/.json for each project.
      • The frontend team agreed to use Airbnb style guide to help use best practices, but there are many others to choose from.
      • Look into prettier for formatter, ESLint for linter. When starting on ESLint, it asks you for the rules you like.
      • We could have it as a tool that formats the code, so we can diff before pushing change

Minutes

Audio recording of the meeting.

  • Attendees
    • Doris Tam (Wellington, NZ) - Mahara developer, Catalyst IT
    • Gold (Wellington, NZ) - Mahara developer, Catalyst IT
    • Kristina Hoeppner (Wellington, NZ), Mahara project lead, Catalyst IT
    • Adam Bark (Texas, US), Co-founder, LearnOpenTech
  • Apologies
    • Robert Lyon
  • Agenda
  • Other business
    • Adam - Is there object storage support in Mahara?
      • There is an S3 module. This is one Adam already knew about and has raised an issue on it.
      • There is also an OpenStack module in the works, but it isn't public yet.
    • Kristina - there are new episodes of the podcast.
  • Next Developer Meeting
    • Who: Bob (Chair), Kristina (Note taker)
    • When: Wednesday, 22 March 2023 at 23:00 UTC
Retrieved from ‘https://wiki.mahara.org/index.php?title=Developer_Area/Developer_Meetings/93&oldid=13539’