chrismccord

config :wps, WPSWeb.Endpoint,
  live_reload: [
    notify: [
      live_view: [
        ~r"lib/wps_web/core_components.ex$",
        ~r"lib/wps_web/(live|components)/.*(ex|heex)$"
      ]
    ],
    patterns: [
      ~r"priv/static/(?!uploads/).*(js|css|png|jpeg|jpg|gif|svg)$",

Wigny

Application.put_env(:input, Input.Endpoint,
  server: true,
  http: [ip: {127, 0, 0, 1}, port: 4001],
  adapter: Bandit.PhoenixAdapter,
  render_errors: [
    formats: [html: Input.ErrorHTML],
    layout: false
  ],
  live_view: [signing_salt: "aaaaaaaa"],
  secret_key_base: String.duplicate("a", 64)

rwp0

# ~/.config/gh/config.yml

# What protocol to use when performing git operations. Supported values: ssh, https
git_protocol: https
# What editor gh should run when creating issues, pull requests, etc. If blank, will refer to environment.
editor:
# When to interactively prompt. This is a global config that cannot be overridden by hostname. Supported values: enabled, disabled
prompt: enabled
# A pager program to send command output to, e.g. "less". Set the value to "cat" to disable the pager.
pager:

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

DavidKuennen

(function (context, trackingId, options) {
    const history = context.history;
    const doc = document;
    const nav = navigator || {};
    const storage = localStorage;
    const encode = encodeURIComponent;
    const pushState = history.pushState;
    const typeException = 'exception';
    const generateId = () => Math.random().toString(36);
    const getId = () => {

tadejm

require 'net/http'
require 'json'
require 'uri'

@token = ''

def list_files
  ts_to = (Time.now - 30 * 24 * 60 * 60).to_i # 30 days ago
  params = {
    token: @token,

davisford

Add the `replication` section to the mongod.conf file:

```
$cat /usr/local/etc/mongod.conf
systemLog:
  destination: file
  path: /usr/local/var/log/mongodb/mongo.log
  logAppend: true
storage:
  engine: mmapv1

garybernhardt

This document has moved!

It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.

bmcguirk

# Full credit to Pete here: http://www.createdbypete.com/articles/simple-way-to-find-broken-links-with-wget/
wget --spider -nd -o ~/wget.log -e robots=off -w 1 -r http://www.example.com
grep -B 2 '404' example.com.log >> example.com.404.log

ericclemmons

Using <details> in GitHub

Suppose you're opening an issue and there's a lot noisey logs that may be useful.

Rather than wrecking readability, wrap it in a <details> tag!

<details>
 Summary Goes Here