alabid

The installation directions for marvel -- a plugin for elastic search -- is very scant and unnecessarily indirect. The clearest instructions I found on how to install the marvel plugin through homebrew was on Twitter! Twitter! Why?! Anyways, to install marvel via brew, you can do this:

brew update
brew upgrade elasticsearch
cd /usr/local/Cellar/elasticsearch/<whatever version>
bin/plugin -i elasticsearch/marvel/latest

jamii

Specification

Out Of The Tarpit

BOOM Analytics: Exploring Data-Centric, Declarative Programming for the Cloud

Dedalus: Datalog in Time and Space

Logic and Lattices for Distributed Programming

jctosta

Screen Quick Reference

Basic

Description	Command
Start a new session with session name	screen -S <session_name>
List running sessions / screens	screen -ls
Attach to a running session	screen -x
Attach to a running session with name	screen -r

ThisIsMissEm

var child_process = require('child_process');

exports.handler = function(event, context) {
  var proc = spawn('./test', [ JSON.stringify(event) ], { stdio: 'inherit' });

  proc.on('close', function(code){
    if(code !== 0) {
      return context.done(new Error("Process exited with non-zero status code"));
    }

obfusk

import code; code.interact(local=dict(globals(), **locals()))

non

What is the appeal of dynamically-typed languages?

Kris Nuttycombe asks:

I genuinely wish I understood the appeal of unityped languages better. Can someone who really knows both well-typed and unityped explain?

I think the terms well-typed and unityped are a bit of question-begging here (you might as well say good-typed versus bad-typed), so instead I will say statically-typed and dynamically-typed.

I'm going to approach this article using Scala to stand-in for static typing and Python for dynamic typing. I feel like I am credibly proficient both languages: I don't currently write a lot of Python, but I still have affection for the language, and have probably written hundreds of thousands of lines of Python code over the years.

worace

SQL Engine

Remember our old buddy Sales Engine? It just won't die. The original clients from the sales engine project have returned, this time requesting more Business Intelligence features. Our original SalesEngine was starting to push the bounds of what we could do efficiently in pure ruby, so our new implementation is going to require some updated tech.

This time around we'll implement sales engine using a database with ActiveRecord. This will allow us to offload some of that complicated business logic where it belongs -- in a relational databse. But steel yourselves, since this new implementation will require writing some SQL.

• Library/CLI only (no web ui?)
• Spec harness?
• New BI reqs?

zchee

--- Actions ---
$Copy                                              <M-C>
$Cut                                               <M-X> <S-Del>
$Delete                                            <Del> <BS> <M-BS>
$LRU                                              
$Paste                                             <M-V>
$Redo                                              <M-S-Z> <A-S-BS>
$SearchWeb                                         <A-S-G>
$SelectAll                                         <M-A>
$Undo                                              <M-Z>

Bekbolatov

Clean tmux cheat-sheet

By resources

sessions

list-sessions        ls         -- List sessions managed by server
new-session          new        -- Create a new session

dwhitney

def graphql: Endpoint[Json] = {

    post(
      "graphql" ? (body :: authOptReader :: contentTypeReader :: imageOptReader :: queryReader :: variablesReader)
    ){ (body: String, authOpt: Option[TokenUUID], contentType: String, image: Option[FileUpload], query: Option[String], variables: Option[String]) =>

      contentType.take("multipart/form-data".length) match {
        case "multipart/form-data" => {
          for {
            auth <- getAuthorization(authOpt)