BOOM Analytics: Exploring Data-Centric, Declarative Programming for the Cloud
| (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) |
| (defmacro rec-lazy-seq | |
| "Like lazy-seq, but also takes a single binding form that will be | |
| a reference to the lazy seq object itself, so that the lazy seq can | |
| be defined in terms of itself." | |
| [[name] & body] | |
| `(let [p# (promise) | |
| ls# (lazy-seq | |
| (let [~name (lazy-seq @p#)] | |
| ~@body))] | |
| (deliver p# ls#) |
| (ns chords.core | |
| (:refer-clojure :exclude [==]) | |
| (:require [clojure.core.logic :refer :all] | |
| [clojure.core.logic.fd :as fd] | |
| [clojure.core.logic.pldb :as pldb] | |
| [fipp.edn :refer (pprint) :rename {pprint fipp}])) | |
| (pldb/db-rel note-name ^:index p) | |
| (pldb/db-rel octave ^:index p) | |
| (pldb/db-rel note ^:index p1 ^:index p2) |
Here are my attempts to script an IntelliJ-based IDE using javax.script.* API (ex-JSR-223).
The list of available scripting languages and engines:
- Groovy - built-in, via Groovy jars and
<app>/lib/groovy-jsr223-xxx.jar - JavaScript (Nashorn) - built-in, via Java Runtime
<app>/jbr/...(deprecated and will be removed soon) - JavaScript (GraalJS) - https://plugins.jetbrains.com/plugin/12548-intellij-scripting-javascript
- JPython - https://plugins.jetbrains.com/plugin/12471-intellij-scripting-python
- JRuby - https://plugins.jetbrains.com/plugin/12549-intellij-scripting-ruby
- Clojure - https://plugins.jetbrains.com/plugin/12469-intellij-scripting-clojure
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.
| (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) |
| (defn select-view | |
| "Navigates to a sequence that is the result of a select on the | |
| current structure. Has similar functionality of srange and filterer, | |
| but can be used with arbitrary selectors making it vastly more | |
| powerful." | |
| [& path] | |
| (fixed-pathed-path [late path] | |
| (select* [this structure next-fn] | |
| (next-fn (compiled-select late structure))) | |
| (transform* [this structure next-fn] |
Recently CSS has got a lot of negativity. But I would like to defend it and show, that with good naming convention CSS works pretty well.
My 3 developers team has just developed React.js application with 7668 lines of CSS (and just 2 !important).
During one year of development we had 0 issues with CSS. No refactoring typos, no style leaks, no performance problems, possibly, it is the most stable part of our application.
Here are main principles we use to write CSS for modern (IE11+) browsers:
- SUIT CSS naming conventions + SUIT CSS design principles;
- PostCSS + CSSNext. Future CSS syntax like variables, nesting, and autoprefixer are good enough;
- Flexbox is awesome. No need for grid framework;
- Normalize.css, base styles and variables are solid foundation for all components;