Merry Christmas everyone! This is our final installment for this year's 12 Tips of (CommandBox) Christmas! We're leaving this year with a bang as we look forward to what's coming in the future with the next major release of CommandBox CLI.
We've talked about what packages are, how to create them and how to publish them on Forgebox. Now that you have the basics down, we've got some special ninja kung foo magic that will let you crank out modules with almost no effort at all. We obviously can't implement the module for you, but there is a lot of boilerplate around creating the Git repo, scaffolding out files, setting up tests, and publishing. We can turn all that boilerplate into 2 commands. **
** Some one-time setup required
For today's 12 Tips of (CommandBox) Christmas blog, we're covering private ForgeBox packages. This has been out for a while but we haven't talked a great deal about it. The idea of private packages is that you want to have packages of code that you and your coworkers use to build your apps and you want to use ForgeBox to list them so you can have CommandBox manage their installation and updating versions. However, these are internal packages that you don't to share with the rest of the world.
For today's 12 Tips of (CommandBox) Christmas we're going to review how to debug a server that don't want to start. Figuring out why a server won't come up is usually very easy, but some people will waste a lot of time on it if they don't know how to access the logs. Part of the issue is that the start command fires off an async process to actually start up the server, so you don't get much feedback right there in your console.
As Christmas draws near, remember to pick up batteries for all those toys. There's nothing worse than a Christmas morning with not enough AA's. In fact, there's solid evidence that this entire holiday is a ruse to keep battery manufacturers in business. They're probably kahoots with the peppermint latte guys. Anyhoo, let's talk quickly about using custom versions of Java with CommandBox.
For today's 12 Tips of (CommandBox) Christmas, we'll talk about staying up to date when it comes to your CLI binary and the modules you have installed. New versions of stuff come out all the time and you don't want to be stuck on an old version.
In today's The 12 Tips of (CommandBox) Christmas we're going to discuss Docker. Containers are changing how the world deploys apps and services for development and production. With Docker you don't need to ask around to find a good ColdFusion hosting company. All you need is a company who supports Docker and you know you can deploy there. Docker requires a shift in thinking though. Smaller, transient servers that you don't install every time. Portable configuration and flexible deployments based on text configuration files and environment variables. Hey, that sounds right up CommandBox's alley!
For Christmas this year, why don't you give the gift of unit tests to everyone (including yourself) who may work on your app in the future. Nothing else brings about the same amount of confidence in refactoring or assurance that your app still works on that new CF engine update you just installed. While you use TestBox to write and run your tests, CommandBox has some commands built in to help you do it in style. And most importantly, these CLI commands are perfect for automating your tests on your favorite CI server like Jenkins or Travis.
In this installment of The 12 Tips of (CommandBox) Christmas we'll talk about a CommandBox module called CFConfig that will make your life a whole lot easier. A couple of days ago we covered the server.json file which helps you define what CF engine to use (Lucee, Adobe, etc) and your JVM settings and web server settings in a way that is easy to distribute to you coworkers. There was one big thing missing though and that is all of the settings that you put in your ColdFusion administrator like datasources, CF mappings, and request timeouts. Well, Christmas has come early this year because CFConfig is the piece of the puzzle that does that for you!
'Tis the season to share with others. And what a perfect time to talk about sharing your CFML libraries! How many times do you think CF devs have written the same libraries and integrations over and over, just to keep their work to themselves. Giving your work back to the community is what makes the world go 'round and also makes the CF space more attractive to outside developers looking in.