Basic Assignments
 
Options & Settings
 
Main Time Information
Color Code: Yellow
Assigned To: Brandon Moore
Created By: Brandon Moore
Created Date/Time: 5/25/2023 2:07 pm
 
Action Status: Blank (new)
Show On The Web: Yes - (public)
Priority: 0
 
Time Id: 10177
Template/Type: Brandon Time
Title/Caption: Framework meeting with Wayne and Alan
Start Date/Time: 5/23/2023 11:45 am
End Date/Time: 5/23/2023 2:30 pm
Main Status: Active

Sorry, no photos available for this element of time.


Notes:

After the server meeting, just Wayne, Alan, and I stayed on to go more in-depth on the framework stuff that Wayne is testing, trying, and pitching. Wayne has been spending tons of time looking into the ColdBox framework and experimenting with things. He's really going for it.

We talked about files, folders, and structure of how the application could and would work. The whole thing is setup in a rest type interface with specific paths, pages, and URL's (web addresses) to make it work. REST API or RESTful API architecture stands for representational state transfer. Basically, that deals with logical paths, files, and folders to create organization. You then place special code at each end point to do a specific task. That is part of the way it is organized. Our old site has tons of pages, all bunched into a couple of folders (all mixed together). When I say a ton of files, I'm talking thousands of files. This newer site will have like or similar pieces and pages in specific spots or places. It's all part of how it gets organized and managed. Interesting.

Alan and Wayne were talking about object-oriented coding with options for extending, inheriting, and sub classing functions, variables, and conditions. They both fully get it. I haven't had any formal training on this, but I'm picking up some of the pieces and concepts.

Next, they got into talking about limiting the handlers (receiving pages or virtual doors and windows). We covered a number of other topics such as nesting, sub classes, pre and post level page handlers, and how all deeper business logic needs to be over in the service models. Once again, it was mostly Wayne and Alan talking shop and I was listening. To translate, our existing site and pages have a bunch of things that we do every time to make sure that the page gets valid information. They are talking about doing all of that pre validation and logic as a simple handler and thus making each page smaller and not duplicating code (hundreds of lines per page).

After talking for a while, Wayne was showing us what it takes to rewrite things and pages using the new architecture and structure. We kept jumping off on tangents as Wayne was explaining and we were asking questions and making comments. Fun little interchange. At one point, Wayne had to either jump off and/or deal with something at his home. Alan and I were talking about options for permissions and limiting things even before we show them. Keeping things skinny and lite.

Here are some of my other notes. They don't really flow into nice paragraphs.

- Currently, our main pages, inside of adilas are kinda like handlers. We just don't call them that. Sometimes we call them the wrapper pages and string together some black box and/or special page includes to make it all work.

- All business logic would need to be in the services.

- Lots of talk about separating logic and views (pages).

- Using fracture (potentially more complicated) to show less (looks more simple - based on show/hide settings and configuration stuff).

- Creating rule books and using the database to help drive the pages, logic, rules, and procedures. Basically, the code gets stored in the database, where it could be updated, shared, or tweaked as needed. The pages just process the rules and/or instructions.

- Migrating data, seeding things (pre work and adding things for setup), checking for pending actions, and processing different actions. Small data assembly line stuff, for our own setup and configuration. That could be pretty cool!

- Wayne was saying, not really rewriting our code, more of moving it...

- Alan would love to help with this restructure project.

- We talked about options of how to integrate these things together.

- There are still some core changes that are needed. The key word was "core".

- Lots of talk about scale - how fast, how many, etc.

- Too many includes (code pages pulled into other code pages). This gets hard to trace down dependencies and variations if different pages are mixed together.

- We have some master copy and paste coders and developers. If that is the case, let's help them out so that they can copy and paste what we want them to do and use. If you can't beat them (some of our team may never change), then join them type attitude (give them good stuff to copy and paste).

- Tiny servlets and micro services. Everything is based off of time or events.

- We talked about budgets for both time and money. How quick can we do this? Time, money, resources?

- How long do we have if we don't do this? Not sure... meaning making changes and/or moving things over towards fracture (future plans and making the changes listed). Just part of our discussion.

- Wayne will reach out to Ortus Solutions (maker of the ColdBox framework) and see what options we have. Is there any way to use some of what they have and still keep some of our older existing stuff? We are looking for a middle ground, if possible. Basically, just a quick check to see if an option exists - mixing old code and new code and old structure and new structure. We may have to just choose one or the other, they may not cross or mingle very well (water and oil).

- Small story of how the Utah pioneers had to stop building a temple so that they could finish up the railroad. Once the railroad was done (lines completed) they were able to build their temple faster using the railroad to haul rock from the quarry to the temple site. Fun story.

- We talked about a new possible name for fracture (current code name for our future build out) and/or something that has a nice ring to it. We were thinking about "adilas lite" or something along those lines.

- What about building out a mini version, creating small modules and then charging for those pieces? Everything could be broken down into modules and sub modules.

- Originally, we were going to leave the existing adilas code alone and build something new, using the same database. As we were talking, it became apparent that we needed to build new. Meaning new code, new data, new database, new, new, new. The whole thing. As we were talking, we kept referring to ship A (existing adilas platform) and ship B (new or future adilas platform - aka fracture or adilas lite).

- Our first prototype, that Wayne is already working on, will be for payees. This is for vendors and users and will include a single sign-on option. Once again, just a prototype and proof of concept.

- Lots of great conversation about the adilas cafe and community. This is dealing with a global or master level list and access to the whole platform and/or adilas application. Imagine a single global login and then you could choose if you wanted to work (only show corporations where you have permissions and access), play (demo sites), buy things (marketplace), sell things (marketplace for goods and services - professional services), participate (community and social media stuff), and/or get some training (adilas university). Here is a link to more info and research on the adilas cafe from the developer's notebook.

- After Alan left, I talked with Wayne about percentage ownership stuff in adilas. Wayne would like to get some more ownership. He's doing a great job! We have many on our team that are really pulling the load very well. That is awesome!

- For me - adilas lite - make a simple play or plan. It could be a rough sketch or simple layout plan. Keep it simple.