Whilst in Minneapolis for this years dev.Objective (previously cf.Objective) conference, myself and Simon Hooker (Head of Product Development) decided to also attend another conference; Into the Box. Into the Box started in 2014 as a small niche conference put on by the team at Ortus Solutions centering around their range of ‘box’ products. The lineup for this years conference was a little more diverse, branching out and covering a wider range of topics.
The conference was at a different hotel to dev.Objective, so Simon and I simply hopped on the light rail at the Mall of America and headed over to the Embassy Suites in time for the conference breakfast. There was approximately 60 people attending the conference with 15 speakers running two tracks and 15 talks in total including the keynote.
This talk started off with an introduction to what NoSQL is, how it is not one particular thing and that it is mainly just a ‘buzzword’ with no standards, how it differs from traditional relational (SQL) databases and why it was created. It covered basic information about the different NoSQL database types, key/value pairs store, document store, column databases and graph databases. They then went on to describe the mental shifts that a developer needs to make when moving from a relational database management system (RDBMS) like MSSQL or MySQL to one of the many NoSQL systems, with things like:
Going to the database doesn’t have to be a costly operation
Denormalizing data takes some getting use to
Data integrity becomes the developers job instead of being the databases job
Schema changes are easy
Brad then walked through a demo using CouchBase, a document store, and while doing this explained the different terminology used with Couchbase, for example ‘buckets’ which are like databases, a ‘view’ is like an index, and so on.
Luis presented a good outline of the CommandBox product with a brief overview of all the different features. These features make CommandBox a complete toolkit for CFML developers and include a CLI, package manager, REPL, integrated CFML server, ForgeBox integration (package repository), automation and scaffolding (particularly for the ‘box’ products).
CommandBox is an excellent tool for any CFML developer and from version 2 (currently in beta) will be running on Lucee with Lucee being used as the integrated server.
Fellow Brit, Matt, was on hand to talk to us all about Vagrant which as developers we can use to create and configure lightweight, reproducible and portable development environments. You can use Vagrant to make an environment per project that is easy to define, transport and tear down that is provisionable and versionable. You can then share this across your team meaning that everyone has the same environment, no matter how their development environment is set up. You can use VirtualBox, VMWare, Hyper-V or Docker as the host platform for the virtual machine that Vagrant provisions.
Vagrant is mainly a CLI tool and Matt explained the various commands to initialise, start up, suspend, halt, destroy, provision, package, etc… boxes as well explaining where you can obtain pre-configured boxes from.
To finish up, Matt explained about the various ‘provisioning’ tools that you can use that allows you to run a custom set of commands when your Vagrant box starts up covering the two most popular; Chef and Puppet. Both essentially do the same job, just in a different way, with the main difference being that with Puppet you have to list dependencies and Puppet figures out how to order the install, but with Chef it runs the script in the order in which you define it.
Given it’s superb title I had high hopes for this session, hoping that it would show me what is (apparently) so great about ORM, however it did nothing to convince me that using ORM in a production system is a good idea. There was nothing wrong with Joel’s presentation but I still came away with the same feeling about ORM, which is that for anything other than prototyping ORM is a bad idea. To me, it is a level of abstraction away from the database that any good developer should not be able to live with as it removes so much control from the developers hands to make good, efficient queries. Many developers are already pushed too far from the database by DBA’s, etc… so adding in another layer for them to have to try and see-through is just generally unhelpful.
If you have a legacy CFML application that you want to move to an MVC framework like ColdBox, this could be a massive undertaking, rewriting / reworking the whole application into the framework. Scott however explained in this talk how you can take a more piecemeal approach to this due to a feature of ColdBox that allows you to essentially drop your existing application into the ‘views’ folder, make some minor path changes to the applications cf includes, create objects, etc… calls and add any required configuration to the ColdBox Application.cfc. Once this is done your application ‘should’ work as before and you can then, overtime, refactor your application into the proper ColdBox MVC structure, on a component by component basis.
Building on Luis’s general CommandBox talk from earlier in the day Brad, speaking at a million-miles-per-hour with extreme passion, spoke in detail about the package management and automation features of CommandBox. CommandBox supports packages from various different sources via it’s box.json package configuration file. The package management feature in CommandBox will be extremely familiar to anyone who has used NodeJS’s NPM tool as it works and is configured in a very similar way. Automation in CommandBox allows you to perform tasks from the command line in a similar way to the popular Grunt and Gulp NodeJS task runners but with the scripts written in CFML instead.
Behavior Driven Development, Automation and Continuous Integration
Friend of mso and another Brit presenting at the conference Kev McCabe spoke about one of his favourite topics, behaviour driven development (BDD) and how this feeds into process automation and continuous integration. Kev explained how BDD is more about the people and the discussion to make sure that the requirements are defined across business functions before the coding begins so that the functionality that is produced actually does what everyone is expecting. This then fed into explaining how having the BDD tests in the code allows you to automate the testing process and allows you to have the confidence to run a continuous integration environment for your application.
If you liked reading this article you may also like: