When preparing for a big event, it is our job to make sure the general public sees exactly what is expected, and with the help of Amazon Web Service (AWS) we did! All planning comes with a few standard issue assessments/steps: Identify need, identify options, and begin to build!
Entering the pond
What is #attached
First off, Drupal has had a great year and a great quarter. According to builtwith.com Drupal is second among all Content Management Systems at 13.75% of the top 10K websites and has added ~250K new website this quarter. That said, the number one CMS (WordPress) is at 42% of the market and according to the same source has added 5MM (yes, 5 million) websites this quarter. Here's the graph:
I've been doing a lot more Behat testing recently. As my tests have gotten more complex, I've discovered that it was only a matter of "luck" that my earlier tests were properly cleaning up after themselves. What I mean, is that during my tests I fill out and submit a node form, checking that I successfully created it and that the appropriate users can see it. After each scenario you want to clean up any data that was created so you can run the test again and get the same result.
If you are using New Relic for performance monitoring a Drupal project, you may have noticed a large discrepency between the browser throughput and app server throughput. In the example that follows, the difference is 100:1. The cause is a limitation in the auto-instrument feature:
"[notice] child pid 45617 exit signal Segmentation fault (11)":
This is usually the start of a very bad day. Since a segfault is a low-level error in native machine code (in this case the PHP interpreter), many typical debugging techniques don't apply. Today I decided to try something new: