Since this project has been going on for so long and I am terrible at trying to keep logs of the process, I wanted to break down what was done and provide better insights as to why warecache is what it is today.

Origins: motivation

Ok, so back to the beginning. I, like many people here, get frustrated when trying to work with some tool or process and feel like there has to be some better way to actually do something. As you likely have read in the project description, I was trying to figure out how to deal with running out of a linear encoder and taking an abysmal amount of time to replace it in an outdated design, but there were a few other annoyances I had. 

I've hoarded parts for leftover or partially finished projects for over a decade, and it's annoying to have to try and find what you need without some better way to track what was bought. Normally I would store all of the relevant parts for a project together though this ends up with duplicate parts in multiple cardboard DigiKey or Mouser boxes. What about having a reel of 100nF capacitors on hand to share between projects? Where the hell does that go?

Of course, that's drops in the ocean compared to the amount of crap that the various employers had. I can't remember how many hours I've spent digging through random parts to help debug something. Quite often it was easier to just order a new part, but then what to do about keeping that IC on hand for when someone inevitably blows it up during testing? Just ends up being the same problem over and over again.

Getting to work

I let this idea fester around most of 2021, getting more and more bothered about what could be done to actually know where things are, what I even have, and what I need to buy to make things. That phrase pretty much has been stuck as the core concept of warecache, and why it's everywhere in written material. 

But this is before warecache, as I originally was calling it "pop-in", which I forget what "pop" was supposed to be, as it was a bit of a back-cronym (maybe "Parts Orientated... ??? Inventory. I don't think there ever was something specific for the second 'P', maybe procurement). Was a bit cutesy with the concept of "popping in" new parts to the system. Name didn't stick around forever, as it wasn't discernible from a lot of other things. 

Software beginnings

Enough about the name, let's get into the technical stuff. 

At that point, I never really touched any sort of UI library, but knew it was important enough. A big requirement I also had was that I wanted to have the software work on a potato; after dealing with Click-Up for a bit of time and finding it a huge pain due to being really, really, really slow I didn't want to repeat the mistakes. 

So of course after working on tons of microcontroller projects in and outside of work, I reached for using C for the entire application. You can certainly accuse me of being a nutcase, which I prefer cashews if you want a mental image. 

The important thing I felt like to start with, was figuring out some of the data models: how was I going to even store any of this? What do I even need to store?

I wanted to be able to keep track of bill of materials, individual parts, and projects themselves since it seemed like the minimal amount of items while remaining flexible. Since this could be useful in a lot of different ways and possibly others not in electronics/manufacturing, I wanted to make this agnostic to any industry. So this set of items seemed nice.

One problem though: how the hell am I going to deal with effectively what boils down to "type checking"? I mean having specific templates or formats for parts so that they have the same field entries. I keep thinking back to some BOM outputs from EDA tools, where half the fields are blank. Always bothered me, and I wanted to have some way to do this, but it had to be at runtime not precompiled since that means I have to maintain or hard code what part types are available.

In the end, I opted for having dynamic arrays of "info fields", which are the key-value pairs of things like tolerance, or temperature range, etc. I was trying to ensure that the info fields could be entered into a database, and having fixed tables seemed counterintuitive to my goal. The key value pairs made things easier, but I left synchronization and type checking for a future goal. 

So the clear setup of Parts -> BOMs -> Projects seemed to be the ideal setup, but this still doesn't solve the actual problem that I wanted to figure out: the hardware sensing. I still need to have some way to show the inventory in some way. I struggled with this for a few years, and put it off for the data types.

The projects however, had an interesting requirement: being able to have subprojects. Being able to have a reusable subassembly or some sort of structure that can be utilized by a number of other projects was something I really liked as a concept, but I didn't fully fix this until much later. There's the specific handling of "what if a subassembly is in a BOM vs explicitly as a subassembly"? I just wanted to have a consolidated BOM for the smallest units, which is not entirely the best way for every scenario. If you have the subassemblies on hand, why would you need to worry about the cost/count of the smaller parts? I'll get into the fix, once the timelilne catches up.

One last point for the BOMs and Projects, was version control. Projects can have multiple BOMs, and merging them together felt strange so I opted for named BOMs. But then having to deal with project and BOM versions, I decided to have the project versions act like snapshots, containing specific BOM versions. This is still a little strange, and has been kept but it seems to make sense for now.

I feel down a rabbit hole for storing all of the data, which ended up being in Redis. Why? Because fast (also I didn't really understand SQL and Redis seemed more approachable). 

First Pass

Ok, so I needed to actually get some UI elements up so that the data could be shown in some capacity. To make things simple, I didn't bother with a real server, as I thought I would be able to iterate faster with having the client and server side in the same application even though I still called it the "client" software.

I setup the nested projects in a file tree like browser, showing the date they were created, the version, and the author. 

I ended up realizing that projects having authors didn't make as much sense, and ended up only having the versions keeping the author field as it semantically was better.

Below is one of the early pictures I had of the software.

It was spartan, but I wanted to keep it utilitarian. One of the more fun things I wanted to have, was an optimal cost calculator, similar to how Digi-Key pesters everyone placing an order with the "would you like to change the quantity of this one part to save 4 cents??". I would much rather figure out price breaks and optimal quantities before I submit a cart to some distributor, but didn't have a way to store/save that info so I just showed the price per unit cost and the savings. Essentially, I just wanted to have some sort of analytics, to show that it could be done.

Not to mention the part status information, as that is something critical for anyone, to be able to see "what parts are problematic in this design".

The "BOM" tab hasn't really changed at all, as it just shows a table with all of the parts.

Some small demo video of the system with Redis running in the background is below