The SitePoint PHP blog has posted a tutorial from Alex Bilbie that "re-introduces you to Jenkins", a popular build automation software, and how you can integrate it, and a new feature called "pipelines", into your processes.

As our applications become more complex – with Composer dependencies, Webpack build scripts, and per-environment variables – we inevitably reach a point where testing all of these different intricacies becomes slow and laborious, especially when you’re tearing down and rebuilding the entire environment for each test. Likewise, code style might deviate over time and creating a production ready deployment archive requires a specific set of steps to be followed.

He talks about some common tasks that might be involved in the build (installing Composer libs, running PHPUnit, etc) and how automating them can help prevent issues and make it less time consuming for your developers as they make changes. Along with the latest version of Jenkins (v2.0) they introduced the "pipelines plugin". Pipelines allow you to define multi-step configurations Jenkins then uses when the build is executed. He walks you through installing Jenkins, setting it up and creating your first job. They provide the example pipeline script to get you started. There's also a section talking about the Jenkinsfile and setting it up in the Jenkins job to automatically be used (instead of a config in-job).

He finishes the post looking at multibranch pipelines and some things "taking it further" by adding in other plugins, customized with their own section in the Jenkinsfile configuration.

In a recent post Pawel Turlejski takes a look at what he thinks is wrong with PHP closures as compared to syntax in a few other languages.

PHP 5.3, along with many other features, introduced closures. So now we can finally do all the cool stuff that Ruby / Groovy / Scala / any_modern_language guys can do, right? Well, we can, but we probably won't... Here's why.

He compares the PHP syntax for using closures/lambda functions with the abilities of Groovy and Scala. He does point out out that the ArrayObject wrapper does allow you to work a bit more fluently with the array's contents, but it's still not quite the same. According to him:

I’m sure closures will find their uses in the PHP world (like delayed execution or automated resource management), but IMHO replacing traditional loops and array operations is not one of them.

In a recent post Ant Phillips looks at another bridge that's offered to combine PHP with another language (besides the Java one) - a link over to Groovy.

Up until recently the PHP runtime was treating Groovy code just the same as Java. Anyone could compile a Groovy class to Java class files using the Groovy compiler. Those class files could then be dropped into a Zero application and used in PHP through the PHP/Java Bridge. The problem is that Groovy isn’t the same as Java.

He compares the way its works when its Java-esque and how it should work as combined with the Groovy bridge. The code is much cleaner and, by making it more readable, makes it easier to maintain in the future. You can see some slides from a presentation hes given on the subject here.

In a new post Michael Kimsal does a good job comparing the rise of PHP5 (and what it brought with it) to his language of choice these days - Groovy.

I remember when PHP5 first came out having 'discussions' with a number of people who insisted that PHP5 was way better than 4. [...] Basically, intentions were made clearer with things like "public protected private" (PPP),but I have not yet seen any web project get done faster or dare I say even much *better* due to those sorts of things. [...] This isn't specifically saying PPP is necessarily bad, but that PHP could have addressed the issue in a fashion more suitable to dynamic languages. Keep reading for an example.

His comparison is to how Groovy handles properties in a class - everything is private unless declared otherwise. This could be ported (somewhat) over to PHP and would eliminate the need to search&replace all over the code for the right variables.

Michael Kimsal points out the posting of the latest part of his "Grails for PHP developers" series to his blog site - Part Five of the series.

I've put up the latest installment in my "Grails for PHP developers". Rather than delve too much more in to Grails head on, I'm taking this installment (and at least the next one) to delve more in to the Groovy language itself. Groovy offers similarities to PHP, but also many differences which can trip you up if you're not careful. I'll try to lay those out as best I can in the next couple of installments.

This new part of the series goes back and puts the spotlight on GRoovy, the base of the Groovy/Grails combo. He talks about working with variables and arrays as containers for multiple pieces of data and some possible gotchas that could come up along the way.