You can read the show notes and listen to the podcast here.
Michael: Welcome back to the show. I'm here with Brad Wood and he is the amazing application system architect for Ortus Solutions as well as being evangelist for many of their Box products. Today, we’re going to be talking about design patterns so you can have amazing architecture in your apps and there's a whole bunch of patterns we're going to look at. We’re going to look at just in case you’ve been asleep for the last 20 years and missed what a design pattern was and how it affects coding. We’re going to look at that and why you should be using them and how they can be common solutions to common problems and help you produce better code in less time.
In fact, generally, just become better software craftsman and architect apps better. Also, we'll briefly look into the CommandBox two-day training that Brad is doing before the cfObjective conference. He's giving a talk on design patterns at cfObjective which is only weeks away now so, very excited for that. Welcome Brad.
Brad Wood: Thank you, Michael.
Michael: Just for folks who don't know, what is design pattern and I'm assuming it's nothing to do with design and Photoshop and all that, It's all to do with coding.
Brad Wood: Well, it's funny you say that. The concept of design patterns actually were not invented in the context of software development. The guy that actually originally came up with the notion design patterns was Christopher Alexander and he was an architect. He built buildings and he came up with this concept that you built tons and tons of buildings but you had the same repeatable patterns the way you would deal with empty space, the way that you would arrange rooms and things.
He wrote a book that had all the common design patterns that went into architecting buildings and it was after that, that that fueled the conversation of let's do this with software development. It's interesting to know that the history of software design patterns actually was rooted in the concept of just literally architecting physical buildings, just the same kind of idea.
Michael: Maybe made famous by the book Design Patterns that was written by that famous gang of four.
Brad Wood: Yeah. The gang of four actually was a direct response to a Christopher Alexander's work. That's what came out of that and so that's what popularized the idea of design patterns.
Michael: Fabulous.
Brad Wood: Yeah.
Michael: What exactly is a design pattern?
Brad Wood: It's good question. You should come to my session and you'll find out. No. A design pattern is the idea that there're common solutions out there that you're going to solve a problem. They have a name, some shared name that you and I can talk about the same solution. They're not really code per se. They can be represented in code but they're an idea. They're a baseline that you can take and build into your application to help solve certain things.
The important thing about them having name is that you and I might do the same kind of solution to a problem but if we don't have a common talking ground we can talk about that. That's like we’re speaking different languages. If I can say to you, well, this class here is a singleton class and you're familiar with that design pattern, you know what I mean, you know what those implications are. It provides a base platform where people can talk about the way they solve problems.
It's really a pool of common solutions you can dip into but it's not always silver bullets. Design patterns aren't really just copy and paste code, you stick this in your application and everything works. They're more of ideas that you can use to work into your applications. Of course, they typically come with pros and cons, which is why it's not always just one exact design pattern that always solves every problem. There's always usually something that you gain from design patterns and something that possibly you lose or just know a downside to it.
Being familiar with what patterns are out there can be very helpful and of course, it's interesting to note that different languages and different ecosystems have their own design patterns. There's a lot of Java, a lot of J2E design patterns that are very popular but not all of those transfer well to other languages, dynamic languages like Ruby or CFML. They might have some patterns that are more common to them, things like on missing method to be able to … the ability to respond dynamically at runtime to method calls that don't exist. That's a design pattern that doesn’t and can't exist in static languages like Java. More than just learning design patterns is knowing which ones are applicable to the paradigms of a language you're developing in at the time.
Michael: Well, there may be some patterns that apply to C but ColdFusion doesn’t need them because it deals with that design problem already.
Brad Wood: Absolutely. Yes. Sometimes you'll have language constructs that inherently help deal with the problem that you have in other languages. It's always good to know as they need to be familiar with this learning design pattern as possible but to know also why they're needed and when they would be needed. Otherwise, if you're just blindly following the pattern because you read in the book somewhere but you're not really sure like why you would use it, you might end up actually doing yourself a disservice.
Michael: In your talk, you're going to lay out some patterns that are useful for ColdFusion and help people in that decision.
Brad Wood: Yes. The goal is just to make sure that people are aware of what design patterns are, what the background is and why they need to be familiar with them. As a developer who considers themselves a software craftsman, developers should be thinking about what's the best way to build things. I mean this is true of many other skilled occupation in the world is there're certain ways people solve problems because they've been determined to be some of the best ways. As developers and craftsmen of code it's important for us to excel in that area.
Once I introduce it, my goal is to basically go through and just talk about some of the main really common design patterns that are specifically used for ColdFusion, many of which are in wide use and ideally show some code samples if they're simple enough to demonstrate each one to get people thinking about them. Then, what I also wanted to do in addition to talking about patterns that are desirable is I wanted to also spend ta decent amount of time talking about so called anti-patterns. These are design patterns that have been proven not to work. They have more of a detriment to your code. A lot of times it's just as useful to see examples of don't do this. It might seem like a good idea or you might do without thinking but it's actually a bad idea. That can be just as useful as being told do this because that's a good idea.
Michael: I guess spaghetti coding is one of those anti-patterns.
Brad Wood: Yeah. If you look at a lot of website that list patterns and anti-patterns, you'll actually see spaghetti code listed as one. That's more of when people just happens by or happens [inaudible 00:07:51] unless you apply better practices, you'll just end up as spaghetti code.
Michael: What was your favorite pattern?
Brad Wood: I don't know. You didn’t tell me you're going to ask me that question. There're so many patterns. I could say one of the most common patterns would be the singleton pattern. We use singleton pattern everyday, which is the idea of a class that should only be instantiated once and then shared throughout the entire application. I don't know if I'd say that's my favorite pattern per se. Those are the most common ones.
One of my favorite ones is probably the observer pattern which is also referred to as published subscriber. That's really common in event-driven programming where you have some events being emitted through a central source and you have listeners or observers that are responding. That pattern is very common in the ColdBox framework with interceptors and it's very common in a lot of languages and it's also a very powerful pattern since it helps you decouple pieces of your code base and concerns. That's quite possibly one of my favorite patterns, I suppose.
I've never thought about that question until just now.
Michael: Well, I'm here to bring out the best from all guests. Hitting that ball on the fly, a little over than that. These anti-patterns have some really interesting names like anemic domain model, god object, premature optimization, which sounds why you should go to your doctor for and improbability factor. Which ones you … There's one there that you need the most or …
Brad Wood: The anemic domain model, that's one of the first anti-patterns I learned about and I learned about it from Sean Corfield who wrote a whole book or not a book, a whole article in the Fusion Quarterly Publication back around 2008 maybe. Because it was very common in ColdFusion at the time around the mid-2000s, ColdFusion developers thought that Java was cool, so we should do everything Java did. Everybody was getting into join your programming and projects like the [Euclidean 00:10:07] I think it was p38 code generator came out. You could give a user that gives you user service and a user bean, and user DAO and a user gateway. Cancel all these objects for you.
What oftentimes happen is people would use these code generation tools and they would create a whole bunch of these empty placeholder objects. They would never really add any behaviors or meet to them. They would just be a bunch of empty objects that didn't do much of anything, but it was a pat yourself in the back, “Hey, I'm doing auditory development now because I've got objects coming out my ears.” You'd end up with this five to one problem that Sean will talk about where you have one table in your database and you have five CFCs in your application for each one table, which would lead to just a very large amount of CFCs. What made them anemic was the fact that they had very little implementation. They were mostly just a very small amount of [order 00:11:05] loop play code. They didn't really serve as a very rich domain model.
The anemic domain models when we have a lot of classes that don't really do anything, that they don't serve much of a purpose and so they're anemic and then they lack implementation, which oftentimes means that your implementations which has to be somewhere is littered throughout your views or your controller of your application as opposed to being in the model where it should be.
That's one of the most common ones followed probably by god object which a god object is an all-knowing class that's grown to a mammoth size and APIs so watered down because it does everything. It has methods from A to Z. It breaks the rules of having a program that does one small thing and does it well. instead you have a program that does everything and probably does it maybe sort of well.
God object is one that I've seen in my own code a lot. All classes start out small and over time, you keep adding things, and adding thing, and adding things, and then one day you look and you think I've got 1,500 lines of code and one CFC and it does so much stuff and you think to yourself this has become a god object. This is an anti-pattern that's hard to manage. That's where refactoring comes in, taking that, breaking it apart, turning that back into an appropriate pattern when you recognize the anti-pattern that you've developed on.
Michael: That sounds like a thing I've come across pretty option that APIs just have 20 or 30 parameters and they're trying to do a zillion things. They're really hard to understand.
Brad Wood: Actually, and they're harder test as well.
Michael: Yeah.
Brad Wood: The less responsibility an object has or a function has, the easier it is to test. In testing terms, we use that fancy word, the cyclomatic complexity. I always say it wrong, which is all the possible ways you can call a function with different combinations of input and get outputs. I mean, you're right, unit tests. You have to test every single one of those. That's a good code smell. If you have a function that has a thousand ways it can be called, it quite possibly has way too much responsibility that can be an anti-pattern for sure.
Michael: Yeah, I wrote an article on code smell. I think there were like 16 different pathways a code could smell. I'll stick a link to that in the show notes along with … I saw you did an article on Coder's Revolution about anemic domain model many moons ago.
Brad Wood: Yeah, that was quite a while ago. I think it was shortly after I read Sean's original article on that. When it comes to positive design patterns, these are things that we should know about ahead of time and we think to ourselves I have a certain problem, what are some solutions I can plug in here?
A lot of times the anti-patterns I think are patterns that just come about over time on accident and the important thing there is to be able to recognize them and see the code smells and your code and say, wait, this isn't quite right and then know how to fix them.
That's one of the goals of my talk at cfObjective is for education, help people know about the design patterns they should know about, know about the anti-patterns that they should be avoiding.
Michael: Yeah, know what to do. I think it's good to know what you shouldn't be doing and so you can spot it when you're looking at someone else's code, because truth is a lot of us work on other people's code which always is quite as good as the code we think we were writing even when the other person is really our self from a year ago.
Brad Wood: Sometimes you feel like it was written by a different person.
Michael: I think it was. Yes, what was this person up to?
Brad Wood: What's the quote that says something like develop as though the person who manages this code, after you'll be a crazy ex murderer who knows where you live or something?
Michael: I don't know that one, but it sounds appropriate.
Brad Wood: One of those things I read on the internet once.
Michael One of the other principles is can you get all the code onto one screenful in your monitor for wherever the object is because if it goes over 20 screenfuls, it's really hard to take it in.
Brad Wood: What about people who have a really big screen though?
Michael: Well, I guess they can. If you have already big screen, in theory, you could deal with bigger objects. Just show the folks your screen setup. You have a few screens there.
Brad Wood: Well, I had one that quit working today but I have four monitors here. The idea is that I can fit four times as much code into each of my functions without breaking the unspoken rule. It's really just a workaround.
Michael: You could have another eight screens there, just use your eyes and the back of your head to look at each screens.
Brad Wood: True. I can get a variable eight screens' worth of code into my function and still be within the legal limits.
Michael: Yeah. I think eventually we're just going to have brain implants that you will have the screen directly in your brain and then you won't have a limit.
Brad Wood: Yeah. Now, imagine if you're doing development on Google Glass or something and the screens just … wouldn't be able to fit much code at all in there, would you?
Michael: No, unless it was really teeny. Is that true though? I mean, Google Glass, your glasses take up a whole screen. If you're looking at a monitor, basically, the rim of the glass covers the whole monitor, right?
Brad Wood: Maybe.
Michael: If you work with your nose touching the monitor, which I haven't seen you doing.
Brad Wood: No, not usually. See, I think I always have to be careful with the rules of thumb like that. I think it's good if it's a rule of thumb. I've always avoided having hard rules that says, “Well, lineup code should never be too long that it goes past 80 characters,” or, “You should always put line breaks between your function arguments.” I always like to be pragmatic about it. At a previous job once, we've been trying to decide well, what's the exact number of parameters to an argument that's too many that you can't put them on one line, you should put in line breaks.
I really hated coming up with a specific number set in stone. I wanted to say, well, how about let's make it so it's readable and figure out what that means on a per function basis, just think to yourself is this readable and if not, improve it.
The one thing that I always look for is if a block of code has gotten so large that the beginning and ending curly braces for if statements or loops or threads don't fit on the same screen because that can really start to hurt readability when you open an if, or open a function, open an if, open a loop, open a closer, open a thread. Then meanwhile, six pages down you have like 17 ending curly braces all in a row. You're thinking which one of these is which. You know what, that's the …
Michael: If you're using a good editor, it does match them up for you.
Brad Wood: That's nice, but yeah, that's always …
Michael: I agree.
Brad Wood: … a good indicator. Well, let's take some chunks of these out and move them. I've come up with some pretty long methods myself. I can attest, managing those can be a lot harder when you have things spread over so many pages.
Michael: It also depends how long your parameter names are. If you're using descriptive names instead of X, Y, and Z for your parameters then your … Obviously, it's going to be wider.
Brad Wood: That is true.
Michael: That's a good practice.
Brad Wood: Yeah. With the exception of loop counters or something so that might be like I. I do always tend for longer names if I have the opportunity, but it does really help later on with instead of a variable called pass. I have a variable called pass to this file or something. It helps later on.
Michael: Yeah, that makes sense. I usually think of the code is effectively written once and read many times.
Brad Wood: Oh yeah.
Michael: You might as well make it easier on your future self on other people in the team to make it easier to read, and send the effort there. That's why these design patterns are important because they make the stuff easier to read and easier to maintain.
Design pattern's probably not going to make your program more powerful. I mean anything you can do in a design pattern you can do in crappy code with god objects and spaghetti code.
Brad Wood: Yeah, they probably definitely make it more elegant. I mean, a lot of the idea of design patterns in my opinion like MVC, for instance, is a design pattern, a very broad one. A lot of patterns are actually [fluxes 00:20:10] of other patterns. It's the idea that you can look at my code and if you recognize the pattern in use, it's easier for you to understand what was going on in the first place. It's definitely one of the benefits I think is that our developers immediately have an inherent understanding of what it is you're doing if they recognize the pattern you're using. Sure.
Michael: You mentioned also Brooks' law. Tell us a bit about that. Is that Mr. Albert Brooks the Mythical Man-Month?
Brad Wood: Yeah, there're some honorable mentions I was probably going to bring up just because they weren't necessarily design patterns, but they were definitely things you wanted to avoid. Brooks' law is the famous code that adding manpower to a late software project makes it later. That is from Mythical Man-Month which comes from the saying that one woman has a baby in nine months doesn't mean that nine women could have a baby in one month which is a clever saying that's also applicable to software development. Some things just take a certain amount of time. You can't always simply throw manpower at them. That's a common misperception you see a lot of times.
The project's behind the schedule, we'll add three more people onto the team and the reality, you actually, by increasing the team, increase the communication overhead, increase the total possible number of communication points, and increase the number of the amount of learning. That's a project management level anti-pattern that will oftentimes just delay a project further by a well-meaning manager, because development is described as knowledge work. It requires problem solving. It requires deep thinking. If developing was like warehouse job [inaudible 00:22:01] you just stick things in the bag. Sure, you can double the number of people on the line and double throughput but development work is not like that. There's a lot more knowledge involved.
I was going to say another honorable mention that is not quite a pattern or an anti-pattern but I like it is the law of Demeter. That's usually summed up or paraphrased to be you should never have a line of code that has too many thoughts on the same line so order.getthis.getthis.setthis.dosomething because it assumes a very deep knowledge of all the nested classes aside of the main class. What you're breaking is the encapsulation where you should deal mostly with the immediate API of a class, not have to worry too much about the implementation of seven classes nested down inside of it. That's an interesting one, because that's like a rule of thumb or code smell you can keep on the back of your head. If you see yourself typing 17 chained methods to dig down into another hierarchy and then do something with that 18th class you pulled out. Why possibly you don't have a very good API defined and so that's the law of Demeter.
Michael: I would paraphrase that as too many dots make you dotty.
Brad Wood: That's good. Can I use that in my slides?
Michael: Absolutely. Take it away. I just made it up.
Brad Wood: The best ones.
Michael: Then, I noticed there's a memento design pattern. Is that like that movie where the guy kept recursing backwards into his past?
Brad Wood: I don't think I've seen that one. No. The memento design pattern usually doesn't involve any recursion. The memento design pattern is something that we use quite a bit actually in a lot of our apps. It is simply the idea that you can capture the state of an object in some memento or, excuse me, packet of information.
What we'll usually do is we'll have a base class that most of our beans will extend and it will have a get memento method which will simply return some JSON objects to a serialization of all the properties in that class.
Then potentially, maybe the nested properties as well so I guess it could be at the recursive. That can be great for quickly populating the class instance or just representing the internal state of a class for maybe rendering that back out to the user as JSON or something. That's the memento design pattern. Probably talk about that one as well so just pretty straightforward.
Michael: A lot of these, they're not designed to be complicated. If you're intrigued by this you can pick up and start using one of these design patterns this afternoon if you want to.
Brad Wood: Yeah, and the idea is you're probably using some of them already and you never knew the name for it. That's part of the fun in learning it is you see things, you're like, “Oh yeah, I've done that, but I never really knew that was a name for it.” Now that you know that name, you can have a conversation with another developer and instead of spending five minutes to describe how the design works. You simply say, I'm using a memento pattern and the other developer goes, oh yes, of course, I'm familiar with that one. It really creates this common language between you and other developers.
Michael: I think having a common way of describing stuff and a language really helps, not just for design patterns, but if you've got something in your application or the requirement, it really helps to have a language to talk about that. Sometimes we don't think about the language we use, but it actually does make life a lot easier.
Brad Wood: Yeah, absolutely. I'm a big fan of communication that has as little ambiguity as possible. When you have a conversation with people in your life, let's put that thing in the functional and then we'll call it from the whatchamajigger. I hate those conversations. Wait a minute, what are we even talking about right now? I love having meaningful words that you know exactly what you're talking about and that happens at all sorts of level, not even in programming.
Michael: One of the anti-patterns I have seen a fair amount in ColdFusion land is premature optimization where people obsess about optimizing stuff before they've even run the app with realistic data.
Brad Wood: Yeah, that's a big one. There's a famous quote that says premature optimization is the root of all evil but that's tongue in cheek.
Michael: That's pretty strong.
Brad Wood: Well, it is. The developers can spend a lot of time worrying about what's faster if I do variable plus, plus, or variable equals variable plus one kind of things. The reality is in most applications, it's completely negligible. You can worry all day long about which function has an improvement over another function. The reality is you can spend a lot of time and in the end maybe for nanoseconds at most.
A really good rule of thumb there is always go with what's readable, go with what makes clean, clear, concise code always by default. Then, part of your suite of tooling at your job should include testing, including performance testing, scalability testing, load testing. Then, if and when things come up in your application, when you notice that there's a slow point. Then, go ahead and address that.
Otherwise, I mean I've seen a lot of people. It's a fun conversation. It's easy to take a function, stick inside of a loop, run it 10 million times and say, ah, this one was four second slower. It would have ran 10 million times. The reality is if you're like calling that functions four times, the couple picoseconds of difference, if that's meaningful in your application, you probably shouldn't be using ColdFusion or even Java for that matter. Most web applications don't have requirements that say you have to have response times in under five milliseconds or something. It's a waste of time even though it can be a fun conversation. It's oftentimes not worth the time to optimize things ahead of time. That's a very good one.
Michael: These days you can easily tell what code is running slow. There are a lot of tools that you can use to see where the slow code is. I mean, fusion reactor is one of them.
Brad Wood: Absolutely, I really like the profiler feature that's part of fusion reactor. Six I believe is when it started. Any request that takes over a certain threshold like three seconds long, it will immediately begin profiling. After the fact, it will show you the parts, the stack trace that the request spent the longest amount of time running, which is really, really, handy. That way, you may have a function that runs in a second, but it's called 50,000 times. There was 15 seconds worth of times spent in that function and it's one of my favorite features about fusion reactor to get off topic for a second.
The point is you wait until you actually see performance bottlenecks and then you address them, which assumes, first of all, that you're using the appropriate tooling. You're actually doing scalability and load testing on your app. Then, you have an appropriate time and place in which you worry about those micro optimizations as opposed to trying to just guess preemptively ahead of time, which you're using them wrong if you try to guess ahead of time.
Michael: Yeah, because you can't tell until you really run the app and in particular, until you've got realistic volumes of data. It may be that some code runs real fast when you've got a hundred records in the database. When you've got a hundred thousand records in it, it's running like a dog because you forgot to add the right index is the database often a reason.
Brad Wood: Sure.
Michael: You ain't going to find that out just by reading the code.
Brad Wood: Exactly. Well, that's where it can really come in handy tools like Jenkins or things that run a unit testing suite, an integration testing suite can also report how long those tests take to run. You can get really nice graphs that will show you how many tests you have as well how long it would take me to run. If you see some abnormal spike in the amount of time your tests are taking to run, that can be a sign for you to go and take a look and see as a database table tripled in size and then unexpectedly added additional time to your application. It can be useful as well.
Michael: [inaudible 00:31:21] the thing that the CommandBox helps with or test box, one of the box things I thought automatically helps with rerunning stuff and shows you where problems are.
Brad Wood: Maybe. I'm not sure exactly what you're asking.
Michael: I'm sure I've seen you demo something where it was rerunning tests and some things were highlighted in read when they were not being nice.
Brad Wood: Oh, are you thinking of the code coverage functionality?
Michael: It could be, yeah.
Brad Wood: There's several things …
Michael: I saw so many amazing things in the box, stuff into the box conference that touched …
Brad Wood: Well, so CommandBox 3.7, which I'll be releasing before the conference, has test box watchers, which is something we've unabashedly stolen from node again because it's really good idea. That's the idea that you can have CommandBox watch a directory full of code and then as you save files and you make an edit, you hit save in your editor. CommandBox will notice that a file timestamp has been updated and will just immediately run your test without any prompting to do so in a console window right next to it. You can get basically immediate feedback if you've broken something in the unit test.
There's also the code coverage test box reported that we have which ties in to fusion reactor. That's not so much for performance, but it will tell you what lines of code in your application have test coverage like were actually executed during the test and what lines of code were not executed during the test, meaning that they weren't covered. That might also be something else you've seen.
Michael: Yeah, I think maybe that hasn't been released during the [inaudible 00:33:07] conference. It sounds really useful thing because if you haven't run the code, how do you know it even works?
Brad Wood: Yeah, exactly. It's very eye opening to run your unit test and then with the coverage tool and you'll see if statements. In the code in the first half you'd see if it was executed, but the else block was never even hit by your unit test. What that tells you is you need to write another unit test that will go through that function and will hit the else. That way, you ensure that when you break the code inside of that, you'll know about it right away.
Michael: Also, if you're refactoring some spaghetti code seeing that coverage tells you that you may identify whole chunks of code are just never run.
Brad Wood: Yeah, absolutely.
Michael: I mean, I remember we did some refactoring on a program like there was a gig of code, but 90% of it was … Yeah, exactly. Ninety percent of it was copies of copies and copies of code that we tweaked and then thrown away. It was still littering the web root.
Brad Wood: Yeah, see. If you're using source control, which you should be, you should never have an excuse to leave stuff laying around the web root. If you want to do an experiment, create a branch. Exactly.
Michael: It's a good suggestion. I know as well as your talk on design patterns, you've got a two-day course before cfObjective on CommandBox. Tell folks about that, why should they come to that. What is CommandBox for the three listeners who don't know what CommandBox is?
Brad Wood: For the three listeners.
Michael: You've got to clarify what it is.
Brad Wood: Well, actually, so back up-
Michael: I hope everyone else.
Brad Wood: Yeah, to back up and start with your questions from the beginning, the last three years we've done our into the box conference the day before cfObjective, and so this year we've spun it off a couple months ago. You were there. Our own two-day conference in Houston, so we just thought, well, what are we going to do? What kind of training do we want to offer before cfObjectives? We decided to do a two-day deep dive into CommandBox. We did a full one-day workshop before any of the box with CommandBox that worked out really well. We had so much stuff to cover we could barely fit it in one day so we're going to do two whole days.
This is a class that you can sign up for. You can pay to attend. All you have to do is just fly out a couple of days ahead of time and it's in the same location, I believe, as where the cfObjective conference is happening.
Michael: In Washington, D.C. at the National Press Club.
Brad Wood: Yeah, in D.C., exactly. I saw, in fact, some of the cfObjective sessions are in the First Amendment Room. Does that mean we can say whatever we want in the session's what I was kind of wondering.
Michael: Does the First Amendment apply to ColdFusion?
Brad Wood: I don't know but we're in the First Amendment Room. I feel like I should just be able to say anything I want in there and be totally protected.
Michael: Well, you're cf for Life so you can say anything you want right here. What is it you want to say to this?
Brad Wood: Come to my workshop. That's what I want to say. Your next question was what is CommandBox for anyone who doesn't know. CommandBox is next generation tooling for ColdFusion developers. It's a command line tool that runs natively on Macintosh, Windows and Linux and it provides command line execution of ColdFusion code, it has a rapple which is the ability to just write code one line at a time and executed immediately from the command.
It allows you to automate ColdFusion task so instead of writing shell scripts or batch files you can write, you can write CFML files, run them as con jobs. The scaffolding allow you to quickly create applications. There's plug-ins, modules, and CommandBox for the ColdBox framework, for the framework one to framework four that preside CMS4, CFWheels framework, so there's a lot of plug-ins. Even though it has a box in the name, it's absolutely not just for cold box users for any ColdFusion user.
One of the most useful things it does is it start servers, without having to have any previous installations on your computers so you can start, lose these servers of any version and even Adobe ColdFusion servers, 9, 10, 11, 2016, and all of that any installation. Just box start server or server start rather and so it's …
Michael: You don't have to download the install for it?
Brad Wood: No, you don't. The only thing you ever have to download is that initial exe file or just a binary if you're on Unix-based operating systems and that's it. Everything else you need is downloaded on the fly so if and when you start an Adobe ColdFusion 11 server as part of the startup, it will do a one-time download behind the scenes or grab some WAR files but you don't have to do any manual installations, which is really nice so you can test the same application running at multiple engines all simultaneously by just spinning them up with CommandBox, interacting with them and then shutting them down when you're done. It's a really good tool.
All of our cloud-based offerings, the tooling that we're creating, we have Heroku Buildpacks. We have Docker-based images combined with our CFConfig projects so you can basically wrap up any ColdFusion imaging you want with any configuration you want. Data sources, mappings, all scripted at deploy time and package that with your application code. All of that is based on using CommandBox as the engine that starts up and run. There're a lot of people doing Travis CI integrations for the unit test. It's all based on CommandBox.
In fact, I've been playing this week with deploying some stuff to Heroku which uses CommandBox to spin up the server, all of our Docker and Docker swarm work have been using our CommandBox images. That's all going to be part of what I've talked about in the CommandBox workshop is how you can use CommandBox to have better local development as well as better cloud development.
Then especially we're going to just focus on extending CommandBox. You can write your own custom CLI commands. You can do task runners now. What we want to do is help empower people to build really cool reusable, libraries in CommandBox and then share those on [Forge 00:39:37] box as modules and there's really great tooling in place now that people like Eric Peterson have helped put in place where you can scaffold out a new CommandBox module and publish it on GitHub with a full Travis CI suite of unit tests. All in just a couple commands. It's super easy and it's super simple to do now.
A lot of the CommandBox training is showing people how to do that so people can contribute to the CFML ecosystem that we have in place.
Michael: That sounds really exciting. It seems to me that all these things that you're showing folks how to do with CommandBox and continue with integration and using Docker, I mean those are not design patterns but there's something similar about how here's a modern way to do ColdFusion development.
Brad Wood: Yeah, they are very modern. These are things that had been prevalent in other languages for quite a while. People have been deploying apps in the cloud and scripting the configuration and doing continuous deployment and continuous integration for a long time. The ColdFusion community specifically has always lagged behind in that area. People always seem a little bit slower to pick up these newer practices and I think a lot of it was two main things, lack of tooling and lack of education, just about those things in general and how to do it in ColdFusion so.
A lot of our Ortus libraries like CommandBox are filling the tooling gap and then things like our workshop are trying to fill the education gap. There's just a lot that people don't even know about. In fact, I mentioned CFConfig, a project built on CommandBox that allows you to script all the data source settings and mappings and all of the configuration for ColdFusion servers, Lucee and Adobe. I mentioned that to some this last week. Even though it was announced three or four months ago, they have never heard of it in their life and they were like, “Oh man, I needed this two months ago.”
That's why we do things like these workshops and stuff to just try to increase awareness of the tools that are out there so people can modernize and improve their workflow, be better developers, really.
Michael: Fabulous, so let's just switch gears a bit, why are you proud to use ColdFusion today?
Brad Wood: Yeah. Well, several reasons. I am a proud to use Cold Fusion because the people that are in it and there was a lot of friends that I know that are fellow ColdFusion developers. I'm proud of the things we've built and what we've accomplished. When I talked to Java developers who are in ColdFusion developers, I'm proud to use ColdFusion because it makes me productive. It gives us a great language. It solves my problems and it solves them more quickly and easily than some of the languages so that's why I'm proud to use ColdFusion is because how productive it makes me and the modern language that it's become.
Of course, it's good to know that I'm a part of building the ecosystem, the open source projects out there that are shared on GitHub and shared on Forge box and the great thing about that is that everybody can be proud to be part of the open source ecosystem. That's not a secret club that you have to be in or there's no barrier to entry. Anyone who writes a reusable function or module and they stick it out on Forge box and they publish the code, they can also be proud to be part of building the open source communities.
I like to make sure we're always inviting other people to be a part of that because it gives you a lot more ownership and feeling of contribution in the community when you can say there're people out there using something I've written and everybody can do that.
Michael: In the process of writing an article on why ColdFusion and [inaudible 00:43:46] and part of that research was finding the [inaudible 00:43:49] article special ColdFusion is dying which obviously is not the case because some of those article date back 10 years. What would it take to make ColdFusion even more alive this year?
Brad Wood: Well, I think one of the first steps is for people to attend conferences like cfObjective to grow us developer and to learn things and to attend workshops like the CommandBox workshop just so they're always learning new things. One of the stark differences in a lot of other programming communities in ColdFusion is in a lot of communities people have a big focus on best practices and using the frameworks and using design patterns and using tooling. It's just baked in to the communities and expectation.
We don't always see that as much in ColdFusion and so I think a good goal for people to set is what's the new thing you're going to learn this year, what's the new thing you're going to learn this month, maybe this week, even if learning just means reading some blog post on Docker so it's a bit more demystified. You always have to be continually learning new things to keep yourself up to date on a topic. One thing that Sean Corfield had talked about he tried to learn a new language every year, right? I think that's a cool goal to say, what am I going to learn.
For ColdFusion developers, what new ColdFusion technology or library you're going to have a chance to dip into, are you going to learn? I think that will help make ColdFusion better, make ColdFusion more alive and it will make the developers doing ColdFusion more proud of what they do. When you talk to another developer that's not a ColdFusion developer, you could more proudly talk to them about the modern practices that you're doing and not have to be ashamed of the legacy ColdFusion app that you managed that was written like it's 1999, right?
Michael: Yeah, best lonely party like it's 1999, not code like it's 1999.
Brad Wood: Yeah, you can party like it but don't code.
Michael: Misquote [prince 00:46:09].
Brad Wood: Is that were that quote came from? I never actually knew one.
Michael: Well, it was on one of his album. Yeah. Party like it's 1999. I think it was released prior to the end of the millennium so it sounded more exciting back then.
Brad Wood: It was exciting back then. I actually had a song I wrote called the Y2K Song back in like 1999. I played it at our school talent show because everybody loved it. Of course, until after the year 2000, it was like, oh well, nothing to see here.
Michael: Well, I'm working on a CF for Life song right now with someone who's a musician so it will be coming out soon.
Brad Wood: Nice.
Michael: Yeah.
Brad Wood: Excellent.
Michael: Another … Hmm?
Brad Wood: I was saying there's quite a few musicians in the ColdFusion space.
Michael: There's a lot. I think the ability to do music is related to programming. There's a correlation there.
Brad Wood: I absolutely agree with that.
Michael: The other thing with learning is why not pick a design pattern to learn this month and maybe if you're working in a team, everyone in the team see if they can utilize that pattern in that code that month and that way you have something to talk about.
Brad Wood: Yeah, that's a really good point. In previous places I'd worked at, we started a book club and people would write through books like Uncle Bob's Clean Code. There's a whole number of design pattern books that would be excellent to read through as a development team. You could each week take one pattern, everybody reads through and just talk about it. Talk about it if it would work in your application. If you're using it, if you're using it correctly. That's a really good idea.
Michael: Yeah, I like that. Book of the month or method of the month or maybe it's learning how to use Docker, ColdFusion or Jenkins or any of these, or CommandBox even.
Brad Wood: CommandBox, yeah.
Michael: Yeah, cool. cfObjective is coming up real soon now. What are you looking forward to in the event?
Brad Wood: I always look forward to the same thing and that's meeting people. Usually, the same people I've met before but always new people as well. In fact, I was just speaking with someone on Slack this morning that was asking about the CommandBox session and talking about cfObjective, and I don't think I've actually gotten a chance to meet him in person so always looking forward to getting together and talking with people.
I'm a big fan of the hallway track as a lot of people call it in conferences. I go to a lot of sessions. I also like to just talk to people in the hallway so I'll be at the Ortus booth and there will be a bunch of Lucee association members there as well and we're all looking forward to just talking with people. I get so many good ideas at conferences. I get a lot of feedback at conferences.
People that maybe will come at the mailing list but they'll see me in the hallway and be like, “Hey, I was using CommandBox, the other day and I was thinking, wouldn't it be cool if you could do X, Y, Z. I'll think, such a good idea. I'll put in a thicket for that, we need to do it. My favorite parts of conferences is always just being able to talk with people that use our open source products and use things as getting feedback hanging out with them.
Michael: Yeah, I think a lot of people get that from conferences and a lot to learn in the sessions as well. Find out what's new is happening, what you've missed out on in the past.
Brad Wood: Yeah.
Michael: If folks want to reach further, how would they find you online?
Brad Wood: Online, one of the easiest ways to ping me is probably in the CFML Slack team. I hang out in the box products channel. I'm also on Twitter or if they have any questions specifically about design patterns on my session, they could just email me at [email protected] as well.
Michael: Excellent. Well, really appreciate you coming back on the show, Brad, and hope your talk at cfObjective goes wonderfully.
Brad Wood: I hope so too.
