On the Tighten.co blog there's a tutorial posted from Jake Bathman for the Laravel users out there covering the APP_KEY value - what it is and how its used in your application.

A recent Laravel security update fixed an issue with how APP_KEY is used. For someone to exploit this issue, they'd need to have access to the production APP_KEY. The simplest fix for the exploit is to rotate (change) your APP_KEY. That led some of us at Tighten to ask the question: What does the app key do? What is involved in rotating it? What are best practices for managing these keys for our Laravel applications?

In this post, we'll talk about what APP_KEY does and doesn't do, some common misconceptions about its relationship to user password hashing, and the simple steps to changing your APP_KEY safely without losing access to your data.

Before diving in too deep, he reminds the reader about a security release Laravel recently made to correct an issue with APP_KEY handling (and the recommendation to rotate it). It then moves on to talk about what the setting is, how to generate a new one and its use in cookies. It also tries to dispel myths around:

• its use for password hashing (it's not)
• where it is used for encryption
• rotating the key
• multi-server use

It also makes a recommendation of the process to use for currently encrypted data that was created using the previous APP_KEY value and how to re-encrypt.

On his site Ross Tuck has a post that covers a common design pattern, the Command Bus, how it relates to CQRS and that they shouldn't return anything. In the post he takes some of the most common questions about using a command bus and tries to clarify with the correct answer.

The most common question I get about my command bus library is: “can commands really return nothing?” The second most common question is “Why do you let commands return something, don’t you know that’s Wrong(tm)?”

It’s easy to get hung up on form, not function. That’s a shame because command buses aren’t important. In the grand scheme of things, they’re completely, utterly, totally unimportant. It’s all about where the messages are going, not how they get there.

Still, let’s take a look at some myths about command buses.

The questions he tackles include topics like the relationship between CQRS and command buses, if you should be using them together (dependencies) and some discussion about return values and the "right" way to do things.

Amine Matmati has written up a post with a few quick points refuting the "bloated framwork" myth as it relates to the Symfony framework.

At work, we’re trying to choose which PHP framework to use for our next project. As we’re breaking up our monolithic app into services, only micro frameworks were considered by the team. This choice was made to avoid the pain points we’ve encountered using our current full stack framework.

Not all full stack frameworks are created equal, however. Having worked with Symfony before, I proposed it as an option. As expected, I’ve had some pushback from my fellow coworkers. The main reason being that Symfony is bloated and overkill for our needs.

He then goes on to talk about how, despite many Symfony components being used individually by other projects, the overall framework still has the reputation for bloat. He goes through some of the main points usually mentioned by the opponents:

• Doctrine is complex/bad/slow
• Symfony is too verbose
• Symfony uses too much configuration

He does agree with some of the points made but usually not in the general way they've been stated. For example, while he does agree that Symfony is verbose he also points out that this verbosity provides more control to the developer as to exactly how things hook together.

The Inviqa blog has posted an article that seeks to debunk some common testing myths when it comes to ensuring quality in software development (and its results). They cover eleven different points with a rebuttal for each, refuting them as excuses and possible misunderstandings.

Software testing has been around for many years now but over this time some incorrect assumptions have arisen about what testing is, what the process involves and how the process of testing can add value to the software development process. Here we take a look at some of the more common myths about testing and, from a tester’s point of view, provide correct and valid information for each point.

Among the myths they cover are things like:

• "Bugs come from lazy developers"
• "If we test it for long enough, we’ll catch all of the bugs"
• "Developers and testers are like cat and dog"
• "Testing is boring"
• "We don’t need testers"

Each includes a paragraph or two of content pointing out the problems with the statement and offering some constructive ways to help solve it in your organization.

The 7PHP.com site has announced a giveaway of free tickets to this month's Nomad PHP virtual user group meeting, the European chapter. The topic for this month's EU meeting is authorization and authentication (disclaimer: I am the speaker).

Here I am again for another NomadPHP Ticket(s) give-away. Two tickets will be given away – to the 1st & 2nd draw winner! If you did not know, NomadPHP is virtual PHP User Group mainly for people who do not have the chance to avail of a local PHP user group. But it is open to ANYONE around the world. I also remind you that NomadPHP is an initiative brought forward by the icon of The PHP Community, namely ‘His Awesomeness’ Mr Cal Evans.

To enter the contest to win the tickets, you just make a comment on the post and he'll select the winners before the event. The meeting is Thursday, October 17th at 8pm CEST.

Igor Wiedler has shared some of his thoughts on his site today about the "heaviness" of things that call themselves "microframeworks" and why it may not be about the amount of code involved at all.

Quite often silex has been described as heavy or bloated. It's time to put this myth to rest. [...] Micro-framework What an excellent buzzword! Let's face it, this is an overloaded and mostly nebulous term. I don't think it's possible to clearly define what it means. [...] But the real answer lies in what silex doesn't do.

He suggests that the "micro" in "microframework" is more about it providing a limited amount of features (bare-bones) versus a more full-featured, possibly full stack framework. He talks about the dependencies that Silex currently has and provides some statistics about it and these packages it depends on. He also briefly mentions the minimal interface the framework provides, citing the few components you'll probably touch in your work with it.

SitePoint.com has a new article sharing three of the things they see as common myths around learning new programming languages.

Are you yet to learn your first programming language? Why is it that you’re putting it off? If you think it’s going to be too hard, like learning a real, spoken language – you are wrong. In fact, you’ve fallen victim to what I like to call The Big Programming Language Fallacy - the mistaken belief that programming languages are analogous to real languages.

They go through each of their myths and explain what's wrong about them, each building on the previous ones in the list:

• Myth 1: Programming Languages are the ‘Languages of Computers’
• Myth 2: Programming Languages are Foreign and Hard to Read
• Myth 3: Programming Languages Take Years to Learn

They point out that, in the case of most programming languages these days, they've been designed to be "readable" and something that can relate to basic terms (a subset of a completely new language).

In this new post to his blog Larry Garfield tries to dispel a common misconception in the PHP development world - that the readfile function should be considered harmful and can cause memory issues in your code.

If you're like me, you've probably read a dozen or two articles about PHP performance in your career. Many of them are quite good, but some are simply flat out wrong, or misinformed. One of the old truisms that has been repeated for as long as I can recall is "don't use readfile() if you have big files, because it reads the whole file into memory and your server will explode." [...] There's just one problem with that age-old truism: It's not true.

He created some benchmarks to illustrate the differences between several of the common methods for working with files via the fread, fpassthru, stream_copy_to_stream and of course readfile. He reports the results based on the runtime and the peak memory usage and noted, ironically, that while the times varied slightly, the memory consumption was exactly the same for all of the approaches. Since there's no real reason not to use "readfile", he looks at three reasons why there might be this stigma attached to it (including the issues that could come up with output buffering enabled).

In this new post to his blog Nikita Popov aims to dispel the popular micro-optimization myth of using single quotes over double quotes for a performance boost.

If there is one PHP related thing that I really hate, then it is definitely the Single Quotes Performance Myth. [...] Let's do a random Google search for "PHP single quotes performance": You will get many results telling you that single quotes are faster than double quotes and that string interpolation is much slower than string concatenation. Most of them advise to use single quotes and concatenation to improve the performance of your application. Let's be clear here: This is pointless.

He did some benchmarking of his own to see how the myth would hold up and, as it turns out, it doesn't - "There is none". His proof compares two strings, one normal single-quoted and the other a double-quoted, and the opcodes they generate. They end up exactly the same. Since it's the opcodes that matter, he recommends using something like APC if you're really worried about the performance. He also includes an example using the token_get_all function of PHP to see how fast the strings run through the lexer too (again, almost no difference).

As an added bonus, he also throws in a bit about string concatenation versus string interpolation with some benchmarking scripts and results of their own.

In an effort to dispel some of the rumors and myths around the CakePHP framework (as presented most recently by a different blogger) Chris Hartjes has made a new "mythbuster" post to his blog today with a rebuttal to the points from the other article.

I ran across an article comparing CakePHP and Symfony and found that the writer had a number of preconceived ideas about CakePHP. These same ideas keep popping up everywhere, used by people looking to get their hate on about CakePHP. I sent a very well-reasoned email to the writer clearing up some of those misconceptions [...] So, in the interest of clarifying things about CakePHP I thought I would share that email, slightly rewritten for this blog posting, but the content is roughly the same.

The post/email covers a few different topics some might have misconceptions about concerning the framework:

• Lack of Documentation
• Scaffolding
• Models are tied to controllers in a 1:1 relationship
• Cake's Ajax and Javascript helpers do not support graceful degradation
• Cake's HTML and Form helpers produces bad markup
• Unit tests are an afterthought
• CakePHP is not an "enterprise capable framework"