Steve was talking about getting a designer to help us with the Bear 100. He would like to take it out to Google maps, GPS, mobile friendly, and even allow for people to use our site to do sign-ups and other pieces. We could have the site tied out to ecommerce and allow for tons of other options. That could be fun.

Eric came into the meeting and had a couple of questions about customizing the invoice and quote process. We talked about parent inventory, sub inventory, parent attributes, flex grid tie-ins, and even black box custom tables. We also talked about adding in some blank or generic flex fields in the quote line items and the invoice line items. They want some custom fields per line item. Steve was saying, don't tell me what you want... show me. That way we know what tool to use and where to put it into play. Steve was also talking about maybe going up steam and setting those moving variables up higher on the customer level. In a way, the over arching question was I want to extend the existing options and functions per invoice and quote line item. We then have to help, how do we figure that out and what solution could we use to solve that problem? Good stuff.

This doesn't play in quite yet, but at some point we would love to get into real in-line database extensions. That is somewhat of the bigger brother to the flex grid tie-ins. Being able to add and subtract data points and data fields per section. As a side note, we have tons of companies that virtually commandeer (take over - like a pirate ship) any field that they can to get the job and/or task at hand done or finished. Kinda interesting.

Steve wants to get more information, from the source. He would like to get a real world scenario and then make a plan from there. Not just a quick band-aid, he wants to help develop the solution. What are the processes, what are the needs, what already exists, and what else is still needed? It keeps getting deeper and deeper (4 and 5 levels deep).

There was an analogy of a "part changer" - think of mechanic that just swaps out part after part in order to fix something. We really need the mechanic that gets in there and looks at the problem and then makes a decision. From Steve - It's not how fast you go, it's how well you go fast - older Porche commercial.

///////////////////////////////////

Switching gears, we started talking with Wayne about servers.

We were talking about virtual machines, physical servers, load balancing, and the difference between hardware problems and software problems. We were talking about clusters and getting redundancy and depth of options. If we stay with Newtek, we need to build in some of our own pieces. If we go more with AWS, we get to just use some the existing pieces. There is a trade off - AWS has more options but it also a deeper pool. Newtek is not as deep, but in some ways easier. We were also talking about rollover, fail safe modes, mirrors, etc.

We spent quite a bit of time talking about the Adobe ColdFusion engine and how we could potentially configure cluster type environment. When you get out of a single machine environment, what do you do with the database. On a single machine (server or dedicated box), it is simple. On a cluster, you have to keep things moved and/or separated. We would love to break some of the system down into their own databases. The idea here is making each database corporation specific vs server (whole box) specific. We have talked about this for years (since 2012 ish) and have called it world building and other project names. We really want to do this, but we also know that we have tons of code changes that are needed. We could separate out the shared tables in the existing database schema but we would have to do it table by table. As a side note, we have already done this very process for invoices, invoice payments, po/invoice line items, customer queues, sub inventory, etc.

One solution would be to create a corporation specific datasource (pointer to a specific database) and then help that get migrated and pushed around. We also talked about loading in objects per user that has all of their corporation specific settings and values. Eventually, we will still need to break out the payee/users so that we have a master list and then allow them to be merged and virtually bridged to any corporation and even any system. We still have all kinds of exceptions, such as be in corp x but pretend like you are in corp y (look and feel and settings). It gets kinda crazy.

The subject started to switch to more and more object oriented programming, storing values in session objects, and other objects that are server based. We also talked about database server clustering and moving all databases (per corporation) to a dedicated database cluster that only served up data and content. Lots of possible configurations and options. Both Alan and Wayne were talking about cross-schema queries and all kinds of advanced things. As another side to this equation, we are seeing more and more of a need for aggregated totals, auto processing, daily task management, etc. All of these things play into the mix. We are seeing certain tables that are great as shared tables and other tables that really need to be independent and corporation specific.

As we move forward, even towards a fracture type model, we will need to separate databases, logic, move more towards object oriented programming, API socket calls, etc. Just for fun, Wayne and Alan were talking about different levels and using bigger teams - backend guys, database guys, middleware guys, frontend and UI (user interface) guys, etc. We aren't that big.

Steve's idea... Alan, Steve, Dustin, and Brandon are all going to be at a convention. Let's use that time to do some planning and take it to the next level. That's a great idea.