cbswagger, the postman, and other options Overview of some free (or affordable) tools to document your API. How to use cbswagger to the max: filtering on tags, limiting on security.

Web Components provide a modular way to build a consistent design system and user experience across your entire application. Instead of copy/pasting the same chunks of coded into various places, you can have a JavaScript/HTML expert focus on getting the UX correct, without them needing to worry about what's happening in the CFML layer at all. Web Components offer reusable functionality on the front-end, with native JavaScript. They are a great middle-ground between standard request/response based CFML applications, and apps that aren't quite ready to move to a full-on JavaScript SPA framework. Web Components themselves are 100% native JavaScript - no new libraries required! Let's learn how Web Components work, then look at integrating them into a CFML application -- I promise it's easier than you think! Target Audience: Developers looking to learn more about writing reusable JavaScript and UI components that are platform independent. This talk will spend a little time going over connecting the front-end code to a CFML application, but attendees should already be well versed in CFML and understand how to build a JSON API endpoint. Main Takeaways: - Creating your first Web Component - Interactivity with Web Components - Connecting to a CFML back-end - A quick look at using Lit to build things - Pros and Cons - Next steps and other resources

Securing and Tuning CommandBox Servers for production

Having a consistent development environment between engineering teams is crucial for the success of any project. What's even more crucial is to have this environment as close to production as possible. This may seem easy with tools like Docker, CommandBox, etc..., but what happens as we add new applications to our lineup? or change some underlying infrastructure? or introduce some new technology to the stack? How do we manage keeping everybody on the same configuration? How will your app behave in a clustered/load balanced setup? How will this new Lucee update impact your app? Will my Adobe ColdFusion app run on Lucee? How will our nodeJS or Ruby app integrate with our CFML app? These were all problems we solved at Cavulus by leveraging the power of CommandBox modules to make order from chaos... or more pointedly: Khaos. In this session we'll walk through what Khaos is, and how it can help you standardize your complex environments, share exact configs between developer, QA and product teams, manage self-signed SSL certs in a trusted fashion between applications and much more. Khaos internally makes use of many common tools, like Git, GitHub, Docker, Docker Compose, Mkcert and CommandBox to make spinning up a new environment as easy as `box up my-app`.

In this talk we'll demonstrate using CommandBox to generate CloudFormation templates on-the-fly that deploy to AWS as fully-configured and fully-automated CI/CD pipelines. Then we'll further explore how to customize the system for your application by securely injecting environment variables (secrets), automating testing with TestBox and configuring auto-scaling. In less than an hour we'll accomplish what would normally take days to piece together from scratch using AWS documentation alone.

Coldbox, TestBox, Wirebox, Rulebox, CommandBox, Forgebox, CBElixer, CBSwagger, Colbox MVC, Coldbox HMVC, Coldbox Relax, ContentBox, CacheBox, MessageBox, CFConfig, Quick, CBORM, QB, CBAuth, CBSecurity, CBLivewire, Codechecker, DocBox, DotENV, CB HostUpdater, CFMigrations, CFMongo, CFRedis, Cors, ColdBox Mail Services, CB Validation, CBStreams, CBCollection, Hyper, CB Elastisearch, LogBox, Mementifier, .......you get the idea. There are a lot of “boxes”. What are they and what do they all do???? Are they all necessary??? Do I need to learn all of them???? This session will “tell the story” of all the boxes based on the problems they are trying to solve. We’ll start from the metaphorical “blank sheet of paper” at the beginning of a web project and we walk and talk through its planning and development, we’ll anticipate the real world snag and difficulties that we and the team will go hit and show how “there’s a box for that”.

I've been a professional geek for over 20 years, but I still feel like I'm out of my zone. Technology moves so fast. There are so many things to know. Everyone is so much smarter than me. I don't know what I'm doing, and it's just a matter of time before someone finds me out. Or something like that. Imposter Syndrome is a problem. But it can be dealt with.