| [%bs.raw {|require("bootstrap/dist/css/bootstrap.min.css")|}]; | |
| type complex = { | |
| value: string, | |
| className: string | |
| }; | |
| module BtnColorContext = | |
| Context.MakePair({ | |
| type t = complex; |
| module StringContext = | |
| Context.MakePair({ | |
| type t = string; | |
| let defaultValue = "Awesome"; | |
| }); | |
| let component = ReasonReact.statelessComponent("Tree"); | |
| let make = _children => { |
| {:aliases | |
| {:dev {:extra-deps {com.bhauman/rebel-readline {:mvn/version "0.1.2"} | |
| org.clojure/tools.nrepl {:mvn/version "0.2.12"} | |
| cider/cider-nrepl {:mvn/version "0.17.0-SNAPSHOT"}} | |
| :main-opts ["-m" "repl"]}}} |
| (ns figma.specs | |
| (:require [clojure.spec.alpha :as s])) | |
| (def color-chan | |
| (s/and number? #(<= 0 % 1))) | |
| (def alpha-chan | |
| (s/and number? #(<= 0 % 1))) | |
| ;;============================================= |
| ;; Run using a local build of ClojureScript master, e.g.: | |
| ;; clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.10.155"}}}' -i build.clj | |
| (require '[cljs.build.api :as b]) | |
| (b/watch "src" | |
| {:output-dir "out" | |
| :output-to "out/main.js" | |
| :optimizations :none | |
| :verbose true |
| module Store = { | |
| type action = | |
| | Increase | |
| | Decrease | |
| | SetUsername(string); | |
| type state = { | |
| count: int, | |
| username: string, | |
| }; | |
| type storeBag = { |
When you're working on multiple coding projects, you might want a couple different version of Python and/or modules installed. That way you can keep each project in its own sandbox instead of trying to juggle multiple projects (each with different dependencies) on your system's version of Python. This intermediate guide covers one way to handle multiple Python versions and Python environments on your own (i.e., without a package manager like conda). See the Using the workflow section to view the end result.
- Working on 2+ projects that each have their own dependencies; e.g., a Python 2.7 project and a Python 3.6 project, or developing a module that needs to work across multiple versions of Python. It's not reasonable to uninstall/reinstall modules every time you want to switch environments.
- If you want to execute code on the cloud, you can set up a Python environment that mirrors the relevant
Running in Datasette at https://vice-police-shootings.now.sh/vice-bc7c892/ViceNews_FullOISData
Here's what I did:
First, I exported as CSV the data from https://docs.google.com/spreadsheets/d/1CaOQ7FUYsGFCHEqGzA2hlfj69sx3GE9GoJ40OcqI9KY/edit#gid=1271324584
Then I converted it to a SQLite database using https://github.com/simonw/csvs-to-sqlite like so:
csvs-to-sqlite ~/Downloads/ViceNews_FullOISData.csv /tmp/vice.db \
-c Fatal -c SubjectArmed -c SubjectRace -c SubjectGender -c OfficerRace \
Since it has come up a few times, I thought I’d write up some of the basic ideas around domain modeling in Clojure, and how they relate to keyword names and Specs. Firmly grasping these concepts will help us all write code that is simpler, cleaner, and easier to understand.
Clojure is a data-oriented language: we’re all familiar with maps, vectors, sets, keywords, etc. However, while data is good, not all data is equally good. It’s still possible to write “bad” data in Clojure.
“Good” data is well defined and easy to read; there is never any ambiguity about what a given data structure represents. Messy data has inconsistent structure, and overloaded keys that can mean different things in different contexts. Good data represents domain entities and a logical model; bad data represents whatever was convenient for the programmer at a given moment. Good data stands on its own, and can be reasoned about without any other knowledge of the codebase; bad data is deeply and tightly coupled to specific generating and