Planning software and diaries

A while ago, I started a thread on planning software.  https://permies.com/t/74551/Permaculture-Planning-Software

Lately I've been thinking about diaries (not daiquiris), especially in the context of having a link to ledger (a text based format for double entry accounting, in particular to hledger which is ledger written in Haskell).  I managed to get the demonstration project of a blog for POET (POET is something on top of Mason, which is a bunch of Perl modules).  I tried writing it properly, and kept getting some strange errors.  So I lef the source code largely alone, and just change the labelling of things in HTML forms to make it look like a diary).

A diary entry for the farm is not a simple title, timestamp, content.  There are other things that need to go along.  Location is a good example I think.  If I go to get dyed diesel for the farm, the location in terms of the diary is the entire farm, as the diesel could be burned anywhere.  If I mow the lawn (the lawn is more than 10% of my farm for some strange reason), this is a big area.  If I go to do something on tree 17, that is a quite restricted area of the farm.

So not only do I want to find hooks for ledger type stuff, I want to be able to attach GPS track segments and other things.

While it is nice to be able to write all the diary entries necessary during the day they happen on, it may not happen.  And I don't expect this to be unusual.  You may be writing about the day in question, about a particular time of the day, an interval of the day (start and stop timestamps), or perhaps an array of similar type time/date entries.

I've seen entirely too many people sit down and write client/server type things and they miss aspects of the conversations, or they don't describe the interactions well enough.  And then there are problems.  Back in the days of UNIX and Bell Labs, there was a tendency to write "Little Languages" to solve particular problems.  And this follows into using yacc, bison, flex and perhaps the Perl Recursive Descent Parser (and other stuff).  If one sat down to write a language to describe an interaction (or conversation), it seemed to be easier to make it consistent and cover all the problems.  Otherwise your parser never would build.

Thinking along those lines, I went looking again at blog software, and ran across Swagger.  Swagger begot Swagger2, which begot OpenAPI.  Apparently the tools out of this "project" can be used to build significant parts of both the client and the server(s).  To me, this is like building a little language.  Except this all has such things as security built in from the start.

The API specification can be provided in JSON or YAML.  I've always hated javascript, so I never tried to learn anything about JSON.  But it seems almost eveyrbody loves it.  YAML I know a little about, and at least one person thinks the YAML version of an API is easier to understand than the JSON.

I've no idea if this forms a basis to start looking at computational aspects of permaculture.  I think the idea that this incorporates security from the beginning is important.

Today, if we have a well instrumented farm (I don't), we might have RFID tags on all the animals.  Let's say we have a scale, which weighs animals as they pass.  What happens if the owner of the farm walks across the scale?  The animal has a RFID tag, does the owner?

On UNIX, we typically use UID less than 1000 for "system" users.  I don't think assigning 1000 system users to a farm is enough.  I don't think having 1 million system users is enough.  So next step up is 1 billion system users (probably 1024^3) is probably the default.  That almost uses up a 32 bit dataspace.  So we probably want a 64 bit dataspace for User ID on the farm.

The first animal we put into the system gets the ID 1024^3+1, and so on.  In the old days, we might assign UIDs to all the trees on our farm.  What happens if we have trembling aspen?  We could have 1000 (more?) aspen on the farm, and they are all the same organism.  They are clones.  Lots of plant propagate by suckering (or layering).  If we coppice or pollard, we generate new entities.  So we need some way to relate a specific UID to one or more UIDs.

Which is all wonderful.  Except I have even less time to work on this that I might have, because my insurance company has said that I need to "finish" the deck by Sep 30.  And I am trying to treat every tree in the world (well, every tree seed in my fridge) as fall rye, and plant them now and get them started for next year (when some might get planted).

Am I looking at this correctly?  Is OpenAPI a framework for all the different servers on a farm LAN to talk to each other through describing an API?

Do you know of good documentation or tools to do this?  Example applications (or should I say example API)?  My tendency is to use Perl, but what other languages have support?  Why should I use them?

Did I miss anything?

Talking to myself, oh well.

I found a set of tutorials at API Handyman.  My feeling is that OpenAPI is a tool built to help people who know nothing beyond HTTP and love javascript.

If all you have is a hammer, the world looks like a nail.  Or something like that.  I think the idea of OpenAPI is kind of useful.  But, with 2 iterations at the core API under the name Swagger, and this OpenAPI version being the third, there still looks to be things missing.  The idea promises something about security.  As near as I can tell, you can specify no security, you can specify keys or you can use OAuth2.  As presented, I was expecting OAuth2 to be secure, and what everyone should endeavor to use.  Looking a little into OAuth2, I don't think I would want to touch it.  So, if you want to use it, keys are probably the thing to use.

It may be that OpenAPI can let you develop a language to have "apps" on the farm talk to each other, including things like diaries and describing purchases in a manner that can fit with LEDGER.  But I think once the language/protocol is figured out, you then redo everything using a parser for things on ports that have nothing to do with HTTP or HTTPS.  And most farmers or people in permaculture are not going to get involved.

As a sheep farmer, I looked at something like this about ten years ago and could not find anything, so I just built a program myself. I am a 9th generation sheep farmer and not a computer programmer, so I used Microsoft Excel to build it. It started off modestly, but got pretty big over the last 10 years or so.

What I found was, I could not split the personal expensing from farm expensing, and everything in a farmers life is based off time. Excel does time stamping, dating and numbers well so it really made a comprehensive program. What I found was, on a day to day basis, the information inputs were quick and easy, but at the end of the year the statistics were amazing. I could calculate in the weight gain curvature of my lamb crop, tell you up the month values for my woodlot, keep an inventory of the material flowing out of the quarries, and calculate budgets in regards to household withdrawal and farm stuff. That is just scratching the surface.

It is important to keep track of this stuff because while my work is making dirt grow green grass that miraculously gets turned white wollied animals into red meat that deposit black pellets back onto said green grass under a canopy of blue skies. That is what i do, but to be able to talk with bankers, lawyers and other business people, I not only have to be able to talk numbers, I have to back those numbers up. No one else will do it for you.

The best I've come up with is simple is better.
I have some programmer friends and when we talked about coming up with a program for our homestead farm they said it would be too involved, that is was simpler for my needs to just use excel and just link the columns and rows so at the end I had a page of totals, sub totals and it all related.
I ended up adding formulas so that each page does auto tallying and the last column gives totals for that page.
For my needs this was far less expensive and it is easier for me to use than getting a custom program built.