all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||||||||
|
|
|
Yellow
|
|
|
Sorry, no photos available for this element of time.
|
|
|
|
Uploaded Media/Content & Other Files
(3)
|
||||
| Media Name | File Type | Date | Description | |
| we_are_already_using_object_oriented_concepts.jpg | Image/JPEG | 7/17/2017 |
As the meeting progressed... we started talking about how we already starting to use object oriented programming. Our model will need to be a mixed bag vs. a single threaded solution. See the actual page https://data0.adilas.biz/adilas_for_business/photo_gallery_full.cfm for more info. As a side note, each photo has a small caption under it... there is a lot of good info there. |
|
| ideas_on_teams_and_changing_the_structure.jpg | Image/JPEG | 7/17/2017 | As our conversation progressed, we determined that we may need both a code change and a personnel change. This drawing was made while we were talking about the dynamic environment that we are in and how we need to organize and make some changes. See the main element of time for more details. | |
| ideas_for_the_new_adilas_model.jpg | Image/JPEG | 7/17/2017 |
Steve and I were talking about possible new models for what we wanted adilas to be. We talked about how we have already gone through about 9 different versions. We talked about how the development process goes and how things get added on and then interconnected as things get built.
As part of the conversion, we talked about how the new pages would really benefit from having a bunch of new features. Some of them have abbreviations (for speed while drawing), but here is a better list of what each one means. - part of a platform - built on a framework - able to export data to all levels and formats - black boxes (able to plug in custom code) - full validation - run on the API socket level - separate display and logic - separate databases - dynamic naming for all database fields - in-line database extensions - object oriented programming - built on time and running all levels through time and space (data assembly line) - 3D world building |
|
|
Notes:
|
|
On the morning GoToMeeting session with Steve and Alan. We started out and were talking about ideas for moving to the next level. We were talking about needs per page. We came up with some ideas such as: - part of a platform - built on a framework - able to export data to all levels and formats - black boxes (able to plug in custom code) - full validation - run on the API socket level - separate display and logic - separate databases - dynamic naming for all database fields - in-line database extensions - object oriented programming - built on time and running all levels through time and space (data assembly line) - 3D world building Steve had a question... Do we keep evolving what we have and keep patching and fixing or do we do a full rewrite and fully restructure things? This is not a new question, but it keeps coming up. Do we build on what we have or do we rewrite and virtually start over? We have so many options, it is somewhat overwhelming to new comers. That tends to require lots of training and setup. One of our main pieces is how customizable we can be. That is a big selling point for our system. One of the challenges is that we use tons of other outside libraries for code, what happens if those libraries go down or are no longer supported? We need both the electric elevators and the manual doors with staircases... We have to have options to do both manual and automated functions. That is really important. Our main focus used to be just functionality... it seems to be changing gears and is getting more end user oriented. We have to maintain a balance between functionality and user interface. That is always a challenge. We keep seeing things "fracture" right and left. The deeper we go, the more things break into subs and subs of subs. As a funny note, on 6/22/17 Steve proposed a new company name (just for fun). He was calling it "Fracture". Kinda funny. Alan and Steve were talking about new trends such as predictive typing, JQuery, Ajax, JavaScript, API socket stuff, object oriented programming, etc. We have to mix and blend tons of different ideas. Kinda like a painter having a pallet of tools, colors, and ideas. We are very good at slowly cascading features across the site. Maybe we just keep doing that... The main draw back is the time it takes to do that... Steve would really like to keep the adilas team as a small tight strategic group vs. a huge multi level corporation. Once again, it will be a balancing act. Keep the vision going! We will just keep working on it every day. Instead of jumping to a full rewrite... what if we do a full "continue rewrite". Adilas is a giant idea farm. We just need to keep going and harvesting those ideas. As a side note, we don't really fit into some of the standard software models. Our model has been a continual rewrite process vs. a staged or version based release. Our product has been the same price with all of the new functionality - almost free upgrades. We release new features almost weekly or monthly. A more traditional method might be a full rewrite per year or every other year. We are releasing on a weekly or monthly rate. There are days that we push multiple different releases in a single day. Pretty crazy. We are seeing that the new changes we want to implement have both a code aspect and a personnel aspect. There may need to be some changes on the teams and how the people are organized. Here are some other things that we are seeing... - We need to get all of the code into one repository (master). Currently, we only have some of the pieces. If we wanted to make a global change... we would miss some of the custom stuff. We need to pull it all together. - We need to go over the CFC's and pull related pieces into similar files. Currently, the methods and functions are organized but all together in a general clump. We would love to have folders for all main pieces such as customers, invoices, quotes, PO's, etc. We then want to pull all of the CFC's into specific pieces that have like and/or related pieces. We could also just make a special page that shows the mapping of where those pieces are. If it is organized, you could get there really easy. It doesn't have to be in the exact same sport. Maybe think of mapping and/or documentation of where things are at vs. physically moving things around (this idea came later on in the discussion). - We might need to restructure how the files and folders are organized. See element of time # 2870 for more details. - At some point, we may need to form our independent developers into lightly structured teams, leads, and managers of sorts. - As a side note, we could start changing the structure without changing every aspect. Currently all core code is under the top_secret folder. We could use that as a research library. What if we created a new folder and started to organize things better? We could still use the same database, just start changing the structure from the inside out. This could play into the concept of the continual rewrite idea but could really help with the structure of the whole. We have a ton of key players... all doing different things... all have different ideas... but we never really get together. Maybe a monthly meeting would be good with an agenda and letting all of the key players know what is going on. That could really help. Keep experimenting on the side. There may not be a silver bullet or specific answer... just keep working on it every day. As we kept talking about it... we jumped out to the photo gallery that Russell helped us make from the developers notebook. We are actually trying to do a form of object oriented programming and it is developing as we go. See attached for a quick screen shot. Keep your options open... You may not want to force everything into the same space. Don't wreck your toolbox by forcing it. We may gain a ton of advantage by using tons of different tools vs. forcing it into a perfectly standard model. We might benefit by the hybrid type model. We are seeing the clients' role being a huge part of the puzzle. They are basically saying that they want their own custom unified system that works and flows as they want and see. Our users are getting drunk on technology. They want more control. This could be settings, permissions, controls, rules, views, displays, logic, flow, etc. We are seeing small projects that are being built out... as we get more pieces, our clients and/or our developers are seeing new places to build bridges between the different pieces. Adilas is becoming a cluster of bridges. Maybe we keep allowing that. Our answer may be what Shannon said way back... "How we run adilas may need to be as flexible as adilas itself." We run a hybrid model. What if we strip out the best pieces of object oriented programming or other pieces that we want. We basically harvest whatever pieces we need. We just organize things and then create a virtual mapping. It doesn't really matter where things are as long as we come together to get things done. Think of our developers - I'm in Utah, Steve is in Colorado, and Alan was in California. We all came together to have our meeting. We need a platform or interface that pulls from all of the different pieces. We mix and blend things together to get the final output or desired outcome. Kinda like our analogy of funnels and tool boxes. You set up a funnel of what is coming in (data, logic, needs, etc.). You then use the tools to get what you need out of the system. You can repeat this over and over again and/or even use reverse logic as needed. See the photo gallery for ideas on funnels and toolboxes. Mix and blend as needed. Basically, setup the possible options and then let the users mix and blend as needed. Don't draw all of the lines (possible solutions)... leave it open and let them mix and blend as needed. If our clients want a more specific or structured flow process, we send that over to custom code. We are harnessing our ideas and concepts little by little. No more batches... even on rolling out new features and implementing some our ideas... no more batching... apply bits and pieces as we go. That is the model. We can't have tomorrow without the yesterdays. See attached for a couple of screen shots. |