vvvvalvalval

;; Synchronous Clojure trained us to use Exceptions, while asynchronous JavaScript has trained us to use Promises.
;; In contexts where we work asynchronously in Clojure (in particular ClojureScript), it can be difficult to see a definite way of managing failure. Here are some proposals.

;; OPTION 1: adapting exception handling to core.async CSPs
;; As proposed by David Nolen, with some macro sugar we use Exceptions in go blocks with core async in the same way we would do with synchronous code.

(require '[clojure.core.async :as a :refer [go]])

;; defining some helper macros
(defn throw-err "Throw if is error, will be different in ClojureScript"

jamestalmage

Why

Doing require extensions correctly is essential, because:

1. Users should be able to install multiple extensions in succession, and have them work together.
2. Coverage tools like nyc need it to reliably supply coverage information that takes into account sourcemaps from upstream transforms.
3. Because non-standard, un-predictable behavior causes hard to solve bugs, and major headaches for project maintainers.

What is a require extension anyways?

gaearon

import { combineReducers } from 'redux';
import users from './reducers/users';
import posts from './reducers/posts';

export default function createReducer(asyncReducers) {
  return combineReducers({
    users,
    posts,
    ...asyncReducers
  });

rgrove

Can't share the complete code because the app's closed source and still in stealth mode, but here's how I'm using React Router and Redux in a large app with server rendering and code splitting on routes.

Server

1. Wildcard Express route configures a Redux store for each request and makes an addReducers() callback available to the getComponents() method of each React Router route. Each route is responsible for adding any Redux reducers it needs when it's loaded. (This isn't really necessary on the

mholt

mholt [9:10 AM] 
When using http.Get(), is it really necessary to read the full response body just to close it later?

[9:10] 
The docs keep saying `Caller should close resp.Body when done reading from it.` and I keep seeing code like this:
```
io.Copy(ioutil.Discard, resp.Body)
resp.Body.Close()
```

pesterhazy

(ns background
  (:require [clojure.tools.logging :as log])
  (:import [java.util.concurrent]))

(defonce !executor (delay (java.util.concurrent.Executors/newCachedThreadPool)))

(defn background
  "Calls the fn passed in a thread from a thread pool, returning immediately.
  Unlike future, background does not swallow exceptions."
  [f]

lukebussey

cd /Library/Preferences
sudo rm com.sophos.sav.plist

cd /Library/Application\ Support/Sophos/cloud/Installer.app/Contents/MacOS/tools/
sudo ./InstallationDeployer —force_remove

jonico

#!groovy
import groovy.json.JsonOutput
import groovy.json.JsonSlurper

def label = "mypod-${UUID.randomUUID().toString()}"
podTemplate(label: label, yaml: """
spec:
      containers:
      - name: mvn
        image: maven:3.3.9-jdk-8

HyperBrain

Serverless plugin author's cheat sheet

This cheat sheet provides a detailed overview of the exposed lifecycle events and available commands (and entrypoints) of the Serverless framework, that can be hooked by plugins (internal and external ones). The document is structured by the commands invoked by the user.

Lifecycle events are shown as the globally available outer events (all providers) and sub lifecycle events that are provider specific in the called order. Currently only the AWS provider is shown. If you have information about the other provider,

gpeal

...
apply from: './flavors.gradle'
...
android {
    buildTypes {
        productFlavors {
            project.flavors.each { flavor, config ->
                "$flavor" {
                    dimension 'scope'
                    if (flavor != 'full') {