Details

Written by Austin

Category: Software hacking

Published: 24 April 2020

Hits: 6195

After careful consideration I've decided that stratus are shitty clouds. They're grey and amorphous, can be low-flying, and are aesthetically unpleasing. In a not-unrelated vein I am pondering a thing that might serve as an IOT-friendly key:value datastore.

High-level requirements / goals:

1. Easy to add to existing code. Minimal boilerplate, minimal RAM/CPU overhead.
2. reasonably secure; an endpoint (IOT device) should be reasonably confident that it's getting unmolested data
   1. note that this shouldn't protect against MITM or anything sophisticated
   2. note also that you shouldn't use this for anything important like heart monitors
3. dead-ass simple. IOT devices suck and have limited CPU/RAM/connectivity resources
   1. unfortunately this pretty much eliminates active crypto
   2. hard-coded & configurable API keys would be just fine tho
   3. shared-secret check bits might work ok (actually they'd be great with a decent hashing algo)
4. massively tolerant of failure
5. self-configurable / zero bootstrap

So here's a starting place, read-only:

• some ideas are stupid, but I don't want to forget that they're stupid
• hosted via simple static/flat text file with key: value\n pairs
  • build static config files offline, signed
• simple strnpos (or similar) to identify key and end-of-key "\n", substr() to extract it
• "API key" as an n-bit hex value
  • this is nontrivial. IOT code is distributed en masse, per-device configs are infeasible
  • each host can have a GUID (MAC address or derived from)
• host the static text file in a web space under that key, making it hard to find
  • /df/0xDEADBEEF.txt
• Use a key like "where my config should live". If you need to move it for any reason, just update that key and the thing would next pull from the new location. This key should mostly be self-referential tho (duh)
• Use a key for the API key too, in case you have to migrate that for any reason
• an IOT device should also check for its own GUID as a key, possibly indicating a new config location
  • to let one retroactively split off some clients, or per-client config specialization
• Other self-referential config things should include update frequency and debug / logging levels

If done correctly one could debug production device(s), ship them, disable debugging, and later re-enable it -- without requiring a code push / OTA.

#include "stratus.h"
Stratus stratus("http://austindavid.com:80/df/df.txt", "secret key");

...
setup () {
    // networking setup happens
    stratus.update();
}

loop() {
    static int variable = 1;
    EVERY_N_SECONDS(stratus.get("refresh interval", 300)) {
      stratus.update();
      variable = stratus.get("variable", variable);
    }
}

Doing a little better (potential TODO):

• implement a pub-sub; URL -> MQ, GUID + secret for authorization & authentication
• for more arbitrary-sized objects (beelobs), http get a single key / retrieve a single (biggish) value?
• use the datastore -- http post a key + value pub
• have clients pump a checkin value to indicate they last successfully read sub

Details

Written by Austin

Category: Software hacking

Published: 26 November 2019

Hits: 7402

I hope the ads aren't too annoying. I enabled what I HOPE will be unobtrusive ads across all platforms, to be in the non-content areas of the pages. If they get out of hand please This email address is being protected from spambots. You need JavaScript enabled to view it.. Your ad blockers should entirely hide them if needed.

I choose to run the ads to finance the site. My net hosting costs are on the order of $200/yr, and ad traffic roughly covers that -- with most volume to my virtual hat around Christmas time. Unfortunately the volume has tailed off in the last year so I'm exploring options for improving things -- higher-quality placement (and therefore higher revenue per ad) and more prominent placement, beyond the virtual hat.

Details

Written by Austin

Category: Software hacking

Published: 15 November 2019

Hits: 8539

One of my boys is homeschooled, and even before he did well with some warm-up / practice worksheets at home. I made randomized worksheets in Google Sheets that would let us print out the same types of problems, but with different values. Because he could memorize them (at least the earlier, simpler ones). These are targeted for a 7th grade program but likely apply to 6th and 8th grades.

• Adding and Subtracting Integers
• Integer Multiplication / Division, including PEMDAS / orders of operation
• Long division (Integer)
• Fractions I (integer + simple fraction)
• Fractions II (addition, subtraction, multiplication, division)
• Decimals (rounding, addition, subtraction, multiplication, division)
• Scientific Notation & Metric conversion
• Variable substitution (pre-algebra)
• Solving equalities & inequalities

Details

Written by Austin

Category: Software hacking

Published: 03 September 2018

Hits: 7939

I'm writing this because I spent too much time puzzling over it until I found a few gems. I probably won't use this IRL because it's clunky (and I think I have a way I prefer). but here's ACTUALLY how to write a JSON-serializable class, and why.

The official JSONEncoder docs say: "To use a custom JSONEncoder subclass (e.g. one that overrides the default() method to serialize additional types), specify it with the cls kwarg; otherwise JSONEncoder is used." Less-obvious (at least to me): JSONEncoder can *only* encode native Python types (list, dict, int, string, tuple ... that sort of thing); if you want to encode any other class, you *must* specify cls= in the dump/load methods, and you must provide a JSONEncoder subclass.

Specifically, json.dumps(data, cls=CustomClass) (where CustomClass is a subclass of JSONEncoder, with a default(self, o) method:

class SpecialDataClass(JSONEncoder):
    def default(self, obj):
        if isinstance(obj, self.__class__):
            return { 'data': obj.data } # or whatever serializable native type
        else:
            super().default(obj)

Serialize with: json.dumps(specialData, cls=SpecialDataClass)

This "works," but it broke down (for me) when I wanted to have a class stored within a dict, and I wanted to serialize that dict. Like, json.dumps(dict) fails if dict contains a special class. The class doing the serialization has to know what it's serializing (so it can specify that keyword), but I don't want that level of binding in my code. Generally this will fail if you have >1 special, unrelated classes to deserialize. Yes you can write a custom deserializing class which handles all of them (sort of a Moderator), but c'mon.

What I did instead (and what will probably change): I provided my to-be-serialized class with "serialize" and "deserialize" methods; they return or take simple JSON-friendly data. The enclosing class (PersistentDict) now accepts a "cls=" argument. New values in that dict would be instantiated in this class, and on read/write all values are pre-serialized or post-deserialized for sending down to json's dump/load methods.