kconner

macOS Internals

Understand your Mac and iPhone more deeply by tracing the evolution of Mac OS X from prelease to Swift. John Siracusa delivers the details.

Starting Points

How to use this gist

You've got two main options:

ssrihari

An opinionated list of excellent Clojure learning materials

These resources (articles, books, and videos) are useful when you're starting to learn the language, or when you're learning a specific part of the language. This an opinionated list, no doubt. I've compiled this list from writing and teaching Clojure over the last 10 years.

• 🔴 Mandatory (for both beginners and intermediates)
• 🟩 For beginners
• 🟨 For intermediates

Table of contents

1. Getting into the language

d-t-w

<code_scheme name="TW" version="173">
  <ClojureCodeStyleSettings>{
  :cljs.core/as-&gt; :only-indent
  :cljs.core/assoc 0
  :cljs.core/cond-&gt; :only-indent
  :cljs.core/cond-&gt;&gt; :only-indent
  :cljs.core/defonce :only-indent
  :cljs.core/with-meta :only-indent
  :cljs.core.async/go :only-indent
  :cljs.core.async/go-loop :only-indent

roman01la

ClojureScript REPL Workflow

Short write up on using REPL when developing UIs in ClojureScript.

Hot-reload on save or Eval in REPL?

Everyone's standard approach to hot-reloading is to use a tool (Figwheel or shadow-cljs) that reloads changed namespaces automatically. This works really well: you change the code, the tool picks up changed files, compiles namespaces and dependants, notifies REPL client which then pulls in compiled changes, and re-runs a function that re-renders UI.

The other approach is to use ClojureScript's REPL directly and rely only on eval from the editor. This more or less matches Clojure style workflow. This approach might be useful when you don't want tools overhead or hot-reloading becomes slow for you or you just used to this style of interactions. Also changing code doesn't always mean that you want to reload all the changes. On the other hand it is very easy to change a couple of top-level forms and forget to eval one of them.

justone

This logback configuration is an example of diverting debug level logs for a specific package to a separate file, while maintaining info level in the main log. This allows viewing all package logs in context, and then when an info or warn level log appears, you can switch to the debug log and see that line in context with debug statements.

This is particularly useful for debugging a new or troublesome package in production without cluttering up your main log stream.

The main appender is the primary appender to which all application logs are

yogthos

Introductory resources

• High level overview https://yogthos.github.io/ClojureDistilled.html
• An Animated Introduction to Clojure https://markm208.github.io/cljbook/
• Interactive tutorial in a browser https://tryclojure.org/
• Interactive exercises http://clojurescriptkoans.com/
• Clerk notebooks with introductory examples https://github.clerk.garden/anthonygalea/notes-on-clojure
• More interactive exercises https://4clojure.oxal.org/
• Lambda Island tutorials https://lambdaisland.com/
• Functional Programming with Clojure resources https://practicalli.github.io/

pjstadig

The Pledge

One thing that always made me a little sad about transducers was how map lost its ability to iterate multiple collections in parallel. This is actually my favorite feature of map. For example:

(map + (range 5) (range 5 10))
=> (5 7 9 11 13)

One somewhat practical use of this is if you want to compare two sequences, pairwise, using a comparator. Though I wish that every? took multiple collections, this is an adequate substitute:

maacl

(ns pms.core
  (:require [clojure.spec.alpha :as s]
            [clojure.spec.gen.alpha :as gen]
            [clojure.spec.test.alpha :as stest]))

(comment "This is a small experiment inspired by Oskar Wickströms
  excellent work at
  https://haskell-at-work.com/episodes/2018-01-19-domain-modelling-with-haskell-data-structures.html. I
  wanted to see what would be involved in building the equivalent
  functionality in reasonably ideomatic Clojure. It is also my first

semperos

{:aliases {:dev {:extra-deps
                 {org.clojure/tools.nrepl {:mvn/version "0.2.13"}
                  cider/cider-nrepl {:mvn/version "0.17.0-SNAPSHOT"}}}
           :std {:extra-paths ["resources"]}
           :test {:extra-paths ["test"]}}
 :mvn/repos {"private-repo" {:url "https://example.com/repository/maven-releases/"}}}

levand

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