diff --git a/.gitignore b/.gitignore
index 2982cb4..d43dcac 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,4 +6,10 @@ yarn-error.log
/__sapper__/
/.cache/
.vercel
-.env
\ No newline at end of file
+.env
+/build
+/.svelte-kit
+/package
+.env
+.env.*
+!.env.example
\ No newline at end of file
diff --git a/README.md b/README.md
index 7c315d9..94a48f5 100644
--- a/README.md
+++ b/README.md
@@ -1,126 +1,40 @@
-# nikolas.ws
+# create-svelte
-## ToDo Items:
+Everything you need to build a Svelte project, powered by [`create-svelte`](https://github.com/sveltejs/kit/tree/master/packages/create-svelte).
-- [x] Add sitemap.xml
-- [ ] Better Alt texts for all images
-- [x] Metadata and JSON-LD
-- [x] Add RSS feed
-- [x] Migrate remaining images to SmugMug
-- [ ] Write up missing project texts
-- [ ] Cypress tests around nav UI
-- [ ] Cypress tests w. AxE
-- [x] Add bibliography section
-- [x] Add resources section
-- [x] Add Visual Art section
-- [ ] Add music section
-- [x] Add session-based analytics
-- [ ] Syntax highlighting colors
-- [ ] Typeset goodies (small caps?)
+## Creating a project
-
-### Texts
-
-- [ ] transcribe talks with recordings
- - [x] Cartography Symposium (https://vimeo.com/291928620, http://good-maps.nikolas.ws/#1)
- - [ ] PCC Lectures (http://web-mapping.nikolas.ws/#1)
-- [ ] How Why Done Reports
-- [ ] Rebuild: Session Based Tracking
-- [ ] Rebuild: Using Sapper
-- [ ] Design Systems in 2020
-- [x] Ethical Web Development / The Ethical Internet
-- [ ] Setting type: letterpress style
-- [ ] Aperiodic tiling & CSS
- - [ ] https://users.csc.calpoly.edu/~zwood/teaching/csc572/final12/kowen/
-
-### Projects
-
-- [ ] Toba Capital
-- [ ] Hansel from Basel
-- [ ] Evidation
-- [ ] SmugMug
-- [ ] Dicegraph
-- [ ] Department Press Estimator: http://estimator.department.press/
-- [ ] Cooking Papa: cooking-papa.nikolas.ws
-
-## Getting started
-
-### Running the project
+If you're seeing this, you've probably already done this step. Congrats!
```bash
-npm install
-npm run dev
-```
-
-Open up [localhost:3000](http://localhost:3000) and start clicking around.
-
-## Structure
-
-Sapper expects to find two directories in the root of your project — `src` and `static`.
-
-### src
-
-The [src](src) directory contains the entry points for your app — `client.js`, `server.js` and (optionally) a `service-worker.js` — along with a `template.html` file and a `routes` directory.
-
-
-#### src/routes
-
-This is the heart of your Sapper app. There are two kinds of routes — *pages*, and *server routes*.
-
-**Pages** are Svelte components written in `.svelte` files. When a user first visits the application, they will be served a server-rendered version of the route in question, plus some JavaScript that 'hydrates' the page and initialises a client-side router. From that point forward, navigating to other pages is handled entirely on the client for a fast, app-like feel. (Sapper will preload and cache the code for these subsequent pages, so that navigation is instantaneous.)
+# create a new project in the current directory
+npm init svelte@next
-**Server routes** are modules written in `.js` files, that export functions corresponding to HTTP methods. Each function receives Express `request` and `response` objects as arguments, plus a `next` function. This is useful for creating a JSON API, for example.
-
-There are three simple rules for naming the files that define your routes:
-
-* A file called `src/routes/about.svelte` corresponds to the `/about` route. A file called `src/routes/blog/[slug].svelte` corresponds to the `/blog/:slug` route, in which case `params.slug` is available to the route
-* The file `src/routes/index.svelte` (or `src/routes/index.js`) corresponds to the root of your app. `src/routes/about/index.svelte` is treated the same as `src/routes/about.svelte`.
-* Files and directories with a leading underscore do *not* create routes. This allows you to colocate helper modules and components with the routes that depend on them — for example you could have a file called `src/routes/_helpers/datetime.js` and it would *not* create a `/_helpers/datetime` route
-
-### static
-
-The [static](static) directory contains any static assets that should be available. These are served using [sirv](https://github.com/lukeed/sirv).
-
-In your [service-worker.js](src/service-worker.js) file, you can import these as `files` from the generated manifest...
-
-```js
-import { files } from '@sapper/service-worker';
+# create a new project in my-app
+npm init svelte@next my-app
```
-...so that you can cache them (though you can choose not to, for example if you don't want to cache very large files).
-
-### content
-
-Thie folder of markdown files gets parsed into JSON at `src/data` for consumption and rendering by the application.
-
-## Bundler config
+> Note: the `@next` is temporary
-Sapper uses Rollup or webpack to provide code-splitting and dynamic imports, as well as compiling your Svelte components. With webpack, it also provides hot module reloading. As long as you don't do anything daft, you can edit the configuration files to add whatever plugins you'd like.
+## Developing
-## Production mode and deployment
-
-To start a production version of your app, run `npm run build && npm start`. This will disable live reloading, and activate the appropriate bundler plugins.
-
-Deploy explicitly with vercel:
+Once you've created a project and installed dependencies with `npm install` (or `pnpm install` or `yarn`), start a development server:
```bash
-vercel --prod
-```
-
-Or just push to master for the automated CI pipeline.
+npm run dev
-## Using external components
+# or start the server and open the app in a new browser tab
+npm run dev -- --open
+```
-When using Svelte components installed from npm, such as [@sveltejs/svelte-virtual-list](https://github.com/sveltejs/svelte-virtual-list), Svelte needs the original component source (rather than any precompiled JavaScript that ships with the component). This allows the component to be rendered server-side, and also keeps your client-side app smaller.
+## Building
-Because of that, it's essential that the bundler doesn't treat the package as an *external dependency*. You can either modify the `external` option under `server` in [rollup.config.js](rollup.config.js) or the `externals` option in [webpack.config.js](webpack.config.js), or simply install the package to `devDependencies` rather than `dependencies`, which will cause it to get bundled (and therefore compiled) with your app:
+To create a production version of your app:
```bash
-npm install -D @sveltejs/svelte-virtual-list
+npm run build
```
+You can preview the production build with `npm run preview`.
-## Bugs and feedback
-
-Sapper is in early development, and may have the odd rough edge here and there. Please be vocal over on the [Sapper issue tracker](https://github.com/sveltejs/sapper/issues).
-
+> To deploy your app, you may need to install an [adapter](https://kit.svelte.dev/docs/adapters) for your target environment.
diff --git a/content/an-ethical-web-development.md b/content/an-ethical-web-development.md
deleted file mode 100644
index 03ba25c..0000000
--- a/content/an-ethical-web-development.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-title: Towards an Ethical Web Development
-description: Thinking about what it means for an industry to determine a moral standard of practice.
-date: 2020.09.01
-slug: an-ethical-web-development
-type: text, texts
----
-
-
-
-
-
-Since the beginning of this summer, with everything that’s descending upon us with Covid-19 and the Black Lives Matter uprising, it feels like we are living through a moment of moral accounting. In Portland, antifa is in the street in running battles with secret police, exploited workers are speaking up about the realities of our treasured restaurant industry, business owners are shutting down and pulling a disappearing act instead of facing accountability for their behavior. This has me thinking about _my_ industry, which we all know has massive problems around racism, techno-fascism, and robber-baron level exploitation. We’re still dealing with people who read _Snow Crash_ and _Neuromancer_ and think those books were descriptions of Utopias.
-
-There are a lot of people doing hard work right now to address these issues in the industry, working to identify how we can — as businesses — move toward a more just system of working, how we need to avoid baking our prejudices in to the AIs we build, and how the physical underpinning of the internet is built on an exploitative and extractive logic of global capital. This is all good and necessary work. It makes me think though, about if there are distinctions between the craft and practice of web development and the business logic and drive the industry. The industry vs the practice - as in the technical skill of painting vs the economic system of patronage. Clearly they are related, and clearly our conception of painting has always been tied to the economic structures that make it a reality as a profession, but is there a way to think about an Ethical Web Development? It would be tied to running an ethical business, and necessarily need to be supporting by an ethical economic system, but how could we articulate what it would look like the perform the craft and practice of web development ethically? What would an antiracist and antifascist web development practice look like?s
-
-Recently we were visiting my parents in Corvallis, and as it happens my moms partner is [Michal Nelson](https://www.michaelpnelson.com/biography) - a moral philosopher who specializes in ecological and environmental ethics. So I asked him if there were any frameworks for determining if a given industry (his discipline focuses on forestry and resource management for example) was acting “ethically”. How does an industry set its own standard of ethical behavior? He explained that acting “ethically” is essentially just staying internally consistent to a set of values that you’ve articulated — and in this way being “ethical” or “sustainable” doesn’t inherently hold any value. Many people or entities agree on the importance of acting ethically, but their baseline for what the core concepts actually mean, what they are talking about when they mean “harm” for example can vary wildly.
-
-An ethical framework is a tool to reduce the possibility space - to help determine what choices available should be taken rather than could be taken. It creates a heuristic for determining which actions will cultivate an environment that supports a set of desired values. Determining ethical considerations becomes a design problem — what values do we want to see in the world? What outcomes do we want and why? Who are we considering, who are we not considering? What are the edges and the limitations beyond which we decide not to concern ourselves?
-
-There are many ethics available to work from, and conflating a single ethic with the entire range of possible ethics can be a problem. If we assume that a utilitarian, individualist ethic is the _only_ possible ethic we can work with (cough cough economics cough cough) it will necessarily preclude a whole range of outcomes that just aren’t possible to arrive at from those starting conditions. Another ethic based on compassion, animism, and collectivism would start with wildly different axioms and naturally arrive at different outcomes. This debate and tension is at play _today_ among the people who study and try and outline what a sustainable future of forest management is - it’s an ongoing conversation (argument?) between people who don’t share the same basic axioms around what they are trying to talk about.
-
-Perhaps the core of any ethic is “harm reduction”. We can see this in the Hippocratic oath and the medical ethic — first do no harm. The issue is that “harm” is not a natural, discoverable property of the natural world. Harm is necessarily framed as a value judgment, the corollary to the idea of "good in the expanded field". We can outline the structural requirements and definitions of harm, and use those value judgments to identify harm in the world, but it’s still a human judgement system being used to sort and order the world. The medical world to illustrate this, we can look at the contemporary prerogative of “informed consent”. We now define lack agency over medical decisions as a harm done to an individual. This has not always been the case.
-
-This starts to get at the ecological connections between the craft and the business and web development - we can easily frame accessibility as a fundamental requirement of an ethical web development practice in that it reduces the harm of excluding individuals from our work. But we can arrive at that principle from the logic of many different ethics, some of which could be wildly contradictory. From a utilitarian, efficiency and profit maximizing ethic, creating accessible web apps is ethical because not doing so would be to leave money on the table. From a humanistic and compassionate ethic, it’s accessible because it fosters inclusion and equity. So we see accessibility and a clearly defined ethical practice, but that doesn’t mean that we all agree on _why_ accessibility is ethical.
-
-I think in order for us to define what we mean when we try and define how our industry can be ethical, we need to work through a few steps:
-
-1. What values do we want to encourage and foster in the environment?
-2. Where do we draw the distinction between things we are concerned with and things we are not?
-3. How do we determine who is effected by our ethic and who is not?
-4. How do we then define the rules for determine which actions we should take and which actions we should not take?
-
-If, as an industry and as individuals, we can have these conversations then we can start to come to terms with what it means to work every day in a world where we are actively supporting and enriching the worlds first trillionaire. Is an ethical web development one where we must boycott AWS? How do we feel about data centers in general? What about ISPs, what about underwater cables?
-
-[Jaya Saxena's recent piece in Eater](https://www.eater.com/21398969/future-co-op-worker-owned-restaurants-ethical-business) clearly identifies the problems associated with acting ethically as an individual — or even an industry — while remaining a part of a society that systemically undermines that ethic through structural design.
-
-> Building an equitable restaurant, a place where all workers are paid fairly, have benefits, and can work in an anti-discriminatory environment, is going to take a near-undoing of the way most restaurants are run.
-
-Saxena examines some current models for employee-owned and cooperative businesses, and privately owned business that actively choose equality and community over profit. She identifies that is a compromise in these enterprises, and sums up the system issues at hand by concussing that "… when it comes to restaurants, it’s hard to change one thing unless you’re changing everything."
-
-There are systemic forces at work that prevent any individual, or even any small community from truly reaching a place of ethical behavior. This makes me think that there has to be a split between "acting ethically" and "being ethical". We can all act ethically, working our way upstream against the system forces arrayed against us, but that's no guarantee that we will, at the end of the day, be ethical.
-
-The essay identifies one restaurant and farm that solves their ethical crisis by charing $195 per person per meal, and frames that as a choice that _consumers_ get to make. This is striking. We live in a time of unprecedented efficiency, unbelievable abundance, and massive wealth but if a _restaurant_ is called to truly account for its exploitation to charge its true price, it's immediately untenable. This feels like it must be true across many industries – Uber would rather cease service in California than treat it's drivers like employees. What would it take to truly understand what the network of costs, values, debts, and the real price of things?
-
-Would an ethical web development be able to account for that cost and still be able to be a business in our society? During my early courses in fine art printmaking at University, I was taught that a blank sheet of paper had value on its own. Not only the price attached to it (steep, for nice paper) but also the work and craft that went in to making it. One had to be sure that the image we we're impressing on the blank sheet of paper added value to it that than reduced it. Our work had to be more valuable than the paper, and if it wasn't we didn't make it.
-
-[Ingrid Burrington](http://lifewinning.com/tag/writes/) has written extensively about the physical realities of the internet, and what it means to turn the raw stuff of the earth into the objects we need to make computers. She's even turned computers back into [raw stuff](https://twitter.com/lifewinning/status/1049653649562132482). It's hard to confront the reality of an open pit lithium mine and conclude that needs must for better batteries.
-
-Can web development be ethical? Maybe not. But that doesn't mean that we don't have an obligation to act ethically. If we can articulate the ethic we want to have in our industry, and stay internally consistent to those principles in an effort to manifest values we want in the world, maybe that's enough. Or a start anyway.
-
-
-
diff --git a/content/arcgis-for-developers.md b/content/arcgis-for-developers.md
deleted file mode 100644
index 964142b..0000000
--- a/content/arcgis-for-developers.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: ArcGIS for Developers
-slug: arcgis-for-developers
-date: 2015.10.31
-site: https://developers.arcgis.com/
-description: A fully developer-facing experience for the ArcGIS Platform, including marketing messaging, documentation, platform management, and online tools to enable a a developer to get the most out of the ArcGIS platform.
-type: projects, esri
----
-
-
-
-
-
-
-
-
-
-
diff --git a/content/arcgis-online.md b/content/arcgis-online.md
deleted file mode 100644
index 02b04c5..0000000
--- a/content/arcgis-online.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: ArcGIS Online
-date: 2015.10.31
-slug: arcgis-online
-site: https://www.arcgis.com/
-description: Designing, prototyping, and developing the web platform for the worlds leading GIS software.
-type: projects, esri
----
-
-
-
-
-
-
\ No newline at end of file
diff --git a/content/at-the-mountains-of-madness.md b/content/at-the-mountains-of-madness.md
deleted file mode 100644
index 90a8c31..0000000
--- a/content/at-the-mountains-of-madness.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: At the Mountains of Madness
-site: http://miskatonic.nikolas.ws/
-date: 2014-06-21
-description: An exercise in digital publishing, this edition of _At the Mountains of Madness_ by H.P. Lovecraft is a free, open, public domain text. Created as a high-end, web-native publication in response to a personal desire the read the text online, and being unable to find a version that did the original physical publication any justice.
-type: projects, department
-archived: true
----
-
-
-
-
-
-
-
-
-
-
-
-
\ No newline at end of file
diff --git a/content/axioms.md b/content/axioms.md
deleted file mode 100644
index cf219f2..0000000
--- a/content/axioms.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: Axioms
-date: 2013-5-20
-description: Bachelor of Fine Arts in Printmaking thesis. An exploration of examining the experiences and memories of the built city through print, collage, and drawing.
-type: art, printmaking
-archived: true
----
-
-
-Carceral Armature, Lithograph, Magnetic Tape, 2012
-
-I am interested in exploring the connection between personal identity and external environment, specifically focusing on urban density. I am engaged with the idea that as we navigate our environment, we create an internal model — a mental map of our surroundings and our place within those surroundings. This internal model may or may not accurately reflect the external world. The connections and contradictions that occur when these two environments collide create definition of personal identity. If identities are shaped by cities, cities are shaped by collected identities. This is an intangible and emergent property rising from the imaginations of an entire cities inhabitants. In this fluid exchange, cities become organisms.
-
-
-
-Carceral Armature, Detail
-
-The "hard" city of infrastructure and physical space creates the framework that the "soft" city of emotion, recollection, and assumption rests on. Urban structure and culture parallels the interactive relationship between human mind and body. Urban growth creates a feedback loop where change in individuals creates change in city, which effects further change in individuals. Our actions weigh on the city, but by inhabiting it we are irrevocably influenced.
-
-
-
-All Cities Are Built Twice, Etching, Tusche Wash, 2012
-
-
-All Cities Are Built Twice, Detail
-
-In the language of mechanical reproduction, this work uses printmaking as its primary medium in order to create densities of visual texture, and comment on a world of analog and digital reproduction. Print allows some degree of non-linear process. Through the use of the multiple, stage proofing, and the technique of chine-collé, I am able to create an image that layers over itself at different stages of time. This collapsing of image is present in all the work, sometimes being composited, sliced apart, and re-composited until the original is entirely removed and a new image exists over its deconstructed framework. Each piece is based upon a single system of relationships and gridded framework co-opted from a typographic practice, reflecting the hard infrastructures of construction and communication that contemporary society is built on. Writing systems are a central component of my work in that they allow an individual to create a permanent mark of their thoughts on the environment. Writing is a direct externalization of identity. Through abstraction of city form and iconography, I seek to reflect the abstract forces that fundamentally guide our globalized world.
-
-
-An Exact Replica of a Thing that Never Existed, Etching, Silkscreen, 2012
-
-
-An Exact Replica of a Thing that Never Existed, Detail
-
-I am focusing on the blurred distinction between human geography and physical geography as it comments on post-modern urbanism, issues of sprawl and lack of specificity and physical place in a post-geographic, globalized system of living on a human level. I examine the connections to local environment and context within the global city. With these prints, I seek to examine the current relevancy of both physical and informational infrastructures, from highways to the internet, shipping lines to global markets, built environments to typographic systems, in defining place and self.
-
-
-The Capacities of the Human Body to Locate Itself, Etching, Giclee, 2012
-
-
-The Capacities of the Human Body to Locate Itself, Detail
-
-#### Bibliography
-
-##### Gibson, William. “Dead Man Sings”, _Distrust That Particular Flavor_. New York: Putnam Group, 2012
-
-A short essay discussing the unnoticed shift that human life took when analog, and later digital, media started to elongate our collective memories. Interesting discussion of what effect locating identities and human narratives outside of our head, or oral traditions, can have on a society.
-
-##### Gibson, William. _Pattern Recognition_. New York: Berkley Publishing Group, 2003
-
-Gibson’s seventh novel. A densely layered quasi-narrative dealing with problems of geographic specificity, globalized fashion trends and trade, the power of corporations in the realm of cultural influence, and the capabilities of pareidolia and obsession.
-
-##### Calvino, Italo. _Invisible Cities_. Orlando: Harcourt, 1974
-
-Calvino describes cities are as they felt and lived in experientially rather than descriptively or objectively. He raises issues of mirroring, reflecting, and the relationships between person and place. As he dissects and lays bare a single city, questions of semantic reasoning and possibilities of communication are raised.
-
-##### Dear, Michael, Flusty, Steven. "Postmodern Urbanism." _Annals of the Association of American Geographers_, Vol. 88, No. 1 (Mar., 1998), pp. 50-72
-
-Dear and Flusty set out to describe how the modernist Chicago School theory of urbanism does not hold with post-modern geographies, in particular Los Angeles. They describe the city structure of Los Angeles in relation to landscape opportunities and necessities, population demographics, and market pressures of late-stage capitalism. They go on to describe how the physical regions of the post-modern city are indicative of social structures, and how these hierarchies either enforce or subvert cultural patterns. They forecast a city with the post-modern structures of Los Angeles taken to dystopian extremes.
\ No newline at end of file
diff --git a/content/boring-deisgn-systems.md b/content/boring-deisgn-systems.md
deleted file mode 100644
index 667b46c..0000000
--- a/content/boring-deisgn-systems.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: The Most Exciting Design Systems Are Boring
-author: Josh Clarg
-slug: the-most-exciting-design-systems-are-boring
-year: 2017
-source: https://bigmedium.com/ideas/boring-design-systems.html
-thesis: What it says on the tin.
-tags: design systems, design/development
-type: annotation, bibliography
----
-
-> Design-system builders should resist the lure of the new. Don’t confuse design-system work with a rebrand or a tech-stack overhaul. The system’s design patterns should be familiar, even boring.
-
-> The job is not to invent, but to curate.
-
-When building a design system, the primary job is in working with what's already existing rather than starting from scratch and greenfielding everything.
\ No newline at end of file
diff --git a/content/building-a-client-library.md b/content/building-a-client-library.md
deleted file mode 100644
index 6838a29..0000000
--- a/content/building-a-client-library.md
+++ /dev/null
@@ -1,192 +0,0 @@
----
-title: Building a Client Library for ArcGIS
-slug: building-a-client-library
-date: 2015.3.09
-description: Writing a wrapper client library to smooth out design weirdness at the API level leads to plenty of design thinking on the way things should be.
-type: text, texts
----
-
-This year I built a JavaScript wrapper for Node and the Browser around the ArcGIS REST API to simplify working with that platform as a developer. This was as an exercise in API design, as well as making a tool that I wanted to use but didn't exist yet. The project is a bare-bones library to ease interactions with the ArcGIS REST API in JavaScript and Node apps.
-
-Sometimes – and for sure in this case – an API can be rough, built over time, and not provide the sort of logical models that work well with specific language environments. This was the case with the ArcGIS REST API that I was running in to. A lot of the decisions had been made over the course of years, and didn't translate very smoothly a language as young as Node.js.
-
-The first step was to figure out what problems I wanted to solve. A lot of my work with Esri PDX has been about content handling, and so this is where I started. Reading _all_ the doc to get a big picture of what's going on with the API, and talk to everyone who's done work like this before to figure out what problems *they* needed to solve was the first step. From there I felt I had enough context and information to make the thing useful for more people than just me, and make sure that it was coherent with the underlying goals of the original API.
-
-This project works to simplify and unify the gap between the ArcGIS REST API and a contemporary Node application. This library is a UI in the most basic sense of the term — it provides an interface between the developer and the servers. That interface needs to be well designed and thoughtful in order to make the process as smooth, intuitive, and pleasurable as possible.
-
-One of the most important parts of the project is to provide developers with a way to access the ArcGIS platform without needing to architect their entire application around opinionated frameworks (like Dojo, for example). Though the library itself is written in ES6, it's distributed as plain, normal ES5 – both as a node package and a packaged bundle. This means it works both in Node and the browser, and has very few opinions on how it integrates with the rest of your app.
-
-Right now, the library wraps most of the basic platform content management and interactions - getting and editing users, organizations, and items. The Node ArcGIS Client Library is an open source project — so it's scope will increase as the community works to accomplish more goals and workflows.
-
-## Setting up the client
-
-The first step in using the library is initializing the client with your target portal.
-
-```
-var ArcGIS = require('arcgis')
-var arcgis = ArcGIS()
-```
-
-This sets up a default object for interacting with the API. This default is going to talk to ArcGIS Online as an anonymous, unauthenticated user. One can authenticate this client session as a named user by passing in a user token obtained from a successful OAuth login process.
-
-```
-var arcgis = Arcgis({
- token: namedUserToken
-})
-```
-
-This isn't exclusive to ArcGIS Online. The API for interacting with your organization's installation of Portal or Server is the same. Setting up the client session with your instance is done by specifying your API domain.
-
-```
-var arcgis = Arcgis({
- domain: 'ago.my-server.com',
- token: namedUserToken
-})
-```
-
-Beyond the initialization of the client, the library is exclusively async. All the functions return promises by default.
-
-```
-function log (m) {
- console.log(m)
-}
-function ohNo (err) {
- return new Error(err)
-}
-arcgis.request()
-.then(log)
-.catch(ohNo)
-```
-
-You can also pass in a node-style callback, if you'd prefer.
-
-```
-function log (err, results) {
- if (err) {
- return new Error(err)
- } else {
- console.log(results)
- }
-}
-arcgis.request({}, log)
-```
-
-Both methods work just as well, and use all the same business logic. I like promises, but maybe you don't. This is one of the main reasons the library does its best to avoid inflicting my opinions on your codebase.
-
-Once we have an authenticated session, we can do all sorts of stuff — like figure out who we are:
-
-```
-function hello (user) {
- console.log('Hello, ' + user.firstName)
-}
-arcgis.user('NikolasWise').then(hello)
-```
-
-We can get all of the items that user has in the platform:
-
-```
-function getContent (user) {
- return user.content()
-}
-function logContent (content) {
- console.log(content)
-}
-arcgis.user('NikolasWise')
-.then(getContent)
-.then(logContent)
-```
-
-Or a list of all the groups that a user is a member of.
-
-```
-function logGroups (item) {
- item.groups.forEach(function (group) {
- console.log(group.title)
- })
-}
-arcgis.user('NikolasWise').then(logGroups)
-```
-
-The library also can interact with the user's organization, returning information, members, or all the content associated with the organization.
-
-```
-function logOrg (org) {
- console.log(org)
-}
-arcgis.organization('esripdx').then(logOrg)
-```
-
-The organization call defaults to 'self' — whatever organization the current user is a member of.
-
-```
-function getMembers (org) {
- return org.members()
-}
-function log (members) {
- console.log(members)
-}
-arcgis.organization().then(getMembers).then(log)
-```
-
-Many of the content calls are abstractions or helper methods for longer, more complicated calls to the `search` endpoint.
-
-```
-function getContent (org) {
- return org.content()
-}
-function log (items) {
- console.log(items)
-}
-arcgis.organization().then(getContent).then(log)
-```
-
-In this way we are able to create a transitional layer between the API itself (a super complicated call to the search endpoint) and what application developers need (all my organization's content).
-
-## Working with content
-
-Platform content is the weakest link in the library as of today. ArcGIS supports a huge range of item types, and quite a number of sophisticated things you can do with those item types. For now the basics are more or less in place — like getting an item's details:
-
-```
-var layerID = 'a5e5e5ac3cfc44dfa8e90b92cd7289fb'
-function logItem (item) {
- console.log(item)
-}
-arcgis.item(layerID).then(logItem)
-```
-
-Or updating the those details and editing the permissions:
-
-```
-var layerId = 'a5e5e5ac3cfc44dfa8e90b92cd7289fb'
-function updateItem (item) {
- return item.update({
- snippet: 'Building footprints in my neighborhood in Portland, Oregon'
- })
-}
-function shareItem (item) {
- console.log(item)
- return item.permissions({
- access: 'public'
- })
-}
-arcgis.item(layerId)
-.then(updateItem)
-.then(shareItem)
-```
-
-So far, there's some support for item-type-specific methods that are starting to open up the possibilities of manipulating your content from Node — like getting all the data in a layer.
-
-```
-var layerID = 'a5e5e5ac3cfc44dfa8e90b92cd7289fb'
-function getData (item) {
- return item.data()
-}
-function logData (data) {
- console.log(data)
-}
-arcgis.item(layerId)
-.then(getData)
-.then(logData)
-```
-
-There is a lot more of the platform that we could cover than this - services, analysis, layer creation and tile publishing all are actions that this library or ones like it could cover.
\ No newline at end of file
diff --git a/content/calcite-web.md b/content/calcite-web.md
deleted file mode 100644
index f97f6df..0000000
--- a/content/calcite-web.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: Calcite Web
-slug: calcite-web
-site: http://esri.github.io/calcite-web
-date: 2015.11.25
-description: A framework that addresses common design problems and interactive elements for Esri, creating a united visual language and user experience.
-type: projects, esri
----
-
-
-
-## Design System, Development Framework
-
-[Esri](http://www.esri.com/about-esri) is a large, international technology company with development teams all over the world — from Portland to Glasgow to Zurich to Beijing. Esri's _design_ team however, is based in the Redlands, California mother-ship. This meant that a lot of the design tools created for Esri's web presence were unevenly distributed across the huge number of teams who needed to develop web properties.
-
-At [Esri PDX R&D](http://pdx.esri.com/) we had [assembled](http://paulcpederson.com/) a [strong](http://patrickarlt.com/) [team](http://ungoldman.com/) of designer/developers. We sat down to create a design system that we could distribute to _all_ of Esri's development teams, with the goal of creating a unified user experience for all our customers, and keeping all of our properties aligned and in sync as we moved forward.
-
-
-
-## Goals
-
-Building a design library and CSS framework can be a complicated affair, made more complicated by the large audience of developers we had to make the project work for.
-
-**Adoption:** We had to make the framework incredibly attractive to Esri developers, and incredible easy for them to use. Our main goal was unification, so any barriers to adoption needed to be removed.
-
-**Composabillity:** To this end, we needed using the framework to be as simple is including a CSS file and copy-pasting code samples.
-
-**Modularity:** Many of the projects at Esri have rigid, preexisting code bases and technologies that we needed to integrate smoothly with — we needed to provide a system that works in whatever tech stack it finds itself in.
-
-**No Opinions:** We wanted the framework to provide a full set of interactive patterns — requiring JavaScript — but also work in any JavaScript framework environment.
-
-**Robust:** Certain aspects of the framework — like [the grid system](/projects/viewport-grid) had major functional requirements. The grid itself needed to be column based, fully responsive by default, and work down to IE 8.
-
-**Flexible:** Developers needed to have access to a wide range of patterns, ensuring that common structures didn't get independently invented in different projects. Designers needed to have the freedom to create on-off pages that stood out without feeling constricted.
-
-
-
-## Using Sass
-
-Sass — through the [Node Sass project](https://github.com/sass/node-sass) allowed us to meet many of our goals. A major theoretical underpinning to the framework's .SCSS involved making the specificity graph as flat as possible, and decoupling style code from selectors. This allows the design code to be reused and adapted basically anywhere in any given project.
-
-```
-@mixin tab-contents() {
- @include box-sizing(border-box);
- border: 1px solid $lighter-gray;
- margin-top: -1px;
-}
-@if $include-tabs == true {
- .tab-section { @include tab-section(); }
-}
-```
-
-The CSS development principles are outlined in [an excellent article (and Esri User Conference presentation) by Paul Pederson.](http://paulcpederson.com/articles/css-for-people-who-hate-css/)
-
-## JavaScript, or Not
-
-All of our interactive patterns require a `.js-` prefix hook to bind JS events too. This lets projects using [Angular](https://angularjs.org/) or [React](https://facebook.github.io/react/) to write their own component code for the interactions while still getting all the canonical design code for a pattern.
-
-
-
-The JS portion of the framework uses Publication / Subscription event bus to connect user intent and component behavior. This allows for programmatic control of the UI, and lets a pattern communicate to the rest of the application. The JavaScript library is written as a set of ES6 modules, and is compiled to an ES5 UMD module, attaching itself to the `window` on load.
-
-
-
-## The Brand
-
-Color and Typography do most of the heavy lifting when communicated brand identity on the Web. We developed a gray scale, and selected a limited set of colors from the immense set of [Esri's color pallete](https://github.com/Esri/calcite-colors) to expose as simple color classes and variables. We updated the typography to Avenir NExt by Adrian Frutiger and Akira Kobayashi to give Esri's classic Avenir print style a boost that it needed for screen display.
-
-
-
-## Conclusion
-
-The framework as been very successful so far — being integrated into new designs for esri.com, new sections of [ArcGIS Online](http://www.arcgis.com/home/item.html?id=52bdc7ab7fb044d98add148764eaa30a), and a number of [related ArcGIS properties](https://developers.arcgis.com/).
diff --git a/content/clean-start-for-the-web.md b/content/clean-start-for-the-web.md
deleted file mode 100644
index db53962..0000000
--- a/content/clean-start-for-the-web.md
+++ /dev/null
@@ -1,104 +0,0 @@
----
-title: A Clean Start for the Web
-slug: a-clean-start-for-the-web
-thesis: How do we make the web fun, participatory, and good?
-source: https://macwright.com/2020/08/22/clean-starts-for-the-web.html
-author: Tom Macwright
-year: 2020
-tags: internet, web
-type: annotation, bibliography
----
-
-> The web’s evolution over the last decade has mirrored the American economy. All of the essential indicators are going “up and to the right,” a steady stream of fundamental advances reassure use that there “is progress,” but the actual experience and effects for individuals stagnates or regresses.
-
-tmcw is approaching the contemporary problem of technical debt, the result when our system is so complex and fucked that it's starting to collapse and there's nothing we can do about.
-
-> The platform side is what changed last week, when Mozilla laid off 250 employees and indicated that it would affect Firefox development … The real winner is not just Chrome, but Chrome’s engine. One codebase, KHTML, split into WebKit (Safari), and Blink (Chrome, Microsoft Edge, Opera, etc.)
-
-> This a textbook monoculture. In one sense, it’s a victory for collaboration because nobody’s ‘wasting time’ on competing implementations and web developers can expect the same features and bugs across different browsers. But in a deeper way, it threatens one of the basic principles of how the web has evolved.
-
-Tmcw identifies that our browsers our now a monoculture, which is an interesting problem to have because 1) there are some clear indications that a monoculture by technical behemoths is _bad_ but it's only an interesting because 2) browsers should just be all implementing the spec anyway. The _spec_ is an interesting problem, since _it also_ is just a monoculture dominated by technical behemoths.
-
-> Organizations like the WHATWG, W3C, and IETF have been collaboration spaces for independent developers, corporations, and academics to discuss potential new features of the web.
-
-At least the spec pretends or tries to be open and community oriented.
-
-> Chrome has been moving extremely fast, adding new specifications and ideas at a startling rate, and it’s becoming one of the hardest pieces of software to replicate.
-
-The problem is that Google dominates the spec, and is gaining monopoly on the _spec_.
-
-> Not only is it nearly impossible to build a new browser from scratch, once you have one the ongoing cost of keeping up with standards requires a full team of experts.
-
-This is probably the point and the goal of the hostile takeover of the spec. The creation of a platform that becomes a monopoly on a market is a hallmark tech company business model.
-
-> The web has had about 25 years to grow, few opportunities to shrink, and is now surrounded by an extremely short-sighted culture that is an outgrowth of economic and career short-termism.
-
-Haha, Im not sure I have any insight here but its funny
-
-> For folks who just want to create a web page, who don’t want to enter an industry, there’s a baffling array of techniques, but all the simplest, probably-best ones are stigmatized. It’s easier to stumble into building your resume in React with GraphQL than it is to type some HTML in Notepad.
-
-Tmcw identifies that there is a problem for creators in that making web shit is outlandishly difficult.
-
-> The end result is that I no longer expect pages to be fast, even with uBlock installed in Firefox and a good local fiber internet provider.
-
-Tmcw indentifies that there is a problem for consumers in that our technical debt has resulted in a horrible experience.
-
-> I don’t want to lay all of the blame at those web developers … Segment offered a big page of on/off switches with hundreds of data providers & ad-tech companies on it. And, sure, enough, some folks closer to the business side started clicking all those buttons.
-
-This is an interesting way of throwing the business team under the bus for making choices that are obvious to them and removing our own culpability in building these systems.
-
-> How do we make the web fun, participatory, and good?
-
-There is Tmcw's thesis: which obviously has a ton of value judgment wrapped up in it.
-
-> the current web which has basically thrown away semantic HTML as an idea.
-
-Is that true or is that just a dig at the current dominant process and system?
-
-> Then there’s the “application web”. This started as server applications…
-
-We've seen Tmcw dig at the front-end space before.
-
-> The problem is that the “document web” is often plagued by application characteristics - it’s the JavaScript and animations and complexity that makes your average newspaper website an unmitigated disaster. Where document websites adopt application patterns they often accidentally sacrifice accessibility, performance, and machine readability.
-
-I feel this is classic Tmcw "get off my lawn" crankiness. Rich Harris addresses this: `It's a spectrum, and the interesting stuff happens in the middle. There's magic in that grey area. I still believe the web has the potential to be a fundamentally more expressive medium than its predecessors (http://worrydream.com/MediaForThinkingTheUnthinkable/ is on a similar wavelength to that notion)`
-
-> The application web uses JSX, not HTML, and would like that in the browser itself, or Svelte, instead of JavaScript, and would like that too.
-
-Haha our boy is coming for Rich! I'm not I understand what the dig here is … he's mad at a language that has a compile step? Isn't that what like … most applications use? Rust, C, whatever, they all compile down to a native runtime language.
-
-> When I read blog posts from ‘traditional web developers’ who are mad that HTML & CSS aren’t enough anymore and that everything is complicated – I think this is largely that the application stack for building websites has replaced the document stack in a lot of places.
-
-I mean, that's a decent point. The problem is that we've created a disconnect between what we want to build, why we won't to build it, and how we build it. We use insane toolchains to solve simple problems, and not all tools are for the same thing.
-
-> The appeal of social networks is partly because they let us create documents without thinking about web technology, and they provide guarantees around performance, accessibility, and polish that otherwise would take up our time.
-
-This seems like a decent point well made. Those of us who want to reduce tech behemoth monoculture absolutely need to reckon with the real value that social networks offer to users.
-
-> standards like RSS and services like Instapaper show that pleasing formatting and distribution can be done at the platform level and be provided on top of existing vanilla websites.
-
-Thats a decent proof of concept the problem, as illustrated above, is around the tools and systems we've built for ourselves to make things "easier".
-
-> Okay, so let’s say we’re creating a new document web … First, you need a minimal, standardized markup language for sending documents around. … Then, you need a browser … Could you build a pure-Markdown-browsing browser that goes straight through this pipeline? Maybe?
-
-This is a pretty interesting idea, but sounds like it's absolutely a subset of the current system which is railed against above. Maybe the idea is that it can grow independently _from_ being a subset _to_ being something more.
-
-> The problem with imagining the application web is that it’s pretty expansive.
-
-Yeah no shit tmcw. Im not sure how any of this gets around the problem outlined above: hostile takeover of a public spec by private tech behemoths.
-
-> The worse the ‘Mac App Store’ and ‘Windows App Store’ and ’App Store’ and ’Play Store’ get, the bigger a cut those monopolies demand, the more it costs to be a Mac or Windows developer, the more that applications get pushed to the web. Sure, some applications are better on the web. But a lot are just there because it’s the only place left where you can easily, cheaply, and freely share or sell a product.
-
-Creating an "App Web" could so easily just colonize that space with those same models of monoculture.
-
-> There are a lot of other ways to look at and solve this problem. I think it is a problem, for everyone except Google.
-
-Right, this is the goal for Google. And creating a new set of specs is not going to _solve_ that problem, because that problem is a reflection of our current society and what we value and how we work.
-
-> The idea of a web browser being something we can comprehend, of a web page being something that more people can make, feels exciting to me.
-
-This is a good goal, and I endorse it! Our medium tho is that of the technical monoculture, the baked in assumptions that a small group has used to create this new world. The issue is with the hardware and the physical things and the human society that surrounds and makes those things possible.
-
-> What if we could start over?
-
-Tmcw is calling for a revolution of the web without being so explicit about it. The idea he is presenting is that there needs to be a messy, democratic, socialist approach to our _specs_ that create more room for the individual, and that in empowering the individual with rights also creates a number of responsibilities to the society that they must uphold. This is a socialist argument for the web, and I wholly agree with it. I think that he needs to be explicit about what he's actually calling for and imagine what the real world repercussions of the position would be, and how we need to make the same call of our society for the same ends.
\ No newline at end of file
diff --git a/content/coffee-time.md b/content/coffee-time.md
deleted file mode 100644
index a335416..0000000
--- a/content/coffee-time.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: Coffee Time
-site: http://coffeetime.io/
-date: 2014-04-24
-description: An Android and iOS app designed to manage intra-office coffee debt. Designed the app itself and the accompanying website with Paul Pederson. API and back-end by the wonderful team at Esri PDX.
-type: projects, esri
-archived: true
----
-
-
-
-
-
-
-
-
diff --git a/content/design-systems-agile-and-industrialization.md b/content/design-systems-agile-and-industrialization.md
deleted file mode 100644
index 8d581c1..0000000
--- a/content/design-systems-agile-and-industrialization.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: Design Systems, Agile, and Industrialization
-slug: design-systems-agile-and-industrialization
-author: Brad Frost
-year: 2020
-source: https://bradfrost.com/blog/post/design-systems-agile-and-industrialization/
-thesis: Design systems are reflections of organizational processes.
-tags: design systems, design/development
-type: annotation, bibliography
----
-
-> There’s a big difference between having smart, reusable patterns at your disposal and creating a dictatorial culture designed to enforce conformity and swat down anyone coloring outside the lines.
-
-Frost is responding to the concert that design systems can enforce a Taylorist dehumanization of our work, but that they only do this as a reflection of existing organizational principles.
-
-Working with other leaders in the design systems world, Frost suggests that design systems should be boring – that is they should primarily focus on the parts of the process that are foundational and allow of the team to do spend time on the interesting problems.
-
-> Not having to reinvent things from scratch every time you need something is generally a good idea.
-
-The work that we do under the system of 'Agile' is part of the organization structure that pushes for Taylorized dehumanization of web development. Our systems that we build have the ability to either support individual expression and humanity, or to suppress it. The difference between these outcomes is the broader system underlying our approaches to work.
diff --git a/content/eastfork.md b/content/eastfork.md
deleted file mode 100644
index 794f52a..0000000
--- a/content/eastfork.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: East Fork Pottery
-slug: eastfork-pottery
-date: 2018.06.25
-site: https://eastforkpottery.com
-description: Pushing the Shopify platform to its limits to create a smooth and playful experience.
-type: projects, fuzzco
----
-
-Alex & Connie Mattisse run Eastfork Pottery out of Asheville, NC. They both have a strong design sense, and a clear understanding of their brands identity and point of view.
-
-This meant that the challenges of this project centered around pushing Shopify towards a more contemporary client-side user experience, including lazy-loading grid items and smooth client-side page transitions.
-
-
-
-The project had a strong editorial design aspect, simple layout with strong typography and photography.
-
-
-
-The catalog view used a staggered grid that repeated every 15 items. This meant I needed to request paginated sets of items in multiples of 15, then repeat the layout within the pages.
-
-
-
-A quick shopping modal from the catalog view allows for browsing and adding items to the cart without going back and forth to individual item pages. The color option swatches swap the active image for quickly previewing the many colorways.
-
-
-
-The product detail pages needed to carry the editorial feel, and allow for the voice to exist for products.
-
-[TK] The registry
-
-[TK] The animated logo goodness.
-
-
-
-The UX for the cart needed to avoid the standard form submission for updating the cart contents. Abstracting the cart interactions into an API that can be called by use actions on the DOM was critical – and allowed us to have natural update methods tied directly to input interactions.
-
-[TK] The quiz thingy, and the need to add arbitrary data to the cart that gets carried through to the packing manager.
-
-[TK] The add a gift card bit
-
-
-
-Another interesting design moment was the image treatment on the long-form content pages. Each page as a unique colorway in reference to the season glazes (configurable for each section from the Shopify Admin interface), and the images are a gray-scaled and multiplied over the background color. On hover, the image transitions to a full-color treatment. Animating the transition between these sates is tricky – CSS blend modes cannot be transitioned as they are binary states. The effect is achieved by having _two_ images, one with the multiply & grayscale, and one full-color but transparent positioned above it. On hover, the opacity of the top image is transitioned, providing the desired effect.
\ No newline at end of file
diff --git a/content/empty-room-i.md b/content/empty-room-i.md
deleted file mode 100644
index 2aa407d..0000000
--- a/content/empty-room-i.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: An Empty Room I
-slug: empty-room-i
-source: https://photos.smugmug.com/Prints/Prints/i-ZTNJTLf/0/7af009e0/XL/empty-room-1-800-XL.png
-alt: Black and white Risograph with halftone dots depecting an empty room, looking through an archway to a door.
-description: One layer Risograph on Stonehenge Cream \#110
-date: 2017.01.01
-edition: 10
-size: 5x5 inches.
-media: Risograph
-type: art, risograph, edition
----
\ No newline at end of file
diff --git a/content/empty-room-ii.md b/content/empty-room-ii.md
deleted file mode 100644
index 0e84bbc..0000000
--- a/content/empty-room-ii.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: An Empty Room II
-slug: empty-room-ii
-source: https://photos.smugmug.com/Prints/Prints/i-swpfRT6/0/afe88f66/XL/empty-room-2-800-XL.png
-alt: Black and white Risograph with halftone dots, looking down a hallway into a kitchen with a diamond floor pattern.
-description: One layer Risograph on Stonehenge Cream \#110
-date: 2017.01.02
-edition: 10
-size: 5x5 inches.
-media: Risograph
-type: art, risograph, edition
----
\ No newline at end of file
diff --git a/content/empty-room-iii.md b/content/empty-room-iii.md
deleted file mode 100644
index f89a328..0000000
--- a/content/empty-room-iii.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: An Empty Room III
-slug: empty-room-iii
-source: https://photos.smugmug.com/Prints/Prints/i-ZJ5zFbh/0/00bd2583/XL/empty-room-3-800-XL.png
-alt: Black and white Risograph with halftone dots depecting an empty room with an old telephone next to a closet.
-description: One layer Risograph on Stonehenge Cream \#110
-date: 2017.01.03
-edition: 10
-size: 5x5 inches.
-media: Risograph
-type: art, risograph, edition
----
\ No newline at end of file
diff --git a/content/empty-room-iv.md b/content/empty-room-iv.md
deleted file mode 100644
index 7b14237..0000000
--- a/content/empty-room-iv.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: An Empty Room IV
-slug: empty-room-iv
-source: https://photos.smugmug.com/Prints/Prints/i-qxW2n3g/0/eaedebbd/XL/empty-room-4-800-XL.png
-alt: Black and white Risograph with halftone dots depecting an empty room, a radiator by a doorframe.
-description: One layer Risograph on Stonehenge Cream \#110
-date: 2017.01.04
-edition: 10
-size: 5x5 inches.
-media: Risograph
-type: art, risograph, edition
----
\ No newline at end of file
diff --git a/content/empty-room-v.md b/content/empty-room-v.md
deleted file mode 100644
index 88cc1fc..0000000
--- a/content/empty-room-v.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: An Empty Room V
-slug: empty-room-v
-source: https://photos.smugmug.com/Prints/Prints/i-K3KMsx8/0/49163269/XL/empty-room-5-800-XL.png
-alt: Black and white Risograph with halftone dots depecting an empty room, a small closet in the foreground.
-description: One layer Risograph on Stonehenge Cream \#110
-date: 2017.01.05
-edition: 10
-size: 5x5 inches.
-media: Risograph
-type: art, risograph, edition
----
\ No newline at end of file
diff --git a/content/everything-easy.md b/content/everything-easy.md
deleted file mode 100644
index c0ad840..0000000
--- a/content/everything-easy.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-title: Everything Easy is Hard Again
-slug: everything-easy-is-hard-again
-author: Frank Chimero
-source: https://frankchimero.com/blog/2018/everything-easy/
-tags: internet, web
-type: annotation, bibliography
----
\ No newline at end of file
diff --git a/content/factorial-race.md b/content/factorial-race.md
deleted file mode 100644
index 2df719e..0000000
--- a/content/factorial-race.md
+++ /dev/null
@@ -1,102 +0,0 @@
----
-title: Factorial! Race!
-description: Finding an upper limit on factorials in JavaScript
-date: 2021.06.07
-slug: factorial-race
-type: text, texts
----
-
-
-
-
-For the past while now, I've been tinkering on [a side project](https://www.dicegraph.com/) that builds and graphs arbitrary probability distributions created by dice rolling outcomes. It's extremely niche and dorky, but it's a been a really fun way to explore both product design development and new concepts in math and programming that have otherwise never presented themselves during my career.
-
-This is an article about the second bit.
-
-One of the interesting things that I discovered early on was that when adding the ability to _multiply and reduce_ dice rather than just _multiply or reduce_ dice (ie; roll 1d6, roll the resulting number of dice, on a 4 or higher roll again, sum the total results. Complicated!) the distributions are [not normal](https://en.wikipedia.org/wiki/Normal_distribution), which means in order to actually graph the distribution we need to calculate every possible outcome. Not a big deal, since computers are good at this sort of stuff!
-
-However, I quickly discovered an upper bound: the calculation requires working with [factorials](https://en.wikipedia.org/wiki/Factorial). When the factorials get big, JavaScript gives up and returns `Infinity`. This is because there is [a maximum limit](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER) to the size of a double-precision floating-point number that JS uses for the `Number` type. Wow, this got both mathy and programmery really quickly.
-
-This gave us an upper bound of `170!`, since the rest of the distribution calculations don't like it when you pass them `Infinity`.
-
-```js
-const factorial = (x) => x > 1 ? x * factorial(x - 1) : 1
-factorial(170) // 7.257415615307994e+306
-factorial(171) // Infinity
-```
-
-Lucky for us, JavaScript has implemented a [Big Integer](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt) type for integers that are … well … big! I was able to refactor my `factorial` function to use `BigInt`s.
-
-```js
-const big_factorial = (x) => x > 1 ? x * big_factorial(x - BigInt(1)) : BigInt(1)
-big_factorial(BigInt(171)) // 1241018070217667823424840524103103992616605577501693185388951803611996075221691752992751978120487585576464959501670387052809889858690710767331242032218484364310473577889968548278290754541561964852153468318044293239598173696899657235903947616152278558180061176365108428800000000000000000000000000000000000000000n
-```
-
-So what's our new upper bound? We can handle `170!` easily, how high can we go? `1,000!`? `10,000!`?
-
-```js
-big_factorial(BigInt(1000)) // 402387260…0n
-big_factorial(BigInt(10000)) // RangeError: Maximum call stack size exceeded
-```
-
-Turns out `1,000!` is a walk in the park. `10,000!` gets a little more interesting! The error that returns on the function is about [too much recursion](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Too_much_recursion). We're calling `big_factorial` _from_ `big_factorial` ten thousand times and the browser thinks this means something is wrong, so it bails out on the process.
-
-So, what if we refactor our recursive `big_factorial` to use a loop?
-
-```js
-const big_fast_factorial = (x) => {
- let r = BigInt(1);
- for (let i = BigInt(2); i <= x; i++)
- r = r * i;
- return r;
-}
-big_fast_factorial(BigInt(10000)) // 284625…0n in about 70ms
-```
-
-`10,000!` is fast! We can get reliably get the result of that in less than 100ms. And since our loop will run as long as it needs to, our upper bound should now be based on compute and return time, rather than type errors or browser guardrails. Lets see what we can do now:
-
-```js
-big_fast_factorial(BigInt(20000)) // ~300ms
-big_fast_factorial(BigInt(30000)) // ~650ms
-// …
-big_fast_factorial(BigInt(90000)) // ~7238ms
-big_fast_factorial(BigInt(100000)) // ~9266ms
-```
-
-Things … start to get slow above 30 or 40 thousand factorial. Every additional ten thousand to our initial number adds more and more time to the compute function. Im sure theres some fancy `O(n)` complexity notation to express this, but I don't really want to figure that out. It's too slow to use an in a UI above say, `50,000!`.
-
-Turns out tho, even mathematicians don't really calculate factorials this big. They use [Stirlings' Approximation](https://en.wikipedia.org/wiki/Stirling%27s_approximation) instead, since it's faster and "good enough". It looks sort of like this:
-
-```
-𝑒ln(𝑛!) = 𝑛!
-where
-ln(𝑛!) = ∑𝑛𝑘=1(ln𝑛)
-```
-
-It would be pretty cool to do this in JavaScript! And personally, I love "good enough". I've already got a handy function for running Big Sigma calculations:
-
-```js
-const new_arr = (s,n) => {
- if (s < 0 || n < 0) { return []}
- return Array.from(Array(n+1).keys()).filter(v => v > s-1)
-}
-
-const Σ = (min, max, fn) => new_arr(min, max).reduce((acc, val) => fn(val) + acc, 0)
-```
-
-So lets try this out:
-
-```js
-const log = (x) => Math.log(x)
-Math.exp(Σ(1, 1000000, log)) // Infinity
-```
-
-Oh no! The end result of our `1,000,000!` function _is still Infinity_. Thats because one million factorial is … very big. It could still fit into a `BigInt`, but then we have another problem: we cant run `Math` functions on the `BigInt` type. And we can't rewrite the functions to use `BigInt`s because the type is, by definition, _only for integers_. and `𝑒` is definitely not an integer. Even a math library like [math.js](https://mathjs.org/) has the same issues around typing, despite trying to account for it.
-
-Naturally, this leads to a simple proposal: FaaStorials! Fast Factorials as a Service! Since factorials are immutable, it should be possible to store the first 1,000,000 or so in a database, and provide an API for querying and returning them. Even a slow network request would be faster than computing the factorial locally. It should be possible to crunch (slowly) all the factorials, and write them to a database for retrieval on demand. I wrote this function and got about 7,000 rows written before I realized it would probably be expensive.
-
-According to my rough estimating, `1,000,000!` would send a response that weights about `700kb`, and the whole database would be in the neighborhood of `350gb`. This would cost me about $80 a month to store, maybe $100 a month to pay for the requests as well. I pulled the plug on the script.
-
-As with many problems, the upper bound ends up being defined by time and money, the end!
\ No newline at end of file
diff --git a/content/five-dysfunctions.md b/content/five-dysfunctions.md
deleted file mode 100644
index a972c3d..0000000
--- a/content/five-dysfunctions.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: The Five Dysfunctions of a Team
-slug: five-disfunctions
-author: Patrick Lencioni
-year: 2002
-source: https://www.tablegroup.com/books/dysfunctions/
-tags: business, teamwork
-thesis: Someone sent me a copy of _The Five Dysfunctions of a Team_. I didn't really like it.
-type: annotation, bibliography
----
-
-
-
-
-
-_The Five Dysfunctions of a Team_ by Lencioni reads like middle-manager fan fiction. Beyond the outrageously bad dialogue and cutely arranged set pieces, all spread out across large type, short chapters, and generous white space to pad this brief seminar into a “real book”, Lencioni’s thesis throughout is freighted with the zeitgeist of the early 2000s late capitalist striving.
-
-Structuring this self-help seminar for middle managers disillusioned with their directionless grind to nowhere as a "fable" (or "bad fiction") makes it read like a shockingly earnest first draft of Max Barry's _Company_, which is a satirical skewering of corporate management consultants and practices.
-
-Team dysfunctions are seen as failings of individual actions, and that the behavior of individuals in a team is the root cause for failure of the team. This implies that behaving differently in an organization is enough to the change the outcomes of that organization. This is flatly untrue - individuals have little to no ability to change the outcomes of structural and organizational decisions that have been built into the fabric of the group. Lencioni’s fictional startup is built on capitalist axioms that inherently undermine the very points he’s trying to argue. For instance, the root dysfunction he identifies is "Lack of Trust". There is literally no reason, cause, or benefit to “trusting” a corporate team. When employment is at will and there are no protections for workers, focusing on individual impact and the appearance of productivity to peers and higher ups becomes the sole function of work. Placing the goals and priorities of an organization above your own is deeply foolish when that same organization has no doubts or qualms about your place in it. The organization of structural power defines the absence or presence trust, and individual behavior has no sway on that power structure.
-
-The dysfunctions in total are as follows: Absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results. When viewed through the lense of structural power, it’s clear that absence of trust and fear of conflict are two sides of the same coin - as are lack of commitment and avoidance of accountability. All four are more easily understood by the systems that are in place for doing work rather than behaviors of individuals. The fifth is perhaps true, but nearly tautological to the point of uselessness. To imply that a dysfunction team is inattentive to any results is absurd, so the implication is that the team is inattentive to the _correct_ results. If you focus on the right thing you won’t be wrong. Not very helpful. Again, the lense of organizational power is helpful: instead of asking what results are attended to, the question becomes what results are valued and rewarded.
-
-The approach that Lencioni takes in demonstrating (crudely) his ideal team also suffers from one of the key rhetorical traps outlined in _Keywords: The New Language of Capitalism_ by Leary - speaking of the corporate as if it where literally corporal. The Team in this case becomes embodied, and in doing so it erases the humanity of its members. This is the key contradiction in the dysfunctions - Lencioni identifies that the only way to sublimate ones individuality away for the sake of the corporate structure is through individual improvement, which he equates to moral improvement. This is perhaps less a flaw in his reasoning than a description of corporate America’s ideal employee. The corporation desires all of the reward and benefit of your labor, and the complete devotion of yourself to producing that labor, while disavowing any risks or consequences that may attend it as your own personal problem. Lencioni deserves credit at least for outlining the goals and structures of vampire capitalism so clearly.
-
-Lencioni continues to show that a team of leaders _must_ necessarily remove themselves from the teams they lead, and create a cloister amongst themselves. In doing so, he advocates for placing the goals of the collective leadership team over their individual goals and the goals of their individual groups. This is the regular party line for corporate technocrats: the humans below us whom we rely on to perform labor matters less than the group of peers who direct and profit from that labor. This rhetoric performs two jobs; the first is working to distance the powerless from the powerful, and the second to justify the distance that the powerful already sense between them and their subjects. There can be no relationship of peers between a rich owner of a company and white collar workers whose labor they profit from. It’s been known and observed that being rich and owning companies means you are no longer able to act like or understand people who are not rich or own companies. You lose empathy for them, and see only other rich owners as your group of peers. Lencioni works to sooth any moral qualms the rich may have about this while indoctrinating the middle managers who are the true audience to the necessity of aligning with capital over labor. This scene immediately segues into our brave executive team having a conversation about “adjusting the amount of resources allocated to engineering” - in other word firing people.
-
-This is the core issue I have with the entire book. Any consequences of wielding power are firmly denied - placed within the realm of the “strategic decision” while the political structure of the corporation demands and requires individual subservience to collective goals with absolutely no reciprocation of any kind. Sorry, it’s a strategic decision and we're allocating resources elsewhere. Now your entire family doesn’t have health insurance. Is anyone truly surprised that an absence of trust is endemic to the corporate structure?
-
-Lencioni goes on to demonstrate a firing in action. “My husband is a lawyer so you will have a tough time making the case to fire me?” What is this? This is insane. In what world do these people live in where at-will employment isn’t a thing? You can be fired at any time for any reason. The VP in question goes on to negotiate her own firing. 3 months severance and instant vesting of stock. Is this seriously how Lencioni imagines this works? Is this really how this works for these people? Because for people like me it’s much more like “hand in your gun and your badge immediately, we’ll give you two weeks severance if you sign this NDA”. People like me _want_ to be fired so we can collect unemployment. And later, “Companies don’t usually fire contractors” what planet is this dude on?
-
-Through the book, Lencioni uses phrases and idiomatic structures that I don’t think I’ve ever encountered before. “Enter the danger.” What does that mean? Is it the danger zone? These come at a quick pace, and are present in both the dialog and the interstitial narration. The overall effect is one of complete disorientation, the feeling is that your bobbing at sea in the text without being able to get firm bearings on any sort of shared, consensus reality. “They called each other on the carpet”? What the fuck?
-
-Our hero’s behavior definitely looks like what CEOs and top brass like to pretend they are doing, so we’re creating tautological support for managers to continue doing whatever they are already doing and dressing it up as an insight. The only thing that’s surprising about this grift is that I didn’t realize what was happening sooner.
-
-This book has a terrible definition of politics - instead of embracing that politics is the application of power (and therefor inherent and necessary in any social group, especially a firm) Lencioni seems to define politics as dishonest interpersonal behavior -“acting a given way in order to solicit a certain reaction” or something. This shows that Lencioni has absolutely no understanding of the power that the heads of firms do wield, as understanding the mechanisms of that power would necessarily be politics.
-
-In a scene where the executives are considering selling the company, we see them weighing the decision in terms of their own personal benefit. This means they each own a good amount of stock. This means that they are owners of the company. This means that they have a completely different relationship to the work as their employees, who are not owners, own no stock, and make no decisions. What does this do for our middle manager audience? They reject the offer, so it must be a lesson in valuing the work over the money (or a reinforcement that the whole point is to chase more and more money)
-
-The final 35 pages of the book are the actual seminar - Lencioni has padded 35 pages of content into 222 (not counting the final dedication to the fallen of 9/11 to really cement the early 2000’s tone). The seminar includes a questionnaire that each member of a team should fill out, however it helpfully reminds the reader that no part of the assessment may be reproduced or stored in any way. I guess you have to buy everyone a book and have them fill it out in the book. At the end of the assessment there is an advertisement for Lencioni’s consulting services. The transparent grift is breathtaking. The overview of the dysfunctions solidify the slog of the previous terrible fiction: in short that the individual behavior and interpersonal relationships are more important than organizational structure in defining outcomes, and that what behaviors you are currently doing are correct but you should probably hire Lencioni as a consultant because it takes constant work and maintenance to avoid falling apart.
-
-In short, a perfect grift to tell the Silicon Valley middle manager or executive exactly what they want to hear, formulated in a way to extract as much money out of them as possible.
\ No newline at end of file
diff --git a/content/foucaults-pendulum.md b/content/foucaults-pendulum.md
deleted file mode 100644
index 276e990..0000000
--- a/content/foucaults-pendulum.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: Foucault's Pendulum
-slug: foucaults-pendulum
-author: Umberto Eco
-year: 1982
-source: https://bookshop.org/books/foucault-s-pendulum-9780151327652/9780156032971
-tags: conspiracies, numerology
-thesis: The horror of meaninglessness leads us to seek a deeper meaning in pareidolic connections of arbitrary facts. Actively encouraging this tendency — even cynically and for profit — can lead to earnest commitment from your audience and end in tragedy.
-type: annotation, bibliography
----
-
-
-
-
-
-Reading Foucault's Pendulum in 2021 was a deeply depressing experience.
-
-To speak directly to the current client of conspiracy theory and American politics, Eco deals _explicitly and directly_ with emergent facism and proliferation of conspiracy theory. In 1982. And focuses on Christian nationalism. In 1982. And basically sketches out the situation that led to the crises that led to Jan. 6. In 1982.
-
-It's a great book — long and winding, with a compelling _in media res_ that centers Eco's _probably unique_ interest and understanding of Italian post-war facism and semiotics. While the primary story is told by the narrator Casaubon, most of the books told as other, tangentially related stories. Some of these are Casaubon's, a lot of these are another character Belbo's, and the rest are from a wide variety of strange and interesting characters they meet.
-
-As far as the plot goes, the story is about the Knights Templar and Gnostic mysticism. The fundamental premise of the novel is that there are a lot of coincidences around historical stories that have really unsatisfying explanations, and in to this void step the gnostics, who are sure that there is something that can be known that will explain everything. And by everything, we get to explanations of _everything_. Our protagonists Casaubon, Belbo, and Diatollevi, seek to create the grand unified theory of everything. They build on gnostic traditions and methods to explain a cohesive story of the unexplained. They call is "The Plan". Initially they do it from a sense of cynical parody, then from an attempt to extract money from their marks, and ultimately they fall victim to the appeal of the pareidolic connection, and convince themselves that this is a natural way of interpreting history. This has immense consequences for all three of them.
-
-There is a lot I'm not touching on here — from the role that the women in the novel play (problematic at best, especially with Lorenza, and I'm not too sure about Eco's treatment of Lia, the novels most level-headed character) to specific Christian theological histories (honestly I just don't give a shit). But the core of the book is worth considering in relation to our current time and place.
-
-
diff --git a/content/fun-with-json-ld.md b/content/fun-with-json-ld.md
deleted file mode 100644
index c96e8e9..0000000
--- a/content/fun-with-json-ld.md
+++ /dev/null
@@ -1,186 +0,0 @@
----
-title: Fun With JSON-LD
-slug: fun-with-json-ld
-description: Learning about JSON-LD is all about and why we should.
-date: 2020.08.25
-type: text, texts
----
-
-
-
-
-
-Working with [Adam Riemer](https://www.adamriemer.me/) on SmugMug's SEO has been a really illuminating experience. SEO consulting has always been flagged in my mind as "Snake Oil Business", but Adam really is the best in the field. Almost all of his SEO suggestions focus on performance and accessibility, and he has some clear, hard metrics to define "good". This squares with my fundamental understanding of good SEO practices, and has broadened my horizons and understanding of of the practice.
-
-Something that Adam introduced me to is JSON-LD – a way of creating structured metadata for pages that's more explicit that microdata formats. Here's what I've learned about JSON-LD so far.
-
-JSON-LD is Google's preferred format for accurately and succinctly structuring metadata for pages. This gives them insight into what's on your page and why, and they use The Algorithm to interact and consume this data. Using their standards gives you the _opportunity_ to get top, fancy search results but there's no guarantee of that. The best thing to do is to use your structured data to give the best, more accurate, and complete picture of what content your page has for your audience. Trying to game SEO here is probably going to backfire, just describe things as they are as clearly as possible.
-
-The primary _purpose_ of structured data is to create a machine-readable and algorithm friendly metadata for your content. This allows the content to be consumed by the crawlers and the robots, and join in the mesh of content that Google exposes to users when they perform searches or ask questions of it.
-
-Clearly this is a double-edged proposition. By using structured data you're explicitly buying in to the ecosystem that Google is creating, and allowing your content to be trawled and used and understood however they want. You undoubtable end up providing value to Google in excess to what they are providing to you. Not to mention participating in the project of making the world machine-readable, which has it's own philosophical freight.
-
-[Schema.org](https://schema.org/) has a lot of data types that might be appropriate for your project: Articles, Books, Breadcrumbs, Carousel, Course, Critic Review, Dataset, Event, How-to, Local Business, Movie, Podcast, Product, Software App, and Video are all ones that look interesting to me.
-
-For something like this site, we're using pretty much entirely `Website` and `Article` – and connect them with a `CollectionPage` and a `Person` who is me! Maybe some of the art will be a `CreativeWork`.
-
-Some information on these types:
-
-- Article: [https://schema.org/Article](https://schema.org/Article)
-- Person: [https://schema.org/Person](https://schema.org/Person)
-- Collection Page: [https://schema.org/CollectionPage](https://schema.org/CollectionPage)
-- Creative Work: [https://schema.org/CreativeWork](https://schema.org/CreativeWork)
-- Web Site: [https://schema.org/WebSite](https://schema.org/WebSite)
-
-Lets work through [Google's example of an article](https://developers.google.com/search/docs/data-types/article), maybe for this article!
-
-Here's the `script` tag that is home to our structured data:
-
-```
-
-```
-
-We fill it with a JSON object that describes our data structure:
-
-```
-{
- "@context": "https://schema.org",
- "@type": "Article",
- "headline": "Article headline",
- "datePublished": "2020-08-25T16:42:53.786Z",
- "dateModified": "2020-08-25T16:42:53.786Z"
-}
-```
-
-The `@context` key clues the robot in to the data definition we're going to be using, which is the `schema.org` definitions. The `@type` tag associates the following data with the pre-defined structure. From there on it's relevant data! `headline`, `datePublished` and `dateModified` are all directly pulled from the content itself. In out case our data looks like this:
-
-```
-{
- "@context": "https://schema.org",
- "@type": "Article",
- "headline": "Fun With JSON-LD",
- "datePublished": "2020-08-12T08:00:00+08:00",
- "dateModified": "2020-08-12T08:00:00+08:00"
-}
-```
-
-Open question: `BlogPosting` or `Article`? Im going to stick with `BlogPosting` since these texts are really just that. I would use `Article` if I was writing a news piece or a review, or something maybe more scholarly.
-
-The last required field is an `image`:
-
-> For best results, provide multiple high-resolution images (minimum of 300,000 pixels when multiplying width and height) with the following aspect ratios: 16x9, 4x3, and 1x1.
-
-```
-{
- …
- "image": [
- "https://example.com/photos/1x1/photo.jpg",
- "https://example.com/photos/4x3/photo.jpg",
- "https://example.com/photos/16x9/photo.jpg"
- ]
-}
-```
-
-This means that creating thumbnails for every Article is important, and those images need to exist on the page in a way that user can see.
-
-For this site, the main use of these images is going to be for sharing thumbnails. The fact that the image needs to be on the pages is interesting, since that really influences the design of the page. I've found that creating the necessity for a prominent thumbnail or hero image that accompanies each article is a recipe for a) not writing articles and b) bland stock photography. I want to avoid both. That means for this site I'm going to do illustrated images, small sketches and motif explorations that may or may not illustrate the article, and attach it to the _bottom_ of the article.
-
-There are two other sections I want to look at, even though they are not requirements according to Google. These are the `author` and the `publisher` fields. The goal of using these fields is to create an association between you and your work; or in the case of the `publisher` field between an imprint entity and the creative works they've published. In our use case for this site, my goal is to create a machine-readable entity that is 'Nikolas Wise' and attach my articles and my work to that, in order to create a coherent entity that is exposed to the broader web.
-
-The `author` field is a `Person` or an `Organization`, the `publisher` field is an `Organization`. Lets start with `Person`:
-
-> A person (alive, dead, undead, or fictional).
-[https://schema.org/Person](https://schema.org/Person)
-
-It gets added to our LSON-LD like this:
-
-```
-{
- …
- "author": {
- "@type": "Person",
- …
- }
-}
-```
-
-There are a lot of properties in this schema, like `deathPlace` and `knows`. One could really get into this and make it a very robust and complete data object, but I'm not sure how much value that would bring at the end of the day. There's a fine line between following specs and best practices to achieve a goal and ticking boxes to structure our lives solely in order to make them legible to the algorithm. I guess we each decide where that line is for ourselves.
-
-For me, I'm going to stick with `name`, `url`, `image`, `jobTitle`, `knowsLanguage`, and `sameAs`. Although `publishingPrinciples` seems interesting, and I might write one of those.
-
-Most of the fields are simple text strings, and can get filled out like so:
-
-```
-{
- …
- "author": {
- "@type": "Person",
- "name": "Nikolas Wise",
- "url": "https://nikolas.ws",
- "image": "https://photos.smugmug.com/Portraits/i-ThnJCF5/0/f9013fdc/X4/wise-X4.jpg",
- "jobTitle": "Web Developer",
- "knowsLanguage": "en, fr",
- "sameAs": …,
- }
-}
-```
-
-The language codes are from the [language code spec](https://tools.ietf.org/html/bcp47), and could also be [language](https://schema.org/Language) schema objects. The job title could be a [Defined Term](https://schema.org/DefinedTerm) schema object.
-
-The `sameAs` key is an interesting one, it's either a URL or an array of URLs that connect this `@person` with other parts of the web that are _also_ that `@person`.
-
-```
-{
- …
- "@person": {
- …
- "sameAs": [
- "https://twitter.com/nikolaswise",
- "https://github.com/nikolaswise",
- "https://www.instagram.com/nikolaswise/",
- "https://www.linkedin.com/in/nikolas-wise-6b170265/",
- ],
- }
-}
-```
-
-This will connect "me" with this site and my twitter, github, instagram, and linkedin profiles. Those are the pages that I want to the algorithm to associate with "me".
-
-`@organization` is similar to `@person` in a lot of ways, and the fundamental idea is the same. The goal is to create a single entity that the algorithm can connect disparate pages and items too. I'm not going to set of an `@organization` here, but the the [`@organization` schema type](https://schema.org/Organization) has the spec for the object.
-
-So that's it! That means the entire JSON-LD for this article – and therefor the rest of the texts as well, looks like this:
-
-```
-
-```
\ No newline at end of file
diff --git a/content/headless-cms-introduction.md b/content/headless-cms-introduction.md
deleted file mode 100644
index df0b0f2..0000000
--- a/content/headless-cms-introduction.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: Headless CMS; A Brief Introduction
-description: What _is_ a Headless CMS, and how can it be useful for building websites and apps?
-date: 2021.05.28
-slug: headless-cms-introduction
-type: text, texts
----
-
-
-
-
-
-A Content Management System is a central aspect of any web project - even projects where you would never think of as "having" or "using" a CMS. In these sorts of projects the content management system _is_ the codebase, and the strategy for managing content is identical to the process for managing code. This, obviously, is not ideal for anyone who wants to edit content and not code, or in uncomfortable in the workflows that developers rely on for our day-to-day practice — like Git. The other end of the spectrum of CMS is something like Squarespace — the code is the content. Not ideal if you want to edit code and not content. A traditional CMS like Wordpress attempts to split the difference; the CMS controls the code and the content, but makes an attempt to keep them at least a little independant by storage content in a database and providing an admin interface for editing and authoring that content.
-
-All of the above approach the problem of content management with the same set of assumptions: the CMS is responsible for taking the content, combining it with the code, and assembling and delivering the entire website. Both parts are coupled together, with the CMS rendering the "head" of the website or app.
-
-In the past few years with rise of build-time generated and static sites, a new approach to this problem has been articulated and built by a number of companies. The basic idea underlying this new approach is that the CMS should only be in charge of content, and interacted with like any other API. This decouples the code from the content, and removes the CMS from any responsibility of interacting with the code at all. This style of CMS does not render anything out to the web, and is thus called a headless CMS. In short, a headless CMS has no website out of the box. This means there is not a default theme (there are no themes!) to configure, there is no classic "blog" visuals or interfaces to configure and map too content. A blog is just one of many things a headless CMS can be used for.
-
-A headless CMS has a number of advantages: the first among them is that the product in charge of managing content can focus solely on managing content, and be very, very good at authoring, creating, and editing without needing to also be a good tool for building web apps with. The second biggest advantage is it provides the development team with complete freedom to meet the real-world business use cases associated with the project without relying on the CMS to support those use cases.
-
-Search Engine Optimization is an excellent example of these two characteristics at work – we are completely free to implement any SEO improvements without any support from the CMS, because the CMS doesn't do anything but manage content. SEO tags and page metadata can become content like any other content, and the codebase of the web app is responsible for rendering the actual website as it goes over the wire and gets consumed by browsers. Instead of relying on Wordpress Plugins or trusting that Squarespace is following best practices, all of the implementation details over your SEO strategy is completely in your teams control — just like any project _without_ a CMS integration — while the content itself is entirely in your strategy or marketing teams control.
-
-A Headless CMS exposes content via an API, and that's all it does.
-
-Contentful provides a set of client libraries that allow content to be consumed in a developers language of choice, meaning that the technologies or systems used to render your app can be selected by any set of criteria at hand, rather than being forced into a decision by the CMS – if you use Wordpress you're writing your app in PHP within Wordpress. With Contentful you can [write your app in Go](https://github.com/contentful-labs/contentful-go) if you want and live your best life.
-
-Below is a quick overview of using the Contentful JavaScript SDK to access content in the Headless CMS. It returns JSON and can be used at run-time or build-time to add content to a website or app:
-
-```
-const contentful = require('contentful')
-
-const client = contentful.createClient({
- space: ,
- accessToken: ,
- host:
-})
-```
-
-The `client` provides a set of methods for interacting and querying the content database;
-
-```
- getSpace: async ƒ getSpace(),
- getContentType: async ƒ getContentType(),
- getContentTypes: async ƒ getContentTypes(),
- getEntry: async ƒ getEntry(),
- getEntries: async ƒ getEntries(),
- getAsset: async ƒ getAsset(),
- getAssets: async ƒ getAssets(),
- createAssetKey: async ƒ createAssetKey(),
- getLocales: async ƒ getLocales(),
- parseEntries: ƒ parseEntries(),
- sync: async ƒ sync()
-```
-
-You can use the `getEntries` function to get all the entries available:
-
-```
-client.getEntries()
- .then(entries => {
- console.log(entries)
- })
-```
-
-Or query on metadata or content:
-
-```
- client.getEntries({
- content_type: 'lesson',
- 'fields.slug[in]': 'content-management'
- }).then(entries => {
- console.log(entries)
- })
-```
-
-Contentful in particular is interesting because one of the fields you can add to your entries is a reference _to other entries_. This gives the information architecture model some pretty amazing abilities to structure and enable pretty much any sort of content strategy you want to build. Some simple key-value pairs for getting strings to complicated, nested, conditional data structures.
-
-And from the code's perspective, it's all just JSON!
-
-For an example of how one can write components that consume this general API data, I've put together a small sample of how to create a component that's defined by JSON structures, and how handling different configuration keys alongside content strings can create a powerful way to integrate with a Headless CMS like Contentful. Check out the [demo on Glitch](https://component-doc-sample.glitch.me/).
\ No newline at end of file
diff --git a/content/heavy-pop.md b/content/heavy-pop.md
deleted file mode 100644
index 27270d1..0000000
--- a/content/heavy-pop.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-title: Heavy Pop
-slug: heavy-pop
-date: 2016.05.01
-media: Risograph
-size: 6x9 inches
-edition: 50
-description: Fine press monograph for artist [Morgan Rosskopf's](http://morganrosskopf.com/) solo show at [One Grand Gallery](http://www.onegrandgallery.com/) commissioned by the artist and the gallery.
-type: art, riso, edition, book
----
-
-
-
-
-
-
-
-The project is a collection of drawing and collages by Morgan Rosskopf. The book is printed in off-process CMYK and hand bound in experimental reverse drum leaf perfect binding. The monograph works with the rest of the gallery show, acting as documentation and a piece of art in its own right — an object treated in the same manner of a cassette tape for sale at a concert.
-
-
-
-Morgan is trained a fine art printmaker, and the multiple is a valuable part of her art practice. This show, however, focused on individual works – drawing and collages. Morgan wanted to provide a low-cost object that worked in the tradition of the multiple to supplement the show without providing literal prints of the work.
-
-
-
-The translation between formats, density of image, and literal color space all worked together to create a new interpretation of Morgan's work — some ideas were able to come forward with the process, while others became more muted. The monograph became a unique art object itself, rather than a piece of documentation.
-
-
\ No newline at end of file
diff --git a/content/how-to-design-while-developing.md b/content/how-to-design-while-developing.md
deleted file mode 100644
index ac0c41a..0000000
--- a/content/how-to-design-while-developing.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-title: How to Design While Developing
-slug: how-to-design-while-developing
-date: 2016.5.15
-description: Moving beyond the idea that the designer and the developer on a web project are different people, and that somehow those are different things.
-type: text, texts
----
-
-
-
-
-
-For a long time, websites got made with one person designing how it should look and one person developing the code that made it look that way.
-
-A lot of times, this is still how things get done - one team makes static Photoshop comps, and hands them off to a team of developers who know stuff like whether React or Ember or Node or Ruby is the best thing. This can sometimes cause friction. The designer expects the website to look exactly like the comp, the developer writes a bunch of custom CSS and HTML to fit the design, and whoever needs to make sure the whole thing is WCAAG compliant spends weeks hating both of them. When the next comp comes down the line, it all happens again. For a big site, this leads to design drift, and a hugely tangled codebase that’s a [nightmare to try and untangle](http://paulcpederson.com/articles/css-for-people-who-hate-css/).
-
-This splitting of systems is an artificial one that’s sustained by organizational assumptions: we need designers, and we need developers. The thing about Design though - capital D _design_ - is that it’s simply a method of deciding on a structure to accomplish a purpose. The design tools and methods one uses to accomplish good design is always in tune with the thing being made. A building doesn’t go from painting to construction drawings, nor does a car go from modeling clay to racetrack. The clay and the paint are very useful steps to _start_ the process of design. They help us to be creative and loose and explore new solutions to the problems at hand. This exploratory work helps us to understand how a thing will _feel_ in the world.
-
-These initial drawings and sketches get translated into their final structures, and translation is a process that can enrich both what is being translated _to_ as well as what is being translated _from_. Every precise moment may not align directly, since differences in context can have deep implications for meaning.
-
-We turn our drawings into objects with all the considerations of the final materiality present. We can’t ignore the shape of the engine or structural code requirements, although our models and paintings certainly can. Design is provisional until the point at which it exists in the world, and when talking about the web even this isn’t any sort of ending. A website is its own sort of thing, with its own structure and requirements that need to be present and known throughout the entire process of design.
-
-A drawing and a website will never look the same. This is mostly because a website isn't static. Because of this, what a website _looks like_ is just a small piece of what a website _is_. A website is what it enables its users to accomplish, what its developers have to do to keep it stable and moving forward.
-
-The best way to meet our goals as people who make good websites is to focus less on those drawings right away. Instead we should think more about simplicity and elegance than the detail oriented perfection of a jpeg.
-
-Don’t get me wrong - the jpeg can be important. It shows us how we think we can solve our problems, a glimpse of how we want our website to looks and feel, and the tone we want to communicate. Through all this it needs to have to room to change and breath as it comes to life and become a real thing. Our drawings should not be on the level of “what does this look like” but “what problem does this solve and how”. At every step in the process we can work to make the real thing better, to solve new questions that arise as we move through the process of design / development – a process where there is no gap between those two ideas.
-
-To design a website is to develop it - and as we develop a website we are constantly making design decisions. A designer cannot abdicate their responsibility to design by saying “well, my jpeg looked great.” A developer cannot abdicate their responsibility to a codebase by saying “well that’s what they wanted in the comp.”
diff --git a/content/is-progressive-enhancement-dead-yet.md b/content/is-progressive-enhancement-dead-yet.md
deleted file mode 100644
index 9141c2e..0000000
--- a/content/is-progressive-enhancement-dead-yet.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-title: Is Progressive Enhancement Dead Yet?
-slug: is-progressive-enhancement-dead-yet
-author: Heydon Pickering
-year: 2021
-source: https://briefs.video/videos/is-progressive-enhancement-dead-yet/
-tags: design, development, javascript, js
-thesis: Progressively enhancing web applications is not only an essential practice for accessibility, but it provides a framework to respect separation of concerns in technology _and_ reduce boilerplate, polyfills, and otherwise kludgy code.
-type: annotation, bibliography
----
-
-
-
-
-
-Pickering wants to talk about Progressive Enhancement, but apparently a lot of people are over it and want to be done with it. Pickering thinks that putting progressive enhancement to bed – and worrying about it no more would be a "grave" mistake.
-
-Pickering addresses some common misconceptions.
-
-Progressive Enhancement is Not:
-- Something you install using a package manager.
-- Progressive enhancement is not a `
-
-
-
-
-
-
-
-
-
-
