Blog

As BoxLang (our new CF-compatible JVM language) nears its final release, we're very pleased to announce that Query of Query support is ready for testing!  QoQ often times draws a variety of reactions from people, but it's a really nice feature to run any SQL select you want against 1 or more in-memory queries for the purpose of filtering, aggregating, or joining.  One of the biggest complains is performance, which is why I've performed 2 round of performance enhancements to Lucee's QoQ support in the past which I detailed here and here.

Building on the knowledge and experience I got from overhauling Lucee's QoQ, I incorporated those lessons into the architecture of every part of BoxLang's query object, and QoQ implementation.  I'm pleased to have a fully-functional 100% Java implementation of QoQ which supports everything Adobe and Lucee QoQ supports and much more.  We're not using an HSQLDB fallback-- everything is pure Java and super optimized.  I was able to make some big architectural changes since this was being built from the ground-up.

Two years ago, I published this post detailing how I had refactored the Query of Query support in Lucee to be much better and also much faster:

https://www.codersrevolution.com/blog/improving-lucees-query-of-query-support

I removed the single-threaded HSQLDB callback for grouped/aggregate and distinct selects and tuned the performance.  QoQ's are a bit of a polarizing feature in CFML.  They've suffered in the past from poor support and poor performance which has caused a lot of people to avoid them.  There are certainly places where queryMap(), queryFilter(), and queryReduce() are the best approach, but there are also times where you simply can't beat the readability and conciseness of an ordered,  aggregated select.  I know developers who tell me they never use "reduce" higher order functions because they are too confusing, but I've never met a developer who didn't understand "GROUP BY department"! 

I've got several other ideas to increase the feature set of QoQ in CFML including native support for INNER and OUTER joins as well as this idea of exposing CFML string, number, and date functions directly in QoQ.  I've also put in a handful of tickets for Adobe ColdFusion to invite them to follow in the improvements I've added to Lucee. I'd send them pulls, if I could : (

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).

This post falls in the category of something that took me several hours to figure out and other people are not likely to figure it out on their own and I'm likely to forget it if I don't write it down!  The problem is if you have a jar file with some 3rd party library that you want to use in Lucee.  Often times this works great, but other times the dependencies of that library may conflict with other jars already loaded into the classpath for Lucee, its bundled libs, or the servlet container. 

There was a Twitter conversation today where Ben Nadel mentioned that one of the continuing issues with ColdFusion was bad JSON support.  I assume by that, he's referring to CF's tendency to change the datatype of variables while serializing them. I mentioned that Lucee Server has much better support for this and I'd like to show very quickly why this is.

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!

Michael Smith has released the full results of this year's State of the CF Union survey over on the TeraTech blog.  I enjoy seeing this data every year as a framework author since it helps us know what engines and types of OS to target with our products.  This year, there's a full write up and a little commentary on each graph.  Note the write up is spread across two blog entries:

http://www.teratech.com/blog/index.cfm/2016/2/19/State-of-the-CF-Union-Survey-2016--Results

http://www.teratech.com/blog/index.cfm/2016/2/19/State-of-the-CF-Union-Survey-2016--Results-Part-II

Notable bits of data were:

• CF9 is finally falling behind CF10 and CF11.  This is good since we'll be dropping support for CF9 in ColdBox soon
• Lucee has left Railo usage in the dust, and a solid amount of people are already using Lucee 5
• Still a lot of people out there using no framework at all or FuseBox!  Of course, I assume this isn't new dev, but rather the same old legacy apps that have been around for years
• A lot of people not using a DI framework. Kind of curious if they're not using CFCs at all.
• Really surprised how many people still use Notepad++ for dev.  
• The "How many years have you used CFML" graph is very depressing.  Very little new blood coming into CFML.
• Love how many people are using CommandBox.  I'm so pleased to see it being useful for the CF world
• A decent chunk of Amazon EC2 users, but it's clear most CF shops aren't doing cloud deploys. Not sure if Adobe doesn't focus on cloud because their users don't care, or if it's the other way around.
• Surprised to see how many home-grown REST frameworks there are. I can't imagine a world in which you wouldn't waste more time doing that from scratch than to drop in something quick and easy like ColdBox 4's REST routing.  There's so much out of the box to be gained.
• There's a decent chunk of CF devs in very large companies, but the majority are in small business's with 1-20 total employees.  That's interesting since it's not where I would have pegged most CF devs to be.
• The comments are very interesting too.  Lots of love for Lucee and lots of frustration for Adobe.  

OK, well there's my thoughts. Head over and check out the data yourself. 

In the beginning was the Web, and the Web was with CFML, and the Web was CFML. It was with CFML in the beginning. Through it all websites were made; without it no websites were made that had been made. In it were tags, and those tags were the productivity of all programmerkind. The productivity shone in the darkness, and the darkness did not overcome it.

Ok, maybe I'm overstating CFML a bit, but when it was created it was revolutionary.  It redefined how websites were built and set the bar for other web programming languages.  And though CFML led the pack for a while, there were soon others to follow.  These languages were also productive, came with compelling frameworks, and made building sites fast and fun.  Many of these servers were also free and open source and around them large communities grew.