The PHP Roundtable podcast, hosted by Sammy Powers has posted their latest episode: Episode #67: Imposter syndrome and the Dunning-Kruger effect . This time Sammy is joined by guests Ryan Welcher and Wendy MacIntyre.

In an industry like software engineering where it seems like there's always something else to learn, it's easy to come down with a case of imposter syndrome. We chat about imposter syndrome's impact on the PHP community and contrast it with the Dunning-Kruger effect.

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

The Three Devs and a Maybe podcast, hosted by Michael Budd, Fraser Hart, Lewis Cains and Edd Mann, has posted their latest episode - Episode #112: The Mafia Effect.

In this weeks second in-person episode, we start off by congratulating Fraser on his recent engagement. We then move on to chat about setting up Kong, rate-limiting APIs and monitoring the health of an application system. From here we discuss the final stages of Mick’s masters dissertation, highlighting the PageRank paper and the Matthew (not Mafia) effect. Finally, we mention Edd’s trip to Silicon Milkroundabout and blog posts that he has recently had the chance to publish.

Other topics mentioned include Kali Linux, the major DDoS on Dyn and the idea of convention over configuration. You can listen to this latest episode either through the in-page audio player or by downloading the mp3 directly. If you enjoy the show, be sure to subscribe to their feed and get the latest updates as new shows are released.

Przemek Sobstel has a recent post investigating an interesting theory in caching of any kind of application, not just PHP ones. He looks at the dogpile effect: when a cache expires and the database or host cannot catch up with so many non-cached requests coming in.

Implementing caching in web apps seems to be simple. You check if value is cached. If it is, you fetch cached value from cache and serve it. If it’s not, you generate new value and store in cache for future requests. Simple like that. However, what if value expires and then you get hundreds of requests? It cannot be served from cache anymore, so your databases are hit with numerous processes trying to re-generate the value. And the more requests databases receive, the slower and less responsive they get. Load spikes. Until eventually they likely go down.

He recommends using something called a "semaphore lock" to help prevent this kind of issue from happening. This lock prevents the removal of any stale content until after one process has finished refreshing the requested data. Only once the lock is released are the other processes allows to serve the fresh data. He includes some PHP pseudo-code that illustrates the point: trying to fetch the content, checking for the lock and releasing it when the single process is done with the refresh. He includes a link to a full implementation as well. He's also written up a full library, Metaphore, that integrates this into a full caching system.

In the wake of the announcement of the Heartbleed vulnerability in the widely used OpenSSL software, the PHPClasses blog has posted a look at how it relates to PHP applications and how you can see if your application is effected.

Just a few days ago it was publicly announced a serious security bug called Heartbleed that affects secure sites based on the OpenSSL library. Read this article to learn more about this security problem, how to test if your Web server or SSH server is vulnerable, how it may affect your PHP sites, what you should do to fix the problem.

They start with a look at the bug, what it is and why it's such a big problem. It talks about what kinds of applications are vulnerable (hint: it has nothing to do with the PHP) and how you can test to see if your server is secure. The rest of the post talks about how to resolve the issue and how it relates to OpenSSL connections to other servers and SSH.

Adam Culp has posted a three part series to his blog with some guidance about how to create "clean code" in your application development:

Whether we’re experienced developers or newcomers, we’ve all seen code that could/should have been done better. Many times it’s even code we ourselves wrote and revisited later for one reason or another. I, for one, have seen my share of code written by a “past me” and wondered what on earth I was thinking when I wrote that. Of course there has also been times when I was hired to fix another developers code, and it can be scary also.

There's three posts in the series:

• Part 1, Dirty Code (cause/effect)
• Part 2, Dirty Code (why we do it)
• Part 3, Dirty Code (how to spot/smell it)

Michael Wales has taken a look at what effect HipHop could have on your CodeIgniter application (or lack there of).

So, what does this mean for the CodeIgniter community? In short, absolutely nothing. Most CodeIgniter developers are building applications that will run on shared hosts, virtual private servers or a cloud-based virtualization system. Of that very large group of our community, an extremely small number have the capability to compile the HipHop binaries or alter their configuration in order to serve HipHop pages.

He points out that, for most developers and applications, time is better spent optimizing the actual application - things like reducing the I/O needs, caching, etc. HipHop, unless you have a very high demand and load on the application, won't give much of a gain. He gives the example of Facebook's load and how even it would only relatively recently would benefit from the tool.

Everyone that knows of the social news site Digg.com knows the problems that being linked on it can cause. Smaller servers get overloaded and pages can either be very slow loading or completely offline within minutes of being "digged". There's a few out there that have come up with different solutions, but several of them involve mirroring the content somewhere else. In this proposal, however, they combine the power of Lightttpd and PHP to handle the loads.

We host a wide variety of sites, covering everything from converting your garage into a living space to video game addictions. Because we are such a small operation, being hit by a link from a big site such as Digg would be both a blessing and a curse.

In order to place our ads on each page, we use PHP's auto_append_file feature to run our advertisement code. By using PHP's other neato function, auto_prepend_file, I can create a small piece of PHP code to detect when the site is being hit by Digg. In this situation, I have chosen to use Lighttpd to handle the increased loads, because of its proven high performance with large numbers of concurrent connections.

In his example code, he shows how you can detect when a user is coming from a digg.com page and take them to a cached version of the page they've requested (with the .cache extension).

Everyone that knows of the social news site Digg.com knows the problems that being linked on it can cause. Smaller servers get overloaded and pages can either be very slow loading or completely offline within minutes of being "digged". There's a few out there that have come up with different solutions, but several of them involve mirroring the content somewhere else. In this proposal, however, they combine the power of Lightttpd and PHP to handle the loads.

We host a wide variety of sites, covering everything from converting your garage into a living space to video game addictions. Because we are such a small operation, being hit by a link from a big site such as Digg would be both a blessing and a curse.

In order to place our ads on each page, we use PHP's auto_append_file feature to run our advertisement code. By using PHP's other neato function, auto_prepend_file, I can create a small piece of PHP code to detect when the site is being hit by Digg. In this situation, I have chosen to use Lighttpd to handle the increased loads, because of its proven high performance with large numbers of concurrent connections.

In his example code, he shows how you can detect when a user is coming from a digg.com page and take them to a cached version of the page they've requested (with the .cache extension).