Blog

A few days ago, Joseph Lamoree posted about a cool little command line tool he wrote in Python that would scan a list of servers check check for a public facing administrator.  

I thought this would be a great example to compare and contrast writing the same simple command line tool in CFML using a CommandBox task runner.  Here is what I came up with

Here's a quick one that I tried out for the first time today.  Someone asked if it was possible for a CF app to have a desktop notification on the server it's running.  CommandBox servers have a try icon that runs inside the JVM of the server that can create popups and even Swing windows.  Turns out, it's actually really easy to tap into this to get a toaster popup on your desktop.  

One of the really great features of CFML is the ability to run SQL against a result set in memory.  This allows you to union separate results together or even apply additional filtering on an exiting result if you can't control what the DB gives you.  Like everything, there is a time and a place for this.  There are people who strongly dislike QoQ (query of queries) but my take is that I think they're great when used with relatively small data sets and unless performance profiling shows they are causing issues, I have no problems using them.  

I was adding a feature to CommandBox CLI this week when I typed up some code that iterated over the keys in a struct, filtering out the ones it needed and then performed an action on the matching ones.  I used the functional methods structFilter() and structEach() in CFML.  They are an example of functional programming as they accept functions as input.  This also means we can call them "higher order" functions.  But termininologo aside, I typed up the same code using an older interactive approach just to compare the too.  It was an interesting and rather self contained example so I thought I'd share it as a real life use case for FP (functional programming).

Here's a quick trick on working with a SQLite DB from CFML quicky and easily.  I was playing with the SQLite DB that the original .NET version of GitHub for Desktop and I wanted to access the db file from the CLI to query data and manipulate it.  The steps where very easy  

The very first step was the easiest, and this was to create a blank CommandBox Task Runner:

task create --open

This post falls in the category of something I hammered out for a client today and I thought to myself, "Wow, that's just obscure enough that no one would probably figure it out on their own."  As such, I figured I'd put it into a blog post for Google to index and for me to point people to in the future.

If you use any of the CF UI tags, CFChart, CFForm, or CFAjax functionality, then you need to have some web accessible JS, CSS, etc files for it to function.  In older versions of CF, this was under the /CFIDE folder which wasn't very cool since it made it harder to block access to that folder by default.  On the most recent versions of Adobe CF, you can hit it as /cf_scripts and the IIS connector has a built in handler that passes those requests through.  

So this is a short one to just showcase how one of our new features in the CommandBox 3.7 beta works.  What does it do?  The new command is testbox watch and it will stay running in the foreground and monitor your app for any file changes.  When a file change it detected, it runs your tests from the console and outputs the results so you can get instant feedback on save as to whether you just broke something.

So this post is a response to some blog comments on this post I made today extolling the features of creating native CLI scripts in CFML with CommandBox.  I mentioned in passing that Node is a popular tool for this, but I felt CommandBox had improved the mousetrap so to speak. I also acknowledged by bais as the lead developer of CommandBox, but I stand by my comments. Adam Cameron, in his eternal quest to keep me honest was a little incredulous though, and wanted to see some better proof of my claims.  Instead of elaborating in the comment section, and since I'm well into the "opinion" territory, I decided to respond in a blog post on my personal blog.  

Here's a quick post on a somewhat-undocumented feature of CommandBox.  I say "somewhat" because if you type "config set" and hit tab from the interactive shell, we'll auto-suggest this setting, so it's not impossible to find but I've not put it in the official docs.

So, here's the setup.  You can pretty much do anything you want with the ForgeBox website entirely through the CLI.  That includes creating accounts, logging in, publishing packages, updating packages, listing packages, and searching packages.  This is made possible by our nice (Coldbox-powered) REST API that's part of the ForgeBox site that the CLI interfaces with.  

Sometimes you may wish to play around and try out the commands to create users and packages, but you hate to create a lot of dummy data that clogs up the database or shows on your profile.  The fix is to point your local CommandBox CLI over to our staging instance of ForgeBox.  This is as simple as setting a single config setting from the command line and the change takes instant effect for all your ForgeBox interactions.  Just remember, this setting is remembered until you change it back so don't forget.  

I've been just giddy testing the new Multi-server support in our latest CommandBox 3.1.0 beta.  I never knew starting up a ColdFusion 9 server could be so exciting.  Well it is when you just have to type:

CommandBox> start [email protected]

That's it. You don't need a single thing installed prior other than CommandBox.  Everything necessary will be downloaded and, depending on your internet connection speeds, you'll have a new server running in less than 60 seconds.  Don't worry, it's not limited to ColdFusion 9.  We also are supporting Adobe ColdFusion 10, 11, and 2016 as well as Railo Server 4.2 and Lucee Server 5.0 rc!