(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
When hosting our web applications, we often have one public IP
address (i.e., an IP address visible to the outside world)
using which we want to host multiple web apps. For example, one
may wants to host three different web apps respectively for
example1.com
, example2.com
, and example1.com/images
on
the same machine using a single IP address.
How can we do that? Well, the good news is Internet browsers
(ns reagent-test.core | |
(:require [reagent.core :as reagent :refer [atom]] | |
[datascript :as d] | |
[cljs-uuid-utils :as uuid])) | |
(enable-console-print!) | |
(defn bind | |
([conn q] | |
(bind conn q (atom nil))) |
(ns om-data.core | |
(:require [om.core :as om :include-macros true] | |
[om.dom :as dom :include-macros true] | |
[datascript :as d])) | |
(enable-console-print!) | |
(def schema {}) | |
(def conn (d/create-conn schema)) | |
# Sublime package NVM node path configuration | |
# Save this file in: | |
# ~/Library/Application\ Support/Sublime\ Text\ 3/Packages/node_env.py | |
import os | |
os.environ["PATH"] = "/Users/YOUR_USERNAME/.nvm/v0.10.26/bin:/Users/cranemes/.nvm/v0.10.26/lib:/Users/YOUR_USERNAME/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin" | |
print("PATH=" + os.environ["PATH"]) |
A multi-level groupBy for arrays inspired by D3's nest operator.
Nesting allows elements in an array to be grouped into a hierarchical tree
structure; think of it like the GROUP BY
operator in SQL, except you can have
multiple levels of grouping, and the resulting output is a tree rather than a
flat table. The levels in the tree are specified by key functions.
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 |
(function (RSVP) { | |
if (!RSVP) { | |
return; | |
} | |
/** | |
Spread is utilized with the all() method. | |
Basic Usage: |
;; 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]] |
NOTE: This was first authored on 26 Feb 2014. Things may have changed since then.
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