paulo-ferraz-oliveira

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) ->

mayel

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

mcrumm

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

pyrmont

name: build

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

jobs:
  build:

swalkinshaw

Moved to Shopify/graphql-design-tutorial

jswny

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

christhekeele

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.
  

chrismccord

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:

rauchg

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');

jeroenvisser101

#!/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)