A (more) complete cheatsheet for Arel, including NamedFunction functions, raw SQL and window functions.
posts = Arel::Table.new(:posts)
posts = Post.arel_table # ActiveRecord
Please refer to this blogpost to get an overview.
Replace *-INSTANCE
with one of the public instances listed in the scrapers section. Replace CAPITALIZED
words with their corresponding identifiers on the website.
I've been deceiving you all. I had you believe that Svelte was a UI framework — unlike React and Vue etc, because it shifts work out of the client and into the compiler, but a framework nonetheless.
But that's not exactly accurate. In my defense, I didn't realise it myself until very recently. But with Svelte 3 around the corner, it's time to come clean about what Svelte really is.
Svelte is a language.
Specifically, Svelte is an attempt to answer a question that many people have asked, and a few have answered: what would it look like if we had a language for describing reactive user interfaces?
A few projects that have answered this question:
#!/bin/sh | |
echo | |
if [ ! -d "deps" ] || [ ! "$(ls -A deps)" ]; then | |
printf "\e[32m=> Fetching dependencies and building the application...\e[0m\n\n" | |
echo "+ mix do deps.get, compile --verbose" | |
mix do deps.get, compile --verbose | |
echo | |
fi |
{ pkgs ? import <nixpkgs> {} }: | |
with pkgs; | |
let | |
inherit (lib) optional optionals; | |
elixir = beam.packages.erlangR21.elixir_1_7; | |
nodejs = nodejs-10_x; | |
postgresql = postgresql100; |
SPC | |
SPC: find file | |
, switch buffer | |
. browse files | |
: MX | |
; EX | |
< switch buffer | |
` eval | |
u universal arg | |
x pop up scratch |
def calc_allocations(self, date, quantity, cap): | |
"""Figure out ideal allocations for a given date""" | |
# { | |
# coin_name: (percent_allocation, data) | |
# } | |
top_market = self.get_top_market(date, quantity) | |
total_cap = sum([coin.market_cap for coin in top_market]) | |
allocations = [{ |
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
{ | |
"mode": "patterns", | |
"proxySettings": [ | |
{ | |
"title": "EMR SOCKS Proxy", | |
"type": 3, | |
"color": "#cc8c2a", | |
"address": "localhost", | |
"port": 8157, | |
"proxyDNS": true, |
defmodule LeakyBucket.Bucket do | |
@moduledoc """ | |
Simulates a leaky bucket implementation | |
""" | |
use GenServer | |
@initial_amount 0 | |
@increment_rate 1 | |
@leak_rate 2 | |
@leak_interval 500 |