kees/grip

output.mp4

An XOR gate with inputs at $7,0$ and $7,1$ outputting at $5,0$.

What's in each branch of this project?

Branch	Description
`main`	Where all development occurs
`001-stateless`	A decent little clickable grid (bad on mobile)
`002-list-lookup-state`	Grid toggle is refactored to use state
`003-bool-array-state`	Grid state is improved
`004-control-panel`	Input panels for grid interaction
`005-ruleset`	Apply a stateful series of logic gates

Develop on the project on any given branch:

npm i
npm run watch
open http://localhost:8280/

The project is not meant to be built manually but it can be done with npm run release.

I am working on a unique CI/CD workflow using branches instead of releases. All development occurs either on main or a local branch. A branch is pushed at any milestone which will publish IN PARALLEL to all other branches. I use numerical prefixes which is arbitrary but conveniently sorts chronologically.

Currently I need to work on custom formatting indices and page navigation, then the effect will work. I want a visitor to step through live builds to see the progress and if interested, read thoughts on them. Realistically the solution will be a canvas page that uses rewrite-clj on publish and embeds live builds in an iframe.

For now, view the main branch here: hardly.link/projects/d02-grip/

View the loose initial roadmap

📚 Section

📗 Subsection

Development goal

✏️ In progress

✴️ Completed and unreleased

✅ Completed and released

What is this list formatting? I’m trying out a style of list I wrote about adapting here. It's an informal and currently manual notation for managing projects that are too small to need a grand kanban deck.

📚 Housekeeping
- ✏️ Add some notes
  - ✅ Basic information
  - Mindset and goals
📚 Important fixes
- ✏️ Mobile layout
✅ Basic statefulness
- ✅ High-low state values
- ✅ Boolean array state values
  - ✅ Fix XY swapping
  - ✅ Fix integer coercion with interceptor
📚 Schema/spec
- Introduce something for validation (I like malli?)
📚 CI/CD
- ✅ Branch or tag repo management?
- ✏️ Build workflow
  - ✏️ Create post-build script
    - ✅ Normal build
    - ✅ Accept a string argument that will propagate
    - ✅ Either switch HTML refs to relative paths OR just watch reloads
    - ✅ Upload build to SPECIFIC path of S3 bucket, deleting
    - ✅ Upload index to SPECIFIC path of S3 bucket, file only
    - ✅ Invalidate CloudFront
    - ✅ Integrate bb to start redoing the primitive versions in clj scripts
    - ✏️ Complete pagination
      - ✏️ Create index page linking to all published pages
        
        ✅ Versions (e.g 003)
        
        Variants (e.g 003a)
      - ✏️ Create back and next buttons
        
        rewrite-clj to add vector of all populated sorted branches to views and dynamically choose current +1 and -1
    - 📗 Further dom population
      - Insert github link to repo branch
      - Basic info "built from xxx in user/repo"
      - Page title from branch name?
    - Style index page
  - ✅ Create github action
    - ✅ Detect some change (branch, tag)
    - ✅ Execute the post-build script with necessary data
  - ✏️ Revise early published versions once workflow completed
📚 Malleability
- 📗 Refine data transformations
  - Introduce specter for incoming application of rules?
- 📗 Prepare for data transformation
  - ✅ Introduce QOL form creation library (fork?)
  - Explore alternatives for simplicity
- ✏️ Data in
  - ✅ Control panel
  - ✅ Basic actions
  - Continue with basic input actions as needed
  - Read from saved grid and ruleset: program abstraction
- ✏️ Data out
  - ✅ Single button status
  - Side effects
  - Save state and rules as accessible program
- Data transforms
  - ✏️ Logic gates
    - ✅ Basic unary & $n$-ary gates
    - XOR, XNOR
  - Logic gate status lights, styling, diagrams
📚 Evolution
- Stepwise re-render, time
- ✅ Tick

kees- / d02-grip

kees/grip

About

Languages