smahood

Left Hand Shape: 
T-

Vowel Shape: 
A

Right Hand Shape: 
-F

smahood

Left Hand Shape: 
S-

Vowel Shape: 
A

Right Hand Shape: 
-F

smahood

/*
 * Good on you for modifying your layout, this is the most nonQMK layout you will come across
 * There are three modes, Steno (the default), QWERTY (Toggleable) and a Momentary symbol layer
 *
 * Don't modify the steno layer directly, instead add chords using the keycodes and macros
 * from sten.h to the layout you want to modify.
 *
 * Observe the comment above processQWERTY!
 *
 * http://docs.gboards.ca

smahood

For my current keyboard customization, I'm overusing custom keycodes and case statements pretty heavily and haven't had 
any performance problems at all. 
Here are some thoughts on ways to make a hyper-customizable layout a little less painful. My intuition tells me it will run
slower than the current QMK system, but I suspect it will not be noticeable at all in real usage (at least with the controller
in the ergodox infinity - it may have trouble with some really cheap boards).

Issues with the layer based approach 
- On the ergodox infinity, has a maximum of 32 layers which is not enough for some of the experiments I have wanted to try
- When building layers incrementally or experimenting with changing layouts, changes have to be propogated manually throughout 
all layers and are a bit of a pain

smahood

; Types of Pedestal Routes 

; Example A - Tabular Routes (adapted from pedestal leiningen template
(def routes #{["/"      :get `home-page]
              ["/about" :get `about-page]})

; Example B - table-routes (adapted from http://pedestal.io/reference/table-syntax#_detailed_reference)             
(ns myapp.service
  (:require [io.pedestal.http.route.definition.table :as table]))

smahood

(ns quickstart.core
  (:require [ol.Map]
            [ol.View]
            [ol.proj]
            [ol.layer.Tile]
            [ol.source.OSM]))


(def my-center (ol.proj/fromLonLat #js [37.41 8.82]))

smahood

(ns quickstart.core
  (:require [ol.Map]
            [ol.View]
            [ol.proj]
            [ol.layer.Tile])
  (:import [ol.source.OSM]))


(def my-center (ol.proj/fromLonLat #js [37.41 8.82]))

smahood

(ns quickstart.core
  (:require [ol.Map]
            [ol.View]
            [ol.proj]
            [ol.layer.Tile])
  (:import [ol.source.OSM]))

(def my-center (ol.proj/fromLonLat #js [37.41 8.82]))

(def my-view (ol.View. #js{:center my-center

smahood

;; For every sub that you want to use the db for in the future, return 
;; a map containing the db as well as the return value.
;; Not tested in a real project,  I assume the passed DB will retain the value as it came in to 
;; the function but have not tested that.
;; I also have no idea if this will cause other issues when implemented in a large project

(defn sorted-todos
  [db _]
  {:db db :value "sorted-todos-value"})

smahood

Starting a new project
- My first code is usually written in devcards. I try to stay in the core namespace until I have a reason to extract something out.
- I put each major thought into it's own card and use the docstring at the start to document the basic reasons it is there - at this point
I have not determined the implementation, so this is more about documenting the purpose so that I don't lose sight of it in future 
refactoring
- I will usually split each component of each thought into it's own card, using deftest to start documenting assumptions and eventually
writing tests for each of them. I have never really been into test-driven development, but I've found devcards to be the first environment
where it is something I consider doing. Usually, though, I use the tests to simply document the desired future behaviour and implement 
the useful tests later. Tests that seem extraneous or pointless once I get to an actual implementation of the component are either 
removed completely or left as a record of e