skeeto

;;; -*- lexical-binding: t; -*-

;; $ emacs -Q --batch -f batch-byte-compile example.el
;; $ emacs -Q --batch -l example.elc -f disas
;; $ emacs -Q --batch -l example.elc -f bench

(defun add (a b)
  (+ (car a) (car b)))

(defalias 'car-alias #'car)

pramsey

• Google Presentation Link [goo.gl]
• PDF Presentation Link [s3.cleverelephant.ca]
• "Ottawa turns to U.S. tech giants too often: internal memo" [cbc.ca]
• "Government as a Platform: the next phase of digital transformation" [gds.blog.gov.uk]
• DevOps Real Talk [www.theregister.co.uk] "incremental change, tight feedback loops, shared knowledge, and mutual respect" "If you're a developer releasing large changesets, you're part of the problem."
• The Government IT Self-Harm Playbook [medium.com]
• Better For Less (UK IT) [[drive.google.com](https:/

reborg

Rich Already Answered That!

A list of commonly asked questions, design decisions, reasons why Clojure is the way it is as they were answered directly by Rich (even when from many years ago, those answers are pretty much valid today!). Feel free to point friends and colleagues here next time they ask (again). Answers are pasted verbatim (I've made small adjustments for readibility, but never changed a sentence) from mailing lists, articles, chats.

How to use:

• The link in the table of content jumps at the copy of the answer on this page.
• The link on the answer itself points back at the original post.

Table of Content

daveliepmann

(ns localstorage)

(defn set-item!
  "Set `key' in browser's localStorage to `val`."
  [key val]
  (.setItem (.-localStorage js/window) key val))

(defn get-item
  "Returns value of `key' from browser's localStorage."
  [key]

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

ahoy-jon

With leiningen http://leiningen.org/

lein new clojure-into

You can then open your project in LightTable http://www.lighttable.com/ and start hacking !

Neil-Smithline

;;; Create and display an `ibuffer' showing only `org-mode' files.
;;;
;;; I have bound this to "\C-cb" using:
;;;    (global-set-key "\C-cb" #'org-ibuffer)
;;;
;;; Now "\C-x\C-b" creates a generic `ibuffer' and "\C-cb"
;;; creates an `org-mode' `ibuffer'.

(require 'ibuffer)