In a post to his site Freek van Der Herten shares some functionality that Spatie uses to help keep the stale pull requests under control across their 180+ repositories: a Botman-based bot that assesses the last updated date and closes after a given amount of time.

At Spatie we have over 180 public repositories. Some of our packages have become quite popular. We're very grateful that many of our users open up issues and PRs to ask questions, notify us of problems and try to solve those problems, ...

Most of these issues and PRs are handled by our team. But sometimes those issues and PRs become stale. [...] That's why we created a bot that can automatically close stale issues and PRs. Here's [an example] of the bot in action.

He then shares the code they currently use for the bot, making use of the BotMan package as a base and the knp-labs/github-api package for the GitHub interaction. The code includes the GitHub service provider, a client class, an Issue object and the command that's run to find and close out the stale pull requests and issues.

On the SitePoint PHP blog there's a new post with an interesting question for PHP developers that might go against how they were tought to code from their early days - should you close your PHP tags at the end of your code?

Even those with a modest grasp of PHP know that code must be enclosed within special tags. [...] However, if your file contains just PHP - and no escaped HTML code - the closing ?> tag is entirely optional. Many developers argue that unnecessary code should be removed but there's another reason you could consider scrapping the closing tag.

Their rationale is that, in some situations, extra characters or other information could pop up after that closing PHP tag and cause problems in your code. If you drop the closing tag completely, there's no risk that this could happen and PHP parses it the same way.

There's lots of great comments with opinions both for and against.

Raphael Stolt has an interesting idea about PHPUnit plugin (GitHub_TicketListener) that allows you to close (or reopen) Github issues via PHPUnit tests.

Since PHPUnit 3.4.0 a new extension point for interacting with issue tracking systems [...]. The extension point has been introduced by an abstract PHPUnit_Extensions_TicketListener class, which allows developer to add tailor-made ticket listeners supporting their favoured TTS.

The "@ticket" notation that PHPUnit allows as an annotation is the key to linking together your unit tests with the new listener. Two methods, getTicketInfo and updateTicket, are used to have the listener make a cURL connection over to Github and send the request to a REST-like service on the remote side.

If you're a fan of the Git version control library and have been wanting to work with your Zend Framework applications in it, Matthew Weier O'Phinney's blog has a post you should read. He's worked up a method to clone the Zend Framework repository in a Git instance.

I've been using Git for around a year now. My interest in it originally was to act as a replacement for SVK, with which I'd had some bad experiences (when things go wrong with svk, they go very wrong).

He steps through the full process, providing a basic introduction to cloning in Git as well as how to define the correct settings in Git's config file to grab the latest version from the Zend Framework site.

According to this post on the PEAR blog, the first PEAR bug triage is now over:

PEAR’s bug tracker hit the 600+ open bugs mark a month ago. [...] So with 600+ open bugs (not including the feature requests), we had to do something. [...] The logical step was to hold our own bug smashing event and see how it works for PEAR.

Back on March 22nd and 23rd (Easter weekend) they hunted for bugs. Several developers showed to help out and many bugs were fixed and they managed to bring the number of open bugs for PEAR down to 547 with the two days of work. There were some milestones reached too:

Thanks to the triage, we are close to reaching two important milestones: Closing bug reports with lower bug ID than 1000 (1 bug left!) and 2000 (5 left).

John Walsh got to thinking about performance when it comes to the MySQL functions versus MySQLi in PHP - this quick post is the result:

I've decided that a little investigation in weather it can connect,query and close faster than the MYSQL function I prefer the MYSQLi version as the _connect function is a lot more organised with the DB select in it.

The code used for the benchmarks is simple - just a connect, query and close (no fetch). The results of running each 1500 times shows that, by a pretty narrow margin, the MySQL extension comes in around 92 milliseconds faster than MySQLi.

John Walsh got to thinking about performance when it comes to the MySQL functions versus MySQLi in PHP - this quick post is the result:

I've decided that a little investigation in weather it can connect,query and close faster than the MYSQL function I prefer the MYSQLi version as the _connect function is a lot more organised with the DB select in it.

The code used for the benchmarks is simple - just a connect, query and close (no fetch). The results of running each 1500 times shows that, by a pretty narrow margin, the MySQL extension comes in around 92 milliseconds faster than MySQLi.

After having some issues with spam comments over on his blog, Ryan Malesevich decided to do something about it. So, being the WordPress fan that he is, he implemented a new plugin to help things a bit - removing the ability to comment on a post older than 21 days.

I'm using a plugin called Auto-Close Comments. Whenever you write a post, edit a post, or anything similar to that, it will go through the database and close any comments for posts older than three weeks. I'm going to try it out for a while to see how my spam comments are altered.

You need to install it manually since there's no official packaged plugin for it, but it's a pretty simple matter of cut & paste to get it working. Then, you just define the number of days that you want the cutoff to be and you're all set.

After having some issues with spam comments over on his blog, Ryan Malesevich decided to do something about it. So, being the WordPress fan that he is, he implemented a new plugin to help things a bit - removing the ability to comment on a post older than 21 days.

I'm using a plugin called Auto-Close Comments. Whenever you write a post, edit a post, or anything similar to that, it will go through the database and close any comments for posts older than three weeks. I'm going to try it out for a while to see how my spam comments are altered.

You need to install it manually since there's no official packaged plugin for it, but it's a pretty simple matter of cut & paste to get it working. Then, you just define the number of days that you want the cutoff to be and you're all set.

If you work with streams in PHP, Dotvoid has a tip that just might come in handy some day in the future. The tip deals with the difference between HTTP 1.1 and 1.0.

I have a class that I wrote some time ago that is called URLImporter. It's simple, does what it is supposed to do and thus makes my life easier. Essentially it helps me fetch URL resources - mostly dynamically generated data from password protected extranets that require me to use HTTP POST.

Up until recently this class have only been used behind an http proxy. The other day I moved it to another machine - that is not behind a proxy and suddenly it stopped working.

He realized the problem after a bit of research - HTTP 1.1 automatically performs a "keep alive" on the connection, not timing out after the transaction's done like 1.0 does. His solution? Passing another HTTP header to the stream connection: "Connection: close".