Close

Source Code Cleanup

A project log for TrillSat

Texting Without Cell Towers, Power Grid, or the Internet: IoT meets AX.25 Aboard an Arboreal Space Elevator

lee-djavaherianLee Djavaherian 05/21/2018 at 06:120 Comments

I've been cleaning up my various source code files and getting them ready for release in the next couple of weeks.

I edited my OpenSCAD source to allow variables at the top of the code to change the output (to render individual parts for printing, display the entire assembly, display the exploded assembly, and perform an animation).  In my C, Lua, Python, and BASH code, I also made a pass through my config files to section out my private code, removed hard-coded values, and renamed some directories to more appropriate names.

It takes time to think up appropriate names while programming (and pulls you out of your context), and this can break your concentration when you are involved in something complex.

My paper notes are the same.  I have good spelling, penmanship, and drawing skills, but you'd never know that by looking through my technical notes, which are almost indecipherable, since I scribble train-of-consciousness as fast as I can think, and similarly, this doesn't allow me to access my spelling or fine motor skills, since I'm not focusing on them at the moment.  It really isn't writing or illustrating--it's a brainstorm data-dump: misspelled words and scribbly ideograms.  I then make a second pass over the material if I need to formulate a visual or literary language.  But it's kind of depressing looking at hundreds of pages of your own old, messy notes...

My source code is the same way.  First I get it working (using whatever constructs are needed), then I make a second pass to refactor into more modular programming practices, abstracting away similarities, eliminating redundancies, etc.  But this takes time.  As proof-of-concept, my first release, Version 1.0, is always messy.  I don't use alpha/beta indicators or 0.xxx versioning to signify versioning, as every release is a beta as far as I'm concerned.  I just do the major.minor thing and start with 1 and then use the decimal values in sequence to denote future versions, only changing to a 2 if there is a significant improvement  (which has never occurred to date).

When I was young, I was a perfectionist, and it was easy for others to see this in my work, but as I got older, I realized that I wasn't optimizing the "entire" structure, and so I began to apply my perfectionism to systemic and systematic processes and not visual ones, and this is sometimes hard for anyone but myself to recognize (an ugly shell with beauty inside, so to speak).  But the fact that someone like Leonardo da Vinci can draw and write beautifully in his notebooks while also expressing complex, abstract concepts (beauty throughout) is astounding, and I wonder how he achieved this ability (or perhaps it wasn't really what I think it is, I don't know).

In some ways, though, when you force yourself to slow down and perfect something trivial, like the simple notes, the illustrations, the prose etc, it helps to clear the mind when you look back at that thing later, and may actually be a better way of doing things (more gains in the long run) than my messy "molding over several iterations" approach; I don't know, since I've never really tried it for anything sufficiently complex.  But it would take a person of the utmost skill to do such things.

Several years ago, I created a BASH script which adds the appropriate GPL license files, extracts README documentation from my website, adds the version number, strips out my private code segments, packages everything into a tarball, and stores the released versions in an archive.  This allows me to program and test my code in place with all of my hard-coded customizations, and then I can just run the packager to generate the correct tarball for public release.

But with the TrillSat project, I've encountered a situation that I haven't dealt with before:  this is my first "open-hardware" project containing an electrical schematic, 3D-printed parts, and source code for several different CPUs, all of which I am trying to publish.  In other words, there are electrical, mechanical, and software designs, all combined into one project, which means that the packaging separation and selection of appropriate open-source licenses have to be carefully considered.

I also had to modify my packager to account for C and Lua files which use a different form of commenting than typical Perl/Python/BASH style # comments.  For example, C99 and above can use // and Lua uses --.  Since I use the comments sections to add control codes, my packager needs to parse them, and the license headers also need to be inserted into those comments, appropriately, for that language and type of license.

And I discovered a new problem that bummed me out:  when I upgraded my smartphone to Android 6.0 (AOSP) a while back, it broke the Access Point functionality of my ESP8266 NodeMCU code, which was working fine before, since this version of Android does not seem to connect to an AP without a real DNS server (but of course, I don't use one since I'm using it for the TCP/IP protocol only, not the Internet).  I'm not sure how I will handle this yet as I don't want to downgrade my phone OS, and building a DNS server in NodeMCU is not feasible.  Somehow, I'll need to spoof the client to convince it that a real DNS server is present.

And, lastly, I still have to re-test all of my code to ensure that it still works after I've stripped out those customizations, which is tedious.  There is a lot of work to do over the next couple of weeks...

Discussions