| description | tools | |||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
4.1 Beast Mode |
|
You are an agent - please keep going until the user’s query is completely resolved, before ending your turn and yielding back to the user.
| # Project Policy | |
| This policy provides a single, authoritative, and machine-readable source of truth for AI coding agents and humans, ensuring that all work is governed by clear, unambiguous rules and workflows. It aims to eliminate ambiguity, reduce supervision needs, and facilitate automation while maintaining accountability and compliance with best practices. | |
| # 1. Introduction | |
| > Rationale: Sets the context, actors, and compliance requirements for the policy, ensuring all participants understand their roles and responsibilities. | |
| ## 1.1 Actors |
Here's the unusually long linkography from the Zoom chat during World Building in Haskell with Tom Harding:
Perlin noise youtube playlist: https://www.youtube.com/playlist?list=PLRqwX-V7Uu6bgPNQAdxQZpJuJCjeOr7VD
The inventor of Liquid Haskell Ranjit Jhala is funny: https://www.youtube.com/watch?v=Ci48kqp11F8
Fun Prolog stuff, totally off-topic: https://arxiv.org/abs/1809.02840
| // Y Combinator | |
| const Y = a => (b => b (b)) (b => a (c => b (b) (c))) | |
| // isomorphic Church encoding/decoding | |
| const Church = { | |
| to: n => f => x => Array.from (Array (n)).reduce (f, x), | |
| from: f => f (x => x + 1) (0) | |
| } | |
| const True = a => b => a |
| const R = require("ramda"); | |
| const data = { | |
| title: "Intro to functional lenses", | |
| author: { | |
| name: "Jiri Marsicek", | |
| email: "[email protected]", | |
| position: { | |
| name: "Software Engineer", |
| const effects = {} | |
| const coeffects = {} | |
| const actions = {} | |
| const state = {} | |
| function registerEffect(id, f) { | |
| effects[id] = f | |
| } | |
| function registerCoeffect(id, f) { |
| # Makefile for transpiling with Babel in a Node app, or in a client- or | |
| # server-side shared library. | |
| .PHONY: all clean | |
| # Install `babel-cli` in a project to get the transpiler. | |
| babel := node_modules/.bin/babel | |
| # Identify modules to be transpiled by recursively searching the `src/` | |
| # directory. |
Lightning talk proposal for ReactiveConf 2016
At Blueberry, we've been frustrated with maintaining and getting oriented in our React components and their props. That's why we made a tool for automatically generating a component library from a project's components.
We named it BlueKit and released it as open-source.
Proposal for this year's Reactive lightning talks @ReactiveConf - If you want to see my talk, star this gist please :-) [Reactive Blogpost][reactive-conference-blogpost]
As a JavaScript developer, could you imagine using something else than Atom, Sublime or other IDE-like text-editors? During their daily work, people wrangle a lot with different applications, editors, windows, browsers and loose a lot of time because of their tools getting in their way.
Redux has brought the notion of reducer back into the awareness of many developers for whom they are a novel concept. In fact they are quite simple, and used all the time in such things as SUM aggregations in databases, where they compute a single value from many.
It's great that Redux has made reducers known to a broader audience, though they are relatively ancient concepts in programming, in fact. But the particular way Redux illustrates a reducer in its documentaion is, in my opinion, with a coding style that is harder to extend and read than it should be. Let's distill reducers down to their essensce, and build up Redux reducers in a way that lowers complexity, and helps separate Redux idioms from your business logic.
A reducer is a pure function that accepts more arguments than it returns. That is to say - one whose "arity" is greater than 1. It 'reduces' the two things you pass it down to a single value. Here are two reducers, in a map
