If you don't believe me, it's worth watching the Industry and Economy panels together:
Bringing Lessons Forward
I am still immensely proud of my zkb.py module. It remains a touchstone for me of how to design something that is actually maintainable and easy to drop into new projects. I can easily drop KB scraping into any project, and spend time leveraging the data rather than fighting the API. Going forward, I want to repeat this slim and modular style, so I can mix and match parts going forward.
I am terrible at learning these lessons on the first pass. I usually opt for a "make it work" mentality over a "make it pretty" and I have paid for it over and over. Thankfully I have a lot of good parts and (hopefully) enough experience to try and avoid the straight-path pitfalls that have left me with so much unsustainable, bloated, spaghetti code in the past.
The theme for the next set of tools will be "building blocks". I've achieved a lot of these prototypes in my spreadsheets, and I need to be bringing those pieces forward rather than writing custom tools for everything. The added benefit of modules rather than monoliths is recyclable code. As and example, if I can get a sustainable BPO module class set, I can tie it together with kill data for "materials destroyed" reporting.
Fortune Favors the Bold
BPO Handler
As I said, the goal is "building blocks" and as such, I will first focus on rebuilding my blueprints handler. The day-0 goal for Kronos is to replace my terrible kit builder, because the first need moving forward is accurate cost/material-quantity reporting. Those two functions represent the largest player-time investments on my plate as an industrialist.
Previously, I had tried to make a SDE scraper that could be run per-expansion and output a middle layer file that could be slurped into a bigger tool set. I am not sure if this is still the most sustainable thing going forward, because a read-only DB should be relatively cheap... but with BPO material requirements becoming MUCH simplified, I may also include this method again.
System Handler/Teams Handler
The next immediate goal will be to accurately estimate install costs. Since resources will be system-level, it will be useful to design a system object to track these inputs. I expect to write both a gdoc JS script and a Python module for this data. The men will be separated from the boys on quick, accurate, and reliable cost predictions.
Teams will be largely manual in REV0, but I am hoping @RegnerBA lives up to his promises of an API dedicated to Teams. I expect the initial prototype to be largely discarded for a more extensive REV1.
Front End?
Marcel has opened up Aideron Robotics tool development to corp members. I am hoping to take a little time between getting a stable base tool and developing a front end to really hammer on some UI stuff. I have an unnatural fear of UIs that I should really overcome, and D3JS + Bootstrap should allow me to finally leave the spreadsheet nest and upgrade my graphpr0n prowess outside of JMP. But until I have some foundation and am able to spin up heavy industry to a point I like it, I doubt I will spend much time on front end stuff.