On the morning GoToMeeting session. I helped Russell get some login credentials for the data 0 box. He is going to be adding some new databases and PHP options for the WordPress part of the site.

Wayne jumped on and we chatted before the meeting. Some of his stories about growing up in Idaho. He also showed us some stuff that he has created in Mindcraft - a huge super detailed castle.

- He started with a question, is the world round? His answer was, it is round, and that is what I choose to believe. Sometimes we don't understand the who, what, where, how, and why. We just have to take the information and either choose to believe and/or challenge it. How well do you accept things at face value?

- Things that are true and obvious at one point in time, may change as things progress. The same is true with programming. It is ok to question things and even challenge the norm. Be willing to break the models. We talked briefly about building and breaking things and then doing that again.

- Why do you write code? Alan - it is like a puzzle and I like to figure out the pieces. When you finish the project, you can be proud of what you did and created.

- Sometimes we like to show what we did and/or finished - that is a form of motivation (external feed) - We also love to talk and show people who can appreciate and understand what things are and what it takes to make that.

- Eric - He likes to build things. He loves the design part of it and then seeing it come to fruition.

- Russell - Easy, pretty, and powerful. Making things easy for others.

- Programs and technology can really make or break a company.

- What are the downsides to programming? Unpaid time that needs to be spent, people who don't understand, unbillable hours, the unknown, underestimating needs and/or requirements. Feature creep, pioneering and making things that don't end up getting used, etc.

- Eric - He likes to bill by the hour. He swallows some of the cost and calls it his ongoing learning process.

- Testing and test driven design - what is the style to do that and how do you accomplish that? Sometimes we get ourselves into our own little traps. If we take some time, sometimes we can step back and look at things from a different angle.

- Why do we test and why do we write tests? Confidence. Being able to verify that it does what you want it to do... Reliable and secure... What about the design? What if you did test driven design? Instead of just writing code, you virtually think of the tests that it needs to pass vs just the plain action code. What is your vision?

- Start with a test, then write the code to pass the test. The test might be the scenarios and/or the steps we want it to take. Have a bigger vision, but be willing to test and design as you build the component pieces.

- Think modular code and being able to test independent pieces. Super complex code that isn't modular may be bad code.

- Lots of emphasis on style. Appearance, the way things are done, systems, naming conventions, consistency, flow, a set of standards, easy to follow, other people/developers can follow along, patterns, directions and verbage, etc. A familiarity or comfort level.

- What is our style? Wayne likes to spread things out, spaces, white spaces, lots of comments, lining things up for easy reading. There are also section headers and/or natural breakpoints. Wayne really liked to break up walls of text into tabbed sections. He liked to line things up and make it more readable. That really helps.

- Wayne is using TestBox (testbox) a component of ColdBox (coldbox) for his testing.

- He broke his code into setup, before, after, and tear down type functions.

- Unit tests - tests a single set of code in an independent model.

- Database calls may be expensive (bandwidth, speed, and traffic). We need a way to emulate and/or fake the database calls. That allows the logic tests to be performed without full access to the database.

- Being able to mock things up is a huge key. Can we send fake data through the existing tests.

- DAO (data access object) - This could be a real dataset from a database or a fake or mocked-up dataset. The key is that the test can run if the data is real and/or fake. Either way, it is still able to run. This may not go here, but Wayne was breaking up existing methods and almost making mini black boxes even within the functions themselves.

- Where do you do your error handling? Wayne was specific where the error handling was and also where it was not.

- Simulating real database calls with mockbox (mock-up data).

- Formatting the data before the data is returned. Help prep the data so that it is ready when presented to the outside.

- Test suites (a family of tests). Wayne set these up with a keyword such as testGetPermissions, testObjectInit, testSomeotherFunction. The key word was the string test on the frontend of the function name.

- They, the guys, started getting more technical and actually looking at code and going over some of the test scenarios.

- If you really go into full on test driven design and unit testing, you have to be to a certain level. Similar to project management, if you are not at a certain size, you could totally over do things. You need to match both the testing and the project management to the size of the application and the size of the project.

- One of the goals of this test driven design approach allows for multiple different developers to play in the same sandbox. It helps to check tons of inter-dependency relationships (functions calling functions or other dependent options). It also helps your own code and making sure that all of the different scenarios can still play through. So, instead of retesting each condition, you already have tests in place to help it be more fluid and have a good confidence level of what is going on.

- Code once and use many. Having said that, don't repeat yourself... that usually means that you are writing bad code. Wayne was showing how he often setup a valid object, and then he changed one param at a time. That made it easier to see what piece had changed. Efficiency and trying to simplify where possible.

- What are the tipping points? Too repetitive, too long, too many forks, too many switches, etc.

- Wayne, on purpose, was showing tons of different coding styles. His goal was to show that we could do it in any number of different ways. We just need to format the style to fit our company and then try to go from there.

- Test the code that you wrote, not the code that some other company wrote (such as Adobe or Microsoft or Java or something like that).

- Labeling and getting things organized. Try to group like things together.

- Copying and pasting is very natural. It is very helpful, but can really duplicate problems. It can also make things fail due to lack of going back through and cleaning things up.

- As you mature, as a company, you will really want to continue upping the unit testing and get use to test first, then code, test first, then code. Once things are in place, the future changes get easier and easier. Especially having good tests in place.

- Russell asked for a step-by-step video on how to create things and even some best practices on what to do and how to do it. Wayne offered some other URL's, references, and links that will help us. How to install, how to tweak, etc.

- Alan's question - How do we help independent developers to buy into this? They are already somewhat fighting us on basic code sign-off. What are they going to say and/or do if we force testing, unit tests, and test driven design? Wayne was saying that if you get it, it will really help with future skill sets. There was then some back and forth questions on where are we going and what are we requiring? Both Alan and Wayne were talking about things. Wayne is going to go back through and create the initial test sets and then we'll need to go from there.

- All of this will get easier as we go along.

- Wayne - without proper testing... Adilas will fold in on itself due to the weight of the codebase and number of virtual cooks in the kitchen. It will start fracturing and crumbling without the pillars and support system. The test driven functionality and design will end up being part of the culture.

- Alan - we currently have some mega functions, that do way more than they should... those are really hard to test. We need to break things down into smaller and smaller function and be more focused and/or encapsulated into specific functions.

- Wayne - by learning how to do test driven philosophy... it has made his job so much more enjoyable and fulfilling. This is a life style change for programmers.

- Alan - If we go with test driven design and development... that means more dreaming on the frontend. He then said, Brandon, you will enjoy the more dreaming part of this.

- Eric - testing is sometimes dangerous being left to the original programmer. Sometimes we need a separation.

- Eric and Alan - MVC (model view controller) stuff - We have replicated things over and over again... As we get things better and better, we'll get a much cleaner code set. He really wants us to start pulling things into smaller pieces where we can get to what we need without all of the extra weight that currently exists. Think of adilas going on a code diet... we could really cut some weight and become more efficient. All we need is that little bit of logic or that little bit of validation.

- Maybe moving trims (trimming functions) out of database queries and up higher in the process. Setup the trims higher and then use all of the trimmed values as part of the re-usage. Once it becomes correct, use that value. Otherwise you could get disconnects and possibly be passing different values to different pieces without even knowing.

- One of the main goals is maintenance and starting to reform this code and application in new ways. Making the code rewrite that much more possible.

Dustin, Alan, Wayen, and I were on the morning meeting. Small demo by Wayne on object oriented coding. We were seeing all kinds of service objects, data objects, database access objects, and other models. This all goes back to the keeping the data, the validation, the business logic, and the database stuff all on different levels. That just makes the code more re-usable and more logical to follow (both internal and external). All of this makes things more modular and easy to use.

We spent a little bit of time talking about MVC's (model view controller). Each area is different. You have the model, the view, and the controller piece. They are all kept separate and run on their own levels. You can then mix them as needed. We talked about DAO's (data access objects) and using universal getters and setters to get at the data and the sub pieces of those concepts.

The guys were getting into what will and won't work and why. They were talking trade-offs of simplicity vs flexibility and other factors. Other topics ranged clear out to security, XSS (cross site scripting), SQL injections, etc. They were talking about transactional records, commits, roll-backs, try/catches, and other safety measures. They were talking table level locking, application flow, traffic, scalability, and usability.

They were talking about unit tests, global testing, and other pieces. Standalone tests, mock-ups, and sequence tests. Having their testing already ready and done really helps them to go in and change things with confidence. Test driven design and getting that peace of mind, knowing that you have a number of prebuilt and preselected tests to run on your old and new code. It is a real time saver and helps them have the confidence that things are working, even with changes.

We are changing the implementation (how things are done) vs the background core principles (why or what is being done). Pretty technical discussion. These guys are masters and are good at what they do.

We are trying to get the entire application out to the web/API socket level. We need a way to structure things and yet have modular data and open access to all.

After the demo/meeting we all split up and worked on our own projects. Steve, Alan, and Wayne kept working on some Metrc plant code. I was working on the developer's notebook project. Then after that, we jumped into a discussion about servers, virtual servers, and how to help optimize the different servers. We were talking heap sizes, through put, and other optimizing and server asset management options.

On the morning meeting with the guys. We started out with Wayne asking questions about payee/users and how they can and do criss-cross and how they can cross between corps. We talked about options and why we did what we did. We got in to migrating parts, items, and PO line items. We then has some conversation about splitting up databases, indexing, and other processes that could either optimize the data processing and data retrieval process.

Calvin and Alan popped in, they were working on labels on the content server. Alan helped Calvin wrap some of his code in a try and a catch. It was awesome and he was able to push the cfcatch variable. That allowed us to figure out what we needed to do to fix it. Super cool.

Steve and Alan - "We break things and then we fix them." Fun little saying.

Alan would like to rework the forgot password project. He wants to rework the security and how that process would work. He would like to beef things up a bit and make it more bomb proof.

Alan would also like to work with Wayne on breaking code into smaller blocks and working in a more MVC (model view controller) type model. Basically, making baby steps and making things into a more object oriented code base. Alan was talking about encapsulating and modularizing functions, data, and components. Lots of code reuse and minimal duplication. Question - Build new or build on what you have? We are leaning towards refactoring existing code vs re-writing new code. Adilas' goal is build as if for years.

We were talking about sub inventory and taking that whole new level and pushing it out into an object oriented model. We also talked about implementing Wayne's testing framework along the way with the new changes. The goal is trying to limit the number of times we are re-writing the same thing. We want to reuse code as much as possible. We talked about strengthening our foundation so that it could handle more weight and also allow for flexibility and fracturing, which will still occur, no mater what we do.

Light talks about black box code and who pays to keep it updated. There seems to be two different levels. There are critical updates and non critical (optional) updates. We need to figure out a standard procedure to deal with custom code and black box code. Sometimes, if we have a problem and we are forced to think about it, we can usually come up with a pretty good solution. If we wait too long, we are forced into emergency surgery and sometimes that is not the best approach. We want to be pro-active on our approach and on our development.

Steve and I were talking about some hanging projects... One is the invoice due dates and watching for outstanding receivables (David and Shari O. really need this). This was a Russell project that only got half baked. We need to finish it up. The goal there is for us internally, to be able to see what companies owe what and what the dating is. Then once it gets to a certain level, we could prompt for payment and/or be able to shut things off.

We also talked about how it takes a whole village to raise the upcoming generation. We are really trying to build the adilas community and adilas family. We have many talented persons who are playing the game along with us.

Random notes from the day. Brian Stewart is a friend and 30+ year computer guy and programmer. He works for a different company but we go walking and hiking together in the mornings. We talk business and code while we walk. Here are a couple of gems from today.

- There is a difference between working in your business or working on your business - Brian Stewart on a morning hike.

- Create systems... Instead of setting pass/fail goals... create a small system and then start playing the game. Success is playing the game and working the system. The results will usually end up following. - Brian Stewart on a morning hike.

- Brian and I spent quite a bit of time talking about good cop, bad cop, and helping to setup the community and environment that you want for your company. A lot of the discussion was dealing with finding that balance point between speed, function, stability, and beauty. Not everybody has the same personality and/or skill sets. Lots of mixing and blending. Some of the conversation was how to mix senior developers and junior developers and to help them play well together. Sometimes that mixing becomes an issue and also a who gets credit for what and who gets paid for what. Sometimes a tough mix.

On the morning meeting with Steve, Dustin, Alan, and Josh. We started out and got things going. Dustin is going on a trip soon and was reporting about some areas in the North East that he will be visiting. Sounds fun. Here are some other things that happened on the meeting.

- Helping Dustin with some FORM logic. He has a ton of form field data that needs to be dynamic, grouped, and passed over to an action page and still be able to maintain its complex data format and maintain its special groupings. We went through a number of scenarios and he took a number of screen shots. We talked strategy and I showed him some similar code that is used for duplicating PO's and passing dynamic data from page to page.

- Talking with Alan about the idea of on purpose allowing the view of the pages to fracture and be more controllable. We did a small graphic (drawing) and talked about how we have known form field values. We also have a known database table that could hold the data field settings such as show/hide, defaults, data types, special instructions, sort values, field name aliases, etc. We then talked about how we could potentially use ColdFusion custom tags to hold the logic to dynamically populate and/or build the HTML (web format) pages based on the custom tags. The custom tags are a combo between a function and an include. Anyways, we had a good discussion on that. Alan was saying that this plays in perfectly to the MVC (model view controller) type scenario that we would like to use. See attached for a small drawing.

- We had two other outside parties come into the meeting. We had Molly (an adilas consultant) and a guy by the name of Ryan McCorvey (a user for McCorvey's Pro Shop - Bowling). They both had similar requests. They have different pages and reports (or functions) that are hitting time outs. Both companies have tons of data and Alan and I were taking notes and looking for possible bottlenecks and either slow queries and/or slow database tables. They could do the same reports and actions with small amounts of data, the system just choked and/or timed out when trying to process too much data. Kinda like getting a huge mouth full and not being able to chew and/or swallow. Anyways, we worked with both individuals and took some notes. Alan started looking into some research on what causes those table level slow-downs and what not.

- As we get into bigger and bigger datasets, we have to play well with scalability, indexing, and being able to play the big data game. Interesting how things keep progressing.

On a GoToMeeting session with Russell. He was showing us some new and modern concepts of MVC (model view controller), object oriented pieces, full API access, getters and setters, custom skins, GUI interface, and tons of cool JSON storage stuff. Russell also had a number of ideas for the adilas fracture site and what we could do, be, show, and even become. Kinda fun. I recorded the session.

Russell would like to take adilas to a new level. Putting in standards and testing to help the process. We want to standardize without cutting off the custom code arm that we love and are used to. Adilas would be the safeguard of the data and files and content storage, we then allow, through the API sockets, the ability to sew things up and put things in any way they want. We become the major backend app and allow for customized frontend options. Dream it up, we'll wire it up.

Steve and Russell had some early conversations about custom dashboards and being able to build things with small widgets, modules, cards, windows, panels, tabs, etc. Be able to show/hide different things, be able to drag and drop features, make it super cool.

Beautiful, powerful, easy!

If you had to start all over again (virtually burn things down), what would you do different? What would you do the same? Where would you take things? Fun questions.

Steve is seeing huge needs of a integrated system out in ecommerce land. Currently, there are tons of small companies trying to build their own little piece of the puzzle, but nothing interacts and fully connects. He is also seeing a need for a single system that could be good at all of the different pieces.

Brief talks about the current adilas Snow Owl theme and where things could go with new CSS variables. Lots of JavaScript and web components. The look and feel is super important. Light talks about heading more and more towards open source code and projects. Good talk and discussion.

After the meeting, Eric jumped in and had some questions on showing some of the discount stuff. We talked about who on our team could do some more CSS stuff and finish up some of the Snow Owl functionality. We also talked about Spencer and maybe having him help with some raw CSS stuff. Maybe we could make some CSS snippets and then build from that or from there. That would be really cool. Good page or resources of the CSS and styling changes (over time). The existing CSS stuff (minus Snow Owl) exists out in https://data0.adilas.biz/css/index.cfm - It would be super cool to keep expanding some of those options... :)

Alan did a small training session on getting away from spaghetti code. - see attached for the video recording.

- Spaghetti code may be quicker at the time, but it can come back to haunt you. If you have lots of duplicate code that needs to be updated, you just made it harder on the maintenance side of things. It comes down to reuse, efficiency, layers (MVC - model, view, controller), and built-in intelligence.

- The intelligence is not in the page... it becomes a layer of abstraction (aka separation of data, logic, and visual pieces).

- In an MVC model, here are some of the pieces. The View is just the display (UI or user interface objects) - no real logic here. Just do or show this. The Controller is the underlying logic that is virtually the engine and/or the brains. This element does all of the logic and operations. It doesn't know where the data comes from, it just knows what to do with it. The Model is basically the backend data. There have been multiple conversations that talk about the view-model, the controller-model, etc. Basically, different ways to pull in the data and divide and conquer.

- Wayne Andersen has been trying to help us to head in that direction, meaning more of an MVC type model.

- Inside of adilas, we use a lot of CFC's (ColdFusion components) as a controller and/or a controller-model. We are seeing a need to break these CFC's into smaller parts and pieces.

- Alan was talking about our CFC's and how we are trying to break them up - we are starting to break things in DAO's (data access object). These could be things such as invoiceDAO, bankDAO, customerDAO, depositDAO, etc. Basically, a DAO for each topic and/or section.

- The guys would like to use existing functions, but right now, they are somewhat spread all over the system. So, they tend to re-write a new function and/or try to tweak an existing one to do everything that they needed, even though that same CFC or method may also be used in other places. It starts to create some non-efficiencies in some ways. Also, because the CFC's are somewhat spread all over, the guys may not know where to go to look for either existing pieces and/or where to put the new code. The result is, you start getting some light spaghetti coding.

- Talking about objects, classes, inheritance and how that works with code.

- Organizing things into smart objects - using methods such as create, update, remove, find by id, find all, find custom, etc. This gets into getters and setters and making the data access objects smaller and more usable. They were talking about using lists, arrays, and structs to do database queries vs writing out queries line by line. Basically, if we create methods and/or functions, then they (those new objects and their methods) start doing all of the other query operations.

- Going back to DAO's inside of adilas. Alan started talking about services. These are basically the wrapper logic that talks to DAO. For example, invoice service deals with the invoice DAO, the deposit service deals with the deposit DAO, etc.

- We talked about the existing CFC's inside of adilas. Originally they were setup in things such as assets, liabilities, maintenance, management, reports, requests, searches, security, etc. We then added numbers to those as they got bigger and bigger. For example: we have search_1 through search_15 with tons of different methods in each section. They all belong there, they just aren't very searchable. We have assets 1-13, cart 1-4, liabilities 1-7, maintenance 1 -14, etc. It is categorized, but it was setup a little bit too broad. It would be so much better if we had an invoice service that showed all methods dealing with invoices. Those invoice services would interact with the invoice DAO's. Then, if you wanted to look-up what has already been done with invoices, you would know where to go and what to do.

- Classes and classification - classes and sub classes (going from broad to more specific to even more specific or a subset within that classification set or sub set). They were talking about a sample of dogs... all dogs bark, all dogs walk, all dogs run. However, each type of dog has a slightly different bark, speed, color, size, etc. Each individual within those classes and sub classes have specific data that is tied to them. For example: Sally, the German Shepherd is going to be different than Billy the beagle. They were talking about objects, instances, etc.

- We are going to be doing more and more training as we go forward.

After the meeting, Alan, Dustin, and Russell jumped on a Zoom meeting to talk about some other options. See attached for that video as well, if you are interested. Great meeting and I think that the guys enjoyed it.

Great team training meeting today. We were working on real world problems and things we do all the time inside of adilas. We went over building form controls how we have been doing and where it could possibly go. Really fun seeing the different ways and even how we could push it clear out to the component (reusable custom code/tags) level. Lots of fun. We had Steve, Brandon, Alan, Bryan, Danny, and Josh on the call.

We spent some time going step by step and building on the last code sets. We talked about scoping variables and when to not scope the variables (scopeless). We did quite a bit of training on reduce options and the power of modularizing the components. This leads into an MVC (model, view, controller) type level with options. Good stuff.

See attached for the video.

Russell and I merged in some code and then talked about projects. We also spent some time talking about fracture stuff (where we are headed). Russell has a lot of good information there and has a dream and a vision already in his head. I'd love to capitalize on that see if we can get those ideas out of his head and on paper and/or recorded somewhere. Here are just a few things...

- Russell really wants to organize the core with specific sections. He has a drawing that he does to explain some of the pieces. Basically, imagine a center core that is round. On the top and both sides, there is a known slot where something may be inserted into it. Imagine a slot for special logic and/or a controller. Another for classes and/or a model (structure of the objects and pieces). And yet another for the visual or view portion. Somewhat of an MVC (model, view, controller) type model.

- Relating to the core with special insert points, each of the insert pieces (logic, view, what) would allow for both industry specific code and custom code. Basically, You set the core up so that it can and is able to handle things (code, views, logic, other objects) that change the core without hurting the core.

- Along those same lines, for fracture, Russell would like to have two different types of API's - One would be a rest (URL or path based) API. The other API socket would be for things like graph QL or some other type of API socket.

- One of the goals of this new interface and/or application would be to have the ability to reach out to other industries and be able to swap out the pieces to virtually make the application or platform switch clothes or be able to change as if the application was switching clothes and/or modes of operation. Dynamic core, known plug-ins per industry, and ability to flip/flop without affecting the core. On purpose built that way.

- What if we could... be able to... handle all custom needs? Be able to handle all industry specific needs and all core needs? That would be a very flexible and dynamic architecture and/or design. We want to head in that direction.

- We used to say something like... You dream it up, we'll help you wire it up. What if you could say, Dream it up, you wire it up? Basically, give the power to wire it up to the persons who are using it... That would be so cool. Real live world building and/or setting up their own data assembly lines. That would be super cool.

- Headless CMS (content management systems) - Headless CMS storage for your data. We offer a huge and configurable database and backend app or toolset. You get to decide how you want to use it and what you want to do with it.

- Along those same lines... if we want to reskin the app for a different industry, we do the same thing that our users do, we just do it in bulk to accommodate more than just one company at a time (think bulk setting changes and/or industry specific themes or modules). It is still a headless CMS storage system for your data and your business flow. It just deals with are we configuring it or are you (as a company or user) configuring it. We both use the same tools.

Danny and Steve were talking about sales and having a buddy along with you. If you are all by yourself, you tend to get depressed and demotivated - in some ways. A buddy really helps to pick you up and bounce things off of. You don't feel like you are alone.

Eric joined and was asking about building out some of the off balance sheet items and off sheet liabilities for customer loyalty points. Basically, a real liability but not part of the main math on the balance sheet. We also briefly talked about watchers, feeders, and triggers. See this link form some other research on the subject. They were also talking about how 3rd party integrations get really tough and you can't take them out the full way just because things get so deep.

Steve and Eric were talking about the pricing engine, the discount engine, tiered pricing - lots of options there. They were talking about expanding parent attributes, smart group buttons, dynamic QR codes, barcodes, and advanced label options. All tied in with pricing, labels, and tiered pricing.

The topic changed into some project management and project planning options. Including a list of requirements, scenarios, design options, and the whole meal deal. Looking beyond the current project and how it, the current project, plays into the bigger whole (system thinking). Once we know the project scope, we could then setup timelines and estimates. You have to have all of the pieces in order to really provide the whole meal deal.

After Eric left, Wayne, Alan, and myself were talking about frameworks and options for code and building code. A framework is a standard way of calling things, linking to things, ways of storing and organizing assets, and all the way into deeper hierarchical levels. They were talking about a product called ColdBox and how that may play into the mix. Most frameworks use some sort of MVC type model. Here are some other related topics to MVC (model view controller). An HMVC is a hierarchical model view controller.

Lots of pros and cons were being discussed. Including who will do the research, experimenting, deciding, training and teaching - once a decision is made? What do frameworks do? What do they not do? How can you customize them and what tasks fit nicely under a framework type model? We also talked about our existing, home grown framework and how that works. Alan had a number of really good questions and seemed very versed on the subject. Good discussion.

Our last topic for this meeting was an error with file uploads and images. Wayne is going to go in and add some logging and see if that helps us figure things out. It doesn't happen all the time, we are trying to figure out what it is that causes the errors. One of the tough ones...

2/8/23 created video.

1/24/23 created video.

1/23/23 checked and pushed with Brandon

Through 4/14/: 46.29

Through 3/1: 173.39 hours

12/21 through 1/22: 62.93 for JM

2/3/21: 35hrs
1/4/21: 15.59 hours for JM
12/14/2020: Brandon and John M will start meeting this week to get the ball rolling.

Chuck joined Sean and Marisa on the last little bit of the other meeting. We were going over financials, accounts payable, and accounts receivable. Lots of fun showing numbers and some of their trends. Lots of drawing on the screen.

Both Sean and Marisa had to bail out and so just Chuck and I kept going. We switched gears and talked about the add/edit media/content pages that Chuck is working on (small page level facelift on certain pages). We also briefly talked about maybe using a JS framework (JavaScript) for the next version of adilas. Eventually, we really want to allocate some time, funds, energy, and resources to work on the fracture project. We are hoping that that could be part of our plans going forward. Even if it is a little bit here and there, we would take it and run with it. One of our first main goals is to create a plan and then be able to pitch the pitch. No new code, just mock-ups, requirements, prototypes, and proof of concept stuff. We really want a great plan and then to be able to do and build what we are hoping and dreaming about.

Along those same lines, Chuck was talking about making sure that our application has multiple layers. The database level (dao's - database access objects), the middle layer (business logic, models, and services - object oriented pieces), we then need an interchangeable display or show level (visual wrapper, themes, custom, or even white label options). If we build it out that way, the 2 lower levels could be almost untouched, even if we had to redo the upper or display level. Sometimes that is called the view level. It goes deeper than this, but an older acronym is MVC (model, view, controller). There are more modern versions of that now, but that is all that would come to my mind as I was recording this. Long story made short, keep the data, logic, and display levels as separate pieces and you are heading in a good direction.

Chuck and I were talking about using setup wizards and easy setup steps to virtually walk people through complex or involved processes. We covered a bunch of different topics today. One of them was MVC or model view controllers and how splitting things into different levels allows for more modular code. The thing that changes the most is the view model (display). The other pieces tend to stay fairly similar without huge changes between versions. Chuck would like me to speak with his wife about some of those different levels and some tips and tricks on keeping them separate. She worked with a client that does government work and they were setup with really good deafferentation between data layers, business logic layers, and view or display layers. She is also familiar with a number of different frameworks and possible options there.

As we were talking, Chuck said that one of his goals is going to be working on layouts, use of whitespace, and number of clicks to get something done and finished. Those sounded like good goals to look into and work on for adilas projects. Next, we chatted about navigation, layouts, and the concept of an artist with a pallet and being able to change the layout and control your space (work environment). Sometimes the word space is too deep for people to grasp. They think of stars and constellations. We are currently talking more about personal space and configuring your own environment or working space (homepages, nav options, preferences, dashboards, etc.). Chuck would love to help develop some really cool dashboards and such. That would be awesome.

More talk about wizards and easy bulk setup options. We would love to configure some almost hands-free setup options. Think of what a cost saving this would be. Basically, if we could make the setup easier, we could eliminate some large costs and time savings by letting the users set it up themselves. That is still a long way out, but a great goal. Along those lines, we were talking about how both settings and permissions really need to dictate displays, options, and work spaces. If we did it well enough, we could even offer a free trial or something along those lines. Right now, it takes too much to setup it all up and get someone trained. We can't do it for free because it takes someone who know the system to setup it up, configure it, and get the people trained on it.

If we could get things done in bulk or through simple handholding wizards, that would really help the process. Those handrails or wizards turn mountains into smaller icebergs (perception of what is there to take in or acknowledge). We talked about some possible mini apps or standalone modules for the current adilas platform. Timeclocks, timecards, uers, payroll, expense tracking, point of sale, CRM (customer relationship management), ecommerce, etc. All of the main 12 business functions. Fun little meeting and some good ideas. We would like to include and even start working on the fracture project with some of these ideas. That is and has been a big goal and driving force for what we are doing. What is the next step and how can we get there?

Looking over code for gift cards. Checking emails. Ended up pushing up some code and ran into a problem (crossing two code branches). Eric joined, Wayne joined, and we ended up rolling things backwards (back to the master branch). We talked about the need for unit testing as well as integration testing. Eric and Wayne were talking about software lifecycles and us maturing as a company. We are getting better and better but still need some improvements.

We could use some internal training on writing tests and how best to make sure that we have good coverage. We have so many different levels of coding skills (junior devs, senior devs, full stack devs, designers, etc.). We got into a big conversation about where certain logic needs to go and how best to handle errors and logic for checking for record counts.

That lead into a conversation about MVC (model, view, controllers) and how we are currently doing some of that but we are also mixing things. For example: We have some of the view and the controller in-line or on the same page. Some of our logic is intermixed with the display vs the business logic. Some of the code is older and some of it is newer. We need to make some plans and then go and head in that direction. Currently, we tend to go in a number of different directions. It gets done, but it looks more like patchwork vs tight, smooth, standardized code. Getting a plan and being united in that rollout, even if we have to do a little bit at a time, would be awesome for our fracture project and plans.

Wayne, John, Cory, and I on the server meeting. Talking about tech support at our hosting company. Wayne gave John some more permissions in the hosting environment. Wayne is working on a side project in ColdBox and testing out a new ColdFusion specific framework. We talked about doing upgrades and upgrading from some of our older code. Ideally, we are moving more to an MVC framework (model, view, controller) with tons of new options. Currently, we are mixing code with some older libraries and dependencies. Our goal is going to be making fully independent pages and pieces.

Constant process of upgrading our stuff. Conversation about upgrading and what technologies we are using. Are we upgrading with older tech or with the newer more modern tech. We are trying to plan for our future clients. Wayne and John were going over options for switching databases. After that, Cory and John were going over data layouts and small requests. They spent some time talking about different projects. Cory and I did some checking on some custom reports and additional requests for more data and more settings.

Meeting with Wayne, Cory, Steve, and Shari O. over a Zoom meeting. Talking about Wayne wanting to retire by the end of the year. He was reporting on his research and plans with the ColdBox framework from Ortus Solutions. I took a bunch of notes...

- Our development process – it's too difficult and hard to test

- Be able to make a plan, set some goals, requirements, and then be able to hand that off to a developer

- Unit testing

- Our product is super complicated

- Spaghetti code

- Included files – they are all over the place

- Knowing where to put things – tops, headers, body files, footers, etc.

- Spend a bunch of time developing and then spend more time trying to get the code actually launched.

- Our development process takes a long time and causes frustration to our team and our clients

- Back to included files

- Different processes – ways of using the page

- Element is undefined in xyz scope – session, variables, FORM, URL, application, arguments

- Things get lost

- Paths – all kinds - ../, ../../, other paths – that creates problems in different pages that are included in different pages

- Wayne talking about global variables and global listings

- Setting up a standard framework and setting up standard practices

- Even though our code is older, it has really gone a long way

- Because of the way that it is coded, it makes it harder for progression and ways to hand it off

- Steve wants to sell the cool-aid (our current product)

- Triage – what needs our attention first? Life threating things first.

- Steve was talking about some of the developers being lazy – kinda getting frustrated

- Wayne is trying to solve some of those problems and/or issues – he wants to show us some concrete evidence and ways to solve things.

- Some of our developers are up against the wall and doing the best that they can.

- Wayne would like to make our code as simple as possible – guide or a recipe type level

- Cory – to rewrite the entire adilas application – that would take years and years and thousands and thousands of dollars (millions – plural).

- Cory – What about clients who want changes to their current system?

- Steve – How does object-oriented programming play into this? MVC – model, view, controllers – classes, sub classes, view models, controllers

- Wayne really thinks that he could crank out some major changes in a hard month - at least a good indicator or model

- Tons of little maintenance stuff is already baked into the framework

- In our current code, we have so much validation, permissions, and sub logic work – 75% of the whole thing is error handling and validation.

- Cory – If Wayne leaves, what is the reliance on him and the framework? Wayne thinks that it will be even easier and work better – even for the long haul.

- Wayne – Open-source projects and making the framework better – he has contributed already to the main code branch and has had some of his code accepted.

- Steve – Can we do this little by little? Wayne – Sort of – It would be better to get it all done so that we are operating in a different environment.

- Steve – What about docker? Wayne – We would use docker for the main ColdFusion stuff for the servers – Not tied to the current ColdBox framework.

- Steve asking about the datasource project (bus to individual motorcycle). – Wayne was saying how we could do some work to eliminate the reliance on the primary key – Turn everything into combo keys vs the single primary key id. All of the tables could be intermixed with combo keys.

- Steve – We may need to abandon some of the old ways of doing things

- Wayne – Even our database structure needs to be updated and changed. It is built in the older style. Technology changes over time, speed, computing power, etc.

- Steve – We need to be careful where we go, because changes do happen – all the time. Skate to where the puck should be.

- More than one way to skin the cat – If it doesn't work, we could go a different direction.

- Wayne wanted to get a fully working prototype done and finished up before he showed us what was available.

- Wayne is starting on the payee level login as his first few pieces and pages. He wants to get it all ready and documented before we just jump. Wayne is still learning as well.

- Cory is glad that we are talking about this – She would love to see our developers be more efficient and get stuff done.

- Wayne – He feels this is something that has to happen. We need this as part of our solution. Looking forward, we almost don't have a choice.

- Steve – Wayne, you are part of the ownership of this company – Let's make it good for everyone. He was encouraging Wayne to keep going and even setting up the next meeting to show us more.

- Cory asked how Wayne found this framework stuff. Wayne explained how he found things.

- Wayne did a small little dog and pony show on some of his code. Showing rules, routines, variables, and lists.

- Steve and Cory – They both think that Wayne should keep going and bill as he does his work. We also want to make sure that John is up to speed.

- This is a personal investment on Wayne's part – building the future of adilas.

- Wayne has been using Toggl time tracking to keep track of his hours.

- Just for fun – Wayne wants to get it done well enough that we want to write him a check… :)

- Documentation on how you do things – Ortus books and live samples

- Hoping to save money, keep our clients happy, and have a stable product.

- Cory – you have to change to grow. Things that don't grow die.

Long meeting today. Started out talking to Wayne and Shari O. about emails, internal emails, external emails (outbound to different clients), and possible options. Wayne repointed the IP addresses yesterday back to the original way we had the email system setup. It was kinda wacky for a couple of days. Anyways, we put it back to what it was. We still need to look deeper into this, but it should be stable for now.

Steve was asking about the bus to motorcycle project - datasource or world building project. Wayne was reporting that some of his new code is trying to deal with this issue or these issues. We talked about the current state and where things are going. Briefly touched base on combo primary keys and removing major dependencies on existing standalone primary keys (database connection and relationship stuff). Along with the datasource topic (which database to talk to as a single time) the conversation also included our ever growing need to do cross corp stuff. We didn't talk about it, but some of this is very similar to the adilas cafe talks and discussions that we have had.

If we get majorly into cross corp stuff, and each corp has its own database or sandbox, we may end up doing cross corp stuff through API socket connections. That sounded like a good idea. We'll have to look at it, as we may do unions, API sockets, or other temp database tricks to show and/or report combined data.

We flipped over to the new framework that Wayne is working on. He did a small demo for us on what he is working on. These are just a few of my notes. See attached for a 1:39 - one hour and 39 minute video of of some of meeting.

- Our switch to a new framework is not just a time saver. It goes way deeper than that.

- Lots of conversation about supporting different frameworks, themes, and versions of code.

- The whole new framework is setup as an MVC framework or MVC model - model, view, controller

- We need to keep moving forward in order to stay valid

- Layouts and views

- Everything is event driven

- We have both raw input (info and data directly from a user or customer) and we also have cleaned up and formatted data (okayed, approved, combed, retrieved, or sanitized data).

- These are just some keywords and concepts - handlers, events, models, interceptors, layouts, views, classes, methods, etc.

- One of the goals is to get rid of all of the repetitive, ticky-tacky maintenance code. This is stuff like params, validation, permission checks, making sure that certain values have been set, etc. Basically, the prep work before the real meat of the page begins. Some of our pages may be hundreds of lines of code deep before we actually get to the meat of the page. The framework would help us simplify and standardize some of the prep work stuff.

- If we build this way, it could open up options for multiple layouts and/or views (what it looks like). Keeping a separation between the business logic and the view or presentation of that data.

- Events, watchers, and triggers that help us run clean-up and other processes and routines. Key everything off of certain events.

- Getters and setters - smaller mini functions for each class, object, and property within that class. All built-in and/or available. We really wanted to do this for the fracture project (future project for adilas).

- Options for self-documentation

- Debugging, tracer options, logging, and security stuff already built-in

- Lots of talk about the benefits of using a framework.

- Mementos and smaller sub sets of data, that may be pre-formatted and/or setup how we need it - saving time in conversions and retrieving available data.

- Defining things and then using them over and over again in other pages.

- This is huge, but the framework already has a ton of built-in documentation and samples. That takes a lot of work and preparation. Also, it is able to self-generate basic documentation based on how we code it (based off of keywords, hints, notes, and rules).

- If we build off a new framework, we could use either Adobe ColdFusion (current model) or we could use Lucee - open source CFML engine. The framework can flip flop pretty easily between the different backend engines. It's basically a config option.

- We do lots of things over and over again. Make that more simple, standardized, and compartmentalized.

- They offer a standard set of options and configurations. We can use that and/or pick and choose or customize whatever we want.

- Light talks about the pros and cons of an ORM model (object-relational mapping - mixing of objects and relational databases)

- Shooting for a more modern approach - use of code, technology, and a layered approach

- Wayne really wants to come up with a process of how to convert our current pages and code into the ColdBox framework. Think of a set of instructions (virtual recipe) and then allow other developers to help convert the pages. Basically, a road map to follow.

- Our customers really need and want us to be more stable and reliable, as a company, and as a software system. This includes how we develop code, release and deploy code, and manage systems and servers. In a nutshell, they want us to grow up, as a company and have a bit more of a standard structure and presence.

- We are heading more and more towards clustering, enterprise level stuff. We need to build towards that.

- As a side note, Wayne says we have way too many includes (files that get included and/or strung together to make the whole).

- One of our major focuses on switching the backend architecture is customer reliability.

- Wayne sees a need for radical changes to simplify, stabilize, and build things out for the future. It has to be sustainable and sustainability. Light talks about evolution vs revolution or changes over time vs drastic changes all at once. Things are smoother if software can evolve vs just being harshly changed. However, sometime things need to majorly change, hopefully for the better. There are some pros and cons to both approaches.

- Building new has a motivation factor to it - true story - what keeps us going?

- This is a chance to rebuild it like we want it - build to the dream

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

We switched subjects and were the guys were talking about hosting companies and how that scene is changing in the datacenters that we are using. We have seen a lack or lowing of the customer service levels. We may end up checking out some other hosting companies.

John and Cory were talking about other projects and timelines. They were also talking about uptime, downtime, and databases. We talked about coming up with new SOP (standard operating procedures) for pushing up code, code rollbacks, and deployment of new features. That got into talks about manual and automated database updates, scripts, auto processes.

That topic lead to a discussion on roles and responsibilities and who does what. There is a need to define some of the roles a little bit deeper and make it clearer who does what and in what order. More SOP stuff for the backend processes and procedures. There also needs to be good communication between the developers and the system admin persons. We have to keep up those communication channels. That is really important. Nobody can read minds.

Towards the end, John and Cory were going over projects and coordinating dates/times for testing, review, look and feel changes, and testing. Good stuff.

Eric joined the server meeting and we were talking about the sales tax aggregates and what kind of love is needed there. It's up, working, and just needs a little bit to really be fully functional. We talked about getting that code outside of the database triggers and being able to do manual or force updates. We spent 40 minutes going over pros and cons of automated database triggers, manual switches, scheduled tasks, and how best to tackle the aggregate counts, totals, and sums. We only have a few things aggregated right now, but a ton more options are on the horizon.

We then switched to the backend and frontend frameworks that we are looking into. We got into a conversation about technical debt (older or legacy code) and where we are headed. We really want to move more into an MVC (model, view, controller) type framework and application. We would like to change the main structure and underlying conventions that we are built upon. This brought up conversations about breaking the link between view pages, model pages, and controller pages.

Cory was saying that we beat the odds of how long we have lasted on our older code set, and lifecycle as a software company. We are really good at building new things. We would like to get better at planning and strategically doing maintenance and upgrades to the core and/or foundation. Ideally, we want to take some of our older, bigger, monolith code and break it up into smaller and smaller pieces. Things like helper files, microservices, MVC models, and restful API sockets. We already do a bunch of that, but the whole thing is not yet fully there.

Our guys (developers) keep running into things that are slightly off and/or could be changed. Sometimes, that makes them slowdown and either figure out what was done and/or them wanting to fix it, to make it smoother or better. There is a maintenance cost associated with training and learning. Sometimes you only learn by dinking around and playing with things (experiments and trystorming).

We may need to get some funding in place, even to help make the plan. This has been one of the things that has been missing all along (lack of funding). Sometimes, it also feels like we need some fresh blood (new energy or new talent). We are all getting a little bit older and have been pulling this load for quite some time now. That ends up wearing on you, even if that wasn't the intent. As long as we are talking about some ideals, we would love for our code to be more robust, less fragile, and easier to make global changes. There are a lot of intricate and moving pieces. As an idea, maybe we trim our team down and keep a smaller, highly talented, but nimble developer team. We are not sure where to go. It's always a balance.

Steve was asking Wayne some great questions. We are trying to figure out a plan for making the plan. It gets deep quickly. Steve was also asking about the datasource project and where that stands (looking for a progress report).

Working with Alan on ship B, fracture, and adilas lite stuff. We were reporting on what we have been doing and who is doing what. Alan has been digging in deeper and checking out ColdBox, CommandBox, React, VueJS (vue), and other code frameworks. I took a few screenshots of his notes (see attached). Here are some other topics that we talked about:

- We would like to organize the features that we want to include and build out. Still on the wish list - to get this done and all organized

- Code style guides

- Features of CommandBox and ColdBox - products by Ortus Solutions - automation with Git (code repository stuff), sanitizing, formatting, and standardizing data and code.

- Alan is leaning towards VueJS vs React JS. We went over some pros and cons.

- Our current choice or pick for our tech stack is looking something like this: CommandBox, ColdBox, Lucee/ColdFusion, MSQL, Bootstrap 5, and VueJS.

- Lots of talk about routing, events, handlers, and MVC layers and levels (MVC = model view controller framework or methodology).

- Integrated testing for integration test and unit testing.

- Custom layouts

- Lots of white labeling options and data driven design and data driven settings.

- Nesting or sub architecture and modules - inheriting different things

- Little baby apps or configurable widgets

- Building out prototypes and playing with concepts, ideas, and options

- Layers and everything going through API sockets or API endpoints

- We would love to get into drag and drop widgets and options to create your own layouts. This would allow for either preset widgets or mini widgets that could be places, configured, and added to dashboards as needed. Super cool!

- Use of popup modals and one-pager type interfaces.

- We want tons of asynchronous type actions and transactions. Certain things need to flow step by step, but other things can be done asynchronously.

- To start out with, maybe a light mode and dark mode, to keep it simple. We may add more other custom look and feel options later on.

- Doing wireframes and then rolling over to actual mock-ups.

- We would like to look at some of our past R&D options from Jonathan Wells (designer and prototype guy).