On the heels of and in conjunction with the 3.7.0 release of ContentBox, we are pleased to announce the 3.7.0 release of CommandBox ( a happy coincidence that the version numbers of the two are the same! ).

This release provides major updates in security and functionality to the CFConfig module, which may be used to configure CFML servers at runtime. The settings and environment variables, which were previously handled by the bash script used to start the image, are now delegated to CFConfig. You can read more on using environment variables for CFConfig here.

Today we are very excited to bring you ContentBox version 3.7.0!

Most projects in CF now involve creating some type of consumable CFC Endpoint or API Service... do you Unit test your API, do you use Integration Tests on your API? How many ways do you test your API? Not all tests are created equal.

We build our CFCs and CF API to be consumed with CF Apps, Mobile Apps, Javascript apps and devices we haven’t even thought about yet. To be smart developers we need to be able to test our CFC endpoints, and the code that uses those endpoints.

We’ve all had those projects, the salvage project, the legacy project that we picked up, and wished we never had.

Was it written 5 years ago by that young dev with lots of passion but no big picture vision.

Was it written 6 months ago by another team, by a top gun developer who knows all the design patterns, and tried to future proof the app, only succeeding in making it impossible for anyone else to understand.

At this year's CF.Objective I presented on the topic of programming design patterns.  Here are the slides for the presentation.  This session covers what programming design patterns are, how they got their start, and reviews common design patterns and antipatterns.  There are simple code samples that go with most of the samples, including the antipatterns.