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

That Podcast:
Episode 39: Public Relations (What's in a name?)
Mar 15, 2017 @ 12:27:27

That Podcast, hosted by PHP community members Beau Simensen and Dave Marshall, has posted their latest episode - Episode #39: Public Relations

Beau and Dave discuss skiing, skateboarding, Rebekah's book launch, Bullet Journaling, Rachel Nabor's Practical Cartooning for Technical Folk, Beau getting back into DJing, Dave dabbling in Bitcoin bot trading, Logan, and multiuser SaaS.

Other topics mentioned include this article on what it feels like to be an Open Source maintainer and some thoughts about multi-user logins from Jonty Behr. You can listen to this latest episode either using the in-page audio player or by downloading it directly. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter for updates when new shows are released.

tagged: thatpodcast ep39 public relations podcast beausimensen davemarshall

Link: https://thatpodcast.io/episodes/episode-39-public-relations

Codeception Blog:
Writing Better Tests: Expectation vs Implementation
Dec 27, 2016 @ 10:49:42

The Codeception blog has recent post they've written up talking about writing better tests for your application and the difference between expectation and implementation as it relates back to meaningful tests.

What makes a meaningful test? This question should always be asked. No matter we write your tests first or tests after, they may stay in a project for years and it is pretty important them to test the things that really matters. Badly written tests can slow us down by constantly failing on each implementation change, and such tests can be written no matter you follow TDD or not. The idea of a test is to ensure that software works and not to freeze it at specific point.

Such situation happens when a test is bound to implementation details. [...] But how to understand what is stable and what is not? We need to use interfaces. Not that one which is written as interface keyword in PHP but a general term: User Interface, API. And that’s what makes unit testing and browser testing similar: we always need to rely on public interfaces for a test.

They give an example of a test that's "bound to implementation details" from the Magento codebase that relies on a specific function implementation (the "makdir" method). This function is a part of the Symfony functionality, not Magento, and what might happen if things change in your application. They note that the main difference is testing for the result versus testing for the behavior of the functionality. The tutorial wraps up by suggesting that the only testing that should be done is on public, well-defined interfaces that are not as subject to change and not copying logic into tests.

tagged: codeception testing tutorial expectation versus implementation interface public

Link: http://codeception.com/12-21-2016/writing-better-tests-expectation-vs-implementation.html

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