Wayne, John, Cory, and I on a server meeting. Talking about data back-ups on servers and ratios per server. Trying to get things nailed down and make sure that we have sufficient back-ups per server. Each server is slightly different as far as volume, corporations per server, and what the server's do (usage, traffic, and storage). It gets kinda interesting.

Wayne and John are going to check on all of the database boxes and how many days of rolling back-up we do per box. We have tons of copies of the code, and it changes every day. The actual data is the highest prize and needs to be treated with care. This may not fit here, but we see three main pieces to our application. You have the code, the database structure, and the actual data. If any of those pieces are missing, you only get a fraction of the whole. They are all required to make it work.

Along with back-ups, Wayne was reporting that he is watching the servers for errors and monitoring things. We talked about getting more details from clients who are reporting errors. Ideally, we could get the time of day, the corp id number, the server, and the steps that they were doing when they got the error. If we don't get much detail or feedback, we don't know where to start looking (per say). Those steps to get the errors are super important. Sometimes it could corp-specific code, settings, permissions, or even just page logic flow. Basically, we need the path that the users took to get the errors or certain results. It gets interesting.

Wayne did report that he is working on the corp-wide settings (huge table and breaking it into smaller pieces). That will end up being a pretty big project, by the time we are done with it. Currently, we have close to 400+ settings, attributes, and defaults. It's only going to keep growing.

Switching gears, we did some stuff with Marisa on emails and got her setup as an email admin on the backend. Cory was then asking some sales tax aggregate questions and we were going through different options. Eventually, we will need to walk through all of the steps and branching forks. That lead to some conversations about the value of data and getting the data in the right hands. Some of our developers have really wanted and needed certain data in order to do their projects and customize their stuff. Real data is key.

The last discussion for today's meeting was dealing with hardware, bundles, and making things consistent across the board - where possible. Marisa and John were talking about recommended hardware lists and what should be on there. The main subject was a certain scanner/printer combo. Our current model doesn't really allow us to force any certain decisions. We are very open. As we go forward, we may find a benefit by creating certain bundles and then fully supporting those decisions. It gets kinda tricky! The more we can help the system work as system, and everything plays together, the better. We may need to develop possible bundles of both hardware and software products. The other side of this coin that we looked at was developer costs and maintenance costs for different system and supporting different hardware configuration pieces. That's a somewhat hidden costs, but it is totally real. Anyways, some good hardware discussions.