| import org.elasticsearch.spark._ | |
| import org.elasticsearch.spark.rdd.EsSpark | |
| import org.elasticsearch.spark.sql._ | |
| // Create a DataFrame to write to ElasticSearch | |
| case class SimpsonCharacter(name: String, actor: String, episodeDebut: String) | |
| val simpsonsDF = sc.parallelize( | |
| SimpsonCharacter("Homer", "Dan Castellaneta", "Good Night") :: |
| module Layout exposing ( .. ) | |
| import Html exposing ( .. ) | |
| import Html.App | |
| import Html.Attributes exposing ( .. ) | |
| import Material | |
| import Material.Scheme as Scheme | |
| import Material.Layout as Layout | |
| import Material.List as List' |
Disclaimer: This piece is written anonymously. The names of a few particular companies are mentioned, but as common examples only.
This is a short write-up on things that I wish I'd known and considered before joining a private company (aka startup, aka unicorn in some cases). I'm not trying to make the case that you should never join a private company, but the power imbalance between founder and employee is extreme, and that potential candidates would
| # ======================== Elasticsearch Configuration ========================= | |
| # | |
| # NOTE: Elasticsearch comes with reasonable defaults for most settings. | |
| # Before you set out to tweak and tune the configuration, make sure you | |
| # understand what are you trying to accomplish and the consequences. | |
| # | |
| # The primary way of configuring a node is via this file. This template lists | |
| # the most important settings you may want to configure for a production cluster. | |
| # | |
| # Please see the documentation for further information on configuration options: |
This is a basic guide on how to learn Elm rather than actually teach you. I'm going to mostly link to resources that I feel are valuable and try to "teach you how to fish".
The main purpose is to accelerate your learning and save you a lot of googling and weeding through bad explinations.
| # Pass the env-vars to MYCOMMAND | |
| eval $(egrep -v '^#' .env | xargs) MYCOMMAND | |
| # … or ... | |
| # Export the vars in .env into your shell: | |
| export $(egrep -v '^#' .env | xargs) |
development https://git.heroku.com/xxx.git (fetch)
development https://git.heroku.com/xxx.git (push)
origin [email protected]:xxx/xxx.git (fetch)
origin [email protected]:xxx/xxx.git (push)
production https://git.heroku.com/xxx.git (fetch)
production https://git.heroku.com/xxx.git (push)
staging https://git.heroku.com/xxx.git (fetch)
| defmodule LeakyBucket.Bucket do | |
| @moduledoc """ | |
| Simulates a leaky bucket implementation | |
| """ | |
| use GenServer | |
| @initial_amount 0 | |
| @increment_rate 1 | |
| @leak_rate 2 | |
| @leak_interval 500 |
| { | |
| "mode": "patterns", | |
| "proxySettings": [ | |
| { | |
| "title": "EMR SOCKS Proxy", | |
| "type": 3, | |
| "color": "#cc8c2a", | |
| "address": "localhost", | |
| "port": 8157, | |
| "proxyDNS": true, |
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