Main navigation

Dylan Tack's Blog

Metal Toad's second hackathon will be focused on the Internet of Things. Why IoT? Over the years we have accumulated broad experience in this area; we've built systems including analytics for solar and wind energy, backend services for wearable devices, and a vehicle telematics platform. Of course this is a growing field, and in addition to software and data analytics for IoT, this will be a chance for toads to get their hands dirty with a soldering iron.

Some friends on Twitter were alarmed by this Drupal change record: "Accept header based routing got replaced by a query parameter". This change replaces "Accept: application/hal_json" with "/node/1?_format=hal_json". The issues leading to this change are too lengthy to capture on Twitter, so I'll give my perspective here.

Many of our readers have asked for an update to the mobile device diagram. Rather than diagramming what handset makers are selling, I thought it would be interesting to plot what our visitors are actually using. With that in mind, here is the updated version with data extracted from Google Analytics:

Like many Drupal developers, we have become big fans of decoupled front-ends using Drupal as a RESTful backend (a.k.a. "headless" Drupal). The myriad of authorization options can be confusing, however. We've settled on OAuth 2.0 for most situations. When OAuth is brought up, many people will think of the single-sign-on flow in a browser, with the associated redirects and permission dialogs. This flow is widely used, but not always a good fit for first-party applications, or machine-to-machine API interactions.

When working with Angular's $http service, one of the nifty options is a built-in cache service. It's off by default, and enabling this service can prevent repeated requests for the same resource. In this post, I'll compare Angular's service to native HTTP caching in your browser (I used Chrome as a baseline for comparison, and other browsers may differ slightly).

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:

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: