Dan Card

We're starting to move from the high level overview and more into the details of our project.  Architecture We established that we using React as our front end technology and ColdFusion as our server side. At a more granular level, we'll be using React with Redux for our front end app and we want our server side to be not just "ajax" enabled but a true REST API. To this end, we're going to incorporate Coldbox from Ortus Solutions. Repos These two code bases have different needs, and possibly locations, when they are deployed. As a result, we're going to have two repositories: one for the React and another for the API. This will allow us to keep our code separated and cleaner all the way through to deployment.  For each of these repos, we'll follow the procedure we laid out previously with the MASTER branch being used to deploy to production and a DEVELOPMENT branch being used for active work which is then fed into the Master branch via pull requests.  Test...

Part of the CI/CD Development Series Once we have our Deployment Diagram designed, we need to figure out out to get from here to there. If the end point is the appropriate server environment, the starting point is the developer with his/her hand on the keyboard. These steps take place on a variety of machines, within various process and can changes based on what files are checked in or not. At the moment, we've only created the early basics as seen below. The Beginning of our Deployment Activity Chart Even though there is quite a long way to go there are some elements which we have already been determined. For example We have determined the broad strokes of our technology stack. This is going to be React on the front end and ColdFusion on the server side. We have determined that we are going to be using linting on both the CF and React paths. CFLint for the CF and ESLint for the Javascript We have determined that we are going to be formatters - CFFormat for CF and...

Part of the CI/CD Development Series A UML Deployment Diagram is a static picture that shows the different "nodes" that work together to create an environment. Typically these nodes consist of hardware, software or other key points. It's a high level overview, just enough detail to get the idea across of the layout without getting too lost in the details. These are the three deployment diagrams for our project. Production The production deployment is more elaborate than the other two below. Our project has a React front end which means that in addition to images and CSS files, it will also have a largish number of Javascript files. All of these are static and do not need any server side processing. As a result, we don't want them on our ColdFusion server taking up space, memory, bandwidth and other resources when we can use those resources for more efficient processing of ColdFusion files. This allows our server to handle more CF requests since they are not busy ...

Last Wednesday at the Boston ColdFusion Users group a question came up that was very relevant to an approach I've been taking. The question was basically ' I have a bean (cfc). In it I have all my properties etc. as well as functions that contain my business logic about people in my org. I've also started storing some UI elements as separate functions in that same Bean as well. What are the thoughts of the group?’ I listened closely to the comments because a) I've been doing something similar and b) the room was filled with smart people more experienced than me.   Here's my current approach. We are striving to use a clean MVC pattern with each cfc modeling a table in our DB. One of these deals with addresses, say addr.cfc which has all of our logical functions in it to keep them separate from the cfms. In order to comply with our business processes, we have developed an "edit address" form which uses AJAX to communicate with UPS for zip code verificat...