(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.
(defn graph [app owner opts] | |
(reify | |
om/IInitState | |
(init-state [_] | |
(let [data (:data app) | |
width (:width opts) | |
height (:height opts) | |
x (-> d3 .-time (.scale) (.range [0 width])) | |
y (-> d3 .-scale (.linear) (.range [height 0])) ] | |
{:width width |
(require '[clojure.core.async :as a]) | |
(def xform (comp (map inc) | |
(filter even?) | |
(dedupe) | |
(flatmap range) | |
(partition-all 3) | |
(partition-by #(< (apply + %) 7)) | |
(flatmap flatten) | |
(random-sample 1.0) |
(comment ; Fun with transducers, v2 | |
;; Still haven't found a brief + approachable overview of Clojure 1.7's new | |
;; transducers in the particular way I would have preferred myself - so here goes: | |
;;;; Definitions | |
;; Looking at the `reduce` docstring, we can define a 'reducing-fn' as: | |
(fn reducing-fn ([]) ([accumulation next-input])) -> new-accumulation | |
;; (The `[]` arity is actually optional; it's only used when calling | |
;; `reduce` w/o an init-accumulator). |
<!DOCTYPE html> | |
<html> | |
<head> | |
<meta charset="utf-8" /> | |
<meta name="format-detection" content="telephone=no" /> | |
<meta name="msapplication-tap-highlight" content="no" /> | |
<!-- WARNING: for iOS 7, remove the width=device-width and | |
height=device-height attributes. See | |
https://issues.apache.org/jira/browse/CB-4323 --> | |
<meta name="viewport" |
Recent improvements to the ClojureScript compiler have greatly simplified setting up development versus production outputs.
This example uses Figwheel as something that you want to exclude for production, but the pattern is general.
With this simple setup you only need one html file/view and it will work for developement and production.
(ns nested-routing.core | |
(:require-macros [om.core :as om] | |
[secretary.core :refer [defroute]]) | |
(:require [om.dom :as dom] | |
[om.core :as om] | |
[secretary.core :as secretary] | |
[goog.events :as events] | |
[goog.history.EventType :as EventType]) | |
(:import goog.History)) |
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 |
It would be interesting if Figwheel could essentially decorate any implementation of IJavaScriptEnv
, taking on the responsibility of watching the filesystem (perhaps even delegating that to ClojureScript :watch
, and expanded :watch-fn
, and perhaps minimally calling IJavaScriptEnv -load
when Figwheel determines it is needed.
Then, for those REPLs that can participate, if IFigwheelSupport
can be extended to them, they can do further cool stuff. (Perhaps IFigwheelSupport
is actually necessary while IJavaScriptEnv
as described in the previous paragraph is insufficient, and a more fancy impl of -load
is needed?)
That way, things like the existing Node REPL could be minimally supported by Figwheel, as well as Ambly, the Browser REPL, etc.
What does IFigwheelSupport
do?
Perhaps somewhere there is a HUD interface and Figwheel can ask a REPL to display things on its HUD? An iOS or Android-specific REPL could delegate to Objective-C or Java that implement a HUD using platform-specific UI widgets