Reinventing the Wheel - Industry Tools

As I have repeated in my previous postings, EVERYTHING is changing in industry.  Though some of my existing tools could probably be re-kludged to work going forward, this is as good a chance as any to get off the crutches and move forward into a real sustainable tool.

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

https://github.com/lockefox/EVE-Prosper/tree/master/Kronos

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.