Cory and Chuck were going over some new changes and things that we needed Cory to test and give us the thumbs up on. The new changes have been pushed up to the developer's testing server and need to be reviewed. The biggest section on new code is dealing with the parts and general inventory items section. We have modified the parts homepage, the advanced parts search, add/edit parts page, view parts page, parts usage, parts history, and a number of other part/item related reports and pages. We also have two branches with some changes to the shopping cart on the dev testing server, ready for review.

As a great little side note, Cory mentioned that we have to give people time to update their SOP's (standard operating procedures) if we go changing things. Some of the companies really rely on those SOP's. I didn't even think about that. One other comment that Cory made was - "We need to manage the things that are in our control." There are tons of things that we can't control, but those that we can, we need to do it in such a way that we control the changes, updates, and releases. Ideally, we will test, plan, and even schedule the releases.

We got into a discussion on data tables and pros and cons. Chuck would really like to revisit this topic when we build out fracture (future adilas project). We would like to look at pros and cons, which plugins to use, or just build our own. We really like what the current ones do in concept (export, sort, filter, search, print). However, we would like to change the layout, the display, the amount of real estate that it takes, defaults, and pagination. The current data tables work really good up to 500-1,000 ish records. Anything more than that and they fall apart (due to pagination and how the JavaScript loads the tables). Chuck and I were talking about some possible hybrid type options where we use client-side and server-side code to help them be more effective. Including storing default settings, default sorts, default show/hide columns, and mixing AJAX and server-side logic. Basically, making custom data tables that work for what we do and how we want to play the game. Definitely a must have for the fracture project.

After Cory and Chuck left, I kept going and switched topics. I was checking banks and looking into bills and payments out to our guys and gals. I also wanted to record some notes from my morning hike with my hiking buddy this morning. We were talking about this while walking in the snow, up High Creek Canyon before work.

- Real costs - Build in ongoing maintenance costs - not just the original development

- Also dealing with costs - what about coving costs for admin, managing, planning, normal development, deploying, and future or ongoing maintenance. Many of these costs are being skipped right now in our quotes and invoices. We need to cover what it really costs. Currently, we are giving away a bunch of free work and labor.

- Maybe stopping custom work - I'm not sure how to take this one, but we were talking about it. Currently, custom work is a huge part of what we do. Having said that, a good 75 percent of my work and efforts are being used to help with 1x (one time) revenue gains vs general system enhancements that are on a reoccurring revenue gain or side of the fence. My efforts are being used in project management, planning, code sign-off's, heling on the projects, babysitting developers, and deploying those projects. I'm kinda torn here. I enjoy helping but is it efficient? It may not be... Hard to fully tell. Anyways, thought that I would at least make a note about it.

- Use data to make decisions to help figure out where your product or features are being used. The data will help you make certain decisions (supply/demand/usage). When is it being used, by who, how many times, and can I quickly get to aggregated or summed up data on the subject? It is an normal core usage or add-on piece? This may or may not go here, but our model gets more complicated by having tons and tons of different servers. We may need to identify different pieces of the application (core, extra functions, settings, features, add-on components, 3rd party solutions, industry specific pieces, custom code, etc.) and then setup flags and tags to who is using it, what are the costs, any add-on's, and make that information available from a single spot (aggregated data). This would be a great feature to add into our fracture project. We may have to create our own little master list and then report that data back to the main server through API sockets and what not. We really need to be able to get to that data (who is using what) quickly. We need a quick summary of how and what is being used or is turned on/off. We can see that data right now, but we have to go to multiple places and even run special queries to get that data back. It's not very quick right now. Anyways, a great idea. Let the data lead and help to tell the story.

- We may want to track other key decisions per corporation such as merchant processing, number of locations, number of users, numbers of vendors, number of invoices, expense/receipts, deposits, elements of time, etc. We also need to track data storage amount and also files, images, and other media/content. We already do this, but the numbers are not centralized. This would be another wonderful feature for the fracture project. Basically, system stats and aggregates based on data counts, numbers, values, etc. If we get this dialed in, we could really use this to help set prices and charge for what is being used and/or turned on. This is an eventual goal for us, when we can get to it.