You can listen to the podcast and read the show notes here
Michael: Welcome back to the show. I'm here with Eric Peterson, and he is the module superman. He's written over 40 modules in ForgeBox and he's giving a talk … We're going to be talking today about modules make your projects have superpowers. He's giving a talk cf.Objective in a few weeks, and we're going to be looking at what exactly a module is and why you'd use modules, where you can find pre-written modules, how you can save time with them, and also you don't have to use them with ColdBox. You can use them with other frameworks so he's gonna talk about that. Also, we're gonna look at some of the ways you can use [inaudible 00:00:40], and putting together a query builder with modules, testing, and even how you could view the whole ColdBox framework itself as a module. If we have time we'll look about, because Eric only joined the ColdFusion community a few years ago, but he's been very prolific. So we'll talk about how it's different being a new ColdFusion developer versus a, how should we put this politely, the seasoned ColdFusion developer. So welcome Eric.
Eric: Thank you for having me on Michael, glad to be here.
Michael: Yeah, so what exactly is the module for folks who don't know what it is?
Eric: The easiest way to define the module, is probably to define it in terms in other communities. It's analogous to a Ruby Gem, or a WordPress plugin, or even a MPM package, if you know those languages. It's a self contained bundle of code, that can be reused across different projects, and even different platforms, like the web for ColdBox, or another framework, and even CommandBox on the Command Line.
Michael: Wow, you can even use it from the Command Line?
Eric: You can. I have a couple of examples where I used the same module on my website and in the Command Line with CommandBox.
Michael: And I guess the technical term here is encapsulated. The code is self contained, doesn't depend on other stuff-
Michael: You can just plug it in to your program, and away it goes, and does what it's supposed to do.
Eric: Correct, with ColdBox it's as simple as get it installed to the right folder, and you're off to the races.
Michael: All right, and you mentioned ColdBox there. What exactly is ColdBox, because not everyone listening maybe have used it.
Eric: ColdBox is an NFC framework provided to help you get from your idea to your end product quickly. It has a lot of built in features that help myself write code that's easily testable, and that's very dry and just a pleasure to work with. I love all the powers the ColdBox framework gives me. I'm sure I'll talk about some of them with my modules. If you've used something like Framework One, it's like that. It's got a lot more features packed in. That's how it puts itself out into the community as the feature filled one, as opposed to the minimal one.
Michael: And a NFC model view controller so it helps you split up your model from your view, and all the control code.
Eric: Correct, it gives you a nice framework to split that code up, and to encapsulate the things that need to be changed, and that will change more often, and just more organized code. It really helps on a team. We migrated about a year ago, still in the process of migrating some sites, and it's nice to know where things go as a team.
Michael: It is, I mean I think that really helps with maintenance, whether it's with a team or it's just yourself and your own code coming back to it a year later. I sometimes think when I write code a year ago, it's almost like a different programmer wrote it because it takes a little getting back into reading the codes. So having a framework organizing it, certainly helps with that.
Michael: So you really are a module enthusiast. You've written over 40 modules, and shared them with the public on ForgeBox.
Michael: Why would someone want to use modules? What's-
Eric: You know the example I like to start out with is a simple site I think a lot of your listeners will be familiar with, CFLib, a site that has user defined functions. It's a place that people go and they find the function that does what they want. They copy it in, and they use it. That's probably the simplest example of module that I can think of. It's code that you are going to need in multiple projects, and it's really tied to any single project. So the module format just gives us a way to package that up, and share it. Now you don't even need to go copy and paste, and find the place in your project. You can just install it through ColdBox, and ForgeBox, and you have a module in your application now that you can use. That scales all the way from a user defined function, to may a library of functions, or even the ColdBox framework itself is installed like a module.
Michael: Wow, well we'll talk a bit more about that later. I'm writing some code and I think that maybe there's a module that exist for that, how would I even find that a module exists? Is there some way to search for these things?
Eric: Yeah, the first place that I would go check is on ForgeBox.io. So the quick disclaimer is not everything that ends in box needs ColdBox. In fact most of them don't, and ForgeBox is put forth by Artist Solutions as the community repository for modules. It's used for all frameworks, all code, no framework, if you are still on that wagon, and CommandBox. So you can go there, you can search for a module and see if it has what you need. If it doesn't, you can write one and give it to the community so the rest of us don't have to write it.
Michael: That's great, or you could take one I guess, and fork it, or improve it, or-
Eric: Right, most of the modules are hosted on GitHub. There's some neat things you can do with CommandBox to install [inaudible 00:07:02] themselves, instead of going through ForgeBox. You lose some features, especially like versioning, if you go that way, but it's nice to have the option for some libraries. A lot of people, I don't think know how easy it is to make something a module. You need a box.json file, which CommandBox will help you generate, and that's it. That's the only required file to make a module in ForgeBox.
Michael: Wow, so if you had some code that was pretty well written, how long would it take you to make it into a module?
Eric: If I wanted it just up so people could download it, and maybe get the versioning features of ForgeBox? It would be up in a minute. If I wanted to wrap it with some ColdBox awesomeness, it depends on how much, but it only takes one more file, and some configuration in that file. So it could be anywhere from just two minutes at that point, all the way to ten or fifteen, if there's some neat features that we want to make available to ColdBox users.
Michael: Cool, so I mean you could be writing these modules to share with your own team members, or you could be deciding to share them with the public. If someone was considering, should I make this code public or not, what would you say to them?
Eric: Do it.
Michael: Why? I knew you were going to say that but I just want to get the why, because some people are a little shy about showing their code, sharing-
Eric: Yeah, and I can understand that. I think my response would be, you're not gonna get any good, constructive feedback if you're not going to share your code. The community will use it, or they will leave it, and that's fine. It's not a reflection on you. You might have a very different use case than everybody else. But you never know who is going to see it, and run with it. I put out a kind of alpha level module working with database migrations, trying to define them in code, and leave them in our library, and run them. I had some issues. I'd been working them out, but another community member saw it, and forked it, and took it over to a ContentBox module, and was able to make something that really worked for them. So while my module still is in alpha state, somebody else was able to make something really work well for them, and share that with the community. Now neither group, ColdBox or ContentBox users need to go and rewrite that themselves.
Michael: That is cool. So that lets other people give you feedback, improve the code. I'm guessing if you were gonna share your code like that, you probably make a little bit more effort to make it better code.
Eric: Right, and we have some awesome tools nowadays that can help you get a module, scaffold it up and running with a GitHub Repo, and even continuous integration testing on Travis for the [inaudible 00:10:19] without you having to figure it out all to yourself. So we have a lot of ways to help you get to good, maintainable code, and the community it awesome. The community will step up. They'll do pole requests. They'll add feature requests, and ideas, and it's just open source at it's finest.
Michael: So you've created a module but there are other things in modules with ColdBox. You have conventions. Tell us a bit about that, and how that gives you more super powers in your code.
Eric: Right, so you can think of modules in their basic sense as just a bunch of code that you download into a folder. You could take that code, and you could jump into a framework like Framework One, and you could set up your mappings with your Dependency Injection Container, and then use that code. You could skip that step, and just new up the components as you need them. Or, in ColdBox a lot of those are defined in a file, the module config file. That will do things like setting up your DI mappings. It will parse settings from your parent applications, so you can override module settings. In some rare cases you can actually write settings back to the parent application. You can set up my favorite ColdBox feature, which is interceptors. A good way to think of that is, event driven programming, announcing that an event happens and then acting on it.
That gives a really easy way to tie straight into the core request cycle in ColdBox and Application Cycle. One example of that, I have a verify CSRF interceptor that's a module. The idea being, I always forget to put the CSRF token and the verify call into my application, which could be a security concern. I wanted something that would try to verify automatically, and then it would yell at me if I forgot, helping me be a better developer. So with the ColdBox module, when I install it, it automatically hooks into the processing of the request, and checks that for me. So I literally just have to type, box install, verify CSRF and receptor, and the next time I load my ColdBox application it's working. I don't have to do any other configuration.
Michael: So you're talking about using a module from CommandBox or-
Eric: CommandBox is the easiest way to install modules. It's hosted on ForgeBox, and that's where CommandBox will look by default.
Michael: Oh okay, so you don't have to download the module code yourself. CommandBox will do that for you.
Eric: No CommandBox is a great package manager, and handles all that so no more zip files.
Michael: That almost sounds like a political campaign slogan. So you use modules with ColdBox, but what about using it with other frameworks? Tell us a bit about that.
Eric: I touched on that a little bit, as a module is just a bunch of code. It really can be used in any application. Obviously if you are trying to add features like interceptors to your module, it's pretty tied to the framework. A lot of that can be encapsulated in that module config file. The rest is left up to the other frameworks to map how they would like, or again, you can download the module. One module example I have that came to mind is a resource transformer for an adjacent API. You could download that. You could new up the components yourself, and pass those around. You could wire them up in your own dependency injection framework, and then use those. There's nothing inside them that requires ColdBox.
Ortus has done a great job at making it so all the bits that would be needed for ColdBox, or that could be enhanced by ColdBox, can be contained in that module config file. In fact, I've done a couple pull requests for projects I use that aren't ColdBox modules, to just add the module config file, so if makes it easier for me in the ColdBox application, and it doesn't change the code at all for anybody else using it. It's just a file that they ignore.
Michael: Then are modules just doing code behind the scenes? Or can they have a user interface that you can do admin stuff, or end user stuff with?
Eric: Yeah, so ColdBox specifically, a ColdBox module is a self contained ColdBox application. You can have the full MVC Suite in there of handlers, models, and views, and routing, and to defining routing in the module, which a common use case for ColdBox modules right now in the community is to use them as API versioning endpoints. So if I have an API, I could create a module for API V1. I could define the routes I want in there. I have even pull in code from a different module. So I can at least keep all my business entities in my application, and only handle the transformation, and the changes that might be different in the versions. When I'm ready for version two, I can make a new module in that folder, API V2, and that keeps both versions running with their own name space. So yes, you 100% can.
Michael: So what you're talking about here, you're using some third party API, and they've gonna and changed their whole API structure, and created new methods, or gotten rid of things, or changed the syntax, or done something else wacky. But you can protect your code from that, and have it run against multiple versions of the API, depending on what you want it to do.
Eric: Yeah, you could definitely do that. Specifically I was talking about providing your own API.
Michael: Oh, this is providing versioning for your API to other people.
Eric: Right, right, since that is a good practice that once you have a version, you never turn that one off. Or at least you give plenty of warning before turning that version off. It's just a really nice way to version your API. It's all contained inside this ColdBox module.
Michael: So what are some other things you've done with APIs using modules?
Eric: That's the biggest one, and I love that use case … Is that I can define a module, and inside there I have the handlers for my endpoints, my API endpoints. They have the transformation specific to the API, and if I'm going to make a breaking change, I can make a new module. I'm reusing the same business models, and now I can transform it in a slightly different way, or add the new relationship includes that somebody might want to get back, and I haven't had to touch my old API code. If there's a bug in one version of the API, I go to that folder, and I can then change that. Of course these are modules that aren't gonna be shared. You aren't gonna commit your API endpoints to ForgeBox. That's also a neat thing with ColdBox modules is you can have local, specific to your project modules.
Michael: And I think you did something with the GitHub API. Is that one of your modules?
Eric: Yeah I do have a wrapper around the GitHub API to make it so I can use it just without … Use the GitHub models, and the GitHub language, rather than a bunch of HTTP calls. That's up on ForgeBox's cbGitHub. It's definitely a work in progress. That's one thing that I tend to do with all my modules is I put it up there as soon as I think there's anything useful, because the community can come and help. The community can help show the direction if it's useful. So it has the endpoints that I needed for a project. One really neat thing is it can be used in ColdBox, or in CommandBox. So if you ever wanted to have your CommandBox commands interact with the GitHub API, maybe create a repo, you can do that with this module, which is pretty neat.
Michael: That is amazing. What are some other cool modules you've created? I think you mentioned a query builder you've made.
Eric: Yeah, so I have a bunch. I could go through all of them but that would be kind of boring. I do have a query builder called QB. If you are looking for some more flexible way to write some complex sequence statements, you can check that out. I have a API transformation tool based off of the fractal library in PHP, CF Fractal. Some more simple ones, I have a higher order functions library, kinda like you think underscore, or low dash called CF Collection. Some that I pull in all the time are a COREs library, which just helps set the COREs headers for ColdBox applications. A redirect back library, which helps to keep track of the last place a user went in their app, and give me a nice way to send them back, instead of having to know where they came from.
Some great ones from the community, we just saw a Postmark API wrapper come out to interact with Postmark, and send your emails through there. One of my favorite non ColdBox modules that I've been playing around with was a CFML Parser, to take a file and parse it out into different tokens. I'm excited for the fun things we can do with that with [inaudible 00:21:19] and code formatting. It's a great time to be part of the ColdFusion community there.
Michael: It is, well I'll put a link in the show notes that lists all of your modules there, so that way people can find them easy.
Eric: Great, thank you.
Michael: You're welcome. So what about testing? Do modules help with that in some way?
Eric: 100%, so if you've ever been testing an application, and you find that … You're trying to test a small piece of code, but the interacts in a certain way, and you end up doing more of an integration test, but you're not sure where the bug is, and you are kind of diving, and you're writing integration tests that really are testing small pieces of your module, but they're kind of tied because the code is tied. You probably have stopped testing that part of your application because it gets difficult. So one neat thing about modules is, you're taking your code, you're pulling it out of an application, and now you can test it in isolation. It's a lot easier to get full test coverage, for this small module, then it is to try to test, full test coverage inside your application. And it helps me wrap my head around what should I be testing, because instead of[inaudible 00:22:43] in a request, or this small piece, it's like I have one unit. It makes unit testing so easy.
Additionally, we have some nice scaffolding tools that include an integration suite if you are making a ColdBox module, that you can test your module acting inside of a ColdBox application. For instance, if you're making an interceptor, and you wanted to make sure that it's working, there's really no way to do that without starting up ColdBox. But you don't have to figure out how to do that. There's a module template that will scaffold that out for you, and it's out of the box. In fact that's one thing I definitely plug. If you're looking at making any ForgeBox modules, there is a CB module template up on ForgeBox, and it's a package for CommandBox that helps you scaffold out the module, all the required files, and folders structure that will get you going. It will create a Git repo, a GitHub repo, and give you Travis Build, out of the box.
The Travis Build is neat because it's testing on Adobe ColdFusion 10, 11, and 2016, and Lucee 4.5 and Lucee 5. So you're getting all of the major CF engines right now, and seeing if your code works on all of them, because everybody is on a different CF engine. We want our code to support that. We want [inaudible 00:24:14] to be useful to more than just, I developed it on Lucee 4, and so it works on Lucee 4.
Michael: So just in case anyone listening doesn't know, Lucee is an open source CFML engine. Travis, that's like an automation software or-
Eric: Yeah, it's a continuous integration platform. So it will … When you commit to GitHub, or have a pull request on GitHub, it will check out that code that just was committed. It will run a script, which in our case is going to run our tests in TestBox. If it passes, it will send back green. If it doesn't, it will send back red. So you'll know on your GitHub repo if the code that was committed broke something. Really great for pole requests. One of the things I love is that it, like I mentioned, it can test on multiple engines at once. You could do that manually, or you can, let Travis do it for you.
Michael: So very similar to Jenkins for people who have used that for continuous integration.
Eric: Right, one benefit for Travis is it is free for all open source projects. So if you have a public repo on GitHub, it is free to use Travis.
Eric: One of the reasons we picked it out.
Michael: Right, well that makes for much more reliable code, you know every time you make a change, it gets checked in, tested automatically with all the versions.
Eric: Right, I can't tell you how many times I think I've finished a module, and I push [inaudible 00:25:57] just to realize that I've left out a semicolon somewhere, because Lucee doesn't require those, well in all places, and then … It's nice to have that instead of somebody on Twitter or Slack message me saying hey, your thing is completely broken on Adobe ColdFusion.
Michael: It is, so we mentioned earlier that you could view ColdBox itself, the whole framework as a module.
Michael: How would you explain that?
Eric: If you wanted to install ColdBox into an existing application, this is something our team has been doing with a lot of our apps, rather than rewrite, you can solely migrate to ColdBox. There's nothing that says you can't. You can in CommandBox, type install ColdBox, and it will download the framework and install it where it needs to for you. So in that way it's just a big module. I know that Framework One has similar commands that help you scaffold out a Framework One app, and CFWheels as well, if we're gonna hit the three that I know. The three main MVC frameworks for ColdFusion. So each of those you can see kind of as a module, that gets installed, especially in the sense that it is shared, reusable code, so you don't have to type it, or copy and paste it every time you start a new project.
Michael: I think that's the biggest takeaway from this. If you haven't used modules, just go to FuseBox, browse around. There's over 100 modules there, which must mean you've written nearly 30% of the modules on ForgeBox.
Eric: ForgeBox yeah, and I think there's a lot more than 100, but I do have about 40. I'm not gonna say any of them are amazing, but some of them you'll find useful I hope.
Michael: Maybe I was searching the wrong way, but on the homepage of FuseBox it has modules listed, and it seemed to list 124 there, but maybe it was more there, and I'm just not seeing them.
Eric: Yeah, there's a lot of different package types, and you could consider all of those modules in some ways.
Michael: Oh, well then there's probably nearer to 200 then.
Eric: So yeah, if I have … I have a good percentage of them, but none of it's stopping anybody else from pushing it up too. Nobody-
Michael: Yes, let's get … What would it take to get to 1,000 modules on-
Eric: Right, I'd love that. I'd love that.
Michael: That would be really useful, because if you look at how other languages, like Ruby, or WordPress, or whatever … They do their reusable code, they have online repositories with thousands of different modules. So there's no reason ColdFusion can't have the same.
Eric: Right, or our favorite scapegoat, MPM and Node has … If you've used that, you know that your Node modules folder has hundreds of modules just for one project, which some people complain about, but the way I see it, is that's 100 things that I don't have to remember, and keep in my head. It just works.
Michael: And that maybe is good … You know if you went to the MPM repository, you might get some inspiration for something you could recreate in ColdFusion.
Eric: Yes, yes for sure. I've definitely done that. I've stole from Ruby, and from Node, and from PHP. I'll take it wherever I can get it.
Michael: There you go. So you mentioned earlier that you started doing ColdFusion maybe five years ago. So what's it like being a new ColdFusion developer, versus many of the other people in the community who've been doing it for 10, 15 years? Some people even started in the last century.
Eric: I'm sure they're love to hear it put that way.
Michael: Well I started in the last century so.
Eric: So I only started programming about five years ago. When I got to my first job, ColdFusion was the language they had just started using. It was a brand new development team. All of us were pretty new at it. They had picked ColdFusion. I didn't know any better. I didn't know any different, I guess I should say. I started using it. It was our own, homegrown something. I'm not even gonna call it a framework. I know that my team listening would agree with that. There was a time where I got to the point developing on it that, I just wished that we had something else, because I could look into some other communities, and see all the tooling they had, all the packages, or modules that they had to share, and see how we were feeling like we were doing everything from scratch. It's just kind of the feeling like you hear ColdFusion is dying, and I remember subscribing to that belief. What changed-
Michael: Well wait a minute, you didn't start it until after it had been dying for five years according to some bloggers, which is pretty ridiculous-
Eric: I know-
Michael: How could something be dying for more than 10 years?
Eric: It is, and you know something changed for me. I went to one of the ColdFusion Summits, and I decided that instead of just sitting in the sessions, I'd go try to meet people in the community and talk to them, and participate. For me, participation changed everything for how I see ColdFusion. I saw, instead of a lack of the tools that I wanted, I saw an opportunity to help shape those tools, shape the community. Projects like ForgeBox … I think ForgeBox is probably the most important ColdFusion development, or platform. I mean I haven't been around long, but it's brought ColdFusion into the modern era of package managers and the tooling that it has. So Ortus is doing a lot of great work to keep ColdFusion relevant, and exciting. Once that mindset happened, it became fun. It became fun to make a module that did it. It became fun to figure out how … What are the ColdFusion ways of doing this? ColdFusion has a lot of benefits. I love how fast it is to develop in. It feels, you can think of this as a pro or a con, it feels like Java Script to me, which is very familiar. It's nice that the syntax looks very similar between the two languages.
I love the ColdFusion Slack community, and the help they give. So yeah, I had a change there, and the change was, I'm going to give back. I'm going to, instead of whining, and moaning, and complaining, I'm gonna go make it better. It's made all the difference. I love working in ColdFusion nowadays.
Michael: That is great I think you've answered my next question, which is why you're proud to use ColdFusion, but maybe you have some other things to say there.
Eric: Yeah, I think the reason I'm proud to use ColdFusion is because I have an opportunity to give back. I think if you are feeling stuck in ColdFusion, if you're feeling like it's dying, I would wager a guess that it's because you're not utilizing the community. You're not going to them for help. You're not going to them for modules, and you're not giving back the things that you've learned. Because in my experience, that changed everything for me. I went from wanting to, trying to convince my team that we should move to a completely different language, and completely different [inaudible 00:33:59], to just loving what we were doing. We've been able to modernize in place, and bring our code more up to date, and it keeps getting better every day. So it's exciting to code in our applications now, and in ColdFusion.
Michael: Now, it sounds like you had a lot of fun modernizing in place, using new, some of the new frameworks and new tools out there, that are really cutting edge. I've compared this to what people do in Ruby or PHP. Some of the stuff in ColdBox and CommandBox, you can't get in other languages.
Eric: Right, it's a nice all in one encapsulation. Again, Ortus has put a lot of work in there.
Michael: Yep, and it's all freely available, it is amazing. So do you have any idea … Updating in place to modernize in ColdFusion, versus switching to a different stack. Do you have any idea how much time you saved by going that approach?
Eric: I don't. That would've been a really hard thing to do, to switch stacks because my team, for the most part were all home taught developers, had a little bit of training but not much formal training. That would've been … It took us a while to get the ColdFusion syntax down. It would've taken us longer to get something like PHP or, oh my gosh if we moved to Ruby. Looking at Ruby code is still like, what is this. So I don't know how much time we saved. I know we saved, I don't have a number, we saved a lot of time by not rewriting. There's a great blog post out there, it's either on the Ortus website or Brad Wood's website, about introducing ColdBox to a legacy application. We did that successfully with over seven applications. There's one of them that's still transitioning, but the other six have been fully transitioned to ColdBox, and it worked great. We could write new features, or if we were making a change, we could refactor an old feature, and introduce new things. It worked great. You don't have to rewrite your app, just move pieces at a time, and save all that time and money, and heartache.
Michael: Cool, so lots of great ideas for making ColdFusion alive there Eric. What would it take to make it even more alive?
Eric: If you have some code that you're using for project to project, wrap it up in a module, and push it up to ForgeBox. If you need help, you can come talk in the ColdFusion Slack, specifically the box products channel. There's a lot of us that hang out there that can help you modularize your code. I think you'll find of use in ForgeBox in the modules there. We want to find use in the stuff you've already written, so we don't have to do it again.
Michael: Fabulous. So what are you looking forward to at cf.Objective this year?
Eric: I have a solid place in my heart for cf.Objective. It was the first conference I got to speak at last year. One of my favorite parts was just being able to talk to some of the speakers. They have a really good ratio. The speakers are all really available. I love rubbing shoulders with the people who make Lucee, or make ColdBox, or just have great ideas. I know there's some great sessions this year about Docker, which I'm really interested in. I love the getting to meet people I've talked to online, and get to meet them in person. They're just as great in person, if not better. That helps keep me excited to work in this community.
Michael: Excellent, well hopefully it all goes good with your talk there at cf.Objective. If folks want to find you online, how would they reach you?
Eric: The best way is probably on Twitter. I am at _elpete, that's E-L-P-E-T-E. If anybody knows who has the Twitter handle without the underscore, I'd love it. I'm elpete on GitHub, or you can find me, the same name on the ColdFusion Slack, which if you are not signed up, come in. It is great, a lot of great conversation, great help from the community, and deciding how we're gonna move forward with modern CFML.
Michael: Great, well we'll put all of those links up on the show notes to this episode. Thanks so much for being with us today Eric.
Eric: Thank you. It was a pleasure.