---Utility for keymap creation. | |
---@param lhs string | |
---@param rhs string|function | |
---@param opts string|table | |
---@param mode? string|string[] | |
local function keymap(lhs, rhs, opts, mode) | |
opts = type(opts) == 'string' and { desc = opts } | |
or vim.tbl_extend('error', opts --[[@as table]], { buffer = bufnr }) | |
mode = mode or 'n' | |
vim.keymap.set(mode, lhs, rhs, opts) |
Based on this blogpost.
To sign Git commits, you need a gpg key. GPG stands for GNU Privacy Guard and is the de facto implementation of the OpenPGP message format. PGP stands for ‘Pretty Good Privacy’ and is a standard to sign and encrypt messages.
Install with Homebrew:
$ brew install gpg
#!/bin/sh | |
set -e | |
if [ "$(elm --version)" != "0.19.1" ]; then | |
echo "Globally installed elm 0.19.1 is required" | |
exit 1 | |
fi | |
export packages=~/.elm/0.19.1/packages |
There's a lot of type terminology and jargon going around when discussing types in Elm. This glossary attempts to list some of the most common type terms along with synonyms, terms from other language communities, examples, and links to more detailed articles on each topic.
This is some sort of answer to recent posts regarding Web Components, where more than a few misconceptions were delivered as fact.
Let's start by defining what we are talking about.
As you can read in the dedicated GitHub page, Web Components is a group of features, where each feature works already by itself, and it doesn't need other features of the group to be already usable, or useful.
Thanks to the original blog post: https://equimper.com/blog/how-to-setup-tailwindcss-in-phoenix-1.4
cd assets
npm i --save-dev tailwindcss postcss-loader postcss-import
-- Adapted from https://gist.github.com/roine/a2da44f2047d494cabaf715f06a591db#file-4_application-elm | |
module Main exposing | |
( Flags | |
, Model | |
, Msg(..) | |
, Navigation | |
, Route(..) | |
, bodyView | |
, fromUrl | |
, init |
From 0.19 Elm introduced 4 ways to boot an app:
- sandbox (no outside interaction)
- element (simple outside interaction - side effect, flags, subscriptions)
- document (same as above but with title tag control)
- application (whole SPA features)
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