Henricus Louwhoff hl

Tracing in Elixir with `:recon`, and `formatter`

I tend to not remember how this is done, so here goes, for easier copy-paste effect:

:recon_trace.calls(
  {_mod = HTTPoison, _fun = :request, fn ([_, _, _, _, _]) -> :return_trace end},
  _calls = 10,
  [scope: :local,
 formatter: fn (tuple) -&gt;

Deploying to Fly.io with SQLite

Deploying a Phoenix app to Fly.io is a breeze...is what everyone kept telling me. In fairness, I imagine the process would have been breezier had I just used postgres, but all the sqlite and litestream talk has been far too intriguing to ignore. "Wait", you say. "It is just a flat file. How much harder can it be?"

It is easy to make something harder than it should be. It is hard to take something complex and make it truly simple. flyctl launch does an amazing job at providing a simple interface to the utterly complex task of generating deployment resources, especially now that we are living in a containerd (erm, firecracker) world.

This gist is for anyone who, like me, thinks they know better than to read all of the documentation and therefore necessari

Moved to Shopify/graphql-design-tutorial

Prelude

I. Preface and Motivation

This guide was written because I don't particularly enjoy deploying Phoenix (or Elixir for that matter) applications. It's not easy. Primarily, I don't have a lot of money to spend on a nice, fancy VPS so compiling my Phoenix apps on my VPS often isn't an option. For that, we have Distillery releases. However, that requires me to either have a separate server for staging to use as a build server, or to keep a particular version of Erlang installed on my VPS, neither of which sound like great options to me and they all have the possibilities of version mismatches with ERTS. In addition to all this, theres a whole lot of configuration which needs to be done to setup a Phoenix app for deployment, and it's hard to remember.

For that reason, I wanted to use Docker so that all of my deployments would be automated and reproducable. In addition, Docker would allow me to have reproducable builds for my releases. I could build my releases on any machine that I wanted in a contai

If you want a run-down of the 1.3 changes and the design decisions behidn those changes, check out the LonestarElixir Phoenix 1.3 keynote: https://www.youtube.com/watch?v=tMO28ar0lW8

To use the new phx.new project generator, you can install the archive with the following command:

$ mix archive.install https://github.com/phoenixframework/archives/raw/master/phx_new.ez

Bump your phoenix dep

Phoenix v1.3.0 is a backwards compatible release with v1.2.x. To upgrade your existing 1.2.x project, simply bump your phoenix dependency in mix.exs:

require-from-twitter

Since Twitter doesn't have an edit button, it's a suitable host for JavaScript modules.

How to use

Source tweet: https://twitter.com/rauchg/status/712799807073419264

const leftPad = await requireFromTwitter('712799807073419264');

	defmodule Module.Extend do

	@doc """
	Extend a module (i.e. define `defdelegate` and `defoverridable` for all functions from the source module in the current module.
	Usage:
	import Module.Extend
	extend_module Common.Text
	"""
	defmacro extend_module(module) do
	require Logger

	name: build

	on:
	push:
	branches: [ master ]
	pull_request:
	branches: [ master ]

	jobs:
	build:

	defmodule Default.Behaviour do
	@moduledoc """
	Creates a behaviour that carries its own default implementation.

	When used into a behaviour module, when that module in turn is used, all functions
	defined on it are given to the using module.

	This allows you to have concrete implementations of the behaviour's default functionality
	for testing, unlike cramming them all into a __using__ macro.

	#!/usr/bin/env ruby
	def notice(text)
	puts "\e[33m#{text}\e[0m"
	end

	def success(text)
	puts "\e[32m#{text}\e[0m"
	end

	def error(text)