Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Greg Bowler
@g105b
It's a very valid point, and I have recently been researching how to formalise coding style/guidelines.
It's hard to change opinions on coding styles that you've had for a long time, and psr-2 is contrary to a some style decisions I've justified over the years.
That's just me being stubborn though, I appreciate that 1.4 million others have some weight in the argument.
php-cs-fixer is the answer to contribution issues that you've had in the past. I can't remember what project it was that you contributed to, but I remember you having a lot of trouble adhering to their style guide, which meant that a single line change was being rejected over and over again... we don't want that - this project needs to be totally open to new contributors.
James Fellows
@j4m3s
Funny you should mention that - I was thinking about it the other day. It was behat, and I really must delete the PR as I gave up on it long ago!
Greg Bowler
@g105b
I've started outlining a contribution file, which is shown to people by Github when submitting new issues: https://github.com/phpgt/dom/blob/master/CONTRIBUTING.md
Made it on dom for now, but this should be pretty standard across all repos.
James Fellows
@j4m3s
What's the conclusion on psr2 then old bean? There's a composer depth for it to auto-fix, and if I run it against the csrf repo it fixes the scrutinizer issues about the placement of the abstract keyword.
Greg Bowler
@g105b
An automated check on a coding standard is certainly a must, but I'm not sure about some style decisions in psr-2. It's all just my opinion, I know.
James Fellows
@j4m3s
Should I leave it with you? As it stands there are no coding standards (though scrutinizer is checking something).
Greg Bowler
@g105b
Yeah, I'll sort it at some point to automate the coding style within CI.
James Fellows
@j4m3s
Cool. In the meantime then, can I standardise csrf on psr2? At the moment it has no defined standards so anything would be better than nothing!
Greg Bowler
@g105b
Your personal coding style is better than psr2 in my opinion. All editors can handle changing between styles so I don't think it's a pressing issue, but do it if it makes you feel better.
James Fellows
@j4m3s
I did it, and sure enough the scrutinizer issues are now closed. I might look into adding a psr2 compliance check into the scrutinizer process so the build fails if the code committed doesn't match the standard. May as well get into the habit of enforcing it, even if we change the standard later.
Greg Bowler
@g105b
Agreed. I'd like to discuss and standardise my preferred style, but it isn't getting done yet so using psr2 is the best way to go right now.
Greg Bowler
@g105b
Looking at psr2 again, it's so far from my personal ideal...
On a different topic, going back to the mailing list question, I was talking to someone about this the other day, and their solution was simple. Now we have a more informal chat area (here), Github issues are the mailing list. People can subscribe via email, and also reply via email to the thread, and everything is logged in the issues list... we have already been using the solution without realising it.
James Fellows
@j4m3s
Good point! when I was thinking about psr2 I realised this was the sort of thing that could go on a ticket.
I think we introduced this forum for Pan-Project issues that didn't fit into a single repo.
Greg Bowler
@g105b
I'm going to create a new repository soon at phpgt/docs which will host the documentation in Markdown format, once I work out how inter-file linking works in a Github repo. I don't plan on using the repo as the area to direct people to for docs, but rather load in the repo into www.php.gt and render it nicely there.
Greg Bowler
@g105b
Scrap that—deleted the phpgt/docs repo in favour of Wikis. Because Wikis are just git repos, I'm looking into how a CI step can generate the API docs for each project and pump the output into the wiki... that would be ideal.
Greg Bowler
@g105b
In other news, I ditched Scrutinizer in favour of Codacy - Scrutinizer was crashy the other day with me, so I had a look for a valid alternative. I'll see how it goes before suggesting it as the preferred tool. What do you think of it? (for dom: https://www.codacy.com/app/phpgt/dom)
I think the guide that it is checking against needs a bit of a tweak... hopefully it can be configured to work with a standardised guide, like Scrutinizer.
Greg Bowler
@g105b
OK while sorting the docs I found a little rabbit hole, peered in it, then fell right in. I'm configuring a post commit hook to take special markup tags in the readme files to keep the wiki up to date. 8-)
James Fellows
@j4m3s
I noticed you'd switched to codacy for the dom build a few days ago. Couldn't figure out why - but now I know. I haven't looked at what they are doing actually.
Teeny rabbit hole I'm sure! Is a post commit hook the right place? (rather than a build script)
James Fellows
@j4m3s
Can't remember why, but I just started looking at bower and grunt. I can see that grunt can handle the scss compiling and javascript minifying etc, even updating the headfile. Should phpgt also do these things (as it does in v1), or should it leave them to grunt - maybe including a template gruntjs file to get people started?
James Fellows
@j4m3s
I've given this some thought and I'm conflicted about the "correct" answer here. There's a whole (actively used and maintained) ecosystem of grunt that handles things like javascript consolidation and minimising, scss processing and autoprefixing, cache busting, moving assetts to the www directory etc. Why would you try to duplicate those in php.gt? On the other hand, I think the objective of php.gt is to create a self contained, low barrier to entry code environment. If that's the case expecting people to install npm and grunt could be a step too far - even if you include a pre-configured grunt file to handle everything using the default locations for php.gt.
James Fellows
@j4m3s
I've spent some time setting up a basic grunt build process that handles pretty much everything right from bower deps through to a single compiled, autoprefixed and minified css and js file. I like the flexibility, and much prefer the fact it's done as part of a dev and build process instead of being done on every page request.
And I've concluded it's a lot of faff. It's surfaced all sorts of code issues in both my js files (using js hint) and sass (using the proper sass compiler and seeing its terminal output)
James Fellows
@j4m3s
But at the end of the day, if the objective of php.gt is an easy entry rad envir
onment, trying to use grunt etc instead of coding those capabilities into php.gt would be a bad call.
Greg Bowler
@g105b
I have tried grunt in the past and actually actively used bower, but they both have massive limitations (as do many node-based things (side note: npm removes kik package; everything in production breaks without warning (I recommend you read about that to gloat how well designed composer is))). For v3 we need to keep in mind how people may want to use build systems, but I do stand by the decision of doing the majority of the basic web build process in php without needing any extra tools. Keeping everything configurable will allow people to use their own tools if they want.
Greg Bowler
@g105b
I'm looking into how to properly handle logging. @j4m3s, you use a logger class don't you? I'm wondering if PHP.Gt should redirect error_log usage for production logging, and eat up and redirect echo, var_dump, etc. for debugging logs. Thoughts?
James Fellows
@j4m3s
Sounds like you're re-inventing a solution to something that's already been solved. psr/log is the composer dependency for the PSR standard logging interface. There are then a host of implementations that you could choose from. You could ship a default, very lightweight implementation but let users override it with something more functional if they want. Either way I really don't think you should write any logging implementation yourself!
Greg Bowler
@g105b
I mean, use stdout and stderr instead of implementing a logging class.
James Fellows
@j4m3s
Hmm Im not sure why you would...
Why not just use a logger via the Psr standard interface? Is someone wants to write direct to stderr then they can fill their boots - but it's not good practise
Greg Bowler
@g105b
I was just talking to a ruby guy, it sounded a nice way of doing it that's all.
James Fellows
@j4m3s
Those crazy hippies?! :)
31 million downloads of the monolog logging framework according to composer.
I use apache/log4php but there are hundreds of alternatives.
Greg Bowler
@g105b
I'm totally aware of the logging frameworks for PHP, I just wanted to hear your thoughts of dealing with it differently. I thought the idea of sending logs to stderr or stdout was interesting and worth contemplating.
James Fellows
@j4m3s
Sorry, I misunderstood. (almost) any of the logging frameworks will direct the log messages to stderr or stdout i think. i find it really useful to filter different logs into different files though.
Greg Bowler
@g105b
It got me having ideas though - using var_dump all over the place to automatically be picked up by the debug logger would be useful to me, but there is no point in introducing any new major logging implementation... worth a thought.
James Fellows
@j4m3s
You don't need var_dump though do you? The logger would print objects you passed to it. And if you do those var_dumps using logger::debug...
I'm not sure a "new major logging implementation" is much more than a few lines of code. And if you code to psr/log then you can switch implementations just by updating composer :smile:
Greg Bowler
@g105b
Aye. Thanks for your input.
I think the reason I took note of the idea was due to not having to teach programmers to use a logger - but I always go back to what Gordon said - don't implement something solely for helping stupid users. Harsh words, but still rings true.