Unit tests are a crucial part of the software development process. When used well they give you the confidence and sense of security needed to make changes without introducing bugs or regressions. When used badly they become a hindrance, slowing down development and encouraging bad practice. One common mistake is to write unit tests which reach too far and introduce fragility to your test suite.
The documentation surrounding AWS Aurora reserved instances is a little confusing. One of its main selling points is seamless Multi-AZ replication at the storage level; however, when you purchase reserved instances the Multi-AZ option is fixed at "No". Does this mean you can't run read replicas in another AZ if you're using reserved instances? Will you be charged the on-demand rate for your read replicas?
In order to combat spam and fraudulent email it's become common practice to deploy technologies such as SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to provide a means for receivers to verify whether a message is from who it claims to be. Unfortunately, these are not foolproof and can still allow fraudulent messages to slip through. There's also no way of knowing what a receiver will do with messages that fail these checks and no way of knowing how effective they are. DMARC (Domain-based Message Authentication, Reporting and Conformance) goes some way towards improving this.
If you're working on or debugging a PHP application that creates files in the /tmp directory then you may find yourself needing to check for the existence of or the content of these files. On RHEL/CentOS 6 and below this would be as straightforward as listing the contents of /tmp or opening the file in your preferred text editor. On RHEL/CentOS 7 however you may be surprised to see that while your application can see its files fine, you can't.
As Google have publicly stated that a site's usage of SSL will now start to play a part in the ranking of its pages in search results (and presumably other search engines will follow suit) I decided it was time to switch this site to SSL. With online privacy an even bigger concern than ever there's no reason not to use cryptography where possible. I'm posting the steps I took here as a guide for anyone else thinking of making the same move in the hope that someone might find it useful.