Calendar Update

No worries! Bugs happen. 07:20 was my last message, and 07:25 has come and gone unreminded. Looks good.

In other news I guess we figured out why we’ve had email / text reminders for classes off for so long :wink:

I still think they’re handy. I have a guess for how often the cron job kicks off, though. And maybe that’s more often than strictly necessary.

Did you revert back to the prior version of calendar? All of the enhancements that were visible yesterday seem to be gone today.

1 Like

Sorry I missed your post 11 hours ago. Duh on my part.

@denzuko … what is the status of the pre-prod? Can it be used to deploy the calendar for beta testing?

again, the moment we tackle all those linting errors we’ll have a docker image that’s pushed to pre-prod automatically

Have you changed over to PSR-2 ?

https://bakery.cakephp.org/2014/12/16/CakePHP-3-to-fully-adopt-PSR-2.html

1 Like

me? yes, back in 2014 while I still publicly supported ruby and php.

Well, last I looked the calendar travisci was still running cakephp in phpcs instead of PSR-2

Also with an old version of phpcs because only old versions support the old cakephp standard.
We upgraded to 3.4 …

To start off yes we can see the upgrade to cake 3.4

travisci was still running cakephp in phpcs instead of PSR-2

Well that phpcs is what is being pulled in from composer and PSR-2 is a coding standard. Which the majority of those errors in the build log are phpcs pointing out that our code is not compliant to PSR-2 coding standards.

How is that important for getting this calendar update out to everyone?

our code is not compliant to PSR-2 coding standards

How is that important for getting this calendar update out to everyone?

If one has:

But still suffers from:

giphy

And from:

then how can one ever get to enjoy:

We are currently using an old cakephp coding standard.
PSR-2 gives far less errors.

We change this travis config and replace

before_script:
  - sh -c "composer require 'cakephp/cakephp-codesniffer:dev-master'"
  - phpenv rehash

with

before_script:
 - pyrus install pear/PHP_CodeSniffer
 - phpenv rehash

And change the composer config to replace

"cs": "phpcs -p --extensions=php --standard=vendor/cakephp/cakephp-codesniffer/CakePHP ./src ./tests ./config ./webroot",

with

"cs": "phpcs -p --extensions=php --standard=PSR2 ./src ./tests ./config ./webroot",

So that was a little unneeded. To quote codesniffer’s own repo:

The master branch contains codesniffer rules that are based on the PSR2 standard. If you want to check against the historical CakePHP coding standard use any of the 1.x releases.

So we where already supporting PSR2. So just to be thorough here; if we’re getting less errors now just by “switching linters” but not fixing the lint errors in the code then was that really a fix?

I’m not certain what is in cakephp-codeniffer but last time I tried to install it, I had to use an old version of phpcs.
.
Why not just use the latest phpcs as it has the PSR2 standard?

I’m still not certain why we are worrying about stylistic linting.

Linting doesn’t just catch stylistic errors it also catches precursors to other errors and areas of improvement.

There’s been two instances that I’ve caught a bug in the calendar because of misdesigned code which needed refactoring and those came up from linting. Another case would be when I was in a previous role and a Harvard grad developer introduced a security flaw into a JTW api implementation just because he wanted to get around a bug in his application’s request size.

Linters are are like the smoke detectors.Sure they could be going of just because one lit a candle or cooked their dinner a little too much but when one needs it they really need it.

1 Like

I can see that … I think the cakephp version has a bunch of unneeded checks is the only thing I can think of . OR the current phpcs version now detects better? But I invite you to try it locally. Install phpcs under linux per the packages and then install the cakephp version. You have to use their phpcs because it is older. I’m all for having the standards but with less errors.

1 Like

I’ve actually been running things on cloud9 and even those show the same thing as travis-ci. Which incidentally enough is using the latest version of phpcs.