Posted: 2017-11-24 | Last updated: 2017-11-24
As my progress on Pieces of Eight moves forward I seem to have adopted a pirate themed naming convention. Why call a class "ComparisonOrchestrator" when you can call it "ComparisonCaptain"?
More of the basic functionality has been added, the program can now;
*Using the assumption that the competitor has the same cost price as us.
My plan next is to add functionality in the GUI to add a competitor and read the data from a file (currently hard-coded for testing).
The great thing about OOP (Object Oriented Programming) is that most of this functionality is already there, I just need to alter the methods slightly.
As I'm going through each component of the program I test as much as possible whether it be reading a price in a file or printing a single word to the screen. This just makes good sense rather than getting to the end and running the program only to find there is a little mistake hidden somewhere in the hundreds (or thousands) of lines of code.
As this is an ongoing methodology, there can be lines left in that are unneeded and although most IDE's do a great job of pointing out unused bits of code I'm also constantly checking for them myself as well as refactoring algorithms and method calls.
As in my last post where I briefly mentioned matching SKUs and the many, many pitfalls and challenges that could arise; I so far, have been "exact-matching" SKUs.
So if I have a company product with the SKU: "ABC", the program will look for a product with exactly that SKU in the competitor prices. Great!
What, though, if the SKU the competitor is using is actually "ABC-1" or "ACME-ABC" because of some obscure naming convention? What if we don't know what SKU the competitors are using and only have a name to go off? E.G: "ACME ABC Garden Gnome".
My thoughts on a solution have bought me to this so far;
I see caveats to the second two bullet points - it may provide false positives which can be a nightmare to find and sort out. I'd love to use machine learning to train the program but I feel that is a bit ambitious for such a small program.
Aside from the other problems with large spreadsheets, filtering data adds even more processing to the pile meaning it is not a realistic method of garnering helpful data.
The whole purpose of the process is so that we can see if we are selling a product too cheaply or for too much (and probably not actually selling it as a result).
Therefore, I would like to add some kind of filtering criteria, so that the program can show you, for example;
As well as, of course, all data for each competitor.
Once I have the core functionality I will look to how I am going to present that data to the user. This is going to be one or ideally both of the following;
While all this is going on I am also thinking about a program to read in a CSV of historic order details so that we can make use of the data. This should be a relatively simple process but one which could be of use.
Oh, and I'm also off work, so I'm "relaxing" too. :)