You can listen to the podcast and read the show notes here
Michaela Light 0:01
Welcome back to the show. And today we're going to be looking at migrating legacy cold fusion code to MBC. That's model view controller for those of you haven't come across it yet have been around for quite a while. And we'll look in the episode with Nolan arc, who is the chief genius at south of Sastre
does a lot of ColdFusion. And he's been doing software development for like 19 or 20 years now.
And we'll look at what MBC is, and what problem it solves. And in particular, we'll dig down into framework one and code box, which are two frameworks which use MBC. And we'll also look at dependency injection and why you should be using that in your MBC apps, and how you can use it in framework one and code box and how you can refactor your real world procedural code. I think that procedural code maybe as a special way of saying it might be a little like spaghetti but maybe not. Maybe
Your code is better.
And we'll look at some strategies for migrating large apps
over to MPC in phases, so you don't have to freak out with this. And if we get time, we'll also mentioned CommandBox and get and how they could help you out do this faster. So welcome, Nolan.
Nolan Erck 1:18
Thank you. Thanks for having me.
Michaela Light 1:19
Yeah. So I know you did a whole day workshop on this at CF Summit out in Las Vegas. And you had hordes of developers learning how to do it, or a horde is about 40 people, I think,
Nolan Erck 1:34
yeah, we had, I think there were about 40 students in the class.
Michaela Light 1:38
That's great. So what exactly is legacy ColdFusion because that term gets thrown around a lot.
Nolan Erck 1:47
It does. And that's a that's a pretty broad, maybe ambiguous term. My opinion is, it's 2018. Pretty much any ColdFusion code that is not really
In a proper framework ColdBox, framework one,
taffy even or something like that, it's probably a legacy app. Most of the time, the things I see in my consulting experience are apps that are still predominantly using CF includes as their way of being modular. Maybe a little bit of custom tags here and there, maybe an occasional CF component that
is kind of just wrapping around a couple of functions. But most of the things that I see these days that I would call a legacy app are either just see if includes everywhere, or maybe just giant top down see FM pages with a 10 12,000 lines of code in them, though that's kind of anything in that world is what I would call it legacy app at this point.
Michaela Light 2:47
10,000 lines of code in one see FM file
Nolan Erck 2:50
Oh, yeah,
Michaela Light 2:51
it's quite a mouthful.
Nolan Erck 2:53
It does. I actually had a project I did for a client
a little while back
And there were about 10 dot CFM files in their app. And each app, each file was eight to 10,000 lines of code. It was just one top down, see FM that would post back to itself with different form variables. And that's how they wrote that out. So
hopefully you don't see that. Unfortunately, I don't see that too often. But kind of variations of that theme auto CF includes and a lot of self posting forums that don't quite have a good modular structure to things. It's what I see a lot of in terms of legacy code.
Michaela Light 3:30
And, and, you know, just to be the devil's advocate here, what's wrong with hat keeping your code in that format?
Nolan Erck 3:37
Well, I guess that Yeah, and that's a fair question. If there's, if it's working, and you're not changing anything with it. You know, there's the argument for if it ain't broke, don't fix it. The
problems come into play when you discover new bugs. When the customers need new features added to it. We need to support new things like
Maybe you want that same chunk of business logic to work to power a mobile app, maybe to power a REST API, things of that nature. When you've got one giant 8000 lines, the FM file, you've got all of your business logic, all of your sequel stuff, all of your HTML, and probably JavaScript and other things to all kind of mingled together. It's really hard to break things out and fix bugs without causing what they called technical debt, or maybe bit rot. Other things that just make the code harder to maintain long term. Other things that cause potentially more bugs to be added into the application. You also run into the case of
the way modern web development is working. There are a lot of people that are specializing in the front end people that are becoming very, very good at HTML, CSS, and JavaScript. But they don't necessarily touch sequel statements very often at all. And you also have the opposite people that are great SQL gurus that know ColdFusion and how to write CF query tags that are amazing. And they don't spend a lot of time on the front end writing JavaScript. When you have ever
In one file, it's really hard for those two types of people to work together on a project without having conflicts where they're editing the same kind of line of code. If everything is in a repository, you run the risk of lots of merge conflicts and that sort of thing happening slowing down everyone developing on the app.
So when you split things out into more of a modern MVC architecture, it just organizes the code a little bit better to keep the different types of development isolate a little bit better, makes it easier to make one sort of change, like a UI change that is just HTML and CSS, without risking breaking the sequel statements, or vice versa. If I want to fix a sequel statement, I don't run the risk of breaking the JavaScript and that sort of thing. So that's kind of the benefit of why I would go to the trouble of redoing something that's currently in 1000 line.cm file.
Michaela Light 5:49
Well, and and also, if, you know, if people listening do have apps they're maintaining with with those giant files, the chances are there's a lot of duplicate code and then there's a
Nolan Erck 6:00
Lot of unused code exactly what of unused code, a lot of things that are very hard to test, one giant dot dot c FM file with let's say 10,000 lines in it.
My experience has been the way those typically work is there some sort of web form in the page somewhere. And depending on which fields got filled in the form, different chunks of that file will run accordingly. Oh, the user clicked on button a run lines one through 500 when the form is submitted, if the user clicked on button B, or C, run lines 1100 through 1750, when the form is submitted, and so you have to do all of this manual fill in the form a particular way to run the different individual chunks of code. That's a very manual tedious process to test everything in the app. If you break things out into let's say, see a functions and put them in a component. You have all of these individual little units, and then you can run unit test software like test box to just automate all of that testing process.
If you have individual things that are components or functions, you can also put them in
their own separate CFC file, making that 8000 line file much, much smaller. You lessen the risk of a change you make breaking the code that you know already works when it's been nice and compartmentalised off into a separate library somewhere.
Michaela Light 7:13
So yeah, so you avoid that whole whack a mole bug fixing thing where you fix one bug, and then it causes another one, and you fix that and another one pops up. Exactly. Yeah. So sounds like a good thing to move to a modern framework using model view controller. What for those folks who haven't done it, what exactly is a model of view and a controller?
Nolan Erck 7:40
So model view controller is just that's the generic design name for the design pattern MBC model view controller. That's a technique you can use in pretty much any object oriented software development language, so not just cold fusion, but Java. net c++, small talk
Various other o languages, they all support MBC. And the idea with that is, rather than having one giant file with everything smushed together, you break your app up into three sections. The model is model is sort of an abbreviated way of saying business model or data model. It's basically where all of your sequel type stuff goes, you're inserting update statements or SELECT statements to talk to your database, or whatever the other storage thing is you have if you're talking to XML files, reading and writing files from a network share,
that would all be considered your model code, as well as any sort of business logic that lives on top of that SQL statement. So let's say for instance, I have a table in my database to store
user logins people who can access the app, they have a username field and a password field in the database. My model code is going to have some sort of SELECT statement saying select username and password where the user ID is XYZ to check if someone has logged in or not. In addition to that sequel statement, there's probably a
Couple of if l statements afterwards saying if I found a record, then correctly log the user in and save their session. If I did not find a matching record, return some sort of know rematching record found or invalid user result back to the other code. So it's not just your sequel statements, it's anything. business logic is related that touches that stuff and the code that supports it. That's your model. The view is basically the part of your app that users actually view on the screen in their web page. It's the HTML, the CSS, the JavaScript.
When you make a view file,
there, it's mostly those things. It's mostly just HTML tags. You include your CSS, you include your JavaScript as needed, you put that in the file, there might be a few lines of confusion here and there things like an if statement, saying if the user is logged in, draw the logout button on the screen. Else, draw the login button. So tiny little bits of not really business logic, but little bits of branching to make the UI do what it's supposed to do in the
given state, what you don't see in the view our flat out see if query tax
giant loops of business logic to check if users logged in or anything like that, that's all done back in the model. And then the controller sits between those two things. So when the user is in the view, and they click on, let's say, buy new products button, controller looks at that view. And so they clicked on the buy new products button, let's go into the model and get the list of new products and return that back to the view and make that show up on the screen. So the model sits between the two and sort of connects the two sides together. The analogy I usually use when I'm teaching this in an intro class is it's sort of like working in a restaurant. When a customer first goes into a restaurant. They're presented with a menu and this is the thing they can view and see all the different options they have for what they'd like to order. The customer does not take that information and physically go back in the kitchen themselves. They tell a middleman the waiter what they'd like to order from the system. So the waiter in a restaurant is sort of like the equivalent of a controller in
The Model View Controller app. So I'm the waiter doesn't actually make the food, they hand the information back to the kitchen where all of the heavy lifting is done, we're all at storage as things are taken out of storage, like the fridge and freezer, where everything is prepared properly. And then when that's done, the waiter then takes that information and brings it back to the front end, enhance the results said the cheeseburger you ordered or whatever to the customer.
And that's kind of the the best analogy I've come up with so far on how you would organize your code and
how to keep things separate. And that seems to work pretty well for people that are new to Oh development if you think of it like a restaurant with three different sections, your kitchen, your waiter and the front end menu slash tables where people actually hang out.
Michaela Light 11:41
And and that means when you're maintaining and MBC app, if you're going to change something about how it looks, you only need local view part of it. You don't have to search through the rest of the code. Similarly, if you change the business logic or the database you're you know, you only need to look at those files exactly right in the model.
Nolan Erck 12:00
Right, and the way modern web development is going, there are a lot of people that specialize in that front part that, that write a ton of CSS and HTML. And they do amazing tricks for making your user interface look brilliant, and support all the fun special effects that new browser support.
And a lot of people do just that for their job. And they don't spend any time learning how to do SQL statements or more advanced back in cold fusion tax. So if you split things up into these two different in the three different components, or sections, rather,
those front end experts have files that are 90%, straight HTML and CSS, they can really focus in on the part of the app that they need to focus on and not have to scroll through 1000 different CF queries and a great big CF switch statement and a bunch of CF directory calls that they don't care about. They don't run the risk of getting lost looking for the piece of code they want. And they don't also run the risk of accidentally deleting some of that code or breaking it when they're just trying to find the form tagged up.
Michaela Light 13:00
forever. So yeah, you give people a nice kind of separate way to work on things. And you do an NBC app as well. Yeah. And not only does it protect you from the UI experts breaking the no back end code, it also saves you from the back end code geniuses messing up the CSS and all that stuff that's been done. Exactly. So I run into that a lot to wear a back end developers are great at sequel and cold fusion, but maybe they're not up to date on what the current html5 and CSS three features are. Just kind of let them work in their own back end piece and let the front end developers work on their face and connect them together with MVC. And, and even if it's just you on your own doing the app, it's it's certainly mental, less mental bandwidth. If you know, you can just focus on the database bit when you are editing this file. And you can focus on the UI bit in this file instead of having to keep it all in your head at once. Oh, absolutely. And I and I build applications that way. Even when I'm the only developer on the project. I still use it in
Nolan Erck 14:00
DC framework to keep everything organized. Yeah, support that reason. So I can focus on the HTML tasks all together, and then focus on the sequel tasks altogether later. And then again to with everything modular like this, it makes it much easier to test the individual sections with an automated tool like test box.
Allow me to give a better quality product to customers with much less overhead and work on my end.
Michaela Light 14:25
Great. So let's assume we've decided we're going to do change our legacy app to MBC. What are the you know, let's look at some of the most popular MVC frameworks, which will be framework one or co box and I think those were the most popular in our recent state of the cold fusion union survey. So
So tell us a bit more about each of those like just in a nutshell, what is framework one and what is called box. So framework one and co box. They're both model view controller frameworks. So the core features of
Nolan Erck 15:00
Giving your app structure and breaking everything up into a model view and controller in the middle. Both frameworks do that out of the box, pardon the pun, the box whole box.
Unknown Speaker 15:11
They
Nolan Erck 15:13
they both work the same way. As far as structuring your app goes. Both of them have a model folder that you put all your model business logic stuff in. They both have a views section of your app where you put all of the HTML that your app views, and they will also have a controller component in the middle that connects the two together.
The differences between the two are framework one
is meant to be a very minimal framework. It's literally one file, you download a file, put it in your machine, your your app structure,
you connect it to your application, CFC and it just starts working.
I personally like framework one for easy developers out of legacy CFO land and into looking at MBC structure for that
It's one file. There's not tons of other stuff that comes with it. It's very easy way to sort of
take developers who might be scared of moving to an object oriented thing. And kind of showing them look, it's it's not quite that different than what you're doing. Now, you just you have a couple folder names, you have to you have to have folders with these names. You have to use a certain naming convention for things. And when you name your files a certain way, the app sort of just spins up and starts working. And pull box does the exact same thing. You name your files a certain way. You put them in a directory structure with a certain naming convention. And the code basically just starts up and running and you're good to go. The difference with framework one versus Cole box. The big difference is
there are lots of add on packs, if you will, and other supportive products that are part of the cold box ecosphere.
That help if you have like a larger enterprise sized application, if you're concerned about things like automated testing, having cashing options available
Things of that nature, there are other, add on packs for lack of a better phrase that the cool box ecosystem provides for that. And there's also an actual company supporting the cool box stuff for the solutions has a team of developers that that's what they do day in day out as they support customers that are using the cool box products.
Not that you can't use framework one for professional grade MVC apps, I do. Many other cold fusion outfits do as well like the the Mira CMS platform is entirely written on framework one and that works great.
It's just a kind of a stripped down minimal way of starting your app versus the call box way that's got a few more bells and whistles baked into the app from the get go.
Michaela Light 17:47
So yeah, so if you you can go either way with with those other any other MVC frameworks that people might come across in the wild. There are others. There's
Nolan Erck 18:01
There's technically Yeah, there's a few others that are still out there, CF wheels is out there still, I'll be honest, I don't use CF wheels for anything. So I'm the wrong person to ask about the current status of feature sets in that framework. But also some that are a little bit older fuse box.
You might also see information about model glue and Mach two. Those are others that have been around and are technically still in existence, although I don't think they're super widely supported anymore.
But they all
they all do the exact same thing that framework one and toolbox does. They give your app the model view controller structure, depending on which one you choose to go with, they may have some other add on features that you might find, benefit your workflow.
They all do the same thing though, as far as give you the model view controller structure and organization to your app. I guess the big difference between
the current frameworks framework one and toolbox versus some of the older ones fuse box monolithic
And so on is the current frameworks, their what they call convention based frameworks. So you use those frameworks. And then all you have to do is name your files a certain way, and name your functions a certain way. And the app just knows how to wire everything together. Because you follow the naming convention. It's a convention based framework. It just glues everything together and start running your app. The other frameworks that I mentioned, model, glue, fuse box, and so on. Those are what they call configuration based frameworks. They do the same model view controller thing. But rather than following a naming convention that magically makes everything work, you have some sort of config file, usually a giant XML file or something close to that. And what you do in that config file as you tell the app, when I want this particular event to happen, saving the user to database listing the current customers on the screen, whatever the thing is, you have a config file where you go in and say, okay, when that happens, this is the model code I want you to run. After that model code is done. This is the view I want you to have show up on the screen. You kind of glue things together with this config file. At the end of the day, they
They all do the same thing. Some people just like the config
set up a little better than the convention setup or vice versa.
Michaela Light 20:08
And then framework one and co books which which camp do they fall in that they're both file. They're both convention based you name files a certain way, and they just magically work. There's no XML config to worry about with either of those. Right? Excellent. So if you're going to try this out your you know, maybe you're going to try out framework one or co box, some legacy code.
Nolan Erck 20:34
You know, what, what's the approach you take to that? Because you might have like you said, you might have 10,000 lines and files. Yeah, he might. I yes, there are a couple of different ways you can go about it. I've actually got some notes on this topic on on south of shasta.com. If you click on the presentations link, I've got my slide deck and some code samples from a talk I gave called MBC. Within without a framework and it steps through taking
A small legacy app and moving it into MBC. And then using that MBC code to run it in a framework, one kind of setup. So that's a point of reference, people can check out if they want to get more information on this.
If you kind of understand the concepts of what a model does, what have you, and controller does,
you have a giant legacy app, I find the easiest part to start with is make a model folder
and make some CSS in there for your CF query stuff. So if you have a couple of giant legacy files, maybe you have a lot of customer or employee queries in your app, if it's like an employee management application, for instance,
make a folder called model, make a file in there called employee dot CFC. And then as I find queries in my code, doing things like saving a new employee to the system, okay, well, that's a CF query with an insert statement inside it. I would cut that out of the giant file, paste it into
the employee that CFC component
And wrap that in a function called something like save employee. And then instead of having the CF queries in line and my giant file, I can at least start calling that component as needed. That way, if that insert statement is duplicated in three or four spots in my file, now I don't have that CFPB duplicated in four spots, I just have calls to this one function. So we'll have more files in my app, but fewer lines of code to manage. And the code I have is more reusable. So I usually start with something like that, move my model stuff into one spot.
And then we could have left is some combination of business logic and view things and then it can get a little bit more
Unknown Speaker 22:37
tedious.
Nolan Erck 22:39
You could try to manually keep going and set up your own sort of MBC folder structure from that
point. That's a little bit of what I cover in that MBC with them without a framework talk I mentioned
you could also go with Cole box or framework one and
thing I've seen people do with some success as well as just take your
kind of the larger files. If you have like an employee, see FM, it's got some HTML in it some business logic and some sequel queries in it.
Make an empty framework one or cold box project,
make a an event or I'm sorry, an employee detail section in your framework. And just take the entirety of your old employee that CFL legacy file, paste it right into the view in your framework. And it's not going to be a great organized application at that point. But you can at least get the code running in an MVC framework. And once it runs, and the URL actually draws the contents on the screen the way it should,
then you can kind of work backwards from there and move the screen of queries, CF queries out of the view and put them into the model folder in pull box, a framework one
and starts separating things out that way. I've had some success doing variations of that theme as well on apps
clients of mine. In fact, we're doing that right now with a client who has a very old legacy FM app that a previous developer wrote and is no longer around. So we're migrating that into a framework one ecosphere, for him right now. So that we get a structure so we can do better mobile support and give him a better, you know, architecture and just move forward with some modern development for him. So that's a great, yeah. And I think the other step step I've seen is the, you know, often you you pull out those
Michaela Light 24:32
bits of model or front end code, and you discover you've got 15 variants of basically the same code. Exactly. And then you're figuring out did they really want 15 different variants of this sequel statement, or is it really supposed to be all the one particular? Yeah.
Nolan Erck 24:50
Anytime you can delete code, and still get the same functionality, that's usually a win. You know, the fewer lines of code you have to look at, the less likely you're going to break something by accident.
Michaela Light 25:01
Now I know you mentioned dependency injection in that. And so what exactly is that? And how does that help out with this whole process? So dependency injection?
Nolan Erck 25:14
The short answer for it is, the further you go into object oriented programming, the more classes and objects and CF components you'll have in your application.
dependency injection frameworks help manage getting information in and out of those components, it just makes it a little bit easier for you. depending on the complexity of your app.
dependency injection framework like Dr. One or wire box, might do a little bit for you, it might save you a whole lot of typing.
You can sort of a lot of the boilerplate code that you have to write in Object Oriented Development. If I have five or six different components that I'll talk to each other.
Perhaps better example would be let's say I have a component
That is an employee component. And before that employee component can work, I have to create some sort of login component to make sure the employee can log in, after maybe also create some sort of manager component to make sure that the employee has a manager wired up to it.
Maybe there's a third component to some sort of, I don't know, authorization key that I have to pass into the employee port will work as well. So just to get to that one employee component that I want from my app, after make these three other objects, and test them into that. So off the top of my head, that might be somewhere in the neighborhood of five, six, maybe seven lines of code I have to write every time I want this one employee component to be created in my app and use that for something, copy and pasting six or seven lines of code everywhere in my app that I want an employee object to be created, gets kind of tedious. We're violating the dry principle of don't repeat yourself. It's a lot of stuff I just don't want to do as a developer.
It's not really moving the application forward. It's just necessary boilerplate to get that one feature done. You can use a dependency injection framework to start
Sort of hide all of that stuff in the back end. So rather than me running the Create object tag,
five time to create the five different objects just to build up my employee component that I want, I can say, hey, dependency injection framework, please make me an employee. And that dependency injection framework knows what all the boilerplate things are that it needs to do it, make a manager, make an authorization component, make a login component, whatever they are, it just does that all behind the scenes, and hands me back my employee component when it's done. So I write one line of code that says di framework, go get me an employee, please. And it does it. And then inside the DI framework, it does all the boilerplate stuff, magically behind the scenes, I don't have to write that code anymore. I don't have to copy and paste that code anywhere. Just kind of streamlines
building those those things into my app for me.
And then, depending on how complex the job is, you can add other features that help it out. Sorry, go ahead. Yeah, no, I was just gonna say we spent a whole episode I think was episode
Five on dependency injection where we have for an hour all about dependencies. Okay, so if that sounds intriguing to anyone listening, check out that episode. And I'll put that in the show notes. You know, this week like to note to that a dependency injection framework is different from a model view controller framework, you do not have to use both of them in your application, you can pick one or the other, and get value out of them. So if you are at a spot where you have a giant legacy cold fusion app, and moving the whole thing to a framework out to an NBC app, I cold box still sounds kind of scary to you. But you know, you have lots of spots where you can consolidate five component create object calls into one column, that sort of thing. You can just drop a dependency injection framework into your spaghetti app, and actually use it right now you don't have to go the full on MBC way to get to a dependency injection framework. They're totally separate things. You can add one or the other, or both in your app as logistics allow you to do.
Michaela Light 28:57
That's great. So
You know, if someone has a large app, and they want to migrate to MBC, you mentioned some strategy already for chopping out code, and moving it over.
Nolan Erck 29:11
But any other strategies you recommend people listening do, um, there's a component in cold box, the name of which is escaping me at the moment. But it's designed for moving legacy apps into the call box framework easily. And I apologize, I don't have the name of it offhand. But there is a feature in call box to help move that over. Other things you can do not framework specific feature wise, that help put your code into a good version control system.
Make two branches up code, one called legacy for your current legacy
code base, and make another one called MVC. And
as you have time, just keep moving features into the MBC version of your app. And then you can switch between the two branches and a be your app as it goes to make sure that your legacy code is still working while you have customers using it. But anytime you add a feature or
fix a bug, you can copy that feature into your MBC version, switch to that branch and double check all the code, make sure it still works. And then kind of slowly move your app into a better structure that way. So that's another thing I'd recommend whether you're using framework, one, toolbox, whatever. A good version control system will help make this process quite a bit easier.
And a good one might be good, yeah, get popular one. Yeah, get gets the good protocol that everyone likes. GitHub accounts are free now, or super cheap if you need a private repository. And there's also other players in that field and federal com does really well for get and subversion projects. There's Atlassian, and Bitbucket and a handful of others that are that are all great and they all have different bells and whistles and options for number of developers that can join the project and that sort of thing. So you just you know just pick whichever one you need and go from there. And the nice thing about the good companies to is the project
They're all transferable. So if you set up a get repository on, for example, and funnel, and decide, oh, I need to feature that only Atlassian supports, you just import your repository into Atlassian. And all your code is still there, all your branches are still there.
You're not having to start over at ground zero or anything like that. That's a great tip.
Michaela Light 31:20
So anything else you'd recommend people do if they're contemplating moving a large?
Nolan Erck 31:28
I would. It's a big project. It's a fair amount of tedious kind of work. When you move to an MVC framework. All of the URLs in your app are going to change. You're no longer going to be going straight to site name.com slash Employee Details, that's the FM in a framework, you're going to go to site name.com slash index, question mark and then some sort of URL config thing telling the framework which model of you and controller combined together to make the employee detail event or
scope or whatever the whatever the naming convention is that they use in that framework. So there's a fair amount of tedious kind of work for it, maybe, you know, get a good set of headphones on a cup of coffee and just break the work up into individual tasks in some sort of good project management software. So you can follow along how far you're at in moving the code over
the. So you don't want to be trying to do several other things at the same time, I wouldn't know I would make this kind of its own separate task. If you have a bug fix, you have to put in your legacy app today because a customer is complaining, I would put that fixed in the legacy branch just like you normally would. And then I would make a separate task to say okay, now that that fixes in the legacy version, let's make a
an item on our Scrum board to move that into the MVC version, and I would just kind of manually move things over that way until the final MBC version is ready.
In addition to that, yeah, I would make separate tasks for things like update all of the URLs in the app,
move all of our CF queries into a model folder,
things like that as I would get into it.
Michaela Light 33:13
Now, some of the tools that might help you out with this Come on box. Yes.
Nolan Erck 33:20
Tell, you know, for folks and having us Come on box, what is that? So command box is sort of the cold fusion world's
answer to node. Notice been the big thing of the JavaScript plan that lets you run JavaScript from the command line, as opposed to in a web browser. And node also lets you basically run a JavaScript server if you will, from the command line and run all your code that way without having to
it without under switch gears, and it puts everything in one language and ecosphere. That's why the node has taken off really well in the JavaScript land. It's a command box, which is another order solutions product.
kind of brings us that same setup.
into CFL, rather than having to go to a browser and set up a new website in is, rather than having to manually install cold fusion command box makes all of that a command line thing, I can just type up a couple things that the DOS prompt, and it does it. If I need to switch from cold fusion version 10 to 11. I don't have to manually go up to adobe.com look for cold fusion 11 into my Adobe ID downloaded with the little Adobe download client that they have you sometimes I don't have to go through any of these steps to do it. You just in command box you say please start up a cold fusion 11 server and command box goes out to the cloud grabs the jar and runs it in seconds. There's no manual config involved in doing that. If I want to switch from I can switch from any version of cold fusion, I believe nine and up.
It might be 10 and up. But you can switch between 10 and 11. If there's a particular hot fix in let's say version 11 that I want I can say good
Version 11 point 1.02 or whatever the particular build is I'm looking for. You can also switch between Adobe CF and versions of Lucien raycho. By doing that same command line
trick, you just type in, please use Lucy 5.1 now, and it will go into the cloud, grab that JAR file, and boom, you're running on VC five.
I have a client that I saw this week, actually, they needed a new Cold Fusion server up and running for a really tiny web app.
So I went into their office looked at what they have thought, Okay, what are you using here and they said, what's basically this one page with a forum post on it, it does a couple of database queries. And that's about all we use it for. Okay.
Ran box server start Lucy 5.2 and had them up and running on a new instance of Lucy in minutes.
It really streamlines web development. So if you have to QA work between different types of cold fusion, it gives you the ability to write command line tools in CFL
You need to like write a tool to copy files from one directory to another things like that. You can do it all in CFL now.
It also automates again, back to the node example. One of the things node lets you do is you have a dot JSON file to basically build fancier JavaScript projects. You have an Angular app with lots of CSS frameworks that it uses maybe some jQuery plugins and that sort of thing. You can write little recipe, JSON files that node will use to say, go out to these five different GitHub repositories, grab all the code from them, copy them down into my project, move a couple of tasks around, rename this file, whatever the manual stuff is, you have to do to set up a project to get it working. Node lets you do all of that from the command line. And now with command box, we can do all of that in the cold fusion land as well. You have the same kind of JSON file to configure where all the dependencies are for your project. It will go out to the different GitHub repositories and grab them all for you.
We even have a second JSON config file in command box for controlling
The settings in your cold fusion admin. So let's say part of your setup in a project is you have to add a,
you have to turn a particular caching option on and off, or you have to add a data source to your app so that it talks to a database. Typically, you would go out into you open a browser, go to see if i d slash administrator login, data sources do all this manual stuff. With command box. That's all a scripted option now from a JSON file, just put your data source information in the file and you're done. You never have to manually go into the admin anymore, you can just set up your development environment. And it works quite nicely. So things like that the day to day, mundane tasks for setting up a new development project. A lot of that sort of work is now automated script double reusable, saves a lot of time and hassle with cold fusion projects, all because of command box.
Michaela Light 37:52
Nice, great, and we'll talk about the cost of command box and some of these other tools in a moment. But first other other
Nolan Erck 38:00
Any other tools that would help someone moving legacy code over to MBC? Oh, there's probably lots of things that help. Command box is a pretty big favorite of mine right now I use that a lot. A good source control app like source tree and a good GitHub or similar account. Those are, those are all useful tools.
Get a good idea as well, that supports CFO I'm currently using Sublime Text for a lot of my development. But cold fusion builder is also great if you need to go in and refactor code very quickly. Any of the eclipse based IDs will work like CF builder. I think CF Eclipse is still technically around if you wanted to try that.
sublime has some some good CFL support. Now.
There are a few others that have
CFL options in them as well. You can try. It just depends on I would just
Michaela Light 38:53
say, yeah, whichever you like was a lot of discussion about IDs. And it really is whatever
works for you. Oh, I think Sublime is probably the most popular one these days. It seems like they certainly was in the survey we did.
And I'm, I'm imagining that having more than one monitor probably helps you when you're moving code around between different places, I guess yeah, that could be a thing that people use. I I personally don't use two monitors, I use one.
Nolan Erck 39:24
But it just depends on what your workflow is and how you visualize relationships between code.
Michaela Light 39:33
So let's talk the cost of some of these tools. I know some some of them are open source so framework one that's open source that's free. Command box is free. There's free versions of get though you can pay if you want more privacy or other features. Yep.
Code box I seem to recall is paid.
Nolan Erck 39:56
Call Marxism. You can you can download cold boxing.
Is it for free to build whatever applications you want, if you need support for, like training, um, if you want to block off like a three day workshop to learn how to do something in cold box, then the orders folks do have different training options available and support options. And they charge for some of that that's how they keep the machine rolling and add new features called box. But know if I wanted to download. If I wanted to make 10 new web apps today and run them all on cold box, it would cost me zero dollars.
You can absolutely use that for free. I think the only things that we've discussed that have a pay component would be Sublime Text is technically free. But
if you continue using it, you'll get a little nag screen that pops up saying hey, you should probably support this app. And it's written by I think, one lone developer. It's not written by a big behemoth company with millions of dollars. So it's kind of nice to support the little outfits like that and show them hey, I do like a product and I use it you know to be productive. I think the cost on Sublime Text is
somewhere in the neighborhood of 30 or $35, so it's not terribly expensive if you do want to buy it and support the the gentleman who's making it
Michaela Light 41:09
get I'd encourage people if they're using it to pay, you know, yeah, absolutely. There is another another developer behind that software. Exactly support the products that you enjoy and that are making you productive so that they can continue being productive as well.
Nolan Erck 41:25
The n c f builder is paid, see others paid? I'm forgetting him. I think there's a 30 day trial version of that for free as well if you want to check it out. And then if I remember correctly, it will continue working after 30 days it just several of the fancier features get kind of disabled. I think that's right. It's been a little while since I've turned on CF builder.
Michaela Light 41:47
Yeah, I forget what was the What do we call? Yeah, what's that cool, not shareware, but
Nolan Erck 41:54
I'm forgetting a trial.
Unknown Speaker 41:56
trial. We were sure and maybe
Michaela Light 42:00
Hold Where? Yeah.
Nolan Erck 42:03
cripple Where is a cripple?
Michaela Light 42:08
Wouldn't be very PC. I don't think I
Unknown Speaker 42:12
can you see?
Michaela Light 42:15
Yes, there you go.
Nolan Erck 42:17
So source tree source Murray, I believe you have to make an account at at Atlassian calm before it will work. But making an account is also free.
And the nice thing about source tree is it works on Windows and Mac. So you don't have to pick one platform. Cold Fusion builder is also the same way it works on Windows and Mac and then get itself.
You technically need to get provider hosting company of some sort like github. com or unsubtle or Bitbucket or one of those.
Get has free options for accounts. I think the catch with that is your code has
To be public open source,
they might give you like one option for you get one free repository, I'd have to double check.
There's also unfollow, and Bitbucket and they all usually have some combination of a free account and then various tiers that from there that you can go with, depending on how many projects you have, how much privacy you need,
how big your project is, and that sort of thing.
Often I know github.com has a pretty good account. For most developers. It's around seven or $8 a month. And it gives you unlimited private repositories and unlimited public repositories. So make as many free open source things as you want. And if you also have 15 or 20 clients that need private repos, set them up in that same account and everything will just continue working for you.
And then, of course, if you have a bigger team need bigger functionality you can go there's like a GitHub organization account and there's Bitbucket has
different accounts and beanstalk and some of the other options are out there for you, too.
So the only thing so maybe an ID and maybe a fancier GitHub account, everything else is pretty much free.
Michaela Light 44:11
And all the coffee, you're going to drink into refactor the code.
Nolan Erck 44:18
So let's just change gears a little. And, you know, tell us why you're proud to use CF today. Well, I'm a consultant for a living. And clients will call and say we'd like you to build this web app or mobile app for us.
What do you think the best option is to maximize return on investment, get things done quickest? That sort of thing. And as a consultant, I do try to be as objective as I can and look at Okay, what technology are they currently using? what options are available? What kind of problems do I have to solve? and nine times out of 10 when I'm building kind of a standard web app? Cold Fusion is just the better way to go. I get more done per line of code out of the box, than I do with tools like now.
Or PHP or some of the other options out there. It just it makes me more productive more quickly.
So that's why I tend to continue going with CFL
Michaela Light 45:10
as a great reason. I mean, I tend to think if if cold fusion was made in Redmond with Microsoft standpoint, it probably would, you know, be more successful than it is today. Because so many shops just have those Microsoft filters on it isn't Microsoft then we don't like it. But they're missing out.
Nolan Erck 45:33
Agreed.
Michaela Light 45:35
So, you know, that has been talking the past about how cold fusion is dying and I think that's pretty ridiculous because like more and more sites use it and Adobe sells more and more licenses. I was just interviewing Kershaw.
I'm spacing on his last name, but
I'll put the episode in the show notes. And I think it's valid. Valid
Krishna, I probably just totally mangled it there. But something very close to that. And he was saying that they're selling more and more every year. And apparently he talks about that other day that was talked about at the CF summit from the main keynote.
So my question is, what would it take to make cold fusion even more alive? For the people listening? That's a good question. It,
Nolan Erck 46:26
it's definitely still a unique product compared to a lot of the things that it gets compared to even if those comparisons are sometimes unfair. People often say, cold fusion versus.net or cold fusion vs. php. And those aren't really fair apples to apples comparisons in in all the different ways you just get more features in a cold fusion install than you do in, let's say, a basic PHP install. And you have the support from a company like Adobe behind it, whereas PHP is more of a community driven project. There's not really a company I can call and blame if I find a bug in PHP, as directly as I can call Adobe.
Say, Hey, there's an issue here, can you send a consultant out and fix it or, or whatever.
So I think part of its going to be
somehow fixing that perspective people have have, it gets kind of unfair, but compared to a lot of tools that are free
and
finding other ways to get it in front of people that use it for more of the, what I'll call sexy, calm startup ideas, a lot of the
new startups that are happening now tend to go with a stack like node or Ruby, things of that nature that are
at first glance, more of the free scribble command line interface. Tools. My hope is that the success of things like command box will help push cold fusion forward in that direction is using command box mix. Developing cold fusion very similar to the workflow you would use for developing let's say, Ruby Evernote app.
So hopefully some combination of those things and Adobe's continue
support and Lucy folks moving forward with their version as well well
we'll start to get more traction on that and get rid of this call fusion is dead perspective
Michaela Light 48:10
yeah I'm working on stamping out the meme from the whatever blogosphere or the mental thoughts people have you know cyber anything confusion is alive and agreed done more than 50 interviews on this podcast already in the last year. That's great about other people you know thing to say it is a lot of you were at least three of them Nolan because you're such a nice guy. Again, so But yes, but and also the what I think was six cold fusion conferences last year.
Sounds about right. Mira, mira con and CF cam and CF Summit East and CF summit Las Vegas and
into the box and the MC DEF CON and I probably missed a name of brilliant
conference let me know in the messages people if you're listening to this episode and I missed your conference out
Nolan Erck 49:08
so I think that's a good thing. So met talking about CF summit. We're big conference, hundreds of people, all cold fusion. Folks, what did you enjoy about CF summit this year, um, you actually hit the nail on the head right there. I enjoyed seeing hundreds of CF folks in one spot. The other conferences are all really good. And I learned a lot at end of the box. For instance, that was a great cutting edge conference where I learned quite a bit of new current modern CFL development techniques. But the end of the box conference itself is physically smaller in size there they're growing each year. It just hasn't gotten to the size yet of cold fusion summit. So the nice thing about summit was
going to a conference for a product that has that perspective of a cold fusion is dying. And just looking around the keynote room and seeing four, maybe five hundreds
CFL developers all they're eager to learn new Cold Fusion techniques and development ideas. So very much like seeing the large breadth of people, they're
seeing some of the new things that are moving forward with the new version of cold fusion 2018 and hearing the features that they're working on the future of that that was great. I always enjoy talking to the folks from artist solutions and Blue River, find out what they're doing with their products. All of the artist stuff and Mira CNS are sort of some of the flagship CFL apps out there that helped put that technology in front of a lot of different people. So I very much like seeing what they're up to
talking to the other outfits and other folks finding out what they're doing with cold fusion.
Yeah, it was it was overall really good conference.
And the folks in Las Vegas Yes, it's in Vegas, which never hurts for fun and enjoyment after the conference is done. And the folks at convective wrote a cold fusion tuning guide. The
debuted at location summit this year too. So that was another nice thing to see. Helping to get people moving forward with writing better cold fusion apps was that guy from convective
Michaela Light 51:13
is great. Sorry, excuse me. I have a phone ringing. So no worries. So if people want to find you online, Nolan,
Nolan Erck 51:23
what are the best ways to do that? They can find my company at south of Shasta calm. I'm also on Twitter at South Shasta.
They can also email me Nolan at south of Shasta calm. And I'm on GitHub as Nolan irk the RC K. You can track me down that way. And I'll also be at into the box in April giving a talk on connecting v j. s with cold fusion. They can come say hi to me there as well.
Michaela Light 51:50
Excellent. Well, thanks so much for being on the CF Live podcast and have fun at all the conferences you go to this year.
Nolan Erck
My pleasure and likewise
