Part 1: Adding custom metrics to a Phoenix 1.5 live dashboard

The code for this demo is available here

As I mentioned in the previous post, one of the downsides to the new Phoenix live dashboard is that the metrics and graphs are transient. In order to see longer term trends, we’re going to send our telemetry metrics to InfluxDB via StatsD.

Add the statsd reporter to your Phoenix app

Open lib/metrics_demo_web/telemetry.ex and add the following line to the deps:

{:telemetry_metrics_statsd, "~> 0.4"},

It should now look like this:

defp deps do [ {:phoenix, "~> 1.5.3"}, {:phoenix_ecto, "~> 4.1"}, {:ecto_sql, "~> 3.4"}, {:postgrex, ">= 0.0.0"}, {:phoenix_live_view, "~> 0.13.0"}…

Part 2: Sending Phoenix 1.5 metrics to InfluxDb

The code for this demo is available here

To get started, make sure you have the Phoenix 1.5 project generator:

mix archive.uninstall phx_new
mix archive.install hex phx_new 1.5.1

Create a new Phoenix 1.5 project:

mix phx.new metrics_demo
cd metrics_demo && mix ecto.create

Open metrics_demo/lib/metrics_demo_web/controllers/page_controller.ex and add the following line to emit a telemetry event:

:telemetry.execute([:metrics_demo, :render], %{controller: "PageController", action: "index"})

It should now look like this:

defmodule MetricsDemoWeb.PageController do
use MetricsDemoWeb, :controller

def index(conn, _params) do
:telemetry
.execute([:metrics_demo, :render], %{controller: "PageController", action: "index"})
render(conn, "index.html")
end
end

Now open metrics_demo/lib/metrics_demo_web/telemetry.ex


The Heroku buildpacks make some assumptions about your project based on earlier versions, but with a few tweaks can be used with version 1.4 of Elixir and 1.3 of Phoenix.

This assumes you created your project with mix phx.new hello_phoenix --umbrella. Replace hello_phoenix and HelloPhoenix with your app name where appropriate.

Most of the instructions at http://www.phoenixframework.org/docs/heroku are still valid. Complete those and then make the following changes:

  • This may be obvious, but the config/prod.exs mentioned is the one in the web app folder: hello_phoenix_umbrella/apps/hello_phoenix_web/config/prod.exs.
  • Change the reference in prod.exs from HelloPhoenix.Endpoint to HelloPhoenix.Web.Endpoint.
  • You’ll also need to remove import_config…

In case you missed it, check out Part 1.

Creating the URL to HTML Lambda

The first lambda works great, and is actually all we’re using for our original use case. However, uploading html files to S3 is a little clunky. It would be nice if we could provide a url and have the html automatically created and uploaded to our bucket.

Creating the project and the Lambda is almost exactly the same as for the previous lambda (same handler and role), but this time we won’t add a trigger. …


Creating PDFs from HTML with AWS Lambda and API Gateway

There are quite a few cases in which we’d like to be able to output a dynamic PDF (invoices, statements, receipts, etc.) However, our experience has been that working with PDF templates and editors is fairly painful. We would instead like to be able to work with the tools we’re familiar with, HTML and CSS. As such, we needed a mechanism which takes HTML as input and returns a PDF as output.

Creating the HTML to PDF Lambda

Creating a custom Lambda is fairly straightforward. You’ll need to log into your AWS account, head over to Services > Compute >…


Say you’re writing a test and you have an intermediate method that takes some input and uses it to construct some output. In the context of your test case you don’t care what this intermediate method does, but the method under test expects the output to correspond to the input.

One way to set this up is to simply stub out all of the known values you expect your test to pass into the method.

var someClass = MockRepository.GenerateStub<ISomeClass>();someClass.Stub(c => c.someMethod(1))
.Return(new AnotherClass { Id = 1 });
someClass.Stub(c => c.someMethod(2))
.Return(new AnotherClass { Id = 2});
someClass.Stub(c =>…

We’ve all been guilty of doing a lazy git commit -a, accidentally including a file we didn’t mean to in the commit. Or perhaps you meant to at the time, but later decided to split it into two commits. You can easily fix this with git reset.

TL;DR

I know you’re busy, so here’s the quick and dirty version:

$ git reset --soft HEAD^
$ git reset HEAD folder/file.js
$ git commit -c ORIG_HEAD

Now for a little explanation

The first thing we want to do is get our staging area back into the state it was just before we made the commit. Whenever you see…

Marc Delagrammatikas

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store