The php[architect] podcast, hosted by PHP community members Eric van Johnson and John Congdon, has posted their latest episode: Episode #12 - Whole lot of Xdebug

Our twelfth episode is in the can, thanks to Eric van Johnson and John Congdon. Eric and John discuss freelancing and how it changed John’s life, regular expressions, PhpStorm, and how the PHP community gets together. [Their guest] Oscar talks about trying to use Xdebug regularly and the value of debugging tools in general [and there's an] interview with Mark Niebergall on his Xdebug article, his day to day work, and working remotely.

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 to get updates when new shows are released.

The PHP Roundtable podcast, hosted by Sammy Powers, has posted its latest episode. In this new show he's joined by Keith Casey, Tim Lytle and Mike McDerment to talk about hourly versus value based pricing when charging for freelance development work.

There are two seemingly contradicting philosophies about how to charge clients for programming work. The hourly camp suggests that the client is paying for your skill and hiring you for your time. The value-based pricing camp suggests that the programmer should price a project based on its value to the client instead of the hours it will take to build it. Today we chat about these two ideas and discuss the pros and cons of both.

You can catch this latest episode either using the in-page audio or video player or by watching the live recording directly over on YouTube. If you enjoy the show and want to see more like it, be sure to subscribe to their feed and follow them on Twitter for information about the most recent and upcoming shows (and live recordings).

The PHPUgly podcast has posted their latest episode as recorded on August 18th, 2016 - Episode #24. Join hosts Eric Van Johnson and Tom Rideout as they talk about:

• The TV show "Mr Robot"
• the SDPHP and SDLUG Meetups
• the "FIG Follies" articles
• the idea of "Being asked to work for free"

You can listen to this latest episode either using the in-page audio player or over on SoundCloud. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter for updates on when the latest shows are released.

That Podcast, hosted by PHP community members Beau Simensen and Dave Marshall, has posted its latest episode - Episode #38: [Work, Work, Work].

Beau and Dave talk about some of their recent work efforts, Dave's first look at DynamoDB, other AWS services, migrating event streams, email integration with Context.io and the challenges of maintaining privacy with such systems.

Amazon Web Services topics include DynamoDB, SES and Lambda. Also mentioned are Monii and Context.io. You can listen to this latest episode either through the in-page audio player or by downloading the mp3. If you enjoy the show be sure to also subscribe to their feed and get information on the latest shows as they're released.

In a new post to his site Andi Gutmans talks about how the "web is about to get 2x faster" with the first stable release of PHP 7, the latest major version of the PHP language.

Today the Web is about to get twice as fast. PHP, the most popular Web development language, which runs by some estimates 80% of the Web sites, is getting a big step-up in speed.

Underlying this exciting news there is heroism. [...] This is what I call the fun part of being a hero. It is quick. Energizing. We’re stressed but our survival instincts kick into gear. [...] With today’s release of PHP 7, PHP-based Web sites will be running twice as fast without needing to make any changes to the underlying software code. This is an amazing accomplishment! [...] But this is not a story of technology but rather of true heroism. A story of persistence. A lot of sweat. Many disappointments and frustration.

He starts back when PHP was just in its infancy and talks briefly about the amount of work (in 2012) put into a major rework to improve PHP's performance only to end up with not much difference. Instead of giving up on the goal, the "heroism" idea kicked in and work was done to make the real improvements PHP needed to get the performance they wanted. The end result of hard work (and much discussion) was the PHP 7 we have today, improving performance dramatically.

Luciano Mammino has posted six tips for blazing fast web applications to his site. These tips aren't as much specific to the code (though they're related) as they are general good practices around architecture, development work and common issues.

In this post I will try to highlight some of the most common principles that you have to take under consideration when you want to achieve a great level of performance while building a web application (specifically on the backend part). I believe the concepts discussed here can be applied to any language and framework even if, due to my specific experience, I will mention some examples, design patterns, conventions and tools that are mostly used in the PHP world.

His post lists out six main rules along with some description and links to other tools for each:

• Avoid premature optimization
• Do the minimum amount of work to solve the problem
• Defer the work you don't need to do immediately
• Use cache when you can
• Understand and avoid the N+1 query problem with relational databases
• Prepare your app for horizontal scalability when possible

There's lots of good tools mentioned here so find one that fits your needs and helps solve the issue. There's also some good articles mentioned, giving more information about a particular topic or other perspectives on how to solve it a different way.

The Three Devs & A Maybe podcast has released their latest episode today, Episode #68 - Podcasting, Remote Working and Testing with Adam Wathan.

This week we are very lucky to be joined by fellow podcaster and host of Full Stack Radio - Adam Wathan. We begin discussion with his reasons behind starting a podcast, experience being a solo-host and the secret to great podcast recordings. We then move on to how he got into programming at high school - with reflection on that if he had been using a Windows machine at college, he would most likely be a .NET developer by now. As both Edd and Adam work remotely at this time, the topic of remote pair-programming and Kanban style board implementations then arises. Finally, we discuss his thoughts on Message-passing vs. strict-contracts, Smalltalk and Elixir exploration and how it is hard to give a definitive answer on the best way to begin learning TDD.

You can listen to this latest episode either through the in-page audio player or by downloading the mp3. Be sure to subscribe to their feed if you enjoy the show too!

The Loosely Coupled podcast has posted their latest episode today - Episode #19, How We Work. Join hosts Jeff Carouth and Matt Frost as they talk about work life, personal life and what tools, processes and techniques they've used during their careers to get the job done.

In this episode Jeff and Matt explore how they go about organizing their work life and our personal lives. They cover the idea of how the process evolves depending on your environment and even your personal inclinations. In 2011, Jeff wrote a blog post about the tools he used back then and realized that it has changed a little but for the most part works for him. They cover some pitfalls of processes that require tickets/stories to be broken down into parts where developers cannot understand what they’re doing or why, and how they’ve learned over time to get to that information. They also talked about learning how to be professionals and defend against situations that would impact your work or your code in negative ways. Finally they touch on Matt’s work scheduling experiment which is inspired by the Makers Schedule versus the Managers Schedule and how it has helped him be more productive.

You can listen to this latest episode either by using the in-page audio player or by downloading the episode directly and listening at your leisure. Be sure to subscribe to their feed or follow them on Twitter for the latest updates and show announcements.

There's an interesting discussion happening in the /r/php subreddit on Reddit.com that asks about taking a job if a custom framework was involved.

i recently got a new job and whilst I'm working my notice period I've been tasked to find my replacement. One of the big questions my boss has is whether a developer would mind taking over a MVC framework I built specifically for the company. (I would explain why we didn't use Laravel / Symfony / Zend etc. but that's a whole post in itself). The framework is conventional and should feel familiar to someone with Laravel experience... But at the end of the day it's totally proprietary. It's built to PHP-FIG standards and would come with full documentation. So, would you have any issues taking the job, or would you be put off?

There's opinions shared that lean both ways, but there seems to be a large majority that strays more heavily into the "no" column. They suggest that, with all of the great and well-developed PHP frameworks already out there, a custom one would probably cause more problems that it solves. While there's plenty of technically oriented comments, there's also a few that are more "high level" looking at the reasoning for taking the job (hint: it's not just about technology) and what the needs/requirements of the business are.

The SitePoint Web blog has a recent post from Matthew Setter offering some helpful hints on working with other people's code. In it he shares suggestions ranging from the technical out to a bit more "learning oriented" to get up to speed on concepts and techniques.

Dealing with code created by other people is a fundamental skill for a developer. Give it a year and other people’s code could even be your own. Today I’m going to look at some of the best approaches for how to deal with other people’s code, read legacy code, effectively. It’s not an easy topic to cover.

He's broken it down into a list of several different topics, each with their own descriptions and links to tools or reading resources for more information:

• Interact
• Observe
• Run Tests
• Fix Bugs designed for Newcomers
• Find Available Resources
• Use a Good IDE
• Read Books & Blogs
• Contribute to Documentation
• Be Considerate

He puts some good emphasis on that final point, reminding the reader that it's not just years of experience that make for a better developer, it's more about skill.