Dan Card

Recently I had to do a quick "utility" page where I needed to see how many files from a directory listing had been recorded into a database. I've been writing about 98% of my CF code in script syntax but, since it was quick and easy, I did this quickly in tags because it was outputting directly to the browser. In doing so, I made an interesting discovery in that, when you use closures, even in tag based pages, you can write cfscript. Here's the example Get the directory listing:  < cfset alljs = directoryList(expandpath( '/src' ), true , "path" , "*.js" )> Get the database listings and convert it to an array < cfquery name = "alljsQ" datasource = "blah" > select * from sitefiles where filename like '%.js%' </ cfquery > < cfset recordedFiles = valuelist(alljsQ.filename).listToArray()> Use a filter function to weed out the files I'd already recorded < cfset missingFiles = alljs.fi

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 The core of every CI/CD process is the code repository whether it be Git, Mercurial, SVN or whatever. The general idea is that it allows multiple developers (or whomever) to access your code in the appropriate way in the appropriate level. This can either be the ability for anyone to pull an open source project but not write to the repo directly or full access to a developer on your team to create branches, push to master or anything that needs doing. For our project, we're using git although the hosting provider was up for discussion between Github, Bitbucket by Atlassian or CodeCommit on AWS. We decided to go with AWS for two reasons. 1. We are going use other tools in AWS as part of the build so we decided to keep it all together. 2. We needed to solidify the ins and outs of using IAM for the process. Basic Steps Create the Repo Create the branches we need Use IAM to apply the appropriate permissions to each branch and to set up

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

Part of the CI/CD Development Series In order to achieve your goal, you need to a) have one and then b) find the best way to clarify that goal into some tangible medium. Paper and doodling is a great start but eventually those doodles need to be put into a some clear communication format which is accessible to yourself, your team and anyone else who needs to see what you are striving for. There are several diagrams that go into communicating the plans and specifics of software projects. UML has several diagram listings including Deployment Diagrams, such as the one below, Component Diagrams, Activity Diagrams and more. This inevitably leads to the multiple problems of  - How to develop the diagrams  - How to publish the diagrams in locations which can be referenced by the target audience  - How to update the diagrams which have been distributed or published. This last item is probably the most difficult since it is easy to put off publishing the new diagrams until it is &quo

Part of the CI/CD Development Series The next step is developing who is on our hypothetical development team. Given that it has a React front end and ColdFusion as the Server Side language, I came up with the following personas, all of which have their own needs and considerations for our development environment. I've listed all the jobs that need doing, not the people involved since, even on a small team or a team of one, these "hats" are all worn by someone, even if it's the same person. Personas for our Project Dev Ops Coordinator - The person responsible for smooth and accurate deployments CF Developer - The person responsible for the API and fulfillment code development and maintenance. React Developer - The person responsible for the front end development Database Coordinator - The person responsible for the schema, data, up time and, presumably the testing databases used by the developers. Lead Developer - The person responsible for coordinat

Background In March of 2020, I was between projects that the last several learning curves that I'd gone through had left a wide assortment of completed tasks but that I might still have some mental holes in the process. As a result I'm creating an entire project from scratch, soup to nuts so to speak, including all the scaffolding, documentation, tasks, deployment and so on. This page is the reference page for all the blog posts that are part of that project. Table Of Contents Project Launch Jira and Confluence Creating Stories and Tasks in Jira: Personas and our Software Development Team As a Dev Ops Coordinator I would like a tool which allows central creation of diagrams which "live update" in several places. The Three Deployment Environments: Production, Testing, Development As a Dev Ops Admin, I need to plan out our CI/CD process As the Dev Ops Coordinator, I need to set up our git repo into several branches with the appropriate permissions for each o

I decided to use both Jira Software and Confluence. Jira Software is what most people associate with Jira - it's a ticketing system where,  fundamentally, tasks get put onto cards, those cards are assigned to people who then do them and check them off on the list. Sounds straightforward (like most of IT) but the details make it a little more complicated (again, like most of IT). Confluence is a documentation tool that is meant to be a way for teams to document seemingly everything. Like most of the software, there seems to be several ways to do the same thing. Turning to Jira, I created a new project and chose to do a scrum project. I was thinking of doing a simple Kanban board which is a simpler process, but if you're going to do something, do it full bore. Project created, I was presented with a menu consisting of  - Scrum Board - Empty since we haven't set anything up yet  - Backlog - Ditto  - Active Sprints - Ditto  - Reports - Ditto  - Releases - Ditto  - Is

It has been a while since I've posted anything which is more to my detriment than anything else. I teach a class at UMASS Lowell and one of the things that I emphasize to my students to journal each week as they go through the learning curves that they have. The major reason for that is that it's very possible to do all the natural floundering around you do as part of learning something, find a winning combination, and then forget how you got there, especially after a few days (hours? minutes?) or not even realize what combination of keystrokes got you to where you are. Over the past year or so, I've dived into several new technologies and techniques ranging from large scale React applications to cloud based testing servers to CI/CD issues. It's been a blast and mostly successful although there were many many of these learning curves where the actual steps to go back and recreate it might not be as smooth as they should be. As a result, I'm starting a series (with