Slim is an excellent PHP micro-framework. Out of the box it gives you compatibility with PHP standards (PSRs), PSR-11 for the container, PSR-7 for HTTP messages and PSR-15 for middleware. Its lightweight design gives you the bare minimum to get started with your web application; routing, a middleware dispatcher, error handling and a container. You need to wire up the additional services needed to handle requests and return responses.

But where do we start? Let's take a look at installing a clean installation of Slim from a community skeleton, and add our first component to it; the Twig templating engine.

Starting with Slim

Slim provides a skeleton application that lets you get started quickly, but it's designed more with an API in mind than a web application. I prefer to start with a more lightweight skeleton from Slim maintainer Rob Allen. Rob’s starter comes with PHP-DI dependency …

Webhooks make up the backbone of interactions with services like Twilio. When an event happens on one of our numbers, maybe it receives an SMS, then Twilio sends an HTTP request to our server with information on what happened. Typically we'll reply with instructions on how to respond to the event, perhaps we'll want to reply with an SMS of our own.

Webhooks make interacting with events from Twilio really straightforward, but they also open our application to be manipulated in unexpected ways. If someone knows your webhook URL, they can craft HTTP requests to generate fake events that were never intended.

To protect from counterfeit requests Twilio includes a signature header X-Twilio-Signature in every webhook sent to your server. We can use our secret Twilio authentication token plus the data submitted to the server to generate our own signature. We can then compare this to the header signature to …

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, …