swannodette

(ns blog.errors.core
  (:require-macros
    [cljs.core.async.macros :refer [go]]
    [blog.utils.macros :refer [<?]])
  (:require
    [cljs.core.async :refer [>! <! chan close!]]))

;; convert Node.js async function into a something
;; that returns a value or error on a channel
(defn run-task [f & args]

konklone

# Basically the nginx configuration I use at konklone.com. 
# I check it using https://www.ssllabs.com/ssltest/analyze.html?d=konklone.com
# 
# To provide feedback, please tweet at @konklone or email [email protected].
# Comments on gists don't notify the author. 
# 
# Thanks to WubTheCaptain (https://wubthecaptain.eu) for his help and ciphersuites.
# Thanks to Ilya Grigorik (https://www.igvita.com) for constant inspiration.

server {

zenorocha

// Future versions of Hyper may add additional config options,
// which will not automatically be merged into this file.
// See https://hyper.is#cfg for all currently supported options.

module.exports = {
  config: {
    // default font size in pixels for all tabs
    fontSize: 14,

    // font family with optional fallbacks

pascalpoitras

This configuration is not maintained anymore. You should think twice before using it, Breaking change and security issue will likely eventually happens as any abandonned project.

arobson

Abstraction Suggestions

Summary: use good/established messaging patterns like Enterprise Integration Patterns. Don't make up your own. Don't expose transport implementation details to your application.

Broker

As much as possible, I prefer to hide Rabbit's implementation details from my application. In .Net we have a Broker abstraction that can communicate through a lot of different transports (rabbit just happens to be our preferred one). The broker allows us to expose a very simple API which is basically:

• publish
• request
• start/stop subscription

raytiley

var dbRef = new Firebase("https://YOUR-FIREBASE.firebaseio.com/");

export default Ember.Controller.extend({
  
  /**
  @property currentUser
  @type {User}
  @default null
  */
  currentUser: null,

brendanzab

NOTE: This was first authored on 26 Feb 2014. Things may have changed since then.

C++'s Templates

C++'s templates could be seen as forming a duck typed, purely functional code generation program that is run at compile time. Types are not checked at the initial invocation stage, rather the template continues to expand until it is either successful, or runs into an operation that is not supported by that specific type – in that case the compiler spits out a 'stack trace' of the state of the template expansion.

To see this in action, lets look at a very simple example:

template 

vaughnd

;; Schema

{:db/doc "Find or create tag atomically."
   :db/ident :find-or-create-tag
   :db/fn #db/fn {:lang "clojure"
                  :params [mydb n key value]
                  :code (when (empty? (d/q '[:find ?e :in $ ?ns ?key ?value :where
                                             [?e :meta/tag-namespace ?n]
                                             [?e :meta/tag-key ?key]
                                             [?e :meta/tag-value ?value]]

joelkallman

(function (RSVP) {

    if (!RSVP) {
        return;
    }

    /**
      Spread is utilized with the all() method.

      Basic Usage:

telent

App configuration in environment variables: for and against

For (some of these as per the 12 factor principles) 

1) they are are easy to change between deploys without changing any code

2) unlike config files, there is little chance of them being checked
into the code repo accidentally

3) unlike custom config files, or other config mechanisms such as Java