(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.
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 |
(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))) |
(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.
Simply put, destructuring in Clojure is a way extract values from a datastructure and bind them to symbols, without having to explicitly traverse the datstructure. It allows for elegant and concise Clojure code.
I've heard this before:
What I really get frustrated by is that I cannot wrap
console.*
and preserve line numbers
We enabled this in Chrome DevTools via blackboxing a bit ago.
If you blackbox the script file the contains the console log wrapper, the script location shown in the console will be corrected to the original source file and line number. Click, and the full source is looking longingly into your eyes.
(defmulti transmogrify | |
"Rewrites the last form of a thread-last to use transducer (if possible)." | |
(fn [f xform src & args] f)) | |
(defmacro transmogrify->> | |
"Like ->> but uses transducers" | |
([x] x) | |
([src & xs] | |
(let [end (last xs) | |
xforms (butlast xs) |
chas@t440p:~/Downloads$ java -cp cljs.jar:/home/chas/.m2/repository/org/clojure/tools.nrepl/0.2.10/tools.nrepl-0.2.10.jar:/home/chas/.m2/repository/com/cemerick/piggieback/0.2.1/piggieback-0.2.1.jar clojure.main nrepl_piggieback.clj & | |
nREPL server running on port 7888 | |
# using Leiningen here _only_ to connect to the running nREPL server | |
# any nREPL client will do | |
chas@t440p:~/Downloads$ lein repl :connect 7888 | |
Connecting to nREPL at 127.0.0.1:7888 | |
REPL-y 0.3.5, nREPL 0.2.10 | |
Clojure 1.7.0-beta1 |
One important extension that Gradually Typed Clojure will require is hooking into the standard Clojure evaluation process. There are at least two motivations for this:
The existing prototype has been a useful experiment which has revealed some of the subtleties of Clojure evaluation.
The basic approach is to use nREPL middleware to type check REPL interactions.
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.