Actions

Developer Area/Developer Meetings/93: Difference between revisions

From Mahara Wiki

< Developer Area‎ | Developer Meetings
No edit summary
m (Added a link to a Proposal page for the code linter.)
 
(5 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
*Introduce a project-wide linter (re-think our standards and adapt to more modern PHP 8+ standards)
**What we currently have: <code>make minaccept</code>  
**What we currently have: <code>make minaccept</code>  
**#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)
**#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)
**#Difficult to update and manage as it's hard-coded
**#Unmanaged and difficult to update and manage as it's hard-coded, covering a small subset of rules
**#Only covers a small subset of rules
**How does a linting tool help us?
**#These set of rules are managed by us, and we don't have time to look for each rule ourselves.
**# Less time spent on syntax, more on implementing and pushing solutions (towards PHP 8 compliance).
**Why should we have a linting tool?
**# Easily to change, update, and adapt the rules within the project as we need and in our speed.
**# Consistent code and coding practices and becoming more PHP 8 compliant.
**# Eventually, CI/CD can warn us of issues of new code we push the code before merging, i.e. on GitLab
**# Automate some code-review, so the dev can use time better by focusing on the important logic of patches
**# With a standardised syntax, the core team can more easily work with community patches and get them in faster.
**# Never argue about syntax ever again when the standards are computed!
**# Easily change, update, and adapt the rules within the project consistently with a tool that pulls in modern coding standards for us.
**# Give new developers an easier time picking things up with a computed style guide and start pushing code faster.
**# We can go at our own speed. Start with warnings first, and slowly turn the rules into errors. Errors prevent pushing, warnings only suggest.  
**# Eventually, our CI can enforce/warn us of issues where we can still push the code and disallow merging, i.e. on GitLab
**# Crucial that open source project standardise syntax so core devs can save time when community members will have different coding styles.
**What is a linter and formatter?
**What is a linter and formatter?
***A linter is a static analysis tool that can show us area of bad coding practice.
***A linter is a static analysis tool that can show us area of bad coding practice.
Line 34: Line 27:
*** We can change the strictness, warnings vs. errors.
*** We can change the strictness, warnings vs. errors.
*** Formatters provide syntax checking and updates code
*** Formatters provide syntax checking and updates code
** Examples of backend languages moving forward with syntax, specifically if/else cuddling
**How does it help other teams at Catalyst?
***https://www.oracle.com/java/technologies/javase/codeconventions-programmingpractices.html - Java
***https://www.php.net/manual/en/control-structures.elseif.php - the official PHP website cuddles their if/else ifs
***https://www.php-fig.org/psr/psr-12/ - PHP PSR12 standards
***https://www.perltutorial.org/perl-if/ - Perl
***https://www.w3schools.com/php/php_if_else.asp - Standards taught today for students/learners including university
***https://firefox-source-docs.mozilla.org/code-quality/coding-style/coding_style_cpp.html Mozilla Firefox's standards
**At Catalyst
*** The frontend team use Prettier formatter – a set of rules to follow
*** The frontend team use Prettier formatter – a set of rules to follow
*** The code was only ever all changed just once after deciding on the rules
*** Fix once, get the benefits going forwards with minimal changes
*** Going forwards, there will be minimal changes in code.
*** By using Prettier for JavaScript, they can adjust the rules in a prettier.rc/.json for each project.
*** They use for JS: Prettier, where they can adjust the rules in a prettier.rc/.json
*** The frontend team agreed to use Airbnb style guide to help  use best practices, but there are many others to choose from.
*** There are many style guides. The frontend team agreed to use Airbnb style guide to help  use best practices.
*** Have formatters to automatically execute upon saving a file.
*** Tools shouldn't be blockers, they need to help us.
*** Look into prettier for formatter, ESLint for linter. When starting on ESLint, it asks you for the rules you like.
*** Look into prettier for formatter, ESLint for linter. When starting on ESLint, it asks you for the rules you like.
*** Bob: We should have it that the tool formats the code, so we can diff before pushing changes.
*** We could have it as a tool that formats the code, so we can diff before pushing change
** Cons of linters/formatters
 
*** What if it changes logic? They shouldn't, but we can choose our speed by setting all rules warnings at the start, and fix one rule at a time.
== Minutes ==
*** Even though it's looks different at the start, over time it will become familiar.
[https://seafile.catalyst.net.nz/f/65b34a582bb3462b8815/ Audio recording of the meeting].
*** Everything was ''<nowiki/>'new''' at a some point.
 
*** We don't like things secretly changing our code in the background. Don't use a formatter, just start with a linter so that you can solve the issues.
* Attendees
General items
** Doris Tam (Wellington, NZ) - Mahara developer, Catalyst IT
*Any other business
** Gold (Wellington, NZ) - Mahara developer, Catalyst IT
*Next meeting and chair
** 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’