🌐 https://wiki.xxiivv.com/site/malleable_computing

🌐 https://www.inkandswitch.com/malleable-software/

🌐 https://www.redblobgames.com/pathfinding/a-star/introduction.html

🌐 https://jyn.dev/the-terminal-of-the-future/

🌐 https://beautifulracket.com/appendix/why-lop-why-racket.html

🌐 https://beautifulracket.com/

"Turning the database inside out with Apache Samza" by Martin Kleppmann

🌐 https://youtu.be/fU9hR3kiOK0

🌐 https://www.buildyourownlisp.com/

🌐 https://www.scottsmitelli.com/articles/ideal-candidate/

🌐 https://htmx.org/essays/locality-of-behaviour/

🌐 https://blog.jse.li/posts/torrent/

Rich Hickey - Simple made Easy

🌐 https://www.youtube.com/watch?v=SxdOUGdseq4

🌐 https://wiki.xxiivv.com/site/discourse.html

🌐 https://jakelazaroff.com/words/a-local-first-case-study/

🌐 https://woodgears.ca/links.html

🌐 https://arendjr.nl/blog/2024/07/post-architecture-premature-abstraction-is-the-root-of-all-evil/

🌐 https://basecamp.com/shapeup

Bret Victor - Inventing on Principle

🌐 https://www.youtube.com/watch?v=PUv66718DII

🌐 https://bitbashing.io/gc-for-systems-programmers.html

🌐 https://gamebalanceconcepts.wordpress.com/2010/07/07/level-1-intro-to-game-balance/

🌐 https://tylr.fun/tyde22.pdf

🌐 https://hazel.org/

🌐 http://lampwww.epfl.ch/papers/idealhashtrees.pdf

🌐 https://hypirion.com/musings/understanding-persistent-vector-pt-1

🌐 https://www.inkandswitch.com/peritext/

🌐 https://www.inkandswitch.com/local-first/

🌐 https://courses.cs.washington.edu/courses/cse503/08wi/parnas-1979.pdf

🌐 https://larrysanger.org/2024/02/the-return-of-the-coders/

🌐 https://theconvivialsociety.substack.com/p/the-convivial-society-no-17

🌐 https://www.roguebasin.com/index.php?title=Grid_Based_Dungeon_Generator

🌐 https://wiki.xxiivv.com/site/permacomputing.html

🌐 https://martinfowler.com/bliki/CQRS.html

🌐 https://internet-janitor.itch.io/decker

Jack Rusher - Stop Writing Dead Programs

🌐 https://www.youtube.com/watch?v=8Ab3ArE8W3s

🌐 https://www.maria.cloud/intro

🌐 https://github.com/SerenityOS/serenity

🌐 https://olano.dev/2023-11-30-code-is-run-more-than-read/

🌐 http://kmdouglass.github.io/posts/summary-out-of-the-tar-pit/

🌐 http://blog.fogus.me/2022/11/10/the-one-about-lisp-interactivity/

🌐 https://erlang.org/download/armstrong_thesis_2003.pdf

🌐 https://diataxis.fr/

🌐 http://www.call-with-current-continuation.org/strand/MANUAL

New code must both accomplish the desired outcome, and be easy to comprehend and work with as a team of humans.

It takes enough cognitive load to consider everything that must be done to create a new service by itself, let alone decide on what principles to follow when it comes to architecture. A simple set of guidelines can help immensely off load this in the same way the python formatter black makes all the formatting decisions for us.

"Good fences make good neighbors"

These principles dictate most importantly that that good abstractions are built around the core domain. Giving your business logic a little love in the beginning will allow the business logic to love you back in the end.

The benefits of the proposed guidelines can be summed up into 3 things: Readability, Testing and Conducive to change

There's a lot of flame wars, and ways programmers tend to divide themselves. What editors to use, what distro you're repping, "Functional vs Object Oriented", cloud services, reactive frameworks, web frameworks, databases, the list goes on and on.

In order to mature as an industry, one big thing we're all going to have to do is to drop these hot debates. Ego is the biggest contributer to code stink I have seen in my experience.

You see this especially prevalent when someone has been "burned" by a particular poorly implemented pattern. What often happens is they become disallusioned and forget any positive aspects of the system, and start using the complete opposite of that pattern.

As it turns out, some patterns are better than others at addressing certain problems. Functional programming is great for writing logic and handling streams of data. Do you know what it's not good at? Functional programming sucks at interfacing with external systems, like caling APIs or working with the database. And there's a reason for this, becasue Functional programming specifically strives to elliminate side effects, when in essence that is literally what a database is. The database is like one big side effect.

So how are these guidelines helping? Well, this holistic approach does not prescribe any sort of framework or style. In fact it encouranges the mixing of styles depending on the context your code is in. If you find that your orchestration logic is really well suited to a procedural style, then forget about your declarative ideals for a minute and write some subroutine calls.

There are 4 types of logic/layers to define: Data, Business, Orchestration and Presentation, each with different concerns and responsibilities.

Similar to logic, data can take various forms which couple to concerns more or less than others. Arguably how we define data is more important than the structure of logic or layers of code. It can be more difficult to do this though, since data is the bloodstream of any codebase, and tends to be shared more than we intend. I’d like to define just 2 types of data here.

It's encouraged to split out into other django apps if "vertical slices" appear

app.types would contain the classes to contain your logic for the domain layer. Dataclasses work well, but nametuple, TypedDict or just regular python classes work well too.

Similarly app.api_types is for types which will be sent to or from api calls. This isn't necessary, but It's nice to define what these are, rather than guessing at whatever point in code the data is extracted, running a higher risk of ~KeyError~s. An added bonus is you could link to documentation in the code as a reference. To reiterate, this may be completely unnecessary if you're only calling a couple trivial apis, so do what makes sense for your project here.

app.api defines methods to make api calls. Most of the time these methods should accept either basic values or domain models, and be responsible for mapping to app.api_types. The reason being that if app.api or app.api_types isn't responsible for controlling the protocol, some other module is, which means they're coupled.

app.db is similar to app.api in that it should usually accept simple values or domain models, then return domain models. There's nothing wrong with returning ORM models from these methods, as long as they're only used in the orchestration layer and don't make their way into other data or business logic.

app.logic can really be named anything depending on the logic, and if there is any substantial logic there, it should be split into multiple modules and maybe apps. This represents the business logic, and it's a bit more strictly defined. It's similar to the last two data modules, except it must not incur any side effects.

app.service is the orchestration layer which ties everything together. This layer should be very small. It consumes methods in app.api, app.db and app.logic to perform tasks or generate results.

Then app.views and app.urls is what's left, they're just the presentation layer which ties into app.service (it can tie in directly to app.db~/~app.models. for simple views, or DRF views, since DRF is handling the logic).

A quick note on Django Rest Framework. DRF works well for simple CRUD applications, but most of the time we're not building simple CRUD apps, and there's some nuance there. This should be identified early, and we should try to avoid turning our Serializers into mega classes that run all of the api/db and logic.

We've scaled back quite a bit this year with the garden, focusing on cultivating only a small area right out front. In addition, we've hauled a couple of loads of horse manure from a nearby small horse farm.

Most of the manure was applied right on top of cardboard which was laid in a single 5ft wide bed spanning about 20 feet.

In it we planted some tomato, tomatillo, hot and bell peppers, beets, kale, potatoes and peas. Later we planted beans, cucumbers and squash.

Next to this bed we've been weeding (there's lots of wild lettuce, burdock, thistle and maple saplings in the area) and replacing with some flowers: sunflower, hollyhock and chamomile. In the area we planted some clearance perennials from the hardware store in along with the other perennial flowers planted there.

We hope to continue to transform the area into self seeding flowers intermixed with fruiting shrubs and other perennials with a stable ground cover.

On the other side of our direct front, we've been transplanting various berry varieties in hopes to establish a more cultivated berry area. Including: strawberries, pineberries, black raspberries red raspberries, tayberries, currants and goji berries. Also we planted a asparagus plants from the farmers market last year. Most did well, the area required more fertility, but thankfully the plants are pretty low maintenance.

We bought way too many potatoes for seeding this year, I couldn't stand to throw away the excess, so I planted some in the food forest further out and some in the rotted chicken manure pile. They all came up and are doing well, especially in the manure pile.

There's not much available this time of year, besides sunchokes (which are pretty quite abundant by now, but we're continuing to let them spread). Berries just really started rolling at the end of June, our strawberries have suffered from lack of fertility and care (hopefully this will improve).

So far here's what's fruited: naking cherry, goumi berry, black raspberry, some strawberry, goji berry. In late June, still waiting on: currant, gooseberry, red raspberry, tayberry

This winter was rough for our apple trees, I think I made the mistake of removing some nets too early, so rabbits ate the bark many of the young apple trees. To compensate, I pruned these trees pretty hard. They're leafing out, but not nearly as vigorous as previous years. I just hope they don't rot out, and are able to grow again from the stump! I will definitely replace the netting so the rabbits can't get to them next winter.

I have tried starting some Asian pear seedlings (from last years harvest). I had a decent success rate cold stratifying in the fridge in a bag of dirt, and planting into tall soil modules. I ended up with about 6 in the end (from ~12 successful seedlings) as some failed upon transplant. They're doing alright so far.

I also cold stratified quite a number of peach and apricot seedlings, which didn't sprout as readily as the pears (also I forgot about them). In late June I've put them out on the counter to sprout.

Many of the stone fruit trees around the property I pruned pretty hard. This caused an explosion of growth, that I will likely prune again in summer. I'd prefer if the trees stayed smaller for picking, and ease of future pruning. Some trees seem to be getting leaf curl, a fungal infection. It's not too bad for the most part. I hope the pruning will help let in sunshine and wind to help counteract the infection.

Our old apple tree that is supposed to only fruit every other year is fruiting for it's second year in a row! From my research this habit is likely due to being unpruned, resulting in over fruiting in one year causing the swing in the other direction the following. I think my pruning helped!

Additionally this year I have been cutting back comfery which has been very prolific to mulch surrounding trees. In addition I've pollarded several of the honey locusts around the property to also much the fruit trees. This has helped keep the soil really moist with minimal weeds.

This year to make things more comfortable I've been pretty diligent with cutting back thistles and other annoying plants with my machete and sickle. In addition I've been mowing more trails through, making it easier to access the groups of fruit trees.

This year is the first year that quince has fruited substantially, I'm looking forward to seeing what it turns out to be like! Also sea buckthorn is fruiting for the first time on a couple of trees.

I pruned the pears back pretty hard as well, and they're responding by putting out lots of new leaves and fruit. This succulent growth is attracting some aphids, but the ladybugs can be seen prolifically cleaning up well enough, I'm not concerned.

The theme I set out for this year was intentionally. When we bought this 2.8 acre property in fall 2022, it was wild, and it still is. Like a Midwestern jungle, I love it.

But in the chaos, there is always room for intentionally. It's tricky though, to bring order in the midst of chaos while retaining the character of the landscape. It's actually pretty easy to wipe out all character, just mow everything, apply herbicide & pesticide to anything that looks like it "doesn't belong" and seed turf grass, but that's not my intention.

So what was my intention? To cultivate a comfortable, fruitful, lush place that myself and others would want to spend time in. I also want to accomplish this without becoming reliant on external inputs.

turns out, coming to this place is a very iterative process, as first of all, I don't know exactly what kind of place I want to spend time in. This is where biodiversity and chaos helps. The landscape is constantly giving feedback, in every season and proving it's value in the ecosystem. Black raspberries show us every spring why I love wandering out back.

But it's not always so obvious how each plant, fungus, insect, bacteria or animal provides value, but it's well known that every one plays an important role. Even noxious weeds, they all proliferate for a reason. Burdock is hated by many, growing in neglected patches behind garages and in lawns, then attaching their velcro seeds onto pets, shoes and clothing. But without burdock opportunistically hitching rides and filling in spots of earth and sunshine, it's not obvious whether those slices would have been filled at all. Bare earth and wasted sunshine is more costly than any noxious weed to an ecosystem.

But on the other hand, there are species that establish and steal resources from others, or unnecessarily worsen the environment more quickly than it can be reestablished. Being able to grade species in this way requires a lot of perception and research, and even then, it's not obvious how to proceed.

The first rule: Be perceptive, actively observing in all seasons, and research!

The easy answer again is total annihilation of unwanted species, but I can hardly see a case where that is best. What I've found to be most helpful is to look in each area and consider the following:

1. Is there anything suffering that can use help?
2. Are there any resource hogs?
3. Any noxious weeds?

Then, remove any resource hogs and noxious weeds for the plants that need help. But remember, if removing those plants would result in bare earth, it might be worth reconsidering, or finding a plant better suited to fill that niche in that area first, otherwise you'll be fighting an uphill battle.

It's important to keep in mind, you should feel still feel comfortable in your jungle. Mowing paths between areas has been helpful to provide easier access to otherwise hidden areas, allowing myself and others to enjoy walking through. Again, you need to first be able to perceive your landscape.

Observing season after season, year after year gives nature a chance to surprise me, like every fall when a flood of asters bloom, (what for the rest of the year otherwise might have been deemed a weed)

Control Flow is a term used when describing the path of program execution. While it is necessary, by definition, control flow should be de-emphasized in declarative programming. Yet, I believe micromanaging control flow still plays an active role in even the most functional programs today.

Consider the following pseudo code

function count (text) {
        words = split(text)
        return length(words)
}

result = count('foo bar baz')
log(result)

Now consider the flow of execution.

Simple enough, we just read from top to bottom (jumping as needed). First count is called, which calls split, then length, returning the result, which is given to log to print.

Now slightly a different question, what does the dataflow look like?

'foo bar baz' -> count ( split -> length ) -> log

Looking at this one liner, this feels like a nice way to understand the execution and flow of data, but it doesn't match up exactly with the top-to-bottom layout. So even despite the lack of control flow operations like loops, conditionals or lambdas, it can take effort to extract and understand the data flow.

To further contrast, the simple arrows show the execution pointer moving down, yet the data is jumping all over the place:

For me, when I'm trying to debug some code, the first thing I try to do is to understand where the data is coming from and where is it going. This allows a divide and conquer approach, that ensures O(log(n)) dev time to find the discrepancy.

Let's consider a more complex example using FBP instead.

mouse/click -> button/check
button/click -> counter/increment
counter/result -> console/log

In this fictional example, we have an interactive environment, where a mouse device provides data about clicks, which are sent to a button to check for a click. Any resulting clicks are sent to a counter to increment. The resulting count over time is sent to the console to log.

Notice now that both control flow and data flow is very clear, moving from left to right, top to bottom. In more complex cases, it can be represented well as a directed graph, like a flow chart. Either way, data flow is explicit, and in doing so, control flow is actually removed. In other words, the program has no control over the flow of the program counter, in fact, it's not obvious that any program counter is necessary in a program like this. All nodes can be operating in parallel.

So what other benefits can this paradigm provide? Spreadsheets provide a glance into what's possible by simply allowing arbitrary references with functions for math and aggregation, which update reactively to arbitrary updates to cells upstream. Propagators and truth resolution systems are another concept along the same lines.

In a generic system where data flow is our key means of abstraction, we can build more flexible and modular systems that are easier to analyze and experiment than much of what's out there today, so give it a try!

Winter last year, I had removed a lot of wire nets around established fruit trees, in order to clean up the weeds rising around them. This turned out to be a bad idea, as rabbits eat the bark especially on apples, which can stunt or even kill trees pretty quickly, even those that are fairly established.

So this past winter, I added a many nets back around damaged trees, which has helped to protect them.

This year I didn't have much pruning to do. I mainly have focused efforts on cleaning up our tayberry bushes, continuing to remove rotting wood from our apple tree.

Next year I hope to focus more on honing in the structure of many of our pears, apples and peach trees to promote health, and a smaller size.

We ordered 25 hazelnut bushes from https://www.forestag.com. They're establishing well, planted along a shallow swale on a mound.

Additionally, we're planted a couple magnolia trees, which are also establishing well.

We're seeing a number of trees affected by peach leaf curl, as we've had an especially wet early spring.

Thankfully the pruning we've done in past years has opened the structure of much of these trees, letting in more air and sunshine. As the season progresses, the disease naturally becomes less prevalent, depending on severity.

We're looking forward to some great harvests this year!

Our old apple tree has lots of fruit on it for it's bi-annual fruiting habit. (last year we didn't get much)

Many of our peaches, nectarines and apricots flowered prolifically, and are putting on fruit now. We're looking forward to good harvests in August through October.

Bamboo, in Wisconsin!

Tayberries, our first ever harvest

Nanking cherries, really tasty and abundant!

Unsure what this is, but the leaves smell like winter green when crushed.

Another picture prior to blooming

June 7: 3 lbs of cherries

June 22: Early berry season I'm not weighing as they're more for a snack

• Nanking cherries: A good 40 handfuls
• Black raspberries: 40 handfuls, ripening over time
• Goji berries: 20 handfuls, ripening over time
• Tayberries: 1 handful, still ripening
• Silver berries: 2 handfuls

July 23

• 2 handfuls of blackberries
• 4.5 lbs of potatoes harvested from the garden

August-October

• About a couple pounds of peaches
• A few pears

js + html fails by using event hooks setup imperatively react/vue are a bandade

A good language makes it impossible to bury triggers or transfers of data

mutable variable and reassignment are not good enough, this defies explicit data flow

A good language provides careful semantics for handling state over time

A good lanugage implements a particle system elegantly

locality of behavior is an imporant principle as well as modularity.

React/vue have good solutions for this, but are isolated views on to the web they enable creation of components which can be declaratively included within other components, embedding state and logic. Components handle input events from the top down, bubbling events up and delegating statefulness to the parent and propagation of state through children.

A good language provides a general solution to modular stateful code

A good lanuage enables elegant creation and management of UI

TDD is "test driven development" a simple priciple, to write a test first, see it fail, then make the change.

But there's a big problem. Test failures are not guaranteed Even if you check in the failing test to version control, the previous test failure will not necessarily be ensured with something like continuous integration.

And more likely, you will just make the change and write the test in one commit.

Solution? Keep all your old code to run new tests against. version control keeps your old code, but it doesn't really make sense to use this to run multiple versions in CI.

What if instead, every function is referenced to by it's hash. The program is simply a hash itself, a function to be run grouping together all your other hashes.

Tests run against these hashes. New versions of your program are simply new functions made up of different functions, although this doesn't exclude the possibility of retaining old functions for testing purposes.

So when adding a test, you indicate at what hash the test should fail at (before your change) and then after you change it, you register that this hash should pass the test.

Then the test runs twice, once with the old hash and one with the new. Then the test results are cached forever, since they ran against a hash, which is guarenteed to run the same forever.

Event sourcing is nice. Except when your event protocol changes, and you need to either run a migration, or do some crazy defaulting to ensure old event versions still work fine

What if instead, the event interpreter was an event itself?

So when the interpreter changes, an event is emitted to indicate this, This means in order to determine the current state of anything managed by the event sourcing system, all you must do is push that entitiy's events through the most recent program event at the time it was emitted.

Namespaces are for separating names that might collide.

Namespaces do not however enable coexisting copies of the same code at different versions.

Using hashes however elliminates the need for namespaces. You may have aliases for your code for reference, but importantly: they are not required internally for your code to run.

This means your system may operate fine with multiple versions of the same program installed simultaneously without any issues, even running at the same time.

Need some kind of program which allows you to "check in" data which can be hashed and held onto.

This repository can hosted so it can be pulled down by others

Then apart from this, you can have your version control, which simply holds links to versions in the repository.

The way programs are hashed is first by breaking it down to a symbolic representation, then by looking at the internal references, and breaking it apart.

Every chunk of code is hashed separately, and a dependency tree is made.

for instance, if your code looks like this:

def foo(): print('foo')

def bar(): print('bar')

def foobar(): foo() bar()

Then foo, bar and foobar will be hashed separately Then foobar, rather than holding onto the named references, will hold the hashes of foo and bar.

So when foobar is pulled down, all it's dependencies are packaged with it.