By 
PHP is great, but its loosely-typed goodness is a double-edged sword. On the one hand, it gives PHP the legendary low barrier to entry, but on the other, magical type juggling inevitably means bugs.
Because PHP is an interpreted rather than compiled language, catching these type problems is tricky, and often they'll go unnoticed for a long time before they catch up with us somewhere down the road. Problems sit and fester in our code base waiting to strike. Unused code can clutter our application, and there is a myriad of other ways in which we write PHP that won't produce errors but are bugs.
There are some excellent tools to help us catch errors and find bugs before we even run our code. IDEs like PhpStorm can inspect our code and give us information on potential problems before a script is ever executed.
Catching problems with our code before …
Laravel 6.0 is released, and as a new major version, there are plenty of fun new features for us to play with. The release notes give us all the highlights, but as part of a recent stream, I decided to take a look at one of the more exciting additions, the new error handler, Ignition.
Ignition
Ignition replaces Whoops as the default error handler in Laravel 6, but it works on older Laravel applications going back to version 5.5. The impressive thing about Ignition is because it's designed from the ground up to handle Laravel's specific errors, it can make suggestions on how to resolve errors, and even automatically fix common problems for us.
If we deliberately add a typo in our blade template name, then Ignition realises this and suggests the fix for us in the green panel.
Even smarter is the fact that Ignition can automatically …
Every new starter at Twilio has to build an application using one of our products, then demo it to receive their fabled Track Jacket. For my application, because WiFi is always a pain at conferences, I wrote a PHP script that sends you the next talks for a given event.
Writing this so it worked locally was relatively straightforward with PHP’s inbuilt web server and ngrok, but when I got up to demo this in front of my peers, I didn’t want to be relying on my laptop to be open, awake and responding to the proxied HTTP requests. This code needs to be sitting somewhere on the internet so that it can respond to messages any time of the day or night, and not just when my laptop was open and connected to the wifi.
Serverless functions are great for this; they allow you to run code on …
As I'm sitting here in Twilio's San Francisco office thinking about what to write for my introductory blog post, it's hard not to be introspective. It's a long way from Swansea, a small city in South Wales in the UK, to San Francisco. Both physically and figuratively. Physically it's a 3 hours drive, an 11-hour flight, 20-minute taxi, and an 8 hour time difference. But in reality, it's taken the help of several amazing people and an entire dev community to get me here.
I'm pretty old in terms of an internet developer. I started my dev career back when people were worried about planes falling out of the sky when the year 1999 rolled over to 2000. I started work coding in ASP connecting to a massive Oracle database; showing metrics over the intranet was cheaper than buying licenses for bespoke process control software at the local steelworks. Yes, …