Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Cal Evans:
Q&A on Public Speaking with Jessica Rose
Jul 14, 2016 @ 09:10:45

PHP community member Cal Evans recently talked with Jessica Rose, a well-known speaker at technology conferences all about public speaking and some of her own thoughts and advice to potential speakers.

This week my guest is Jessica Rose. Jessica speaks at developers events all over Europe and the US.

She took time out from her busy schedule to join me to answer questions on public speaking. We talk abut her first talk, preparing for talks, speaking to audiences whose first language is not English, and so much more.

Their conversation was recorded as a live Google Hangout and can be viewed either through the in-page video player or by heading over to YouTube.

tagged: qa public speaking jessicarose video interview youtube hangouts

Link: https://blog.calevans.com/2016/07/13/qa-public-speaking-jessica-rose/

Cal Evans:
Public Speaking: A Conference Organizer’s Perspective
Jul 04, 2016 @ 10:55:25

For those interested in how things work "behind the scenes" at technology conferences and how it looks from an organizer's perspective, Cal Evans has put together a video to share his own experiences.

My good friend Adam (@adamculp) and I spent a few minutes answering questions about how talks are selected in a [Call for Papers]. If you’ve ever wondered, about the process, give it a listen.

The recording was of a live Google Hangouts session they did a while back answering both some of the common questions people have and questions from their viewers. They talk about the Call for Papers process, how they've selected talks in the past and the role that passion plays. There's also discussion about speaker experience, diversity and how to find out the interest level of you topic. There's plenty more mentioned in the video as well, so if you're considering submitting to a technology conference be sure to give it a listen (well, watch...it is a video after all).

tagged: public speaking conference organizer perspective calevans adamculp video qa

Link: https://blog.calevans.com/2016/06/29/public-speaking-conf-organizers-perspective/

Evert Pot:
Drop 'public' not 'var'!
Mar 28, 2016 @ 12:23:32

In a recent RFC that's been proposed and is now up for voting, the suggestion has been made to drop the var keyword in PHP 7.1 and completely remove it in PHP 8 (made a bit redundant buy the public keyword in classes). Evert Pot, however, disagrees and suggests dropping public instead.

A PHP RFC vote has started to deprecate the var keyword in PHP 7.1 and remove it in PHP 8. At the time of writing, there 23 who say it should be removed, and 18 who say it should not. [...] I’d like to offer a different opinion: I think people should be using var instead of public. I realize that this is as controversial as tabs vs. spaces (as in: it doesn’t really matter but conjures heated discussions), but hear me out!

He goes through an example on one of his own projects, showing how he's mostly removed the public level of exposure from his development (using final and statics instead). He then suggests three common thoughts he sees people having being in favor of dropping var versus public:

  • #1: Everyone doing the same thing is good
  • #2: It’s ugly!
  • #3: The public keyword is useful to convey intent

He also points to one place where he does see the need for a public but also suggests that in that case var would do juts fine too.

tagged: public var class exposure level rfc proposal voting

Link: https://evertpot.com/drop-public-not-var/

Davey Shafik:
The Visibility Debate
Feb 16, 2016 @ 10:43:04

Davey Shafik has a post to his site with some of his thoughts about the "visibility debate" - essentially when the different method/property visibility types make the most sense.

A lot has been said about when to use public/private/protected. Some say that you should never use private, while others say you should never use protected.

About the only thing that people can seem to agree on is that public should be used with caution. That your versioning should be based around your public API, and you have a responsibility to maintain that API. The issue is mainly around the maintenance responsibility of protected vs private. Given that other developers can depend upon protected, it can effectively be considered to have the same overhead as your public API.

He shares some of his own reasoning behind how he uses the different levels in his own code. He touches on each of the different levels, sharing when and how he thinks it should be used to keep a well-structured, consistent API for your library or application.

tagged: visibility opinion public private protected api structure consistency

Link: https://daveyshafik.com/archives/69929-the-visibility-debate.html

PHPUnit 4.8: Code Coverage Support
Aug 10, 2015 @ 08:48:52

Sebastian Bergmann has posted about some updates in the latest version of the PHPUnit PHP unit testing tool (v4.8) and changes in code coverage handling.

PHPUnit 4.8 introduces a couple of small improvements. For instance, the @testWith annotation was added as "syntactic sugar" for defining data providers and the --no-coverage commandline option was added for ignoring any code coverage configuration from the configuration file.

PHP_CodeCoverage, the library used by PHPUnit to collect, process, and report code coverage information, has been updated for PHPUnit 4.8. It can now collect code coverage information on PHP 7 without the need for a third-party extension such as Xdebug. And PHP_CodeCoverage's HHVM driver has been updated to reflect changes to how HHVM provides code coverage information.

He gets into a bit more detail about the updates to both the PHP 7 handling and changes for HHVM, including how to call it for PHP 7 (phpdbg vs just the normal CLI) and how HHVM no exposes its coverage information publicly. This makes it simpler for PHPUnit to grab the data without special handling code. He also looks ahead to PHPUnit 5, scheduled for release in October 2015, and that some functionality will be deprecated when the version is changed.

tagged: phpunit codecoverage support php7 hhvm changes phpdbg public

Link: https://thephp.cc/news/2015/08/phpunit-4-8-code-coverage-support

Laravel Podcast:
Episode 31: Public Speaking Preppers
Jul 29, 2015 @ 10:17:41

The Laravel Podcast, hosted by Matt Stauffer with guests Jeffrey Way and Taylor Otwell, has posted their latest episode - Episode #31: Public Speaking Preppers.

In this episode, the crew discusses preparing for conference talks, vacationing, and dreamy destinations!

You can listen to this latest post either through the in-page audio player or by downloading the mp3 directly. Be sure to subscribe to their feed or follow them on twitter for more information about the latest episodes as they're released.

tagged: public speaking preparation laravel podcast ep31

Link: http://www.laravelpodcast.com/episodes/14331-episode-31-public-speaking-preppers

Paul Jones:
Semantic Versioning and Public Interfaces
Jun 03, 2015 @ 09:16:33

Paul Jones has an interesting post to his site that makes the link between software versioning and public interfaces your code provides. He points out that, despite semantic versioning helping to define how to version your code, there's still some ambiguity about it and backwards compatibility.

Adherence to Semantic Versioning is just The Right Thing To Do, but it turns out you have to be extra-careful when modifying public interfaces to maintain backwards compatibility. This is obvious on reflection, but I never thought about it beforehand. Thanks to Hari KT for pointing it out. Why do you have to be extra-careful with interfaces and SemVer? [...] If we remove a public method, that’s clearly a BC break. If we add a non-optional parameter to an existing public method, that’s also clearly a BC break. [...] However, if we add a new public method to the concrete class, that is not a BC break. Likewise, changing the signature of an existing method to add an optional parameter is not a BC break either. [...] But what happens with an interface?

He suggests that changing current functionality (such as adding a non-optional parameter) is a backwards compatibility break but in an interface so is adding a new method. By adding a method you "break" the implementation someone already has, causing plenty of trouble for the users. He wonders about the right approach for making these updates, if it's creating a new interface or just extending the current one and having users migrate. He also includes a few update notes about abstract classes and how Symfony handles BC breaks too.

tagged: versioning public interface backwardscompatibility break bc abstract symfony

Link: http://paul-m-jones.com/archives/6136

Protecting Your Keys From GitHub
Mar 05, 2015 @ 12:03:05

On the NetTuts.com site there's a new post talking about protecting your keys when using a public site like GitHub. This relates to an easy thing to forget - removing hard-coded credentials from code before pushing it public.

In December 2014, Slashdot ran an alarming story Bots Scanning GitHub To Steal Amazon EC2 Keys, based on developer and blogger Andrew Hoffman's experience trying out Ruby on Rails on Amazon with AWS S3. He inadvertently committed an application.yml file with his AWS keys. [...] It's an easy mistake and most of us have probably done a similar thing at one point or another. And it's not just AWS keys that are at risk. As our use of cloud-based services increases, the expanding use of a broad variety of service API keys can be leveraged by hackers and spammers alike.

He goes through a solution he's found to help protect those credentials, in this case working with the configuration of a Yii framework-based application. He starts with a mention of .gitignore but points out that it could have unexpected results from "quirks" in its handling. He suggests a different option - using a configuration file that lives someplace outside of the main git directory and can be referenced directly from inside the application. He provides two kinds of examples: one using a PHP-based configuration and another based on an INI file. He finishes the post with a mention about WordPress plugins and the fact that they're (usually) stored in a database and open to exposure if a SQL injection vulnerability is found.

tagged: github protect keys commit public exposure configuration file gitignore

Link: http://code.tutsplus.com/tutorials/protecting-your-keys-from-github--cms-23002

Matthew Setter:
The Path To The First PHP Conference Talk
Feb 24, 2015 @ 12:08:10

Matthew Setter was encouraged by some recent conversations and conference sessions about getting out into the PHP community and taking up presenting at conferences. In his latest post he talks about some of these conversations and his ideas moving forward.

[The PHP UK Conference 2015] was an especially meaningful conference for me, as the opening keynote, by @coderabbi, moved me to take more action, more serious, dedicated, and focused action than I’ve taken to date. [...] I sat there thinking “WOW, I’m really a part of the community“. I also started thinking I want to contribute more, and build a profile just as big as his, and many of the others at the conference. So what to do?

He talks about the encouragement from others he's gotten to get up and present at a conference and the feedback he's gotten on his (unfortunately so far) rejected submissions. He's renewing his effort, though and has plans to document his progress via a "pseudo-journal" during his journey to hopefully serve as a guide to others wanting to share their knowledge with the community. He talks some about his plan moving forward and the work he's doing on the public speaking side to improve his skills.

While not for everyone, speaking at conferences is a great way to share experience, information and start conversations about new technology. If you've ever thought about making the move, follow Matthew's journey or check out these other articles to help you get started.

tagged: first conference talk public speaking phpuk15 community

Link: http://www.matthewsetter.com/path-first-php-conference-talk/

Fabien Potencier:
The PHP Security Advisories Database
Oct 27, 2014 @ 11:54:48

Fabien Pontencier has made an official announcement about a move to make the PHP Security Database the Symfony project started over a year ago. In the announcement he talks about the move to (hopefully) make it more widely adopted - pulling it out from under the Symfony namespace and into the FriendsOfPHP organization.

A year and a half ago, I was very proud to announce a new initiative to create a database of known security vulnerabilities for projects using Composer. It has been a great success so far; many people extended the database with their own advisories. As of today, we have vulnerabilities for Doctrine, DomPdf, Laravel, SabreDav, Swiftmailer, Twig, Yii, Zend Framework, and of course Symfony (we also have entries for some Symfony bundles like UserBundle, RestBundle, and JsTranslationBundle.)

[...] Today, I've decided to get one step further and to clarify my intent with this database: I don't want the database to be controlled by me or SensioLabs, I want to help people find libraries they must upgrade now. That's the reason why I've added a LICENSE for the database, which is now into the public domain.

The database has already been moved over to the FriendsOfSymfony organization and is still functioning with the SensioLabs security checker. You can find more on the database and its contents in this GitHub project.

tagged: security advisories database public domain friendsofphp

Link: http://fabien.potencier.org/article/74/the-php-security-advisories-database